Die neue Linux-Distribution - ein 'Rolling-Release'?

veröffentlicht am 01.05.2020 mit 1326 Worten - Lesezeit: 7 Minute(n) in * LINUX *

Inhaltsverzeichnis

Es könnte so einfach sein: Da wird ein Betriebssystem einmal installiert, ab und an ist ein update fällig, aber im Prinzip läuft und läuft und läuft die Kiste ganz einfach …

Aber die harte Realität sieht anders aus: alle paar Monate bis Jahre ist eine Neuinstallation fällig, wenn man ein sauberes und stabiles System nutzen will. Aber halt - gab es da nicht den Begriff des ‘rolling release’?

Vorbetrachtungen

Echtes Rolling Release

Wikipedia definiert den Begriff so:

Rolling Release (englisch, aus to roll ‚rollen‘ und release ‚Veröffentlichung‘; sinngemäß „laufende Aktualisierung“) ist ein Begriff aus der Softwaretechnik im Bereich der Betriebssysteme und bedeutet, dass eine kontinuierliche Softwareentwicklung vorliegt. Bei einem Betriebssystem, das das Rolling-Release-Prinzip anwendet, gibt es keine Betriebssystem-Versionen, bei denen bei einem Versions-Upgrade eine große Menge an Software auf einmal aktualisiert wird. Die einzelnen Software-Pakete werden vielmehr immerfort aktualisiert.

Mehr dazu hatte ich bereits vor eineinhalb Jahren in einem Beitrag beschrieben.

Die Auswahl

Die Welt der Linux-Distributionen ist vielfältig. Distributionen kommen und gehen, manche sind Nischenprodukte, andere erreichen größere Popularität. Und weil ich im Zweifel froh bin, wenn ich in einer aktiven Community auch mal nachfragen kann, habe ich mich bei der Auswahl auch ein bißchen an DistroWatch und deren Zahlen orientiert. Daraus ergab sich:

Redhat-Umfeld: Fedora aktualisiert alle halbe Jahre, hat man 2 Versionsupdates “verschlafen”, dann ist eine Neuinstallation fällig. Ein echtes Rolling-Release habe ich in diesem Umfeld nicht gefunden.
Debian-Umfeld: bisher hatte ich Linux-Mint im Einsatz. Dort wird aber ausdrücklich beim Versionswechsel eine Neuinstallation empfohlen. Nun gibt es dort auch LMDE, das auf Debian Testing basiert - das wäre ein echtes ‘rolling release’.
In einem Forum las ich mal den provokanten Hinweis:

“Ubuntu ist ein kaputtes Debian, und Mint ist ein kaputtes Ubuntu”

Dafür lief mein Mint aber über viele Jahre sehr stabil, und auch zwei bekennende “DAUs” aus meinem Bekanntenkreis haben keinerlei Problem (und ich muß weniger Support leisten als zu Windows-Zeiten).
Aber warum nicht mal wieder back to the roots und Debian selbst betrachten: Neben dem oben erwähnten Debian Testing gibt es mit Debian Sid eine weitere ‘rolling-release’-Ausgabe. Und dann gibt es noch Siduction, das wiederum unmittelbar auf Debian Sid basiert.
Arch-Linux und Ableger: Wie bei Debian die Distribution LinuxMint versucht, sich auf Neueinsteiger zu fokussieren, so gibt es in der Arch-Welt mit Manjaro einen Ableger, der sich dasselbe Ziel auf die Fahnen geschrieben hat. Und:
Sowohl Arch selbst als auch Manjaro sind von Natur aus ‘rolling-release’-Distributionen
Gentoo: diese Distribution ist zwar rollierend, aber Quelltext-basiert. D. h. jede Anwendung muß zum Zeitpunkt der Installation erst aus dem Quelltext erzeugt/kompiliert werden - das ist zeitaufwendig und aus meiner bescheidenen Sicht nix für Leute, die sich damit nebenbei beschäftigen und eigentlich mit ihrem Rechner andere Aufgaben erledigen wollen.

Die Testkandidaten

Manjaro

Um es kurz zu sagen: das Problem sind die zur Verfügung stehenden Programme. Wer aus der Debian-Welt kommt, der empfindet die Auswahl an Programmen in den Manjaro/Arch Repositories durchaus als eingeschränkt.

Manjaro benutzt den Arch-Paketmanager Pacman, die Pakete sind in verschiedene Repositories (Core, Extra, Community) zugeordnet. Was dort nicht zu finden ist, kann evtl. über das sog. AUR (Arch User Repository) installiert werden, das ist vergleichbar mit den PPAs im Ubuntu/Mint-Umfeld, aber insoweit mühsamer, als es sich vielfach um Scripte handelt, die die Pakete erstmal noch “bauen” müssen.

Einen Vergleich zur Paketverfügbarkeit in den einzelnen Distributionen bietet diese Tabelle:

Erste Spalte: Liste der Pakete aus LinuxMint 18
Zweite Spalte: markiert, wenn das Paket nicht aus den normalen Paketquellen zur Verfügung steht
Dritte Spalte: falls verfügbar, dann das Paket in Manjaro aufgelistet
Vierte Spalte: bezeichnet das Manjaro-Repository
Fünfte Spalte: falls verfügbar, dann das Paket in Siduction aufgelistet
Sechste Spalte: Kurzbeschreibung des Pakets

Zu guter Letzt: daß der Calamares-Installer, der auch hier (wie in Siduction auch) verwendet wird, die Benutzerrechte verwürfelt, das habe ich erst bei der nachfolgenden Installation von Siduction gemerkt - das Problem ist aber auch hier vorhanden.

Siduction

Hier bin ich schon bei der Installation gescheitert - dazu gibt es eine eigene Artikelreihe. Damit war die Distribution raus aus der Betrachtung.

Debian Sid

Die Installation mit dem Debian-Installer verlief problemlos, auch die Benutzer-Rechte im Home-Verzeichnis stimmten - im Gegensatz zu Siduction mit dem Calamares-Installer.

Die Probleme ergaben sich erst im weiteren Verlauf, Stand Mitte April 2020 nach etwas mehr als einem Vierteljahr, sieht das so aus:

selbsttätig deinstallierte Programme:
- git
  nach irgendeinem Update/Upgrade von der Platte verschwunden …
- scilab
  nach irgendeinem Update/Upgrade von der Platte verschwunden …
defekte Pakete/Programme:
- ebook-Reader
  .epub-Dateien lassen sich aus dem Dateimanager (Nemo) nicht öffnen. Calibre oder der ebook-Reader lassen sich aus dem Menü ebenfalls nicht öffnen. Versucht man Calibre aus dem Terminal zu öffnen, kommen etliche Fehlermeldungen:
```
~$ calibre
Traceback (most recent call last):
  File "/usr/bin/calibre", line 20, in <module>
    sys.exit(calibre())
  File "/usr/lib/calibre/calibre/gui_launch.py", line 73, in calibre
    main(args)
  File "/usr/lib/calibre/calibre/gui2/main.py", line 529, in main
    app, opts, args = init_qt(args)
  File "/usr/lib/calibre/calibre/gui2/main.py", line 114, in init_qt
    app = Application(args, override_program_name=override, windows_app_uid=MAIN_APP_UID)
  File "/usr/lib/calibre/calibre/gui2/__init__.py", line 875, in __init__
    raise RuntimeError('Failed to load the progress_indicator C extension, with error: {}'.format(pi_err))
RuntimeError: Failed to load the progress_indicator C extension, with error: PyCapsule_GetPointer called with incorrect name
```
- sFTP (hier mittels FreeFileSync)
  Greife ich über Netzwerk auf einen anderen Rechner mit NTFS-Platte zu, auf dem ebenfalls Debian Sid läuft, dann können die Zeitstempel der über sftp übertragenen Dateien auf dem Zielrechner nicht aktualisiert werden (funktioniert, wenn auf diesem zweiten Rechner Debian Buster läuft)
- unrar
  führt bei manchen Archiven zu beliebig wachsenden Dateien beim “auspacken”, eine nur wenige Kilobyte große Textdatei in einem Archiv wächst bis zum Abbruch des Programms, die kann dabei locker auf einige GB anwachsen.
- Farbprofil für Monitor läßt sich nicht installieren:
  In den Systemeinstellungen unter ‘Farbe’ gibt es keine Geräte-Einstellmöglichkeit für den/die Monitore und folgerichtig beschwert sich DisplayCAL bei dem Versuch, ein Profil für einen Monitor zu hinterlegen, mit einer Fehlermeldung.
  Übrigens: mit Debian Buster sieht das so aus - da gibt es einen Monitor:

Schlußfolgerungen

Nachdem also mit dem Debian Sid in Reinform so nicht (mehr) zu arbeiten war, bin ich zu folgender Überlegung gelangt:

Aufgrund des Entwicklungs-Ablaufs in Debian ist natürlich Debian Sid die instabilste “Abteilung”, aber auch die Neueste. Das hat aktuelle Software, aber auch Fehleranfälligkeit zur Folge.
Nächste Stufe des “Paketdurchlaufs” ist dann Debian Testing. Hier sollte es deutlich stabiler zugehen, Diskussionen in Foren zeigen aber, daß dort ab und an auch die aus Sid “durchgerutschten” Fehler “stabiler”, also länger hängen bleiben könnten.

Hier endet aber dann der ‘rolling-release’-Ansatz, alle 2 Jahre oder so wird Testing eingefroren und das nächst stabile Release ausgekoppelt. Daran ändert sich dann eben auch 2 Jahre wieder nichts.
Im Hinblick auf solche schnell-lebigen Programme wie darktable oder QMapShack, aber auch in Situationen wie PSD2 mit den Auswirkungen auf Finanzsoftware im letzten Jahr, ist das natürlich ein Nachteil.

In manchen Fällen können hier die sog. Backports helfen: aktuelle Versionen eines Programms werden, soweit es die abhängigen Programmbibliotheken zulassen, auf den letzten älteren stabilen Stand zurückportiert, also dort verfügbar gemacht. Das ist z. B. bei QMapShack, gnucash und aqbanking der Fall.

Also werde ich zunächst mit einem - wie ich es nenne - “semi-rolling-release” arbeiten.
Und deshalb sehen - nach einer Neuinstallation (die zum Glück sehr unaufwändig von statten geht) - meine Debian-Softwarequellen jetzt so aus:

~$ inxi -r
Repos:
  Active apt repos in: /etc/apt/sources.list 
  1: deb http://deb.debian.org/debian/ buster main contrib non-free
  2: deb-src http://deb.debian.org/debian/ buster main contrib non-free
  3: deb http://security.debian.org/debian-security buster/updates main contrib non-free
  4: deb-src http://security.debian.org/debian-security buster/updates main contrib non-free
  5: deb http://deb.debian.org/debian/ buster-updates main contrib non-free
  6: deb-src http://deb.debian.org/debian/ buster-updates main contrib non-free
  7: deb http://deb.debian.org/debian buster-backports main
  8: deb [ trusted=yes ] file:///var/local/repository ./

Und nun lasse ich erstmal wieder einige Zeit ins Land gehen, um abzuwarten, wie die Langzeiterfahrungen aussehen - und wie das nächste Versionsupdate vor dem Hintergrund des oben Gesagten gelingt. Weil diese nächste Version aber aus einem ‘rolling release’ abgeleitet wird, bin ich hier zuversichtlich - werde aber sicherlich berichten.

Und wenn alle Stricke reißen und ich doch was Neueres brauche … dann kann ich immer noch “vor der Zeit” auf Testing aktualisieren …