This is some pretty exciting news! The Arch Linux team have announced a new direct collaboration with Valve (Steam). Something that's not too surprising, since Valve do fund a lot of open source work, and SteamOS for Steam Deck is built directly on Arch Linux so working more closely together makes a lot of sense.
Posted to the Arch developer mailing list by Levente Polyak, the Arch Linux leader:
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.
[RFCs]: https://rfc.archlinux.page/
The secure signing enclave could certainly be an interesting one. What do you think Valve and the Arch team will be cooking up with that? This is something that could perhaps be a useful change for anti-cheat to have a more secure platform on Arch and so SteamOS / Steam Deck, and potentially get more games to enable it for us.
Update 28/09/24 - 14:13 UTC: Arch Linux packager and Valve collaborator Campbell Jones, mentioned to me:
Article taken from GamingOnLinux.com.The enclave is essentially intended to be a way for us to PGP-sign packages with a single signing key instead of how we do it right now, which is with one personal key per packager. It will not benefit Proton or the anti-cheat situation in any way and is completely unrelated.
fenglengshun Sep 28
Then again, I don't need THAT much stuff on host system anymore (vs user-space) so I could settle with SteamOS official desktop installer once my Wayland and Portals woes are settled (currently, mainly usb-portal for gnome-boxes and just general Remote Desktop stuff).
.
officernice Sep 28
The second one is developers supporting the platform. Something many do not want to do even when in some cases it is as easy as enabling a checkbox.
Independently of this, great news BTW!
Last edited by doragasu on 28 September 2024 at 9:09 am UTC
pleasereadthemanual Sep 28
just general Remote Desktop stuff).Server RDP or desktop RDP? And what issues?
(as a curious person who runs a GNOME-based RDP server)
If we're being optimistic about that secure signing piece targeting better anti-cheat, I'd suggest that Valve are looking to out-perform Windows in that regard, and turn SteamOS into THE trusted way to prevent cheating on any given game. Make it as trusted as a console, or more so if possible.
That would sadly damage regular Linux desktop and its gaming usage as a whole so I really hope it is not the case.
a build service infrastructure and a secure signing enclave
One of the common tactics as of late to discourage kernel-level cheat injection is secure boot, making it difficult (not impossible) to load your cheat before the anticheat can catch it. The problem with secure boot on Linux is that Linux is open source software and users may have a lot of different forks of the same kernel. For the users that are just using the upstream kernels in the Arch repos though, having Valve as a central authority for the Linux ecosystem could mean a good thing for security, since using Valve's key instead of signing with your own keys means cheaters can't just write a cheat as a kernel module and stuff it in the initramfs without resigning the EFI binaries as their own and giving it away.
I don't agree with these approaches to anticheat, but it is what the developers want, and Valve supporting that method to discourage Windows gatekeeping is still better than whatever the alternative is.
Last edited by bonkmaykr on 28 September 2024 at 10:04 am UTC
EduardoMedina Sep 28
I won't lie, as a Bazzite user who builds my own custom image, I kind of wished that Valve would switch to a an rpm-ostree or similar infrastructure. I would love to have SteamOS images, with my own tools pre-baked in.IMHO, OSTree is a very bloated software that steps on things that systemd can do. Even GNOME OS tries to replace it with parts of systemd.
I think that SUSE immutable systems are better focused. transactional-update seems smaller than OSTree and Snapper manages the snapshots. Moreover, in SUSE and openSUSE immutable systems you can rollback things the /etc folder, while with OSTree you only can rollback through the system images. In Aeon Desktop the automatic updates are scheduled with a systemd timer.
Finally, with Aeon Desktop you have a rolling release system, while with Fedora you have a point release system if you don't use the rawhide repo, but rawhide is nothing more than an experimental repo.
I like Fedora, but if you try Aeon Desktop, you can see that it's a lighter system than Silverblue, although the presence of x86_64-v3 packages in Aeon Desktop may be influencing.
Last edited by EduardoMedina on 28 September 2024 at 11:07 am UTC
Vortex_Acherontic Sep 28
I can dream i know
Just hoping that collab goes far but sad they don't also work with debian and gentoo
Meanwhile the steam client still sucks on linux. When a new revamped Wayland native Linux Steam client?
Examples? It runs very well on my Plasma/Wayland setup and the only issue I've had is with GPU accelerated rendering, which seems to be a bit unstable.
Last edited by robvv on 28 September 2024 at 12:14 pm UTC
I guess we'll never see Arch 3.0 now
Hell, we never got to see v1.0. :P
Yes, that was a part of the joke. ;-)
Does this mean Arch Linux finally sees OpenQA like openSUSE and Fedora do to ensure their rolling release stability?
you mean the overrated PR gimmick that in reality does nothing vs. the fame openSUSE has been rightfully granted over the years about breaking due to unsynced mirrors, the usage of Packman, the OBS hell leading to constant dependency hell questions, SUSE's own weird idiosyncracies (sudo non-configuration and various other stuff) and zypper's dangerous practices of altering permissions on system folders without notifying the user? https://forums.opensuse.org/t/master-pdf-rpm-file-conflict/148878/8
Last edited by sudoer on 28 September 2024 at 12:34 pm UTC
How anti-cheat relates to that?To really secure system integrity, there needs to be a full validation chain up to the kernel (and potentially beyond). Without that validation, game devs may continue to distrust anticheat tools on Linux. We don't yet know the new API MS announced to integrate in Windows, but it's really certain Linux will not be able to provide an equivalent unless the kernel and core libraries are build and signed by a trusted entity. Wouldn't make much sense to use that APi if the user can use a patched kernel. As SteamOS uses Archs kernel images and libraries, that must be done in Archs build system, hence the speculation this is related.
To be frank, I think we will see a major shift in cheating and anti-cheat in the coming years, it will be a battle of "AIs".
Patreon
PayPal
See more from me