Auf Mastodon ansehen
Meine Lebenserfahrung mit Betriebssystemen kann man in vier Zeitalter einteilen:
- DOS
- Windows
- Ubuntu
- Rolling Distributionen
An die alten Zeiten mit DOS und Windows kann ich mich kaum noch erinnern, und darum soll es nicht gehen. Abgesehen von ersten Linux-Erfahrungen mit SuSE Linux 5.2 aus dem Jahre 1998 (das hiess damals noch so; heute: openSUSE), begann mein richtiger Einstieg in die Linux-Welt mit Ubuntu 6.10 (Edgy Eft) im Jahr 2006.
In den ersten Jahren habe ich jedes Ubuntu-Release installiert. Das war eine spannende Zeit, die von interessanten halbjährlichen Neuerungen geprägt war. In jedem April und Oktober habe ich mich wie ein Kind auf die Verbesserungen und Neuigkeiten im halbjährigen Ubuntu-Release gefreut; das war fast wie Weihnachten.
An diesen Feierlichkeiten habe ich ca. 10 Jahre lang teilgenommen. So ab 2015 wurde mir die Neuinstallation bzw. das Upgraden zu viel, weshalb ich auf den LTS-Pfad eingeschwenkt bin. Ab dann wurde nur noch alle zwei Jahre die Long-Term-Version neu installiert. Nachdem Canonical (die Firma hinter Ubuntu) ab den 2020er Jahren sich mit Eigenentwicklungen immer mehr von der Community entfernt hatte, begann bei mir die Zeit des Distro-Hoppings.
Letztlich bin ich bei der kuratiert-rollenden Distribution Manjaro gelandet. Während all dieser Jahre bin ich dem Gnome-Desktop treu geblieben, obwohl er bei Ubuntu auch einmal anders hiess (Unity). Ob das der Weisheit letzter Schluss war, wage ich zu bezweifeln. Nicht, weil ich Probleme mit Manjaro habe, sondern weil sich die Weltkugel der Linux-Distribution kontinuierlich weiterdreht. Wer weiss, was da noch kommt.
Genug des Vorgeplänkels; nun komme ich zum Thema.
Wie gesagt, wer sich auf ein LTS-Release-Modell verlässt, hat (theoretisch) zwei Jahre lang Ruhe und kann ein stabiles System geniessen: Nicht frickeln, sondern arbeiten ist hier die Devise. Die Release-Zeiten bei LTS-Modellen fallen unterschiedlich lang aus, aber da möchte ich jetzt keine Haarspalterei betreiben. Vorhin habe ich "theoretisch" geschrieben, weil man dennoch in hoher Kadenz mit Updates bespielt wird. Dabei handelt es sich in erster Linie um Sicherheitsupdates, was notwendig und gut ist. Je nachdem, welche Paketformate man verwendet (Flatpak), tritt die Update-Policy ohnehin in den Hintergrund, weil sich die Pakete selbst aktualisieren oder über die Flatpak-Paketverwaltung aus dem LTS-Zyklus ausbrechen.
These 1: LTS-Release-Modelle nerven durch häufige Updates genauso wie Rolling-Release-Modelle.
Obwohl Manjaro einem kuratierten rollendem Modell folgt, rauschen fast jeden Tag Updates herein. Ich fühle da kaum einen Unterschied zu einer reinen Arch-Installation. Die Updates kommen etwas später, aber sie kommen kontinuierlich.
These 2: Egal ob LTS oder Rolling, häufige Updates sind an der Tagesordnung.
Die entscheidende Frage ist, welchen Einfluss das auf die Systemstabilität hat. Rollende Distributionen haben zwei Vorteile:
- Sie beheben spät erkannte Probleme schneller
- Sie halten die Funktionalität auf dem neuesten Stand
Dem gegenüber gibt es Nachteile:
- Sie führen nicht erkannte Probleme ein
- Sie setzen höhere Kenntnisse der Anwender:innen voraus, um diese Probleme selbst zu beheben
Wie sieht der Vergleich zu LTS-Distros aus:
- Anwendungen sind besser/länger getestet, weshalb sie weniger Probleme mit sich bringen
- Spät erkannte Probleme hat man länger am Hals
- Auf neue Funktionen muss man länger warten
These 3: Aufgrund der neuen Paketformate relativiert sich der Unterschied zwischen LTS und Rolling.
Nun stellt sich die Titel-Frage, wie lange Rolling Releases halten. Das Versprechen ist, dass man eine Distribution, die einem Rolling-Release-Modell folgt, nie mehr neu installieren muss. Bisher glaube ich nicht daran. Um das beurteilen zu können, muss man die Installationsdauer einer Distribution messen können. Das macht man mit diesem Befehl im Terminal:
Auf meinem Notebook:
stat -c %w /
2023-11-17 15:04:12.000000000 +0100
Auf meinem Desktop:
stat -c %w /
2023-04-14 08:48:38.000000000 +0200Nun, in beiden Fällen liegt die Installation der Distribution weniger als zwei Jahre zurück, weshalb ein Vergleich mit einem 2-jährigen LTS-Update-Zyklus schwierig ist. Gelegentlich treten bei meinen Rechnern Probleme beim Update auf. In den meisten Fällen liegt es an Abhängigkeiten, die nicht aufgelöst werden können. Darüber habe ich erst neulich geschrieben. Auch heute bockte mein Desktop beim Update von ca. 125 Paketen. Wenn ich mich recht erinnere, waren es Abhängigkeiten von 32-Bit-Grafik-Bibliotheken von systemd. Durch das manuelle Löschen dieser Bibliotheken konnte ich das Problem schnell beseitigen.
These 4: Je länger man eine Rolling-Distribution betreibt, desto häufiger treten Fehler auf.
An dieser Stelle möchte ich die Fähigkeiten des Paketmanagers infrage stellen. Warum ist Pacman (bzw. Pamac) nicht in der Lage, solche einfachen zweistufigen Abhängigkeiten aufzulösen? Hier ist ein fiktives Beispiel:
Der Upate-Prozess kann nicht fortgeführt werden, weil Paket A von B abhängig ist, und Paket B von D1 und D2 benötigt wird.
Wenn ich mich recht erinnere, ist genau das die Kernaufgabe eines Paketmanagers.
Dieser Artikel bietet keine Antworten, sondern stellt Fragen. Was haltet ihr von meinen vier Thesen und wie sind eure Erfahrungen? Verrottet eine Rolling-Release-Installationen mit der Zeit? Schreibt es bitte in die Kommentare.
Titelbild: https://pixabay.com/photos/apples-rotten-apples-rotten-fruits-6694486/
Quellen: stehen im Text
> These 1: LTS-Release-Modelle nerven durch häufige Updates genauso wie Rolling-Release-Modelle. > These 2: Egal ob LTS oder Rolling, häufige Updates sind an der Tagesordnung. LTS löst das Problem der häufigen Updates nicht. Es löst das Problem der häufigen API-, ABI- und Funktionsupdates. Auch LTS-Versionen haben Sicherheitslücken, und die müssen genauso in einem regelmäßigen Patchzyklus integriert werden.
> These 3: Aufgrund der neuen Paketformate relativiert sich der Unterschied zwischen LTS und Rolling. Die These erschließt sich mir nicht aus dem Text drum herum. Was ist damit gemeint?
> These 4: Je länger man eine Rolling-Distribution betreibt, desto häufiger treten Fehler auf. Unterschreibe ich so überhaupt nicht, auch nicht für LTS. Das eine Ding, das Paketmanager eher dazu nötigt, Systeme zu zerstören, ist, wenn "von der Norm abweichende" Paketquellen genutzt werden, zB. Ubuntu PPAs, Debian Testing oder SuSE OBS – alles, was entweder inoffiziell ist oder offiziell nur für bestimmte Dinge angedacht ist – und Pakete darin dann querschießen, da sie keiner QA unterliegen. Diese Repos können auch LTS-Versionen hinzugefügt werden, dann gehen die nach ner Zeit genauso kaputt wie Rollings. Hält man sich an die offiziellen Richtlinien, können auch Rolling-Distros lange halten: Bei Arch bspw., wenn man die Arch Linux News verfolgt und rechtzeitig auf notwendige manuelle Paketchanges reagiert, das AUR konservativ nutzt, keine inoffiziellen Paketrepos benutzt – und Downstream-Repos wie Manjaro, Garuda und CachyOS aus dem Weg geht. :)
> An dieser Stelle möchte ich die Fähigkeiten des Paketmanagers infrage stellen. Warum ist Pacman (bzw. Pamac) nicht in der Lage, solche einfachen zweistufigen Abhängigkeiten aufzulösen?
Verstehe dieses an den Haaren herbeigezogene Argument nicht. Warum der Querschuss gegen Pacman? Funktioniert genauso gut gegen APT. Du hast ein Arch schließlich auch mit einem pacman -S gnome installiert, nicht mit einer Liste an 200 Paketen und Libs. Paketmanager sind dazu da, den Deptree von A bis D2 zu walken und ab D2 alles zu installieren, dabei anzumerken, dass 199 der Pakete eine Abhängigkeit sind – wozu sonst nen Paketmanager nutzen? Für ne super komplizierte DB, die ne Liste an installierten Applikationen speichert?
Alle Paketmanager arbeiten mit den Paketdaten, die sie remote fetchen und dann lokal dahaben. Wenn dort steht A
"> These 3: Aufgrund der neuen Paketformate relativiert sich der Unterschied zwischen LTS und Rolling. Die These erschließt sich mir nicht aus dem Text drum herum. Was ist damit gemeint?" Ich glaube da ist gemeint, dass z.B. Flatpaks unabhängig vom Rest des Systems aktualisiert werden und somit die Flatpaks eher einem RR-Schema folgen.
"> An dieser Stelle möchte ich die Fähigkeiten des Paketmanagers infrage stellen. Warum ist Pacman (bzw. Pamac) nicht in der Lage, solche einfachen zweistufigen Abhängigkeiten aufzulösen?
Verstehe dieses an den Haaren herbeigezogene Argument nicht. Warum der Querschuss gegen Pacman? Funktioniert genauso gut gegen APT. Du hast ein Arch schließlich auch mit einem pacman -S gnome installiert, nicht mit einer Liste an 200 Paketen und Libs. Paketmanager sind dazu da, den Deptree von A bis D2 zu walken und ab D2 alles zu installieren, dabei anzumerken, dass 199 der Pakete eine Abhängigkeit sind – wozu sonst nen Paketmanager nutzen? Für ne super komplizierte DB, die ne Liste an installierten Applikationen speichert?" Das hab ich auch nicht ganz verstanden - benutze halt auch kein Pacman. Manchmal kommt es zu solchen Situationen. Portage (Gentoos Standardpaketverwaltung) kann solche Probleme zum Teil lösen (man kann da auch einstellen, wie weit im Abhängigkeitsbaum Portage runtergehen soll), manchmal gibt es aber auch "circular dependencies", die sich nur durch manuelles Eingreifen lösen lassen - kam bei mir bisher noch nicht so oft vor.
Hallo Christian These 3: Ja, genau das meine ich damit. Fähigkeiten des Paketmanagers: Ich schiesse nicht gegen Pamac oder Pacman. Ich hätte genauso gut einen anderen Paketmanager erwähnen können. Im konkreten Fall ist es mir bei Pacman aufgefallen, deshalb habe ich diesen genannt.
These 3: siehe unten bei Christian.
ich benutzte auf meinem Desktop Rechner seit über 10 Jahren Debian Testing. Dort rauschen auch täglich neue Packete rein aber das System musste ich bis jetzt noch nicht wieder neu installieren. Die aufgetreten Probleme waren sehr selten und behebbar
Hallo Ralf, danke für deinen Beitrag.☕ Auch bei mir war MS-DOS 6 das erste Betriebssystem, und seit einigen Jahren bin ich mit verschiedenen Betriebssystemen unterwegs, die Rolling-Releases sind und ich bin zufrieden.🙂 Ich möchte an der Stelle mal sagen, dass es das Betriebssystem und den Desktop nicht gibt. Weil die Ansprüche an ein System so unterschiedlich sind wie wir Menschen. Wie heißt es so schön, man muss viele Frösche küssen, bis man den Prinzen hat.🐸
Bin VERWIRRT, weil hier eigentlich Debian seit 9.6, also etwa schon seit 2017, gelaufen ist 🤔️
Das Gerät ist ein Netbook von 2011, welches seinerzeit mit "Meego Linux" verkauft worden war, das ich damals aber durch "Lubuntu LTS" ersetzt hatte, meine ich mich zu erinnern.
"Lubuntu LTS" gab es alle zwei Jahre, und im Wechsel mit einem anderen Gerät hatte ich –abwechselnd– "upgegraded", bzw. "neu installiert", d.h. die Installation lief maximal vier Jahre.
So um 2017 herum habe ich dann "Lubuntu" einfach durch Debian ersetzt, und es seitdem nie bereut. Das soll die Verdienste bzw. subjektiv erkannte Vorteile von RR Modellen natürlich keinesfalls relativieren – Debian war/ist für mich einfach ..."konsequent".
Ich hatte bisher mehr Fehler unter LTS-Distributionen wie Debian oder Ubuntu, die vor allem nie behoben wurden, als unter rolling release Distributionen. V.a. KDE hat da einen schweren Stand. Daneben hat gerade unter Ubuntu noch kein einziges Upgrade ohne Fehler stattgefunden - ich musste quasi immer neu installieren. Deswegen setze keine LTS Distributionen mehr ein und empfehle sie auch nicht, außer für Server. Ich würde mir wünschen, ich könnte es. Einzig ElementaryOS hat es verstanden und setzt rein auf Flatpaks und der Desktop + Kern-Apps werden aktuell, während das Basis-System bleibt. Aber diese Distribution hat andere Probleme. Das Konzept bräuchte Debian, dann wäre es (für mich) brauchbar.
Hmmm, was ist dein Problem mit Debian? Ich nutze das seit weit über 20 Jahren in der stable Version und ich kann nicht klagen. Beschreibt mal deine Probleme. Bei mir haben die immer erst mit mixen von Quellen angefangen.
Das Hauptproblem ist die überall stark ansteigende Komplexität. Die Komplexitätsprobleme gibt es beidermaßen bei LTS und Rolling Releases. Der Linux-Kernel hat sich in den letzten 10 Jahren von 25 auf 40 Millionen Code-Zeilen fast verdoppelt. Wie viele (unterschiedliche) Bibliotheken, wie viele (neue) Abhängigkeiten, wie viele Programme gab es vor 10 Jahren im Vergleich zu heute? Diese Komplexität ist wegen unzähligen Schichten und Schnittstellen, hunderten verschiedener Frameworks und wegen dem ständigen Mitschleppen von Altlasten zur Abwärtskompatibilität, teilweise unbeherrschbar geworden. Alles Dinge, die uns eigentlich Verbesserungen und Erleichterungen bringen sollen, uns jedoch den "Sauberen Blick darunter" verbergen und zum Teil verwehren (systemd). Viele der genannten Dinge leiden unter ständigiger "Versioneritis", während andere Projekte irgendwann verweisen aber aus Kompatibilitätsgründen trotzdem berücksichtigt werden müssen. Das führt zu immer mehr Edge-Cases (besondere, einzigartige PC-Konfiguartionen), die bei der Weiterentwicklung schlicht nicht berücksichtigt werden (können). Selbst so ein riesiger Konzern wie Microsoft bekommt das, wie man an den Windows-Updates der letzten Jahre beobachten kann, nicht mehr vernünftig hin!
Um den Problemen der ausufernden Komplexität zu begegnen, kommt vermehrt VIRTUALISIERUNG zum Einsatz! Nicht umsonst gibt es bei Linux auf der einen Seite die Ansätze zu "inmutablen" "atomaren" Betriebssystemen. Und auf der anderen Seite existiert ein ganz klarer Trend immer mehr Anwendungen und Programme mit all ihren "Schmuddel-Abhängigkeiten" relativ bequem in Container-Formaten zu betreiben ... AppImage, Flatpak, Snap, Docker.
LTS Distros bieten für den normalen Anwender in jedem Fall mehr Stabilität und Verlässlichkeit als Rolling Releases. R.R. sind zwar aktueller und werden wenn es denn knallt sehr schnell gefixed, doch viele der Problemlösungen dort setzten oft Expertenwissen voraus!
Die Updates sind bei LTS wahrscheinlich nicht viel seltener als bei anderen Distributionen - aber sie betreffen sicherlich weniger Pakete. Genauso bei Rolling Release. Wenn ich bei meiner RR-Distro (Gentoo) jeden Tag einmal die Paketdatenbank aktualisiere und dann emerge --update --deep world laufen lasse, ist das oft nur eine Handvoll Updates. Wenn ich das 1x pro Woche mache, wird das schon mehr. Und dann ist noch die Frage, ob ich mich in stable oder testing aufhalte - ich bin mittlerweile zurück auf stable, weil mich insbesondere gefühlt wöchentliche Updates von qtwebengine aber auch vom Kernel genervt haben (weil halt klassisches Gentoo mit Selbstkompilieren). Prinzipiell ist es ja auch wünschenswert, dass Fehler und Sicherheitslücken schnell behoben werden und dann gleich neue Pakete bereitstehen. Und je mehr Pakete man insgesamt installiert hat, desto häufiger ist halt auch mal eins zum Updaten dabei. Man kann das ja auch einfach ignorieren und nur 1x pro Woche/ Monat den Kram einspielen.
Kann deine These 2 zur Update-Häufigkeit für Debian Stable keinesfalls bestätigen und für Debian LTS schon gar nicht. Da kommen nach meiner Erfahrung ganz erheblich viel seltener Updates/Upgrades als bei Ubuntu. Dort purzeln z.B. fast im Wochentakt neue Kernel herein.
Das ist auch nicht verwunderlich, denn Debian liefert eben nur Sicherheitsupdates, während Ubuntu auch Feature Updates liefert.
Mit apt haben wir bei Debian noch nie Probleme gehabt, wenn ich keine externen Sources verwendet habe. Bei Ubuntu ab und zu, aber sehr selten.
Nutze ein DualBoot-System mit Windows und Archlinux - bis dato keine wirklich großen Probleme
Habe gerade auf GNOME 48 upgedatet...