>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.
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.
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...
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)
My favorite part of Arch is the rolling packages and my least favorite is the rolling kernel. I dislike having to reboot so often.
You will not get security and bug fixes but that's what's bothering you, I think.
The most important libraries for Steam are things like Mesa, which Fedora updates on a rolling basis along with the kernel.
https://src.fedoraproject.org/rpms/grub2/tree/rawhide
Some of these are pretty questionable, particularly disabling the use of "grub-install" on UEFI systems (https://bugzilla.redhat.com/show_bug.cgi?id=1917213)
Mesa and the kernel would be less important, as all the hardware needs to be supported by them on release.
That's not the case w/ the Fedora release cycle. Like I said, it's only slightly behind Arch.
I guess I don't understand what complexity there is to remove in the first place.
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.