Mo, 3. Oktober 2022, Fabian Schaar
Hinweis: Das ist ein Meinungsartikel.
Die Auswahl einer GNU/Linux-Distribution ist von vielen Faktoren abhängig - das ist wohl so ziemlich allen Teilen der Leserschaft hier klar. Manchmal scheinen die Unterschiede nur marginal, manchmal sind sie gravierender. Eine Entscheidung, um die offensichtlich so einige nicht herum kommen, ist die zwischen einem statischen oder rollenden Distributionsmodell.
Welche Distro rollt am angenehmsten?
Mit Folge 16 des GLN-Podcasts findet sich einer der vielen interessanten Beiträge zu diesem Thema auf GNU/Linux.ch. Nichtsdestotrotz möchte ich in diesem Text etwas genauer auf die verschiedenen Detailfragen rollender Distros eingehen: Einem subjektiven Vergleich unterziehe ich hier Arch Linux, Void Linux, openSUSE Tumbleweed, Debian Testing und Sid.
Arch Linux - Urvater der rollenden Distributionen?
Wenn es in einer Diskussion um Rolling Releases geht, ist Arch meist der erste Name, der fällt - und das nicht zu unrecht. Arch ist und bleibt extrem aktuell, selbsternannt leichtgewichtig und wirklich gut dokumentiert. Damit bietet die Distribution entscheidende Vorteile, die einem rollenden Veröffentlichungszyklus sehr entgegenkommen.
Die Installation eines Arch-Systems gilt als eine der unkomfortabelsten, wenn man grafische Installationsprogramme wie Calamares oder Ubiquity gewohnt ist. Dennoch halte ich die Installation für einigermassen sinnvoll: Ist es nicht gerade bei rollenden Distros wichtig, sein System zu kennen, zumindest, wenn es um wichtige Aspekte geht?
Vielleicht muss man nicht gleich alles selbst kompilieren, und doch sollte man zumindest einen Überblick über die installierten Pakete haben: Wie soll ich meine kaputte Rolling-Distro reparieren, wenn ich nichteinmal weiß, an welchem Paket es denn nun gelegen hat, dass sich das ganze nicht so benutzen lässt, wie ich das eigentlich möchte.
Distributionen, die auf Arch aufsetzen und einige, angeblich nutzerfreundliche Änderungen vornehmen, sind nach diesem Blickwinkel das genaue Gegenteil: EndeavourOS und Manjaro erfreuen sich höchster Beliebtheit, installieren aber teils Pakete, die bei Leibe nicht 100% der Nutzer/-innen brauchen können.
Wer schon einmal versucht hat, Pipewire unter EndeavourOS durch PulseAudio zu ersetzen, kann mich in diesem Punkt eventuell etwas besser nachvollziehen. Wer um die Ideale freier Software weiss und sich dann die Mengen an vorinstallierter, teilweise proprietärer Software in einer vollständigen Manjaro-Installation anschaut, dem können sich leicht die Zehennägel hochrollen.
Dementsprechend bleibt Arch nicht ohne Grund das unangefochtene Schwergewicht in der Distributionsfamilie, die von der Mutter-Distribution ausgeht.
Ein weiterer Aspekt, den ich an Arch nicht wirklich leiden kann, ist der Paketmanager Pacman -- und schon höre ich die ersten Arch Nutzer/-innen schreien. Ja, Pacman ist verdammt schnell, ja, das verwendete Paketformat mag wesentlich verständlicher sein als deb und RPM zusammen, dennoch: Pacman ist und bleibt verdammt kryptisch, wenn man dpkg- oder RPM-basierte Paketverwaltungen kennt.
Was wäre bitte falsch an 'pacman update' statt 'pacman -Syu'? Warum muss ich erst das halbe Alphabet in die Kommandozeile hämmern, um an die Funktionalität eines 'apt autoremove && apt autoclean' heranzukommen?
Was spart am Ende mehr Zeit: Eine kryptische Paketverwaltung, die ich mir vor der ersten Nutzung ersteinmal mehrere Stunden aneignen muss, nur weil die Pacman-Entwickler/-innen anscheinend auf Kommando-Neologismen stehen oder eine leicht zu erlernende Paketverwaltung, die pro Kommando vielleicht fünf Sekunden länger braucht?
Erschwerend kommt noch hinzu, dass Arch nicht wirklich für GNU/Linux-Anfänger geeignet ist: So lange die Einsteigerdistros in der Debian-Familie angesiedelt sind, vielleicht in Einzelfällen auch in der RPM-Welt vertreten sein mögen, werden sich Einsteiger zunächst mit apt, zypper oder dnf vertraut machen - Pacman mag noch so technisch weiterentwickelt sein, schlussendlich könnte man an der eigenen Kryptifizierung scheitern.
Ich möchte Arch hier keinesfalls schlecht reden: Eine Arch-Installation nach klassischer Vorgehensweise halte ich für sehr lehrreich, da man früher oder später auf Paketsuche gehen muss, um einen vollständigen Desktop zu erhalten -- dahingehend kann man eigentlich nur dazulernen.
Was mich allerdings stört, ist eine hohe Abhängigkeit, die sich auch bei trivialeren Paketen offenbart: Eine hohe Abhängigkeit vom AUR. Und schon habe ich wieder viele, viele Leser/-innen gegen mich aufgebracht:
Die einen halten das AUR für die Krönung aller Third-Party-Repos, andere für einen Sumpf aus teilweise unsicheren Paketen. Ich verweise hier mal auf einen Pro-Linux Artikel mit dem bezeichnenden Titel "Malware im Arch-User-Repositorium AUR gefunden".
Das mag ein Einzelfall gewesen sein; und doch zeigt er, dass alle Nutzer/-innen des AUR oftmals auf sich allein gestellt sind. Wer die PKGBuild-Skripte nicht liesst, ist potenziell selbst schuld an dem Schadcode, der auf das eigene System gelangen könnte -- ich wollte es nur mal gesagt haben.
Das AUR ist eben nicht das Allheilmittel, sondern wie so vieles ein zweischneidiges Schwert, auf der einen Seite unfassbar nützlich, auf der anderen potenziell gefährlich.
Arch bleibt eine tolle Distro; vielleicht muss man aber überdurchschnittlich viel wissen, was man tut, wenn man sich darauf einlässt.
Void Linux: Alles anders??
Eine weitere, nicht derartig bekannte, allerdings wirklich interessante Distribution ist Void Linux. Diese wurde von einem ehemaligen NetBSD-Maintainer ins Leben gerufen und war ursprünglich nur als Testumgebung für den neu entwickelten XBPS-Paketmanager konzipiert, ist heute aber eine ernstzunehmende rollende Distro, die Stabilität über Aktualität stellt.
Der bereits erwähnte Paketmanager XBPS hat es in sich: Der ist unfassbar schnell, möglicherweise sogar schneller als Pacman. Grundlegend gibt es aber nicht den einen Paketmanager, stattdessen ist XBPS eher eine Sammlung aus verschiedenen Einzelkomponenten, die zusammen eine runde Paketverwaltung ermöglichen:
Grundlegend wichtig sind beispielsweise die Komponenten xbps-install, xbps-remove und xbps-query, die durch dedizierte man-Pages und help-Ausgaben eine angenehmere Lernkurve ermöglichen. Doch nicht nur in diesem Aspekt ist Void anders:
Statt auf systemd setzt Void auf das flinke runit; diejenigen, die sich mit systemd wohlfühlen, müssen sich dahingehend natürlich umgewöhnen.
Was die Installation angeht, ähnelt der void-installer einem klassischen Slackware-Setup und erinnert ausserdem grob an die Installationroutinen von BSD-Systemen. Der Installer mag zwar einfacher sein als eine Arch Linux-Installation ohne archinstall, perfekt ist das System am Schluss aber auch nicht.
Meiner Erfahrung nach, merkt man Void an, dass die Distribution den Nutzer auffordert, die Dokumentation zu lesen -- und diese ist tatsächlich sehr gelungen und lesenswert. Trotzdem sind es die kleinen Details, die Void als Hauptsystem immer etwas umständlich machen:
Wie gesagt, dass sind nur Kleinigkeiten und trotzdem nervt es, wenn sich die X11-Tastaturbelegung nur über eine Konfigurationsdatei ändern lässt, die in der Dokumentation nichteinmal erwähnt wird:
Hier mal eine kleine Hilfestellung; um beispielsweise eine de_nodeadkeys-Belegung einzustellen, muss die Datei /etc/X11/xorg.conf.d/20-keyboard.conf erstellt, und wie folgt angepasst werden:
Section "InputClass"
Identifier "keyboard"
MatchIsKeyboard "yes"
Option "XkbLayout" "de"
Option "XkbVariant" "nodeadkeys"
EndSection
Grundsätzlich ist das natürlich kein Problem, allerdings halte ich so etwas für essentiell wichtig. Essentielle Informationen möchte ich eigentlich nicht auf Reddit sondern in einer offiziellen Dokumentation finden. Sollte ich den Abschnitt übersehen haben, freue ich mich, korrigiert zu werden.
Eine weite nervige Angewohnheit von Void ist der Standard-Display-Manager LXDM, der mit der Xfce-Ausgabe mitinstalliert wird: Leider verhindert dieser das Auswählen eines einheitlichen Mauszeiger-Themes - ebenfalls eine Kleinigkeit, trotzdem nervig.
Möchte man dann auf den üblicheren LightDM umsteigen, muss man erst den LXDM-Service aus /var/service löschen, um dann den symbolischen Link für LightDM dort anzulegen. Schon ein Wechsel auf LightDM würde die Nutzerfreundlichkeit dahingehend erhöhen.
'Dann nimm doch die minimale Basis-ISO!', höre ich die ersten anraten; das habe ich auch probiert, nur ist diese leider wirklich, wirklich rudimentär. Wer eine Basis-Installation von Arch oder Debian kennt, weiss, was eine standardmässige minimale Installation ist - wer eine Basisinstallation von Void ausprobiert, wird seinen Meister finden:
Es fängt bei meiner Hardware leider schon bei der Installation an: Die Einrichtung der WLAN-Verbindung über den Installer funktioniert nicht. Halb so wild, mag man denken, dann macht man das halt über die Kommandozeile.
Tja, schön wär's: Nutzerfreundliche Kommandozeilen-Tools wie etwa iwd, was die Netzwerkeinrichtung über die Konsole wirklich leicht macht, gibt es bei Basis-Void nicht; hier gibt es nur wpa_supplicant und wpa_passphrase. Naja, wenigstens etwas.
Dann muss man die Konfiguration eben darüber vornehmen und die Verbindung in die entsprechenden Textdateien eintragen. Wie bitte, es ist kein Texteditor ausser vi vorinstalliert, und der funktioniert auch nur halbgar? Schade.
Dann wünsche ich viel Spass und Geduld beim Eintragen von Konfigurationen über echo-Weiterleitungen. Und aus eigener Erfahrung kann ich sagen: Geduld wird man brauchen, per default ist diese Konfiguration eher nervenaufreibend als irgendetwas anderes.
Wenn das System allerdings einmal läuft ist es sehr, sehr angenehm, gerade, wenn man die nicht ganz so rudimentäre Xfce-ISO genommen hat. Wer aber ein rollendes System sucht, das sich nach üblichen Standards aufsetzen lässt, wird vermutlich kein Freund von Void werden.
Es ist und bleibt auch eine Geschmackssache, mit welcher Geschwindigkeit ein System rollen soll: An der Bleeding-Edge bewegt sich Void nicht wirklich. Beispielsweise steht Inkscape noch bei Version 1.1, obwohl schon im Juli Inkscape 1.2 erschienen ist. Der Linux-Kernel hingegen lässt sich schon in Version 5.19 installieren.
Unterm Strich kann ich Void nur denjenigen empfehlen, die wirklich mal etwas ganz anderes ausprobieren wollen: Dann ist Void wirklich toll. Ausserdem sollte man einen Reddit-Account mitbringen, sonst könnte Void schnell zur Distro mit sieben Siegeln werden.
openSUSE Tumbleweed: Btrfs oder nichts?
Mit openSUSE Tumbleweed findet sich in der RPM-Welt eine vergleichsweise aktuelle und dennoch stabile Rolling Release-Distro. Anstatt die Pakete direkt weiterzuleiten (Arch), ein bis zwei Wochen zurückzuhalten (Manjaro) oder in bestimmten Fällen monatelang auf dem gleichen Stand zu halten (Void), gilt bei Tumbleweed die Factory-First-Policy:
Anstatt in den Tumbleweed-Zweig aufgenommen zu werden, landen neue Pakete zunächst im Factory-Zweig. Die entsprechende Weiterleitung erfolgt dann nach automatisierten Tests relativ schnell, was sowohl Aktualität als auch Stabilität unter marginalen Einschränkungen zu garantieren versucht.
Das klingt natürlich ersteinmal wie das perfekte Rolling Release. Trotzdem sollte man bei Tumbleweed eine spezielle Gewohnheit der Entwicklung beachten: Die Pakete werden in der Regel im Verbund ausgeliefert, das kann im Falle grosser Desktopumgebungen schnell zu sehr, sehr wuchtigen Downloads führen.
Für diejenigen, die statt einer Internetverbindung eine Bambusleitung benutzen müssen, könnte das gegebenenfalls schwierig werden.
Sollte dann aber etwas nicht funktionieren, hält openSUSE einen interessanten Sicherheitsmechanismus bereit, der der Distribution weitgehend als Alleinstellungsmerkmal erhalten geblieben zu sein scheint, auch wenn er sich theoretisch unter anderen Distros umsetzen liesse.
Die Rede ist natürlich von den automatisierten Dateisystemschnappschüssen, die Tumbleweed über das Tool Snapper vornimmt und als Read-only-Snapshots als Booteinträge im GRUB-Bootloader verfügbar macht. So kann nach jedem Update ein älterer Schnappschuss gestarten werden, auf den über ein einfaches Kommando zurückgerollt werden kann.
Dabei gibt es allerdings eine Bedingung: Um die automatisierten Schnappschüsse erstellen zu können, muss openSUSE mit dem Dateisystem btrfs installiert werden; wer das nicht möchte, guckt gegebenenfalls in die Röhre, wenn das System mal kaputt geht:
Sicherlich können bei einem ext4-Dateisystem auch Schnappschüsse erstellt werden, meistens funktioniert das über rsync. So komfortabel wie die btrfs-Schnappschüsse ist das aber nicht wirklich, zumindest, was openSUSE angeht. Dann müsste man vermutlich auf externe Tools wie TimeShift zurückgreifen, die sich allerdings nicht so gut in openSUSE integrieren würden.
Für die meisten ist eine Installation mit btrfs vermutlich kein Problem; auch wenn sich dieses Dateisystem klar von ext4 unterscheidet und teilweise stabiler sein könnte -- schlussendlich kann man vermutlich alles lernen.
Ich hatte mit btrfs ein sehr merkwürdiges Problem, als ich openSUSE zum ersten mal mit diesem Dateisystem auf meiner Hardware installiert habe: Das System ist bei zwei von drei Bootversuchen im GRUB-Bootloader hängen geblieben, was mir mit ext4 noch nie passiert ist.
Mittlerweile hat sich herausgestellt, dass ich die SecureBoot-Option, die openSUSE standardmässig anschaltet, im letzten Abschnitt des YaST-Installers ausschalten muss. Woran das genau liegt, kann ich auch nicht wirklich sagen. Eigentlich habe ich SecureBoot schon auf UEFI-Ebene abgeschaltet.
Eventuell haperte es damals auch nicht an der vermeintlich falschen SecureBoot-Einstellung, sondern am allgemeinen Entwicklungsstand von btrfs. Wie auch immer; bei Tumbleweed scheint man sehr stark auf btrfs zu setzen.
Leider habe ich bis heute noch keine Option gefunden, über zypper Pakete unabhängig von den Dateisystem-Schnappschüssen zurückzurollen, wie es beispielsweise mit Arch über den Pacman-Cache möglich wäre. Vermutlich würde das aber ohnehin in einem Desaster enden, da grosse Paketgruppen bei Tumbleweed häufig als geschnürte Gesamtpakete ausgeliefert werden.
In meiner persönlichen Wahrnehmung sind mir Distributionen, die dediziertes Zurückrollen von Paketen erlauben lieber. Ein weiterer Kritikpunkt ist die teilweise stark veraltete oder fehlende Dokumentation, verschiedener Teile des Systems.
Die hier genannten Argumente bleiben eine subjektive Auffassung, womit ich zur letzten Distribution in diesem Beitrag kommen möchte.
Debian bleibt mein Favorit
Schon die Zwischenüberschrift macht deutlich: Dieser Abschnitt ist der mit Abstand subjektivste dieses Vergleichs: Nachdem ich in den vergangenen Monate wirklich viele Distributionen ausprobiert habe, von denen ich in diesem Beitrag nur einen Bruchteil beschrieben habe, bin ich bis jetzt immer wieder zu Debian GNU/Linux zurückgekehrt.
Debian wird häufig mit dem Stable-Zweig assoziiert, bietet daneben aber noch einiges mehr: Der Paketfluss ist im Debian Community-Projekt wie folgt aufgebaut.
Neue Pakete landen bei Debian zunächst im "Experimental"-Zweig; dieser ist keinesfalls für einen produktiven Einsatz empfohlen und nur als Auffangbecken für brandneue Pakete gedacht; so landete beispielsweise die Version 43 des GNOME-Desktops noch am Tag der Veröffentlichung bzw. einen Tag danach im experimentellen Zweig.
Wer Pakete aus diesem Zweig einbinden möchte, muss dies über das relativ umständliche apt-pinning tun, den Aufwand ist es in der Regel allerdings nicht wert: Der "Unstable"-Zweig ist im Gegensatz zu experimental ein vollständiges Paketrepository, dass die aktuellsten stabilen Pakete enthält, die in der Debian-Welt verfügbar sind.
Entgegen dem Namen ist Unstable ('Sid') relativ stabil, da besonders instabile Pakete durch Experimental zurückgehalten werden. Was die Stabilität angeht ist er am ehesten mit dem Tumbleweed-Zweig von openSUSE vergleichbar, auch wenn die Pakete hier nicht als grosse Batzen eintreffen sonder eher Stück für Stück ihren Weg in die Distribution finden.
Debian Sid bildet ausserdem die Basis für die Derivate Ubuntu und Siduction. Wer Debian Sid installieren möchte, muss entweder von einer stabilen Debian-Installation upgraden, das Upgrade von einem Testing-System vornehmen oder mit der mini-iso über den Experten-Installer installieren.
Das mag etwas umständlich klingen, allerdings machen die Release-Upgrades bei Debian meiner Erfahrung nach keine Probleme, lediglich einige Konfigurationsdateien können sich beim Wechsel von Stable bzw. Testing zu Sid ändern, wenn man das denn so möchte (dpkg/apt fragt dann entsprechend nach).
Wem Sid trotz dessen zu instabil ist, kann in der Debian-Familie auch auf den Testing-Zweig setzen. Dieser ist die Vorabversion des nächsten Debian Stable und wird entsprechend dem üblichen, aber nicht konkret festgelegten Debian-Release-Zeitplan schrittweise eingefroren und so zum nächsten Stable. Sobald entsprechende Freeze-Daten feststehen, können sie unter https://release.debian.org/ eingesehen werden.
Wenn sich Testing noch nicht in der Freeze-Phase befindet, kommen Pakete in der Regel nach einem festgelegten Muster im Repository an: Sobald ein Paket zwischen zwei und zehn Tagen ohne Probleme oder kritische Regressionen in Sid war, kann es nach Debian Testing weitergeleitet werden. Wenn es mal sehr dringend ist, kann ein Paket auch sofort aus Sid in Testing weitergeleitet werden. (Siehe auch: https://wiki.debian.org/DebianTesting)
Wer ein rollendes Debian einsetzen möchte, sollte meiner Ansicht nach eher auf Sid setzen, wenn dies ein langfristiger Plan ist: In der Regel kommen wichtige Pakete eher in Sid an und werden eben nicht sofort in Testing weitergeleitet; wichtig bleibt eben ein subjektiver Begriff.
In Einzelfällen können Pakete auch aus Testing rausfliegen, obwohl sie in Sid noch in der gleichen Version verfügbar wären, die schonmal in Testing waren -- das war in jüngster Vergangenheit zum Beispiel bei Audacity der Fall, vor kurzem ist aber eine neue Version in Sid eingetroffen, was mir Hoffnung gibt, dass Audacity in kürze nach Testing migriert wird.
Weitere Beispiele für ein derartiges Verhalten wären momentan die Pakete 'gufw' und 'mate-media'. Dementsprechend ist Testing als momentane Entwicklungsversion anzusehen, die entsprechend der Debian Stable-Veröffentlichungszyklen starken Schwankungen unterliegen kann.
Als rollendes Debian würde ich persönlich daher zu Debian Sid raten, Testing würde ich dann empfehlen, wenn eine stabile Veröffentlichung absehbar ist, und dementsprechend neuere Pakete eingefroren worden sind -- dann verändert sich theoretisch nur noch sehr wenig, wobei schon vor einer neuen stabilen Veröffentlichung die Paketstände angehoben werden können.
Dann sollte in der Datei /etc/apt/sources.list aber statt 'testing' der entsprechende Codename des nächsten Stable eingetragen werden. Möchte man also zum Beispiel kurz vor der Veröffentlichung von Debian 12 die entsprechenden Pakete austesten, sollte der Codename 'bookworm' eingetragen werden, sollte Bookworm seinen Lebenszyklus durchlaufen haben und zu Oldstable werden, könnte man dann 'trixie' eintragen und so weiter.
Dementsprechend würde man dann weitgehend bei einem stabilen System bleiben und einige Wochen eine relativ stabile Vorschau nutzen. Möchte man nicht von Stable aktualisieren, können unter folgender Adresse auch wöchentlich neu erstellte Testing-Snapshots heruntergeladen werden: https://www.debian.org/CD/http-ftp/
Doch auch für Sid-Nutzer/-innen ist Testing wichtig: Über die hold-Funktion von apt können auch in einer Sid-Installation installierte Pakete aus einem zeitweise aktivierten Testing-Repo installiert werden, und dem Namen entsprechend auf einem älteren Versionsstand gehalten werden.
Das mag eine kurzfristige Lösung sein, ist alles in allem aber auch nicht mehr als das. Auf lange Sicht ist die dauerhafte Installation von Testing-Paketen in einem Sid-System, gerade, wenn diese gehalten werden, als vorprogrammiertes Abhängigkeits-Chaos anzusehen.
Wer noch mehr über Debian-Sid-spezifisches Paketmanagement erfahren möchte, sollte sich das ausgezeichnete Siduction-Manual anschauen. Weitere Informationen finden sich auch im Debian Wiki.
Für mich persönlich stellt Debian Sid, auch wenn es nicht unbedingt dafür bekannt ist, eine der besten Rolling-Releases dar: Dpkg/apt ist in Verbindung mit aptitude eine verständliche Paketverwaltung, die ein leichtes installieren von Paketen sicherstellt, darüber hinaus aber auch eine kontrollierte Verwaltung von installierten Paketen aus den umfassenden Debian-Repos ermöglicht. Dahingehend ist man auch nicht von gegebenenfalls unsicheren Repos wie dem AUR abhängig.
Ich verstehe, dass Pacman oder XBPS schneller als apt sind, ich verstehe auch diejenigen, die sich ihre Distributionen dementsprechend aussuchen. Wer allerdings bei Debian bleiben möchte, sollte vielleicht mal einen Blick auf nala werfen, ein Programm, das versucht, flotter als apt zu arbeiten und auf Sid angepasst ist.
Gerade das Zusammenspiel der verschiedenen Repository-Zweige machen Debian für mich zu einem universell einsetzbaren Betriebssystem. ;)
Am Ende möchte ich noch einmal betonen, dass ich mit diesem Beitrag keinesfalls andere rollende Distributionen diskreditieren oder angreifen möchte; jede der hier vorgestellten Distributionen hat eine andere Herangehensweise an das Thema, die dem einen mehr, der anderen weniger gut gefällt.
Ausserdem repräsentieren meine Erfahrungen mit den verschiedenen Distros auch keinesfalls die Projekte an sich; das ist oftmals auch von den eigenen Vorkenntnissen oder der Hardware abhängig.
Wer Arch nutzen möchte, nutzt Arch. Void-Fans bleiben bei Void und openSUSE-Nutzer/-innen bei ihrer Distro. Und ich bleibe vermutlich bei Debian: jede dieser Entscheidungen hat seine Berechtigung.
Beitragsbild: Alextredz, CC BY-SA 4.0, via Wikimedia Commons: https://commons.wikimedia.org/wiki/File:Greasing_bicycle_chain.jpg
