Bei OpenSuse gibt es sie: die sprichwörtliche Qual der Wahl. Doch wer sich einen Überblick über die neuen OpenSuse-Spielarten verschafft, darf sich über die hinzugekommenen Möglichkeiten freuen.
OpenSuse Leap, Tumbleweed, Slowroll, MicroOS, Aeon und Kalpa: In sechs Spielarten liegt die quelloffene Distribution mittlerweile vor. Zeit für einen Überblick, der erläutert, für welches Einsatzgebiet sich welche dieser Varianten eignet, was die Derivate technisch unterscheidet und nicht zuletzt, welchen Entwicklungsstatus sie aufweisen.
Wohlfühlzone
Leap [1] ist und bleibt das Flaggschiff von OpenSuse und erreicht die meisten Anwender (Abbildung 1). Das Modell der Weiterentwicklung hat sich seit der Zeit, als Suse sein Geld noch mit dem Verkauf von Installations-DVDs verdiente, nicht grundlegend verändert: Alle 12 Monate erscheint eine neue Ausgabe. In der Zwischenzeit bügeln Online-Updates Sicherheitslücken und Fehler aus, spielen aber – mit wenigen Ausnahmen – keine neuen Paketversionen ein. Eine Auffrischung der Software findet nur beim Upgrade der kompletten Distribution statt. Bis eine Softwareversion in Leap erscheint, hat sie vorher schon in Tumbleweed einen Testlauf absolviert, sprich: Die Anwender meldeten bereits Fehler, falls vorhanden.

Abbildung 1: Während OpenSuse Leap meist mit einem gepflegten KDE-Desktop glänzt, ist der Star von Leap 15.6 der frische Gnome-45-Desktop.
Sind die Fehler von den Maintainern der Software ausgebügelt, fällt den OpenSuse-Entwicklern die Aufgabe zu, diese Fixes auf die älteren Programmversionen in Leap zurückzuportieren. Sicherheitslücken dürfen keinesfalls bis zu einem Jahr auf den Anwendersystemen schlummern. Diese Backports bergen aber selbst wieder potenzielle Probleme. Im Reiter Änderungsprotokoll in YaST Software findet sich eine Dokumentation aller Backports (Abbildung 2).
Das zentrale Charakteristikum von Leap ist nicht unbedingt die geringere Anzahl von Bugs, sondern dass sich Anwender darauf verlassen dürfen, dass sich Funktion und Bedienung ihrer gewohnten Programme nur bei den jährlichen Aktualisierungen verändern. Wem es zusagt, sich nur einmal im Jahr mit neuen, veränderten Versionen seiner Software auseinanderzusetzen, der findet in Leap seine Wohlfühlzone in der Linux-Welt.
Leap erreichte jüngst Version 15.6. Sie markiert die letzte Leap-Version, die einen Großteil ihrer Pakete aus dem letzten Service-Pack der kostenpflichtigen Suse-Enterprise-Version SLES [2] übernimmt. Während die Ausgabe im Vergleich zum Vorgänger 15.5 etliche Pakete auffrischt, liegen notorisch veraltete Pakete wie Audacity (Version 2.2.2 statt 3.3.5 upstream) oder Blender (2.82a statt 4.1.1) immer noch in Uraltversionen von 2018 und 2020 bei.
Der KDE-Desktop läuft nach wie vor in der älteren Version 5 (5.27.11). Gnome dagegen, bei Leap-Updates traditionell eher ein Nachzügler, liegt immerhin in Version 45 bei, wenn auch nicht in der aktuellen Version 46 vom März 2024. Leap 15.5 musste noch mit Gnome 41 von Ende 2021 auskommen.
Geändert hat sich außer etlichen aufgefrischten Programmen und der Desktop-Umgebung zwischen Leap 15.5 und 15.6 wenig. Wer sich mit Ersterem auskennt, muss für Letzteres nicht umlernen. Einzig die Webadministrationskonsole Cockpit [3], eventuell ein Ersatz für das immer weniger gepflegte YaST, ist als wichtiger Neuzugang der Version 15.6 zu nennen (Abbildung 3).

Abbildung 3: Das aus der Server-Administration bekannte Web-Tool Cockpit ist erstmals an Bord und im Webbrowser zunächst nur lokal unter http://localhost:9090 nutzbar.
Steter Fluss
Die OpenSuse-Spielart mit den zweithäufigsten Installationen, Tumbleweed [4], spielt neue Programmversionen schon wenige Tage oder Wochen nach Freigabe durch die Upstream-Entwickler ein (Abbildung 4). Auf diese stetige Veränderung spielt der Name Tumbleweed an: So heißen in den USA verdorrte Pflanzenteile, die der Steppenwind stetig über das Land weht. Diese Upgrade-Strategie, die auch andere Distributionen wie Arch Linux nutzen, ist als Rolling Release bekannt.

Abbildung 4: Tumbleweed glänzt mit wöchentlich versionsaktualisierter Software wie der KDE-Plasma-Version 6.0.4.
Damit die Versionen schnell weiterrollen, bedient sich Tumbleweed eines automatisierten Testverfahrens: Die von Suse entwickelte Software OpenQA [5] installiert das Programm, startet es, klickt auf vordefinierte Buttons oder gibt Text ein. Besonders zeichnet sich OpenQA dadurch aus, dass es grafische Programme testet: Es nutzt dafür eine optische Zeichenerkennung (OCR), um zum Beispiel Fehlermeldungen von Erfolgsmeldungen zu unterscheiden.
Das automatisierte Verfahren gestattet es, alle Neuerungen eines wöchentlichen Tumbleweed-Snapshots in wenigen Stunden durchzutesten – viel schneller, als es manuell möglich wäre. Die Testergebnisse liegen offen zur Einsicht bereit [6].
Abbildung 5 demonstriert, wie OpenQA-Tests für LibreOffice ablaufen: Die Testautomation hat nach dem Start die Tastatureingabe “Hello World!” übermittelt. Nun checkt sie, ob LibreOffice diesen Text anzeigt. Prüfen, ob sich in einer Textverarbeitung Text eingeben lässt – das ist in etwa die Testtiefe, die Tumbleweed-Anwender für ihre Softwareaktualisierungen erwarten dürfen. Mehr als diese Basis-Tests lässt die Manpower von Suse bei Unmengen sich stetig weiterentwickelnder Anwendungen nicht zu.

Abbildung 5: Hier testet die Testplattform OpenQA, ob der Text “Hello World!” nach dem Tippen tatsächlich auf der LibreOffice-Seite erscheint.
Zurückdrehen
Funktioniert ein für Sie unverzichtbares Programm nach einem Tumbleweed-Upgrade nicht mehr zufriedenstellend, haben Sie die Möglichkeit, zu einem früheren Schnappschuss des Systems zurückzukehren (Abbildung 6): Jedes Upgrade konserviert dazu stets den vorherigen Zustand. Das Rollback dreht allerdings das gesamte Update zurück, inklusive aller eingeflossenen Sicherheits-Fixes.

Abbildung 6: Jede Installation (1) mit YaST (2) oder Zypper auf der Kommandozeile (3) und jedes Zurückspielen eines alten Systemzustands hinterlässt ein wiederherstellbares differenzielles System-Backup.
Versierte Anwender können versuchen, ein problematisches Programm separat auf eine frühere Version herabzustufen. Offizielle Unterstützung gibt es dafür nicht, die Zahl der zu testenden Kombinationen wäre endlos. Das einfachste Vorgehen kehrt zunächst zu einem Snapshot zurück, in der die fragliche Software noch in der alten Version vorlag, und aktualisiert dann das System unter Ausschluss dieses einen Programms.
Um zum Beispiel die LibreOffice-Version des letzten Snapshots wiederherzustellen, kehren Sie zunächst mit sudo snapper rollback zu diesem Snapshot zurück und starten den Rechner neu. Dann markieren Sie in YaST Software alle installierten LibreOffice-Bestandteile per Rechtsklick als geschützt (Abbildung 7). Hierzu gehören auch libhypern0 und libmythes, was sich aus den Beschreibungen der Pakete folgern lässt. Nun spielen Sie die Updates erneut ein, LibreOffice bleibt dabei ausgenommen.

Abbildung 7: Die Rechtsklickoption Geschützt — nicht verändern in YaST Software nimmt bestimmte Pakete von einem folgenden Tumbleweed-Upgrade aus.
Startet ein auf einer älteren Version fixiertes Programm nicht mehr, äußert sich das beim Aufruf aus der Konsole in der Regel durch eine Meldung über eine nicht auffindbare .so-Datei oder ein undefined symbol (Abbildung 8). In diesem Fall entfernen Sie in YaST Software den Status geschützt und bringen via sudo zypper dup die Installation wieder komplett auf den unterstützten aktuellen Stand.
Das simple Zurücknehmen von Updates, die Probleme verursachen, gilt als ein Alleinstellungsmerkmal von OpenSuse. Zwar steht der hierfür von Suse entwickelte Systemdienst Snapper [7] jeder Distribution offen. Tatsächlich bringen Fedora, Ubuntu, Debian und Arch Linux ihn auch mit. Doch nur der Suse-Installer richtet ihn funktionsfähig ein, was ohnehin Btrfs als Dateisystem voraussetzt.
Selbstredend lässt sich Tumbleweed nutzen, ohne sich mit Snapshots und deren Rollback zu befassen. Es wäre jedoch realitätsfremd, zu behaupten, dass die Weiterentwicklung von Software ohne Regressionen über die Bühne geht. So bezeichnet man den Effekt, dass eine bisher funktionierende Funktion in einer neuen Version plötzlich Probleme macht.
Daher empfiehlt sich Tumbleweed für Anwender, die es nicht abschreckt, gelegentlich ein Update mit ein paar Konsolenbefehlen zurückzudrehen. Die Konsole kommt ja schon bei Tumbleweed-Aktualisierungen selbst zum Einsatz. Als hilfreich erweist sich dabei eine schnelle Internet-Verbindung, denn die wöchentlich auflaufenden Aktualisierungen bewegen sich im Bereich etlicher Hundert MByte. Sie umfassen oft über 1000 Pakete, für deren Installation gerade ältere Rechner ihre Zeit brauchen.
Monatsration
Da Tumbleweed-Auffrischungen Zeit und Bandbreite beanspruchen, fragt sich mancher vielleicht, ob die Aktualisierungen nicht einfach etwas langsamer rollen könnten. Für Anwender, die das Rolling-Release-Prinzip zwar schätzen, denen die wöchentliche Release-Flut aber zu viel Aufwand verursacht, gibt es Slowroll [8]. Dabei handelt es sich sozusagen um ein gebremstes Tumbleweed mit monatlichem statt wöchentlichem Update-Takt (Abbildung 9). Sicherheitskorrekturen erscheinen trotzdem ohne Verzögerung.

Abbildung 9: Slowroll ist identisch mit Tumbleweed, frischt aber das System nur einmal pro Monat anstatt wöchentlich auf.
Ein wackerer Einzelkämpfer hat dazu ein Toolset entwickelt [9], das automatisiert zwischen beiden Kategorien trennen soll. Die Updates für Slowroll generiert es ohne menschliches Eingreifen aus denen für Tumbleweed. Entstanden ist dieses Vorgehen 2023 als Notfallstrategie für den Fall, dass die Zahl der Freiwilligen nicht mehr ausreichen sollte, um Leap fortzuführen. Die Entwicklung von Slowroll geht langsam voran, obwohl Suse sich Anfang des Jahres zur Weiterführung von Leap entschieden hat [10]. Ein Blogpost von Anfang Mai 2024 [11] macht Hoffnung, dass Slowroll langsam den Zustand erreicht, den sein Entwickler sich erhofft hat.
Zur Installation nutzt Slowroll eine eigene DVD [12]. Leap und Tumbleweed-Installationen wandelt zudem ein Austauschen der Repositories und ein darauffolgendes sudo zypper dup in ein Slowroll-System um [13]. Ein Slowroll-System lässt sich auf den ersten Blick nicht von einer einige Wochen nicht aufgefrischten Tumbleweed-Installation unterscheiden. Tatsächlich verwandelt es ein erneuter Austausch der Repositories problemlos in ein Tumbleweed-System zurück.
Vollautomat
Eine neue OpenSuse-Distribution für ein möglichst simpel zu bedienendes System, das Windows-Umsteigern entgegenkommt, liegt mit Aeon [14] vor (Abbildung 10). Anwender müssen sich hier gar nicht mehr um Aktualisierungen kümmern: Das System spielt sie im Hintergrund in einen dafür neu angelegten, noch inaktiven Snapshot ein. Das gerade laufende System berührt dieses Update überhaupt nicht. Er bleibt in sich konsistent und funktionierend, bis der Anwender Zeit findet, den Snapshot per Reboot zu aktivieren.

Abbildung 10: OpenSuse Aeon bringt vorinstalliert einen Gnome-Desktop inklusive Dateimanager, den Gnome Store und Firefox mit. Weitere Anwendungen decken von Suse unabhängig Flatpak-Pakete von Flathub.org ab.
Sollte nach dem Update das System nicht mehr bis zu einer funktionierenden Gnome-Session hochfahren, bemerkt dies die in Aeon integrierte Komponente Health Checker [15] und setzt das System automatisch auf den letzten erfolgreich startenden Snapshot zurück. Der Anwender nimmt nur eine verlängerte Startzeit wahr, muss aber nicht händisch eingreifen.
Ein nur lesbar eingehängtes Dateisystem verleiht Aeon zusätzliche Stabilität. Dass Benutzer versehentlich Systemdateien löschen, bleibt sogar bei Root-Rechten ausgeschlossen. Dieser Sicherheitsmaßnahme ist es geschuldet, dass Auffrischungen nur per Reboot erfolgen.
Doch wie installiert der Anwender Software in ein solches System? Unter Aeon klappt das nicht systemweit, sondern nur auf Benutzerebene. Zudem bringt Aeon hierfür keine eigenen Pakete mit, sondern bindet Flathub [16] ein, das zentrale Repository mit distributionsübergreifend einsetzbaren Paketen im Flatpak-Format [17]. Als grafische Anwendung zur Installation dient nicht YaST, sondern der Gnome App Store (Abbildung 10), in dem sich Smartphone-Anwender zu Hause fühlen.
Flatpak-Pakete auf Flathub sind gewöhnlich topaktuell (Abbildung 11). In den meisten Fällen kümmern sich die Entwickler einer Software selbst darum, gleich nach Erscheinen einer neuen Ausgabe ein Flatpak-Paket bereitzustellen. Dank des distributionsübergreifend einsetzbaren Formats rentiert sich der Aufwand der Erstellung eines einzigen Pakets. Dagegen überfordert es die meisten Teams, RPM- oder DEB-Pakete auch nur für die verbreitetsten vier oder fünf Distributionen zu erstellen.

Abbildung 11: Auf dem Flatpak-Repository warten systemübergreifende Programmpakete für fast alle Linux-Distribution. Aeon verlässt sich ausschließlich auf dieses Repository.
Den großen Vorteil der distributionsübergreifenden Einsetzbarkeit erkauft Flatpak mit einigen unbestreitbaren Nachteilen. In der Regel werden Flatpaks von eher unerfahrenen Personen erstellt, die anders als die Sicherheitsteams der Distributionen nicht täglich die gemeldeten Sicherheitslücken im Blick haben. Außerdem enthält jedes Flatpak-Paket zusätzlich zum eigentlichen Programm alle Abhängigkeiten. Flatpaks belegen so im Vergleich zu konventionellen Paketen wesentlich mehr Plattenplatz und nehmen teilweise mehr Arbeitsspeicher in Anspruch.
Der Sicherheitsproblematik wirkt die Sandbox der Flatpak-Laufzeitumgebung entgegen, die Anwendungen strikt vom restlichen System abschirmt. Auch könnte sie den Zugang auf das Home-Dateisystem blockieren – der Konjunktiv rührt daher, dass viele Flatpak-Pakete dies im Moment nicht tun. Die Installation mit reinen Benutzerrechten und die Read-only-Systempartition verwehren etwaiger Schadsoftware immerhin Root-Rechte. Im unter Aeon standardmäßig genutzten Wayland sind Keylogger anders als in X-Window-Sessions technisch nicht mehr umsetzbar.
Zur Not installiert der Nutzer auch unter Aeon Software systemweit. Direkt mit Zypper oder YaST klappt das in einem Read-only-Root-Dateisystem nicht. Es liegt jedoch das Tool transactional-update bei, das zu diesem Zweck einen neuen Snapshot anlegt. Nach jeder Neuinstallation wird ein Reboot fällig. Doch dieser Weg, Software zu installieren, sollte nur in seltenen Fällen zum Einsatz kommen, etwa für die Installation eines zusätzlichen Treibers.
Box in der Box
Zusätzlich ist von Haus aus mit Distrobox [18] ein normales Linux-System (Abbildung 12) in das immutabel (also unveränderlich) gestaltete Grundsystem eingebettet. Durch die simple Eingabe von distrobox create tumbleweed installieren Sie ein eigenständiges, ähnlich wie Flatpak-Anwendungen in einen Container eingesperrtes System. Standardmäßig handelt es sich dabei um Tumbleweed, doch der Einsatz vieler verbreiteter anderer Distributionen ist erlaubt. Zwar bedienen Sie Distrobox über die Kommandozeile, doch es starten dort auch grafische Programme (Abbildung 13).

Abbildung 12: Dank Distrobox lassen sich unter Aeon schnell verschiedenste Distributionen als Container einrichten – mit vollem Zugriff auf deren Repositories und der Möglichkeit, auch grafische Programme auszuführen.

Abbildung 13: In einer Tumbleweed-Distrobox genügt es, zypper install gimp einzugeben – schon ist Gimp in der Tumbleweed-Version unter Aeon als natives Tumbleweed-Paket verfügbar.
Ein prominentes Einsatzgebiet findet Distrobox in der Softwareentwicklung: Das praktische Tool stellt mit wenig Aufwand eine Umgebung zum Testen von Software unter verschiedensten Linux-Distributionen bereit. Durchschnittsanwender nutzen damit aber einfach Anwendungen aus Tumbleweed, Leap, Fedora, Ubuntu oder weiteren Distributionen auf einem Aeon-System.
Die Container-basierte Lösung verschwendet weniger Systemressourcen und kostet weniger Zeit als die Installation der Linux-Systeme in virtuellen Maschinen. Die Anwendungen erscheinen mit fast nativer Performance als normales Fenster im Hauptsystem (Abbildung 13) und greifen wie native Programme auf das Home zu. Startmenüeinträge für Anwendungen dürfen Sie in einer Distrobox ebenfalls anlegen. Verglichen mit nativ installierten OpenSuse-RPM-Paketen ist der RAM- und Festplattenplatzbedarf naturgemäß höher. Distrobox ist fest in das unveränderliche Aeon-Grundsystem eingebaut, lässt sich aber auf allen OpenSuse-Systemen installieren.
Fest eingebaut und alternativlos baut Aeon auf die Gnome-Desktop-Umgebung. Es gibt jedoch mit Kalpa ein KDE-Pendant [19], das sich allerdings noch in einem früheren Entwicklungsstatus befindet als Aeon. Aeon selbst liegt seit längerer Zeit als Release Candidate (RC) vor, noch nicht als stabiles Endprodukt. Hauptsächlich liegt das daran, dass der bisher genutzte Standard-OpenSuse-Installer Optionen anbietet, die die Funktion von Aeon sabotieren. Wer die Standardeinstellungen beibehält, arbeitet mit dem installierten System jedoch stabil.
Ein Linux-System mit Read-only-Dateisystem mag Veteranen absonderlich erscheinen. Diese immutable Architektur ist jedoch weder Suse-typisch, noch unter OpenSuse neu. Schon seit Langem bringt der OpenSuse-Installer die Option transaktionaler Server mit, die denselben Systemaufbau einrichtet, wie ihn Aeon und Kalpa nutzen, wenngleich ohne grafischen Desktop. Fedora bietet seit Längerem mit Silverblue [20] und Kinoite [21] ähnlich aufgebaute Derivate an.
Den transaktionalen Server, ein schlankes Server-Rumpfsystem für Container-basierte Server-Dienste, gibt es inzwischen als separates Produkt: Bei MicroOS [22] haben Sie die Wahl zwischen einem kostenpflichtigen Enterprise-Produkt und einer freien OpenSuse-Spielart. Der Fokus von MicroOS liegt zwar nicht auf Desktop-Anwendern, doch wer sich mit Containern auskennt, nutzt es als stabile Laufzeitumgebung für Server-Dienste in einem OCI-Container [23].
Fazit
Zu den stabilen Arbeitspferden Leap und Tumbleweed gesellt sich als neues stabiles Mitglied der OpenSuse-Familie letztlich nur MicroOS, eine für Heimanwender weniger interessante Server-Container-Plattform.
Doch Aeon, das Pendant zum immutablen Fedora Silverblue, gilt nur deshalb noch als RC, weil der bisherige komplexe Suse-Installer nicht zum Gesamtkonzept passt. Die Distribution selbst macht zur Laufzeit keine Probleme. Das lässt sich für OpenSuses immutables Derivat Kalpa mit KDE-Desktop noch nicht behaupten.
Auch Slowroll, eine nur monatlich statt wöchentlich aufgefrischte Variante von Tumbleweed, dürfte in der Praxis unauffällig bleiben. Nutzer wandeln eine bestehende Tumbleweed-Installation leicht in ein Slowroll-System um, der Weg zurück zu Tumbleweed steht gleichfalls offen. (uba)
Infos
-
Cockpit: https://cockpit-project.org
-
Tumbleweed: https://get.opensuse.org/tumbleweed/
-
OpenQA: http://open.qa
-
OpenQA-Testergebnisse: https://openqa.opensuse.org/group_overview/1
-
Snapper: http://snapper.io
-
Slowroll-Tools: https://github.com/openSUSE/slowroll-tools
-
Beitrag zur Zukunft von Leap: https://news.opensuse.org/2024/01/15/clear-course-is-set-for-os-leap/
-
Kommentar zum Mai-Upgrade von Slowroll: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/46FR5PE4LPB5PP7BNQ6R5L24I3F5677Y/
-
Slowroll-DVDs: https://download.opensuse.org/slowroll/iso/?P=*DVD*
-
MicroOS herunterladen: https://en.opensuse.org/Portal:MicroOS/Downloads
-
Health Checker: https://github.com/kubic-project/health-checker
-
Flathub: https://flathub.org
-
Flatpak: https://flatpak.org
-
Distrobox: https://github.com/89luca89/distrobox
-
Fedora Silverblue: https://fedoraproject.org/atomic-desktops/silverblue/
-
Fedora Kinoite: https://fedoraproject.org/atomic-desktops/silverblue/
-
MicroOS: https://microos.opensuse.org
-
OCI-Container: https://opencontainers.org







