Hacker News Reader

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.)

Minor nit pick, but gentoo has had binary downloads since dec 2023 and has supported binary updates for years

https://www.gentoo.org/news/2023/12/29/Gentoo-binary.html

And if Gentoo's binary support is good enough for even ChromeOS, I'd imagine it'll also work perfectly fine for SteamOS.

Interesting summary - what's your take on opensuse? Seems like solid system but hasn't seemed to grow the way I'd expect

It doesn't seem to have much traction outside of Germany.

You’re probably right, but there are some exceptions such as Home Depot.

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.

Ubuntu alphabetical names help if you keep up with it. I can name various releases of the past, like debian, and don't know which is the latest one.

And with numbers you don't need to remember anything, especially if they are release years.

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.

...so they picked a rolling release distro to take snapshots of and distribute outdated versions to their users. Plasma in SteamOS 3.6 (current beta) is still at version 5.27, just like in Debian stable.

The main reason they switched were PKGBUILDs. Debian packaging, while much more powerful, requires more effort, and yet they weren't going to reap its fruits as their distro gets fully reinstalled on each update anyway. Nothing else matters much for their particular use-case. If it was about fresher base system, they could have gone with snapshots of sid instead, which would have been easier as previous SteamOS versions were already Debian-based.

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.

> Python 3.12 & Gnome release delays just to give an example.

GNOME updates usually come when the packagers have time, latest this usually is the .1 release. 47 for example was available like a few days after the official release, if not a day or so after (I didn't check specific dates, but that was when I updated).

With other software it usually depends on if dependencies can work with the new version. LLVM is a major package that always is like 1 release behind due to stuff that depend on it not being updated for the new version. And shipping multiple of a single package is something they try to avoid.

> 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).

> 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.

it does go hand in hand. The max potential may not be faster, but if you have the time and expertise to hyperoptimize, getting those bits of power out can be crucial.

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.

The arch used in steam deck is already used as a immutable base. Users typically use flatpak to install custom software. It's possible to remove the read-only lock, but any modifications to base will get overwritten by updates.