When Canonical Software, the company behind Ubuntu Linux, announced that developers from other distributions were working on Snappy packages, the media pumped a minor announcement into a major story.
The headlines alone tell the story: “Snap! Ubuntu 16.04 Just Made Installing New Apps MUCH Easier;” “Goodbye apt and yum? Ubuntu’s snap apps are coming to distros everywhere;” “Snap Packages Become Universal Binary Format for All GNU/Linux Distributions;” and “Ubuntu bids to eliminate Linux fragmentation by making Snap packages available to all.”
If this story were true, the headlines would have been announcing the most important news in Linux for several years. However, like much that seems too good to be true, the news was.
Snappy packages are a throwback to the static tarballs of the 1970s, bundling all the necessary dependencies for a piece of software in a single package and running from a container for added security. Originally intended for embedded systems, Snappy had in recent months been developed as a simpler method for installing desktop software as well. These efforts had attracted the contributions of developers from distributions other than Ubuntu, and Canonical was announcing that the Snappy format now ran on many major distributions and could be easily ported to others.
Unfortunately, even this simple story became distorted in the media. While other distributions were interested in Snappy, none have actually announced yet that they will use the format. In particular, the Canonical statement implied the involvement of Fedora with Snappy, provoking the comment from Fedora contributor Michael Catanzaro that Fedora is developing a competing solution called Flatpak, and that Fedora developers “have zero plans to adopt Snappy in Fedora.”
Ubuntu Core Engineering Manager Jamie Bennett further muddied the waters by blogging that “Distributing applications on Linux is not always easy. You have different packaging formats, base systems, available libraries, and distribution release cadences all of which contribute to the headache.” In the same blog, Bennett also claimed in some depths that snap packages are more secure.
The news seems to have come as some surprise to many, especially those who work with the .deb format regularly, who have always prided themselves on the quality of their packages. For instance, former Debian Project Leader Branden Robinson remarked, “It’s pretty cheeky of Canonical to spend ten years building itself on the foundation of reliability that Debian provides, and then denigrate the processes, technology and personal discipline that sustain that foundation.”
Amid all these conflicting statements, how are non-experts to know where the truth lies? In the interest of saving space, one way is to judge both the pros and cons of Snappy packages in the hopes of reaching a few less sensational conclusions.
1. Snappy packages mean less work for developers.
True. Currently, developers must either settle on a single package format, which inconveniences users, or else maintain packages for at least 32- and 64-bit .deb and .rpm formats.
2. Snaps are easier to build.
Questionable. Compare the instructions for building snap packages with the instructions for building .deb packages. Both are documented step by step, but each has its own jargon and only gets easier with practice. Neither is for beginners.
3. Snap packages remove dependency problems.
Debian developer Marco d’Itri speculates that this claim is made because an increasing number of technologies like node.js require a specific version of libraries. However, the whole point of modern package management systems like .deb and .rpm is to resolve dependencies with minimal or no user input. The usual solution in other formats is to specify a particular release or later, although that might not work in ever circumstances.
4. Snaps allow the installation of different versions of the same package.
True, but this feature is a characteristic of containers, not snappy packages. Containers can be installed on any distribution, regardless of its package management system.
Moreover, snap packages currently require Ubuntu’s patched version of AppArmor to use containers. At least for now, to have this benefit, a snap package must be built on Ubuntu to have this advantage.
5. Snaps mean greater security because each package is isolated.
True, but again, the reason is containers. The greater security could be had, although with greater effort, on any distribution. Desktop users might get similar security with firejail, which is simple and lightweight.
In addition, although defense-in-depth — that is, by multiple methods — is always sound security, modern packages are signed, assembled and maintained conscientiously.
Asserting otherwise has apparently angered maintainers who are proud of their work. For example, Ikey Doherty, who maintains the Solus distribution, has argued on Google+ that he has no need of snap packages because of Solus’ high standards.
Similarly, Debian veteran Josh Triplett writes that the reason for the high reputation of Debian packages is due not to the format, but to the Debian Policy, which sets the rigorous standards for packages. “Debian without the .deb format would still be Debian,” Triplett says. “Debian without Debian Policy would just be Sourceforge, or rpmfind [two well-known archives of Linux software].”
1. Snap packages are insecure on the X11 Window System.
True. Mathew Garrett pointed out this fact, but it has been mostly ignored because Ubuntu is poised to use Mir for graphical interfaces instead, while other distributions will be using Wayland shortly. However, X Window is likely to remain standard for most distributions for at least a year, and maybe two or three, so the concern is real enough for now.
2. Snap packages are much larger than existing packages.
This claim has been greatly exaggerated. A sample package of LibreOffice included debugging tools, making it appear four times larger than a standard package. However, without the debugging tools, the snap package was only about 50 megabytes larger than the standard package — a real but trivial difference except for those using older or smaller hard drives.
The serious overhead would come when several versions of a library or runtime environment are installed on the same machine.
3. Snap packages consume more RAM.
True. Using containers inevitably increases the overhead. But the difference is unlikely to matter on modern computers although it might offend some users’ sense of efficiency.
4. Software installed by Snappy is slow.
True in some circumstances. Snappy packages use SquashFS, the same filesystem used on Live CDs. To run, they must be loaded into RAM, and connect to UnionFS if an application writes to disk. In most other circumstances, applications installed by Snappy are likely to be faster.
5. Snap is poorly documented.
The documentation for the snap command mixes options for making Snappy packages with options for using them. Many of the concepts for making the packages — assertion, change, connect, plug, slot — are left undefined. Presumably, the quality of the online help will improve eventually, but meanwhile finding the omitted information can take a while.
6. Using snap requires learning two sets of commands.
True. Snappy is not meant as a complete replacement for other package formats. The basic command must be installed by other means and uses a set of options unlike those of other formats.
A Birth Much Exaggerated
This summary makes two clear that the stories about Snappy have been distorted beyond credibility.
It also makes clear that, Snappy is a technology that is at early beta stage at the very most. It attempts to solve problems that many do not see any pressing need to solve, and, like many new technologies, its advantages seem to depend tradeoffs. Its success will depend very much on how it develops, and on how its developers address some of its current limitations.
Much will depend, too, on how other distributions respond. Unless the technology to build Snappy packages is released as free code or an alternative is developed, distributions like Debian and Fedora cannot place Snappy in their core repositories without violating their policies on software freedom.
Snappy has grown from a specialized use into a candidate for a universal package system. Yet whether its developers have become too ambitious is uncertain. Earlier efforts like the Linux Standards Base have failed to encourage a universal package system, and Red Hat’s Flatpak could mean that the only result is a repeat of the old division between .rpms and .debs. More than one observed has linked to an xkcd cartoon that suggests the result of making a universal standard is only one more competing standard, and, so far, that seems the likeliest outcome — something as far away from the reporting in the open source media as is possible to imagine.
Photo courtesy of Shutterstock.