I’ve been using Arch as my only OS on desktops and laptops for years now. Maybe I’m just lucky but in my experience it’s been incredibly stable. I’ve only run into one issue with updating packages using pacman and it was a Postgres + PostGIS conflict caused by my own configuration mistakes (easily fixed). I imagine most updates for the Steam Deck will either be from the core repositories or through Steam itself though, so the same issues you might run into when installing bleeding edge packages from the AUR shouldn’t apply.

As far as why Arch, I think it’s a great “build your Linux OS” distribution that gives you a solid foundation to expand into the bespoke system of your dreams. On my desktop, I have a personalized computing experience using Wayland + Sway, PipeWire and only the software I use. That same DIY principle makes Arch a compelling option for anyone looking to build their own distro; Manjaro is one such example and it’s the distro I used before making the full dive into Arch.

For “build your Linux OS” distribution, Gentoo looks like more suitable since it's more customizable (e.g. many USE flags, still provides OpenRC instead of systemd). Just curious the reason why Arch over Gentoo. I suspect that because Arch is more acceptable for normal Linux Desktop user.

Gentoo wants to compile from source, because of the USE flags. Thats hard on battery life, and maxes out CPUs creating thermal issues, both of which are notorious issues on mobile.

You should be able to accomplish the same thing by using your own pacman repos with compiled binaries that have the right USE flags. They all have the same hardware after all.

You can build a binary distro based on Gentoo, e.g. https://github.com/sakaki-/gentoo-on-rpi-64bit (sadly EOL'ed several months ago).

Anyway, from my own experience, the video decoding performance of gentoo-on-rpi-64bit was somehow nowhere close to LibreELEC, on the same hardware. Perhaps there is a lesson to be learnt there...

Driver support would be my guess.

With PC games, at least in my humble experience, you pretty much always need the latest drivers to run things well (especially so on Linux). With AAA games you will likely need to download several different driver updates within the first month to make it play reasonably well.

My understanding of Arch, is that it's more focused on providing systems which are more up-to-date/current than strictly "stable." [1] This is a pretty big advantage for Valve/Steam/Gamers since its less likely they'll be stuck having to back-port a sea of changes to a dying, but stable, LTS version. Instead they'll be on a platform with a community that prioritizes it. In all honesty, it'll probably make for a more reliable/stable gaming experience since patches will be easier/quicker to ship.

[1] Just to note, I'm not saying Arch is unstable in case someone reads it as that. I honestly was thinking of giving it a go this weekend (currently on a Debian based system), and this is probably the kick I needed to do it.

Historically, this is AWFUL for gaming on Linux, since NVidia is a terrible company which takes forever to get their drivers working on/with new features (Wayland, kernel modesetting, new kernel versions at all for a long time). You seem to be taking a lot of assumptions about what gamers want/need on Windows and cross-applying it.

Steam (via Proton, mostly) already does a lot of development work, and it doesn't care which distro it's on. "Oh no, I updated my kernel and now my graphics drivers don't load at all!" is incredibly common, even with DKMS. Sometimes (mostly) bugs get fixed in Mesa or whatever. Often, new subtle bugs are introduced when a new Wayland/Pipewire/whatever feature goes GA. Having as few moving pieces as possible (by using an LTS distro, or at least something which isn't rolling with upstream and has a modicum of QA) lets you optimize the pieces you need to without worrying that this or that API is going to change underneath you.

Intel and AMD drivers do not have this issue, and Valve was smart enough to not go with NVIDIA, but "I want to be up to date" is a terrible experience.

Additionally, it generally makes for a much less reliable/stable experience (gaming or otherwise) because `pacman -Syu` may at any point break something because you didn't read the release notes, or "mostly" stable features were committed upstream then released so the userbase can put them through their paces and report bugs the developers didn't encounter.

Users of Arch/Fedora Rawhide/whatever accept this, but someone who buys an OEM gaming machine does not need or want this.

Just to note, I AM saying that Arch is unstable. I've been using Linux for 20 years, and I've had my time with Gentoo and Arch. 99% of the tinkering users do is reproducing the work of professional developers at distro vendors who spend a lot of time and effort making sure you never encounter the problems Arch users revel in fixing at all. Sure, you can tell yourself that means you "know" more about the system. But that is time invested that you could have spent doing REAL THINGS, and solving REAL PROBLEMS which are not un-breaking your distro.

> Historically, this is AWFUL for gaming on Linux, since NVidia is a terrible company which takes forever to get their drivers working on/with new features

Historically, sure, but with the leaps and bounds Intel and AMD graphics drivers have made (in no small part thanks to Valve!), we can leave Nvidia in the dust. With said FOSS drivers, "I want to be up to date" is a perfectly reasonable desire and does indeed get the best results as far as gaming goes.

That said, I agree that Arch wouldn't be my first choice for something I'd expect non-technical users to maintain. If Valve really wants a rolling release and close-to-cutting-edge kernel/driver versions, distros like openSUSE Tumbleweed could readily do that (with, at worst, an extra repo for bleeding-edge kernels, though I've yet to find that necessary on my openSUSE-running gaming laptop) without anything even vaguely resembling Arch's maintainability nightmare.

In general I agree with you but this:

> Sure, you can tell yourself that means you "know" more about the system. But that is time invested that you could have spent doing REAL THINGS, and solving REAL PROBLEMS which are not un-breaking your distro.

You can start a sysadmin career with that kind of experience.

I very recently (last week) applied some of the "how do I unbreak my system" lessons I learned from back when I was a teenager messing around with AMD's old proprietary fglrx drivers (and screwing things up on my personal machine) to "how do I get back into my work Linux machine after the Active Directory sync got hosed and my login credentials failed?"

Can confirm. Basically did just that. :)

Not necessarily on Arch specifically, mind you, but a ton of the experience I had that led to me getting my first tech job was breaking stuff and then figuring out how I broke it. It's a great learning experience.

You definitely can, that's how I got into sysadmin jobs :)

But in this specific case, Valve doesn't need to worry about driver support, since they control the hardware? Unless they mean it to be a general purpose distro that people use on other hardware as well, maybe.

Like the word "free" in free software (freedom vs. free of cost), many folks misunderstand the usage of the word "stable" in regards to computers and technology.

For the uninitiated; In programming, "stable" often refers to the programming interface or features a software developer can count on being available for a particular version of a given piece of code (library, server, etc). To the end user, "stable" often is taken to mean "How often does it crash? Rarely or never? It's stable."

I moved off of a standard release and onto a rolling release distro because the software I used the most was always a major release (or two) behind.

Since it's based on arch, I assume they will pull the latest software from arch, test it, and push out updates as they are verified.

If we are talking about upgrading means a complete reimage, Valve probably doesn't push every minor upgrade, but bundles them together. Like what Manjaroo is doing.

Because the turn-around time from upstream-to-packager is smaller, which in turn helps get problems fixed faster. That in turn means devs have more space to fix issues. It is an effective velocity improvement for them and they think it will work for their targeted market.

First, it's worth keeping in mind that this Steam Deck is for all purposes and intents a fixed-spec system. Valve will control all of the most major components that make various end-user support problems appear (fixed CPU, GPU, RAM, motherboard, controllers, storage, etc.)

Now, with that in mind, if you use a system that has a release cadence like Ubuntu, if you want to fix issues, you must report them upstream and backport them into your current system. This is workable, but it is implicitly predicated on the assumption that the backport is the only way to deliver the fix to users in a reasonable timeframe. Otherwise you would have to wait 6 months for Ubuntu to release anything.

If you use a rolling system like Arch that is much closer to the very latest versions, the same process above occurs. But the window for those changes to appear downstream (from reporting the issue to the person receiving the fix) is much smaller. If this window becomes small enough, say "I report an issue and a patch is issued and released in 48 hours", it often means you don't have to backport or maintain the backport for long. If you're maintaining less backports concurrently, or even none at all, that means you have less workload and can focus on diagnosing real issues with up to date code.

Finally, and this is the important part: it doesn't matter for who they want to buy this. I don't think Valve intends this to be seen as a console, but as a portable PC, and I don't think PC gamers who use Steam (and thus are the target market) are unexperienced with the fact games might not work and bugs need to be reported. It's part of PC gaming culture at this point to complain about bugs in PC games. They actually will probably want one anyway because it will make their massive investment in their Steam library all the more available. And if you're some die-hard guy who likes this thing because it's Linux, well, Proton is basically as good as it's ever going to get at this rate, and it's objectively made Linux gaming massively more available, so, you just gotta deal. (Proton's very existence gives developers less of a reason to deal with native Linux ports when they can just target Windows and let the magical translation layer fix it instead. So actually the focus will be going into making Proton better instead to fix these issues, and that is actually probably the best way forward to ensure older games can be available, too.)

There are a thousand confounding variables in this equation and I'm sure you can line up to list them or whatnot. But the important thing here is that in all cases there are social expectations about how the maintainers of each upstream project and distro fix issues, and on what timescale, and how users respond to them. That's why they think this will work.

I dunno about pure Arch, but when I was using Manjaro (an Arch derivative) upgrading often was never a problem for me, as the system stayed ridiculously stable (in a never crashing or breaking on me in any unexpected ways sorta sense), so I imagine as long as Valve makes it a point to test each upgrade they push for any unexpected oddities before they push it to the end-user, there shouldn't be any problems there.

As for the games themselves, Valve's been workin' hard on their Steam Linux Runtime containerized game thingy, and Proton sorta "containerizes" (WINE prefixes) things, so that allows for a reasonably stable environment for any given game which already runs well in those scenarios.

TL;DR: I doubt Valve will have too many problems keepin' this thing fairly stable from an end-user point of view unless you start hackin' around on it changing too much, then it's all on you what happens next. ;)