Rolling Release oder Point Release? Was nutzt ihr auf dem Desktop? Edition 2024

[Der_Rolf]

Schon um das Jahr 2000 herum habe ich erste Versuche mit Linux gemacht die aber immer wieder scheiterten.
Ernsthaft beschäftigt habe ich mit Linux erst als Windows 8 kam.
Damals gab es noch Mint mit KDE.
Das war mein Anfang ernsthaft Linux einzusetzen.
Nachdem Mint kein KDE mehr unterstützt hat bin ich zu KDE neon umgestiegen.
Damit hatte ich mein perfektes Linux gefunden.
Und das nun schon seit vielen Jahren.
Gerade durch Rolling Release ändert sich immer wieder mal etwas und es wird nicht langweilig. 😎

 

[D.S.i.u.S.]

Als Knoppix und Ubuntu die Welt erblickten, habe ich kurz getestet und war nicht zufrieden. Sogar Windows Me mit ständigen freezers war besser.

Im November 2023 Nobara38(Gnome) und Fedora39(KDE) getestet und für sch..... befunden, weil es nicht ohne Probleme lief.

Auch im November Manjaro getestet: manjaro installiert standardmäßig libva nvidia Treiber nicht, macht Probleme mit AUR und ums Verrecken den Drucker nicht zum Laufen bekommen, Farben sind Geschmackssache.

Dann wollte ich die Aussage überprüfen, dass Arch nicht für Neulinge ist. Das stimmt nicht.
Dank arch wiki hat Installation ohne archinstall zwar gedauert aber es ging.
Und vor allem hatte man die Probleme aus Nobara, Fedora, Manjaro nicht.
Arch liefert aktuellen nvidia-dkms Treiber aus offiziellen Repositories. Das finde ich sehr gut.
Zuerst hatte ich frogging-family/nvidia-all Treiber aus AUR, die dann neulich(KW18) durch nvidia- dkms ersetzt wurden.
Dafür muss man mit sudo pacman -R steam Steam entfernen und dann alle Pakete installieren, die tkg-pakete ersetzen sollen. Auch in KW18 habe ich AUR Pakete von 30 auf 12 reduziert.
Ich werde weiterhin Rolling Release bevorzugen, weil es einfach aktuelles Zeug liefert.

@Der_Rolf
Seit wann hat KDE Neon Rolling Release?

 

[sedot]

@Der_Rolf
KDE Neon würde ich eher als Mischform einordnen, der Unterbau ist Ubuntu LTS und Plasma je nach Edition eher Rolling. Aber trotzdem schön, dass du zufrieden bist.

 

[Feuerbiber]

Nutze inzwischen seit 19 Jahren Linux.
Eingestiegen mit Ubuntu 6.06 später zu Mint, dann zu Debian, Versuche mit openSUSE, zu Manjaro, zu Arch zu EndeavourOS und nun seit letztem Jahr zu Fedora KDE Plasma.

Auf meinem Gaming PC läuft Fedora. Einfach, weil es immer den neusten Kernel, Mesa und gaming relevanter Software usw. hat und gleichzeitig abgestimmte stabile Systemsoftware durch Pointreleases bietet. Fedora ist außerdem durch und durch eine Upstream-Distribution, die ausschließlich freie Software vorinstalliert, und Red Hat pusht mit diesem System die Entwicklung neuer Technologien im Open Source und Linux Universum voran. (z.B. systemd, flatpak, wayland, pipewire, rpm-ostree, btrfs, ...)
Red Hat ist einer der größten Kontributoren zu Linux und Open Source, ich möchte dies unterstützen. Hier wird die Zukunft gemacht. Viele "orthodoxe OpenSourceler" sehen das genau andersrum und in Red Hat den Teufel. Aber: von nichts kommt nichts. Eine Distri, die zwar die reine Lehre vertritt, aber nichts upstream zurückgibt, ist ein Leecher.

Aufgrund der weiten Verbreitung von RHEL im Enterprise Geschäft gibt es zudem auch nahezu jede Software.

Diese Mischung aus top aktueller Software im Stile eines Rolling Release und gleichzeitig einer stabilen Systembasis ist für mich die beste Variante. Aufm Notebook darfs auch Arch sein.

Ich verwende Rolling Release.
Zugegebener Maßen bin ich ein Aktualisierungs-Fetischist. 🤭

Keine Sorge auch bei Fedora kommen täglich updates. (mehrere Gigabyte in der Woche)

 

[Eletron]

Ich interessiere mich auch für Arch. Ich habe es sogar letzte Woche installiert und direkt wieder mit AUR zerschossen. Offenbar bin ich noch nicht bereit dafür bzw. ist ein etwas sanfterer Einstieg richtiger in meinem Fall. Fedora ist in meinem Usecase somit die beste Lösung.

Ich trainiere für Arch einfach weiter in meiner VM. Allerdings muss ich sagen, dass ich mich mit Fedora und Gnome sehr wohl fühle. Wenn es weiter so läuft, ist die Wahrscheinlichkeit gar nicht so unwahrscheinlich, dass ich bei Fedora bleibe.

 

[Kuristina]

..und mir dann direkt mit AUR zerschossen. Offenbar .. brauche ich einen etwas sanfteren Einstieg

Der sanftere Einstieg wäre gewesen, AUR erstmal zu ignorieren. Das hast du mit Fedora ja auch nicht. ^^ Aber Fedora ist schon eine gute Distro. Hatte ich auch eine Weile.

 

[Eletron]

AUR erstmal zu ignorieren

Ja, das wäre besser gewesen. Ich wollte zu viel

 

[Snakeeater]

Das größte Problem von Arch: AUR. Habe das schon an anderer Stelle gesagt.

 

[l3mur123]

Ubuntu LTS. Auf der Arbeit (noch) 20.04, auf dem Laptop gerade frisch 24.04.

 

[jenzen]

Rolling Release (Arch). Finde ich auch generell am Sinnvollsten für den Desktop. Auf Desktops sind schnelle Feature Releases IMHO sehr sinnvoll. Auf Servern dagegen Point Release, da zählt normalerweise Stabilität vor allem anderen, notfalls kann man sich ja auch immer gezielt einzelne Applikationen in einer neueren Version installieren als über die Distri-Paketverwaltung angeboten wird.

Point Release bedeutet, dass nur Sicherheitspatches sehr schnell kommen, aber Feature Releases verspätet (erst mit der nächsten Release-Version der Distribution).

Rolling Release bedeutet, alles kommt sehr schnell. Dadurch könnte es aber auch mal Paketkonflikte oder sogar im worst case ein nicht mehr bootendes System geben. Deshalb sollte man das nicht für Server verwenden, aber auf dem Desktop ist es OK, da kann man sich relativ schnell selbst behelfen (entweder mit einem Paket-Downgrade, oder einem Snapshot-Rollback, oder mit Booten von Installationsmedium, chroot und dann reparieren).

Es sei denn man legt auch auf dem Desktop Wert auf extreme Stabilität, dann vielleicht auch hier Point Release, aber die Nachteile sind halt dass man dann allem ein paar Versionen hinterherhinkt, was schon nervig sein kann, insb. wenn man sich auf bestimmte neue Features freut. Und der Nachteil von Rolling Release ist auf dem Desktop einfach nicht relevant genug IMHO, vor allem da es ja trotzdem selten zu Problemen kommt. Meine Arch-Installation ist jetzt ca. 4 Jahre alt und ich musste in all der Zeit 2x ein Paket temporär downgraden weil sonst eine Applikation nicht mehr ging und 1x war mein ganzes OS nicht mehr bootfähig nach einem glib-Paketupgrade und ich musste einen btrfs-Snapshot zurückspielen und ca. ein paar Stunden warten bis Arch das upgedatete Paket ins Repo gepusht hat (denn der Fehler war in der einen Paketversion gewesen, was nach ein paar Stunden schon korrigiert wurde. Viele werden das wahrscheinlich gar nicht mitbekommen haben wenn sie in diesem Zeitfenster nicht geupdated hatten). Das war's. In 4 Jahren. Dafür ist alles immer topaktuell.

 

[sedot]

Dadurch könnte es aber auch mal Paketkonflikte oder sogar im worst case ein nicht mehr bootendes System geben.

Ich bin bei diesem Punkt dankbar, dass die Involvierten bei openSUSE scheinbar sehr genau schauen und das Testing im Vorfeld funktioniert. Paketkonflikte sind bei mir meistens selbst verschuldet, irgendeinen worst case hatte ich noch nicht. Kann auch an meiner Konfiguration liegen oder ich hatte Glück bisher.
Etwas Trouble gab es wohl für User beim Upgrade von Plasma 5 auf 6. Das war neben dem xz case eines der wenigen Fälle in jüngster Zeit.

 

[Natriumchlorid]

Das größte Problem von Arch: AUR.

Ich sehe das AUR als komfortablen Mehrgewinn an. Früher wurde es noch häufiger verwendet, heute sinds vielleicht noch fünf Pakete, welche ich daraus beziehe.
Weshalb sollte dies ein Problem für die Distribution sein? Die Verwendung davon ist nicht obligatorisch.

 

[jenzen]

Das AUR ist overalll sehr positiv, ja, was nicht ganz so positiv vielleicht ist, dass es sehr populäre PKGBUILDs im AUR gibt die eigentlich schon längst im offiziellen Extra-Repo drin sein sollten. Also das stört mich ein wenig, dass Arch ein bisschen mehr in die offiziellen Repos übernehmen könnte. Denn auch wenn das AUR gut ist, so sollte man doch immer die PKGBUILDs überprüfen, es könnte sich ja theoreitsch auch irgendwann mal was schädliches drin sein. Das sieht man dann zwar direkt, aber man braucht zumindest Shell-Scripting-Kenntnisse und Kenntnisse vom Arch-Build-Prozess, um das beurteilen zu können. Für User die das nicht haben, wäre es sicherer, wenn die besonders populären AUR-Pakete auch schnell in die Haupt-Repos übernommen werden. Denn damit eliminiert sich dann auch der Zusatzaufwand, die PKGBUILD zu prüfen. Denn das bleibt beim AUR ja immer beim User hängen. Wenn es schon im BInärpaket-Repo wäre, hätten die Arch-Maintainer ja schon mal drübergeschaut zumindest. Würde also einen kleinen Aufwand vom User wegnehmen.

 

[Snakeeater]

Ich sehe das AUR als komfortablen Mehrgewinn an. Früher wurde es noch häufiger verwendet, heute sinds vielleicht noch fünf Pakete, welche ich daraus beziehe.
Weshalb sollte dies ein Problem für die Distribution sein? Die Verwendung davon ist nicht obligatorisch.

Es verleitet gerade Neulinge dazu jedmöglichen Mist aus dem AUR zu beziehen ohne sich im Klaren zu sein was das für die Systemstabilität/sicherheit bedeutet. Es ist ein glorifizierter App"shop" für Hinz und Kunz. (überspitzt)

Ich gehe sogar soweit und sage das Flatpaks dem AUR deutlich überlegen sind. Hier hat man zumindest eine gewisse Trennung vom Rest des Systems, meines Wissens nach trifft das nicht auf alle AUR Pakete zu.

 

[Natriumchlorid]

Das AUR ist overalll sehr positiv, ja, was nicht ganz so positiv vielleicht ist, dass es sehr populäre PKGBUILDs im AUR gibt die eigentlich schon längst im offiziellen Extra-Repo drin sein sollten.

Ich konnte über die Jahre immer wieder beobachten, dass Pakete ins extra (früher community) Repository aufgenommen worden sind. CoreCtrl fällt mir spontan dazu ein.
Aber so häufig beziehe ich neue Pakete dann auch wieder nicht.

Denn auch wenn das AUR gut ist, so sollte man doch immer die PKGBUILDs überprüfen, es könnte sich ja theoreitsch auch irgendwann mal was schädliches drin sein.

Ich finde die Aussage hat eine generelle Gültigkeit. Benutzer sollten drauf achten, welche Skripte oder Software sie aus dem Netz laden und nicht einfach das Tutorial copy pasten, ganz nach der Art:
curl -o - https://download.server.invalid/installer.sh | sh

Das hat mit dem AUR an sich nichts zu tun.

Es verleitet gerade Neulinge dazu jedmöglichen Mist aus dem AUR zu beziehen ohne sich im Klaren zu sein was das für die Systemstabilität/sicherheit bedeutet.

Das schaffen unerfahrene Windows-Benutzer auch heute noch mit ihren Registry-Cleanern. Welche Instanz hindert sie daran?
Wenn es zu dem Vorfall kommt, dass ein Paket aus dem AUR das System negativ beeinflusst, dann ist hoffentlich ein Lerneffekt vorhanden.

Das Wiki gibt selbst den Hinweis drauf:

AUR packages are user-produced content. These PKGBUILDs are completely unofficial and have not been thoroughly vetted. Any use of the provided files is at your own risk.

 

[Snakeeater]

Hinweise und Menschen haben irgendwie keine gute Historie meiner Meinung nach.

 

[Feuerbiber]

Das AUR ist aber gerade ein relevanter Faktor für Arch

Point Release bedeutet, dass nur Sicherheitspatches sehr schnell kommen, aber Feature Releases verspätet (erst mit der nächsten Release-Version der Distribution).

Das stimmt in der Absolutheit schlichtweg nicht. Fedora ist ein Pointrelease und bekommt dennoch topaktuelle Software wie Kernel, Mesa usw. über die Repos und Anwendungssoftware über Flatpak. Der Kernel ist nichtmal eine Woche hinter Release auf kernel.org. Auch KDE Plasma bekommt zwischen den Fedora-Releases Major-Updates (6.x.0).

 

[andy_m4]

Das stimmt in der Absolutheit schlichtweg nicht. Fedora ist ein Pointrelease und bekommt dennoch topaktuelle Software wie Kernel, Mesa usw. über die Repos und Anwendungssoftware über Flatpak. Der Kernel ist nichtmal eine Woche hinter Release.

Die Frage ist, ob man dann überhaupt noch von einem (reinrassigen) Point-Release reden kann.

 

[Der_Rolf]

Seit wann hat KDE Neon Rolling Release?

Als was würdest Du es einstufen?

 

[Keylan]

Und Manjaro ist kein Rolling-Release, weil Pakete sehr oft einige Wochen zurück gehalten werden. KDE Plasma 6 ist bald 10 Wochen hinterher.

Ist es so schwer zu verstehen, das die Welt nicht nur schwarz und weiß ist, und das diese Bezeichnungen eine Philosophie beim Umgang mit Updates anspricht und keinen Anspruch auf dogmatische Einhaltung hat.

Der Unterschied ist nun mal nicht, ob die Pakete schnell oder langsam kommen, sondern ob es geplante Intervalle für Updates gibt, oder eben Pakete ausgerollt werden wenn der Distributor sagt das es grade passt.