Nach Teil 1 zu Themen wie Baukasten, Modularität und Trennung von Technik und Oberfläche, geht es in diesem Teil um die Frage, wie Programme unter Linux verwaltet werden.

Zentrale Softwareverwaltung

Unter Windows und macOS bedeutete „ein Programm installieren“ früher meist: Ich gehe auf eine Website und lade mir einen Installer herunter und klicke das Setup durch, um die Software zu installieren. Updates wurden dann durch die Software selbst organisiert oder indem ich einen neueren Installer nutze. Programme sind hier also eher Einzelstücke, die dem System „angeheftet“ werden.

Auf Linux galt und gilt historisch bis heute immer schon ein anderes Prinzip: Die Programme sind Teil des Systems und werden über eine zentrale Softwareverwaltung ergänzt oder entfernt. Das wird auch Paketmanagement genannt. Über den Paketmanager werden nicht nur Programm installiert und deinstalliert, auch die Updates werden darüber verwaltet. Auch die Installation von „Abhängigkeiten“, also anderen Programmen oder Bibliotheken, die für das Ausführen eines Programms wichtig sind, wird über den Paketmanager organisiert. Sprich – Programme werden eher als Bausteine eines System verstanden.

In typischer Linux-Manier nutzen unterschiedliche Distributionen unterschiedliche Paketmanager – je nachdem was am besten zum jeweiligen Distro-Konzept passt: Auf Debian basierende Distros wie Ubuntu oder Linux Mint nutzen apt, Fedora nutzt dnf, Arch nutzt Pacman.

Stabilität versus Aktualität

Dieses Prinzip hat Vor- und Nachteile. Eine Distribution wie Debian läuft sehr stabil, da alle Softwarepakete aufeinander und auf das System abgestimmt sind und gut miteinander funktionieren. Zudem ist es sehr einfach, Software vergleichsweise schnell und einfach zu installieren. Wenn ich beispielsweise auf einem Zweitrechner die gleiche Software haben möchte, wie auf meinem Erstrechner, reicht ein Befehl in der Kommandozeile und – schwupp – wird alles installiert. Gerade wenn man Server betreut, hat dieses Prinzip natürlich enorme Vorteile.

Was sind die Nachteile? Nunja, wenn ich eine Software für Linux bereitstellen möchte, muss ich einige unterschiedliche Paketstandards bedienen und die jeweiligen Abhängigkeiten im Blick haben – das ist mit Aufwand verbunden.

Außerdem entwickelt sich Software oft schneller weiter als die Distributionen. Wenn eine neue Version von Linux Mint erscheint, bildet sie einen quasi festgefrorenen Stand der Softwarepakete ab, der zum Zeitpunkt der Veröffentlichung streng genommen schon wieder veraltet ist. Wenn beispielsweise Firefox in neuer Version erscheint, muss man ggf. mehrere Monate warten, bis eine neue Version der Distribution erscheint, die dann erst die neue Version des Browsers beinhalten kann.

Repositories und Rolling Releases

Um dieses Problem zu umgehen, gibt es bei Linux verschiedene Lösungen: Beispielsweise können zusätzliche Softwarequellen oder -repositories dazugeschaltet werden, die neuere Softwareversionen oder zusätzliche Programme anbieten.

Oder Distributionen setzen direkt auf ein Rolling Release Modell, wie zum Beispiel Arch. Dann gibt es keine festen Release-Snapshots mehr, die Distro ist quasi laufend im Update-Modus, neue Software-Versionen werden schnell bereitgestellt – was natürlich auf Kosten der Stabilität gehen kann.

Flatpak, Snaps und AppImages

Und dann gibt es da noch eine Entwicklung, die noch relativ jung ist und in den 2010er-Jahren aufkam. Es entstanden mehrere Konzepte, die alle – auf unterschiedliche Weise – Software unabhängig von Distributionen bereitstellen: Flatpaks, Snaps und AppImages. Großer Vorteil: Sie funktionieren unabhängig von den Paketmanagern der Distributionen, indem sie die benötigten Abhängigkeiten einfach quasi als abgeschlossene Sandbox selbst mitbringen. Das macht sie im Handling für Entwickler:innen einfacher, App und System laufen unabhängig voneinander.

Ein Kritikpunkt daran ist, dass die Pakete in der Regel größer sind, da sie noch zusätzliche Abhängigkeiten enthalten. Und für Nutzer:innen kann es auch zu Verwirrung führen. Ich kann die gleiche Software zum Beispiel über den Distro-Paketmanager installieren oder als Flatpak.

Lustigerweise schließen wir damit auch wieder den Bogen zu Windows und macOS. Ein Flatpak zu installieren kann sich dann doch wieder recht ähnlich anfühlen wie die Installation einer .exe. Gleichzeitig haben sich macOS und Windows über ihre AppStores wiederum der zentralen Programmverwaltung angenähert.