The thing about SteamOS 3

For me, the Steam Deck is still one of the best handheld devices of all time. I've been using mine since the very first Q1 shipment, and I've spent countless hours with it. Nothing in this article will change that.

That's exactly why some decisions around SteamOS 3 bother me all the more. From the perspective of someone who has used Linux on the desktop for over 20 years, there are a number of points here that feel unnecessarily complicated, underdeveloped, or simply questionable. That's what this contribution is about.

File systems

If you research this topic online, you quickly run into a lot of half-truths. Especially around Steam, Proton, and Linux file systems, people often repeat claims that don't hold up when you look more closely. As an application, Steam normally doesn't need to directly deal with the underlying file system.

That's exactly why I find it questionable that, outside the root file system, ext4 is still so strongly favored. In this environment, Btrfs brings several practical benefits that would be quite relevant on a device like the Steam Deck.

One example is Proton prefixes. Many of them contain very similar data sets, which makes them an ideal candidate for more efficient storage management. A CoW file system makes it easier to manage identical data blocks better with additional deduplication, it could potentially save a noticeable amount of memory across many similar prefixes.

There's also Btrfs's built-in compression. On devices with limited storage, that's not a purely theoretical advantage, it can make a difference in everyday use. Why Valve doesn't use these strengths more consistently outside the root file system is hard for me to understand.

A/B root

Another design decision I struggle to understand is the use of A/B root alongside A/B-/var. The underlying idea is of course clear: updates should be applied as robustly as possible, and in case of problems, it should be possible to roll back.

The part that's most problematic for me is that two separate system states are maintained side by side, even though Btrfs already provides its own snapshot and rollback mechanisms. In my view, that wastes some of the advantages that such a file system could actually deliver.

In my opinion, a snapshot-based approach would also have an additional benefit: changes to the base system could be kept under tighter control or rolled back more precisely, rather than being overwritten in the next major update. On a Linux system that already relies on Btrfs from a technical standpoint, the chosen solution feels unnecessarily convoluted to me.

Point release on an Arch Linux basis

In principle, it's of course legitimate to derive a more tightly controlled product from a rolling-release base. Many projects do exactly that in one form or another. The problem for me is, however, how Valve implemented this approach specifically in SteamOS 3.

Valve has essentially built a kind of in-between model: it's no longer truly a rolling release, but it's also not a classic, cleanly maintained point release. Some individual components are kept relatively up to date, while other parts stay frozen much longer. From a product perspective, that may be understandable, but in my view it creates an unnecessarily hard-to-maintain intermediate state.

From the outside, it also isn't always clear how consistently security-relevant components are pulled in on the stable branch. Because the standard configuration on the stable branch is rolled out for a very large number of devices in almost identical form, delays, or outdated leftovers, in central components weigh particularly heavily in my opinion.

I discuss the different release models and their pros and cons again here and here.

Arch Linux basis: questionable

To start with: I understand the desire to choose a distribution as a base that doesn't fully depend on a single company. That significantly limits the options. Still, I consider a SteamOS based on Tumbleweed the more convincing long-term solution.

To put this into context, it's worth taking a brief look at the two projects: Arch Linux and openSUSE. Both are community-maintained rather than centrally managed like a pure company product. For me, the crucial difference therefore isn't primarily formal independence, but the technical maturity of the respective base.

Tumbleweed is tested much more systematically with OpenQA, while Arch Linux relies much more heavily on manual checks by maintainers and the community. For a product like SteamOS, this kind of reproducible, broadly based test coverage is a real advantage.

With the now publicly available Holo-Core preview, the problem also shows up quite concretely. For the ARM64-based Steam Frame, Valve and Collabora first had to create their own Arch-based foundation for aarch64, including additional tooling and CI infrastructure, because Arch Linux doesn't officially support this architecture upstream. What was published explicitly wasn't a complete port yet, but only the package set needed for development and image building, and even that already includes several thousand packages. See also: Holo-Core Experimental ARM64.

That, for me, is the core of the problem: rather than building on a base that already brings multi-architecture support, reproducible build paths, and part of this distribution's work, Valve has to organize large parts of the necessary infrastructure itself. With Tumbleweed, by contrast, reproducible builds from the same package base for x86_64, aarch64, and other architectures have been part of the existing build and release infrastructure for years.

Ultimately, this isn't just build and test infrastructure, but also release processes, and the question of which instance controls the technical trust chain via signatures and published images. That's also a space where, around Arch, additional distribution work is generated, work you could at least partly avoid with a more strongly productized base.

For me, this illustrates pretty well what I mean when I say that in many cases the wheel is reinvented here.

Fedora as an alternative?

At first glance, Fedora could also be a plausible candidate. What speaks against it for me is that Fedora is much more tightly bound organizationally and strategically to Red Hat than Tumbleweed is to SUSE. If you consciously look for a base that isn't shaped too strongly by the decisions of a single company, then Tumbleweed feels like the more obvious alternative.

Bugs, bugs, bugs

Of all the desktop Linux distributions I've used more intensively over the past few years, SteamOS is unfortunately one of the less reliable ones. That's especially frustrating, because on the Steam Deck the system should be able to run quietly and robustly in the background.

Rather than getting lost in an endless list of errors, I want to focus on a few typical examples that I've actually encountered in everyday use. That's where it becomes clear to me that SteamOS often doesn't feel like a particularly cleanly polished product, but rather like a system still struggling with itself in several places.

Gamescope crashes with Steam Link

One issue I've been able to observe repeatedly happened when using Steam Link. In certain situations, Gamescope would crash, making the session effectively unusable. Because Steam Link isn't some rare edge case but a core function within the broader Steam ecosystem, that kind of failure is especially irritating to me.

What makes this error even more annoying is it is random for whom this happens and for whom not. I use an entirely unmodified SteamOS yet it happens to me. Other SteamDeck users I talked to, don't have this issue while others do as well.

Mesa issues

Something else that I've run into again and again are graphics problems that looked very strongly like Mesa-related failure modes. Sometimes they show up as rendering glitches, and sometimes as unstable behavior in specific applications or games. These kinds of things happen on Linux in general, of course, but on SteamOS I've noticed them much more frequently relative to other distributions.

Steam interface freezes

An issue I've run into on SteamOS in the stable branch, but also in beta and even preview, occurs after longer standby periods: when I then launch a game, the entire Steam interface occasionally freezes. In practice, that often leaves me with little choice but a hard restart via the power button.

That's why this bug bothers me so much: it isn't an exotic edge case, but a typical use situation for a handheld device. On my Tumbleweed-based Kalpa, I haven't encountered this behavior in a comparable form so far.

Steam Input crashes

Crashes related to Steam Input have also happened to me repeatedly during longer gaming sessions. This is especially annoying because it's not some minor edge feature, it's a central part of the device's actual control experience. When the input layer and the interface get in each other's way, it hits the user experience directly at its most sensitive point.

Problems with external display devices

Another recurring problem involves external displays. Especially in docked mode, I repeatedly ran into situations where outputs weren't detected cleanly, resolutions didn't match, or the behavior felt unnecessarily unreliable after unplugging and reconnecting. For a device that's explicitly meant to serve as a living-room and TV system too, this is, in my view, an avoidable weak spot.

Flatpak

Handling Flatpak also raises a number of questions for me. For one, SteamOS installs Flatpaks system-wide under /var/ instead of in the user directory. For a device like the Steam Deck, which in practice is mostly used as a single-user system, I think this is at least a debatable decision.

The fact that SteamOS doesn't prompt for a separate superuser password in the classic way during installation also makes me wonder about the exact boundary of permissions and trust. In my view, what's being created here is a comparatively generous model, one that should be cleanly limited technically and easy to understand.

What I'm really trying to get at, though, is the fundamental inconsistency in the system design. If the base system is strongly sandboxed, updated atomically, and designed to be as immutable as possible, then it feels odd to open up, elsewhere, comparatively generous and persistent system-wide add-on paths. Architecturally, I don't think that comes together very neatly.

On top of that, there are weaknesses in the implementation of XDG portals, for example, preventing the screen blanker or screen lock from being disabled by a Flatpak application. If you run SteamOS on an external display device, it doesn't work. Firefox, while watching a video in the browser, behaves one way there under SteamOS and another under Kalpa Desktop, with the same Firefox Flatpak.

(SteamOS - Firefox Flatpak underbinds sleep mode and screen lock)

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

Bluetooth

Another issue that stood out to me again while revisiting and editing this article: file sharing over Bluetooth isn't reliable for me under SteamOS. This isn't a core feature of the device, but it's exactly the kind of everyday detail where a system either feels polished or unfinished.

KDE Connect

Something similar applies to KDE Connect. In principle, this is a function that should fit excellently into the whole picture on a Linux-based device. In practice, though, I repeatedly ran into discovery and connection problems under SteamOS. Especially comfort features like these strongly influence whether a system feels integrated and smooth, or instead feels clunky in daily use.

KDE Connect under Aeon Desktop

KDE Connect under SteamOS 3

Closing words

That should be enough for now.

My preliminary conclusion is this: in my view, a Tumbleweed-based foundation would have been a significantly more robust solution for SteamOS. It would have reduced Valve's workload in many places, made better use of existing infrastructure, and likely led to a more consistent and maintenance-light system.

With the Arch-based SteamOS, on the other hand, I keep getting the impression that Valve had to recreate many components, processes, and technical paths itself, despite the fact that for many of these problems, there are already workable solutions elsewhere that have existed for years.

As a side note: the Open Build Service and openQA from openSUSE can be self-hosted and even support Arch Linux as a target distribution. Just saying, Valve!

Even so, I'm still fully and genuinely excited about the Steam Deck. The device itself is excellent, and many users will never directly run into most of the architecture and maintenance questions discussed here. What I can't quite shake, though, is the thought that with a different base, there would likely have been much more to be gained in many of these areas.

Update

2026-07-23

• Added an aarch64 port of SteamOS as a supporting argument
• Improved readability of the entire article and trimmed it back in places where it wasn't necessary

2026-02-01

• Updated the SteamOS Flatpak issue, since it has not actually been fixed