Test Linux (Mesa 26) vs. Windows 11 im Test: Aktuelle Gaming-Benchmarks mit Radeon RX & GeForce RTX

[TheInvisible]

Rolling Release definiert sich ja eigentlich dadurch, dass es keine Betriebssystem-Versionen gibt. Also eine aktuelle Version und aktualisierte Images. Ich nutze seit 4 Jahren mehrere Solus-Installationen. Solus kann als "cutting edge" Distro bezeichnet werden. Da die Köpfe dahinter etwas länger testen und hin- und wieder auch auf Point-Releases warten. Aktualisierungszyklen finden wöchentlich statt. Das sind also über 200+ Zyklen und mit Ausnahme des WLANs wurde noch nie etwas "breaked". Also es scheint ja zu gehen.

Mit EndeavourOS (bleeding edge) hingehen hatte ich schon nach recht kurzer Zeit einen Totalausfall.

Rolling Release zerschießt dir halt mal gerne irgendwelche Programme oder Dienste wenns ein Major Update gibt. Da stehst in der früh auf, kommen Updates rein und dann geht irgendwas nicht. SteamOS benutzt zwar Arch aber auf Snapshot Basis. Das ist nicht umsonst so...

Deshalb für Linux Noobies immer klar Ubuntu LTS oder ähnliches. Zwar stinklangweilig aber den meisten interessiert es eh null welche Version da jetzt verfügbar ist.

 

[Grimba]

Man kann aber hier schon viel durch die Nutzung von z.B. btrfs und snapshots erreichen, automatisch angelegt bei Updates mit snapper. Das ist dann das Auffangnetz für solche Situationen. Das funktioniert sehr gut und ist in vielen Distributionen inzwischen auch schon so schön gelöst, dass man dafür kein Poweruser sein muss, z.B. in CachyOS.

Einfach im geeigneten Bootloader den vorherigen Snapshot laden, nach dem Boot gibt es auf den Desktop eine Benachrichtigung, dass ein gebooteter Snapshot erkannt wurde, und ob man darauf zurückrollen möchte, das entsprechend anwählen. Noch einmal Neustarten, schon ist wieder alles beim Alten und man wartet einfach mit dem Update noch ein paar Stunden.

Hab ich selbst schon genutzt, ist keine Raketenwissenschaft. Das ersetzt zwar nicht die Stabilität eines Pointreleases, wirkt aber solchen Situationen gut entgegen.

 

[Kuristina]

Die Ansichten, dass ein Rolling Release gerne mal was zerschießt, sind aber auch übertrieben. Ich hatte mal vor Jahren ein Problem mit Grub nach einem Update. Das hatte ich dann zum Anlass genommen auf systemd-boot zu wecheln. Seit dem war aber nix mehr los.

 

[Grimba]

Ja, es ist nicht oft. Was man aber dennoch machen sollte, eigentlich muss, ist bei RR acht auf die News-Seite der Distribution zu geben. Hin und wieder, allerdings selten, ist manuelles Eingreifen bei Updates erforderlich, das wird dann da angekündigt und beschrieben.

 

[Taxxor]

Es klingt im Netz immer so, als würde man sich bei Arch quasi nicht gegen die Updates wehren können und müsste damit leben, dass man eines Tages den PC anmacht und erstmal nen ganzen Tag Fehlerbehebung betreiben muss, aber kann ich nicht jederzeit selbst entscheiden welche updates ich wann installieren will?
Speziell bei Nvidia Treibern wird hier gerne mal gesagt, dass man sich auch viele Probleme holen kann, wenn immer das absolut neuste drauf gemacht wird. Aber ich kann doch einfach ignorieren und den Treiber dann updaten wenn ich will und dann auch auf die Version die ich will, oder nicht?

Ich hätte mir, als der 590er Treiber Probleme mit RT gemacht hat, mit CachyOS z.B. ja im Gegensatz zu Bazzite die Mühe sparen können, einen kompletten Rebase durchzuführen nur um auf ein OS Image zurückzugehen das den 580er Treiber genutzt hat und jetzt das neuste Image installieren das den 595er Treiber drin hat.
Ich hätte bis zum 595er Release einfach alles auf dem neusten Stand halten können, außer eben dem GPU Treiber

 

[Grimba]

aber kann ich nicht jederzeit selbst entscheiden welche updates ich wann installieren will?

Das stimmt im Prinzip, aber Rolling Release Distributionen bauen ja auf neue Versionen statt auf Backporting. D.h. die Distribution geht schlicht davon aus, dass sie rollt. D.h. wenn du einzelne Pakete anhältst (die kann man so flaggen), werden irgendwann Abhängigkeiten brechen, sofern vorhanden. Wenn du auf bestimmte ältere Versionen angewiesen bist, so musst du gucken, ob es für die jeweilige Software einen eigenen TLS zweig gibt, der gesondert gepflegt wird, z.B. beim Linux Kernel, oder du musst im AUR nachschauen, denn da wandern dann für gewöhnlich Versionen hin, die aus der Hauptdistribution gepurzelt sind. Das lässt sich im folgenden insbesondere ganz gut beim Nvidia Treiber zeigen.

Aber ich kann doch einfach ignorieren und den Treiber dann updaten wenn ich will und dann auch auf die Version die ich will, oder nicht?

Wenn du das Paket "nvidia" in Arch oder "cachyos-nvidia" nutzt, dann ist das der rollende Pfad, mit passend zum ebenso rollenden Kernel vorkompilierten Modulen. Stattdessen kannst du aber "nvidia-580xx-dkms" nutzen, welches im AUR oder bei CachyOS gesondert im eigenen Repository vorgehalten wird, und dann bleibst du auch auf 580. Der Name deutet es hier an, das Modul wird dann nicht mehr vorkompiliert angeboten, sondern wird per dkms gebaut, sprich bei jedem neuen Kernel erneut. Würdest du aber z.B. bei den anderen oben genannten Paketen diese vom Updateprozess ausschließen und es käme mit der Zeit ein neuer Kernel, würden die Module eben nicht neu gebaut und sie würden nicht mehr funktionieren, da für den neuen Kernel eben auch passend vorkompilierte Upgrades für "nvidia" oder "cachyos-nvidia" bereitgestellt würden, die du ja dann nicht bekommst.

Ich hätte bis zum 595er Release einfach alles auf dem neusten Stand halten können, außer eben dem GPU Treiber

Ja, auf dem beschriebenen Weg.

 

[Kuristina]

aber kann ich nicht jederzeit selbst entscheiden welche updates ich wann installieren will?

Aufgrund der Abhängigkeiten ist es generell schon sinnvoll alle Updates in einem Rutsch zu installieren, damit man keine Probleme bekommt. Aber ja, du kannst natürlich auch einzelne Pakete vom Update ausschließen oder auch in der Version downgraden. Und du kannst selber entscheiden, wann du die Updates machst. Ich update immer nur am Wochenende.

 

[Alexander2]

Wenns nur um bestimmte alte Versionen einer SOftware geht kann man ggf dann auch Distrobox und ähnliches auf irgendeiner Distro benutzen. Sich da eben das passende raussuchen.
Oder gar sich die mühe machen wie es auch Appimages machen, wenn es das nicht schon so gibt sich alles zum laufen nötige der Anwendung zusammenklauben und wie nen Appimage ähnlich zusammenpacken. Wenns total wichtig wäre.

Ergänzung (13. März 2026)

Aufgrund der Abhängigkeiten ist es generell schon sinnvoll alle Updates in einem Rutsch zu installieren,

Ist eine Explizite Empfehlung bei Arch. bei jeder Programm Installation auch, immer gleich das komplett update mitzumachen. andere Situationen muss man soweit ich weiß dan nauch selbst supporten, also die gehen im FOrum davon sicher aus, das du alles immer aktuell hälst.

Edit:
so ist eben arch ausgelegt.. aber es zwingt dich weiterhin keiner weiterhin updates zu machen, du kannst ab einem gewissen Punkt einfach keine Updates mehr überhaupt machen .. deine Entscheidung.

 

[sedot]

Was man aber dennoch machen sollte, eigentlich muss, ist bei RR acht auf die News-Seite der Distribution zu geben.

Auf welche Distributionen beziehst du dich? Tumbleweed kann es nicht sein.

 

[Kuristina]

bei jeder Programm Installation auch, immer gleich das komplett update mitzumachen.

Das handhabe ich anders. ^^ Ich selber habe auch schon einzelne Updates gemacht, ohne gleich das ganze System zu updaten. Aber ich kenn mich aus, da ist das kein Problem. Die Empfehlung geht auf Nummer sicher und das ist auch gut so.

 

[Grimba]

@sedot Arch. Einfach mal auf https://archlinux.org/ gucken, dort sieht man schon 3 Einträge mit "may require manual intervention" im Titel und das oberste beschreibt, was zu tun ist, um mit Pascal oder älter auf nvidia 580 zu bleiben. Bei Thumbleweed vielleicht nicht, keine Ahnung. Aber auch Thumbleweed rettet dich vermutlich nicht davor, dass ggf. irgendwann eine deiner config-Dateien nicht mehr zu einer erneuerten Software-Version passt, die diesbzgl. hier was bricht, wenn es keine automatisch vom System generierte config ist, sondern eine von dir zumindest modifizierte.

 

[Alexander2]

Ja, ist so @Kuristina wenn man ohnehin normal regelmäßig updatet ist auch nicht sofort ein Problem zu erwarten.
Sollte man mal ein Problem haben, sollte man aber vielleicht inmal dran denken und alles auf neuesten stand holen lassen. Könnte dann schon gefixt sein.

 

[Gohma]

Mein Updatezyklus bei Cachyos ist einmal in der Woche (Freitag) bzw am Wochenende, bin damit bisher sehr gut gefahren.

 

[Elan1338]

@Gohma Einmal pro Woche bei einem Rolling Release ist der gesunde Mittelweg zwischen täglich alles updaten und sich selbst ins Bein schießen und monatelang nichts updaten, um dann beim großen Knall das halbe System neu aufsetzen zu müssen. Freitags ist dabei strategisch klug, da hat man das Wochenende zum Debuggen falls doch mal etwas kracht.

 

[sedot]

@Grimba
Mit Arch kenne ich mich nicht gut genug aus. Insofern snapper konfiguriert wurde sollte doch im Fehlerfall der Rollback zum pre(-install) Snapshot funktionieren ohne weiteren Aufwand.

Probleme mit eigenen .config Dateien hatte ich in den letzten vier fünf Jahren keine.

 

[Gohma]

Freitags ist dabei strategisch klug, da hat man das Wochenende zum Debuggen falls doch mal etwas kracht.

Genau das war mein Hintergedanke bei der Wahl des Updatetages XD

 

[Grimba]

@sedot ja, wie schon oben beschrieben, ist snapper natürlich immer das Auffangnetz in solchen Situationen.
Aber ich hab hier schon was gefunden bei Thumbleweed, was zumindest in die Richtung geht, denn ich wusste doch, dass die diesen Monthly Blog haben, der ist diesbzgl. ganz nützlich:
https://news.opensuse.org/2026/03/02/tw-monthly-update-feb/
Dort ist z.B. folgende Information zu finden über die neue Version von btrfsprogs:

btrfsprogs 6.19: This update brings a notable default change where mkfs.btrfs now enables the block-group-tree feature by default, which speeds up mount times on large filesystems. Users needing backward compatibility with older kernels can disable it with -O ^bgt.

Hier hast du also schon einen Hinweis, dass falls du bewusst mit einem älteren Kernel unterwegs bist, du mit mkfs.btrfs jetzt ggf. aufpassen musst. Sowas meinte ich im Prinzip. Das sind so klassische Rolling Release Fallstricke.

 

[sedot]

@Grimba
Ja, aber warum sollte ich ältere Kernel nutzen wollen? Der Vorteil von Rolling Release ist doch genau möglichst aktuelle Software. Wer es weniger aktuell will kann auch Fedora oder so nutzen.

 

[Grimba]

Ja, aber warum sollte ich ältere Kernel nutzen wollen?

Das ist hier nicht die Frage. Es ist einfach ein mögliches Szenario.
Ggf. möchtest du das Dateisystem ja auch in einem anderen System mounten, oder die Kiste ist so alt und will nicht mit dem neuesten Kernel, oder was auch immer. Du persönlich musst nicht immer betroffen sein, könntest aber. Gleiches gilt mit den Configs. Das ist einfach kein allgemein gültiges Ding. Wenn du in 5 Jahren nie Probleme hattest, dann ist dir das einfach bei den Sachen, für die du was angepasst hast, nicht passiert. Aber es ist genauso wahr, dass hin und wieder Major-Upgrades von Software den Aufbau ihrer Config Dateien ändern, dann gehen die alten schlicht nicht mehr. Davor kann dich die RR-Distribution nicht schützen.

 

[sedot]

Das ist hier nicht die Frage.

Doch, war meine Frage. Entweder ich will aktuellste Software und komme mit eventuellen Fehlern klar, oder eben nicht und habe alte Fehler.

Aber es ist genauso wahr, dass hin und wieder Major-Upgrades von Software den Aufbau ihrer Config Dateien ändern, dann gehen die alten schlicht nicht mehr.

Habe ich nicht in Frage gestellt. Selbstverständlich kann ich nur aus meiner Perspektive berichten. YMMV.