To install new software and keep installed software up to date, Linux distributions maintain their own software archives, called respositories or package sources. These are very extensive. Ubuntu 22.10, for example, lists more than 100,000 packages. This does not mean that Ubuntu knows 100,000 different programs. Many of these packages are so-called “dependencies”, i.e. libraries and other helpers that are reused by several programs or services.

• Overview and explanation of Ubuntu’s “classic” repositories.

This modular approach is useful, but also complex, which is why distributions must take care to provide all the dependencies they need in their repositories. Each distribution has experts responsible for curating the software; they are called “maintainers”.

All this means a lot of effort, and the matter becomes even more complex: To provide the packages, the distributions use different package formats. Ubuntu uses the same package format as Debian, recognizable by the .deb file name extension. Red Hat and Fedora, on the other hand, use .rpm. This means that if a developer wants to make his or her program available for both Ubuntu and Fedora – to name just two common distributions – then he or she must build packages for both Ubuntu and Red Hat; and because multiple versions of Ubuntu exist, for each of those versions as well!

Container formats

What, if developers could spare this effort of packaging for different platforms? Well, they can, and that is one reason why portable container formats – namely Snap, Flatpack and AppImage – are increasingly becoming popular alongside the classic, distribution-dependent approach of package sources and formats. They can be installed on all distributions and have their dependencies included in the container. In other words, developers only need to provide one version of their program for all distributions and all releases. This makes things easier for any software developer, and even the Ubuntu maintainers take advantage of this principle by providing the frequently updated browsers Firefox and Chromium as one snap for all supported Ubuntu releases.

In principle, these container formats can certainly be compared to the way smartphone apps from Apple’s or Google’s stores work. The containers even make it possible to introduce a rights management per app (for access to the location, to the file system, etc.) on Linux desktops similar to smartphones. That is a security gain. However, there are also security losses to be observed. While in classic package management the maintainers of one’s trusted distribution oversee the package archive, the new container formats bypass this instance. In principle, anyone can deploy an application as a snap, flatpak or app image and claim that it does exactly what it is supposed to do. It is up to the users whether they check or simply trust this. Other disadvantages of containerizing apps: the installations require more memory, application launches take longer, since unpacking and starting up the app needs more time especially on weaker hardware, and users have to worry about updates themself unless they install an app store for the container format in question.

App stores for Linux

App stores, however, are a tricky subject. While Ubuntu has its own Snap Store already installed and integrated in the Software appliccation, other distributions tend to use Flatpaks, the format favored by Red Hat. And while flatpaks can in principle be installed from any source, with Flathub having established itself as a quasi-standard, Ubuntu manufacturer Canonical only tolerates its Snap Store. This solo effort has once again earned Ubuntu a lot of hostility from the usual vocal suspects of the Linux community, especially since part of the Snap infrastructure – more precisely the store backend – is not open source. But to be honest: the latter is no different with Dockerhub or Github.