Wo der Weg von OpenSuse Leap hinführt, weiß niemand ganz genau. Wir sehen uns an, wie ein Leap auf der Basis der ALP-Plattform künftig aussehen könnte.

In der Suse-Welt bewegen sich momentan einige Dinge. Was die Nürnberger Distributionen Suse Linux Enterprise (SLE) und OpenSuse angeht, galt zunächst lediglich eines als klar definiert: Container werden dabei eine wesentliche Rolle spielen, die Zukunft soll der Adaptable Linux Platform (ALP) [1] gehören.

Suse orientiert sich dabei konzeptionell an unveränderlichen Distributionen wie Fedora Silverblue und dem hauseigenen, eher für Edge Computing und als Container-Runtime gedachten MicroOS. Allerdings blieben die Fakten zu ALP lange Zeit schwammig, was sich erst auf der Susecon im Juni 2023 änderte. Bis dahin hatte das Unternehmen einzig ein Immutable-Dateisystem mit transaktionalen Aktualisierungen zugesagt.

ALP folgt einem zweigeteilten Ansatz, der ein die Hardware aktivierendes Host-System und eine darüberliegende Benutzerschicht umfasst. Das Host-System soll so minimalistisch wie möglich ausgelegt sein und noch weniger Funktionalität bieten als das derzeitige SLE Micro [2]. Die Benutzerschicht stellt Anwendungen in Form von Flatpaks und ähnlichen Containern bereit.

Tumbleweed

Nur die wenigsten Leser dieses Magazins dürften den Suse Linux Enterprise Server (SLES) abseits des Jobs einsetzen. Für Privatanwender stellt sich eher die Frage, was im Zuge der Umgestaltung aus OpenSuse Leap wird. Suses Community-Distribution muss sich ohnehin seit Langem den Vorwurf gefallen lassen, nicht Fleisch und nicht Fisch zu sein. Die Rolling-Release-Variante Tumbleweed [3] dagegen glänzt mit einer klareren Definition, gilt als vergleichsweise erfolgreicher und zieht mit über 1000 regelmäßig Beitragenden wesentlich mehr Entwickler an.

Die Nutzer von Tumbleweed müssen also sich derzeit keine Sorgen um die Zukunft der Distribution machen. Sie bleibt von den Verwerfungen im Suse-Universum weitgehend unberührt, und im Falle eines Falles verfügt die Community über ausreichend Potenzial, das Projekt notfalls selbstständig als Fork zu betreiben. Ob sich dasselbe bei OpenSuse Leap so einfach stemmen ließe, darf man hingegen ernsthaft bezweifeln. Nichtsdestoweniger wird es in den nächsten Jahren eine stark engagierte Community um OpenSuse Leap brauchen, wenn die Distribution überleben soll.

Schwerfälliger SLES

Schon vor der diesjährigen Susecon war man sich einig, dass SLES definitiv zu den offenen Baustellen im Suse-Universum zählt. Gleich nach der Entwicklerkonferenz berief Richard Brown [4], derzeit Distributionsarchitekt bei Suse, ein Meeting ein, das in groben Zügen die angedachte Entwicklung skizzierte und als Youtube-Video zur Verfügung steht [5]. Zunächst ging er jedoch darauf ein, warum sich SLES immer schwieriger umsetzen lässt und deswegen eine neue Architektur vonnöten ist.

Die Profi-Distribution kommt mit fast 34 000 Quellpaketen. Bei einer Lebensspanne von zehn bis 13 Jahren sagt Suse zu, alles, was das Unternehmen in einer Hauptversion ausliefert, über alle Service-Packs hinweg bis zum Ende der Lebenszeit (EOL) zu unterstützen. Zum Lebensende einer SLES-Version besteht diese also aus dem eigentlichen Release sowie sämtlichen Service-Packs und Updates. Das soll sich mit ALP grundlegend ändern.

Erste Schritte in diese Richtung lassen sich bei SLE Micro beobachten, das hauptsächlich beim Edge-Computing zum Einsatz kommt. Es bietet weniger als 1000 Pakete und folgt einem halbjährlichen Release-Zyklus. Die Lebensspanne verkürzt sich dementsprechend auf sechs Jahre, und Suse hat die Workloads containerisiert. Damit lagen die Nürnberger offensichtlich richtig, denn SLE Micro ist das am schnellsten wachsende Produkt des Unternehmens. Dieser Erfolg soll mit ALP mehr Suse-Kunden in weiteren Märkten erreichen, beispielsweise in Rechenzentren.

Flatpak vor RPM

ALP bezeichnet dabei weder ein fest umrissenes Produkt noch eine Distribution, sondern eine Plattform, auf deren Basis künftige Suse-Produkte unterschiedlicher Ausrichtung und Größe entstehen sollen.

Da OpenSuse Leap in den letzten Jahren den Kern von SLES als Grundlage übernahm und um eine Anwendungsschicht aus Paketen im RPM-Format ergänzte, stellt sich die Frage, was das für OpenSuse bedeutet. Bei ALP spielen RPMs aus Anwendersicht kaum noch eine Rolle, sie tauchen lediglich im unveränderlichen Root-Dateisystem auf. Die Ausgestaltung des Systems mit Anwendungen soll sich auf Flatpaks beschränken.

Da fragen sich viele Anwender von OpenSuse Leap, ob sie sich möglicherweise eine neue Distribution suchen müssen. Diese Frage lässt sich zum jetzigen Zeitpunkt nur mit einem klaren Jein beantworten. Wenn Sie nicht zu Tumbleweed wechseln möchten und sich zudem wenig für Flatpaks begeistern, könnten Sie sich beim Finden einer neuen Distro schwertun. Aber noch bleibt Ihnen Zeit: Das vorausgeplante Ende von Leap in seiner derzeitigen Form hat Suse von Version 15.5, das eigentlich bereits auf ALP basieren sollte, auf Leap 15.6 verlegt.

Suse stellt OpenSuse weiterhin die für Leap erforderlichen Quellen zur Verfügung, allerdings künftig basierend auf ALP. Entwicklerzeit will das Unternehmen jedoch nicht mehr investieren; hier muss die OpenSuse-Community tatkräftig mithelfen, worin Brown das größte Problem sieht. Das Team ist für die anstehenden Arbeiten viel zu klein, und zwei Aufrufe zur Mitarbeit vergrößerten es bisher nicht wesentlich. Das Hauptproblem stellt die Pflege der Desktop-Umgebungen dar.

Vom Zeitplan her ist ein Ergebnis nicht vor Ende 2025 zu erwarten. Brown fasst als mögliche Übergangslösung außerdem ein traditionelles Leap 15.7 ins Auge, bevor mit Leap 16 endgültig ALP Einzug hält.

OpenSuse MicroOS

Um OpenSuse-Anwendern einen Vorgeschmack darauf zu geben, wie sich OpenSuse Leap künftig anfühlen könnte, haben wir uns OpenSuse MicroOS angesehen. Die unveränderliche Distribution ist ähnlich aufgebaut, wie das bei einem künftigen Leap auf ALP-Basis der Fall sein könnte. OpenSuse MicroOS kommt mit Gnome und KDE Plasma, wobei wir uns für die letztere Variante entschieden haben. Bei dem System handelt es sich noch um ein Alpha-Release, das aber trotzdem recht ordentlich funktioniert und sich für längere Tests eignet.

Zum Herunterladen stehen verschiedene Images für x86, Raspberry Pi, Pine64 und verschiedene virtuelle Maschinen bereit [6]. Im Test fiel die Wahl auf das x86-Abbild mit einer Größe von rund 4 GByte. Für einen Desktop entscheiden Sie sich erst während der Installation. Die Images für OpenSuse MicroOS sind nicht als Live-Medium ausgelegt, sie starten direkt in den Installer (Abbildung 1). Wir haben die Installation in Virtualbox vorgenommen.

Abbildung 1: Die Definition der System Role findet während der Installation statt. Das kann wie in unserem Fall MicroOS-Desktop, ein Container-Host oder ein mit TPM und Keylime abgesichertes MicroOS sein.

Aeon und Kalpa

Nebenbei sei noch angemerkt, dass OpenSuse kürzlich aus Gründen der Entzerrung der Nomenklatur eine Namensänderung für die Ausgaben mit Gnome und KDE Plasma vorgenommen hat [7]. Der bisherige OpenSuse MicroOS-Desktop mit Gnome heißt jetzt OpenSuse Aeon, der mit KDE Plasma hört künftig auf den Namen OpenSuse Kalpa.

Wie bei Suse üblich dient Btrfs als Dateisystem, während der Installation richten Sie zehn Subvolumes (Abbildung 2) ein, die unter anderem die von Leap gewohnte Funktionalität von Rollbacks per Snapshots bereitstellen [8]. Im Gegensatz zu anderen unveränderlichen Distributionen basiert das schreibgeschützt eingehängte Basissystem bei OpenSuse MicroOS auf dem hauseigenen Paketmanager Zypper und traditionellen RPM-Paketen, während bei Fedora Silverblue oder Kinoite mit RPM-OSTree eine systemfremde Paketverwaltung zum Einsatz kommt [9].

Abbildung 2: Sind die Einstellungen im Installer vorgenommen, zeigt MicroOS eine Zusammenfassung. Als Dateisystem dient Btrfs mit zehn Subvolumes.

Nach dem Neustart ins System installiert sich zunächst automatisch Firefox als Flatpak (Abbildung 3). Anschließend stellen Sie beim Aufrufen des Hauptmenüs fest, dass außer den Apps, die in unserem Fall KDE Plasma mitbringt, Firefox die einzige vorhandene Anwendung ist. Ein Blick auf die installierte Version des Plasma-Desktops zeigt mit 5.27.6 die aktuelle Version (Abbildung 4).

Abbildung 3: OpenSuse MicroOS bringt außer den KDE-Tools keinerlei Anwendungen mit. Nach dem ersten Neustart ins System wird automatisch Firefox als Flatpak installiert, damit die Anwender sich zumindest Hilfe bezüglich der nächsten Schritte suchen.

Abbildung 4: Nach der Installation zeigen die Systemeinstellungen einen aktuellen Plasma-Desktop und Kernel 6.4. Die Gnome-Edition nutzt standardmäßig Wayland, während der Plasma-Desktop als X11-Sitzung startet.

Suchen Sie nun wie gewohnt nach dem Verwaltungswerkzeug YaST, um zusätzliche Software zu installieren, werden Sie nichts finden. Im Terminal ein Paket per Zypper zu installieren, klappt ebenso wenig. Die Suche liefert zwar das gesuchte Paket, der Befehl zur Installation scheitert aber mit dem Hinweis, dass Sie auf einem transaktionalen System arbeiten (Abbildung 5).

Abbildung 5: Die Installation von Anwendungen mit Zypper gelingt mit MicroOS nicht mehr. Das gesuchte Paket taucht zwar auf, lässt sich aber als RPM auf diesem Weg nicht installieren.

Transactional Updates

Der nächste Schritt führt zu Discover, der Softwareverwaltung des Plasma-Desktops. Hier sehen Sie anhand der Einstellungen, dass das System für Flatpaks vorbereitet und bereits mit Flathub verbunden ist. Von dort komplettieren Sie das System mit den täglich benötigten Anwendungen.

Geht es allerdings um Treiber, Firmware oder Tools für die Konsole, hilft Flatpak nicht weiter. Hier kommen transaktionale Updates ins Spiel, mit denen sich zudem das Kernsystem automatisch im Hintergrund über einen Systemd-Dienst aktualisiert. Um etwa das Konsolen-Tool Htop zu installieren, nutzen Sie den folgenden Befehl:

$ sudo transactional-update pkg install htop

Daraufhin wird das Paket in der aktuellen Version aus den Tumbleweed-Archiven integriert (Abbildung 6). Allerdings können Sie es nicht sofort nutzen. Hier offenbart sich ein Pferdefuß unveränderlicher Systeme: Änderungen am Kernsystem wirken immer erst nach einem Neustart, wobei dann ein neuer Snapshot eingehängt wird (Abbildung 7). Der Vorteil liegt dabei darin, dass Sie direkt zum letzten funktionierenden Snapshot zurückrollen können, sollte nach dem Reboot etwas nicht wie gewünscht laufen. Die neue Systemd-Funktion Soft Reboot, die mit Systemd 254 veröffentlicht wurde [10], mildert diese Praxis künftig etwas ab.

Abbildung 6: Die Installation von Tools und Treibern findet über transaktionale Updates in der Konsole als RPM statt. Die Software landet so beim nächsten Neustart im unveränderlichen Root-Dateisystem.

Abbildung 7: Zusätzliche Software installieren Sie laut Empfehlung per Flatpak oder Distrobox. Über transaktionale Updates eingebundene Pakete lassen sich erst nach einem Neustart verwenden.

Distrobox

Durch die Integration von Distrobox kann OpenSuse MicroOS jedoch noch weit mehr [11]. Mit Distrobox installieren Sie in der Konsole in wenigen Sekunden einen Podman-Container mit einem anderen Betriebssystem (Abbildung 8) und versorgen sich über den Paketmanager dieser Distribution mit Software. Um etwa Arch Linux in einem archie genannten Container einzubinden (Abbildung 9) und darin den Mediaplayer SMPlayer zu installieren (Abbildung 10), benötigen Sie auf einem aktuellen System weniger als eine Minute (Listing 1).

Abbildung 8: Um mit Distrobox Anwendungen anderer Paketmanager zu installieren, setzen Sie zunächst einen leeren Container auf, den wir in unserem Fall archie getauft haben und in dem wir Pakete aus Arch Linux installieren.

Abbildung 9: Im zuvor mit Podman im Hintergrund erstellten Container installieren Sie das neueste Docker-Image mit Arch Linux und besuchen anschließend den Container.

Abbildung 10: Für unseren Test installieren wir mit dem Paketmanager Pacman aus Arch Linux den Medienplayer SMPlayer im Container.

$ distrobox-create --name archie --image archlinux:latest
$ distrobox-enter --name archie
$ sudo pacman -s install smplayer

Das ist eine schöne zusätzliche Funktion, aber keineswegs neu – auch andere Distributionen beherrschen das. So können beispielsweise abgehangene Pakete aus Debian Stable zusammen mit den neuesten Versionen aus Arch Linux samt AUR auf einem System koexistieren, da sie in verschiedenen Containern liegen.

Fazit und Ausblick

Wir wissen nicht, wie OpenSuse nach dem Architekturwechsel letztlich aussehen wird. Wahrscheinlich ähnelt es dem von uns getesteten OpenSuse MicroOS, das mit KDE Plasma jetzt Kalpa heißt [12]. Ob man nun Container mag oder nicht – so, wie die Entwickler sie hier einsetzen, machen sie auch auf dem Desktop eine gute Figur und erhöhen die Sicherheit des Systems.

Einer der prinzipbedingten Nachteile von unveränderlichen Systemen ist der nach Änderungen am Kernsystem notwendige Neustart. Abgesehen von Systemaktualisierungen sollten solche Änderungen allerdings ohnehin so selten wie möglich stattfinden. Mit der guten Integration von Flatpak und Distrobox stehen genügend Alternativen zur Verfügung.

Bevor Sie sich also nach einer komplett anderen Distribution umsehen, sollten Sie sich mit OpenSuse MicroOS beschäftigen. Arbeiten Sie allerdings für gewöhnlich tief im System, empfinden Sie unveränderliche Systeme wie MicroOS wahrscheinlich als vernagelt und dürften dem Prinzip nur wenig abgewinnen können. Für viele andere Anwender könnte das Stichwort Immutable jedoch den Weg in eine sorgenfreiere Linux-Zukunft weisen. (csi/jlu)