Pakete und Anwendungen vom System trennen

Mit dem Aufkommen der Containertechnik, die insbesondere durch Docker populär geworden ist, vollzieht sich ein langsamer, aber stetiger Wechsel innerhalb der Linux-Distributionen und auch der Nutzerschaft in Bezug auf das, was das Betriebssystem an sich eigentlich leisten soll.

In den 90er und 00er Jahren waren die Distributionen noch Sammlungen von detailliert aufeinander abgestimmter Software, die über Tausende voneinander abhängige Pakete ausgeliefert wurden - vom Desktop mit GUI-Software bis hin zum klassischen Lamp-Stack mit Web-Server und Datenbank.

Doch die Serveranwendungen und deren Ausspielen sind immer komplexer geworden. Mehr und größere Teams von Entwicklern kümmern sich um stetig wachsende Flotten von Serveranwendungen, die auch immer schneller ausgeliefert werden sollen. Das Paketsystem der teils über Jahre gepflegten Linux-Distributionen geriet damit schon vor spätestens zehn Jahren an praktische Grenzen.

Containerverwaltungen wie eben Docker sind angetreten, dies zu lösen, indem die eigenen Anwendungen mit ihren Abhängigkeiten gepackt und unabhängig vom darunterliegenden Betriebssystem ausgeführt werden kann. Diese Vorteile entdeckten auch die Entwickler von GUI-Software für Linux und starteten Projekte wie Appimage, Ubuntus Snappy oder auch Flatpak.

Hier ist vor allem das Ziel, dass auch die grafische Software distributionsübergreifend bereitgestellt werden kann, was etwa Anbieter von Drittsoftware entgegenkommen soll, die bisher oft Probleme damit haben, Pakete für Desktop-Linux-Systeme anzubieten. Valve nutzt das auf seinem Gaming-Handheld Steam Deck.

Wendepunkt beim Betriebssystembau

Diese von Anwendungsentwicklern und teils auch Nutzern wohl schlicht wegen der Einfachheit gewählte Technik bringt die Ersteller von Distributionen aber eben unter Zugzwang. Welche Software soll als Paket gepflegt werden und wie lang? Wer übernimmt die Updates? Sind diese nicht besser bei den Entwickler der Software selbst statt den Betriebssystemdistributoren aufgehoben? Endgültige Fragen auf diese Antworten gibt es bisher noch nicht.

Die erwähnten Konzepte der verschiedenen Distributoren zeigen aber, dass an der Beantwortung dieser Fragen gearbeitet wird. Bisher allerdings nicht wirklich distributionsübergreifend. Viel mehr setzen die Beteiligten oft auf interne Lösungen, die meist dynamisch gewachsen sind. Doch das Systemd-Sysupdate könnte genau diesen Wildwuchs wie vieles zuvor schon vereinheitlichen.

Selbst in dem für seine komplexe Entscheidungsfindung berüchtigten Debian-Projekt werden inzwischen nach vielen Diskussionen die Systemd-Werkzeuge vorzugsweise genutzt. Sollten sich die großen Distributionen in Bezug auf die Sysupdate-Komponente ähnlich verhalten, bleibt zu erwarten, dass zumindest die auf die A/B-Updates spezialisierte Varianten diese Technik künftig umsetzen.

Die Paketsysteme wie RPM und DEB mit ihren spezifischen Paketverwaltungen wie APT, Zypper oder DNF würden dann von Werkzeugen, die Nutzer und Administratoren einsetzen, zu Werkzeugen für die Distributoren selbst, um das Basissystem aus Root-Dateisystem und Kernel-Abbild zu erstellen. Wann und vor allem ob dies aber auch im großen Maßstab geschieht, ist derzeit noch völlig ungewiss. Sollten die Experimente mit Systemd-Sysupdate jedoch erfolgreich verlaufen, dürfte die Technik Admins, Nutzern und Distributoren den Umgang mit dem System deutlich erleichtern.