Snakeeater schrieb:
Gibts dazu auch Argumente?
Ich bin zwar nicht
@SVΞN, aber ich kann ja trotzdem mal antworten.
SteamOS ist in erster Linie für die Geräte von Valve selbst entwickelt (Steam Deck, Steam Machine etc.), es benutzt mit dem Neptune-Kernel einen Custom-Kernel, der Anpassungen für diese spezifische Hardware enthält. Die nutzen dir auf einem normalen System nichts, aber Valve aktualisiert die darunterliegende Kernel-Basis recht selten. Jetzt gerade hat es SteamOS 3.8 mit Kernel 6.16 aus dem Beta-Kanal geschafft, wir sind seit 1 Woche bei Kernel 7.1. Vorher ist der stabile Zweig von SteamOS ewig bei Kernel 6.11 rumgedümpelt und hatte daher noch nicht einmal Support für RDNA4, und auch nicht für NTSync, was in CPU-limitierten Szenarien durchaus hilft.
Generell ist die Software-Basis von SteamOS alt. Selbst SteamOS 3.8 nutzt immer noch Mesa 25.3, damit hast du die Performance-Optimierungen für Raytracing, die mit Mesa 26 gekommen sind, immer noch nicht. Und diese Performance-Sprünge sind teilweise schon recht beachtlich gewesen.
Das zweite, was auf dem Desktop gegen SteamOS spricht, ist die Umsetzung des Immutable-Konzepts. Denn das ist vergleichsweise primitiv. Du kannst den Schreibschutz der Systemdateien aufheben und dann mit pacman ganz normal Software installieren, wie unter Arch auch. Das ist dann aber alles mit dem nächsten SteamOS-Update wieder weg, weil das komplette System-Image ausgetauscht wird. Wenn es irgendeine App nicht als Flatpak oder AppImage gibt, und sich auch nicht per Distrobox realisieren lässt, hast du unter SteamOS einfach keine Chance, das zu installieren. Unter Bazzite kannst du in einem solchen Fall dieses Paket mit rpm-ostree über das System-Image layern, das bleibt dann auch nach Updates erhalten.
Ich benutze beispielsweise CDEmu, um CD-Images von alten Spielen aus den 90ern einzubinden, da ich in meinen Rechnern keine CD-Laufwerke mehr verbaut habe. CDEmu benötigt ein Kernelmodul und lässt sich daher weder als Flatpak noch als AppImage realisieren. Auf dem Steam Deck unter SteamOS muss ich das nach jedem Update wieder installieren, weil mir jedes Update das wieder löscht. Unter Bazzite kann ich das layern, dann ist das auch nach Updates weiter da.
Das mag alles nicht so die große Rolle spielen, wenn man die Kiste, auf der man SteamOS nutzt, wirklich nur zum Zocken von modernen digitalen Spielen benutzen möchte. Allerdings hat SteamOS wirklich kein Alleinstellungsmerkmal, es ist eine stinknormale Linux-Distribution, die aber auch spezifische Optimierungen für schwache Hardware hat. Ich spiele damit ab und zu ja auch ein bisschen rum, und stelle immer wieder fest, dass die RAM-Belegung unter SteamOS zwar episch niedrig ist, in der Regel unter 8 GB, aber dafür brauchen Spiele wesentlich länger zum Laden, da guckst du teilweise eine Minute auf einen schwarzen Bildschirm. Bazzite oder CachyOS trauen sich da eher, auch den RAM zu benutzen, der vorhanden ist, und laden da einfach flotter.
Wobei man bei Bazzite gerade ein großes Sternchen hinter dem Label SteamOS-Ersatz setzen muss, denn deren Deck-Image wird seit längerer Zeit ziemlich umgebaut, das letzte stabile Release ist schon vom April und hat noch Kernel 6.17. Das neuere Build aus dem Testing-Branch ist super instabil und taugt nicht zum normalen Einsatz. Da fummeln die schon seit Monaten dran rum, dass ich so langsam das Gefühl habe, dass das nichts mehr wird. Das normale Desktop-Bazzite hat diese Probleme nicht, das ist auf aktuellem Softwarestand stabil.
mibbio schrieb:
Sehe darin für die meisten Nutzer auch keinen wirklichen Nachteil, selbst wenn sie längerfristig bei Linux bleiben wollen.
Ich sehe in den Immutable-Distros definitiv die Zukunft, es ist deutlich schwieriger, sich ein solches Immutable-System kaputtzubasteln. Android, macOS und iOS sind alle immutable, und damit sehr erfolgreich. Das ist die beste Chance, Linux aus der Nerd-Bubble rauszubekommen.
