Triathlon

Distributions offer convenient tools for retrieving programs and other software components. Package managers such as Apt or Yum let you search for, download, and install software in the form of packages.

Classic formats for packages provide one package per piece of software; the package then contains the desired software and some metadata. The latter includes information, such as the name, version, and author of the software, as well as other software dependencies. The package manager parses the metadata and carefully resolves all the dependencies so that installing a package can trigger a number of additional downloads and installations.

As a result, you achieve a state in which the desired program is executable from disk, thanks to meeting the dependencies. Don't forget that installing other software with the same dependencies is far faster now because the required packages are already available. This means that several packages can use the same components (e.g., OpenSSL).

These typical package management systems, however, are specific to a distribution and suffer from various weaknesses (discussed in the next section). For more than a decade, now, developers have looked at the basic principle of a cross-distribution run-time environment for programs and have designed various modern formats that solve some of the problems. Once packaged, the applications run wherever the appropriate environment is available – whether under openSUSE, Ubuntu, or Fedora.

These modern approaches come from different communities or companies and have therefore not necessarily developed in the same direction. To find out which formats might prevail in the future and which are recommended, it is worth taking a look at the three best-known representatives of the genre: Flatpak, Snap, and AppImage.

Old-Timers

The concept of modularity created by RPM, DEB, and other package formats contributed to the triumphant advance of Linux: In most cases, you did not have to search the Internet for a software source (e.g., as for Windows) and check its trustworthiness.

However, the major share of today's widespread formats originated in the mid-1990s, when the demands on workstations and servers were far different from today. It is thus unsurprising that the basic ideas behind these formats have some disadvantages from today's perspective.

By definition, most classic package formats do not let you install different versions of the same software and switch between them, although you can find isolated (thoroughly successful) approaches within the classical mechanisms that are intended to remedy this situation. However, these solutions add additional functions that are not anchored to the format of the packages themselves and therefore require more administration.

The same applies when resolving dependencies. If, say, two web applications on a server require different PHP versions, you will probably experience a conflict during installation. This then forces a decision: Is it worth outsourcing one of the applications or even manually adapting and, if necessary, rebuilding the packages to resolve the dependencies cleanly? Neither approach sounds very tempting, and both require additional time. This is especially true when updates reach the package sources.

The handling of new versions is often a bit inconvenient: If a new version of an installed package is available, the package manager downloads the entire archive once again. Some formats cut this, often unnecessary, overhead by only downloading the delta of the two versions. However, this approach is not widely used and is by no means standard in all distributions.

Especially if you need to manage larger environments, the fact that the classic packages offer hardly any interfaces for external communication has a negative effect. In practice, for systems such as Puppet or Ansible, this means that a package first stores the maintainer's configuration during the install. Afterward, you need to overwrite or at least adapt this so that the updated application runs with the desired parameters.

From a user's point of view, as well as from the software manufacturers' perspective, the classic formats are a bit of a nuisance. Vendors need to build and maintain their software for many different distributions. If you want to support many platforms, you can build for Debian, Ubuntu, CentOS, Red Hat, Fedora, openSUSE, Arch Linux – the list is endless.

In some cases, community maintainers do this work; in other cases, this build process is automated across the distributions' boundaries. Nevertheless, the packager must think of all possible dependencies and peculiarities of the different platforms. Software installation is basically reserved for users with corresponding privileges.

Inventive

There is no shortage of creative ideas to correct the disadvantages of classical package management: Docker container automation [1], for example, follows the principle of a single image of a container including all libraries and other dependencies for the application running in it. The container can therefore be run wherever Docker is installed. However, many users are put off by the complexity of Docker and the effort involved in familiarizing themselves with it, so they prefer not to take advantage of the technology. However, there is a solution one size smaller.

Youngsters

The introduction of the DEB [2] and RPM [3] package formats coincided with the birth of the major distributions Debian and Red Hat. In contrast, the modern Flatpak [4], in particular, appears extremely youthful. Work on the project began in 2007, when Swedish developer Alexander Larsson – at that time still using the bundle format Glick [5] – looked to emulate furniture manufacturer Ikea when it came to packaging. A few years later, the mature xdg-app format emerged; it was finally renamed Flatpak in June 2016 [6]. Larsson himself works for Red Hat and the Fedora project; his development work thus draws on many components that were originally developed at Red Hat.

Snap [7], on the other hand, was written by Ubuntu manufacturer Canonical. It is a further development of the .click package format, which was used on the Ubuntu Phone in 2013. In the following year, the company continued the principle of apps under the name Snappy on the Internet of Things (IoT) platform Ubuntu Core, until Snap finally made its way onto the desktop version of the system with Ubuntu 16.04. In June 2016, Canonical decided to open the format for other distributions and purposes.

AppImage's history goes back to 2004, when developer Simon Peter developed klik. At that time, users could use the browser and special URLs beginning with klik:// to obtain recipes that generated a local executable file for the program. This gave Peter a certain degree of independence from platforms because the system did not deliver the executables from the beginning. New versions of klik never exceeded beta status, which is why Simon Peter released PortableLinuxApps in 2011, a successor that works differently. The project matured and was given the new name AppImage in 2013.

Table 1 compares some of the properties of Flatpak, Snap, and AppImage.

Design and Security

RPM and DEB packages store content in the filesystem with root privileges after installation. It is then up to you or an init system to execute the new program with the desired rights. Without additional user intervention, the application runs in the same namespace as the kernel and all other processes. Isolation from the rest of the environment only occurs if you take care of this yourself with tools such as chroot [8], SELinux [9], or AppArmor [10].

Flatpak's structure, on the other hand, allows a completely different approach. Packages are primarily aimed at desktop use and require a run-time environment. It provides basic content for an application's operation and takes up little space on the hard disk (~150-300MB). A list of existing environments can be found on the project's website [11].

A developer must build each package against one of these run times. It then runs wherever the run-time environment in question is installed. During the installation, the system detects whether the required run time already exists and follows it up if necessary. A system can contain several run-time environments in different variants, which enables applications bundled with Flatpak to be kept in different versions. If a program requires additional dependencies beyond the run time, these are included in the package.

The installation of both the run time and the application requires root privileges. However, because a Flatpak package runs in its own, isolated environment, you can launch the included program without extended privileges.

Flatpak uses various well-known technologies in the background, which are also used in the container environment. Bubblewrap [12], for example, ensures that the software runs in its own namespace [13] in the context of the current user. This means that it only sees itself and the required run-time environment.

Techniques such as cgroups [14] strictly regulate access to files, the network, the graphical user interface (GUI), and various subsystems. Using predefined interfaces from the portal APIs [15], an application running in the sandbox can access resources on the host if required (Figure 1). This approach is what prompts people to refer to Flatpak as the "desktop container."

Snaps works in a similar way. The software bundles require the minimal operating system Ubuntu Core, which you store on the local system using classic Debian packages (Figure 2). The environment contains slightly more than 80MB of basic components. As soon as you install the first snap, the system automatically retrieves the missing parts.

Because Ubuntu Core comes from official sources and is trusted by the system, it runs this run-time environment in the normal namespace. The applications themselves, on the other hand, run in a closed namespace, and the use of resources is limited by cgroups.

Users install the snaps with sudo or root privileges, whereas running the software itself does not require extended rights. The Snap package format is equally suitable for systems with and without a GUI.

AppImage differs in some features from its rivals Snap and Flatpak. A package is a compressed image file that you download and run without extended privileges (Figure 3). Each image contains all dependencies for the respective software.

If you use such a package, the system temporarily mounts the image in the package as read only and starts the application packaged therein, with no installation as for RPM and DEB packages. By default, applications from AppImage packages are not isolated from the rest of the system. If you want to use a sandboxing method [18], you need optional additional programs. You will find instructions on GitHub [19].

Some developers behind the AppImage project have also launched the appimaged [20] daemon, which scans certain user directories for AppImage files, registers them with the system if so desired, and executes images in a sandbox if required. The typical target group for programs in the AppImage format are users who run their systems in a GUI.

Independent of Distribution

Flatpak was designed from the beginning to work on popular distributions like Arch Linux, CentOS, Debian, Fedora, openSUSE, Red Hat, and Ubuntu. Originally, it was intended that users would search the Internet for software sources themselves.

One source is provided by the flatpakref file in a classic format; it contains various information about the package, such as a URL to the content. Flatpak's package management then uses this file to download and set up the corresponding package.

In the meantime, however, developers have enhanced the tools for managing packages with the option of adding remotes or repositories, which you can then browse. Retrieving a package then works in the usual way: First run the corresponding command to search for a program, and install it with the package manager (Figure 4).

Once installed, it is possible to list, update, and remove Flatpaks. You can also launch an application using the appropriate tools. Both individual websites (e.g., from software vendors) and repositories such as Flathub [21] serve as software sources.

The Snap package format and the associated Snappy manager originally focused on Ubuntu as a platform. The long-term goal was to replace DEB packages, as well as Apt and Aptitude. In June 2016, developers ported the package manager and format to further Linux distributions [22]. Since then, Arch Linux, CentOS, Debian, Fedora, Gentoo, openSUSE, and Red Hat have the ability to use Snap packages.

On each distribution, Snappy can read the metadata of Snap packages and implement certain rules depending on the distribution (e.g., in the security sector). For this reason, such a system does not necessarily need to include AppArmor for applications to launch from packages.

The Snap tools interact with the snapd daemon, which you use to retrieve packages from official sources or stores. Canonical's official source for snaps is the Ubuntu Store (for an unofficial source, visit uApp Explorer [23]). If you log in to the store with the package manager, you can install packages without sudo or root rights.

If you can retrieve packages with the .snap file extension by other means, you can install them from the local filesystem. Snappy supports a variety of actions for packages, including the usual suspects such as install, search, update, list, and remove. Snaps store commands on the local system that let you access the freshly installed application directly (Figure 5).

Unlike RPM, DEB, or Snap, for a long time, AppImage did not have a classical package manager to let users search for and install software. Instead, you obtained a package from the vendor's website or some other provider. That was the inventor's idea: On the project's website, you can read that the package format aims to obtain software directly from the vendor and not from repositories that inevitably offer outdated versions at some point. However, the project itself is eroding this concept: On the GitHub page, you will find at least one list of prebuilt images [24].

Once downloaded, you can move the file to the desired location and run it like any other application. Neither downloading the packages nor executing them requires special privileges.

As mentioned above, appimaged has become an optional tool that will be developed in the long term toward package management. Until the software is mature and officially integrated, most users will probably rely on the browser to retrieve applications. However, users have no way to update or list already downloaded AppImage packages – these tasks are entirely up to you.

AppImage supports all major distributions, including Arch Linux, CentOS, Debian, Fedora, openSUSE, Red Hat, and Ubuntu. You call programs packed by AppImage directly (Figure 6).

Acceptance

The degree of dissemination of the three modern formats is difficult to estimate, because there are no official figures and statistics from the respective projects. In addition to RPM and DEB packages, many software manufacturers now offer downloads as a Flatpak, Snap, or AppImage on their own websites, because forum users (on GitHub in particular) are increasingly asking for them.

The few repositories that exist (if at all) for the new packages contain only a few hundred – in one case, well over a thousand packages. If you want to manage a desktop or server system exclusively with new formats, you are at a disadvantage at the moment: The frequently used programs are usually only available in the previously known package formats. Canonical does offer the Snapcraft tool for creating snap bundles from existing Debian packages. You can create packages directly on the website.

If you also want to upload software in snap format to the central source for snap packages, the Ubuntu Store, you must first sign a contributor license agreement with Canonical. Because such agreements usually act as a deterrent to developers from the open source community, many do not make an entry in the official directory or avoid the format altogether.

Flatpak and AppImage also offer tools for creating packages. Unlike Snap, they do not provide an official converter for RPM or DEB packages, because the classic formats usually contain specific instructions for the distributions, which are difficult, if not impossible, to translate into cross-platform procedures.

If you want to upload your Flatpak package to one of the few existing repositories, you do not usually need to keep any special features in mind. After all, AppImage file creators can add their package to unofficial lists that circulate on the Internet and form a kind of image file yellow pages.

Light and Dark

The modern competitors of RPM and DEB do many things right: The user is no longer threatened with "Dependency Hell," in which packages have such nested dependencies that some of them can no longer be resolved at all. Flatpak, Snap, and AppImage usually provide everything you need to run the software in a single bundle. Even the installation and execution are partly done without root rights.

Nevertheless, the modern formats set the bar high when it comes to security: Flatpak and snap packages are isolated from the rest of the system in a sandbox; AppImage at least offers optional functions with the same effect. If you like, you can also install different versions of the same software on your system and sometimes even run them simultaneously – a dream for every system administrator, because this makes it easy to switch between old and new program versions.

As a rule, the formats offer sufficient options for triggering rollbacks and performing delta updates, for which the system only downloads the differences from the older version when updating under Flatpak, Snap, and AppImage. Unlike RPM and DEB, modern formats provide this feature by default, but it requires the package creator to take advantage of it.

The greatest advantage of the new formats is certainly the fact that they work across distribution boundaries. Whether you are using Debian, Ubuntu, openSUSE, CentOS, or any other platform, the application will run everywhere, as long as you take it along as a file and copy it to other target systems, eliminating the need to manage software differently under different distributions. If you want to use the new formats' central software management, it does not take much effort to build and use your own central component.

However, because Flatpak, Snap, and AppImage cram almost all dependencies into the package, the files created are quite large – up to four times larger than a package in one of the classic formats. Although space on mass storage no longer costs the world, this can be a worry. It is quite possible the 20 AppImage files that you download will add the same or similar dependencies 20 times, creating redundancy about which you can do nothing. Downloading applications naturally also takes longer – this can be annoying if, for example, you are experiencing a slow transfer rate.

The classic formats' great strength lies in the central repositories that are usually (but not only) maintained by the distributions. A package manager exists for users, via which you can obtain all packages. Only occasionally do you have to search the Internet for other sources. Flatpak, Snap, and AppImage do not genuinely offer this luxury: If there is such a thing as a central package repository at all, it only consists of a few applications, which are probably of even less interest for your own needs. Optimally, software vendors offer packages in the new formats directly for download.

The classic software repositories have a specific purpose in distributions: Community members, aka package maintainers, ensure that open source software is packaged in accordance with strict specifications, thus complying with certain standards. At the same time, a kind of security check takes place in which the community puts a piece of software and its installation under the microscope.

If manufacturers now offer software directly on their websites, this intermediate step is omitted, with both positive and negative effects. This process works well for those users who want to retrieve new software versions as quickly as possible, while continuing to rely on an LTS distribution, because a maintainer does not need to rebuild the package, and the new formats leave the rest of the system virtually untouched. However, if you are hoping that third parties have taken a look at the Flatpak, Snap, or AppImage beforehand, don't get your hopes up too high.

The situation is different if you use Snap and only use the Ubuntu Store as the official reference point. The developers check the packages there to a certain extent and release them explicitly. In addition, signing an agreement gives the package owner some responsibility.

The new, modern formats provide little or no interaction with automation tools. For example, anyone who wants to roll out AppImage applications on their systems and subsequently configure them individually will probably have a hard time the first time around. Flatpak and Snap also makes it difficult for you to change the configuration afterwards because applications start in a sandbox. However, since interaction with automation tools for classic packages is also rather cumbersome, it would be unfair to say that modern formats alone have this disadvantage.

Conclusions

RPM and DEB versus Flatpak, Snap, and AppImage: Who does the future belong to? The modern formats solve many, sometimes old problems and turn the world of software on its head. However, the community has been quite hesitant to accept these modern formats: RPMs, DEBs, and other classic formats can be obtained too conveniently from huge repositories. One thing is already clear, though: The way Linux systems manage and roll out software has already changed fundamentally, thanks to Docker.

Therefore, it is quite possible that the new formats will prevail in some way with their sandbox and all-inclusive approach. If you want to change now, it is probably best to run with Flatpak: It isolates the rest of the system from the beginning, and repositories to a certain extent allow the central purchase of software.

Incidentally, the community for some time now has called for any software to run by default or even exclusively in its own environment (i.e., in a container). It remains to be seen what the concrete technical implementation might look like. Quite possibly, Docker will end up on all Linux systems, for example, or one of the new standards will prevail.