This RPS article adds nothing to that original PC Gamer piece. From the RPS article:
> PC Gamer got the scoop on this. Valve designer Lawrence Yang told them: "So, Arch Linux, one of the main reasons - there's a couple - but the main reason is the rolling updates of Arch allows us to have more rapid development for SteamOS 3.0. We were making a bunch of updates and changes to specifically make sure that things work well for Steam Deck, and Arch just ended up being a better choice for them."
I've been running Arch on multiple machines for 10 years at this point. Been through the systemd transition. In my experience there is very little breakage, and it's easier to deal with than a huge upgrade every 6 months or more.
I'm guessing Valve will not deploy Arch packages directly to the Deck, but instead do weekly/monthly releases that are properly QA'd. It should be very smooth while giving them flexibility to deploy the patches they didn't upstream yet.
I have the opposite experience, I have had several breakages with Arch in a years time. (without Timeshift - i would have been totally lost how to fix the breakages).
So right now, if i run a system upgrade (pacman -Syu) my system would not boot.
- i had to exclude linux (nvidia,nvidia-utils) from my pacman system upgrade.
- even then most stuff seems to work, except for steam... however, i don't see any log messages that indicate whats wrong.
- so my current conclusion is not to upgrade for another week or so and then try again...
Also, during the gnome 4 transition I had a similar issue that i had to wait "several" updates until the system upgrade wouldn't break my desktop.
It's great, I've been running an Arch server in my garage for about 6 years. I've had maybe 4 updates break in a way that required manual intervention. I've spent maybe 30 minutes total dealing with OS specific update issues, over 6 years!
My Arch based desktop tends to break more often because it has a lot more stuff installed. Since I use it daily, though, it's pretty quick to roll with the punches.
>and it's easier to deal with than a huge upgrade every 6 months or more.
I ran Arch but moved back to a LTS , it is not about stability but mostly I don't want surprises, my file manager works fine for me now , who knows the next version would remove or break something that will be maybe fixed in a different version but would also introduce a new bug.
For my IDE I keep 3 versions just in case some bug or stupid UI change is introduced, for people like my I think as stable base where you can update only the programs that you want/need is a better solution. I also have the option and used it to get backported kernels and nvidia drivers to get better vulkan support - I am at that point in live where I would dread to see that there is an update pending and there is a new kernel or video driver version available.
Even if they did release packages directly, it is trivial to create automatic snapshots that should breakage occur, relevant system directories can be reverted.
No, not if such breakage causes data loss and damage.
Edit: Did everyone replying here forget we're talking about an embedded device, a game console, before responding? It behooves Valve to do QA above and beyond what Arch has done is what I'm saying. Valve wouldn't want to take the chance of just passing on upstream Arch directly. Devices may end up bricked, customers upset, etc. Testing is good actually. Furthermore, their hardware may not even be something Arch tests on, so it could literally brick the device if they just passed through updates.
You mean like those caused by Mac and Windows updates? No OS is perfect, so I'm sure like any device you use, making backups of data critical to you is still necessary. You know what else can cause data loss? Your hard drive breaking.
Arch Linux is great! As a rolling release it needs "Patch Tuesday" type of updates. Falling behind just few weeks leads to a broken system. Over time too many .pacold, .pacsave and .pacnew files are polluting the filesystem, requiring manual intervention.
I've recently discovered pacdiff [0] to solve that problem, which helped me clean up about 30 leftover .pac[diff|new] files from my everyday desktop machine.
One unfortunate thing with rolling releases is that you shouldn’t fall too far behind.
I had to move abroad for a bit and left my desktop behind. That’s fine. I’ve done this sort of thing before and I just boot it up, apt update, apt upgrade, and I’m good.
With Pac-Man I hit a thing where it wouldn’t upgrade. It couldn’t get me up to date from a year ago.
Had to give it up then because this sort of thing happens to me. Put a desktop in storage a while ago during the pandemic and I’m going to go back to it in a couple of months. It’s Ubuntu, I’m confident I’ll be fine.
Could have been a Layer 8 error, but I’ve just completed my second decade of Linux in my early thirties so I kind of grew up with this stuff.
Yeah having been on many distro for 20 years I just gave up on Windows-like (or MacOS) upgrade experience and just split everything that is important in a NAS, everything transient personnal in a home partition totally isolated from the distro, and the rest in a distro partition that can break any day with no consequence. I even do that too with the NAS since ive been fucked before by an upgrade tainting the same partition all the data was in (stupid of me to trust btrfs).
There s no attempt at building a comfortable product, but that s fine.
I know that the quick deprecation of keys inside the arch-keyring can lead to problems when you fall too far behind.
It would be awesome if pacman had an easy way to check what kind of keys are missing, and would automatically try to obtain them...because sometimes I had gpg/pgp problems, too, and these kind of problems are kinda unnecessary.
Same experience and same conclusion except I did the move back to ubuntu a year ago. I guess there's 3 type of user, the one who care about latest and greatest, the ones who don't and the one who aren't sure yet. I went for the third one to the second one
I expect that Steam Decks will have forced updates, users are accustomed to this kind of thing (Nintendo Switch nags you to update every time it comes out of sleep).
I think that Fedora SilverBlue would have been the perfect OS for these kinds of consumer products. Arch is great and probably very rarely breaks but if it does, there is very few ways to recover the situation other than instructing users to reinstall the OS.
With something like fedora silverblue, if an update fails, The system can reboot in to the previous OS image without issue. It also ensures that there is a known state for the OS without having to deal with the fact that users may have changed things which breaks an update.
> Arch is great and probably very rarely breaks but if it does, there is very few ways to recover the situation other than instructing users to reinstall the OS.
What are you talking about? Whenever things break in Arch, I fix them in my own install, either by downgrading a package that may be causing problems, or worst case with a USB stick which can enable me to chroot in the system again. Never had to reinstall anything from scratch.
On top of that, Valve will use its own repositories and you can be sure that for a SINGLE device, they will test things and make sure they don't break when they roll things out. That's a non-issue from the get go.
The problem is you can not tell users to just go fix it themselves. This is a device that should not _ever_ require fixing. It is not ok to ever tell a casual user to open up a terminal and correct the system state.
An immutable OS gives a huge safety layer by allowing all mistakes to be rolled back automatically.
Immutable OS does not mean it is not customizable. Your own customization just go in to "layers" which are applied on top of the OS. Means that if something stuffs up, you turn off your own layers and see if the problem goes away.
> Arch is great and probably very rarely breaks but if it does, there is very few ways to recover the situation other than instructing users to reinstall the OS.
Is there any citation to support this? I’ve run arch for 11 years, never once on that same computer did I have to reinstall the OS. On the rest that have been running it for 2y and 5y they’ve never had that issue, nor instruction.
Yes, me! Just a few weeks ago my Thinkpad ran out of battery mid upgrade (`pacman -Syu`) and got corrupted so bad it caused a kernel panic right after the LUKS prompt. Only took an hour to boot into the live USB, chroot into the disk installation (`arch-chroot`, but don't forget to mount `/boot` afterwards!!!), and reinstall the entire OS with `pacman -Qqn | pacman --overwrite "*" -S -` followed by `pacman -Syyu` (to update bootloader, just in case).
Reinstalled the OS and didn't even have to restore a single dotfile.
Edit: You may have to update your live USB packages first so run `mount -o remount,size=4G /run/archiso/cowspace && pacman -Syu` (cowspace is a ramdisk so make sure you've got the memory)
Edit2: I really hoped "and didn't even have to restore a single dotfile" was enough of a clue that this was tongue-in-cheek. I migrated to Arch a few months ago after two decades of Windows so as far as OS reinstalls go, this was like Microsoft sending me a giant settlement check with triple damages.
Wow. How’s that a reasonable answer? The OS did a very bad job at upgrading something that should be upgraded in an atomic fashion and blew up on both that and a failsafe boot to previous kernel. Neither should happen.
Fedora silverblue can recover from this state. The kernel is just a file inside the OS image. If the latest OS image is corrupted due to a power failure, it will just boot the previous image which is still working.
I have the same experience with Arch. If anything has ever been borked a quick search and at worst Ctrl-Alt-F3 to get to a different TTY and running some commands has fixed whatever it was. I've never needed recovery or a separate boot device. Meanwhile, I've had a few fiascos with Ubuntu dist upgrades.
>at worst Ctrl-Alt-F3 to get to a different TTY and running some commands has fixed whatever it was.
For the average user of a hand held gaming console you may as well tell them to pop the back off and replace the chips on the PCB.
At most you could tell them to hold a button combo to factory reset but ideally you would want some way to roll back the whole OS state to the previous working version. Silverblue allows this to happen in a fairly elegant way by making the OS an image file and mounting it as read only so a roll back is simply mounting an older image.
Say valve pushes out a bad update that messes up the package manager list or puts it in a bad state, there is no recovery method. I guess one thing they could do is have some button combo you hold while booting which copies a fresh OS copy from a protected partition.
I'm sure you could imagine countless ways that a update could possibly break things.
The use case is very different here thought. For a handheld game console, it really has to work forever (or as long as the hardware lasts) without a single issue or ever requiring users to fix anything. The competitors here are nintendo consoles, and the playstation.
It's not acceptable to say "oh its ok you can just open the terminal to fix and I haven't had an issue in 2 years". It has to be essentially perfect or able to recover itself from any kind of software fault without much user intervention.
>The competitors here are nintendo consoles, and the playstation.
Nope, the competition is GPD and other UMPCs. Valve is quite clear about the fact that this is a PC, not a game console. It's a portable gaming PC, but not a console. It's a general purpose computer. I expect a lot of people to install Windows on it, too.
No, it's based on ostree for system distribution (which Colin had been developing since 2011), and using flatpak for applications. This had been a goal of the Red Hat desktop team for a while (see also: Stateless Linux from the 90s), but it took a long time for the community to realize the benefits. Other approaches here are the ChromeOS image style updates, CoreOS's image style updates, systemd's btrfs based OS distribution, and quite a few more throughout history. It's a good idea.
Collabora's SingularityOS they built for Valve for the original SteamOS was going to use ostree, but for various reasons (poor ones), they didn't ship that.
SilverBlue is not a clone of any existing system. It's a brand new setup which treats the OS as read only layered images. A little bit like docker. The key feature is that you can roll back a failed update by simply mounting an older image. You can also allow the user to customize things by adding on extra layers and if anything ever goes wrong, you just boot without the users layers to restore a stock system.
For consumer level hardware this is essential to make sure it never ends up "bricked". The average user can not and will not reinstall an OS manually so if the OS gets in a bad state, the whole device is ewaste now.
Not quite. Silverblue is based around flatpak's (containers) and composing your OS from a set of containers.
NixOs is based on Nix, which doesn't use containers but links binaries against specific versions of dynamic libraries to resolve dependency issues and allow for reliable installations.
Would not ubuntu or fedora be better if you wanted faster release? In my experience when I used to run arch (~4 years ago) I had breaking changes every couple of months where with Fedora I never had one except when I was the culprit by adding a graphics card with proprietary drivers.
Been running arch for nearly 10 years and the only couple of breaking changes I had were either from ignorance or not reading special update instructions.
Also Arch is far more up to date than those you mention (sometimes by many months.) You're not confusing it with another distro?
Them using an arch base doesn’t mean they’ll be running arch as if it was the same end user of a manual arch installation. I’d bet steam is using arch as the base and acting as canonical or whoever vetting (and automating) the upstream changes.
No, Arch uses recent kernel and releases packages significantly quicker than what is available on Ubuntu/Fedora. I'd like to say I've been running Arch for 4 years now and any breaking change was directly due to my own action(s). With them largely in control of the OS, I doubt there would ever be a breaking change that could not be quickly reverted via adequate snapshots and ability to boot a backup root file image.
I’ve been running arch for 11 years, I’ve only had breaking changes a small handful of times, all of which were covered in an alert (email) of what to run to carry on. The only one that wasn’t was an upstream issue on chrome that was a secondary browser for me anyway.
Ubuntu wouldn’t be a faster release, as it’s not rolling release. However Fedora would be in a similar step as arch.
The parting words of the article, on what seems to be a site for PC gamers, looks significant to me:
> but I need a reason to get into Linux and stick with it. Valve’s work might get me there.
How many PC gamers an article with this title will reach, I don't know, but getting more people thinking about "Linux" seems good (even if the open systems guts are in a somewhat closed appliance). Especially when gaming has been keeping a lot of expensive home PCs on Windows -- thereby keeping a lot of other things people do on Windows.
I've run arch on probably a dozen or more physical machines (more if you count VMs) over the last 12 years. I can count the number of breaking updates on 1 hand. The talk about it being unstable may have been sort of true 10 years ago, but now it's just complete FUD.
I mean, everybody blaming Arch for being breaking and unstable...as if Debian or Ubuntu never were unstable. Quick to forget all the Mir, GNOME, wayland messups, huh?
The huge difference with Arch is that it's usually recoverable, no matter what's broken. And that's what I like the most about it.
Debian is more recoverable though. dpkg is much more robust regarding rollbacks and installation failures in cases that pacman (by design) simply does not handle at all. It's much easier to break something in Arch and not notice at all until things start layering up (although it also means it's easier to fix things up "just enough", while Debian will give you hard time until the issue is resolved completely).
https://news.ycombinator.com/item?id=28119317