Freie Software bedeutet freie Auswahl. Ein Vergleich der OpenSuse-Spielarten mit anderen Distributionen hilft, das passende Linux für die eigenen Bedürfnisse zu finden.

Die OpenSuse-Familie ist inzwischen auf sieben Mitglieder angewachsen. Tatsächlich liefert keine andere Distribution so viele funktional unterschiedliche Spielarten. Doch für Anwender zählt nicht die Quantität, sondern die Qualität. Diese OpenSuse-Tipps vergleichen daher Tumbleweed mit anderen Rolling-Release-Distributionen, Leap mit ebenfalls zyklisch aufgefrischten Mitbewerbern sowie Aeon und Kalpa mit den Immutable-Distributionen von Fedora.

Basisangebot

Leap [1] gilt als bekannteste OpenSuse-Spielart, was nicht zuletzt am simplen Release-Modell liegt: Neue Ausgaben erscheinen jährlich. Bisher versorgte OpenSuse anschließend den Vorgänger noch sechs Monate lang mit Aktualisierungen, nun verlängert sich der Support auf 24 Monate. Der Überlappungszeitraum, der Anwendern für das Upgrade ohne eine Lücke bei den Security-Fixes bleibt, fällt damit für die 16er-Reihe von Leap (Abbildung 1) komfortabel lang aus.

Abbildung 1: Leap 16 schneidet alte Zöpfe ab: Der Desktop-Hintergrund ist nicht mehr grün, YaST gehört zum alten Eisen. Die Softwareverwaltung übernimmt das neue Programm Myrlyn.

Etwas schnelllebiger als OpenSuse ist Fedora: Die Workstation-Ausgabe [2], die Leap am nächsten kommt, erscheint halbjährlich. Der Support umfasst stets die aktuelle Fassung und deren Vorgänger plus etwa einen Monat. Anwender dürfen ein Release überspringen, es bleibt dann allerdings nur ein einmonatiges Zeitfenster für das Upgrade ohne Support-Lücke.

Die Fedora-Grundversion (Abbildung 2) basiert wie Leap 16.0 auf einem aktuellen Gnome-48-Desktop. Die Fedora-KDE-Ausgabe [3] bringt ein noch aktuelles KDE-Plasma 6.4 mit, Plasma 6.5 ist erst Ende Oktober erschienen. Fedora gilt insgesamt als wesentlich innovationsfreudiger als das tendenziell konservativere Suse. Einen ersten guten Eindruck hinterlässt der Startvorgang, der anders als bei OpenSuse völlig flackerfrei über die Bühne geht. Auch sonst wirkt die Optik von Fedora liebevoll gepflegt.

Abbildung 2: Fedora präferiert traditionell Gnome, liefert allerdings auch einen taufrischen KDE-Plasma-6.4-Desktop mit.

Die Repositories von Fedora stehen mit rund 75 000 Paketen deutlich besser da als die von Leap mit vergleichsweise mageren rund 35 000. Bei beiden Distributionen fehlen sämtliche von Patentklagen bedrohten Multimedia-Codecs. Wie bei OpenSuse das Packman-Repository hilft unter Fedora Rpmfusion [4] beim Nachinstallieren aus.

Ein funktionell mit Myrlyn, der aus dem YaST-Modul Software entstandenen Softwareverwaltung, ebenbürtiges grafisches Programm gibt es unter Fedora nicht. Möchten Sie mit einem Aufruf Paketgruppen wie den kompletten KDE-Desktop installieren, gewöhnen Sie sich unter Fedora am besten an Kommandozeilenaufrufe wie sudo dnf install @kde-desktop-environment.

Thronfolger

Anno 2004 war OpenSuse in Deutschland die mit Abstand populärste Distribution. Ein rebellischer Newcomer stieß sie noch im selben Jahr vom Thron: Ubuntu. Dessen Ansatz, mit einem schlicht gestalteten Installer vor allem Windows-Umsteiger anzusprechen, bescherte der Distribution von Canonical einen großen Marktanteil. Der gleichfalls minimalistische Desktop, in aktuellen Ubuntu-Versionen ein einsteigerfreundlich modifiziertes Gnome (Abbildung 3), überzeugte viele Durchschnittsanwender.

Abbildung 3: Der Ubuntu-Gnome-Desktop weist anders als das Original eine permanent sichtbare Starterleiste samt Startmenü-Button auf.

Keine Distribution schreibt die mitgelieferte Software selbst, sondern verpackt freie Programme in Pakete, die mit den mitgelieferten Bibliotheken getestet sind. Nicht einmal diese Aufgabe übernimmt Ubuntu selbst, vielmehr bedienen sich dessen Entwickler aus Debian Unstable [5]. Diesen Debian-Zweig nutzen etliche Anwender direkt, entgegen den Empfehlungen der Debian-Entwickler.

In Unstable fließen laufend neue Softwareversionen ein, was – wie bei Rolling-Release-Distributionen üblich – plötzlich das Verhalten von Programmen verändern kann: Ersetzt ein Update ohne Vorwarnung etwa Gimp 2 durch Gimp 3, zwingt das den Anwender, sich neu einzuarbeiten. Der Release-Prozess von Ubuntu, der das Debian-Unstable-Repository für jeweils ein halbes Jahr einfriert, trifft dennoch offenbar die Bedürfnisse vieler Anwender. Er liefert neuere Software als Debian Stable, die Versionsstände bleiben trotzdem zwischen den Distributions-Upgrades stabil.

Schon seit 2006 bietet Ubuntu sogenannte LTS-Versionen mit im Moment fünf Jahren freiem Support an. Ein für bis zu fünf Rechner kostenloses Abonnement erweitert diesen Zeitraum sogar auf zehn Jahre. Dennoch erscheint alle zwei Jahre eine neue LTS-Version. Die Ubuntu-Webseite geht davon aus, dass 95 Prozent der Ubuntu-Installationen solche langzeitunterstützten Releases nutzen.

Ein Abonnement erweitert bereits innerhalb der ersten fünf Jahre die Anzahl der aufgefrischten Pakete, was dann bei jedem Update-Vorgang ein Werbetext verkündet (Abbildung 4). Diese Werbefinanzierung stößt manchen Anhängern freier Software sauer auf.

Abbildung 4: Ubuntu weist beim Login per SSH auf Updates hin und wirbt dabei für die Expanded Security Maintenance (ESM) des für fünf Rechner pro Anwender kostenlosen Ubuntu-Pro-Abos.

Das Verdienst von Ubuntu liegt darin, den nicht von allen Anwendern gewünschten Rolling-Release-Charakter von Debian Unstable für einen Zeitraum zwischen sechs Monaten und fünf oder zehn Jahren einzufrieren. Zudem integriert Ubuntu gleich bei der Installation die bei fast allen Anwendern gefragten Multimedia-Codecs. Es ist jederzeit möglich, von einer Ubuntu-LTS-Version auf die nächstneuere Nicht-LTS-Version zu springen.

Seine Alleingänge brachten Ubuntu des Öfteren Kritik ein. Übrig geblieben ist davon im Wesentlichen nur das Snap-Paketformat. Dieser etwas eigenwillige Gegenentwurf zum distributionsübergreifenden Flatpak-Format kommt praktisch nur unter Ubuntu zum Einsatz. Kritiker fragen, welchen Sinn ein nur in einer Distribution gängiges, distributionsübergreifendes Paketformat haben soll, das gleichzeitig die Startzeit der Pakete verlängert, die Systemarchitektur verkompliziert und die Pflege der Pakete erschwert. Beim Firefox-Paket spüren Anwender den Einsatz von Snap an einer längeren Startzeit, die der Sicherheitsgewinn durch Kapselung hier allerdings rechtfertigen mag.

Rückzugsmöglichkeit

OpenSuse zeichnet sich dadurch aus, dass es mit Tumbleweed und Leap sowohl eine Rolling-Release-Variante als auch eine jährlich aufgefrischte Version im Portfolio hat. Ein Umstieg verlangt Anwendern weniger Umgewöhnung ab als der Wechsel zu einer anderen Distribution. Tumbleweed und Leap beruhen auf derselben Codebasis, wenn auch in unterschiedlicher Aktualität. Myrlyn oder Zypper verwalten hier wie dort die Software. Eine Leap-Installation lässt sich jederzeit zum Tumbleweed-System umbauen.

Das Setup mit Standardeinstellungen richtet einen Mechanismus ein, der automatisch vor jeder Softwareinstallation einen Snapshot anlegt (Abbildung 5), zu dem das System blitzschnell zurückkehren kann. Besonders für Anwender von Rolling-Release-Distributionen ist dies Gold wert. Bei der Weiterentwicklung von Software kommt es unweigerlich zu sogenannten Regressionen, bei denen Neuerungen dazu führen, dass bisher fehlerlose Funktionen einer Software plötzlich Probleme bereiten.

Abbildung 5: OpenSuse legt bei Aktionen der Softwareverwaltung und von YaST automatisch System-Snapshots an. Deren Anzahl lässt sich konfigurieren, um den Speicherplatzverbrauch zu begrenzen.

Ein schon einige Jahre zurückliegender Fall, der den Nutzen der Speicherpunkte unterstrichen hat, trat beim KDE-Mailprogramm KMail auf: Nach einem Versions-Update stürzte es unter Tumbleweed beim Öffnen eines Fensters für neue Mails reproduzierbar ab. Die Nutzer fragten sich befremdet, wie den Entwicklern ein so gravierender Fehler durchrutschen konnte.

Die Antwort: Der Absturz trat nur auf, wenn ein Rechtschreibwörterbuch in einer anderen Sprache als Englisch ausgewählt war. Solche Bugs, die nur in bestimmten Konstellationen auftreten, sind selbst für die mit ihrer Software vertrauten Entwickler schwer aufzuspüren. Tumbleweed versucht, derartige Fehler durch automatisiertes Testen mit der von Suse entwickelten Testplattform OpenQA [6] abzufangen – was nicht immer gelingt.

Zur Rückkehr zu einem funktionierenden Systemzustand genügt es, ihn im Bootscreen unter Start Bootloader from Readonly Snapshot auszuwählen und zu testen, welcher Snapshot noch fehlerfrei funktioniert. Ein Ausführen von snapper rollback macht den gewünschten Status nach einem Reboot erneut zum Normalzustand. Oft beheben die Entwickler das Problem in ein bis zwei Wochen. Ein anschließendes Upgrade führt dann zu einem aktuellen und gleichzeitig fehlerfreien System.

Ins Rollen gebracht

Als der damals bei Suse angestellte Kernel-Entwickler Greg Kroah-Hartman im Jahr 2014 Tumbleweed aus der Taufe hob, war das Rolling-Release-Konzept in Form von Arch Linux längst verbreitet (Abbildung 6). In der Wahrnehmung vieler Linux-Anwender handelt es sich dabei um eine Distribution, die keinen Installer mitbringt, sondern die es ihren Anwendern zumutet, sie in Handarbeit via Konsole einzurichten [7].

Abbildung 6: Typisch für Arch Linux ist die unveränderte Auslieferung von Software in der von den Originalautoren vorgesehenen Form, hier der KDE-Desktop, und die unverzichtbare Textkonsole.

Seit einiger Zeit enthält das Arch-Linux-Installationsmedium jedoch einen pseudografischen konsolenbasierten Installer, der sich abgesehen von seiner schlichten Optik vom Bedienprinzip des OpenSuse-Leap-16-Setups wenig unterscheidet. Der Anwender muss lediglich die Einträge im linken Menüunterfenster durchgehen. Für ein funktionierendes Arch-Linux-System ist es dank dieses Installers nicht mehr nötig, die Festplatte auf der Konsole zu partitionieren oder den Bootloader manuell einzurichten.

Der Arch-Linux-Installer richtet inzwischen auf Wunsch sogar Snapper für Btrfs-Systempartitionen ein. Automatisch angelegte Snapshots vor jeder Softwareinstallation nimmt das System aber noch nicht vor. Das klappt erst nach der Installation des Pakets snap-pac. Doch das simple Rollback per snapper rollback – der eigentliche Zweck von Snapper – funktioniert in der vom Arch-Linux-Installer eingerichteten und im Wiki des Projekts vorgeschlagenen Konfiguration nicht.

Die Stärke von Arch Linux liegt in der weitgehend konkurrenzlosen Aktualität der in seinen Repositories mitgelieferten Software. Viele Programme stehen für Anwender schon einen Tag nach Erscheinen einer neuen Version als Paket bereit. Zudem legt Arch Linux seinen Anwendern nahe, selbst Softwarepakete zu bauen. Das wichtigste Alleinstellungsmerkmal der Distribution ist das Arch User Repository oder kurz AUR (Abbildung 7). Es liefert viele Tausend nicht von den Entwicklern, sondern von Anwendern erstellte Paketbausteuerdateien (PKGBUILDs), die der simple Aufruf von makepkg in ein Binärpaket umwandelt.

Abbildung 7: Das AUR enthält sogar PKGBUILDs für die offizielle App für die Onlinefunktionen des deutschen Personalausweises und die freie Alternative Open eCard.

Für den Anwender bedeutet das CPU-intensive Kompilieren von Paketen auf dem eigenen Rechner allerdings zusätzlichen Aufwand und ist nicht immer von Erfolg gekrönt. Doch mit dem AUR hält Arch Linux in Kombination mit den etwa 120 000 fertig ausgelieferten Paketen in Sachen Softwarevielfalt mit der ansonsten ungeschlagenen Debian/Ubuntu-Welt mit.

Dass die zusätzliche Software nicht in Form direkt installierbarer Pakete vorliegt, hat einen guten Grund: Binärpakete sind Blackboxes. Gewöhnliche Anwender können nicht nachprüfen, ob sie tatsächlich (nur) enthalten, was der Name verspricht. Bei PKGBUILDs aus dem AUR handelt es sich dagegen um Shell-Skripte, deren Inhalt viele Linux-Anwender nachvollziehen können. Außerdem funktionieren die Build-Skripte in der Regel selbst dann noch, wenn Arch Linux Bibliotheken aufgefrischt hat, während man Binärpakete neu erstellen müsste.

Das Paketbausystem von Arch Linux lässt sich mit dem OpenSuse Build Service vergleichen. Hier wie dort steuern Anwender Inhalte in Form von Paketen bei, die über den Umfang der offiziellen Repositories hinausgehen.

In der Arch-Linux-Community sehen viele den projekteigenen Installer als zeitsparendes Hilfsmittel für erfahrene Anwender, die von ihm automatisierte Arbeitsschritte vorher schon per Hand ausgeführt haben. Mittlerweile sind jedoch auch Arch-Linux-Derivate entstanden, die selbst weniger versierten Anwendern eine Kombination aus brandaktueller Software und guter Stabilität zugänglich machen.

Weniger hartgesotten

Das Arch-Linux-Derivat Manjaro etwa bietet einen GUI-Installer und erleichtert die Softwareinstallation mit einem grafischen Programm (Abbildung 8). Der Manjaro-Settings-Manager erspart es Anwendern, die zugehörigen Konfigurationsdateien zu suchen und sich mit der Bedeutung der einzelnen Einträge auseinanderzusetzen. Ein Werkzeug zur Hardwareerkennung erleichtert die Installation insbesondere der Nvidia-Treiber. Die Distribution übernimmt außerdem von Ubuntu das Konzept der vorinstallierten und fertig eingerichteten Desktops [8].

Abbildung 8: Das Arch-Linux-Derivat Manjaro bringt eine grafische Software inklusive Update-Funktion mit.

Das wichtigste Alleinstellungsmerkmal von Manjaro besteht darin, dass es die Arch-Linux-Pakete – Sicherheitsfixes ausgenommen – zwei Wochen verzögert ausliefert. Nach dieser Periode im Einsatz unter Arch Linux sollten viele Regressionen bereits behoben sein. Manjaro-Anwender bekommen damit viele der bei der Softwareentwicklung unvermeidlichen Fehler gar nicht zu sehen.

OpenSuse-Anwender finden ein ähnliches Konzept bei Slowroll [9], das vier wöchentliche Snapshots aus Tumbleweed zu einem monatlichen Refresh zusammenfasst, Sicherheitsaktualisierungen ebenfalls ausgenommen. Slowroll gilt zwar als Beta-Software, doch für Anwender stellt der Einsatz kein großes Risiko dar. Es handelt sich bei einem solchen System praktisch nur um ein bis vier Wochen hinterherhinkendes Tumbleweed. Daher genügt ein Austausch der Software-Repos, um eine Slowroll-Installation in ein Tumbleweed-System zu verwandeln und umgekehrt.

Einen weniger radikalen Ansatz, um Arch Linux für einen weiteren Benutzerkreis zu erschließen, verfolgt das in letzter Zeit auf Distrowatch.com viel beachtete EndeavourOS [10]. Es übernimmt die Arch-Linux-Repositories unverändert und fügt lediglich eine eigene Paketquelle mit ein paar für Einsteiger nützlichen Tools hinzu. Wie OpenSuse startet EndeavourOS (Abbildung 9) nach dem Hochfahren in eine Begrüßungs-App, die allerdings deutlich mehr Funktionen und Informationen bietet als das Suse-Gegenstück.

Abbildung 9: EndeavourOS Live startet einen grafischen Installer und ermöglicht die Auswahl eines Repository-Mirrors sowie die Partitionierung der Festplatte mit grafischen Programmen.

In Stein gemeißelt

Die neuesten Mitglieder des OpenSuse-Ökosystems stellen die immutablen (unveränderlichen) Desktop-Distributionen Aeon und Kalpa dar. Sie hängen ihre Systempartitionen im Normalbetrieb schreibgeschützt ein. Dabei setzen sie wie Leap und Tumbleweed auf das OpenSuse-Anwendern wohlbekannte Prinzip der Btrfs-Snapshots. Allerdings erfolgen Aktualisierungen und sonstige Veränderungen nicht am aktuell laufenden Systemabbild. Stattdessen entsteht dafür ein neuer Snapshot, den erst ein Reboot aktiviert und wieder read-only einhängt.

Bei OpenSuse hat dieses Konzept für eigenständige Desktop-Fassungen nach Vorarbeiten unter dem Namen MicroOS Desktop erst 2023 Fahrt aufgenommen, während die Installationsoption Transaktionaler Server im Leap-Installer schon seit 2018 existiert. Sie richtet allerdings nur ein beschränktes Serversystem ohne grafische Umgebung ein.

Fedora dagegen brachte bereits 2018 das Silverblue [11] genannte Fedora-Pendant zu OpenSuse Aeon heraus. Anders als Aeon liegt dieses Immutable-System mit Gnome-Desktop (Abbildung 10) längst in einer stabilen Fassung vor. Ein gleich aufgebautes KDE-Desktop-System nennt sich Kinoite [12]. Darüber hinaus bietet Fedora noch die Desktop-Flavors Budgie, Cosmic und Sway an.

Abbildung 10: Auf den ersten Blick unterscheidet sich Fedora Silverblue nicht von der normalen Workstation-Fassung, doch die Root-Partition ist schreibgeschützt eingehängt.

OpenSuse Aeon liegt schon seit Jahren als Release Candidate vor, was im IT-Jargon für eine finale Testrunde einer letztlich fertigen Software steht. Kalpa, ein containerbasierter KDE-Desktop, gilt immer noch als experimentell, und es waren in letzter Zeit keine Fortschritte zu erkennen. Das ist schade, denn OpenSuse hat mit dem System aus Btrfs-Snapshots, das den Immutable-Distributionen zugrunde liegt, viel Erfahrung. Das Grundsystem von Aeon und Kalpa sollte keine Probleme bereiten.

Ein sich selbst aktualisierendes, im Fehlerfall durch automatische Rückkehr zum letzten Snapshot selbstheilendes System wäre wie geschaffen für Windows-Umsteiger, von denen es Ende 2025 sicher einige gibt. Ob es wegen der ungewissen Zukunft von Einmannprojekten ohne Unterstützung von (Open)Suse guten Gewissens zu empfehlen ist, steht auf einem anderen Blatt.

Fazit

OpenSuse Leap 16.0 erscheint durch die verringerte Anzahl an mitgelieferten Paketen im Vergleich zu besser ausgestatteten Distributionen wie Fedora oder Ubuntu weniger attraktiv. Dagegen punktet Tumbleweed mit einer sinnvollen Kombination von per Rolling Release aufgefrischter Software und einem System zum Zurückdrehen problematischer Updates. Statt zu den Einmannprojekten der vom Konzept her bestens für Windows-Umsteiger geeigneten immutablen OpenSuse-Desktops Aeon (Gnome) und Kalpa (KDE) sollten Anwender lieber zu Fedora Silverblue oder Kinoite greifen. (uba)