Kommentar: Die Tücken von Rolling-Release-Distributionen

Wenn ich über Rolling-Release-Distributionen und den Wartungsaufwand von Linux schreibe, kommen zuverlässig Kommentare, dass das alles kein Problem sei und man selbst seit x Jahren mit der Distribution y ohne Neuinstallation arbeitet. Kann sein. Muss es nicht. Vor allem aber fehlt es an Planbarkeit.

Ende Februar hat KDE das lange angekündigte Mega Release veröffentlicht. Dabei handelt es sich um die gleichzeitige Aktualisierung des Plasma-Desktops auf Version 6 und der nun auf Qt 6 basierenden Applikationssammlung. Im Gegensatz zu früheren Versionssprüngen ist KDE hier ein grundsolides Release gelungen. Es gibt sinnvolle Verbesserungen, keine großen Brüche, keine signifikanten Funktionseinbußen und vor allem keine riesigen Buglisten. Hier hat KDE definitiv dazugelernt.

Für ein paar Tage war dann Ruhe. Schließlich mussten die Entwickler erst testen, dann bauen und die QA musste auch noch drüber laufen. Aber letzte Woche wurde Plasma 6 und alles was dazu gehört in openSUSE Tumbleweed verteilt. Das geschah ohne Zeitplan und ohne große Ankündigung. Wem das gerade nicht in den Kram passte, weil er das System gerade dringend für einen Arbeitsprozess oder ähnliches benötigte, der konnte ab diesem Tag nur noch das Aktualisieren und Neuinstallieren von Paketen einstellen. Sicherheitsupdates kommen dann natürlich auch nicht mehr. Rolling Release heißt eben auch unweigerlich mitrollen.

Das Update selbst ruckelte sehr stark. Das berichten viele Nutzer. Die Probleme – das möchte ich ausdrücklich betonen – lagen nicht bei KDE, sondern bei der Update-Routine von openSUSE. Der eigentliche Vorgang über zypper brach bei Anwendern mit laufender Wayland-Session mittendrin ab. Wer dann nicht auf TTY wechselte und dort das Update beendete, hatte ein inkonsistentes System und landete bestenfalls nach einem Neustart wieder bei Plasma 5. Größere Probleme waren dann noch fehlende Übergänge bei SDDM, weshalb hier entweder die Konfigurationsmöglichkeit verloren ging oder gleich alle Pakete. Die automatische Entsperrung von KWallet über PAM funktionierte nicht mehr und die Desktopsuche Baloo hing in einem Mix aus 5 und 6 fest. Hinzu kamen kleinere und größere Probleme mit einzelnen Programmen. Je nach Einschätzung des Aufwandes konnte man sich dann entweder einzeln auf Fehlersuche begeben (wobei ein Unfallauto immer ein Unfallauto bleibt) oder neu installieren. Das Zurückspringen über Snapper und ein erneuter Versuch brachte letztlich meist ein ähnliches Ergebnis, ist also nicht die Lösung.

Jetzt wird natürlich wieder jemand schreiben, mit der Distribution xyz wäre das nicht passiert, man hätte nur dies und jenes beachten müssen usw. usf.

Aber meiner Ansicht nach zeigt diese fehlerhaften Aktualisierung wieder verschiedene Punkte:

  • RR-Verteilungen sind nur für den unkritischen privaten Gebrauch geeignet. Solche Großupdates sind nicht planbar, nicht vorhersehbar und nicht verschiebbar. Das macht RR-Distributionen für den produktiven Einsatz ungeeignet.
  • Die klassische Paketverwaltung mit ihren systemimmanenten Problemen ist am Ende ihres Entwicklungszyklus angelangt. Bessere Übergänge bei openSUSE hätten manches verhindert, aber das System aus tausenden Paketen mit fein definierten Abhängigkeiten und Überleitungen ist ein fehleranfälliges Konstrukt. Ein festes Image aus Basissystem und Desktop plus Anwendungsprogrammen hätte diese Probleme beim Update nicht verursacht.
  • Linux ist und bleibt wartungsintensiver als vergleichbare Systeme.
Cruiz
Cruizhttps://curius.de
Moin, meine Name ist Gerrit und ich betreibe diesen Blog seit 2014. Der Schutz der digitalen Identität, die einen immer größeren Raum unseres Ichs einnimmt ist mir ein Herzensanliegen, das ich versuche tagtäglich im Spannungsfeld digitaler Teilhabe und Sicherheit umzusetzen. Die Tipps, Anleitungen, Kommentare und Gedanken hier entspringen den alltäglichen Erfahrungen.
  1. Produktive Systeme würde ich immer so updaten, dass ich ein Rollback oder besser ein gespiegeltes System habe, auf das ich im Notfall ausweichen kann. Ich selbst verwende letzteres auf meinen privaten und berufliche Rolling Release-Systemen.
    Ein klassisches Windows oder Linux-Update ist auch immer ein Risiko für jeden produktiven Einsatz und es müssen Backuplösungen vorhanden sein, bzw. die Updates für den spezifisch geplanten Einsatz sehr gut getestet werden bevor sie ausgerollt werden. Ich sehe hier eher ein grundsätzliches Problem der Softwareaktualisierung als ein spezifisches Problem von Rolling Release-Distributionen.
    Nicht umsonst benutzten die US-Atomstreitkräfte immer noch Disketten ;-).

    • Und was mache ich dann? Ein erneuter Durchlauf endet ja wieder mit dem gleichen Resultat und längere Zeit nicht aktualisieren kann man sich wegen offener Sicherheitslücken nicht erlauben.

  2. Ja, RR-Distributionen würde auch ich nur privat verwenden, eine solche spontane Versionsänderung kann kein Admin “seinen” Anwendern zumuten. Anwender sind was das betrifft konservativ und wollen mehrheitlich keine Änderungen an der Software.

    Aber dass klassische paketbasierte Distributionen an ihrem Ende sind sehe ich überhaupt nicht so auch wenn ich sofort glaube dass ein Desktopupdate im laufenden Betrieb zu einigen Fehlern führen kann, es ist einfach nicht möglich hier alle Varianten im Vorfeld zu testen. Ich glaube dieser “Docker”-Ansatz mit festem Basisimage scheint nur auf dem ersten Blick sinnvoll und führt zu Problemen die man aktuell nicht sieht weil so nicht gemacht wird.

    • Subjektiv ist er deutlich geringer. Es fallen halt einige Fehlerquellen im Bereich der Pakettransitionen weg. Allerdings ist die Auswahl momentan halt noch sehr klein. Fedora Atomic Desktop ist da ziemlich alleine auf weiter Flur. OpenSUSE MicroOS ist noch nicht ausgereift, deshalb bin ich (vorerst) auch zu Tumbleweed zurück.

Kommentieren Sie den Artikel

Ergänzungen dienen der Diskussion über die Inhalte des Artikels. Nachfragen, Anmerkungen und Ergänzungen sind dezidiert erwünscht. Ergänzungen werden vor der Veröffentlichung moderiert. Wir behalten uns vor Kommentare ohne inhaltlichen Bezug oder abseitige Diskussionen nicht zu veröffentlichen.

Bitte geben Sie Ihren Kommentar ein!
Bitte geben Sie hier Ihren Namen ein

Weitere Artikel