Distributions

The universal application distribution mechanism?

The announcement from Canonical that its "Snap" application package tools have been ported to a set of other distributions has generated some waves in the technical press. But developers for one distribution, at least, are not uniformly displaying happiness about this move on Canonical's part. Snap might yet succeed in unifying and simplifying application package creation and installation for multiple distributions, but it might also prove to be just another move in the interminable package-format wars.

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.

Comments (66 posted)

Distribution quote of the week

-- Daniel Campbell

-- Przemek Klosowski

-- Stephen Gallagher

-- Philip Newborough (Thanks to Paul Wise)

Comments (none posted)

KDE neon User Edition 5.6 Available now (KDE.News)

The first version of KDE neon, which is a distribution based on Ubuntu 16.04 that is meant to be a stable platform on which to try the latest Plasma desktop, has been released. "KDE neon User Edition 5.6 is based on the latest version of Plasma 5.6 and intends to showcase the latest KDE technology on a stable foundation. It is a continuously updated installable image that can be used not just for exploration and testing but as the main operating system for people enthusiastic about the latest desktop software. It comes with a slim selection of apps, assuming the user's capacity to install her own applications after installation, to avoid cruft and meaningless weight to the ISO. The KDE neon team will now start adding all of KDE's applications to the neon archive. Since the announcement of the project four months ago the team has been working on rolling out our infrastructure, using current best-practice devops technologies. A continuous integration Jenkins system scans the download servers for new releases and automatically fires up computers with Docker instances to build packages. We work in the open and as a KDE project any KDE developer has access to our packaging Git repository and can make fixes, improvements and inspect our work."

Comments (none posted)

Distribution newsletters

• DistroWatch Weekly, Issue 665 (June 13)
• Lunar Linux weekly news (June 10)
• openSUSE news (June 15)
• openSUSE Tumbleweed – Review of the Week (June 10)
• Ubuntu Weekly Newsletter, Issue 469 (June 12)

Comments (none posted)

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

Ars Technica reports that Ubuntu's snapd tool has been ported to other Linux distributions. "To install snap packages on non-Ubuntu distributions, Linux desktop and server users will have to first install the newly cross-platform snapd. This daemon verifies the integrity of snap packages, confines them into their own restricted space, and acts as a launcher. Instructions for creating snaps and installing snapd on a variety of distributions are available at this website. Snapd itself is installed as traditional packages on these other operating systems. That means there's a snapd RPM package for Fedora, for example. It's the same snapd code for every Linux distribution, just packaged differently, and applications packaged as snaps should work on any Linux distro running snapd without needing to be re-packaged." Snapd is available for Arch, Debian, and Fedora. It's also being tested by CentOS, Elementary, Gentoo, Mint, openSUSE, OpenWrt and RHEL.

Comments (102 posted)

Keen: The case against upstream packaging

Arch maintainer Kyle Keen speaks out against direct delivery of software by upstream projects. "Maintainers' greatest power is the ability to outright say 'This is not good enough for our users' and consequently punish an ISV by either patching out the offensive part or in extreme cases removing the software from the repositories. ISVs know this and so don't act out. After 20 years of enforced good behavior this has lead to the idea of ISVs as 'the benevolent upstream developer.' This is why Linux doesn't have spyware, doesn't come with browser toolbars, doesn't bundle limited trials, doesn't nag you to purchase and doesn't pummel you with advertising."

Comments (104 posted)