> While Valve's specific reasons for picking Arch Linux for Steam Deck remain unknown, it's pretty easy to guess why it was picked. Mainly, it's a particularly lightweight distribution maintained since March 2002, which lends itself well to gaming with minimal performance overhead. A more intensive Linux distribution may not have been the ideal base for SteamOS 3, which is targeted at handhelds like Steam Deck first.
I am not sure Arch is going to be faster for gaming than any other distro, but I can see why Valve picked it for a minimalist base. Another reason I am sure they picked it is that it is smaller and less commercial than others (such as Debain or Ubuntu) and they would have more ability to influence the project.
> In the long-term, the funding touted should, at minimum, allow Arch Linux to improve the security of its distribution and provide more structured releases compared to its current near-continuous update cycle.
This was literally the stated reason they moved from Debian in 2021, because they preferred rolling releases. [1]
[1] https://www.rockpapershotgun.com/heres-why-steamos-switched-...
I think the pick for Arch makes a lot of sense if you consider the big players in the ecosystem:
* Debian habitually ships ancient versions of software unless you setup backports. It's also by far the distro that makes the most downstream modifications to software, which causes issues with upstream.
* Ubuntu is a semi-rolling (basically, a stable copy every 9 months) release of Debian + Backports with a Canonical skin and nice branding. Cute, but it inherits the same problems that Debian has.
* Fedora is fine, but it's also very beholden to Red Hat. Whilst Red Hat going IBM squeeze mode occurred after Valve picked a distro, the ties it has to Red Hat are a problem for Valve, considering their Linux push was always defined by not wanting to be tied as heavily to a third-party vendor (it almost entirely originates from Microsoft blowing their left foot off with Windows 8 and the Microsoft Store being both awful and a direct competitor to Valve; Gabe Newell is an ex-Microsoft employee, he probably recognized the direction MS is going in). Also, major system upgrades with Fedora aren't exactly the greatest process; they work, but since they're inheriting the CentOS structure, Fedora isn't really build around that sort of thing. I've always had to do manual checkups on key software when using Fedora.
By contrast Arch has a policy to "ship as close to upstream as possible" (even in cases where it's weird; last I checked, their nano still has the bad word wrap that nano is known for), pushes out updates extremely quickly and is a non-profit. With Valve having their own button on the upgrade process, they can also ensure that you don't get some of the more typical "hilarity" of running Syu and realizing your drivers made it so you ended up in an emergency shell mode.
Other distros just don't have the installbase to guarantee consistent support (everything on distrowatch) or are too inaccessible for regular users (aka "why not NixOS" -> because NixOS actively requires you to ignore almost every online resource and to only use the NixOS provided documentation since nothing else on the planet works the way NixOS does. Gentoo also is in this category, since most people that own a Steam Deck probably aren't looking to custom compile everything.)
What I don't like about Debian is that they have several names for releases which are difficult to remember (for example, a distribution can be called "Bookworm" and "stable" at the same time and later it is not "stable" anymore). It would be much easier if they just used numbers everywhere and added names in brackets.
Debian also has version numbers (11, 12, 13) but people prefer the names releases for some reason.
I don't mind the names too much, and I don't even mind the moving "stable" name, but I do get confused because Debian's names don't necessarily increment. Ubuntu made the smart decision to make their names alphabetical and that helps tremendously when you're trying to guess how recent a particular version is.
The main reason they picked Arch is the rolling release model with updates from upstream projects they work with landing quickly and continuously.
So yes, TH's speculation is just off the mark here.
About releases: They typically refer to the OS version or base in these rolling distros such as Fedora. Rolling releases aren't all like Sid.
In Fedora, there is a base OS version with a sort of configuration, specif directory structure, major architectural versions of software (like Gnome or KDE), sometimes cryptographic policy, or other system backends such as logging or DNS resolution.
Fedora used its release cycle to migrate to systemd-resolved, to pick an example, because this change introduced structural changes to the way the system operated. In the release in question, system services leverage the D-Bus API to get DNS lookups, systemd binds to the local port. By segregating this behavior by release, it makes the dependency tree much simpler to manage at the cost of possibly needing to backport patches, but Distributions are doing much more than shipping mostly upstream packages like Arch is.
I always thought arch would be well suited to this sort of thing. Arch Build System is very good, and since packages are very close to upstream, it would be very easy to make your own ABS repo as it stands. It is very similar to the ports tree, arch linux has very little flavor in many respects.
Fedora isn't a rolling distro the way Arch is. And even Arch while popularly known as a rolling release distro doesn't entirely live up to this ethos. Python 3.12 & Gnome release delays just to give an example.
Fedora has something that resembles Arch as a rolling distro. Their unstable branch for development which they call Fedora Rawhide.
That said you wouldn't be wrong to call Arch a rolling release distro because it is one for the most part.
You are working off an unusual definition of "rolling release". A rolling release just means that there are no major version bumps that require an active opt-in when upgrading.
And besides, the behavior of Fedora Rawhide can easily be achieved in Arch Linux by just adding the [testing] repo that's already prepared (but commented out) in your /etc/pacman.conf
> A rolling release just means that there are no major version bumps that require an active opt-in when upgrading.
Indeed. However IMO this definition is not complete without taking into account the matching status of upstream software versions available and package versions made available by the distro at any given point in time. This is the continuous delivery expected and what gives a distro rolling status among its peers.
> they picked it is that it is smaller and less commercial than others (such as Debain or Ubuntu)
I agree with you, just nitpicking: it is smaller than some (like Debian) and less commercial than others (like Ubuntu).
How about Alpine? Isn't it more lightweight?
Yes, but it's built around musl libc instead of glibc, which causes compatibility problems with some programs
NixOS could have been good alternative as well and probably easier to maintain / develop, but I'm sure Arch as base takes less space than NixOS.
While I love NixOS and use it personally, IMO it's just too different from standard linux distros to be able to use it in a consumer-facing device, that offers users the ability to look under the hood.
It would've probably lead to massive confusion due to users not getting the "nix-way" and it seems like easy hack-ability is part of the steam-decks value proposition.
While I agree that Nix is not user friendly, Nix would allow more hack-ability than the current Arch approach.
The Steamdeck modifications often get broken in updates, because the Steamdeck software is an image that is managed by Valve. Meanwhile, with Nix I think it would be easier to maintain modifications, as you could layer them on top of each other.
Also, most Steamdeck users:
- Don’t modify their Steamdeck
- Use Flatpak, which works on Nix
- Run an install script from the internet, such as DeckyLoader, Emudeck. Which often break with updates.
Seen from a certain angle, the real question is: why don’t more companies do this? This isn’t charity, this is enlightened self interest paired with understanding that pissing off your free supplier is a bad idea.
I'd say half of it comes down to Valve having the staff with the key knowledge and skills to provide support, and the other half comes down to not being public.
I'm sure many devs and publishers are filled with people who know that acts like this can garner trust and future support for their company, but will have efforts cut short because someone above complained that the line didn't immediately go up.
> the other half comes down to not being public
In every service or product I've bought, going public (and prep to go public) has preceeded a decline in quality. The day Valve goes public will be the day its downward trend starts, because its customers become the shareholders.
>why don’t more companies do this?
What exactly?
Whole big tech contributes to linux. MSFT is probably biggest of them
Wasn't Microsofts biggest Linux contribution the code to make it run on Microsofts Hyper-V ? From what I understand their only other major contribution is the Rust project that ran head long into a wall.
Jup it's crazy that people still think Microsoft (the "We Love Linux initiative") did anything big apart from let Linux run good on their Hypervisor, Oracle for example did 100x more then MS (yes oracle...).
Because it's money, and not doing that barely impacts them. Valve is always more prosocial than other companies because they have an infinite money spigot as long as everyone likes them, so prosociality is their business model.
No other OS is as configurable, adaptable and versatile as Linux. It runs on the biggest super-computers, on the helicopter that flew on Mars, on the server that is hosting this service and on the device I'm typing just now.
Now, just imagine... just imagine how much performance could be gained if game vendors didn't ignore it.
> on the server that is hosting this service
I’m not sure if it changed, but last time I heard HN was running on FreeBSD: https://news.ycombinator.com/item?id=16076041
> just imagine how much performance could be gained if game vendors didn't ignore it
In the case of FreeBSD, Sony used it as the base for the OS on PlayStation since PS3.
> how much performance could be gained if game vendors
It might not even be the fault of vendors or their developers.
GPU drivers are still a bit of a pain to non technical users outside of PopOS. They need to "just work" transparently to the user or they'll just leave for Windows.
And game devs tend to use a premade engine - that engine needs to have good support for both Windows and Unix, or they will just default to the bigger market: Windows. So that's another important driver in migration to Unix.
I frequently find the best way to game on Unix is to either dual boot or install a Windows VM
I recently tried PopOS because of it's benefits for having GPU drivers configured out of the box and was told that it would "just werk". And to be fair to it, it did mostly just work (ignoring unintuitive UX decisions in the OS generally). But I also spent two days trying to get Steam to show at the correct scale and eventually gave up.
I think that’s just an issue with Steam on Linux, surprisngly. As much as I love Steam sometimes they just leave fundamental things like that unfixed.
They don't ignore it, it powers many servers, and the games on Android and ChromeOS.
Additionally PlayStation OS is based on a FreeBSD fork, and the Switch mikrokernel OS still has a POSIX flavour to it, to the extent that it matters for C and C++ standard libraries.
What they ignore is the desktop mess, and lack of paying customers outside platforms where people are willing to pay even for fart apps.
And the RT patches are making it to upstream, which together with the userland sched can make a huge difference in frame rates and latency when gaming.
RT is entirely about guarantee regarding response time. It is generally overall slower than non real time in basically any scenario where it doesn’t matter. Video games are purposefully written so as not to be latency critical so RT would be a net loss.
Generally slower at completing long tasks, sure, but is that the real workload of the Deck?
I feel that there's enough aspects and subtleties to consider that I wouldn't trust anyone, particularly not myself, to guess how things are really going to fare. We will likely have a phase of experimentation and tweaking that will improve things with and without RT patches as more workloads are considered and things are ironed out.
I doubt they wanna run an RT kernel in SteamOS. There are severe costs to doing so.
Are there some benchmarks for that, or a good discussion somewhere?
Because I was wondering about that myself. RT kernel sounds at first like it may help achieve better latency in games, but then you are so deep in the stack and depending on overall performance, that the costs of RT mode might hurt much more than one would gain. But I don't really know how that plays out in practice.
I don’t know. My understanding though is that RT Linux adds predicability at the cost of throughput. For games where CPU throughput isn’t important (like an action game where most of the work is pushed off onto the GPU) this would maybe help. Someone could certainly try. But for other games like many strategy games and simulations where the CPU is a limiting factor, there would likely be a cost.
The problem is that it’s not a free win, and games are very varied. But theoretically, on something like a console, you could offer choice.
My understanding is that real-time isn't so much about lower latency (though that is also desirable), but rather about predictable, bounded latency. For the purposes of gaming, no amount of predictability at the kernel level will reduce the amount of work you need to perform to draw a frame, and that is the real limiting factor for most games.
> For the purposes of gaming, no amount of predictability at the kernel level will reduce the amount of work you need to perform to draw a frame, and that is the real limiting factor for most games.
It all depends on what you're trying to optimize for. You can maximize raw framerate numbers by having an unlimited frame queue depth, but it'll feel like shit because you won't have even frame pacing and your input latency will vary wildly. The ideal scenario in gaming is for your draw time to be perfectly deterministic, and be able to schedule things so you can read input and do your render calls just before vsync.
I assume the realtime patches brought some improvements you'll get even without compiling a hard realtime kernel. There's a whole bunch of CONFIG_PREEMPT_* options.
> No other OS is as configurable, adaptable and versatile as Linux.
BSD wants a word with you.
From games consoles to core internet devices powering the packets to enable you to post.
Linux may be having an up-trend at the moment but BSD has already been there and still is.
Yes, BSDs are great technically and popular enough to be noticeable.
Unfortunately, most of BSD innovation stays locked behind proprietary forks.
> BSD wants a word with you.
BSD is great for many things, but hardware support is sadly behind. I'm a Linux guy but I run both XigmaNAS as my server and OpnSense as firewall on two different platforms, and all their WiFi and Bluetooth chipsets are unsupported, especially 802.11ac is way behind. Not that I'd use all of them on those machines for security implications, but having them supported could be handy sometimes.
If the complaint is WiFi and co, that's not the fault of BSD.
That's the fault of vendors not opening up their proprietary firmware blobs up to other systems.
Saying "complain to vendors" isn't an answer for 99% of users (unless you're a corporate user who vendors will listen to) and basically translates to "it's not worthwhile for you to pick it".
Basically it's the equivalent to a shrug; means you can't do anything with it.
So it could be as versatile as Linux if someone would actually make it versatile? Does not sound very versatile at all.
BTW BSD had its last release in 1995, so you probably mean something else.
And now Real-Time support is getting mainlined, which means we might see even more stuff like Mars Rovers running Linux.
What did mainlining it change from the industry point of view? I recall installing in minutes the -rt fork from official Debian repositories ages ago, mainly to have lower/more consistent latency with music apps, and never had a problem.
Official support, and more eyes seeing it. Maybe better integration since they'll need to make it integrate fully to reach mainstream kernel.
"In the long-term, the funding touted should, at minimum, allow Arch Linux to improve the security of its distribution and provide more structured releases compared to its current near-continuous update cycle."
Isn't rolling release one of the core ideas behind arch? Sounds like the usual gaming journalism...
> Valve is now providing a build service infrastructure
Fingers crossed this means Arch will support the ARM architecture* in the official repositories. There's a related RFC which has been accepted but but I'm not sure where things stand right now.
https://rfc.archlinux.page/0032-arch-linux-ports/
* I'm well aware of Arch Linux ARM but that's a separate project with even less resources (missing packages, some broken). Asahi used to use it before moving to Fedora due to similar problems.
> Fingers crossed this means Arch will support the ARM architecture* in the official repositories. There's a related RFC which has been accepted but but I'm not sure where things stand right now.
That is the goal with the work they are sponsoring, yes.
If I'm not mistaken, Arch Linux only supports x64 (excluding the unofficial ARM port), so I wonder why they've chosen to go with it rather than Fedora or Debian.
I'm still hoping to see an official immutable version of Arch Linux.
SteamOS is immutable, and I'm "stuck" using Fedora Silverblue [1] because immutable is the future and I won't go back to installing stuff manually while cruft accumulates in system directories. I don't interact often with rpm, but I hate them with a passion, while I used to maintain multiple Archlinux packages as it was so easy to do.
1: Silverblue host, but working within an Arch Linux container with Emacs, of course. Imagine having to maintain all the five dozen LSP servers and dev tools without access to the AUR.
I'm still curious about why they picked Arch over Debian or a BSD.
The article claims it's because Arch is "lightweight," but then why not pick a smaller distro?
My best guess would be familiarity (Valve can afford to buy the best developers, and lots of great folks enjoy the fiddlyness of Arch), hackability, and insanely fantastic documentation of Arch
BSDs are off the table because Proton, the set of extensions to Wine for playing video games, uses Linux-specific system calls. Also, the major graphics hardware vendors don't release their first-party drivers for anything other than Windows and Linux. While open source drivers exist, they are not good enough for the latest games or the latest hardware.
> the set of extensions to Wine for playing video games, uses Linux-specific system calls.
I have wine/proton on FreeBSD and FreeBSD has also a Linuxlator (a Linux system call translator), so no blocker here.
But you are right, if you want a open-platform (opposed to Playstation), Linux is probably the better choice atm.
Keep in mind that they did originally pick Debian. SteamOS 1 & 2 were Debian based (used for their ill-fated Steam Machine and Steam Link products), then switched to Arch-based for SteamOS 3
I wonder why Arch as well, because it's a rolling distro so a terrible model for a commercial/production product/service, but why no *BSD is easy: bad modern hw support, Debian because of a rock solid base but extremely old distro with many issues especially in customizing it (I'm serious D/I and preseed are HORRIFIC).
So I wonder why not NixOS since it's safe updates (an update essentially can't break anything, not necessarily true for database etc outside Nix but still much saver than any other non-declarative distro) and effortless rollbacks, customization etc. It's community is problematic right now, but it's still the most complete modern distro we have, with Guix due to the GNU design a bit behind and all the others FAR behind.
> In the long-term, the funding touted should, at minimum, allow Arch Linux to improve the security of its distribution and provide more structured releases compared to its current near-continuous update cycle.
This is a weird point, and concerning if it is true, because it seems to assume Arch's rolling release model is a bad model that the Arch team are forced into due to lack of funds, whereas for most of us it is in fact one of the main reasons to use Arch. As another commenter mentioned, the rolling release model is one of the reasons why Valve chose Arch, so hopefully this comment in the article is just misinformed. But there is a concern IMO that once Arch starts to look how Valve want it to look, they will try and influence the project to move to a more Debian-like release model (so that they have to worry less about breaking changes). Of course whether they can successfully influence the project in that way is another thing.
> This is a weird point, and concerning if it is true, because it seems to assume Arch's rolling release model is a bad model that the Arch team are forced into due to lack of funds, whereas for most of us it is in fact one of the main reasons to use Arch.
This is reading too much into it. The issue is that things like proper build infrastructure and signing enclaves is hard work that is not easy to work out and provide on a volunteer basis.
We (Arch) do not support multiple architectures for the simple reason that it would imply I'd need to watch N number of builds of one package pr architecture. This is what we did for the 32bit version and 64bit version. That's a lot of wasted time, and doesn't help you sell architecture support.
Signing enclave is hard to do right as it requires the technical know-how to do securely and the supported tooling to move the package signing from a pr developer basis to a central signing key. In the long run this would also enable Arch to support Secure Boot.
I thought one of the big things Valve wants to implement is a more sound CI/CD pipeline. And I assume at some point maybe have some sort of more unified app (store). I know people love AUR. But one thing that plagues linux is the flatpak/snap/app-get/dnf/aur dance.
Getting something more unified (at least for 'casuals') would be good.
It's not in what the Arch maintainers said. The improvements are more around improving their build pipeline and allowing things like simultaneous x86 V3 and v4 releases (from the comments I've seen). This isn't about moving away from rolling releases afaik.
Did gentoo have any similar collaborations with Google?
(Chromeos is based on gentoo)
Yeah, and chromeos is more than just the chromeos used on chromebooks, it's also the Container-Runtime Optimised OS (CROS) and used for some other things too, it's "the google Linux".
I'd be speculating but I think inside google there's two Linux's, one which is the immutable OS built via blaze, more like an appliance, and the other is the "dynamic" user environment stuff based on Debian, that is intended largely to be throwaway in most circumstances.
Well... Arch community is very kind and very active, but Arch is a rolling distro, a paradigm essentially incompatible with stable production systems.
I wonder why not choosing NixOS or a custom Guix System (due to the non-free stuff) instead since their model offer effortless rollbacks and safe updates.
I'm glad I started looking at other distributions like Alpine recently. This could just as well have negative effects as positive ones. Time for me to diversify.
What negative effects are you afraid of? I really can not see any downsides to this partnership.
In the long-run, a project can become dependent on such donations and this can give donors power over the project and those donors may want to steer the project in ways that we don't want to see it go. That may not happen and may even be unlikely but it's important to be prepared for that possibility and have contingencies available.
There is already a comment here which discusses one such scenario: https://news.ycombinator.com/reply?id=41695062&goto=item%3Fi...
Steam sells software and prevents you from copying it and using it easily. Not something you want to happen to a Linux distribution.
Usage of Steam's DRM is actually optional. There are plenty of games that you can copy the files of and run on another system without Steam present. [0]
[0] https://www.pcgamingwiki.com/wiki/The_big_list_of_DRM-free_g...
Optional for the developer. Mandatory for the player. Although I heard rumours it's easy enough to install alternate Steam DLLs that always return "yes" to "is this game licensed?"
It's trivial. You replace a dll and the Steam API check is circumvented.
Do they prevent you from using it easily? Yes, they sell software on a platform, but so does Nintendo. Yet Nintendo hardware is completely locked down and the software they sold you works only on said locked down hardware. Meanwhile, I can run anything on SteamDeck, and I can run SteamDeck software and/or their games on any reasonable gaming PC, in any form factor.
In practice, over the years that I've had a gaming collection with them, they've only ENABLED me to run the games easily.
I run Alpine on my mini-laptop (Starlite MkIV) and on an intel compute stick (STK1A32SC) and it works perfectly fine. It's small, fast and straightforward to configure. It has quite a bit of Gentoo DNA which is convenient if you are already familiar with it.