Das Ding mit SteamOS 3

Das SteamDeck ist mit Abstand eines der besten Handheld Geräte das es aktuell gibt und evlt. auch jemals gab. Zumindest für mich persönlich. Als das Deck damals angekündigt wurde und man es vorbestellen konnte, war ich einer der ersten und habe auch eines der allerersten Q1 Steam Decks damals bekommen. Seit dem habe ich unzählige Stunden Spielzeit in das SteamDeck gesteckt. Auch nach diesem Artikel wird sich daran nichts ändern.

Dennoch, aus der Sicht von jemandem, der Linux auf dem Desktop seit über 20 Jahren einsetzt, gibt es unzählige Sachen die mich einfach nur an SteamOS Nerven, oder die ich persönlich anders gelöst hätte. Darum soll es in diesem Beitrag gehen.

Dateisysteme

Das wohl wildeste Konzept bzgl. SteamOS is die Wahl der Dateisysteme. Hier benutzt SteamOS 3 BtrFS für das Hauptdateisystem, während SD Karten und /home mit ext4 formatiert sind. Warum hier nicht auch BtrFS benutzt wird ist mir schleierhaft, mit Ausnahme, dass es ext4 schon seit etlichen Jahren gibt und evlt. die BtrFS Unterstürzung unter Arch Linux möglicherweise etwas suboptimal ist. Aber offensichtlich nicht so schlecht, dass man nicht das Hauptsysteme damit formatiert konnte.

Wer online danach sucht findet einen Haufen Desinformation über ext4 und Steam, z.B. dass Bestimmte Spiele oder Steam Features nur mit ext4 Funktionieren. Was natürlich Blödsinn ist. Als Nutzeranwendung ist das letzte mit dem man sich auseinandersetzten muss das zugrunde liegende Dateisystem. Hier werden abstrakte, read, write Methoden aufgerufen und wie dass dan im Dateisystem technisch umgesetzt ist ist uninteressant. Auch setzt Steam keine speziellen Dateiattribute die nur mit ext4 funktionieren würden.

Eines der vielen Vorteile von BtrFS gegenüber ext4 ist, dass es sich dabei um ein sogenannten Copy-on-Write (CoW) Dateisystem handelt. Das hat mehrere Vorteile, zum einen kann so von eingebauter Dedublikation gebraucht gemacht werden, gerade da SteamOS via Proton unzählige nahezu identische Proton-Prefixes anlegt, und diese aber jedes mal den kompletten Speicherplatz belegen, den so ein Prefix eben braucht. In einem CoW Dateisystem kann man hier massiv Speicherplatz sparren, da identische Speicherblöcke zwischen allen Prefixes geteilt werden können. Auch wenn dieser Deduplikationsprozess in BtrFS explizit angestoßen werden muss, wäre es dennoch keine Schwierigkeit beim anlegen eines neuen Prefix genau das zu tun. Oder man implementiert einen Dienst des genau dieses auf einer regelmäßigen Basis tut. Tatsächlich liefern die meisten Distributionen die mit BtrFS standartmaßgig daher kommen so einen Dienst mit aus.

Außerdem verfügt BtrFS über eine eingebaute Dateikompression, mit der nochmal zusätzlich Speicherplatz gespart werden kann. Warum also hier auf ext4 gesetzt wird is mir unbegreiflich. Zumal sich so auch die Lebensdauer eines Datenträgers verlängert, da, wie der name schon sagt, erst dann ein neuer Block auf dem Datenträger angelegt wird, wenn sich die Daten tatsächlich ändern. Für alles andere werden einfach nur Referenzen auf existierende Blöcke angelegt.

Der ganze Prozess benötigt zwar einen gewissen Overhead an Metadaten, dieser is aber vernachlässigbar klein im Anbetracht der Menge an Daten und Schreiboperationen die man so einspart.

Gerade auf der damals noch verfügbaren 64GB SteamDeck Variante hätte dies massiv an Kopfschmerzen eingespart. Da ich mir das 64GB Deck gekauft habe, hab ich das aus erster Hand erlebt. Mittlerweile habe ich die 64GB eCMM durch eine 265GB M.2 SSD ersetzt, aus eben diesen Gründen.

Alternative SteamOS Systeme wie Bazzite benutzen BtrFS eben genau aus diesem Grund für das ganze System. Mit aktivierter Dateikompression.

A/B Root

Eine weitere Unbegreiflichkeit ist der Einsatz von A/B Root (und /var). Das bedeutet, dass auf eurem Steam Deck SteamOS zweimal installiert ist und somit doppelten Platz benötigt.

Gerade da BtrFS für die Root Partition genutzt wird wirft das einige Fragen auf. Eine davon ist: Warum?

Nicht nur dass es sich um zwei unabhängige BtrFS Dateisysteme handelt und damit die Dedulikation zwischen den beiden unmöglich macht, kommt hinzu das BtrFS eingebaute Snapshot features besitzt mit allen Zusätzlichen Features die BtrFS besitzt.

Dass man so massiv noch mehr Platzsparen kann sollte an diesem Punk klar sein. Aber auch ermöglicht dies mehr als nur einen Wiederherstellungspunkt, um das Deck zurück zusetzten.

Darüber hinaus würde es auch ein schon seit immer bestehendes Problem lösen, dass Nutzer die zusätzliche Programme in das Basissystem installiert haben, nicht befürchten müssen, dass diese mit dem nächsten SteamOS Update wieder verschwinden. Da der der alte ungenutzte A/B Root gelöscht und durch ein neues sauberes, aktualisiertes, SteamOS Abbild ersetzt wird.

Außerdem bestünde dann auch keine Obergrenze von 5GiB Platz in /root um weitere Anwendungen zu installieren.

Point-Release Arch Linux

Eines der großen Neuerungen gegenüber dem alten SteamOS auf Debian basis ist, dass SteamOS nun auf ein rolling Release aufsetzt. Einer der Hauptgründe hier war, dass Debian zu alt ist und die Mesa Treiber teils auf die neusten Vulkan Erweiterungen, Leistungsverbesserungen etc. mehrere Jahre auf sich warten lassen könnten. Von daher unterstütze ich voll und ganz den Wechsel auf eine rolling release basis.

Nur nicht so wie es Valve getan hat. Denn das kuriose ist, dass sie mit SteamOS 3 ihr eigenen Frankenstein Point-Release geschaffen haben. So kommt SteamOS zwar mit (mehr oder weniger) aktuellem Mesa daher, aber so gut wie jede andere Komponente is teils älter als auf einem aktuellen Debian. Was mich persönlich stark an der Sicherheit von SteamOS zweifeln lässt.

Auch ist es mir nicht bekannt, dass Valve im Stable SteamOS Zweig regelmäßig Sicherheitslücken in Komponenten wie dem sudo, OpenSSL o.ä. korrigiert. Einen neue SteamOS Stable Version kommt maximal einmal im Jahr, vielleicht auch nur einemal alle 2 Jahre. Während in der Zwischenzeit bekannte Sicherheitslücken nicht korrigiert werden. Außer man wechselt auf den Beta oder Preview Kanal.

Dennoch bleibt die Standartkonfiguration auf Sable und erzeugt somit Millionen von Verwundbaren Geräte.

In meinem Artikel Linux auf dem Desktop, beschreibe ich weitere Probleme mit Point-Releases, die auch SteamOS unweigerlich betreffen.

Arch Linux basis fragwürdig

Vorweg, ich verstehe natürlich das Bestreben eine vollkommen von der Gemeinschaft bereits gestellte Linux Distribution als Basis zu wählen um nicht zu riskieren von einer anderen Firma abhängig zu sein. Das schränkt natürlich die Optionen massiv ein. Dennoch bin ich überzeugt das ein Tumbleweed basiertes SteamOS auf kurz oder lang die Bessere alternative gewesen wäre. Um meinen Standpunkt nachzuvollziehen muss ich etwas ausholen und einen Blick auf beide Projekte, also Arch Linux und das openSUSE Projekt, werfen.

Zu nächst, beide sind von der Gemeinschaft betriebene Projekte. Während bei Arch Linux die Software in the Public Interest (SPI) Finanzierung, Server und Infrastruktur bereitstellt, gilt selbiges für SUSE im Bezug auf das openSUSE Projekt. Dennoch verwalten sich beide unabhängig von ihrem "Sponsor". Entzieht natürlich einer von beiden, also die SPI oder SUSE den jeweiligen Projekten die Lebensgrundlage, dann war es dass für beide.

Während die SPI eine Gemeinnützige Organisation ist, und fast ausschließlich durch Spenden finanziert wird, sieht es bei SUSE als Anbieter von Linux Enterprise Lösungen etwas anders aus. Hier kann das openSUSE Projekt von der bereits für SUSE vorhandenen Infrastruktur profitieren, sowie von etwaigen SUSE Mitarbeitern die am openSUSE Projekt mitwirken.

Sowohl Arch Linux als auch das openSUSE Projekt werden vollständig von der Gemeinschaft betrieben. Sprich, jeder der zu dem jeweiligen Projekt beitragen will, kann dies einfach tun. Auch Entscheidungen über technische oder Architektonische Aspekte werden in beiden Fällen von der Gemeinschaft getroffen. Kann sich die Gemeinschaft nicht einigen, gibt es in beiden Fällen eine Instanz die dafür zuständig ist eben solche Streitfälle zu schlichten. Bei Arch Linux übernimmt diese Rolle die Projektleitung. Bei openSUSE das sogenannte openSUSE Board. Also ziemlich genau so wie Valve intern funktioniert.

In beiden Fällen werden Mitglieder von der Gemeinschaft gewählt und in beiden Fällen übernehmen sie keine Richtungsweisende Funktion. Ihre einzige Aufgabe besteht darin ein zentraler Ansprechpartner zu sein oder wie eben erwähnt, in Streitfällen bei denen sich die Gemeinschaft nicht selbständig einigen kann, eben diesen Streit beizulegen. Sprich im Falle des openSUSE Projekt kann auch SUSE nicht über eine Board Mitglied Richtungsweisende Entscheidungen durchdrücken.

Demnach sind sich die Art und Weiße wie Arch Linux funktioniert und das openSUSE Projekt sehr ähnlich. Natürlich kann aber in beiden Fällen entweder die SPI oder SUSE durch Androhung Finanzierungen oder Infrastruktur einzustellen indirekt Einfluss auf das jeweilige Projekt nehmen.

Da wir nun geklärt haben, wie beide Projekte Verwaltet werden können wir uns der Frage widmen, warum Tumbleweed, also das "openSUSE Rolling Release" statt Arch Linux.

Zum einen ist Tumbleweed, dank OpenQA, weit aus besser getestet als Arch Linux, da Arch Linux auf manuelle Test durch die jeweiligen Maintainer und der Gemeinschaft angewiesen ist. OpenQA ist eine automatisierte Testinfrastruktur die jedes Tumbleweed Release und jedes SOftwarepaket vor der Veröffentlichung immer wieder auf die selbe Art und Weise teste. So könne nicht nur mehr Tests in Kürzerer Zeit durchgeführt werden. Sondern auch diverse Systemkonfigurationen Parallel, für verschiedene Prozessor Architekturen getestet werden. Etwas was Arch Linux nicht macht, da es hier nur offiziell x86_64 unterstütz wird. Mit Hinblick auf das kommende, ARM basierte, Steam Frame wird das also noch interessant. Hier wird Valve vermutlich sein eigene Infrastruktur intern betreiben.

Desweiteren besteht im openSUSE Projekt eine sogenannte "Factory first" Richtlinie. Factory ist das was einmal ein neues Tumbleweed Release werden wird. Sprich der Großteil des Projektes dreht sich nur um Tumbleweed. Während "Ableger" wie Slowroll, Leap oder gar SUSE Linux Enterprise hinten anstehen. Aber auch nicht weiter interessant für diesen Artikel sind.

Mit Distributionen wie Aeon und Kalpa gibt und gab es auch bereits schon Unveränderliche Tumbleweed Versionen, auf die Valve einfach hätte aufbauen können. Zudem sind beide Versionen voll und ganz mit BtrFS ausgestattet, welches zuvor erwähnte Vorteile bringt. Beide aktualisieren sich transparent im Hintergrund und es besteht keine notwendigkeit ein neues SteamOS hinter einem Beta oder Preview Kanal zu verstecken. Sowie keine Notwendigkeit den Benutzer vor seinem Gerät sitzen zu lassen, während das neue Update angewendet wird. Beide, Aeon sowie Kalpa, müssen einfach nur Neugestartet werden und das neue aktualisierte System ist ohne Verzögerung direkt einsatzbereit.

Außerdem unterstüzt Tumbleweed, damit auch Aeon und Kalpa, SecureBoot. Anders als Arch Linux und SteamOS. Daher ist SecureBoot auf dem SteamDeck, wenn auch technisch möglich, mit SteamOS deaktiviert. Sogar Full Disk Encryption mit TPM 2.0 unlock wäre direkt von Haus aus unterstützt. Valve hätte keine eigene Signing Authority bereitstellen müssen. Automatisierte Updates würden es außerdem auch nicht erfordern den Pacman Paket Cache Manuell leeren zu müssen. Zu guter Letzt wäre die generelle Arbeitsbelastung für Valve extrem viel geringer und das System am Ende Stabiler und zuverlässiger.

Am Ende gehe ich trotzdem davon aus, das selbst ein Tumbleweed basiertes SteamOS von Valve weit gehend vom openSUSE Projekt abgekoppelt werden würde. Dennoch könnten sie einfach ihr eigene OpenQA oder Build Service hosten und die bestehenden Tumbleweed Test und Factory Pakete importieren.

Viele Sachen die Valve extra für SteamOS entwickelt hat, wäre bereits schon vorhanden gewesen.

Fedora eine Option?

Manch einer mag an dieser Stelle evtl. jetzt auch Fedora in den Mix werfen, das wäre auch eine Option, mehr oder weniger. Ähnlich wie Tumbleweed ist Fedora, zumindest auf dem Papier, eine von der Gemeinschaft gewartetes Projekt. Leider hat sich weder Red Hat noch das FESCo in der Vergangenheit mit Ruhm bekleckert was das Absägen von ganzen Projekten oder das Übergehen von Mitgliedern der Gemeinschaft angeht.

So hat Red Hat einst CentOS abgesägt und durch CentOS Stream ersetzt. Selbiges kann jeder Zeit mit Fedora passieren. Außerdem ist Fedora weitaus stärker mit Red Hat verzahnt als es für Tumbleweed und SUSE der Fall ist.

Darüber hinaus werden Positionen in den diversen Richtungsweisenden Körperschaften von Fedora durch Red Hat festgelegt, statt von der Gemeinschaft gewählt. Siehe hier zu:

• The Fedora Project Leader
• Fedora Community Architect (FCA)
• Fedora Operations Architect

Sprich das Risiko auf Fedora zusetzten, wäre für Valve immer genau das ein Risiko. Bei openSUSE gibt es zwar das openSUSE Borad, mit einem garantierten SUSE Mitglied. Wie zuvor erwähnt gibt das Board aber keine Richtung oder technische Entscheidungen vor, anders als es mit dem FESCo und Fedora der Fall ist. Bei Tumbleweed entscheidet ganz die Gemeinschaft.

Bugs, Bugs, Bugs

Von allen Desktop Linux Distributionen die ich im laufe der letzten 20+ Jahre vor der Nase hatte ist SteamOS eines der "unzuverlässigsten".Vermutlich maßgeblich aus zuvor erwähnten Gründen.

Natürlich könnte ich jetzt jeden noch so winzigen Fehler auflisten, der mir jemals unter gekommen ist, aber das würde wohl kaum ein Sinnvoller Beitrag sein. Stadtessen möchte ich mich hier auf Bugs beziehen die nur mit SteamOS auftreten / getreten sind, aber nicht mit Tumbleweed, bzw. Aeon oder Kalpa auf der selben Hardware.

Gamescope stürzte mit Steam Link ab

Ein lange anhaltender Fehler im SteamOS war, das unter Verwendung von Steam Link der Gamescope Compositor abstürzte wenn man versuchte vom SteamDeck auf etwa den PC zu streamen. Zwischenzeitlich wurde dieser Fehler behoben, um mit 2 SteamOS Versionen später wieder eingeführt zu werden. Um dann noch mal etwas später wieder behoben zu werden.

Fairerweise trat dieser Fehler auch mit Tumbleweed auf, allerdings kam hier das Gamescope Update signifikant früher also in SteamOS stable.

Ein ordentlicher OpenQA Test hätte hier vermutlich geholfen.

Mesa Fehler

Etwas was mir auch immer mal wieder begegnet sind Fehler im Mesa Treiber, die bei der gleichen Version unter Tumbleweed mit ebenfalls einer AMD Grafikkarte (z.B. ebenfalls auf dem SteamDeck) nicht auftreten. Siehe hierzu den Bug report zu OpenArena auf dem SteamDeck.

Steam Oberfläche hängt sich auf

Obwohl ich ein vollständig unmodifiziertes SteamOS verwende und den Stable Zweig, passiert es recht oft, dass nach längeren Standby Phasen die Steam Oberfläche sich aufhängt, sobald ich ein Spiel starte. Was dazu führt, dass das System mit Gewalt aus geschaltet werden muss. Also sprich der Power-Button für mehrere Sekunden gedrückt gehalten wird.

SteamInput stürzt ab

Auch ein Problem, was mir so in Stundenlangen Gaming Sessions auf meinem Tumbleweed basierten Kalpa noch nie untergekommen ist, ist, dass SteamInput einfach abstürzt und keine Controller eingaben mehr erkannt werden. Meist startet SteamInput sich selbst wieder neu. Nur ist man dann im Spiel meistens schon irgendwo herunter gefallen oder von einem Boss platt gemacht worden. Ärgerlich, passiert zum Glück nicht so oft.

Probleme mit Externen Anzeigegeräten

Ein beliebtes Problem mit SteamOS ist auch, das Verbinden mit einem Fernseher. Hier passiert es ab und an dass SteamOS zwar das interne Display abschaltet, aber weder Audio noch Bildausgabe auf dem externen Anzeigegerät raus kommt. Einziger "Fix" für dieses Problem ist SteamOS mehrmals neuststarten, am besten während der Fernseher angeschlossen ist, oder undefiniert oft die Docking Station ab und wieder an zu stöpseln. Eine Garantie gibt es heir aber nicht. Irgendwas funktioniert es dann wieder und es dauert eine ganze Weile bis das pRoblem dann wieder mal auftritt.

Zeitweise hatte ich ein Aeon auf einer SD Karte auf dem Deck als Dual Boot installiert, jenes PRoblem ist dort nie aufgetreten. Zugrunde liegt vermutlich der deutlich aktuellere Software Stack von Tumbleweed gegenüber SteamOS. Inklusive AMD Firmware.

Flatpak

Auch sind SteamOS spezifische Fehler im Zusammenhang mit Flatpak leider keine Seltenheit.

Zum einen installiert SteamOS all flats Systemweit, also unter /var/ und somit auch für den root. Für ein Einzelbenutzer System wie das Steam Deck, auf dem es nur einen Steam User gibt, egal wie viele Steam Accounts auf dem Gerät hinterlegt sind, eine interessante Entscheidung. Zudem setzt es voraus, das /var/ root Zugriff braucht um dort Anwendungen hin zu installieren.

Da SteamOS nicht nach einem Superuser Passwort fragt um Flatpaks zu installieren, verfügt der Benutzer also ohne Passwort über root Zugriff auf dem Gerät. Das birgt unweigerlich einige Sicherheitsrisiken. Sprich, aus einem Flatpak heraus könnte man einfach über flatpak-spawn --host beliebige Befehle via sudo oder kdesu abfeuern ohne dass der Benutzer auch nur ein einziges mal ein Passwort eingeben müsste.

Aber das ist nicht dass, worauf ich eigentlich hinaus wollte. Mir is aufgefallen, dass wenn ein externes Anzeigegerät an SteamOS angeschlossen ist, das der flatpak Firefox nicht mehr in der Lage ist den Bildschirmschoner oder Ruhemodus zu unterdrücken, solange ein Video läuft. Ist nur das interne Display in Verwendung besteht dieses Problem nicht. Sprich, schaut man Netflix oder dergleichen von seiner Couch aus wird SteamOS den Fernseher irgendwann abschalten und die Bild- sowie Tonwiedergabe auf den eingebauten Display und Lautsprechern fortsetzen. Außer man unterbindet diesen Modus über die Energieoptionen aktiv und manuell.

(SteamOS - Firefox Flatpak unterbindet Ruhemodus und Bildschirmsperre nicht)

(Kalpa Desktop - Firefox Flatpak unterbindet Ruhemodus und Bildschirmsperre ordnungsgemäß)

Gehen wir ein paar Schritte zurück zum Abschnitt A/B Root, stellen wir fest dass auch /var eine A/B Partitionierung aufweist. Trotzdem verschwinden Flatpak Anwendung von SteamOS Version zu SteamOS Version nicht. Daraus lässt sich schließen, dass es hier eine art Migrationsprozess geben muss um Var-A nach Var-B und umgekehrt zu migrieren. Würde man Flatpaks im Nutzerverzeichnis installieren, bestünden hier keinerlei Probleme. Man könnte sogar alles zu BrtFS migrieren und würde so auch keine Snapshots der flatpaks in /var anlegen.

Als kleiner Einschub, für /var Benutzen Aeon und Kalpa ein Overlayfs um die Konsistenz zwischen /var und einem BtrFS Snapshots zu wahren und rollbacks zu ermöglichen.

Bluetooth

Ein anderes Problem, was mir während dieses Artikel ins Auge gefallen ist, ist dass Dateifreigaben über Bluetooth mit SteamOS nicht funktionieren. Während selbiges mit keinem meiner anderen Linux Systeme ein Problem darstellt.

KDE Connect

Via KDE Connect kann auch kein Gerät mit SteamOS verbunden werden, da keine Geräte gefunden werden können. Während selbiges eines der Zentralen Tools ist, mit dem ich zwischen meinen anderen Geräten Dateien hin und her schieben, da dies meist schneller als via Bluetooth geht. Auch können andere Linux Geräte das SteamDeck nicht finden.

Ich habe auch hier die out-of-date SteamOS Software im Verdacht. Womit sich dieser Artikel sehr gut mit dem zuvor erwähnten Linux auf dem Desktop Artikel verbindet.

Schlusswort

Dass soll es aber auch ersteinmal gewesen sein. Natürlich steht es jedem frei meine Meinung zu teilen oder Argumentation anzufechten. Für viele funktioniert SteamOS schließlich gut genug, so auch für mich. Ich bin immer offen für Diskussionen.

Mein Resüme bleibt vorerst: ein Tumbleweed basiertes StemOS wäre die weit aus beste Lösung gewesen, würde massiv Arbeit sparen, Valve entlasten, zu einem weit aus stabilerem und Fehlerfreierem SteamOS beitragen und Nutzer nicht mit endlos vielen Sicherheitslücken zurück lassen.

Außerdem würde ein solches SteamOS selbst nach dem Valve den Support eingestellt hätte weiter rollen, vorausgesetzt die upstream-tumbleweed Quellen sind natürlich im System hinterlegt.

Beim Arch basierten SteamOS bedient sich Valve ausschließlich seiner eigenen Paketquellen. Eine notwendiges Übel, wenn man Arch Linux als basis gewählt hat und nicht will, das jede Woche ein SteamOS irgendwo den Dienst versagt oder man von den Nutzer verlangt die Arch Linux News zu lesen.

Nicht desto trotz bin ich hell weg begeistert von dem SteamDeck, auch wenn ich mit SteamOS vorlieb nehmen muss. Die meiste Zeit funktioniert das Gerät und das System tadellos. Die architektonischen Entscheidungen die Valve getroffen hat, mögen zwar fragwürdig sein, aber als Endanwender kommt man damit nicht unbedingt in Berührung. Es sei denn man hat ein 64GB SteamDeck...

In dem Sinne, fröhliches Gaming und ich kann den Release vom Steam Frame kaum noch abwarten!

Update

2026-02-01

• SteamOS Flatpak Problematik aktualisiert, da doch nicht behoben