Snaps vs Flatpaks
Mayank Sharma didn’t realise that Linux package management needed a fix… until he ran across projects that are working to reimagine app distribution on Linux.
People demand faster, easier distribution systems; Mayank Sharma checks out the nextgeneration of packaging and asks: is it for us?.
“Mixing repositories can have unexpected consequences on the stability of a system”
Package management is often hailed as the single biggest advancement that Linux has brought to the world of operating systems. But under the hood there’s a murky and convoluted world of official and unofficial repositories, different packaging formats, lots of metadata, and an endless stream of libraries.
A package manager relies on the format of the packages it manages. So for example, DNF (and previously Yum) uses rpm as the backend and extends the functionality of the backend by adding relevant features. The package management systems save time by automating time-consuming tasks such as resolving dependencies. In fact, Fedora’s DNF started out to address several long-standing issues in Yum including dependency resolution and how it handled online repositories.
Repositories introduce another level of confusion. In addition to official ones, most distros also permit the use of custom and third-party repositories to let packagers push newer releases of software than those available in the official repositories. Mixing repositories can have unexpected consequences on the stability of a system.
Sure, you can use tools like Alien to convert between Linux Standard Base (LSB) compliant .rpms and .debs packages. But thanks to the construction of the current packaging systems, you can’t really use Fedora without RPMs or Ubuntu without DEBs. It’s safe to say that while the current packaging scheme works, it does leave many avenues for improvement.
Over the years there have been many efforts to retool the Linux software distribution model to work out the kinks with the existing model. Currently the three that have caught everyone’s fancy are AppImage, Flatpak and Snaps. Let’s put them under the LinuxFormat spotlight to see if they have cracked the code to app delivery on Linux.
For years, Linux users have lived with the duality of DEB packages for Debian- or Ubuntu-based Linux distributions and RPM for Fedora- or SUSEbased Linux distributions. While these packages provide a convenient way of installing software in their respective distributions, the whole system isn’t the most convenient for the application developer. Thanks to the fragmentation aspect, the developers have to create separate packages for multiple distros.
This is something that AppImage attempted to solve back in 2004 (when it was known as klik). AppImage distributes an entire application as a single executable file. The application runs off this package, and doesn’t place files on the base system. In addition, the AppImage file contains all libraries and files it needs to run, and this enables them to work on a large number of distributions.
A typical Linux software will create files at various places, requiring root permission to make these changes to the system. AppImage doesn’t do this. Technically, an AppImage is a ELF file that also contains an embedded squashfs filesystem. All the files that are needed to run the application are stored here. When you run the file, the program embedded in this file mounts the filesystem in a directory under /tmp. It then starts up the application inside this directory.
For security reasons, mounting a file system still needs root permissions. Fortunately, most desktop distributions have FUSE support, which makes it possible to mount file systems without root permissions. This is used by AppImage files to work seamlessly, and this is the only bit of support that they expect from the base system. AppImages are also very portable and can be run anywhere, including on Live environments. AppImage usually installs a desktop file to integrate it with your Linux installation just like a regular installed application, which means that your software will be searchable through your desktop environment.
Costly convenience
Prolific distribution contributor Neal Gompa has experience with all three formats, because he maintains Flatpak in Mageia, Snaps in Fedora and has also assembled AppImages. He believes AppImage has no corporate backing because it’s “fundamentally flawed” and wouldn’t take off unless all Linux distributions agree to provide a base ABI (application binary interface).
“AppImage relies on host libraries to function,” he says. “Ironically, this is actually an ideal case, because it maximises the value of what’s already on your system and in theory makes it easier to do system integration.”
In practice though, bundling libraries leads to incompatibilities that are tricky to debug: “Not to mention, the AppImage founder holds very little regard for security mechanisms and doesn’t have a built-in mechanism for AppImage to be confined. The AppImage toolkit (Appimaged, AppImageKit, etc.) provide various extended functionality at runtime and build-time, respectively, but neither of them make it easy or obvious for validating AppImages before using them,” as Neal explains.
He’s also not sold on the idea of AppImages not having central repositories: “AppStream is functionally useless because AppImages are intended to be downloaded from Joe Rando’s Apps o’ Fun websites that don’t necessarily have to care about integrity. The AppImage founder wants MacOS style “download to run” applications. However, even Apple is moving away from that model now, because it makes it very hard to ensure the integrity of applications and the security of the operating system.”
Flatpak, Neal believes, is a marked improvement over AppImage since integrity and security are baked into the design of Flatpak: “It leverages some Linux kernel features to set up basic confinement (seccomp, for example.).” The one big difference between AppImage and Flatpak is that the latter doesn’t use the host distribution libraries for the applications, and instead relies on runtimes. Neal explains that the runtime is a mini-distribution tailored for
Flatpaks to run on top of. “The default runtimes are based on Yocto,” he says, “but it is possible to build your own runtime on top of a distribution for applications built for that distribution to run on (indeed, Fedora intends to do this).”
Talking about the security model, Neal says that like AppImage, Flatpak also works for unprivileged users: “They can fetch and run applications from Flatpak remotes like FlatHub freely. The remotes require GPG signatures and SHA512 checksums, so untrusted and non-verifiable Flatpaks are difficult to deliver via remotes. That said, users can just download Flatpak bundles and install them to run too, just like AppImage, but this is not the intended default user model. And even then, Flatpak bundles are expected to be signed so that Flatpak can verify them.”
Desktops domain
Despite all their advantages, Flatpak is only intended for desktop GUI applications. “The creators of Flatpak believe that other technologies (Docker, Kubernetes and so on.) should be used for server applications. And there’s a gaping hole for CLI applications”, Neal points out.
In order to be able to address server applications, Neal says, Snap takes what Flatpak does up a notch and leverages AppArmor for confinement. On the downside however, Snap requires significant work on the distribution that’s integrating it to make it work. “Changes to the kernel are required,” he says, “and there’s an entire class of Snaps called classically confined Snaps that require the distribution to install a /snap path that’s either a directory or a symlink to the actual directory configured for the snap mount path.”
Neal points out that to date, the only distributions he knows of that have fully accepted this non-standard path are Ubuntu and Solus. Other distributions like Fedora and Arch don’t ship with this path.
All said and done, however, while building Flatpak is a confusing affair, as a suite of tools it’s clear that Snappy is the easiest to use: “However, today, you can only make Ubuntubased snaps with the official tooling, although there’s work underway to enable other distribution bases, “reveals Neal.
Furthermore, unlike Flatpak, Snappy doesn’t support multiple repositories (or “stores” in snappy parlance). There’s only one Snap store, and it’s run by Canonical. The code doesn’t support easily switching stores, and configuring multiple stores isn’t possible. This means that any user of Snap is effectively tied to Canonical’s store. “This more or less breaks the decentralised model that Free and Open Source software has thrived on in favour of a Apple-like centrally controlled software delivery platform,” says Neal.
Embracing change
Technical comparisons aside, adoption is the true measure of a technology’s success, which is directly linked to the benefits it provides to users and developers. Jeff Hoogland, lead developer of Bodhi Linux believes that the universal package formats are a reasonable idea, at least for end user-facing applications.
“We already see this same type of idea employed in the gaming world via applications like Steam,” says Jeff, “and so making it easier for non-game applications to install or update without depending on the packaging requirements of specific distros is a big step towards getting more mainstream software onto Linux systems.”
Jonathan Thomas, developer of OpenShot concurs: “I feel very strongly for the need of a universal installer on Linux. Most app developers would love to have consistent branding, messaging, and a single flow for installing and updating their apps across all versions of Linux.” The ease of ensuring consistency in installation and updating is one of the main reasons for adopting these universal installers at digiKam: “Each day we provide a build of all bundles for end user to check if bugs have been fixed between stable release. It’s fast and very powerful”, says
digiKam’s lead developer Gilles Caulier. To show the difference between distributing RPM/DEB packages and the universal installers, Gilles notes the project earlier used to receive lots of reports on broken binary compatibility. That’s changed with universal installers: “I know how the application runs and I know what are the right dependencies. There’s no risk of broken binary compatibility with a bundle − all is already inside.”
In fact, when a digiKam user reports a bug with the distribution RPM, the project asks them to check if the problem is reproducible with a universal installer: “And surprise, 50 per cent of the reports are upstream bugs,” says Gilles. “You can imagine the time lost to identify these kind of problems without having a standalone bundle as AppImage to quickly identify a packaging problem.”
Jonathan also uses AppImage for OpenShot. “I chose AppImage primarily because of its wide compatability with different distros, and ease of integration,” he says. “I was also familiar with Krita (which was also using this format), and was even contacted by the creator of AppImage who offered to help.” Gilles has a similar experience with AppImage. He did fiddle around with Flatpak about a year back, but wasn’t impressed with its documentation.
On the other hand, the Solus distribution has employed Flatpak to solve an interesting app delivery issue. In a blog post, lead developer of the project Ikey Doherty wrote that the project, like most Linux distros, distributes the bulk of its software through binary repositories. However, they can’t ship some applications, like GoogleChrome, mostly due to their licensing restrictions. To distribute these apps using Solus’ native package management, the apps were first fetched from the vendor and then turned into Solus’ native .eopkg package format. The system wasn’t robust and provided no mechanism for automatic upgrades. After careful technical deliberation, Ikey went with Flatpak, which he found to be the easiest to integrate into Solus.
No middlemen
Similar reasons were outlined by one of the core KDE developers, Sebastian Kügler, in a blog post earlier last year. Making a case for the three universal packaging formats, Sebastian wrote that currently the project depends on Linux distributors to ship their apps and updates. He argued that this is “problematic” for both distros and application developers because of the delay it causes in pushing updates. Sebastian believes that using the bundled apps/universal packaging formats would solve the problem: “That means we could go as far as shipping apps ourselves and cutting out the distros as middlemen.”
Mageia’s Donald Stuart disagrees with KDE’s position: “Having KDE provide updates so that users can quickly get updates from them could be something worth investigating. However, the QA and packaging teams at Mageia do a very good job of firstly providing updates in a very timely manner; and secondly, ensuring that the updates that are provided are both release stable and work as intended with the rest of the packages included in the distribution.”
Neal finds it odd that KDE considers distributions as middlemen given that many KDE contributions come from the various distributions. He believes the basis for KDE’s argument is the stability-first development model of distributions. Neal says that unlike Mageia, which follows “the LTS only and
update within the LTS series”, distributions like Fedora and OpenSUSE track upstream releases closely and thus are more actively part of KDE development.
“In my opinion, a large amount of KDE’s frustration comes from distributions that don’t regularly keep their stack up to date,” says Neal. “The Debian family, including many derivatives (excluding KDE neon) prefer ‘stability’, which implies they don’t pull in the latest releases that introduce features and fix bugs, which frustrates users of the KDE software on those distributions.”
No size fits all
As long-term Linux users know, there’s more to assembling a distro than bundling apps into repositories. It takes considerable effort in pruning the packages to ensure consistency, compatibility and security. Because this process takes time, many people up and down the Linux app food-chain perceived this as a problem and hailed the universal packaging formats as the solution. We hope we’ve established that while they are useful they aren’t the panacea many imagine them to be. Mageia’s David Hodgins says that the distro isn’t planning on providing universal packaging formats, though the tools needed to produce them are included for anyone who wishes to produce their own. “They’re a solution looking for a problem to solve, that also introduce additional problems with the testing and distribution of updates,” he says.
“If I could have Snaps with the flexibility of Flatpaks, I’d take such a solution,” says Neal. “But today, while I like Snaps as a system more, I don’t think it’s appealing for a lot of people. Instead, I think Flatpak will win out because it’s easy for distributions to integrate and it solves the app delivery problem for graphical applications, which is what most proprietary app vendors make. And unlike Snaps, since everyone can host their own Flatpak remotes, it’s possible to integrate their own method of user subscriptions or payments to grant access to apps.”
On the other hand, Jonathan would love to see the tools improve for these universal installers: “I still dream that one day, app developers will be able to package applications for all platforms (Linux, Mac, and Windows) with a single universal image, and a single repository/app store, and with minimal effort, and provide a simple, user-focused install/update experience. That is my dream.”
Until that future is realised, the different formats will continue to coexist just like the binary package formats have coexisted. Their pace of development and adoption will continue and a number of mainstream programs will soon be available in one of these formats. From where we stand it appears Snaps will continue its strides with the cloud and IoT apps while AppImage and Flatpak will divide the desktop apps between them.
“At the end of the day FOSS is all about user choice,” concludes Jeff, “so these types of installers are just another option for end users to give them the flexibility to use their computer as they see fit.”