The adoption of new technology is almost never without hurdles. Usually, it takes a while before users become familiar and comfortable with the new concepts and usage models. Often, having a good understanding of the underlying architecture can help bridge the gap.
In this article, continuing with what we’ve done with Debian and snap file formats, we’d like to take a closer look at the snap and Flatpak ecosystems, both of which are designed to address some of the shortcomings of the classic Linux package management and distribution.
Flatpak at a glance
Since we’ve already discussed the snap layout and architecture in greater details in the previous weeks, let’s start with a quick overview of Flatpak. Much like snaps, Flatpak packages come with necessary components contained inside standalone archives, so they can be deployed and maintained with simplicity on a range of Linux distributions. Runtime and image components are bundled into a single file using the OCI format.
In general, Flatpak applications are built against runtimes, but they can also contain additional libraries inside their own bundles. A Linux system with the Flatpak binary (primary command) installed and configured can then run Flatpak applications. At the moment, there are 21 distributions that offer Flatpak support.
Furthermore, applications are sandboxed using Bubblewrap, which utilises kernel security and namespace features to set up unprivileged containers. Communication outside the sandbox is possible through a mechanism of portals, which allows granular access to system resources.
Flatpak packages are available to end users primarily through Flathub, an app store and build service that is (semi)-officially associated with the Flatpak project. Submissions to Flathub are done as pull requests through GitHub, and require approval from the store admins. Similarly, publishers of proprietary software have to manually request inclusion of their applications. Flatpak applications are also sometimes available as manual download links. There is no automatic update mechanism available by default.
Overall, Flatpak is architected to primarily support GUI desktop applications, whereas snaps are designed to work with server daemons, cloud infrastructure and internet of things (IoT) devices, in addition to desktop applications.
Snaps at a glance
Snaps are packaged as compressed SquashFS files. Typically, snaps include all the assets necessary for an application to run. Since this can increase the size of snap packages, the snap framework uses runtime components called bases (base snaps), which provide a minimal set of libraries common to most applications, and mounted as the root filesystem for applications. Developers (as well as teams) can also use content snaps, which allow them to reuse code and share data with other snaps.
Snap management is done using the snapd service (and snap userspace component). Indeed, if a Linux distribution has snapd support, that system can then run snaps. Currently, that list covers 41 distributions.
From the security perspective, snaps are isolated from the system using a combination of several mechanisms, including AppArmor, SecComp, cgroups, and others. By default, snaps cannot access resources outside their sandbox. Granular access is provided through interfaces.
Snaps come with a robust development and distribution infrastructure, which includes the snapcraft command-line tool as well as online build service, allowing developers to create snaps for six architectures, and push them to the official Snap Store. Companies as well as individuals can create their own accounts and publish their snaps directly, including both open-source and proprietary software. Application discovery comes in multiple vectors, including native integration in the search functionality of traditional Linux frontends like GNOME software and KDE Discover, Snaptastic available in the elementary App Center, through the Snap Store web interface, using the snap command line utility, and other means.
For the end-user, the consumption of snap and Flatpak packages is quite similar. In both cases, the user can search or install software via command-line or graphical frontends. However, there are also some differences, especially using the terminal.
With snaps, the search for applications is pretty straightforward; the Snap Store and command-line results match, and the installation is simply done by invoking the application name against the snap install command.
Flatpak uses a three-part identifier for each application, with the tld.company.application format. For instance, GIMP is identified as org.gimp.GIMP (with snaps, it’s just gimp). This means that search results in software like KDE Discover or Ubuntu Software Center may be different from how it’s displayed on the command line. Furthermore, Flatpak is designed to work with multiple remote sources, one of which is Flathub. Therefore, it is necessary to specify the remote part during the installation, as well, for instance:
flatpak install flathub org.gimp.GIMP
Both formats allow users to install different versions of the available software. This is done using channels in snaps, and branches in Flatpaks. Snaps allow parallel installs of different versions of the same application (as long as they are present in the Snap Store). With Flatpaks, this can be achieved by offering different versions under a separate name, e.g.: Nightly build 3 testing new lib functionality.
Application updates are also handled differently. Snaps come with automatic updates enabled by default, although users can run the snap refresh command to force an update in between periodic checks. It is possible to defer updates but not disable the functionality completely. Flatpaks can be manually updated by running flatpak update on the command-line.
Summary of differences
Here’s a table of major points discussed throughout the article:
|Support||Flatpak support (21 distributions)||Snap-enabled (41 distributions)|
|Architecture||AMD64, AArch64, ARMv7-A, i586||AMD64, ARM64, armhf (ARMv7), i386, ppc64el, S390X|
|App store||Flathub||Snap Store|
|Multiple store support||Y||N|
|Integration in traditional frontends||Y||Y|
|Number of applications (at the time of publication)||679||2,632 (excluding duplicates and test snaps)|
|Anyone can contribute?||Y (with admin vetting)||Y|
There are many similarities in how snaps and Flatpaks address the problems in the Linux application packaging space. In a way, it might be treated as convergent evolution. There are some differences, too, like updates, parallel installations, and the currently supported distributions. Furthermore, snaps are designed to work beyond the classic desktop, including the server and IoT domains, while Flatpaks allow their users to utilize multiple remotes.
The abundance of options can be somewhat overwhelming to the common user, but it also adds another dimension of freedom, allowing people to choose the most suitable technology for their particular needs. In any case, the world of standalone, confined Linux application has only just begun, and we’re bound to see lots of changes and new interesting ideas take place in the coming years. We hope you enjoyed this article, and if you have comments, please join our forum for a discussion.Cloud Server Linux. Contact us to find out our latest offers!