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

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

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.

So yes, TH's speculation is just off the mark here.

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.

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

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

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.

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.

I agree with you, just nitpicking: it is smaller than some (like Debian) and less commercial than others (like Ubuntu).

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.

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.

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.