Why Valve Is Switching from Debian to Arch for Steam Deck's Linux OS
pcgamer.com
pcgamer.com
But then this little thing doesnt work yet because, they say, they haven't configure it correctly. And this little one, it's nothing mind you, it never worked. And this one, just a small detail, but it broke yesterday. We have a different definition of the box.
And so I go back to my Ubuntu LTS. I really want to try arch but I'm not 20 anymore, fiddling with my workstation is not as fun as it used to be. I just want to use it.
Maybe with the steam deck it will become so battle tested it will turn into the most stable distro ever.
I think their decision makes sense though, they don't want to have to craft every update and spend too much time on it. It's a good strat for them.
Then I adopted Fedora and never looked back for several years. Even more recently I have been using WSL inside of Windows... and it actually covers most of my use cases well enough.
I dont have the time or patience anymore to keep up with distro's like Arch, but I also get that some people love tinkering and figuring out how to make their system work like its some kind of puzzle.
Edit: One thing about Arch, its possible to dig yourself a real bad hole if you don't keep updating regularly and I get that's sort of the point, but it can cause a lot of issues if for example, you go on vacation for a few weeks.
Any changes that could be problematic are announced on the site and the arch-announce mailing list. It's really not a matter of weeks. I've gone many months without updating, without any problems.
In return you'll never need to update a Debian release name in sources.list, click away a nagging update prompt, wait for a double-reboot cycle for some registry changes, or anything of the sort.
Yes, you will need to understand what's on your system to know what news is relevant for you. You automatically will because you set it up yourself.
Yeah.. once I did a normal upgrade and it fucked my whole system. I asked for help and I was told that exact sentence "read the mailing list, it was announced". Thanks, but no thanks.
Perhaps there exists some subculture of folks that delight in having to read a set of articles published in the time between the last update and today before they do so again, but I have never encountered it.
It's honestly incredibly low-maintenance. You just have to spend a relatively long time setting things up first.
I suspect they will do like those Arch derivatives do: holding back updates for testing, which is easy when you target known hardware.
Meanwhile, $work server images have been Ubuntu LTS, CentOS, and AL2 with updates introducing breakage several times a year.
As far as I can tell, they have resolved these issues now, but it was a pain point.
I understand they're different distros with different philosophies, but in the end I do need my screen sharing to work no questions asked.
Fedora do work on six-month releases so there will be some version jumps between versions of Fedora but IIRC they will update little and often just like Arch whilst on a given release.
https://koji.fedoraproject.org/koji/packageinfo?packageID=24...
And Fedora shipped some configuration that worked for the standard environment you'd have when you just installed Fedora and didn't change things around too much. Since Arch encourages you to build your own setup and roll your own configs to a much larger degree, the defaults probably weren't quite right or quite enough for their specific setups.
I don't mean this in an "Arch bad, other distro good" sense, I just wanted to say I've seen the same thing where some detail in an Arch setup was broken. It's simply different strokes for different folks.
When you sign up to Arch, yeah I think you sign up for a lot of tweaking that would be done for you already. Luckily there is the excellent Arch Wiki to hold your hand through much of it.
I like the idea of pop!_os but part of the flagship experience is a big ol' Javascript extension on top of Gnome. I can't imagine I'd find that enjoyable.
Last time I had a Linux working and I didn't hate the experience was a "so small I could drown it in a tub" install/config of Void with mostly Suckless tools/programs. I find Linux to be most tolerable in those kinds of configs, these days. Doesn't do much, but what it does do actually works and behaves fairly consistently. Start trying to get fancy, and the machine begins to feel haunted in a hurry.
It's stable enough for me, and I see that as the price to pay for more freedom and flexibility, but I can understand one wanting to get down to close to zero fiddling and pay premium for OSX to be done with it.
I think in general finding the right tool is more about finding the thing whose inadequacies are least inconvenient to you personally rather than looking for some mythical tool that works well for everyone, in every case.
FWIW, a lot of "work" areas are still deep into Microsoft Word, which works a lot better on Windows.
But when I write or compose documents, I don't need MS Office interop, and it'd probably be my 3rd or 4th choice of "suite" for that kind of thing, behind the Apple's versions (mostly because they have great default templates, are very stable, are fairly easy to use, and are very light on system resources), Abiword/Gnumeric and other pieced-together open source options, and maybe LibreOffice in 3rd place. But, if I had to pass around Office documents, that'd be another story.
Probably my main pain-point on Mac, as far as work-stuff goes, are under-developed virtualization tools. They have a hypervisor, but it's a pain to use and there's almost no community around it. No simple way to pick an earlier version of macOS and virtualize it, even. VirtualBox is... OK. Barely. 3rd party commercial options improve the situation a ton, but you get much better tools out-of-the-box on basically every other at-least-semi-viable workstation OS.
However, the Steam Deck only has three main hardware configurations and Valve presumably has a team dedicated to making sure it runs correctly. So Arch may be a really good value proposition for them.
Looks like they want to have the ability to be fairly agile and not getting locked into a platform for 2+ years
I use Manjaro and it's been nothing but smooth sailing for a few years now. I have it on 4 machines - a home desktop, a work desktop, a laptop and an old Mac Pro from 2012.
It also provides continuous snapshots: https://snapshot.debian.org/
I just want the very latest of a short(ish) list of things, lets say arbitrarily within about 2 weeks of release, which is what Manjaro basically gives me.
pamac upgrade -a
pacman -Syu
Anyway for Steam deck my first reaction is that they will need to:
1. Do like Manjaro and hold updates for a period of time before distributing them.
2. Provide some sort of one-click revert for when an update randomly prevents your device from booting. These are basically the only big problems that I encounter anymore - it usually takes 20 minutes to an hour to figure out which package is the problem and fix it, but you don't want to be doing that on your $600 steam deck.
Edit: As far as updates that brick your system go, my first experience with Arch was that if you don't keep up with the rolling releases, you will brick your system guaranteed when you update. So we'll see how that goes. That was 10+ years ago, and maybe it's not as bad now.
More than 0, but not a lot.
Note I don't stick to LTS releases. If I only upgraded to the X.1 LTS releases I expect it would have been smoother.
1. AUR - almost anything you could need.
2. rolling releases - I admit I haven't used Ubuntu in a long time, but I use Debian for a variety of things, and it can be painful to need a release upgrade in order to get the next version of some piece of software. With Arch and derivatives, as long as you do updates regularly, everything stays new.
I get new hardware support and access to the many only-arch-pre-packaged software, in a more stable base.
Things break often and I am not interested in fixing them. And that's not taking into account wife and kids builds. It took me a while to realize the Arch crowd largely doesn't get that not everyone is exciting to thinker with their OS all the time. I get it. I really do. But I am old
As you say, hopefully Valve's efforts are going to help with that. In fact, there's hardly a chance they won't because they business depends on it, at least long term.
The endless criticism of everything needs to stop.
I spend more time just trying to have up-to-date software on that Ubuntu installation than I spend time configuring anything about the arch installation. Granted, sometimes you need to edit some files after an update (oh device names changed again in pulseaudio so your volume hotkeys need to be fixed!), but that's usually a matter of seconds because I already know how everything fits together. When a package is totally broken for some reason, I just downgrade it.
Meanwhile on Ubuntu your only option for getting up to date versions of Jameica/Hibiscus, pretty much any mapping software that OSM contributors/users would want to use, and a bucket list of other productivity software that tends to be useless if outdated, is to compile from source (don't forget to fix incompatibilities with Ubuntu's libraries!) or manual downloads. Oh I forgot to mention Subsurface and TurtleSport. Don't get me started about those. Bonus points for Ubuntu not having disabled the built-in version checks in a lot of software (it's usually just a compile time options or command line argument!), so it nags users that they're running outdated software when there's no way to upgrade!
At this point I'm convinced the only noteworthy software that Ubuntu manages to have acceptably recent versions of is Firefox. If all you want to do is browse web, Ubuntu might be less work.
I'm not surprised Ubuntu is trying to move to snap packages. That's their last ditch attempt at getting their house in order.
Arch will always at least have an automatically installing AUR package for you with a version that isn't from 2018.
The last time I seriously tried to use Ubuntu was probably 8-10 years ago and I ran into a lot of trouble trying to get up to date graphics drivers via PPAs. I also remember being tired of having to go find a random PPA for every piece of software I wanted. Most of the time I would just find some random blog that provided a "PPA for up-to-date package X" and ultimately felt like what I was doing wasn't really any better than downloading random MSIs like you would on Windows.
With Arch though you get the AUR which quite literally has every piece of software you could ever want and is at least managed and maintained in a central place so you're not just adding random PPAs for everything.
I don't think the AUR is necessarily more secure but in general the nature of how the AUR works does perhaps give some slight advantage. The suggested approach to the AUR is to download and inspect the PKGBUILD so you know how/what the package is doing opposed to a PPA typically being a precompiled binary. AUR helpers will also typically show recent comments, etc. so if a package was compromised or had issues you'd probably know as you're pulling it down.
Really though the AUR just tends to be more convenient and complete than finding random PPAs in my experience.
You're supposed to separately manage the software you care about. e.g. there's a nodejs for people who don't exploit it in their daily use except as dependencies to other software, but if you use it regularly you should manage your own nodejs binaries.
If so, why is this the distribution's fault? The installation is a bit cumbersome but other than that you do not need to do much.
I personally keep my configuration small and tidy, following a "bang for the buck" approach and have not faced any issues. Perhaps my usage patterns are just simpler, but even Steam works fine.
With flatpaks/snaps being so ubiquitous it doesn't really matter much at this point anyway.
Being a rolling release goes directly against that. It might be the most stable rolling release together with openSUSE Tumbleweed. When you combine it with a modern filesystem and features like snapshots it really feels solid.
In the context of the Steam Deck they can just test and hold/fix bugs so that's a very different scenario.
There are just too many changes everywhere and different hardware, software combinations, to expect a bug free experience. Not even Apple with a different release model can manage that and they control everything and have most of the hardware combinations to test. Many DEs and bigger applications need a few point releases to be better but maybe you're talking only about the base distro if it's even possible to make that distinction.
All that said, I can thoroughly recommend NixOS (my setup[1]) as an alternative, and I personally predict SteamOS will show up there eventually. Initial setup is a fair bit easier, and being able to seamlessly boot into any of the previous configurations is a big deal. The main issues so far have been with dev env setups (Nix isn't terrible, but it's another language to add on top of my existing setups) and running out of disk space because each upgrade takes multiple GB. Don't install unless you have ~100GB to spare for the root partition and a decently fast Internet connection.
To me arch tries to be fast moving without checking if anything breaks
I switched to macOS several years ago for my personal desktop. I use Ubuntu (or any Linux) only at work where someone else (IT) manages the machine and ensures things work.
Meanwhile Debian and Ubuntu both are a hodgepot of random patches thrown together by more or less (but rather less) knowledgeable maintainers for reasons which are clear only to themselves and involve goals I don't share such as allowing things to run over weird kernels and maintaining some imaginary philosophical open source purity. I wouldn't touch that with a ten feet pole.
I still personnaly believe that the Linux distribution system is the main reason Linux wasn't more successful. I like Arch because amongst all the successful distribution they seem to be the one doing the less.
Yes I occasionally don't know what's causing a problem and I have to reinstall some packages. It's definitely not stable.
But if I needed stability I would have gone for Cent OS or what ever stands for stability nowadays. And that's the beauty of Linux, There's something for everyone.
When you're doing it yourself, every Arch user seems to have a list of things which "aren't working today".
I've been using openSUSE Tumbleweed for a while, which has all the advantages of a rolling distribution like Arch (and their repo is enormous), but also comes with Yast, their frankly amazing graphical administration tool which handles everything.
It doesn't seem that common, at least in the USA, but I recommend it.
I think that having SUSE behind it maybe helps the stability? But I have no concrete knowledge of the testing process that goes into Tumbleweeed.
http://open.qa/ here, and the OpenSUSE specific instance here https://openqa.opensuse.org/
(I use Arch on my desktop & WSL w/ Debian testing at work)
And yet the use "rolling" distributions that often contains exactly the same software.
Please note that security updates for "unstable" distribution are not managed by the security team. Hence, "unstable" does not get security updates in a timely manner. [1]
Sid/Unstable and Testing track upstream releases.
If an upstream developer releases a new version to fix a vulnerability, Sid gets the upstream fix just like other rolling distro.
If a version in Testing has a vulnerability and Testing entered a pre-release freeze the fix gets backported.
If a version in Stable has a vulnerability the fix gets backported.
This is designed to provide the "best of both worlds".
It’s understandable that some would fall on either side of being ok with that gap or not.
Those were entirely understandable given sid's nature, and it was much more reliable and functional than one would have expected from an "unstable" active development OS distro. It wasn't unstable in the sense of crashing or being generally buggy, and it was generally quite possible to use it as an everyday desktop.
It did, at least back then, require more active administration and a corresponding mindset than a fire-and-forget stable release would, though.
Sid might of course work as a basis for a distro for someone like Valve, but I think they'd need to do something similar to what Ubuntu does with freezes and weeding out issues before releases, or at the least have some kind of a delay before updates were pushed to non-testing devices if they based directly on the unstable release.
Too bad for most linuces we still cant build the base system in a single step like we have been able to do since the dawn of time in traditional unices.
sid is not a release, it is a staging area for packages to roll into a release.
You can absolutely upgrade to sid, run it, and get daily updates, at the much higher risk of breakage of your system.
"This distribution will never get released; instead, packages from it will propagate into testing and then into a real release." is a literal quote from https://www.debian.org/releases/sid/
"continuously updated and never released" would be more correct.
It's like saying that a git repository that never gets version tags is "released on every commit".
having a frequently updated system ensure you're constantly exercising the code paths involved. and your change differential for regression testing is much smaller.
Worse for the user experience if users want to self-install stuff, but still.
Is it because openSUSE Tumbleweed is less popular? Too "opinionated" / "customized, with Yast and all? Or just that (someone in) the team is more proficient in Arch?
openSUSE seems more robust than Arch overall, and especially for updates for which you are not particularly expected to read the document before updatinopenSUSE seems more robust than Arch overall, and especially for updates for which you are not particularly expected to read the document before updating [1].
It would seem that just using openSUSE Tumbleweed instead of Arch would mean less maintenance work for Valve because of this. I guess they need to test and validate updates before pushing them to the device anyway.
KDE/Plasma is also a first class desktop environment on openSUSE, so it would also be a good fit, since they are adopting this desktop environment.
Maybe Arch is more "KISS" and therefore easier to hack?
I also wonder if they considered Gentoo, which would help them tweak the (optimization-related) compilation flags for customized builds?
[1] https://wiki.archlinux.org/title/System_maintenance#Read_bef...
I actually used Arch as the base OS for a few linux computer labs (~100 machines) and it was both a joy and a headache. I really enjoyed being able to package proprietary software like Matlab & Mathematica. It was also nice that students had access to the latest software.
However, the stability of the boot process and upgrades was not fun. Identical machines running what should have been the same configuration would drift over time. I used Ansible to template a lot of the configuration but it would basically be a full time job to keep track of everything. Random machines would end up with a broken Pacman keyring causing updates to fail, etc. Somehow partial upgrades were occuring which would break the boot process.
While 90% of software was easy to package, the other 10% were research projects that would make a lot of assumptions regarding what system C++ libraries were available.
So far with NixOS, it is very stable. Unless you are activelly messing with the bootloader settings, it's almost impossible to break since you can select a previous configuration at boot time. While packageing software is not as easy as Arch, having a per-application dependency tree is extreamly helpful.
That said NixOS is currently going through a lot of changes and missing a few things: 1. No easy secure boot configuration. 2. Networking configuration is sort of in a flux between network-manager & systemd-networkd. 3. Packages are typically fairly up-to-date but the consistency is pretty variable.
TLDR; I am curious how Valve is handeling OS upgrades on the Steam Deck. My experience in using pacman -Syu in a unattended* manner was anything but smooth. I would not be suprised if system partitions are RO and/or updated via a disk image.
Overall Guix looked nice but it is very opinionated on the free-software issue which really hurts its adoptability. It is also a niche sibling of an already niche distro so I doubt it would be used in (real) production any time soon.
The community & related projects around NixOS are also very compelling. Structured flakes like devos [1] and developer tools like direnv/nix-shell make getting started very easy. I'm not sure if the same can be said about Guix (I'll admit I having been keeping a close eye on it). The darwin (MacOS) compatability is also a huge selling point since a lot of MacOS developers already need tools like Homebrew.
I agree that, at this stage Guix will have as much success as Hurd does in becoming a production ready system. But I do think there might be some form of borrowing between the Nix and Guix.
In my case however, I'd rather have an Arch-based system with NixOS's clean architecture.
Archlinux isn't much better when it comes to storage efficiency. Arch does not seperate out documentation and development libraries from the main package so there is quite a bit extra stuff in a lot of packages.
Valve can do a lot of things to save space like disable or delete the Pacman cache after every install. They could build their own repos/packages that stripped out documentation and development libraries.
Overall compared to the size of many games, the storage overhead of Arch or Nix is pretty minimal. At Valve's scale either can & probably will be tweaked to take up <10GB. I guess I forgot that the base model's storage is only 64GB. It makes me wonder if they are going to have optimised game downloads with lower resolution textures; many games would use ~10% of the space if the texture's were optimised.
If you just want to own a Steam Deck for the Steam interface, you can do that. The fact that it's just an x86 Ryzen chip at the end of the day guarantees you at least 10 more years of kernel upgrades, and the current state of Proton makes me confident that it can "just work".
For the people who do care about digging in, we can ascertain that they own $400+ enthusiast hardware, they want to tinker to their hearts content. Arch is just "better" at providing custom Proton builds, hunting down esoteric 32-bit libraries, and maintaining "gaming" software like Feral Gamemode, Lutris, Retroarch and Mangohud. No, it won't be stable, but gaming on Windows is not getting any better, nor will it get any better with Windows 11 cutting support for 80% of the world's active computers.
The problem is that one of the primary selling points to publishers is that it prevents you from running games you might have on your machine (DRM.) That is: The biggest feature of steam besides configuring Wine for you is that it doesn't work most of the time.
Weird that the article doesn't mention KDE Plasma as I believe it's another reason why they need rapid development. They are finishing some huge migrations like Wayland and refining their theme and applications so it's even more accessible to less technical folks. I was scared to death when the reviewers were using Plasma docked because it needs a lot of testing before it's ready. That's natural when you are making big changes.
I suppose the real issue I personally take is the wording used here; updates aren't "just updates" and haven't been for a long time, not even in commercial-desktop-land. You have updates that just do things like security and bug fixes, and then there are feature updates, and then you have major changes. In Debian's case, you don't get major updates of packages within a single Debian release. If you started with GNOME2 for example, you don't get GNOME3 until the next Debian release. But you do get GNOME 2.1, 2.2, 2.3 etc. (this is just an example, not a real versioning or naming scheme)
What the article makes it seem is that you don't get minor updates either. Or bug fixes. Perhaps this is a result of trying to 'dumb down' the intricacies of downstream vs. upstream packaging, distributions and multi-project releases.
At the same time, the whole argument doesn't make any sense anyway: if you are Valve, you control your own releases and your own distribution. It matters a whole lot less what 'upstream' vendor your use is doing, because you can always do whatever you want in your own distro. Or better yet, you can take what upstream does, and use backports to get major core changes into your current version. And if that isn't enough, you can take a look at the many bistro-derivatives, including the likes of Ubuntu; they are (sometimes loosely) based on an existing long-term distro but with a lot of local modifications/replacements on top of that.
Because Valve is already making their own distro, it is unlikely to really matter what 'upstream' they use, the only big change would be the standards they uphold (be it packaging methods, like dpkg vs. rpm) or openness (DFSG vs. "I'll just drop this binary in here and see what happens later"). Better yet, if Debian wasn't a good fit, they could have gone with Ubuntu instead. Or any other derivative.
It smells like a 'we wanted something different but not really deal with licensing/legal' combined with 'the new guy runs arch on his Thinkpad so yeah'. In the end if matters a whole lot less than your average distro-war; Valve still just has a distro, they still release it, and they still support it. It's just more hobby-like than production-like at this time. Switching to some SONiC-SAI type architecture would have made more sense.
Valve wants the more frequent update schedule provided by Arch, presumably so that changes they need can be part of official arch releases vs. maintaining their own branches of debian packages that would need merged periodically.