We are excited to announce that Arch Linux is entering into a direct collaboration with Valve. Valve is generously providing backing for two critical projects that will have a huge impact on our distribution: a build service infrastructure and a secure signing enclave. By supporting work on a freelance basis for these topics, Valve enables us to work on them without being limited solely by the free time of our volunteers.
This opportunity allows us to address some of the biggest outstanding challenges we have been facing for a while. The collaboration will speed-up the progress that would otherwise take much longer for us to achieve, and will ultimately unblock us from finally pursuing some of our planned endeavors. We are incredibly grateful for Valve to make this possible and for their explicit commitment to help and support Arch Linux.
These projects will follow our usual development and consensus-building workflows. [RFCs] will be created for any wide-ranging changes. Discussions on this mailing list as well as issue, milestone and epic planning in our GitLab will provide transparency and insight into the work. We believe this collaboration will greatly benefit Arch Linux, and are looking forward to share further development on this mailing list as work progresses.
Hopefully this would lead to a more (stable version of) ArchLinux.
Arch isn’t unstable. Users mess it up by installing a bunch of random crap from the AUR or fiddling with system files.
SteamOS addresses this by making the root level filesystem immutable and guiding the user to install containerized (flatpak) apps.
Exactly. I ran Arch for over 5 years, and the only “instability” I had was:
That’s really it. I’ve since moved to openSUSE Tumbleweed and an AMD GPU, largely because of built-in snapper support and their server-oriented distros (Leap and MicroOS), and it wasn’t because Arch was “unstable” or anything like that. In fact, I had far fewer issues with Arch than I did with the other distros I used before: Ubuntu and Fedora. It turns out, as you understand Linux better, you tend to mess things up less.
I’ve been using a Steam Deck for almost a year damn near daily with maybe 1 OS crash that was largely due to a very unstable game. How is ArchLinux unstable, exactly?
deleted by creator
This is not true though. Arch packages new program versions as soon as they can - for popular stuff this happens quickly but not everything updates quickly. And when they do publish a new package it goes to the testing repo for a short time before being promoted to the stable repos. If there is a problem with the package that they notice it will be held back until it can be solved. There is not a huge amount of testing that is done here as that is very time consuming and Arch do not have enough man power for this. But they also do not release much broken things at all. I have seen other distros like ubuntu cause far more havoc with a broken update then Arch ever has.
That’s… a weird take. There are variants of Arch that focus on stability, if that’s what you are after.
Which ones? I’m not aware of any besides specialised distros like SteamOS
Try #EndeavourOS!
deleted by creator
they added some nice tools though. e.g. their pacdiff & meld tool eos-pacdiff is pretty nice. then there is a kernel manager and a pretty clever update-script / wrapper around pacman and yay (eos-update). saying it is just Arch + GUI is selling it a bit short imho.
It uses the Arch repos directly though
https://itsfoss.com/arch-based-linux-distros/
Manjaro for example. I also thought Garuda would be focused on stability but according to this article potentially no. So maybe just Manjaro, I do remember reading about something else like it though…
Manjaro has a stability track record miles worse than Arch, to the point where someone made a GitHub wiki called “Manjarno”.
Manjarno, manjarno
— as they say in Spain …
Manjaro does “stability” by delaying everything by two weeks. That doesn’t really help at all and might hurt you for security updates, because those will wait the same two weeks.
They also don’t hold back the aur which causes problems if an aur package is expecting a system package of a particular version, if I understand correctly