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.
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.
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.
hell0 28 Sep 2024
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.
My assumption is this requires building on build servers instead of building on maintainers' machines like they currently do.
Not necessarily. In all likelihood, the enclave will not decide whether it should sign off a package on its own. Which means there should be a way for maintainers to say "this package is authorised and should be signed". This can be done in many ways, including maintainers uploading packages they built themselves (and signed with their own key) to the enclave.
To be clear: they will likely want to move builds to dedicated servers for various reasons, but having an enclave does not make it a hard requirement.
Last edited by hell0 on 28 Sep 2024 at 10:23 pm UTC
marcoshalano 28 Sep 2024
But my first thought was the same as yours.
ElectricPrism 1 Oct 2024
R Daneel Olivaw 1 Oct 2024
CyborgZeta 2 Oct 2024
fenglengshun 3 Oct 2024
Desktop. I mainly used Rustdesk + TeamViewer + AnyDesk, for redundancy in case of connectivity weirdness. Last I tested, unattended access is wonky on KDE and unattended login doesn't work on Wayland at all.just general Remote Desktop stuff).Server RDP or desktop RDP? And what issues?
(as a curious person who runs a GNOME-based RDP server)
I don't disagree that it's bloated, but it is bloated in a way that doesn't bother me and for a benefit that I think is worth it.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.
For me, I just don't like messy packages list. Even in a Distrobox, it bugs me when I have packages that I don't intend to use, that isn't part of the default. The biggest benefit of OSTree for me is their infrastructure- if you take a look at Blue Build system (the now independent image builder aspect of Universal Blue), the effect is that you have a semi-declarative OS image where I can cleanly and clearly put in "Take Bazzite as base, and add these packages." Then Github will build them, and keep 90 days history of them, while my devices has previous image as fallback.
What really made an impression on me was when mainline Kinoite was having an issue once. I just trace each day's image, found when the issue started, test the upstream ublue Kinoitr image of that day, then test the ublue image's upstream in mainline Kinoite... I can just say "Here, this is where the problem started, and it's likely because of this commit." That was a great bug reporting experience, likely both on my and the devs' end. I liked that, and that's why I have a strong feeling towards rpm-ostree.
const 3 Oct 2024
Sure, it's always the first thing to try, but sometimes even that failed. There are similar commands to try after that and at some point you might actually need to force things manually...As I switch locations quite often and have some dedicated devices for specific jobs, repairing these issues cost me days in the last years.I've run into the issue several times, but so far it could always be fixed with a quickpacman -S archlinux-keyring
Did you try that?
There were also updates where arch had already partly updated and then failed on some critical package because of an outdated keyring, but I think that has been fixed in pacman for a while now.
I also still have some machines with manjaro in play that I haven't bothered switching, yet and there you have to bother with multiple keyrings.
Last edited by const on 3 Oct 2024 at 10:26 pm UTC
pleasereadthemanual 4 Oct 2024
Desktop. I mainly used Rustdesk + TeamViewer + AnyDesk, for redundancy in case of connectivity weirdness. Last I tested, unattended access is wonky on KDE and unattended login doesn't work on Wayland at all.Oh, well, you're probably screwed for unattended login on anything except GNOME when it comes to Wayland. There's wayvnc for Sway but there's no real unattended login for that.
I can say GNOME RDP works very well for servers on Wayland.
Patreon
PayPal
How to set, change and reset your SteamOS / Steam Deck desktop sudo password
How to set up Decky Loader on Steam Deck / SteamOS for easy plugins
See more from me