Um neue Software zu installieren und installierte Software aktuell zu halten, pflegen Linux-Distributionen eigene Software-Archive, sogenannte Paketquellen. Diese sind sehr umfangreich. So verzeichnet etwa Ubuntu 22.10 per fast 70.000 Pakete. Das heißt nicht, dass Ubuntu 70.000 verschiedene Programme kennt. Viele dieser Pakete sind sogenannte „Abhängigkeiten“, also Bibliotheken und andere Helfer, die von mehreren Programmen oder Diensten wiederverwendet werden. Diese modulare Struktur ist nützlich, aber auch komplex, weshalb die Distributionen darauf achten müssen, alle benötigten Abhängigkeiten in ihren Paketquellen bereitzuhalten. Verantwortlich dafür sind sogenannte „Maintainer“, sozusagen Pflegekräfte für Software.

• Zur Übersicht über Ubuntus klassische Paketquellen.

All das bedeutet viel Aufwand, und die Angelegenheit wird noch aufwändiger: Um die Pakete bereitzustellen, verwenden die Distributionen unterschiedliche Paketformate. Ubuntu nutzt dasselbe Paketformat wie Debian, an der Dateinamenserweiterung .deb zu erkennen. Red Hat und Fedora dagegen nutzen .rpm. Das heißt: Wenn ein Entwickler sein Programm sowohl für Ubuntu als auch für Fedora – um nur zwei gängige Distributionen zu nennen –  bereitstellen möchte, dann muss er oder sie Pakete sowohl für Ubuntu als auch für Red Hat bauen; und weil von Ubuntu mehrere veröffentlichte Versionen zur selben Zeit existieren, auch noch für jede dieser Versionen!

Dieser Aufwand ist der Hauptgrund dafür, dass sich neben dem klassischen, Distributions-abhängigen Ansatz der Paketquellen und -formate zunehmend portable Container-Formate – namentlich Snap, Flatpack und AppImage – etablieren. Sie können auf allen Distributionen installiert werden und bringen ihre Abhängigkeiten selbst im Container mit. Mit anderen Worten: Entwickler müssen ihr Programm nur noch in einer Version bereitstellen, die auf allen Distributionen und deren Veröffentlichungen lauffähig ist. Das macht die Sache für jeden Software-Entwickler einfacher, und auch die Ubuntu-Maintainer machen sich dieses Prinzip zunutze, indem sie die häufig aktualisierten Browser Firefox und Chromium für alle Ubuntu-Versionen als Snaps bereitstellen.

Prinzipiell lassen sich diese Container-Formate durchaus mit der Funktionsweise von Smartphone-Apps aus den Stores von Apple oder Google vergleichen. Die Container ermöglichen es sogar, auf Linux-Desktops ein ähnliches Rechtemanagement pro App (für Zugriffe auf den Standort, auf das Dateisystem etc.) wie auf einem Smartphone einzuführen. Das ist ein Sicherheits-Gewinn.

Es sind aber auch Sicherheits-Einbußen zu beobachten. Denn während beim klassischen Paketmanagement die Maintainer der eigenen Distribution das Paketarchiv beaufsichtigen, wird diese Instanz bei den neuen Container-Formaten umgangen. Prinzipiell kann jeder eine Anwendung als Snap, Flatpak oder Appimage bereitstellen und behaupten, dass sie genau das tut, was sie tun soll, und es liegt bei den Anwendern, ob sie dies prüfen oder einfach glauben.

Weitere Nachteile vom Containern: Anwendungen benötigen mehr Speicherplatz, Anwendungsstarts dauern länger, und um Aktualisierungen muss man sich selbst kümmern, es sei denn, man installiert einen App-Store für das betreffende Container-Format.

App-Stores für Linux

App-Stores aber sind ein heikles Thema. Während Ubuntu den hauseigenen Snap Store bereits vorinstalliert und in die Software-Verwaltung integriert, setzen andere Distributionen eher auf Flatpaks, das vor allem von Red Hat favorisierte Format. Und während Flatpaks prinzipiell aus jeder Quelle installierbar sind, wobei sich Flathub als Quasi-Standard etabliert hat, duldet Ubuntu-Hersteller Canonical nur seinen Snap-Store. Dieser Alleingang hat Ubuntu mal wieder viele Anfeindungen von den üblichen lautstarken Verdächtigen der Linux-Community eingebracht, zumal ein Teil der Snap-Infrastruktur – genauer gesagt das Store-Backend – nicht quelloffen ist. Aber um ehrlich zu sein: Letzteres ist bei Dockerhub oder Github nicht anders.