It was likely no secret to most Linux users who know a bit about distributions but Valve has clarified directly that the main reason for dumping Debian Linux for Arch Linux was for faster updates.
Previous versions of SteamOS were based on Debian which has a fresh release every 2 years or so, where during that time most of the software stack is frozen in place. For a Linux gaming device, that's obviously not ideal. Gaming on Linux as a whole often needs more up to date packages because everything moves so quickly. Especially for Steam Play Proton, which has at multiple times needed updates to various packages and newer GPU drivers. Arch Linux on the other hand rolls over constantly with updates and so it gives Valve the flexibility they're needing to more easily pull them in.
PC Gamer, one of the lucky few who recently went to the Valve HQ spoke to Valve designer, Lawrence Yang:
"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," says Yang. "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."
Valve upgrades the Steam Client constantly and no doubt they will be doing the same with SteamOS 3 once the Steam Deck actually rolls out. Having finer control over everything that they would get with Arch Linux is basically a no-brainer, as is the huge availability of software that comes with Arch and the AUR (Arch User Repository), something that will be a big boon for the desktop mode.
It's not likely that SteamOS 3 will just plainly update directly from Arch though, as that could end up messy. They will likely bundle updates together once they've been firmly tested. More like a Manjaro approach but with more clear QA done.
Last edited by Nevertheless on 10 August 2021 at 10:37 am UTC
Beeing upstream makes sense for a distributor.. But it's good they make a point release distro out of it, so they have actuality AND stability in their hands. At least for the core software...
They're probably going the "Manjaro route" on this one
If that's the case, how come they didn't decide to use Debian Testing instead?
AFAIK the main Linux developer at Valve doesn't like Debian's package format. While I'm on Debian's side, I don't care too much which one they use.
If that's the case, how come they didn't decide to use Debian Testing instead?
Debian Testing also stops when main Debian freezes for a new release. If they were to use a Debian flavour, probably sid (unstable) would have been better. However, based on my experience until I moved to fedora, Debian unstable was very low on the uptake of linux-nonfree-firmware as well as Mesa. Let's also not forget that Debian did not have an AUR until recently, and that historically Debian devs are stricter about what goes into their repos.
Personally, I would have liked a rpm based distro for SteamOS 3.0 but, at the end of the day, I also hope that much tinkering won't be required on the device, so it doesn't really matter.
Last edited by Arehandoro on 10 August 2021 at 11:40 am UTC
Beeing upstream makes sense for a distributor.. But it's good they make a point release distro out of it, so they have actuality AND stability in their hands. At least for the core software...
They're probably going the "Manjaro route" on this one
In one of the hands on videos ( https://www.youtube.com/watch?v=jb6OWxORfY0 )
at around 9 minutes, the Valve guy shows how it's updated, and he says "system, Steamplay and Bios-updates" are updated at once in a big package for the benefit of knowing exactly whats on the device.
So I wouldn't expect anything like Manjaro..
Last edited by Nevertheless on 10 August 2021 at 12:21 pm UTC
As it's more updated, it need to have a far better debugging and QA tests. I'm not sure if a gaming machine needs updated libraries.
Valve will have to do QA for themselves anyway. They are heavily invested with a lot of upstream libraries at the moment and will probably want to use their latest features. Rolling release distributions do make sense in that regard as the tests distros like debian does would need to be redone anyways after valves changes are applied. So either go full rolling release as a base like Manjaro or do something in the line of packages with mixed recency like KDE Neon. They seem to be tryining the former now. They switch back somewhere in the future.
In one of the hands on videos ( https://www.youtube-nocookie.com/c274cab9-49dd-48b2-acf3-7b6bc8574acb )Well, that is basically how Manjaro do updates though. They bundle everything together, test a bit and then release. Just because Valve have more (like their own stuff included), doesn't mean it's entirely different.
at around 9 minutes, the Valve guy shows how it's updated, and he says "system, Steamplay and Bios-updates" are updated at once in a big package for the benefit of knowing exactly whats on the device.
So I wouldn't expect anything like Manjaro..
Valve guy shows how it's updated, and he says "system, Steamplay and Bios-updates" are updated at once in a big package for the benefit of knowing exactly whats on the device.
So I wouldn't expect anything like Manjaro..
Manjaro usually release updates in "packages" too like you can see here
They're even criticized by vanilla Arch/other forks users for not releasing new packages in the same way as those.
I also couldn't open your youtube link, but judging by your comment for me it seems pretty much similar to Manjaro, but packaged to look like just a single thing (plus bios updates which is nice)
In one of the hands on videos ( https://www.youtube-nocookie.com/c274cab9-49dd-48b2-acf3-7b6bc8574acb )Well, that is basically how Manjaro do updates though. They bundle everything together, test a bit and then release. Just because Valve have more (like their own stuff included), doesn't mean it's entirely different.
at around 9 minutes, the Valve guy shows how it's updated, and he says "system, Steamplay and Bios-updates" are updated at once in a big package for the benefit of knowing exactly whats on the device.
So I wouldn't expect anything like Manjaro..
Not entirely, but I wouldn't expect much choice regarding kernel/drivers/system software.
And like I said, I think that would be a good idea.
Valve guy shows how it's updated, and he says "system, Steamplay and Bios-updates" are updated at once in a big package for the benefit of knowing exactly whats on the device.
So I wouldn't expect anything like Manjaro..
Manjaro usually release updates in "packages" too like you can see here
They're even criticized by vanilla Arch/other forks users for not releasing new packages in the same way as those.
I also couldn't open your youtube link, but judging by your comment for me it seems pretty much similar to Manjaro, but packaged to look like just a single thing (plus bios updates which is nice)
Thanks, the link works now.
Unfortunately every time I tried out Manjaro something broke after an update.. maybe I should try again.
Or allow global packages to install into /usr/local or /opt only? (as the base OS would be a read-only FS if it's image driven)
I stand corrected about the Manjaro update policy. I actually like that much more than the Arch way, cause I think it should help to prevent a lot of upstream problems I wouldn't want to deal with.
Unfortunately every time I tried out Manjaro something broke after an update.. maybe I should try again.
Think manjaro does that to a lot of people personnally am looking at os endeavour it's from a team of long dead antigos distro and it's been brilliant on my test pos dell
AFAIK the main Linux developer at Valve doesn't like Debian's package format.
If that's true, then I don't think it's worth discussing any other reasons. This one is the only one that matters :P
They will have package managers adequate for many users likewise.
Also various DEs available.
This is great for everyone, let them fight for popularity!
Having the base OS update like firmware really makes sense for this, but since it's a "PC" they would need to allow user apps to update separately. Possibly have those bundle as appimages or flatpacks or something?
Or allow global packages to install into /usr/local or /opt only? (as the base OS would be a read-only FS if it's image driven)
The underlying FS, BTRFS, allows for subvolumes and snapshots. I could see it downloading the subvolume whole and switching to it on reboot.
Or it could just download a huge zip file with an update script to run the package manager and use the file as the repo, lol. No need to invent the wheel.
See more from me