Announcement

Collapse
No announcement yet.

It's A Long Road Ahead To Get Ubuntu Snappy On The Desktop

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

  • #21
    Originally posted by riklaunim View Post
    In general that's how Android/iOS apps work. Aside of OS SDK they come with everything they need.
    Sure, but do you really want to revert to that very limited phone functionality on a desktop?

    iOS doesn't even do real multitasking but still struggles with 1/2GB RAM and while Android does real multitasking most good phones have 3GB+ RAM, and still run much more limited scope apps and fewer of them than average for a desktop system. Also most laptops still only come with 4GB-8GB today and would need orders of magnitude more RAM if every app had its own full set of libraries.

    This idea could work well for the Ubuntu SDK apps, but not for much else.

    Comment


    • #22
      Originally posted by blackout23 View Post
      Finally Canonical is is tackling the big hurdles of the Linux desktop.

      If snap packages don't affect the rest of the system and are shipping their own deps or depend on frameworks you should be able to install those on any distro. That would be the best thing to ever happen to Linux on the desktop.
      The package still depend on stable frameworks ubuntu provide. I bet a lot of them are going to have dependencies on unity 8 specific libraries. To run them outside of ubuntu you probably still need to provide the ubuntu specific libraries. The snappy package only provide the application specific libraries. Just like with the android platform.

      Comment


      • #23
        That would be simple

        Originally posted by blackout23 View Post
        Finally Canonical is is tackling the big hurdles of the Linux desktop.

        If snap packages don't affect the rest of the system and are shipping their own deps or depend on frameworks you should be able to install those on any distro. That would be the best thing to ever happen to Linux on the desktop.
        That would be simple: copy the necessary libraries from Ubuntu and drop them into the folder your "export snap" installs in /home, just like a Meltytech kdenlive setup with it's own versions of QT.

        Comment


        • #24
          You have highlighted exactly why this is a bad thing. Shipping libraries with every app instead of properly using shared libraries will cause memory utilization to skyrocket..
          I think shiping of dependencies is optional. If developer dont ship all libs application will use defaults i'm not sure but sounds logical.
          Last edited by kalin; 05 May 2015, 05:07 PM.

          Comment


          • #25
            That it will

            Originally posted by calc View Post
            You have highlighted exactly why this is a bad thing. Shipping libraries with every app instead of properly using shared libraries will cause memory utilization to skyrocket.
            That it will, meaning one or two apps from Ubuntu will be OK but a whole ecosystem of them would be a disaster. Thus, using another distro (or Deb based Ubuntu as they just said would still be supported) and only using Snap package based apps when you must will give better performance and memory usage. You would fall back to a snap package most likely when you found something uninstallable on your native system. This is exactly one of the things the Meltytech kdenlive folders are so good for: dealing with temporarily broken installs.

            For now I have just about finished a difficult conversion to Debian Unstable, but will support using my packages in UbuntuStudio as long as I can. This is because UbuntuStudio based setups with my additions will be easier to support for others who use my setups, at least for what Ubuntu calls the "forseeable future" of their continuing support for debian package based installs.

            Comment


            • #26
              There is a lot of confusion over this issue.

              tl;dr: Ubuntu will not and cannot abandon the Debian system anytime soon.

              .DEB files might look a bit like .RPM files, but their whole premise is vastly different. A .DEB (and also a .DSC, which is the source version of a .DEB) are merely a final deliverable products of the Debian build system, which is a large and very well-thought-out way to build free operating systems based on the idea that contributions may come from outside of the main tree ("upstream"). It allows for defining build environments, applying patches, and really has all the basic tools for creating a continuous build system. This is a vastly different concept from the *BSDs, which are in a essence a monolithic tree repository. The Debian build system was an enormously productive innovation that allowed for a relatively small team to build, test, and deploy a complete operating system from disparate contributions. The Debian build system is Debian.

              So, as long as Ubuntu is based on Debian, it will be using the Debian build system. Ubuntu's LaunchPad is entirely reliant on the Debian build system. All of the core packages will continue to internally be built with it. Since it's trivial to provide .DEB and .DSC repositories based on this system, once you have it in place, I don't see why Ubuntu would not provide this.

              What Snappy will provide is a new way to distribute the end result of the build system, while also allowing contributions from other build systems. For example, developers and vendors will be able to create Snappy packages without relying on Debian.

              How this mix will look remains to be seen, and I imagine that there will be a lot of experimentation until we find the conventions. For example, it might make sense to put the entire base OS as one big Snappy meta package, which would make it very easy to roll back versions (kernel and base services) while keeping installed applications in place. This is immensely beneficial to server deployments, mobile, and could be useful for some desktop deployments.

              The container-based approach is incredibly powerful, a natural evolution from years of experience with virtualization technologies. It can allow a single OS install to support the needs of applications which each require a different base-set of dependencies, greatly diminishing the problems of DLL hell, streamlining OS version upgrades, and really in many ways making the idea of a "new version" of an OS less important than it is now.

              All very exciting stuff! But will probably take a long time to make it to the desktop, and as I said, will probably not make much of a difference for desktop users who are not developers or admins.

              Comment


              • #27
                Doesn't systemd make all those packages obsolete in some years?

                Comment


                • #28
                  Systemd has no effect on packaging systems

                  Originally posted by mike4 View Post
                  Doesn't systemd make all those packages obsolete in some years?
                  Systemd is an init system, delivered by a packaging system. Both Snappy and dpkg/APT (for debs) are packaging systems. Systemd, Upstart, Sysvinit, etc do not affect choice of packaging system, nor is any packaging system I am aware of incompatable with systemd. It is start/stop scripts (preinst/postinist/prerm/postrm in debian) that sometimes have to be rewritten, and that is on a per-package basis. That can obsolete a particular package build, but not the packaging system.

                  As further proof, I am writing this from Debian Unstable with systemd as the init system, delivered of course by debian packages. Even the 60+ packages I built myself were packed into .debs for installation for convenienece in working with them later.

                  Comment

                  Working...
                  X