Mit meinen Plädoyers für LTS-Distributionen scheine ich bei manchen immer wieder einen Nerv zu treffen. Einige scheinen in ihrer RR-Blase vergessen zu haben, wo die Mehrheiten sind.
Anlass für diesen kleinen Kommentar ist die Feststellung bei Heise, dass Desktop-Anwender bei Debian doch eher Testing verwenden, worauf sich schon in den Kommentaren Widerspruch äußerte. Das möchte ich mal aufgreifen, um hier ein paar Grundannahmen zu äußern, die ich für Linux/Linux-Anwender veranschlage und den meisten Blog-Artikeln zugrunde lege.
Zahlen sind natürlich bei Linux ein schwieriges Thema, weil die wenigstens Distributionen wirklich Zahlen erheben und jene, die das tun (wie z. B. Ubuntu) diese nicht transparent teilen, sondern lediglich in Form von Berichten. Man kann also anders als Apple oder Microsoft schlecht sagen, dass x. Mio. Anwender dieses oder jenes Release nutzen. Unstrittig ist, dass die Zahlen von Distrowatch nichts taugen.
Relativ unstrittig dürfte auch sein, dass die meisten “normalen” Anwender von Updates tendenziell genervt sind und eher selten den Mehrwert sehen. Die meisten machen Updates erst, wenn die Systeme sie penetrant daran erinnern oder sie gar einfach erzwingen. Nicht umsonst haben Apple und Microsoft automatische Updates im Hintergrund im Dienste einer allgemeinen Systemsicherheit in den letzten Jahren zum Standard erklärt.
Schauen wir uns mal an, welche Distributionen groß sind. Das sind jetzt “gefühlte” Werte. Sie ergeben sich aus den Zahlen der Distributionen, der Resonanz in den Medien, der Größe der Communitys und der subjektiv wahrgenommenen Präsenz im öffentlichen Raum. Ich mache mal ganz bewusst keine nummerische Liste, sondern gehe alphabetisch vor.
- Arch Linux
- Debian
- Fedora
- Manjaro
- Mint
- openSUSE
- RHEL & Clone
- Ubuntu
Ich behaupte mal ganz dreist: Alle anderen Distributionen kann man von den Marktanteilen unter “ferner liefen” eingruppieren. Bei den meisten darf man wohl sogar bezweifeln, dass sie vierstellige Nutzerzahlen haben. Und auch diese Liste dürfte eine erhebliche Spannbreite aufweisen. Vermutlich sind Ubuntu und Mint mit weitem Abstand führend.
Man muss kein Zahlenakrobat sein, um die Mehrheit der Nutzer bei stabilen Distributionen zu sehen. Das müssen jetzt nicht gleich extreme LTS-Varianten sein. Vermutlich aktualisieren die meisten Nutzer irgendwo in einem Intervall zwischen den 12 Monaten, die bei Fedora das Maximum sind, bis zu den 24 Monate zwischen zwei Ubuntu LTS-Varianten. Das ist übrigens auch der Zyklus den Windows 10 und macOS vorgeben.
Eines dürfte jedenfalls auch klar sein: Manjaro und Arch haben nicht mehr Anwender als die hier gelisteten stabilen Varianten. Selbst dann nicht, wenn man Debian und openSUSE wegen ihrer rollenden Zweige dazu zählt.
Nur mal so als Hinweis, weil viele Poweruser und Entwickler manchmal vergessen, wo die Masse der Anwender sind. Das soll natürlich niemanden daran hindern, RR-Distributionen zu nutzen.
Manche Entwickler/Projekte sollten sich allerdings schon fragen, ob ihr Zyklus mit 3-4 Monaten Sinn ergibt und welche Anwender sie damit erreichen, oder ob dahinter nur die Unfähigkeit zur Produktpflege steht. Einer der häufigst gelesenen Artikel hier im Blog ist ausgerechnet: Kommentar: KDE und die Distributionen – zwei Antipoden. Im Grunde genommen kann man Veröffentlichungen ab einer gewissen Häufigkeit und bei fehlender Pflege der Vorgängerversionen auch gleich bleiben lassen und den Distributoren einfach Git-Snapshots zur Paketierung überlassen.
Ja.
dem möchte ich auch zustimmen.
Es kann sehr anstrengend werden, wenn jeder OSwechsel mit einem RR beantwortet wird 😉
Ein deb.stable.LTS gibt mir momentan 5 Jahre Ruhe. Menschen, die schon länger (+ intensiver) sich mit ihren Programmen beschäftigen und sogar Changelogs lesen! zeige ich auch gerne eine RR, oder sogar eine andere distri…, aber die meisten meiner privat unterstützten Nutzer:innen reicht ja das einfachste (ich werf mal das Wort ‘Bürorechner’ in den Raum).
IMO ist dies die schweigende Mehrheit: da ist alles außer die stable überdimensioniert.
…und das mein ich überhaupt nicht abwertend – im Gegenteil: zeigt es doch (zumindest in meinem kleinen Universum) dass der Wechsel gut läuft und alle ihre Dinge erledigen können 🙂
“Vermutlich sind Ubuntu und Mint mit weitem Abstand führend.”
Sehe ich aus persönlicher Erfahrung auch so.
Bei mir ist es Linux Mint mit Cinnamon, was ich den Leuten empfehle, zeige (live-CD/Stick), mit ihnen dann zusammen auf ihre Rechner installiere und im Nachgang unterstützend Fragen beantworte. Fals notwendig. Linux Mint ist in meiner kleinen Ecke “Volks-Linux” 🙂
Gestern kam wieder jemand von Win8.1 zur Pinguinfraktion.
Ich behaupte jetzt Mal ganz dreist, dass LTS Versionen mehr Bugs und Fehler aufweisen als RR. Zahlen um das zu belegen habe ich nicht, aber es entspricht meiner Erfahrung. Ich hab darum mal den Satz geprägt: “LTS heißt Bugs werden nicht gefixt.”
Was ich damit meine ist, dass neue Programmversionen oft gar keine neuen Features bringen aber Bugs fixen. Inkscape ist da so ein Beispiel oder auch GIMP. Bei einer LTS Version hing man dann in der prä Flatpak und Snap Zeit auf den alten verbugten Versionen fest. Ein Update auf einen neuen Release, welches den nervigen Fehler nicht mehr enthielt, hat man aber nur mittels PPA bekommen. Nach 2 Jahren hatte ich dann so viele PPAs das quasi nix mehr funktionierte XD
Um ehrlich zu sein, LTS sind doch quasi eingefrorene RR snapshots. Klar heißt das ich habe eine Basis um mich drauf zu verlassen. Es heißt aber auch, was bisher nicht geht wird nie gehen. Die viel gelobte Zuverlässigkeit von LTS halte ich für ein Gerücht. Was genau würde den da getestet und verbessert im QA Prozess? Was genau macht der QA Prozess bei Ubuntu besser als der von KODI selbst? Im Regelfall sind die Gründe für ein ausbleiben von Updates nicht bugs, sondern Zeit und Ressourcen Mangel. LTS ist nicht stabiler oder sicherer oder hat weniger Bugs. LTS ist leichter und planbarer zu managen. Drin liegt der großer Vorteil.
Also zuerst einmal: Ich wollte in diesem Artikel explizit nicht werten, sondern lediglich einige daran erinnern, wo die Nutzer sitzen.
“Ich behaupte jetzt Mal ganz dreist, dass LTS Versionen mehr Bugs und Fehler aufweisen als RR. ”
Die Frage ist halt: Haben LTS mehr Bugs als RR, weil es systemisch ist oder weil Upstream die Unfähigkeit zur Softwarepflege vorherrscht und man sich von einem “heißen Scheiß” zum nächsten hangelt und Bugs halt nebenbei fixt oder durch Neuschreiben von Komponenten nebenbei behebt?
Ich glaube das es eher auf Letzteres hinausläuft. Was bei Projekten mit hauptamtlichen Entwicklern durchaus kritisiert werden darf (gibt ja auch Gegenbeispiele wie Firefox-ESR oder Linux-LTS). Man muss sich dann als Projekt nicht wundern, wenn man stetig an Relevanz einbüßt (siehe KDE).
Denn die Nutzer sitzen halt mehrheitlich bei stabilen Systemen und wechseln eher die Software, wenn sie ihren Qualitätskriterien nicht mehr entspricht als die Distribution.
Bei Ubuntu hat man das Problem, dass sich das lable LTS nur auf eine kleine Untermenge der Pakete bezieht, nämlich das was in Main liegt. Inkscape z.B. liegt in Universe, und wird von Canonical gar nicht gepflegt, das ist tatsächlich weitgehend ein einmaliger Snapshot aus testing.
Das ist bei Debian besser, aber auch da ist das fixen von Bugs stark davon abhängig, wie gut das Paket Upstream gepflegt wird, und wie aktiv und Kompetent der zuständige Paketmaintainer ist.
zitat: „Ich behaupte jetzt Mal ganz dreist, dass LTS Versionen mehr Bugs und Fehler aufweisen als RR. “
Da ist ganz sicher ein Trugschluss, da ja LTS Versionen zumindest bei Ubuntu eingefrorene RR sind, bei denen dann noch eine ganze Menge Arbeit in das fixen von Bugs gesteckt wurde. Der Eindruck kann aber dadurch entstehen, das im Verlauf der Zeit immer mehr Bugs entdeckt werden, die dann auch nicht mehr alle behoben werden. Gut zu sehen bei Debian, wo eine neue Distro veröffentlicht wird, wenn die bekannten Bugs gegen Null gesunken sind. Im laufe der Zeit steigen die bekannten Bugs dann wieder stark an, und könne auch höher als im aktuellen Testing liegen. Es kommen ja aber nicht wirklich neue Bugs dazu, die waren vorher auch alle da, sind nur noch nicht aufgefallen. Und im Testing ist man halt mit den testen noch ganz am Anfang, daher kennt man nur die wenigsten Bugs.
Sehe ich auch schon lange so. Als Neuling in der Linux Welt habe ich Anfangs jedes Ubuntu Reales 2 Monate vor Veröffentlichung installiert und auch mit Debian Testing und Sidux experimentiert. Arch war da noch kein Thema, sonst hätte das sicher auch auf der Liste gestanden. Da hatte ich aber auch noch viel Zeit zum basteln, bzw. das schrauben am System stand sogar im Vordergrund. Der tatsächlich Mehrwert war aber recht gering, anfangs gab es noch einige substanzielle Verbesserungen wie Plug and Play für usb Geräte und Schreibzugriff auf ntfs Partitionen ohne Bastelei und experimentelle Treiber.
Softwaremäßig hat es aber eigentlich sehr selten wirklich umwerfende Neuerungen gegeben, im Gegenteil, relativ häufig habe ich es sogar eher als Rückschritt empfunden, wenn funktionierende Lösungen nicht mehr weitergepflegt wurden, und der “modernere” Nachfolger erst mal voller Kinderkrankheiten eingeführt wurde.
Inzwischen bin ich nach zwei Jahren LTS regelmäßig überrascht, das es schon wieder eine neue Version gibt und warte dann auch meist noch ein halbes Jahr mit dem Umstieg. Von KDE habe ich mich schon lange schweren Herzen wegen der ständigen Umbauarbeiten und vielen damit verbundenen Baustellen getrennt. Derzeit nutze ich Xfce und kann ehrlich nicht sagen, was sich außer dem Desktop Hintergrund und der Versions Nummer in den letzten 4 Jahren geändert hätte. Dasselbe gilt für eigentliche alle Anwendungssoftware, die ich nutze. Ausnahme ist bei mir vielleicht der GIS Bereich, da sind bei eine zwei Jahres Intervall doch einige wesentliche Neuerungen erkennbar, aber auch da ist das ein updaten Zyklus, der mir absolut ausreicht. In dem Moment, wo die Nutzung der Software im Vordergrund steht, werden Änderungen schnell eher hinderlich (soweit es nicht um Bug fixes geht), da sie immer auch Anpassungen an den bestehenden Arbeitsflüssen bedeuten. Natürlich kann man trotzdem nicht darauf verzichten, aber es ist nichts was ich monatlich haben möchte, schon gar nicht unangekündigt wie im RR Modell.
Ein “langweiliges” System ist aktuell genau das, was ich schätze.
Aus der Sicht eines Software-Entwicklers macht Rolling-Release, wie es gewisse Linux-Distributionen machen, ebenso wenig Sinn. In der Software-Entwicklung wird ebenfalls ein gewisser Software-Stand genommen ( zb. openSUSE Leap 15.2 ) und hierfür entwickelt. Auch “normale” Software-Entwickler haben wenig Interesse an einem sich ständig ändernden System, wie die RR es anbieten. Dafür gibt es heute andere Wege um selbst auf einem abgehangenem System wie Ubuntu 18, eine moderne ( für das Jahr 2021 ) Entwicklungsumgebung aufzuziehen. Zum Beispiel mit Docker.
Ich habe schon paar mal versucht ein RR zu fahren, aber nach einer kurzen Zeit fingen immer irgendwelche Probleme an, bis hin zu Unbenutzbarkeit, mit denen man sich rumärgern muss. Man muss natürlich immer die Distro-Seite im Blick behalten um größere Probleme zu vermeiden. Aber mal ehrlich, ist der Computer zum Problemlösung da oder eher als Problem Verursacher konzipiert worden?
Rolling Releases, wie es Linux-Distributionen anbieten, ist doch nur die Antwort auf ein Symptom das weder Macos noch Windows wirklich kennen. Installation und Pflege von Software. Unter neuem Macos/Windows ist eine Installation älterer Software in der Regel wenig problematisch. Unter älterem Macos/Windows ist die Installation von neuer Software wenig Problematisch. Im Vergleich dazu Linux? Extra PPAs, extra Repositories, Snapt, Flatpack, selbst Packete bauen. Den in der Regel bieten die original-Repos, meist veraltete Software.
Ich denke alleine die Tatsache, dass der Kaufgrund für ein SUSE oder RedHat das extrem lange LTS ist, zeigt natürlich, was der Markt möchte und womit man Geld verdienen kann. Ich habe 2x Leap und einmal openSUSE Tumbleweed installiert. Mein Notebook Hersteller Tuxedo kommt nicht mal bei dem stabilen openSUSE Leap hinterher und bietet aktuell nur Unterstützung für das auslaufende 15.2 an, sodass ich da nicht die Wahl habe.