Recently we had the big news that Valve (Steam) began a collaboration with Arch Linux, to help fund two very specific parts of the Linux distribution. Now, we have a bit more info on what it means.
After an interview recently from the A1RM4X YouTube channel with an Arch Linux developer, Antiz, they took to Reddit to explain things a little bit further to help people understand what's happening. Here's an excerpt:
Basically, the way packages are currently built / managed still requires a few manual interventions from Package Maintainers (e.g. triggering the build itself and signing the built packages afterwards). As of now, supporting multiple architectures would mean multiplying those manual steps by the number of supported / targeted architectures. With the current number of packages compared to the current number of (volunteers) Package Maintainers maintaining them, Arch is not able to handle the extra amount of effort that it would imply.
A central build service and a central secure signing enclave (the two projects concerned by that Valve "sponsoring") would streamline the overall process by allowing automated build and signing for packages without requiring any manual steps / interventions from Package Maintainers anymore (and it will also allow to increase the security of the process as a side benefit). Only such a streamlined / automated workflow would allow us to start working on supporting multiple architectures without implying to multiply the current amount of required effort.
In other words, those projects are prerequisites to start working on multiple architectures support in a clean & sane way, which is a end goal shared by both Arch and Valve.
So basically, a lot of it is towards supporting multiple architectures. And with the news that Valve are seemingly working on supporting some form of Arm and Android support (likely for a future VR headset), this definitely makes sense. Especially when Valve already use Arch Linux for SteamOS on the Steam Deck, it seems increasingly likely that Valve will use an Arch Linux base for what comes next.
Antiz has also been replying to other comments on Reddit, in one post nothing that it is very much their "end goal" for Arch Linux to support multiple architectures.
Check out the full interview on the A1RM4X YouTube channel with the Arch Linux developer Antiz:
Direct Link
And then I guess make it easier for the future when x86 inevitably dies, and there's some new competitor to Arm, this project could support that...?
Are they also talking about Operating Systems as well? Like how both windows and linux run on x86 but a lot of apps / games only release on windows (and then run on linux via proton).
Last edited by Jarmer on 3 October 2024 at 12:18 pm UTC
Quoting: Jarmerso basically they want to make it easier for the developers of App XYZ (or Game ABC) to just push a button for deployment and BAM their app/game is available on x86 or Arm? Is that correct?
No, this is purely about the OS layer. At the moment Arch only supports x86_64, and lacks the resources/motivation to support any other architectures because providing packages for these is a timesink/chore right now. Arch has had vague plans to improve the packaging infrastructure (to make supporting other architectures easier) for a while, but hasn't gotten around to doing so. Valve have basically come along and asked how they can help.
BlackBloodRum about 2 hours ago
If I had to guess, this is preparation for Steam Deck 2? or perhaps a new SteamOS? Maybe preperation for making SteamOS an OS for anything? Something is happening either way, and with a bit of luck it'll provide that nice easy to use OS we can point all new users to and say "Use this, it works out the box for most things" as opposed to having to say "For nvidia try this distro, for amd try this one, oh and if you need this, try that distro over there, etc.
I think I know what is happening here.
During his 2013 talk at LinuxCon Gabe confessed that his next target for Linux compatibility was hardware compatibility.
I thought the Steam Deck was the final answer to that, but I think he saw opportunity to get more.
You see ARM is a platform that built itself on Linux.
Essentially all ARM compatible is Linux compatible thanks to this.
There're even ARM processors with fully open firmware.
Thanks to Apple, Microsoft suddenly started enabling the option to support ARM through Wine.
Microsoft rules x86(_64), but ARM is deeply integrated in open source software.
I think this madlad is working on ARCH/GNU/LINUX/ARM device and possibly(I can dream) using locally compiled software like Android does it, making CopyLeft ten times as enforcable.
Compatibility would be achieved by providing developers with the tools to compile for a ton hardware at once, porting, Microsoft bribes and emulation(pay attention to the QUEMU project).
I expect a VAC port to Linux/ARM
What I'm not certain about is a VAC port to Windows/ARM. One could argue that to avoid anti-trust they must and one could argue that since they aren't an anti-cheat monopolist, not an OS monopolist, porting it to Windows/ARM requires some extra effort and Windows on ARM is an insignificant platform to them they can get away with it.
I think the Apple vs NVIDIA & Microsoft case about GameStreaming availability can answer that question.
Quoting: Jarmerso basically they want to make it easier for the developers of App XYZ (or Game ABC) to just push a button for deployment and BAM their app/game is available on x86 or Arm? Is that correct? Those are pretty much the only architectures popular right now correct? All computers / phones / etc run on either x86 or Arm right?
And then I guess make it easier for the future when x86 inevitably dies, and there's some new competitor to Arm, this project could support that...?
Are they also talking about Operating Systems as well? Like how both windows and linux run on x86 but a lot of apps / games only release on windows (and then run on linux via proton).
This is mostly ARM/X86.
OS compatibility is only a little true.
I expect the tools the arch team builds to default to Linux compatibility, but allow for incompatibility.
Expect things like: the first iterations of the product don't run on Windows without WSL or another VM, it takes several years before you don't have to manually configure system library searches to compile for only Windows, key signing for Windows with the product first requires reverse engineering your own binaries and later requires you to follow some hacky tutorial, Proton incompatible Window API features take looong to get supported and Driver testing on Windows takes years to get supported.
Patreon
PayPal
See more from me