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

[Luke]

Systemd has no effect on packaging systems

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.

[mike4]

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

[emblemparade]

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.

[Luke]

That it will

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.

[kalin]

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.

[Luke]

That would be simple

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.

[Akka]

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.

[calc]

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.

[dungeon]

It's not so bad especially for closed source projects like games.

Something like this

https://www.portablelinuxgames.org

[jo-erlend]

This looks like snappy packages should be easy to use on other distros, while packages from other distros will become hard to use on Ubuntu because they won't have their own libraries packed with them. That will become an incentive to package for Ubuntu and provide instructions for extraction to a folder in /home for any other distro. Hell the "meltytech" folks have offered kdenlive as a nightly build tarball that extracts to a folder in /home for years.

Let's say you're in a Debian system and you have a package, helloworld.deb, that you'd like to convert as a system independent snap. This package, for some odd reason, has dependencies that you want to include in the snap. So then you do deb2snap helloworld.deb. This will give you helloworld.snap which includes helloworld.deb and all dependencies. If you don't want to include the dependencies, you'll do deb2snap -d helloworld.deb.

Doesn't exactly sound like a nightmare, does it?