Fedora steht für Innovationen. Die in den letzten Jahren in Red Hats Hexenküche entstandenen Neuerungen dienen als Mosaiksteine für grundsätzlich neu zusammengestellte Distributionen.

Seit vielen Jahren entsteht der Großteil der Linux-Distributionen nach einem erprobten Schema auf Basis des Filesystem Hierarchy Standards [1] oder kurz FHS (Abbildung 1). Zudem bildete sich ein System heraus, bei dem Paketbetreuer in den Distributionen die meist aus dritter Hand stammende Software von den Entwicklern (dem sogenannten Upstream) als Quellcode übernehmen und nach den Vorgaben der jeweiligen Distribution paketieren. Das bedeutet beispielsweise, dass einige Distributionen die Telemetrie von Firefox bei der Auslieferung abschalten, andere wiederum nicht, da solche Entscheidungen den Konventionen der Distribution und dem Paketbetreuer obliegen.

Abbildung 1: Der Dateibaum von Fedora 35 entspricht in etwa dem FHS, abgesehen vom Usrmerge, das aber lediglich einigen alten Ballast entfernt, ohne weiter an der Struktur zu rütteln.

Diese beiden Säulen der Zusammenstellung und Pflege einer Distribution erkennen aber seit jeher nicht alle Distributoren als Grundfeste an. Systeme wie NixOS, GoboLinux oder Bedrock Linux setzen sich schon seit vielen Jahren über FHS hinweg und verteilen Anwendungen, Bibliotheken und Konfiguration nach anderen Kriterien. Diese Distributionen bilden aber die Ausnahme und besetzen mit ihren Konzepten bisher lediglich eine Nische.

Im Fluss

In letzter Zeit sägen wieder einige Distributionen am gewachsenen Gerüst der Auslieferung von Software gemäß den jeweiligen Paketformaten wie DEB oder RPM und streben ein universelleres Format an. Entsprechende Vorstöße kommen primär aus der Ecke von Red Hat und von Fedora als deren Hexenküche. Sie finden Niederschlag in Distributionen wie den Fedora-Varianten CoreOS, Silverblue, Kinoite und IoT, bei OpenSuses MicroOS sowie in Endless OS und rlxOS. Auch Systemd 249 bringt Funktionen mit, die unveränderliche Systeme unterstützen (Abbildung 2).

Abbildung 2: Wie sich unschwer erkennen lässt, weicht der Dateibaum von Fedora Silverblue an einigen Stellen vom FHS ab, etwa beim Home-Ordner, einem Symlink auf /var/home/.

Kürzlich verfasste Christian Schaller, seines Zeichens Red Hat Senior Manager für den Desktop, bei Fedora ein Essay unter dem Titel “Fedora Workstation: Our Vision for Linux Desktop” [2]. In diesem Traktat skizziert er die zukünftig angestrebte Ausgestaltung von Fedora Workstation. Darin findet sich nichts revolutionär Neues: Schaller fügt lediglich Mosaiksteine zusammen, die gemeinsam ein Bild davon ergeben, was den Strategen und Entwicklern für die Zukunft der Hauptausgabe von Fedora (und damit mit Verzögerung auch für Red Hat) vorschwebt.

Als Hauptzutaten benennt Schaller neben dem sich bereits verbreitenden Wayland das alternative Paketsystem Flatpak, das Baugerüst von Fedora Silverblue, Pipewire und Toolbox. Alle diese Zutaten entstanden in den letzten Jahren im Umfeld von Fedora und der Gnome-Community. Sehen wir uns die Komponenten und deren Rolle bei der Umsetzung des geplanten Konzepts von Fedora Workstation im Einzelnen an.

Silverblue als Blaupause

Dass Konzepte wie Fedora Silverblue oder Kinoite eine Blaupause der künftigen Fedora Workstation darstellen, gilt schon seit Längerem als gesetzt. Mit der bei Weitem innovativsten Distributionsschmiede Fedora Project (wie sich die Organisation neuerdings offiziell nennt) im Rücken hat Red Hat auch den Rückhalt, neue Konzepte durchsetzungsfähig zur Reife zu führen. Ein Beispiel dafür liefert Systemd, das trotz heftigem Widerstand einer lautstarken Minderheit von Traditionalisten heute fast überall als Standard gilt. Das lässt vermuten, dass auch die Vision, die Schaller in seinem Essay skizziert, in einigen Jahren diesen Weg nehmen könnte. Allerdings spalten bereits jetzt die Zutaten der neuen Distributionswelt die Communities.

Das Konzept von Fedora Silverblue soll vor allem dafür sorgen, System-Upgrades sicherer als bisher zu gestalten. Bislang finden Upgrades im laufenden System statt, beim Neustart führen Fehler zuweilen zu einem nicht startenden oder inkonsistenten System. Die Hauptzutat des neuen Paradigmas bildet RPM-OSTree [3], ein hybrides System zur Handhabung von sowohl Systemabbildern als auch einzelnen Paketen, das auf OSTree [4] (neuerdings Libostree genannt) aufbaut.

OSTree entstand, um atomare Upgrades und deren Rollback zu unterstützen. Es stellt damit eine der wichtigsten Eigenschaften von Silverblue und ähnlich aufgebauten Betriebssystemen dar. Diese Systeme nennen sich “immutable”, was deren unveränderliche Struktur beschreibt. Ein solches System hängt das Root-Dateisystem – abgesehen von /var (Abbildung 3) – schreibgeschützt ein. In dieser Hinsicht gleicht das Prinzip in etwa dem von Live-CDs mit Persistenz. Diese speichern während der Live-Sitzung erstellte Daten mittels Konzepten wie UnionFS oder OverlayFS, die mehrere Dateisysteme übereinanderlegen, in persistenter Form.

Abbildung 3: Alles in Silverblue nicht Schreibgeschützte speichert das System unter /var. Es gibt keinen technischen Grund für die Wahl dieses Verzeichnisses, es handelt sich um eine reine Design-Entscheidung.

OSTree plus RPM

RPM-OSTree erweitert das Konzept von OSTree, indem es über dem nur lesbaren Root-Dateisystem eine zweite Ebene einzieht, die im Fall von Silverblue alle Änderungen am System aufnimmt und neben den vorinstallierten Flatpaks darüber hinaus auch die Installation von RPM-Paketen aus den Archiven erlaubt.

Das bedeutet auch, dass diese Funktion es dem Anwender erlaubt, jederzeit zum reinen Basissystem zurückzukehren, wie es direkt nach der Installation vorliegt. Nichts davon ist wirklich neu; Fedora-Entwickler schlugen die Aufnahme von RPM-OSTree bereits 2015 für Fedora 22 vor. Damals fehlten aber noch zu viele ergänzende Bausteine für einen sinnvollen Einsatz. Davor fand das Konzept bereits in Red Hats Container-Betriebssystem Atomic Host Verwendung [5]. Bei Silverblue handelt es sich um den Nachfolger von Fedoras Variante Atomic Workstation.

Nehmen Sie in Silverblue mit RPM-OSTree ein System-Update vor (Abbildung 4) oder installieren darauf ein RPM-Paket, erstellt das System anschließend ein neues Image, das die Änderungen enthält. Darin leiten Sie via systemctl reboot einen Neustart ein. Falls etwas im neuen Image nicht wie gedacht funktioniert, kehren Sie mit rpm-ostree rollback zum Stand vor dem Update zurück. Wenn Sie mit rpm-ostree install ein RPM-Paket installieren, steht es ebenfalls erst nach einem Neustart zur Verfügung, da das Paket einem neuen Image hinzugefügt wurde (Abbildung 5).

Abbildung 4: Bei Silverblue aktualisieren Sie das System mit rpm-ostree update; es bedarf hinterher eines Neustarts.

Abbildung 5: Auch nach der Installation eines RPM-Pakets müssen Sie das System neu starten, um die Anwendung zu nutzen: Silverblue erstellt auch in diesem Fall ein komplettes Systemimage mit dem neuen Paket.

Flatpak

Für Anwendungen mit grafischer Benutzeroberfläche empfiehlt sich bei Silverblue der Einsatz von Flatpaks (Abbildung 6). In diesem Format angebotene Anwendungen laufen gleichermaßen auf fast allen Distributionen, unabhängig davon, was für ein Paketsystem diese sonst nutzen. Flatpaks starten die darin verpackten Anwendungen in Sandboxen. Das ermöglicht dem Anwender, etwa über die Anwendung Flatseal [6] die Berechtigungen des Pakets gegenüber anderen Flatpaks oder den Systemressourcen fein abgestuft zu steuern.

Abbildung 6: Das standardmäßig in einer Wayland-Sitzung laufende Silverblue bringt nur ganz wenige vorinstallierte Pakete mit, alle im Paketformat Flatpak. Das bestehende Softwareangebot lässt sich sowohl per Flatpak als auch aus dem Fedora-RPM-Archiv ergänzen.

Da Fedora sich auch an Entwickler und fortgeschrittene User richtet, kommt Flatpak besonders dieser Klientel entgegen, denn für sie bedeutet es einen erheblichen Aufwand, mit den Limitierungen herkömmlicher Paketsysteme umzugehen. Die verschiedenen Paketformate erhöhen den Aufwand für Entwickler, Software auf verschiedenen Systemen zu testen. Zudem gestaltet es sich teilweise schwierig, zwei Versionen einer Software gleichzeitig zu nutzen.

Aus diesen Limitierungen folgt die Erkenntnis, dass man ein System braucht, das es erlaubt, die Anwendungen vom Host-Betriebssystem zu entkoppeln. Das erlaubt es den Anwendungsentwicklern, ihre Plattform im Tempo ihrer Wahl zu aktualisieren und gleichzeitig so zu vereinheitlichen, dass ihre Programme ohne Probleme auf den neuesten Fedora-Versionen, den neuesten RHEL-Versionen oder den neuesten Versionen möglichst jeder anderen Distribution laufen.

Eines der größten Probleme mit Flatpak und ähnlichen Paketsystemen besteht für Teile der Linux-Community im absehbaren Wegfall der Paketbetreuer in den Distributionen, die die Konventionen der Distribution umsetzen und als Ansprechpartner für Entwickler und Endanwender dienen.

Toolbox

Grafische Anwendungen installiert Silverblue entweder als Flatpak oder transparent in der übergeordneten Ebene als RPM. Für die sogenannte Toolchain, also die nicht nur von Entwicklern benötigten, über das Terminal benutzten Werkzeuge, ließ sich Fedora die Anwendung Toolbox einfallen (Abbildung 7). Sie erstellt einen eigenen Container, in der sich benötigte Werkzeuge ohne Root-Rechte installieren lassen. Möglich macht dies Podman [7], Fedoras Docker-Alternative.

Abbildung 7: Mit Toolbox erstellen Sie beliebig viele Container, in die Sie dann die benötigten Werkzeuge installieren. Diese Container sind “mutable”, während das System als Ganzes “immutable” bleibt. Benötigen Sie einen Container nicht mehr, löschen Sie ihn einfach.

Wayland

In dieselbe Kerbe schlägt Wayland, der immer weitere Verbreitung findende Nachfolger des in die Jahre gekommenen X.org. Beim klassischen X Window System fiel das Hinzufügen neuer Funktionen in den letzten Jahren immer schwerer. Die Entwicklung von Wayland begann bei Red Hat, dann nahm es der Entwickler Kristian Høgsberg mit zu seinem neuen Arbeitgeber Intel. Schnell wurde jedoch klar, dass es für diese Mammutaufgabe mehr Kräfte zu bündeln galt. Daher stellte Red Hat weitere Entwickler dafür ab, ebenso andere Unternehmen wie Collabora.

Wayland weicht vom Client-Server-Prinzip von X.org ab und verspricht damit mehr Sicherheit für den Grafik-Stack. Andererseits sorgte die dadurch fehlende Netzwerktransparenz durch die Abkehr von dessen dualem Prinzip auch für größere Probleme, wenn es etwa um Screenshots oder das Recording und Sharing von Bildschirminhalten unter Wayland ging [8].

Pipewire

Hier kommt das neue Multimedia-Framework Pipewire [9] ins Spiel, das Fedora seit Version 34 als Standard zum Verarbeiten von Audiosignalen verwendet; die Handhabung von Videos soll bald folgen. Das benötigte Pipewire-API für Screen-Recording, -Sharing und Remote-Desktops unter Wayland wurde kürzlich in das Paket xdg-desktop-portal eingefügt [10].

Diese API erlaubt es Anwendungen, nun auf den Bildschirminhalt in Wayland-Sitzungen oder in Sandboxen (wie bei Flatpak) zuzugreifen. Wim Taymans, Mitentwickler von Gstreamer, konzipierte und realisierte Pipewire für die Verwendung unter Wayland – und somit zukunftssicher.

Zudem vereint das Framework im Consumer-Audio-Bereich die Bedürfnisse von Pulseaudio-Anwendern mit der professionellen Verarbeitung von Audiosignalen, die bisher JACK [11] übernahm. Pipewire bietet genügend Potenzial, um in den nächsten Jahren zu einem Standard zu avancieren, der mit der gemeinsamen Handhabung von Audio und Video vieles vereinfacht.

Fazit und Ausblick

Nach Schallers Meinung ist damit der Grundstein gelegt, um Distributionen – allen voran Fedora Workstation – künftig einfacher zu bauen, zu administrieren und gleichzeitig sicherer zu machen. Die Innovationen von Silverblue sollen nicht nur in Fedora Workstation einfließen, sondern später auch in Red Hats Unternehmensdistribution RHEL. Wie bei allem Neuen regt sich Widerstand, geschuldet dem menschlichen Urinstinkt, beim Gewohnten bleiben zu wollen, was in der IT der Merksatz Never change a running System verkörpert.

Vermutlich setzen in den nächsten Jahren einige Distributionen das neue Paradigma in ihren Systemen um, andere dürften eher beim Althergebrachten bleiben – eine spannende Entwicklung mit offenem Ausgang. Ähnlich wie bei Systemd entwurzeln derart tiefgreifende Änderungen einige Anwender, die sich neue Distributionen suchen müssen. Das lässt sich bereits aus einigen Kommentaren zu Schallers Artikel ablesen. Sinngemäß heißt es darin: “Ich benutze von Anfang an Fedora, aber wenn ihr das umsetzt, bin ich weg.” (tle/jlu)