>They fixed the worst thing about SteamOS: It's now got an Arch base.
I'm a little surprised they didn't go with something like Fedora. The kernel / drivers are kept just as up-to-date as Arch but the rest of the system is a little more stable.
1. Fedora is not a rolling release, so you don't get every single kernel point release like you do in Arch.
2. Steam does not want to do a full Fedora 30 to 31 upgrade every six months. They want to roll. It's a better model, especially when kernel/drivers are improving gaming quickly.
3. Arch has a stable base and gets small updates every day. Regular software services tell us this is a better model than infrequent large updates. Things like RHEL are the exception, but take years of QA, and leave you with old drivers in between releases.
> 1. Fedora is not a rolling release, so you don't get every single kernel point release like you do in Arch.
Fedora rolls the kernel. I'm on Fedora 33 (a full release behind), and yet I still have kernel 5.12.15, the exact same as Arch currently has. I don't have any custom repos configured.
On rare occasions Fedora even gets new kernels faster than Arch, but usually it's less than a week behind.
>2. Steam does not want to do a full Fedora 30 to 31 upgrade every six months. They want to roll. It's a better model, especially when kernel/drivers are improving gaming quickly.
Fedora gets constant Mesa updates as well, it's not pinned. Admittedly it's 2 months behind Arch (21.0 vs 21.1)
You can add the 2 kernel packages to the ignored packages list of pacman and update them manually if needed. Pacman will warn you that it ignored a package update including the currently installed and new package version.
You will not get security and bug fixes but that's what's bothering you, I think.
Fedora updates everything that isn't a breaking change in between releases. Stuff like major gnome versions or replacing core components with similar but incompatible components gets held back for a major release.
> 1. Fedora is not a rolling release, so you don't get every single kernel point release like you do in Arch.
Wrong. The kernel and mesa stack rolls and is rebased regularly throughout the life of a Fedora release. Fedora is prepping for a rebase to Linux 5.13 for both Fedora 33 and Fedora 34 now: https://fedoramagazine.org/contribute-to-fedora-linux-kernel...
Bingo, the kernel updates through the life of the fedora release. Then it stops. The life of a console is 8+ years. This needs to be supported for that long. Valve don't want to do multiple dist-upgrades over that time. They just want roll
From my personal experience not really. I’ve steam running on an about 2yo old (at this point) Gentoo system that’s still working perfectly fine. I really should update it but I don’t do much on that system except play a single game.
I don't know a ton about this, but I thought their major issue was games needing new versions of some random libraries. Being more up to date than Debian would still put you (presumably) years behind.
Mesa and the kernel would be less important, as all the hardware needs to be supported by them on release.
> I don't know a ton about this, but I thought their major issue was games needing new versions of some random libraries. Being more up to date than Debian would still put you (presumably) years behind.
That's not the case w/ the Fedora release cycle. Like I said, it's only slightly behind Arch.
fedora will also patch stuff from upstream to include in their distro. for better or worse arch will try to upstream the patch and if they don't like it just keep an older version around if they don't accept it
Both Fedora and Arch share that philosophy, though. There are very very few patches in Fedora compared to the Debian ecosystem - and often the only exceptions are support for features that in the process of being upstreamed, like Firefox' hardware acceleration support that was added by a Red Hat engineer.
dnf is a large and complex tool to manage a format that has miles of backwards compatibility (and, for extra inconsistent fun, random cases of incompatibility, since they forcibly broke spec at some point, without changing the extension of rpm, so while there's the expectation of compatibility, many old packages just won't work at all and you'll have very little clue as to why unless you're familiar with the history of the format), and has a lot more to it than pacman.
I'm not talking about the workflow for an end-user: Valve is definitely not going to force people to run terminal commands to update their systems. While pacman's update workflow is way simpler than dnf's, it's just not relevant here.
I was primarily talking about the complexity of the tool itself, of updates, and also the complexity of packaging. Arch is a packager's distro, and much of the foundation Arch is built on is the Crux-style "as simple as possible" mindset. There's much less that can go wrong when you're doing much less with much smaller tools.
I'm not hating on dnf or rpm, here, for the record. They're fine tools for their use cases.
I'm a little surprised they didn't go with something like Fedora. The kernel / drivers are kept just as up-to-date as Arch but the rest of the system is a little more stable.