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.
Vortex_Acherontic about 2 hours ago
Quoting: sudoerQuoting: Vortex_AcheronticDoes 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
No need to get emotional just because someone pointed out a weakness in Arch Linux way of releasing updates. Arch could really need such a thing.
OpenQA does in fact limit the surface of errors and helps a lot to ensure stability. You see OpenQA is way more then an "overrated PR gimmick" it is a full CI system and even only briefly cover all of it's capabilities would be an insane wall of text here.
Instead I'll try to answer the other complains you brought to the table:
- Unsynced mirros: Not entirely sure what you mean by that. I know a few cases where zypper (or transactional-update) refuses to refresh the package list due to a missing repo.xml because the mirrors are in fact re-syncing. But that does not cause any damage as nothing happens.
Also if a package is not available in the repos but required zypper will not continue unless the user specifically says so. Also it downloads all packages in advance so it will notice soon enough and ot leave the user with a half updated system. Unless the user specifically says zypper to continue anyway. But that is a user issue not a distro issue. Otherwise ppl would complain it is too respective I guess.
- Packam: Yes I hate it and I don't use it as it causes only issues and indeed package breakage. But that is not an openSUEE issue if some random 3rd party hosts a repo which is neither in sync and not maintained by the openSUSE project. They even warn you about it in their wiki.
After all it's Linux everybody is free to host their own repos. And if the user adds these it is their very own fault. Just as like getting stuff from the AUR can be dangerous.
Simple solution:
a) If some does really require Packman stuff the heck install that stuff via distrobox instead of nuking your host system.
or b) Don't use it.
Installing AUR on Arch using distrobox is actually a good practise there as well. Even I on openSUSE use this way to get some AUR packages.
- OBS Hell: Well it is just the AUR for openSUSE so the same rules apply here. Use it on you own risk and stop complaining about breaking packages if you do. I mean there is a reason why opi (OBS Package Installer) marks home: repos red and warns you if you select those.
Solutions:
a) Install the home: packages in a distrobox container
or b) Don't use it
- SUSE: Yeah SUSE is SUSE they do SUSE stuff. Glad Tumbleweed does not follow their wired decisions. Leap on the other hand .. oh boi I mean I am not a fan of point-release in general. But Leap really s*cks I agree.
Also as a long time openSUSE user I couldn't care less on what SUSE does. Their music videos are kinda funny but that's all.
- Altering permissions: Hm, IDK what you mean by that tbh. It is treu that if someone installed packages from Packman directory permissions in deed get messed up. But that's because it is a 3rd party repo and it is not officially supported. So yeah. I guess the AUR rule applies here. Use it on you own risk. And if you do you are your own support instead of ranting about the distro you just nuked on your own.
Reading the forum post you linked. Which is 3 years old, talks about Leap to Tumbleweed migration and also the topic talks about an external proprietary generic RPM by some 3rd party. I don't think this is a distro issue if a user installs random RPMs from the internet.
I am actually surprised the user did only ran into the permissions issue and not anything more dramatic tbh.
Anyway, we have distrobox for this use case for a reason.
Last edited by Vortex_Acherontic on 28 September 2024 at 7:19 pm UTC
Quoting: TuxeeQuoting: wytrabbitQuoting: MacTavishMeanwhile the steam client still sucks on linux. When a new revamped Wayland native Linux Steam client?
I don't have any problems with it.. In what way does it suck?
I do have a really peculiar issue. Whenever I start Steam via desktop icon which has a
Exec=/usr/games/steam %U
line, the client will start but will only show the indicator which in turn apart from allowing to exit the client will play dead. When starting from the command line with
$ /usr/games/steam
it works as expected (as does Steam when installed as snap package).
I wouldn't say it sucks but it... has issues.
That's because of a conflict with your iGPU in GNOME (which handles multiple GPUs). You should disable it in your BIOS, and everything will work as intended.
Last edited by omer666 on 28 September 2024 at 8:37 pm UTC
Quoting: WORMQuoteThe 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.
My assumption is this requires building on build servers instead of building on maintainers' machines like they currently do.
Nah, in cryptography we already have a solution for that.
Key signing.
The basic idea is:
The user gets the public key of the central(root) private key.
you generate your key pair, the root key signs a file containing at least your public key and any data we want to transfer with it(signing date, name, phone number, limits, etc.), you sign your code with your key, you distribute with the signed code the signed document, the user first confirms the document with the root key, than they confirm your code with the key contained in the file.
This is how encryption works on the web.
Take for example GOL.
If you click on the lock above you find if you understand what your looking at:
Liam generated a key pair.
Google Trust Services signed his public key with their private key.
The Root key of google signed the Google Trust Services key.
Your OS or browser(if you're using a firefox fork) confirms the trust worthiness of the Root key.
Patreon
PayPal
See more from me