Ubuntu’s snap apps are coming to distros everywhere (Ars Technica)

I'm an upstream developer on snapd and snap-confine. I am working on an article that describes snap confinement system. If you wait a few days I will link it here.

Regards
ZK

Apart from the fact that it should provide better "isolation" between different applications, everybody seems to welcome this format on the basis that it "avoids dependencies" by bundling all libraries in each software package. Yet, this has somehow been possible even with the traditional packaging formats (even if distros were obviously trying not to do it by any means). Many debs or rpm exist (mainly for commercial applications) that literally pack in everything.

Furthermore, it looks like the proponents of these formats saw that it was not possible to really bundle everything and introduced "frameworks", that look a lot like "dependencies" but at a much coarser resolution than what distros made us used to. Hence, it seems that the main point is the trade off that exists in the framework "coarseness".

Finally, I am trying to think of some practical cases. Suppose that I want to package the "asymptote" vector drawing program. This uses TeX internally. Should the huge texlive be incorporated in the much smaller asymptote package? Or should texlive be a framework that asymptote depends on? And if so, how much of texlive should go in the framework? All of it or just a subset? And if it is just a subset, will asymptote be able to use parts of texlive that are not in the framework by letting one install them later as other packages?

flatpak is just a rebranding of xdg-app (which is kind of an implicit recognition that snappy has been winning the PR race so far). The first commit to xdg-app's git repo came in December 2014, which is also when Canonical first announced snappy (as 'Ubuntu Core Snappy Edition With Go Faster Stripes' or something like that).

Not just closed-source software. Any application that's big, used for productive work and updates often has that problem. No way Krita users are going to be happy with Krita 2.9.7 on Ubuntu 16.04 for the duration of the LTS. I've got users on 12.04, still, and CentOS 6.5.

And even some rather endearingly deranged demands for support for Ubuntu 10.04 -- but since there was no chance of money changing hands, I told them to go and build it themselves.

If you have one program that can't work with newer than lib-1.0, while another needed lib-1.1 or newer, you had play silly name games with the lib packages, and thus the dependencies of other packages for the package manager to play along.

Now hop on over to Gobolinux, where each lib version is given its own branch in the directory tree, the problem largely evaporates.

This because unix from times immemorial have had mechanisms for dealing with multiple lib versions, and the GNU tools provide them to the Linux ecosystem.

Or you can go one further and look at Nix/Guix, where even compile time differences are taken into account when creating branches.

What the likes of Snap and xdg-app/flatpak is doing is just wrapping all that in containers/cgroups to be fancy.

I don't think the LSB *tried* to address these issues. What they did was to define a bunch of packages that the package manager would make available to apps. What they *should* (imho) have done was tried to define a way for the app to tell the package manager what was required.

They tackled the problem from the wrong end ...

Cheers,
Wol

No need to worry about different library versions, package managers of package names (who really cares if your propitiatory package does not exactly match the naming standard of distribution X?) and file layouts is a moot point for propitiatory packages anyway since they should all install into /opt/ anyway on all distributions.

Of course that would not build a single package for all to download, i.e the "how we are used to work on Windows" model which perhaps is the main problem here since those developers are used to how things work over there and expect Linux to be just like that but slightly different.

It seems that krita is in the git repo for apps that have been built, but i can't find a built version of it.

I'm really happy that they went with a wide release. I suspect becoming a (/"The") Linux Appstore is part of this strategy. Maybe we'll actually get a Year of Linux Desktop!

On distributions with the right kernel features enabled you could run them with strong confinement (X11 notwithstanding) for an added layer of security.

> I have heard that there are occasional conflicts between packages that the base Linux OS (e.g. Debian) wants to install vs. the versions that Steam wants to install.

Probably just initial teething issues with packaging new software and a vendor getting used to a new platform. I've never seen any material issues, and beyond users misunderstanding 32-bit requirements, I can't recall any issues in my 2 years of using it.

It would be trivial to distribute Steam in a Snap, but you'd see the same behavior where the shipped app just bootstraps an per-user installation in ~/. Of course they could change to shipping a Snap and hosting updates through that mechanism. However, I believe it works this way at present because it works on all supported operating systems: OS X, Windows, and Linux. The minority platform is unlikely to get special treatment.

Formal APIs for accessing OS services along with containers is what is required. A model that works is how Android manages it's sandboxes.

Building helps to create the strong division between what is 'OS' and what is 'Application'. So it's needed, but by itself is not the full solution.

A high level example is: Application wants to perform some action that requires some privileged access to OS features (ie: networking, printing, etc) then OS assesses if the app should be given access to those services. If application is denied then it gets a error back and how it proceeds after that is up to the application developer.

Dbus is a good mechanism in which to provide standard APIs, but something like kdbus is needed if you want more robust solution, I think.

One of the reasons why containers have grown in popularity is because Linux offers fantastic features in the form of MAC, namespaces, cgroups, etc. Simple things that are possible, like assigning a unique IP address and networking namespace to a application, is very difficult to take advantage of without resorting to using containers.

When IPv6 gains in popularity then it's possible to use a unique IP address for every TCP connection a application makes and the lifespan of the IP address tracks the lifespan of the TCP connection itself. How do you make features like this easily available to applications?

With containers even stuff like SELinux can be simplified considerably. Consider that Android has successfully moved to using strict SELinux rules by default with minimal disruption to users. This is because Android application environment was built with the concept of 'sandboxes' from the ground up.

> And it should be noted that Xwindows will be deprecated by wayland.

Sort of. X Server being the display manager is depreciated. Support for X11 protocol is not. Support for X11 is available by default in most Linux desktops using Wayland via 'xwayland'. I doubt many people are expecting that X11 is going away anytime soon.

It just seems so strange, and perhaps that's just on me for being too 'experienced'. If I put all my software version 'eggs' into the 'old' model of a distribution, I have one database to query to determine pending urgent and suggested updates from my disro. Now, I have:

* gem
* pip
* rpm and/or apt
* cargo
* curl | sh #omg
* npm

All potentially on one system. Is this really a reasonable alternative? Or is there some force that I'm missing here that is giving such benefits I'm ignorant of?

Don't get me wrong, I'm thankful for the permanent employment plan these ever-dividing abstractions gives us sysadmins. I'm really curious to read about the thinking behind it (and trying to avoid marketing blather as I go). Cheers.