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.
Article taken from GamingOnLinux.com.
Quotea 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 1 hour ago
Quoting: fenglengshunI 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 34 minutes ago
I can dream i know
Just hoping that collab goes far but sad they don't also work with debian and gentoo
Quoting: MacTavishMeanwhile 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
Patreon
PayPal
See more from me