Flatpak, Snap, and AppImage

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.

Infos

  1. Docker: https://www.docker.com
  2. DEB: https://en.wikipedia.org/wiki/Deb_(file_format)
  3. RPM: https://en.wikipedia.org/wiki/Rpm_(software)
  4. Flatpak: https://flatpak.org
  5. Glick: https://blogs.gnome.org/alexl/2007/08/21/glick-01-released
  6. History of Flatpak: https://github.com/flatpak/flatpak/wiki/Flatpak%27s-History
  7. Ubuntu Store Snapcraft: https://snapcraft.io
  8. chroot: https://en.wikipedia.org/wiki/Chroot
  9. SELinux: https://en.wikipedia.org/wiki/Security-Enhanced_Linux
  10. AppArmor: https://en.wikipedia.org/wiki/AppArmor
  11. Flatpak run times: https://flatpak.org/runtimes.html
  12. bubblewrap: https://github.com/projectatomic/bubblewrap
  13. Namespaces in the kernel: https://lwn.net/Articles/532593
  14. cgroups: https://en.wikipedia.org/wiki/Cgroups
  15. Portals: https://github.com/flatpak/flatpak/wiki/Portals
  16. Introduction to Flatpak: http://flatpak-testing.readthedocs.io/en/latest/introduction.html
  17. "Ubuntu Core – A Snappy Platform for Embedded, IoT and 96boards" (see slide 31): https://www.slideshare.net/linaroorg/bkk16406-ubuntu-core-a-snappy-platform-for-embedded-iot-and-96boards
  18. Sandboxing under AppImage: https://github.com/AppImage/AppImageKit/issues/152
  19. Alternatives to sandboxing under AppImage: https://github.com/AppImage/AppImageKit/tree/master/sandbox
  20. Discussion about appimaged: https://discourse.appimage.org/t/new-appimaged-optional-daemon-that-registers-appimages-with-the-system/87
  21. Flathub: https://flathub.org/apps.html
  22. Snappy: https://en.wikipedia.org/wiki/Snappy_(package_manager)
  23. Unofficial browser for Snapcraft: https://uappexplorer.com/snaps
  24. AppImage app directory: https://appimage.github.io/apps

The Author

Valentin Höbel works as senior IT consultant for open*i GmbH in Stuttgart, Germany. In his free time, you are likely to find him playing table soccer, checking out the latest open source technologies, or twittering as @xenuser .

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs



Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>
	</a>

<hr>		    
			</div>
		    		</div>

		<div class=