Valve (Steam) begin a direct collaboration with Arch Linux

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

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

Meanwhile 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

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.

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 September 2024 at 10:23 pm UTC

You're not right but not that wrong either: use a single key to sign all packages is a step to create a way to generate security and consistent images for the console, something related with SBoM, I think.
But my first thought was the same as yours.

It is nice to see Valve involved at every level of the Linux Platform. All of these improvements up and down the stack are so much more effective and optimized. It would be nice to see if Valve can solve the anti-cheat using signatures though as always I trust their intuition. They have been true stewards of the source and companions over the years.

This is so fascinating. Personally just for my own selfish sake, I wish it were a different distro that wasn't rolling (I'm just ready to exit the rolling release rollercoaster), but I completely understand why they're doing this. And it's wonderful! This should do lots of great things for the linux community and gaming.

I no longer use Arch (Arch-based, in my case), but I think it's good to see Valve continue to be good members of the community.

just general Remote Desktop stuff).

Server RDP or desktop RDP? And what issues?

(as a curious person who runs a GNOME-based RDP server)

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.

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.

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.

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.

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 quick pacman -S archlinux-keyring

Did you try that?

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...
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 October 2024 at 10:26 pm UTC

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.