For installating software, Linux has always offered various possibilities. For example, there is always the possibility of manual compilation using the well-known rule of three (configure, make, make install) - including all the advantages and disadvantages. However, the most convenient solution is using the distribution's package manager. This saves the user the annoying translation of source code - but there are also numerous representatives. Besides the usual Red Hat- (yum, dnf) and Debian-like (apt, apt-get) package managers, there are numerous other tools - and this is exactly where the problem lies.

With AppImage, Flatpak and Snap there are three more developments that have made it their business to revolutionize software management under Linux - but how well do they succeed?

In principle, diversity has enriched Linux to a large extent - but not in every area. One area where too much choice quickly becomes a disadvantage is software management. Beginners are confronted with a selection of different package managers, which makes it difficult to get started - but the additional work for developers is probably much more critical.

Linux distributors, such as Red Hat or Ubuntu, act as a kind of middleman. Software projects, such as Firefox or GIMP, provide their source code, which is then translated, tested and finally packaged by the distributors. This additional effort is usually at the expense of up-to-dateness - this means that users do not find the latest versions of their favorite programs in most Linux distributions. This effect is particularly noticeable when using a very restrictive distribution, such as Debian or Red Hat Enterprise Linux. Some projects work closely with distributors to improve package deployment. Nevertheless, it often takes a few patches to integrate packages into a distribution that has been available for some time.

This situation is dissatisfying for both users and developers. On one hand you would like to develop and use software as current as possible, but it also should be stable at the same time - both opposite paradigms which cannot be represented with the status quo necessarily.

The three frameworks mentioned intend to improve the situation by updating and maintaining applications independently of the operating system. The distribution as a middleman is eliminated - developers have complete control over the maintenance of their application for the first time. This sounds tempting, but it also has its pitfalls, which are described below. In some respects, however, all three frameworks mentioned have similar features:

• easy to use
• installing or usage without root permissions
• usable under several Linux distributions

Let's take a look at the tabular comparison:

The first development was AppImage back in 2004. It mounts applications including all dependencies as an image via FUSE. AppImages are simple and do not require any runtime or background services and do not need to be installed - making them ideal for portable applications on USB sticks. Ready-made images can be found on the respective project websites or on AppImageHub - a kind of AppImage app store. Updates are usually packaged in the form of new images, but binary delta updates are also possible. The only drawback is that rights management is currently missing. Thus, executed applications basically have all permissions of the executing user - SELinux can possibly prevent worse here. Other frameworks implement concepts that may already be known from smartphone apps - applications can be denied access to the network, files or specific hardware.

Only three years later, Flatpak followed with another, somewhat more complex, approach. It also provides program bundles including dependencies - but file sizes are reduced here, since the required runtime also provides basic libraries. Applications can - if necessary - supply newer libraries. Applications are executed in a sandbox environment which increases security. There is also a rights management (the XDG Desktop Portals standard has established itself), which restricts installed flatpaks in their permissions. However, this step has to be done afterwards - for example via the program Flatseal, elementary OS even supplies its own tool. It would be nice to be able to see and adjust the required permissions in advance - analogous to the usual app stores of mobile devices. Instead of SquashFS images, Flatpak uses OSTree - this allows deduplication and version control comparable to Git. Alternatively, OCI images can also function as installation media. With Flathub, a dedicated store is available, but custom stores can also be defined, making Flatpak decentralized by definition.

With Snappy, or Snap for short, Canonical offers another solution, which does not only have desktop applications in mind but also server services. A runtime is also necessary here - this time in the form of a background service. This manages applications that are mounted as SquashFS images and executed in sandboxes. There is also rights management here, as well as integration with AppArmor, which is also supported by Ubuntu. Another added value are transactional updates including rollbacks, which significantly streamline and simplify updating of snaps. Both an advantage and a disadvantage is the compression of mounted images. Since the decompression is done at runtime, it slows down the start of the applications noticeably. It is problematic that Canonical again goes its own way here and does not disclose the sources of its Snapcraft store. Content is offered here and automatically scanned for malware - besides open source software, proprietary software like Spotify or Steam can also be found here. Manufacturers can make their content stand out from the masses with public and verified accounts.

SELinux support is currently missing from Snap - an implementation is planned, but it will probably take longer due to deeper dependencies. Another point of criticism is that Snap always automatically looks for updates and installs them on its own. Even if this decision was presumably made in the sense of application security, the update compulsion involuntarily creates parallels to other operating systems - not least because Snapcraft offers applications in different channels. For example, users can subscribe to a specific major version and avoid automatic updates to newer major versions. For packaging applications, Snapcraft suggests the use of Multipass - another exclusive tool for easier provisioning of Ubuntu VMs.

Speed

The following test is intended to clarify to what extent native program packages differ from the three alternative formats in terms of speed. Firefox 94.x was started as an example application in an Ubuntu 21.10 VM with 2 CPUs and 2 GB RAM and tested via BrowserBench.org. VirtualBox 6.1 and an Intel i7-8850H CPU were used on the host side.

All tests were run 3x to calculate a mean value. I am not sure how representative and meaningful the browser benchmarks are, but the startup times and RAM utilization make it clear that native packages still offer the best performance and lowest resource demand. Especially with frequently used software, like a web browser, delays are annoying.

Conclusion

Admittedly, native packages of the distribution are still my first choice. Here you have, in my opinion, the best software quality and best integration into the operating system. With all approaches, I often struggled with divergent UI themes and HiDPI issues.

However, I understand the issues around conflicting timeliness and stability. For some applications, you just want to use newer versions than the distributor allows - but please not for the web browser, which is now used as a client for all needs anyway and therefore has to be used especially often. Among the presented tools I consider Flatpak and AppImage as the most useful solutions. Flatpaks integrate seamlessly into the package management of most Linux distributions and make it easy to use and update the respective program packages. I use AppImages for a few applications and really appreciate its slimness. No runtimes are needed, a simple execution of the image is sufficient - due to the architecture, however, the security leaves much to be desired. However, if you know and check the applications and use SELinux, I think the use is quite justifiable.

I do not consider Canonical's attitude to operate the Snapcraft store proprietary to be justifiable. Allowing a decentralized model would increase acceptance in the community. I would be happy about an option to deactivate compression in order to speed up application launches. Unfortunately, unnecessary delays arise here in everyday life at the moment - it's a mystery to me why the Snap variant of the Firefox browser is installed by default in Ubuntu 21.10. I find it all the more critical that after the release of Ubuntu 22.04 Canonical plans to exclusively offer Snap packages for Firefox.