Ist Rolling Release die Zukunft?

[McMoneysack91]

Liebe Freunde,

zu meinen Distro-Hopping Zeiten konnte ich mich nicht nur zwischen den tausenden Distros nicht entscheiden, ich konnte mich auch nicht entscheiden zwischen Point Release Distros und rollenden Distros.

Die Vor- und Nachteile liegen auf der Hand. Und...seit ich mich bei Debian eingependelt habe, stellte sich mir die Frage auch irgendwie nicht mehr. Okay, Debian hat zwar Sid doch da schaute ich eigentlich nie rein. Höchstens testing. Nun kitzelt es mich doch wieder, rolling auszuprobieren. Grund ist: auf meinem Hauptrechner läuft derzeit openSUSE Leap 15.3 doch irgendwie finde ich den Gedanken von Tumbleweed cool und werde dem eine Chance geben.

Ich bin nicht wirklich aktiv bei Distrowatch oder generell in der aktuellen Debatte, aber kann man einen Trend zu Rolling Release erkennen? Der Gedanke kam mir bei einem Blick zu Windows. Windows war seit jeher Point Release. Win95, Win98, 2000, ME, XP, 7, 8, 10. Okay, jetzt haben wir 11 aber vor einiger Zeit hieß es, es werde kein weiteres Windows mehr geben, sondern ab hier ein kontinuierlich rollendes Win10. Klang für mich nach Rolling Release.

Den Vorteil sehe ICH bei Linux gar nicht so sehr in diesem bleeding edge, immer up to date. Das juckt mich eigentlich überhaupt nicht. Den Vorteil sehe ich eher darin, dass man nicht immer wieder ein sinkendes Schiff verlassen muss, sondern einmal an Bord, gehts immer weiter und weiter.

Den Nachteil führen viele in der Instabilität auf. Rolling heißt Kinderkrankheiten. Doch dafür gibt es doch auch Lösungen. Bei Arch, welches ich nach der "Average Linux User" Anleitung installierte, war immer ein sofortiger Wechsel zum LTS Kernel vorgesehen. Und auch sonst kann man bei Updates doch sicherlich einstellen, dass man seine Updates nach einer gewissen Bugfixing Periode bekommen will - etwa 1 Monat nach Release z.B.


Rolling-Release Hybrid?

Ich frage mich, ob ich nicht aus beiden Welten Beides haben kann. Also dass ich Debian behalte, aber auch in gewisser Weise automatisch rolle, ohne gleich auf Sid greifen zu müssen. Die Repositories unter /etc/apt/sources.list tragen immer den Namen der aktuellen Version, also z.B. "Buster" oder "Bullseye". Ich las, dass man diese spezifischen Namen ändern kann zu "stable" oder "testing". So rollt man bei dem entsprechenden Update automatisch zu der Distroversion, die es dann in das jeweilige Stadium Testing oder Stable schafft. Ist das so richtig? Oder muss hier rotzdem dann der Distro-Upgrade erfolgen?

Das mit Debian wäre nur eine nette Spielerei. Das Kernthema des Threads ist: was glaubt ihr? Wird (zumindest der Desktop) zum Rolling Release hin tendieren?

 

[Tenferenzu]

Ich persönlich bin der Meinung, dass sich das an den containerformaten ala Snap, Flatpack etc. entscheiden wird..

Setzen sie sich durch-> rolling release da die Software sowieso kompatibel ist

 

[rgbs]

... Den Vorteil sehe ich eher darin, dass man nicht immer wieder ein sinkendes Schiff verlassen muss, sondern einmal an Bord, gehts immer weiter und weiter....

Man muss ja z.B. bei Ubuntu kein "sinkendes Schiff verlassen", sondern kann auf die nächste Version updaten.
Bei meinem jetzigen Ubuntu 21.10 habe ich mal mit 18.04 angefangen.

Gruß
R.G.

 

[Comadevil]

Ich las, dass man diese spezifischen Namen ändern kann zu "stable" oder "testing". So rollt man bei dem entsprechenden Update automatisch zu der Distroversion, die es dann in das jeweilige Stadium Testing oder Stable schafft. Ist das so richtig? Oder muss hier rotzdem dann der Distro-Upgrade erfolgen?

Das ist so richtig. Trotzdem findet natürlich ein Distroupgrade statt, wenn es eine neue Version nach stable schafft. Also nach deinem Beispiel wäre dann automatisch das Update von Buster nach Bullseye durchgeführt worden

 

[andy_m4]

Okay, jetzt haben wir 11 aber vor einiger Zeit hieß es, es werde kein weiteres Windows mehr geben, sondern ab hier ein kontinuierlich rollendes Win10. Klang für mich nach Rolling Release.

Windows 10 war und ist kein Rolling-Release. Upgrades gibts halbjährlich (bzw. inzwischen jährlich). Das ist also mit dem Vergleichbar, was Du bei Linux mit ubuntu hast.

Den Vorteil sehe ICH bei Linux gar nicht so sehr in diesem bleeding edge, immer up to date. Das juckt mich eigentlich überhaupt nicht. Den Vorteil sehe ich eher darin, dass man nicht immer wieder ein sinkendes Schiff verlassen muss, sondern einmal an Bord, gehts immer weiter und weiter.

I.d.R. gibts ja dafür den Upgrade-Pfad. Das Du halt weitestgehend problemlos von einer auf die nächste Version kommst. Ist ja nicht so als wenn Du bei jedem neuen Release neu installieren müsstest oder so.
Insbesondere bei dem von Dir erwähnten Debian klappen die Upgrades meist relativ gut.

Ich frage mich, ob ich nicht aus beiden Welten Beides haben kann.

Ja. Kann man. In der (Free)BSD-Welt ist das zum Beispiel verbreitet. Man hat ein Basis-System welches in Release-Zyklen aktualisiert werden (mit Major, Minor-Versionen) und Drittanbieterprogramme welche im Prinzip Rolling-Release sind.

Ich weiß jetzt nicht, ob es eine Linux-Distribution gibt die das ähnlich macht. Es gibt aber mit Snappy bzw. Flatpak ne Geschichte, wo man sich Programme installieren kann die am System-Paketmanagement vorbei gehen (die haben dann sozusagen ihr eigenes Package-Managment). Das erlaubt es dann z.B. auf einem abgehangenen Debian aktuelle Programmversionen zu betreiben.

Ich las, dass man diese spezifischen Namen ändern kann zu "stable" oder "testing". So rollt man bei dem entsprechenden Update automatisch zu der Distroversion, die es dann in das jeweilige Stadium Testing oder Stable schafft. Ist das so richtig?

Ist richtig. stable und testing sind quasi Symlinks auf die jeweilige stabile bzw. testing Version.

Das Kernthema des Threads ist: was glaubt ihr? Wird (zumindest der Desktop) zum Rolling Release hin tendieren?

Würde ich nicht sagen. Beides hat seine Vor- und Nachteile. Und die 100.000 Linux-Varianten werden uns so verkauft, das man dann jedem Bedürfnis nachkommen kann. Und dann wäre es ja Quatsch, wenn sich alle auf eine der beiden Möglichkeiten "einigen" würden.

 

[McMoneysack91]

Aus diesem Thread ist eine Sache noch nicht ganz hervorgegangen und einen neuen Thread mit annähernd demselben Thema zu eröffnen wäre redundant:

Kann man ein Roling Release entschleunigen?

Derzeit bin ich bei OpenSUSE Leap und selbst nach mehreren Anläufen bei Tumbleweed rannte ich immer schnell zurück zu Leap. Rolling Release möchte ich NICHT wegen des Bleeding Edge, sondern wegen der Bequemlichkeit einfach ein aufgesetztes System fortwährend zu haben.

Wie oben beschrieben kann man bei Arch ja auch den LTS Kernel umswichen. Soweit ich verstehe, verschafft einem dies die Möglichkeit, zwar auch zu rollen aber eben etwas später, nachdem vielleicht erste Bugs beseitigt wurden. Ist das so korrekt?

Gibt es diese Möglichkeit auch bei Tumbleweed? Dass man Paketupdates bekommt, die vielleicht schon mehrere Wochen alt sind? Oder ist Tumbleweed per se schon konservativer als Arch und bringt das von Haus aus mit?

Und mal jenseits von OpenSUSE: wie entschleunige ich ein Rolling Release? Einfach seltener Updates ausführen kanns ja nicht sein, denn selbst wenn ich nur monatlich update kann es ja sein, dass ich ein Feature mitnehme was gerade mal einige Stunden alt ist.

Gibt es da eine generelle Anleitung?

 

[sedot]

Kann man ein Roling Release entschleunigen?

Du kannst prinzipiell mit zypper (oder YaST) Pakete sperren um Modifikationen zu unterbinden. Lies;
https://en.opensuse.org/SDB:Zypper_usage#Package_locks

Was ich noch nicht ausprobiert habe ist, wie gut sowas mit größeren Paketen/Pattern funktioniert, also KDE, GNOME, etc. Ich hab LXQT, LibreOffice und Kleinkram (den ich definitiv nicht aktuell brauche) gesperrt und bekomme entsprechend null Updates.

Dass man Paketupdates bekommt, die vielleicht schon mehrere Wochen alt sind?

Tumbleweed wird in Snapshots ausgeliefert. Jeder Build der Distro ist ein (tages-)aktueller Snapshot (nach dem automatischen Testing), falls du dir jetzt ein .iso bei openSUSE herunterlädts bekommst du den neuesten (tagesaktuellen) Build.
Es gibt (Drittanbieter-)Tools wie tumbleweed-cli die auch das springen zwischen spezifischen Snapshots ermöglichen. Hatte ich mal kurz ausprobiert, endete (bei mir) in Paketkonflikten. Die Verwendung wird explizit nicht empfohlen, auch weil das Bewertungssystem für die Qualität von Snapshots als fraglich empfunden wird.
Mehrere Kernel können ohne weiteres genutzt werden.
https://en.opensuse.org/SDB:Keep_multiple_kernel_versions

Und mal jenseits von OpenSUSE: wie entschleunige ich ein Rolling Release?

Ich finde Tumbleweed ist schon einigermaßen langsam machbar. Mit XFCE, Cinnamon, LXQT, openbox (und vielleicht auch Mate) kommen zumindest für die DEs wenig Updates im Vergleich zu KDE oder GNOME.
Umso höher die von den Repos entkoppelte Anzahl an Anwendungen (Flatpak, Appimage) ist, desto niedriger ist dann auch die Anzahl an Paketen beim dup. So zumindest ist meine grobe Beobachtung.

 

[McMoneysack91]

Scheint, als hätte ich in Tumbleweed in der Tat den perfekten Kandidaten für ein langfristiges Rolling Release Konzept gefunden. Es scheint zumindest weit konservativer als ein Arch oÄ zu sein.

 

[mastaqz]

Bei Arch hängt es auch vom Repo ab: https://wiki.archlinux.org/title/Official_Repositories

core-Pakete gehen idR zuerst in testing.

Für zu häufige Updates kann man entweder die Version wechseln, bspw. von firefox auf firefox-esr, oder eben in pacman ignorieren.

Ein großer Vorteil von häufigen Updates ist, dass die Fehlersuche deutlich einfacher ist als bei einem großen Update von 50 Paketen.

 

[Chris_S04]

Bei Rolling oder im speziellen Arch ist aber gar nicht Mal entscheidend ob man einen LTS Kernel einsetzt oder nicht. Die Paketkonflikte können ja auch ganz woanders auftreten, was mit dem Kernel nichts zu tun hat.

Letztlich ist es immer auch persönliche Vorliebe oder Einsatzzweck.
Ich spiele ab und an Mal auf meinem System, deshalb sind aktuelle Pakete schön, die hat man eben in Rolling Releases. Meine Erfahrungen waren aber, dass es irgendwann bei RR immer Mal gekracht hat und es Paketkonflikte gab, die man manuell erst lösen musste usw usf. was mich auf Dauer genervt hat.
Bei Point Releases bin ich nicht so aktuell, habe aber i.d.R. besser getestete Pakete, da innerhalb eines Releases überwiegend nur Sicherheits- und Bugfixes ausgeliefert werden. Hat man jetzt ein Point Release mit einem Supportzeitraum von etwa einem Jahr, dann geht das auch. Ubuntu STS oder Fedora z.B. bringen alle sechs Monate neue Releases. Klar kann dauert das Dist-Upgrade dann Mal, aber bei mir hat das bei den großen Distros zu 99% gut geklappt und ist für mich dann irgendwie stressfreier als RR.

Auf einem Server z.B. der stabil laufen muss, kommt für mich nur Point Release in Frage.

Aber ich verstehe die Vorzüge von RR und finde sie auch verlockend, aber meine eigene Erfahrung lässt mich da etwas zurückschrecken.

 

[McMoneysack91]

Ich denke meine Befürchtungen kommen daher, dass ich noch nie einen Distro Upgrade durchgeführt habe. Ich denke das wird bei Leap als nächstes der Fall sein. Vermutlich bin ich viel entspannter was Point Release angeht, wenn ich einmal gesehen habe wie geschmeidig ein Distro Upgrade ist.

Ich bevorzuge Stabilität vor bleeding edge. Ich könnte gerne auch Software aus 2006 benutzen

 

[sedot]

Es scheint zumindest weit konservativer als ein Arch oÄ zu sein.

Das was du mit den offiziellen Repos bekommst ist ja schon (automatisch) getestet. Würdest du die factory-Repos direkt verwenden sähe es vielleicht anders aus. SUSE bietet einfach einen enormen Unterbau an Know-How und Tech der auch absichert, selbst bei/mit Rolling Release.
Natürlich kann und wird trotzdem irgendwas schieflaufen, ist so bei komplexen Systemen, egal welches Logo draufsteht am Ende.
Denk an (externe) Backups für wichtiges, unabhängig vom OS, dann schmerzen Defekte nicht ganz so sehr. Über Distributionsupgrades freue ich mich regelmäßig, gibt keinen Grund für diffuse Ängste aus meiner Sicht, im Zweifel ist das System auch schnell wieder installiert 😀

 

[McMoneysack91]

Ich denke probieren hilft hier über studieren. Noch "muss" ich Leap 15.3 verwenden, da komischerweise NUR aus dieser Version das WINE mein Gothic 3 v.1.12 (ohne Community Patch, also das rohe aus 2006) problemlos abspielt. Das neuere WINE aus Tumbleweed war eine ewige Bastelei.

Sobald ich G3 in dieser Version durchgespielt habe, werde ich vermutlich auf Tumbleweed umsatteln. Zumal ich dann sowieso auch mal KDE Plasma als DE ausprobieren wollte. Bin ja seit jeher XFCE Nutzer.

 

[sedot]

Gothic 3 v.1.12 (ohne Community Patch, also das rohe aus 2006)

Das war ja schon mit Windows ohne Community-Patch ein Krampf, bin verwundert das du dir dieses Spiel in der Form antust 😅
Du weißt das Lutris auch Install-Scripts bietet? Im Zusammenhang mit WINE ist WINE-GE auch eine Erwähnung wert, als Alternative oder zusätzliche Option, falls mal was nicht geht.

Tumbleweed hat mit Plasma ziemlich viele Updates, teste das ruhig erstmal in der VM. Als XFCE Nutzer könnten dir die Ohren schlackern, Plasma ist so ziemlich das Gegenteil von entspanntem Rolling Release.

 

[andy_m4]

Kann man ein Roling Release entschleunigen?

Im Prinzip kann man das schon, indem man nicht jeden Update-Step mitmacht. Das hat allerdings eine Reihe von Implikationen. Neuere Updates setzen i.d.R. ältere voraus. Wenn also irgendein Bug gefixt wird bzw. irgendein Feature kommt, was Du unbedingt haben willst kannst Du das nicht selektiv hochziehen.
Es kann außerdem theoretisch auch zu Problemen kommen wenn Du ein Programm updatest was in der Zwischenzeit wo Du die Updates augesetzt hat es zu einem Update kam.

Der wichtigere Punkt ist aber: Die alten Pakete bekommen keinen Support. Wenn also irgendwo eine Sicherheitslücke auftaucht wird nicht nicht nachträglich gefixt in dem da Fixes backported werden oder so. In puncto Sicherheit ist es also eher keine so gute Idee Updates zurückzustellen.

Die Möglichkeit Updates zurückzustellen bzw. ggf. ein Rollback zu machen ist eher für den Fall gedacht, das ein Update einen neuen Bug mitbringt. Dann kannst Du die Updates halt ein paar Tage schieben in der Hoffnung das dann zeitnah der Bug gefixt wird.

Vermutlich bin ich viel entspannter was Point Release angeht, wenn ich einmal gesehen habe wie geschmeidig ein Distro Upgrade ist.

Bei Point-Releases wird auch viel intensiver getestet, ob Upgrades auch sauber durchlaufen. Das wird bei Rolling-Release kaum gemacht (weils auch gar nicht zu leisten wäre).
Insofern ist diese Angst eher unbegründet. Da müsstest Du bei Rolling-Release viel mehr Angst haben. Da kann jeden Tag was kaputt gehen.
Außerdem kann man bei Point-Releases besser planen. Man macht die halt dann, wenn man Zeit dafür hat und dann (wie auch schon angesprochen) man vorher in Ruhe ein System-Backup machen kann das falls was schief geht man problemlos auch wieder ein Schritt zurück kann.

im Zweifel ist das System auch schnell wieder installiert

Wobei das im Fall des Falles einem ja nicht so viel nützt. Klar. Man hat erst mal wieder ein lauffähiges System. Aber was das wichtige an Upgrades ist, das die ganzen Daten (also die Dinge aus /etc, /home und /var) wieder funktionieren. Upgrade wirft ja nicht nur neue Programmversionen drauf, sondern nimmt ggf. auch dort Anpassungen vor.
Das ist also eher so eine Art Notausgang das dann (je nachdem was man so betreibt) dann auch noch einiges an Nacharbeit erfordern kann. Klar. Das installieren geht schnell. Der Aufwand steckt dann in der Nacharbeit.

Das neuere WINE aus Tumbleweed war eine ewige Bastelei.

Ich weiß nicht, wie es bei OpenSuSE Tumbleweed ist aber generell ist WINE ein Programm, was man relativ gut auch standalone außerhalb des Paket-Managements betreiben kann. Auch mehrere WINE-Versionen parallel zu betreiben ist jetzt nicht irgendwie ein Hexenwerk. Gerade so diese Spielestarter machen sich das auch zunutze, indem sie ggf. für jedes Spiel die passende WINE-Version vorhalten.

Wenn das also ein Problem ist, kriegt man es eigentlich ganz gut gelöst.

 

[Syntax_Error]

Das Rolling Release Prinzip ist nicht die Zukunft - und wird es auch nie sein. So ist das einfach. ;-)

 

[sedot]

Der Aufwand steckt dann in der Nacharbeit.

Kann so sein, klar. Deswegen Backup von wichtigem Zeug.
Für mich ist in meiner naiven Einfältigkeit nur /home (in Teilen) relevant oder übersehe ich irgendwas wesentliches? Der Rest kann ja neu – /var ist mehr oder weniger temporär, /etc egal bei Neuinstallation.
Post-Install Zeug ließe/läßt sich automatisieren. Womit dann auch (mühselige) Programminstallation wegfällt, so tief bin ich jetzt aber noch nicht drin, dass ich dafür ein „fertiges“ Script hab.

 

[andy_m4]

Für mich ist in meiner naiven Einfältigkeit nur /home (in Teilen) relevant oder übersehe ich irgendwas wesentliches?

Möglicherweise. :-)

Der Rest kann ja neu – /var ist mehr oder weniger temporär, /etc egal bei Neuinstallation.

Naja. In /etc liegt die globale Konfiguration. Und auch /var kann Dinge enthalten die man herüberretten möchte.

Das alles hängt natürlich sehr vom Nutzungsszenario ab und auch wie man bzw. die Distribution konfiguriert ist. In vielen Fällen wird es tatsächlich ausreichen einfach /home zu sichern. Nur kann man keinesfalls davon ausgehen das das immer so ist.

Post-Install Zeug ließe/läßt sich automatisieren.

Ja. Aber auch das muss man ja erst mal machen.

Sicherlich lässt sich das ein oder andere regeln und auch irgendwie hinkriegen. Das muss man aber berücksichtigen und daher finde ich ein lapidares "Dann installier' halt neu" ein bisschen zu kurz gegriffen.
Deshalb hielt ich es für angemessen den Punkt etwas zu ergänzen.

 

[ModellbahnerTT]

Das Rolling Release Prinzip ist nicht die Zukunft - und wird es auch nie sein. So ist das einfach. ;-)

Bei Server mag das stimmen aber in Bereich der Desktopanwender sicherlich nur sehr bedingt.

 

[sedot]

@andy_m4
Ja, ich versteh schon was du meinst, hätte ich anders formulieren können.
Von Leap zu Tumbleweed geht wohl auch ohne Neuinstallation, wie gut und fehlerfrei der Prozess letztlich ist weiß ich nicht. https://en.opensuse.org/openSUSE:Tumbleweed_upgrade
Ließt sich einigermaßen einfach.

Deshalb hielt ich es für angemessen den Punkt etwas zu ergänzen.

Ist imo völlig berechtigt, ich nutze den Hinweis mich mal mit /etc und /var auseinanderzusetzen.