Games run faster on SteamOS than Windows 11 - Ars Technica
-
A shame that many multiplayer game developers, like EA and Riot, still consider Linux to be too unsafe to trust with an anti-cheat. I wonder if Valve is working on a proper solution for that - signed kernels and packages a la MacOS, perhaps?
If even Microsoft was/is considering giving custom kernel modules the boot and potentially not allowing them in the future (due to similar but unrelated issues) why should the Linux community embrace proprietary kernel modules from companies who's goal is antithetical to the user, and which are probably horribly insecure and/or rootkits themselves.
-
I'm pretty sure it's mandatory that any Chinese owned company has to have backdoors and provide access to the government. I've read interviews where people talked about running companies in China, and they would talk about how government employees would come and install hardware in all their server rooms, and they couldn't touch any of it or do anything about it.
I don't think it's a coincidence that most kernel anti-cheat are developed/used by companies that are at least partially Chinese owned.
Yeah it is suspicious. Would be interesting if someone tried to decompile them to try and see if they hold any secret or malicious functions. I know that many of them have serious security vulnerabilities as is.
-
This was already covered in a video by Dave2d (Lemmy discussion here), but it's great to see more widespread coverage of how great performance is for SteamOS vs windows.
Some highlights:
wrote on last edited by [email protected]Unfortunately, the story is very different when running an Nvidia GPU. I hope the driver situation improves. I really don't want to use Windows anymore, but the performance difference is just too big. I'm however running Linux on my second (full AMD) system with little to no issues.
-
A shame that many multiplayer game developers, like EA and Riot, still consider Linux to be too unsafe to trust with an anti-cheat. I wonder if Valve is working on a proper solution for that - signed kernels and packages a la MacOS, perhaps?
Signed Kernels are problematic for some users. While the distribution-supplied kernel binaries are fine for most users, there are always those who want to (or need to, due to hardware quirks or bugs) tinker with the kernel compile-time configuration, or the kernel source code itself...
-
Some anti cheat work better than others, and it depends on how much you'd like to play the game that needs it. Plenty of games without.
EAC does not hide its process and you can see it running. If it's not, perhaps it has left files behind, but that's a Windows issue more than EAC's.
The fundamental issue with kernel anticheat is you're giving full control and unlimited monitoring of your computer to a company, and trusting them to not abuse that access. Being able to see some processes it runs isn't any kind of guarantee that those processes aren't doing something undesirable, and doesn't guarantee that there aren't other processes doing things secretly.
EAC should be one of the better ones, but it's still a question of:
- Do you trust Epic Games to act in your best interest?
- Do you trust Epic Games to dispose of your personal info and not sell it or use it? (remember, it's not a question of whether your info is being collected, anticheat programs are intended to gather a lot of info on everything you do on your PC so it can be confirmed if you're cheating. So you are being spied on, it's just a question of whether they delete the data after harvesting it or decide to sell/use the data already on their servers that you consented to giving them when you accepted the game's ToS).
- Do you think that Tencent's partial ownership of Epic impacts either of the above questions?
- Do you think that NSA and other government agencies are going to use the anticheat to spy on your computer, either through legal requirement or through undisclosed backdoors?
-
Unfortunately, the story is very different when running an Nvidia GPU. I hope the driver situation improves. I really don't want to use Windows anymore, but the performance difference is just too big. I'm however running Linux on my second (full AMD) system with little to no issues.
Time will tell, there's progress towards proper open source drivers for Nvidia now, but I don't know how long that will take to catch up.
-
Yeah it is suspicious. Would be interesting if someone tried to decompile them to try and see if they hold any secret or malicious functions. I know that many of them have serious security vulnerabilities as is.
Considering that Vanguard has already been bypassed at least once (see dailydarkweb.net/vanguard-bypa… ), I think somebody must already know if the tool is ultimately malicious or not. Problem is, the somebody that knows has a vested interest in not disclosing any details, being a cheat bypasser and all. -
Lots of other games to play.
Single-player? Absolutely. Multiplayer though? Outside of fighting games, indie games, and anything made by Valve, it's increasingly difficult to find any multiplayer game that works on Linux, and even those that still work can have the multiplayer yanked off down the line like what happened with Apex Legends. -
If even Microsoft was/is considering giving custom kernel modules the boot and potentially not allowing them in the future (due to similar but unrelated issues) why should the Linux community embrace proprietary kernel modules from companies who's goal is antithetical to the user, and which are probably horribly insecure and/or rootkits themselves.
Which is why I prefer the MacOS approach better - instead of relying on the developer adding a hypervisor, Apple uses binary signatures for all the relevant system files which are attested via something similar to Secure Boot, plus an Apple-provided API for runtime attestation, to ensure that the system has not been touched since boot. I suspect that Valve's assistance in making Arch Linux builds reproducible is pointing towards that goal. -
Signed Kernels are problematic for some users. While the distribution-supplied kernel binaries are fine for most users, there are always those who want to (or need to, due to hardware quirks or bugs) tinker with the kernel compile-time configuration, or the kernel source code itself...
I'd settle for that solution anyways, but only as long as users can still mix and match kernels (one for secure boot and games that require anti-cheat, and another for custom hardware)
