Triathlon

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.