Das Ding mit SteamOS 3

Das Steam Deck ist für mich bis heute eines der besten Handheld-Geräte überhaupt. Ich nutze meines seit der ersten Q1-Auslieferung und habe unzählige Stunden damit verbracht. Daran wird auch dieser Artikel nichts ändern.

Gerade deshalb stören mich manche Entscheidungen rund um SteamOS 3 umso mehr. Aus der Sicht von jemandem, der Linux auf dem Desktop seit über 20 Jahren nutzt, gibt es hier etliche Punkte, die unnötig kompliziert, unausgereift oder schlicht fragwürdig wirken. Genau darum geht es in diesem Beitrag.

Dateisysteme

Wer sich online zu dem Thema einliest, stößt schnell auf eine Menge Halbwissen. Gerade rund um Steam, Proton und Linux-Dateisysteme werden oft Behauptungen wiederholt, die bei näherem Hinsehen wenig überzeugend sind. Als Nutzeranwendung muss sich Steam mit dem zugrunde liegenden Dateisystem im Normalfall gar nicht direkt auseinandersetzen.

Gerade deshalb halte ich es für fragwürdig, dass außerhalb des Root-Dateisystems weiterhin so stark auf ext4 gesetzt wird. Btrfs bringt in diesem Umfeld mehrere praktische Vorteile mit, die auf einem Gerät wie dem Steam Deck durchaus relevant wären.

Ein Beispiel dafür sind Proton-Präfixe. Viele davon enthalten sehr ähnliche Datenbestände, was sie geradezu zu einem idealen Kandidaten für effizientere Speicherverwaltung macht. Ein CoW-Dateisystem erleichtert es, identische Datenblöcke besser zu verwalten; mit zusätzlicher Deduplizierung ließe sich bei vielen ähnlichen Präfixen potenziell spürbar Speicher sparen.

Dazu kommt die eingebaute Kompression von Btrfs. Gerade auf Geräten mit begrenztem Speicherplatz ist das kein völlig theoretischer Vorteil, sondern kann sich im Alltag durchaus bemerkbar machen. Warum Valve diese Stärken außerhalb des Root-Dateisystems nicht konsequenter nutzt, bleibt für mich schwer nachvollziehbar.

A/B Root

Eine weitere Designentscheidung, die ich nur schwer nachvollziehen kann, ist der Einsatz von A/B Root samt A/B-/var. Die Grundidee dahinter ist natürlich klar: Updates sollen möglichst robust eingespielt und bei Problemen wieder zurückgerollt werden können.

Problematisch ist für mich vor allem, dass hier zwei getrennte Systemstände nebeneinander gepflegt werden, obwohl Btrfs bereits eigene Snapshot- und Rollback-Mechanismen mitbringt. Dadurch verschenkt man aus meiner Sicht einen Teil der Vorteile, die ein solches Dateisystem eigentlich liefern könnte.

Ein snapshot-basierter Ansatz hätte aus meiner Sicht noch einen weiteren Vorteil: Änderungen am Basissystem ließen sich kontrollierter erhalten oder gezielter zurückrollen, statt beim nächsten größeren Update unter Umständen wieder überschrieben zu werden. Gerade auf einem Linux-System, das technisch ohnehin bereits auf Btrfs aufsetzt, wirkt die gewählte Lösung auf mich unnötig umständlich.

Point-Release auf Arch-Linux-Basis

Grundsätzlich ist es natürlich legitim, aus einer Rolling-Release-Basis ein stärker kontrolliertes Produkt abzuleiten. Genau das tun viele Projekte in irgendeiner Form. Problematisch ist für mich aber, wie Valve diesen Ansatz bei SteamOS 3 konkret umgesetzt hat.

Valve hat sich damit im Grunde eine Art Zwischenmodell gebaut: nicht mehr wirklich Rolling Release, aber auch kein klassisches, sauber gepflegtes Point Release. Einzelne Komponenten werden vergleichsweise aktuell gehalten, anderes bleibt deutlich länger eingefroren. Das mag aus Produktsicht nachvollziehbar sein, erzeugt aus meiner Sicht aber einen unnötig schwer wartbaren Zwischenzustand.

Von außen ist für mich zudem nicht immer klar erkennbar, wie konsequent sicherheitsrelevante Komponenten im Stable-Zweig laufend nachgezogen werden. Gerade weil die Standardkonfiguration auf dem Stable-Zweig für sehr viele Geräte nahezu identisch ausgerollt wird, wiegen Verzögerungen oder Altlasten bei zentralen Komponenten aus meiner Sicht besonders schwer.

Über die verschiedenen Release Modelle und ihre Vor- sowie Nachteile spreche ich auch noch einmal hier und hier.

Arch-Linux-Basis fragwürdig

Vorweg: Ich verstehe natürlich den Wunsch, eine Distribution als Basis zu wählen, die nicht vollständig von einem einzelnen Unternehmen abhängt. Das schränkt die Auswahl deutlich ein. Trotzdem halte ich ein auf Tumbleweed basiertes SteamOS langfristig für die überzeugendere Lösung.

Um das einzuordnen, lohnt sich ein kurzer Blick auf die beiden Projekte: Arch Linux und openSUSE. Beide werden gemeinschaftlich getragen und nicht einfach zentral wie ein reines Firmenprodukt verwaltet. Der entscheidende Unterschied liegt für mich deshalb nicht primär in der formalen Unabhängigkeit, sondern in der technischen Reife der jeweiligen Basis.

Tumbleweed ist mit OpenQA wesentlich systematischer getestet, während Arch Linux deutlich stärker von manueller Prüfung durch Maintainer und Community abhängt. Für ein Produkt wie SteamOS ist genau diese reproduzierbare, breit angelegte Testabdeckung ein echter Vorteil.

Mit dem inzwischen öffentlich gewordenen Holo-Core-Preview zeigt sich das Problem auch ganz praktisch: Für das ARM64-basierte Steam Frame mussten Valve und Collabora erst einmal einen eigenen Arch-Unterbau für aarch64 schaffen, einschließlich zusätzlicher Tooling- und CI-Infrastruktur, weil Arch Linux diese Architektur upstream nicht offiziell unterstützt. Veröffentlicht wurde dabei ausdrücklich noch kein vollständiger Port, sondern zunächst der für Entwicklung und Image-Bau benötigte Paketbestand, und selbst der umfasst bereits mehrere tausend Pakete. Siehe dazu auch: Holo-Core Experimental ARM64.

Genau darin liegt für mich der Kern des Problems: Statt auf einer Basis aufzusetzen, die Mehrarchitektur, reproduzierbare Build-Pfade und einen Teil dieser Distributionsarbeit bereits mitbringt, muss Valve wieder erhebliche Teile der nötigen Infrastruktur selbst organisieren. Bei Tumbleweed sind reproduzierbare Builds aus derselben Paketbasis für x86_64, aarch64 und weitere Architekturen dagegen seit Jahren Teil der vorhandenen Build- und Release-Infrastruktur.

Dazu gehören letztlich nicht nur Build- und Test-Infrastruktur, sondern auch Release-Prozesse und die Frage, welche Instanz die technische Vertrauenskette über Signaturen und veröffentlichte Images kontrolliert. Auch das ist ein Bereich, in dem rund um Arch zusätzliche Distributionsarbeit entsteht, die man sich mit einer stärker produktisierten Basis zumindest teilweise sparen könnte.

Für mich illustriert das ziemlich gut, was ich meine, wenn ich sage, dass hier oft das Rad neu erfunden wird.

Fedora als Alternative?

Fedora wäre auf den ersten Blick ebenfalls ein denkbarer Kandidat. Für mich spricht aber dagegen, dass Fedora organisatorisch und strategisch deutlich enger an Red Hat gebunden ist, als Tumbleweed an SUSE. Wenn man bewusst eine Basis sucht, die nicht zu stark von den Entscheidungen eines einzelnen Unternehmens geprägt ist, wirkt Tumbleweed für mich deshalb als naheliegendere Alternative.

Bugs, Bugs, Bugs

Von allen Desktop-Linux-Distributionen, die ich in den letzten Jahren intensiver genutzt habe, gehört SteamOS für mich leider zu den unzuverlässigeren. Das ist deshalb so ärgerlich, weil das System auf dem Steam Deck eigentlich möglichst unauffällig und robust im Hintergrund funktionieren sollte.

Statt mich hier in einer endlosen Fehlerliste zu verlieren, möchte ich mich auf ein paar typische Beispiele beschränken, die mir im Alltag tatsächlich begegnet sind. Denn genau dort zeigt sich für mich, dass SteamOS an vielen Stellen nicht wie ein besonders sauber ausgereiftes Produkt wirkt, sondern eher wie ein System, das an mehreren Ecken noch mit sich selbst ringt.

Gamescope stürzt mit Steam Link ab

Ein Problem, das ich wiederholt beobachten konnte, trat bei der Nutzung von Steam Link auf. In bestimmten Situationen stürzte dabei Gamescope ab, was die Sitzung entsprechend unbrauchbar machte. Gerade weil Steam Link kein exotischer Sonderfall ist, sondern eine Kernfunktion im weiteren Steam-Ökosystem, wirkt so ein Fehler auf mich besonders störend.

Was diesen Fehler um so nerviger macht ist die Tatsache, das er nicht für jeden gleichermaßen auftritt. In meinem Fall, auf einem unveränderten SteamOS tritt der Fehler auf. Andere SteamDeck Benutzer, mit denen ich darüber gesprochen habe, haben das Problem nicht, andere wiederum schon.

Mesa-Fehler

Etwas, das mir ebenfalls immer wieder begegnet ist, sind Grafikprobleme, die sehr stark nach Mesa-bedingten Fehlerbildern aussahen. Mal äußert sich das in Darstellungsfehlern, mal in instabilem Verhalten einzelner Anwendungen oder Spiele. Solche Dinge passieren unter Linux natürlich generell, aber auf SteamOS sind sie mir im Verhältnis zu anderen Distributionen einfach zu häufig aufgefallen.

Steam-Oberfläche hängt sich auf

Ein Problem, das mir auf SteamOS im Stable-Zweig, aber auch Beta und sogar Preview, immer wieder begegnet, tritt nach längeren Standby-Phasen auf: Starte ich danach ein Spiel, friert gelegentlich die gesamte Steam-Oberfläche ein. In der Praxis bleibt dann oft nur ein harter Neustart über den Power-Button.

Gerade deshalb stört mich der Fehler so sehr: Es geht nicht um einen exotischen Randfall, sondern um eine typische Nutzungssituation für ein Handheld-Gerät. Auf meinem Tumbleweed-basierten Kalpa ist mir dieses Verhalten in vergleichbarer Form bislang nicht begegnet.

Steam Input stürzt ab

Auch Abstürze rund um Steam Input sind mir in längeren Spielsitzungen immer wieder begegnet. Das ist vor allem deshalb lästig, weil es keine Randfunktion betrifft, sondern einen zentralen Teil der eigentlichen Gerätebedienung. Wenn Eingabeschicht und Oberfläche ins Stolpern geraten, trifft das das Nutzungserlebnis direkt an seinem empfindlichsten Punkt.

Probleme mit externen Anzeigegeräten

Ein weiteres wiederkehrendes Problem betrifft externe Displays. Gerade im Docked-Betrieb hatte ich immer wieder Situationen, in denen Ausgaben nicht sauber erkannt wurden, Auflösungen nicht stimmten oder sich das Verhalten nach dem Umstecken unnötig unzuverlässig anfühlte. Für ein Gerät, das ausdrücklich auch als Wohnzimmer- und TV-System taugen soll, ist das aus meiner Sicht eine unnötige Schwachstelle.

Flatpak

Auch der Umgang mit Flatpak wirft für mich einige Fragen auf. Zum einen installiert SteamOS Flatpaks systemweit unter /var/ statt im Nutzerverzeichnis. Für ein Gerät wie das Steam Deck, das faktisch meist als Einzelbenutzersystem verwendet wird, halte ich das zumindest für eine diskussionswürdige Entscheidung.

Dass SteamOS bei der Installation dabei nicht klassisch nach einem separaten Superuser-Passwort fragt, wirft für mich zudem Fragen nach der genauen Rechte- und Vertrauensgrenze auf. Aus meiner Sicht entsteht hier ein vergleichsweise großzügiges Modell, das technisch sehr sauber begrenzt und nachvollziehbar sein sollte.

Worauf ich aber eigentlich hinaus will, ist die grundsätzliche Inkonsistenz im Systemdesign. Wenn das Basissystem stark abgeschottet, atomar aktualisiert und möglichst unveränderlich gedacht ist, wirkt es seltsam, an anderer Stelle dann doch wieder verhältnismäßig großzügige und persistent systemweite Zusatzpfade zu eröffnen. Das fügt sich für mich architektonisch nicht besonders sauber zusammen.

Hinzu kommen schwächen in der implementation von XDG-Portals um zum Beispiel aus einer Flatpak-Anwendung heraus den Bildschirmschoner oder die Bildschirmsperre zu unterbinden. Betreibt man SteamOS an einem externen Anzeigegerät funktioniert das nicht. Hier Firefox während man ein Video im Browser schaut. Unter SteamOS funktioniert das nicht, under Kalpa Desktop schon, mit dem selben Firefox-Flatpak.

(SteamOS - Firefox Flatpak unterbindet Ruhemodus und Bildschirmsperre nicht)

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

Bluetooth

Ein weiteres Problem, das mir beim Überarbeiten dieses Artikels erneut aufgefallen ist: Dateifreigaben per Bluetooth funktionieren unter SteamOS bei mir nicht zuverlässig. Das ist keine Kernfunktion des Geräts, aber eben genau die Art von Alltagsdetail, bei der ein System entweder rund wirkt oder unfertig.

KDE Connect

Ähnlich sieht es bei KDE Connect aus. Grundsätzlich ist das eine Funktion, die auf einem Linux-basierten Gerät eigentlich hervorragend ins Gesamtbild passen müsste. In der Praxis hatte ich damit unter SteamOS aber immer wieder Erkennungs- und Verbindungsprobleme. Gerade solche Komfortfunktionen tragen stark dazu bei, ob sich ein System im Alltag integriert oder hakelig anfühlt.

KDE Connect unter Aeon Desktop

KDE Connect unter SteamOS 3

Schlusswort

Das soll es aber auch erst einmal gewesen sein.

Mein Resümee bleibt vorerst: Ein Tumbleweed-basierter Unterbau wäre für SteamOS aus meiner Sicht die deutlich robustere Lösung gewesen. Er hätte Valve an vielen Stellen Arbeit abgenommen, bestehende Infrastruktur besser genutzt und vermutlich zu einem konsistenteren, wartungsärmeren System geführt.

Beim Arch-basierten SteamOS habe ich dagegen immer wieder den Eindruck, dass Valve sich viele Bausteine, Prozesse und technische Pfade selbst neu schaffen musste, obwohl es für etliche dieser Probleme andernorts bereits seit Jahren tragfähige Lösungen gibt.

Als randbemerkung, der Open Build Service und OpenQA von openSUSE können selbst gehostet werden und unterstützen zu dem sogar auch Arch Linux als Ziel Distribution. Nur mal so am Rande, Valve!

Nichtsdestotrotz bin ich nach wie vor hellauf begeistert vom Steam Deck. Das Gerät selbst ist hervorragend, und viele Nutzer werden mit den meisten der hier angesprochenen Architektur- und Wartungsfragen nie direkt in Berührung kommen. Mich lässt nur der Gedanke nicht los, dass mit einer anderen Basis an vielen Stellen noch deutlich mehr drin gewesen wäre.

Update

2026-07-23

• aarch64 Port von SteamOS als bekräftigendes Argument hinzugefügt
• Lesbarkeit des gesamten Artikel verbessert und an unnötigen Stellen beschnitten

2026-02-01

• SteamOS Flatpak Problematik aktualisiert, da doch nicht behoben