The thing about SteamOS 3
Complaining at a high level about Valve's SteamOS 3 and what could be done better.
The SteamDeck is for me easily on of the best handheld gaming devices ever released. I was one of the first to pre-order the SteamDeck and received one of the early Q1 SteamDecks. Since then I spend countless hours playing on the device. Not even this article will change that.
But still from someone using Linux on Desktop for over 20 years there are quite a few things which annoy me on SteamOS or which I had have solved differently. That's what this article is about.
Filesystems
Some of the wildest concepts about SteamOS is the way they choose to format the device. While it uses BtrFS for it's main system partition everything else is formatted as ext4. Why Valve didn't opted-in for BtrFS everywhere is not very clear to me. Beside ext4 being around since forever and maybe the BtrFS support in Arch Linux being a little flunky. But not flunky enough to no format the main system partition with it, apparently.
Looking up this online I stubbled over quite a lot of misinformation regarding ext4 and Steam. Like certain features do not work with other filesystems but ext4. Which is nonsense for me. The least thing a user space application has to care about is the underlying filesystem. I mean there are some abstract red, write function which simply get called by an application. While it has not to take care about how the filesystem implements it. Also Steam does not set any fancy file attributes not possible to set on other filesystems.
One of many benefits in using BtrFS over ext4 is that it is a so called Copy-on-Write (CoW) filesystem. This has many advantages some of which would be support for build-in deduplication. Especially SteamOS using Proton creates a ton of near identical Proton Prefixes per game. If these prefixes could share identical files across all of them this would save a lot of space. Even that this process of deduplication has to be issues explicitly some could simply do so while creating a new prefix. Or run a service which does this on a regular basis. Which is what most distributions shipping with BtrFS do.
In addition to this BtrFS has also build-in file compression which could save even more disk space. Why Valve instead opted-in for ext4 everywhere else I can not really understand. Not to mention that the lifetime of any block device could be expanded this way as there are fewer write operation. Since the filesystem will only write a file if it actual differs form something it already knows.
While the entire thing still requires some level of overhead in meta data it becomes insignificant considering the amount of disk space which is saved.
Back then on the 64GB SteamDeck this would have been a game changer and probably save some ppl some headaches. At least it would have had for me as I got myself the 64GB model. Meanwhile I replaced the eCMM with an M.2 SSD for this very reason.
Alternate SteamOS distributions such as Bazzite actually use BtrFS in the way I described it above. With enabled file compression.
A/B Root
Another thing I have a hard time to comprehend is the use of A/B root (and var). This basically means SteamOS is installed twice on the device and therefore takes twice the space. Since they already use BtrFS for their root file system this raises some question, like why!?
Not just because they made two independent BtrFS filesystems this way and break deduplication they also do not use BtrFS build-in snapshotting feature either.
That some could save a ton of space should be obvious at this point but also it would allow for much more restore points and would solve a long standing issue with users modifying the base system. Because as of now it still can happen stuff installed into the SteamOS base system will get overwritten with the next update. The other A/B partition will simply get overwritten with a new and fresh SteamOS image and on the next boot the system will swap the new primary partition.
Not to mention some wouldn't be limited by 5 GiB of space in the base system either.
Point-Release Arch Linux
One of the big advancements of SteamOS 3 was it shift from being Debian based to be based onto a rolling release. One of the reasons was to have a more up-to-date Software stack like Mesa. SO the latest Vulkan Extensions, performance improvements and such to arrive much sooner. While on Debian it might take several years for a new major Mesa release to be shipped. Something I full support.
Except the way Valve handled it. The funny thing is that they now made their own Frankenstein point-release instead. This way SteamOS ships a recent Mesa driver version (to some extend) but nearly any other part of the OS is even older then a recent Debian. Which makes me highly doubt the security of the operating system itself.
Also I am not aware of any regular stable branch SteamOS updates to fix up security issues in libraries such as sudo, OpenSSL and the likes. A new stable SteamOS version arrives at best once a year maybe later. Except some opt-in for Preview or Beta of course. But still stable is the default which leaves millions of devices unpatched.
In my post Linux on Desktop I elaborate further on the downsides of point-releases which in large chunks also applies to SteamSO.
Arch Linux base is questionable
I fully understand the reasons behind using a fully community driven Linux Distribution as the new base to avoid being dependent on the good will of another corporate. This apparently narrows down the available options by a lot. Still I am convinced a Tumbleweed based SteamOS would have been the much better choice in the long run. To understand my point of view we have to take a look at how both projects, Arch Linux and the openSUSE Project, are run.
First of all both are fully community driven projects. For Arch Linux the Software in the Public Interest (SPI) takes care of finance, servers and infrastructure. While SUSE does the same for the openSUSE Project. Still both are run independently from their respective "donors". Of course if one of them stops funding the project they are screwed.
The SPI is a non-profit corporation and primarily funded by donations. While SUSE as an Linux Enterprise firm obviously has a little more resources to throw at the project. While the openSUSE project benefits from the already existing SUSE infrastructure as well as some SUSE employees working on the project.
Arch Linux as well as the openSUSE Project are fully driven by the community. Therefore in both cases each individual member can work on things they are interested in. Also technical and steering decisions are made by the communities. Only if both communities can not agree with themselves there is one central instance in both cases to settle these discussions. For Arch Linux this is the Project Lead for the openSUSE Project this is the so called openSUSE Board. Pretty much as Valve works internally.
In both cases members of this instances are elected by the community but in bot case the Project Lead / openSUSE Board is not allowed to make governable decisions. They only serve as a single point of contact to communicate with others outside the project and to settle disputes. In other words SUSE can not make decisions about the openSUSE project via the board.
Therefore Arch Linux and the openSUSE Project are very similar in the way the work. Of course in both cases the SPI or SUSE can threaten them to pull their financial or infrastructural support and indirectly influence each project.
As we now have cleared up how both project are governed we can ask the question why use Tumbleweed "openSUSE Rolling Release" over Arch Linux.
On the one had Tumbleweed is way better tested thanks to stuff like OpenQA. While Arch Linux relies on manual testing by maintainers or the community. OpenQA is an automated test infrastructure which test every single Tumbleweed release and package before they are released to the public. Always in the same manner. This way it can not only be tested more in a shorter amount of time it is also tested in much greater detail and different system configurations like different CPU architectures. SOmething Arch Linux does not do as it only officially supports x86_64. Which will be interesting to see how the Steam Frame will unfold given it is ARM based. Most certainly Valve has their own internal infrastructure here.
In addition to this the openSUSE Project has a factory first policy. Factory is what will become the next Tumbleweed release. Therefore, most parts of the project center around Tumbleweed. While "forks" such as Slowroll, Leap or even SUSE Linux Enterprise come last. But they are also not of much interest for this article.
With Distributions like Aeon and Kalpa there also already immutable Tumbleweed variants available which Valve could just have had build upon. While they also already used BtrFS as the default filesystem which gives them the previously outlined advantages. Both update seamlessly in the background and there wound't be a need to hide new SteamOS releases behind a Beta or Preview channel. Also it would have had eliminated the need for an update dialog which just makes the user wait in front of the device for the new SteamOS version to be applied. All that is required to update an Aeon or Kalpa based system would be just a regular reboot and get the user back in without nay delay.
Also Tumbleweed and as well as Aeon and Kalpa do support SecureBoot out-of-the box. Arch Linux in contrast does not as well doesn't SteamOS. This is why SecureBoot is disable on the SteamDeck despite the hardware being capable of it. Even full disk encryption with TPM 2.0 based unlocking would have had been supported. Valve didn't had to roll their own Signing Authority. AUtomated updates wound't require the user to regularly clear the Pacman package cache either.
Last but not least it would put a way lower maintenance burden on Valve, the system would run more stable and reliable.
All things considered I*d still expect a Tumbleweed based SteamOS made by Valve to be es separate from the main things as like SteamOS is. Still they could just have had roll their own OpenQA and Build Service and simply import existing Tumbleweed tests and Factory packages.
Many things Valve had to developed for SteamOS themselves would have already been solved for them.
Fedora an option?
At this point some might also throw Fedora in the Mix which would be an option as well. Kind of. As like Tumbleweed so is Fedora a community driven effort. At least on paper. Unfortunately both Red Hat and the FESCo caused quite a few incidents in the past by either killing of entire projects or simply over ruling community members.
Red Hat for example replaced CentOS with CentOS Stream which could happen to Fedora any time as well. Also Fedora is a lot tighter integrated with Rad Hat as TUmbleweed is with SUSE.
Furthermore certain steering and governing positions of Fedora are appointed by Red Hat rather then being elected by the community. As reference:
In other words the risk in usig Fedora as a new base would be exactly this, a risk. While the openSUSE Board has one guaranteed SUSE member but as previously explained the Board has not governing permissions. Not like it is the case with the FESCo and Fedora. WIth Tumbleweed the community is in charge.
Bugs, Bugs, Bugs
Out of all Desktop Linux Distributions I ever used in the past 20+ years SteamOS is at least in the top 10 of "unreliable" options. Probably because of the previously mentioned reasons.
Of course I could list any single issue I ever encountered. But that would not be exactly helpful. Instead I'd like to focus on Bugs SteamOS has / had others like Tumbleweed, Kalpa or Aeon didn't on the same hardware.
Gamescope crashing if using SteamLink
Some long outstanding issue in SteamOS was the crashing of the gamescope compositor if some tried to stream from your Deck to a PC using Steam Link. The bug was once resolved just to be re-introduced a few stable releases later just to be fixed once more.
To be fair the same issue happened with Tumbleweed except that Tumbleweed updated gamescope much much sonner as the stable SteamOS release. A proper OpenQA test might have prevented this.
Mesa errors
Something I run into from time to time are bugs with the Mesa driver which didn't occur on Tumbleweed using the same version and on the same AMD GPU (like on the StemDeck itself). Feel free to take a look at this bug report about OpenArena on the SteamDeck.
Steam interface hung up
Even that I run an entirely unmodifyed SteamOS and the stable branch it happens rather often that after long standby periods the Stem interface freezes as soon as I launch a game. Only solution is to force shutdown the system by holding down the powere button for several seconds.
Steam Input crashing
Another issue I never witnessed in hourly long gaming sessions on my Tumbleweed based Kalpa is Steam Input crashing and the System no longer receiving any gamepad inputs. Usually Steam Input reboots itself. Meanwhile the in-game character already fall of a cliff or was devastated by a boss. Annoying but luckily it does not happen that often on SteamOS.
Issue using external displays
A rather common issue with SteamOS is connecting it with a TV. At times SteamOS switches off the internal display and speakers but "forgets" to output these on the external device. The only "Fix" for this issue is to reboot SteamOS multiple times with the TV connected. Or to unplug and re-plug the docking station an undefined amount of time. At some point it then magically starts working again. Usually it takes some times until this issue happens again.
For some time I had an Aeon dual boot installed on an SD Card which never suffered from this issue. I suspect the somewhat ut-dated software stack of SteamOS, including AMD firmware, to be the root cause.
Flatpak
Some flatpak related issues are also not very rare on SteamOS.
First of all it installs Flats system wide into /var including the root user. An interesting choice for a single user device where there is only one Steam User regardless of how many people are logged into Steam on the device. Also modifying /var required super user privileges. Which SteamOS never asks for. Which means the default user has root privileges on the device which allows any flatpak to just run flatpak-spawn --host and run arbitrary commands using sudo or kdesu without the user ever need to input a password.
While this isn't the actual thing I want to talk about. Rather I'd like to mention how the flatpak Firefox is not able to inhibit the Screensaver or Standby if an external display is plugged in eg. a TV. Using only the internal display all is fine. Therefore, if you are watching Netflix from the comfort of your Couch the Deck at some point will turn off the external device and blank the screen. Unless some has manually disabled this. Which is a rather strange bug and something I did not witnessed anywhere else.
(SteamOS - Firefox Flatpak unterbindet Ruhemodus und Bildschirmsperre nicht)
(Kalpa Desktop - Firefox Flatpak unterbindet Ruhemodus und Bildschirmsperre ordnungsgemäß)
If we take a look back where I talked about A/B root you may notice that the same thing applies to /var. Still Flatpaks do not vanish on OS updates. Based on this I conclude there has to be some sort of migration mechanism to base Var-A on Var-B and vise versa. If Flatpaks would be installed in the users home directory there wouldn't be any issues. They could even perform a full BtrFS migration this way and not accidentally create snapshots of /var
As a side note
/varis actually an Overlayfs on Aeon and Kalpa to ensure consistency between Snapshots and to allow for proper rollbacks.
Bluetooth
ANother issue I noticed just while writing this article is file sharing via Bluetooth. This simply does not work with SteamOS while the same thing works fine on all of my other Linux Systems.
KDE Connect
Using KDE Connect isn't an option either as no other device can be connected to SteamOS as none of them can discover each other. A tool I heavily rely on to share files between all my devices as this is faster as using Bluetooth.
I assume the out-of-date SteamOS software stack to be the root cause here as well. Which makes this article fit very well with the previously mentioned Linux on Desktop article.
Closing thoughts
I think this should be enough complaining about SteamOS. Of course nobody has to agree with me here and for many people SteamOS works well enough. Which in fact it also does for me. Also I am open to any discussion on this topic.
My personal review so far is: A Tumbleweed based SteamOS would have been the much better solution, it would save a ton of extra work, works more consistently and way less issues and not leave SteamOS users with unpatched security issues.
Such an SteamOS could also easily continue to function and exists even if Valve would drop support for it. Assuming the upstream-tumbleweed sources are wired up of course.
Even the Arch Linux based SteamOS Valves own package sources. SOmething which sure is mandatory if running something off Arch Linux and not risking a SteamDeck to break some where or requiring the user to read the Arch Linux News.
Still I am still very exited about the SteamDeck even if it comes with SteamOS. Most of the time the device functions just right. While I might not agree with some of Valves architectural decisions but as an end user some usually dose not run into a situation where this becomes important. Unless you run a 64GB SteamDeck ...
With that said, happy gaming and I can't wait for the Steam Frame to release!
Update
2026-02-01
- SteamOS Flatpak issue updated as not solved