Valve (Steam) begin a direct collaboration with Arch Linux

How anti-cheat relates to that?

To really secure system integrity, there needs to be a full validation chain up to the kernel (and potentially beyond). Without that validation, game devs may continue to distrust anticheat tools on Linux. We don't yet know the new API MS announced to integrate in Windows, but it's really certain Linux will not be able to provide an equivalent unless the kernel and core libraries are build and signed by a trusted entity. Wouldn't make much sense to use that APi if the user can use a patched kernel. As SteamOS uses Archs kernel images and libraries, that must be done in Archs build system, hence the speculation this is related.

To be frank, I think we will see a major shift in cheating and anti-cheat in the coming years, it will be a battle of "AIs".

Actually the enclave part in this story implies we're dealing with a deeper than kernel feature.
I think they plan on using [this kind of processor feature.](https://www.intel.com/content/www/us/en/content-details/671205/enclave-signing-tool-for-intel-software-guard-extensions-intel-sgx.html ).
Meaning that kernel verification isn't needed, because it would be firmware based.
Obviously this also means that the processor firmware starts behaving more like an OS, so you might be tempted to replace it with a FOSS variant to which I say look into coreboot/canoeboot/librem devices.

This isn't as crazy as it sounds HWID features such as CPUID have been really effectively in use for anti-cheat and drm, since their introduction.
Technically it can be circumvented with JIT, but in practice it costs way too much performance, leaving only flatout binary modding, which is OS agnostic anyway.


Edit:
The new info posted by Liam negates all the speculation here.
It's not useful for anti-cheat and it doesn't use fancy processor features.


Last edited by LoudTechie on 28 Sep 2024 at 9:13 pm UTC

and the only issue I've had is with GPU accelerated rendering, which seems to be a bit unstable.

This is a gross understatement. In my experience, Steam is literally the only app on Linux that may cause a total desktop freeze (no matter on which DE, X.org or Wayland) after which I can do nothing but hard reboot my PC. The only workaround to it is disabling hardware acceleration in Steam.

Also, how about the fact that Steam context menu contents are 95% of the time unclickable. This is an issue since the big ui redesign update and it still hasn't been fixed after more than a year or two. You have to click sometimes dozens of times until game properties finally opens for example.

Oh, and also how Steam was already slow to launch on Linux and since the big ui update it's even slower. And many more annoyances..

I mean don't get me wrong, I have endless grattitude towards Valve for everything they've put into Linux, but you honestly have to admit that when it comes to the Steam client itself on Linux, it's a POS and the forever unfixed issues with it makes them look lazy.

Steam has an option to remove the fancy animations IIRC, so you can speed it up. Maybe without that you also wouldn't have a problem with GPU acceleration, so even more speed up with it.

If we're being optimistic about that secure signing piece targeting better anti-cheat, I'd suggest that Valve are looking to out-perform Windows in that regard, and turn SteamOS into THE trusted way to prevent cheating on any given game. Make it as trusted as a console, or more so if possible.

^^^^^ THIS! 10000%

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?

and the only issue I've had is with GPU accelerated rendering, which seems to be a bit unstable.

This is a gross understatement. In my experience, Steam is literally the only app on Linux that may cause a total desktop freeze (no matter on which DE, X.org or Wayland) after which I can do nothing but hard reboot my PC. The only workaround to it is disabling hardware acceleration in Steam.

Also, how about the fact that Steam context menu contents are 95% of the time unclickable. This is an issue since the big ui redesign update and it still hasn't been fixed after more than a year or two. You have to click sometimes dozens of times until game properties finally opens for example.

Oh, and also how Steam was already slow to launch on Linux and since the big ui update it's even slower. And many more annoyances..

I mean don't get me wrong, I have endless grattitude towards Valve for everything they've put into Linux, but you honestly have to admit that when it comes to the Steam client itself on Linux, it's a POS and the forever unfixed issues with it makes them look lazy.

I have not encountered a single one of those issues. Maybe it's a problem specific to your system?

and the only issue I've had is with GPU accelerated rendering, which seems to be a bit unstable.

This is a gross understatement. In my experience, Steam is literally the only app on Linux that may cause a total desktop freeze (no matter on which DE, X.org or Wayland) after which I can do nothing but hard reboot my PC. The only workaround to it is disabling hardware acceleration in Steam.

Also, how about the fact that Steam context menu contents are 95% of the time unclickable. This is an issue since the big ui redesign update and it still hasn't been fixed after more than a year or two. You have to click sometimes dozens of times until game properties finally opens for example.

Oh, and also how Steam was already slow to launch on Linux and since the big ui update it's even slower. And many more annoyances..

I mean don't get me wrong, I have endless grattitude towards Valve for everything they've put into Linux, but you honestly have to admit that when it comes to the Steam client itself on Linux, it's a POS and the forever unfixed issues with it makes them look lazy.

this is off-topic but it sounds like either out-dated nvidia drivers or a resource limitation.

Article updated to clarify, nothing to do with any anti-cheat stuff folks.

I have not encountered a single one of those issues. Maybe it's a problem specific to your system?

No, the issues I listed are also experienced by many others. If you're interested, [here](https://github.com/ValveSoftware/steam-for-linux/issues/9273) is the unclickable context menu issue on steam-for-linux Github.


Last edited by user1 on 28 Sep 2024 at 2:27 pm UTC

this is off-topic but it sounds like either out-dated nvidia drivers or a resource limitation.

As you can see in my PC info, I have AMD and I usually don't run any other software along with Steam. It's completely unrelated to which GPU / hardware you have.

If we're being optimistic about that secure signing piece targeting better anti-cheat, I'd suggest that Valve are looking to out-perform Windows in that regard, and turn SteamOS into THE trusted way to prevent cheating on any given game. Make it as trusted as a console, or more so if possible.

^^^^^ THIS! 10000%

We should hope they implement it in a way more distributions then SteamOS will profit.

Article updated to clarify, nothing to do with any anti-cheat stuff folks.

Still a great project. The whole PGP keychain stuff can really byte you if start up an arch based device after a long time and try to update. As I switch locations quite often and have some dedicated devices for specific jobs, repairing these issues cost me days in the last years.

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?

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.

I most certainly have had several issues with the keyring in Arch. Not sure if it's because I can't properly connect to keyservers or some type of DNS issue. As any good corporate-fearing hermit, I am cautious about these news but Valve is pretty graceful with most of its decisions and this seems more like mutual collaboration rather than exploiting an untouched market. I think a more stream-lined distribution for arch might be a good thing for all involved.

Despite a lot of the discussion about the secure signing enclave, I'm just happy that Valve is continuing to make contributions to the Open Source community with this collaboration.

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.

and the only issue I've had is with GPU accelerated rendering, which seems to be a bit unstable.

This is a gross understatement. In my experience, Steam is literally the only app on Linux that may cause a total desktop freeze (no matter on which DE, X.org or Wayland) after which I can do nothing but hard reboot my PC. The only workaround to it is disabling hardware acceleration in Steam.

Also, how about the fact that Steam context menu contents are 95% of the time unclickable. This is an issue since the big ui redesign update and it still hasn't been fixed after more than a year or two. You have to click sometimes dozens of times until game properties finally opens for example.

Oh, and also how Steam was already slow to launch on Linux and since the big ui update it's even slower. And many more annoyances..

I mean don't get me wrong, I have endless grattitude towards Valve for everything they've put into Linux, but you honestly have to admit that when it comes to the Steam client itself on Linux, it's a POS and the forever unfixed issues with it makes them look lazy.

These seem like isolated issues. Like, I've been running Steam on Linux for nearly 7 years now, and haven't once seen any of this, or reports of this, until now. Save for the context menu thing, but I've only seen that reported for custom themes, and it's due to the new JS engine Steam uses being resource hungry. Are you running on hardware that's older than a decade or something? Because that would explain a lot of the things you described. Also, if you have your games installed to the same drive as the OS, and you have Steam configured to precache shaders, that might be why it's so slow to start. It totally chokes the system with high I/O on start when it runs through the shaders, and performs updates. Move your games to a different drive, and this problem usually goes away.

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.

You should edit the desktop shortcut to include a command to log all output to a file on execution, that will help you narrow down the issue.

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 Sep 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 Sep 2024 at 8:37 pm UTC