Announcement

Collapse
No announcement yet.

Ubuntu Planning To Develop Its Own File Manager

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #91
    Originally posted by nll_a
    You can sell GPL software, didn't you know?
    Yes, but you have to sell it as GPL software, you can't sell it as proprietary software.

    You can fork it at anytime, ditch the CLA and create a whole different beast.
    But you still can't sell it as proprietary software, only Canonical is able to do that.

    Yeah, I don't get why people think it's better to contribute to non-copyleft open source projects with a license allowing any person to make a closed-source application out of it over GPL3 software with a CLA
    Where did I say that? The thing is that the CLA makes it non-copyleft for Canonical (and for Canonical only).

    I don't think "everyone should have the right to close it up" is a good argument. The less people are allowed to do that, the better.
    Where do you got that quote from? Not from me... And no, not the less people, that just makes things unfair. None people should be allowed!

    So the CLA makes it easier for enforcing copyright and stopping GPL violations, hence it's important for Ubuntu.
    Bullshit, they just have to write/modify one line of code and can enforce copyright just as any other contributor. Best case of this would be that another contributor stops the violation for them so they save money. How is that bad?

    Worst case scenario Canonical turns upside down and close Ubuntu down, and we just fork it and keep it open forever.
    And in them meantime (before the worst case) Canonical happily sells the software to device manufacturers that will sell it on their devices as closed source. Will you as a contributor ever see a penny from this?
    Last edited by V10lator; 03 February 2014, 12:34 AM.

    Comment


    • #92
      Damn edit limit...
      Originally posted by nll_a
      Under US copyright law, which is the law under which most free software programs have historically been first published, there are very substantial procedural advantages to registration of copyright. And despite the broad right of distribution conveyed by the GPL, enforcement of copyright is generally not possible for distributors: only the copyright holder or someone having assignment of the copyright can enforce the license. If there are multiple authors of a copyrighted work, successful enforcement depends on having the cooperation of all authors.
      That's questionable at best and you stole it from the FSF, which also says on the same page:
      When the developers of a program make it a GNU package, they can decide either to give the copyright to the FSF so it can enforce the GPL for the package, or else to keep the copyright as well as the responsibility for enforcing the GPL
      Also Canonical is a different story: They want to make money, not stop GPL violations.

      Comment


      • #93
        Originally posted by nll_a
        To be fair, people just like hating on Canonical. The FSF and Apache Foundation CLA’s are pretty much equally broken.
        FSF is a non-profit organisation giving you the option to sign a CLA.
        Canonical is a for-profit organisation forcing you to sign a CLA.
        I don't know about the Apache Foundation CLA but wouldn't contribute as long as I don't do that.

        Linus is a genius, but he's not always right (also source of that quote would be nice, maybe you just took it out of it's meaning?).
        Last edited by V10lator; 03 February 2014, 12:59 AM.

        Comment


        • #94
          Damn edit limit again, yes, you took it completely out of its meaning:
          To be fair, people just like hating on Canonical. The FSF and Apache Foundation CLA's are pretty much equally broken.

          And they may not be broken because of any relicencing, but because the copyright assignment paperwork ends up basically killing the community.

          Basically, with a CLA, you don't get the kind of "long tail" that the kernel has of random drive-by patches. And since that's how lots of people try the waters, any CLA at all - changing the license or not - is fundamentally broken.
          If anything that quote helps my point of view ("Nobody will contribute"), but nice try...
          Last edited by V10lator; 03 February 2014, 01:07 AM.

          Comment


          • #95
            No Other File Manager Uses the Ubuntu SDK

            Canonical has already created their own file manager for Ubuntu Touch. This effort is just about deciding what must be included in the first desktop version of the already existing Qt5 file manager. I think it makes perfect sense for Canonical to create their own file manager using the Ubuntu SDK. Canonical needs to create good first-party apps that show a converged UI and programming model can work for other programmers.

            The great thing about the new KDE Frameworks 5 (once it is finished) is that Canonical can just pull in any KDE module on top of Qt they might want. At the very least indie app developers should be able to that for the Jolla phone, Canonical phone, or any future KDE touch and/or desktop efforts. It appears that writing the apps in Qt (with optional cross-platform KDE modules) should also make them easily portable to Windows, Mac OS X, Android, and possibly other platforms. Canonical chose the perfect time to move away from the Gtk/GNOME ecosystem.

            Comment


            • #96
              Originally posted by Aleve Sicofante View Post
              Care to show a picture of a Nautilus window with the zoom in/out bar and the list/icons icons?

              Zoom is ctrl+ ctrl-. No buttons. This is how I and the vast amount of users expect to zoom just like browsers.

              If you don't like the way gnome is doing things, that is your preference, but I think it is a well thought out design. I realized that that most of the buttons that clutter programs are rarely used and amount to little more than visual noise. Gnome 3 leaves only what is used a lot. Having the noise gone is nice aesthetic, feng shui or something.

              Comment


              • #97
                Originally posted by IgnorantGuru View Post

                The SUID approach is relatively secure for most setups. pmount is another popular example of an SUID mount solution along the lines of udevil. The complexity and often breakage added by more complex authentication schemes simply isn't worth it to most users in practice. If they worked more reliably, that would be another matter. They can also LOWER security because users disable or misconfigure them just to get them working at all (I see this very frequently). The complexity also introduces more places for security to go wrong. I do not consider udisks a highly secure solution, especially having seen the quality of its source code and the general development practices.
                just though i should add on the above as a developer of another mounting tool that is suid root named zuluCrypt[1]

                Accessing block devices requires root's privileges,there is just no way around it especially if you are also dealing with encrypted block devices.

                There are three ways of doing it.

                You can do it the way TrueCrypt does it.TrueCrypt just expects to be run from root's account and everybody who uses it just set up passwordless sudo for it.

                You can do it the way udevil,zuluCrypt or pmount does it.These tools are suid root.

                You can do it the way udisks does it.Udisks has a daemon called "udisksd" that runs privileged.udevil,zuluCrypt,pmount among others are just upfront with what they are doing while udisks is sneaky about it because it does not present itself as susceptible to issues these suid tools have.I mean,when was the last time anybody asked questions about udisksd running privileged constantly? Here[2] is an example of an opened bug on udisks that speaks of access violation in udisks.


                [1] http://code.google.com/p/zulucrypt/

                [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698774

                Comment


                • #98
                  Yawn. Yet another distro kiddie.

                  Originally posted by nll_a
                  Die, Nautilus, die!
                  Yadda yadda CLA yadda yadda. It's GPL3. Grow up.
                  That's funny, because even former Canonical employees don't agree with that:

                  Note:  This blog post outlines upcoming changes to Google Currents for Workspace users. For information on the previous deprecation of Googl...


                  Turning critical legal issues into a throwaway "yadda yadda" opinion is about the most childish thing possible. So how about you grow up, little boy.

                  Comment


                  • #99
                    Originally posted by nll_a
                    Hey, none of this is surprising at all. Don't you get it? We need apps that adapt to phones, tablets, desktops and TVs, and they need to be in QML in order to blend in with Unity 8. So of course a new one needs to be written -- and it actually is already being written for months now and used in Ubuntu Touch images. They are only asking what features need to be baked in so that it's usable on the desktop too.



                    Holy crap. If the community is writing the apps they're being exploited, if Canonical is coding the apps indoors they're tirants. Yeah, can't win there. By the way, if you don't agree with CLAs, just don't contribute to Ubuntu, Qt, or GNU.



                    Maintain that ancient piece of garbage forever? Hell no! Gnome 2 was the worst part of Ye Olde Ubuntu for me. Sure it was stable, but it was a terrible mouse-driven interface, only close to usable with Compiz. Unity was the only thing that made me upgrade from 9.10.

                    Unity is a wonderful shell, and it will soon become a wonderful, full DE so we won't have to deal with gnome devs butchering our apps.



                    The 90's are over, dude, get over it. Most of the world uses GUIs, so they have to support it as the default.
                    I don't think exposing the file system to regular user is a concept that survive to the future. People still sometimes miss it in androids and ios units because they are custom to it. My search based use is more about the metadata than the idea you browse a file system. Already most of my friends with iphones and ipads don't use the file browsing concept any more. In the future I think only systemadmins and developers think about and directly use the file system. And for this crowd of people, I don't think the concept of a command based interactive shell disappear at all

                    Comment


                    • Originally posted by Akka View Post
                      I don't think exposing the file system to regular user is a concept that survive to the future. People still sometimes miss it in androids and ios units because they are custom to it. My search based use is more about the metadata than the idea you browse a file system. Already most of my friends with iphones and ipads don't use the file browsing concept any more. In the future I think only systemadmins and developers think about and directly use the file system. And for this crowd of people, I don't think the concept of a command based interactive shell disappear at all
                      I always find the hiding of files on mobile devices highly offensive. It complicates things, not makes it easier. The files are there, but without a file manager you just can't see what files are there, and where the files are, and what they're about. It's like with Windows ever since XP (or 2000?) where they hide files by default, and doesn't even show file extensions. It doesn't help. On the contrary, it's confusing and prevents you from doing management tasks. It's supposed to safeguard you from deleting or moving important files, but there are way better ways of doing that (like requiring root for that and/or displaying a message noting that you should refrain from doing so). And meanwhile hiding the files is something malware can exploit to its heart's content (I've seen several viruses that make themselves hidden and then masquerade as something else, which would be blindingly obvious if things weren't hidden to begin with).

                      Comment

                      Working...
                      X