The universal application distribution mechanism?

Snap is an attempt to address a number of the problems that have emerged in the traditional Linux packaging ecosystem over the years. To get around dependency issues, Snap packages ("snaps") generally bundle almost all of the software they need to run. Security concerns are addressed by running Snap-packaged applications in a restricted directory space, confined by the AppArmor security module, and further constrained by a set of seccomp filters. There is an "app store" mechanism for distributing and installing snaps, and a set of tools intended to make it easy for application developers to create their own snaps. Snap includes a transactional update mechanism intended to make application upgrades safe and painless.

Application developers have often wished that they could build a single package that would run across all Linux distributions. The nearly moribund Linux Standard Base (LSB) effort tried for many years to create an environment where that was possible, but the application ecosystem that the LSB developers were hoping for never materialized. Now Snap is being promoted as the true answer to the Linux application distribution problem, so it is not surprising that it has garnered a certain amount of interest.

The Canonical announcement claims that snaps now work on Arch Linux and Fedora, along with the expected Ubuntu variants. Support for CentOS, Gentoo, Linux Mint, openSUSE, OpenWrt, and RHEL is said to be in the works. It is too soon to say how well it will work on all of those distributions, since they don't all support all of the features needed by Snap. In particular, most distributions lack Ubuntu's patched version of AppArmor; the word is that containment is simply not provided on those distributions. The instructions for Fedora state that, for now, SELinux must be disabled — a little discouraging for a system that is meant, among other things, to be a security technology.

Some of the early articles suggested that Fedora had actively worked with Canonical to do the port; that came as a bit of a surprise to the Fedora community, which quickly verified that Canonical had never actually said any such thing. In general, Snap seems to have gotten a bit of a chilly reception in the Fedora community; see, for example, this post from GNOME developer and Fedora contributor Michael Catanzaro:

To find more information on Flatpak, see this article and this one for LWN's coverage back when Flatpak was still called "xdg-app." Flatpak has similar goals to Snap's, but, naturally, it differs significantly in the details.

Both Snap and Flatpak are designed around bundling applications with their dependencies, but Flatpak tries to limit that bundling by having packages depend on "runtimes" containing many of the basic dependencies. That should make the packages smaller and, perhaps, address some of the security concerns associated with bundling of libraries. The cost, of course, is that Flatpaks have dependencies associated with them. The idea is that the runtimes will be small in number and will be the same on all distributions, so one Flatpak should still run everywhere.

The Flatpak sandbox makes heavy use of namespaces — a difference from Snap, which generally avoids namespaces. As with Snap, seccomp is used to disable system calls that are deemed to be unnecessary. There are plans to use SELinux to further confine each sandbox, but that appears to be a future item, as does the "portals" concept that gives the user control over what the application can access outside of the sandbox. The lack of portals, in particular, means that Flatpaks still run with the sandbox disabled for now.

It seems unlikely that the Fedora and GNOME developers will simply set Flatpak aside and go with Snap instead. Michael went as far as to suggest that Fedora might refuse to allow the Snap package entirely, since it might undercut the Flatpak project; he was quickly informed, from a few directions, that "does not compete inconveniently with a Fedora project" is not on the list of criteria for inclusion in Fedora. But Fedora has invested significantly in this project — Fedora 24 will include Flatpak support in the GNOME Software application — and seems certain to continue to do so.

What direction that effort takes will be interesting to watch; the conversation made it clear that there are still a lot of unanswered questions about how Flatpak will be integrated into Fedora. What happens if an upstream project starts distributing Flatpaks that duplicate a Fedora package; should that package then be removed from the repository? What happens if the upstream then stops distributing its own Flatpaks, or fails to address a security problem? And so on.

To further complicate matters, distributors are not just facing a choice between two competing next-generation package formats. AppImage is yet another attempt to solve the same problem; it already runs on a wide range of distributions. There are also the various container formats, such as Docker and rkt, in the mix; they, too, are intended to serve as a mechanism for distributing applications. Distribution of full virtual machines is also not all that uncommon. As with traditional package formats, the Linux community does not suffer from a dearth of choices.

The porting of Snap to other distributions seems like welcome news for the community as a whole; it represents an attempt to solve some stubborn problems. But, contrary to some current headlines, it still does not appear that Linux will have a single, universal application-distribution mechanism in the near future. Instead, it rather looks like a confusion of competing formats and mechanisms, perhaps not entirely dissimilar to what we have now. Over time, it may well be that a relatively small number of formats will dominate and life will be simpler. But one should not expect that to happen this year, and it is not going to happen without some fights.