- cross-posted to:
- technology@lemmy.ml
- cross-posted to:
- technology@lemmy.ml
You must log in or # to comment.
I think this is a higher percentage than Windows 11 if you include 16-bit ones from the 90s and early 2000s. (What was wrong with NTVDM64, anyway?)
Switching to linux had me cold turkey league of legends im a healthier happier person now.
the real cold turkey was Riot killing linux support last year. Seems like there wasn’t enough linux players at the time for them to walk back that decision.
Funniest thing.: the Mac client also doesn’t support Kernel anti cheat, but it still works. Fuck riot, I’m glad I ditched it.
Unfortunately the 10% that don’t include the biggest, most played games in the world.
Like Elden ring and nightreign? Hugely successful games. Play them all the time in Linux.
Hows battlefield 6 going on linux? Fortnite? Black Ops 6? Warzone? PUBG? Apex Legends? GTA 5 / GTA Online?
I don’t play any of those.
My point is, there’s loads of great popular multiplayer games that don’t use garbage kernel level anticheat.
But Elden Ring and Elden Ring Nightreign are not multiplayer games…?
You can also add many more of the top most popular multiplayer games to my list, I just listed a few of the biggest. You won’t be playing GTA6, which is likely to be the biggest game of all time, on Linux. Black Ops 7, the biggest release of this year, won’t be on Linux.
You obviously know nothing about these two games lol. Yes they are multiplayer. Nightreign is also designed to primarily be played 3 players online at a time.
Co-op, duels, and “invasions” lol. Not what we’re talking about here. Elden ring is a single player game for all that any one cares or knows.
We’re definitely not talking about co-op when anyone says multiplayer.
You need to learn the definition of “multi”, then.
This. Plus anti-cheat is still a removed on Linux.
Anticheat works fine. Just not the kernel level nasty ones. But that’s a good thing.
But that’s a good thing.
If you don’t want to be able to play the biggest games released, I guess…
You’re looking at it wrong. They need to not invade our kernel.
For this type of anti-cheat yes, they do.
You can choose not to let them, it just means you can’t play the games. Do you believe they’re installing malicious code or something in the anti-cheat?
Exactly. This is not a type I need. My kernel does not need to be invaded. It’s literally enabling spyware and you’d never know it.
Do I believe it? I don’t know. But it’s possible and I’d never know, so fuck that.
- ESEA Bitcoin miner incident (2013) In April 2013 ESEA (a third-party matchmaking + anti-cheat service) had a built-in bitcoin-miner component in their client. It was discovered by users in May. � XDA Developers +1 Because the ESEA client ran with high privileges (as a driver/anti-cheat style client), the mining component was harder to detect and harder to remove compared to normal user-mode software. � XDA Developers The company settled for a $1 M payout. � Lesson: Granting deep OS access to a client means if it goes rogue (or is malicious) you get real damage (mining, rootkit-like behaviour, etc). XDA Developers
- Riot Vanguard (for VALORANT) and related complaints Vanguard is the kernel-level anti-cheat used by Riot Games in VALORANT. � Wikipedia +1 It has drawn criticism for its always-running behaviour (some users report it loads at boot even before the game). � Gist +1 Some users report system instability (blue screens) after installation. � Lesson: Even if the anti-cheat isn’t malicious per se, because it’s so deep, any defect or compatibility issue can cause system-wide pain (crashes, instability). XDA Developers
- Theoretical/privacy risk: drivers acting like rootkits Academic work (“If It Looks Like a Rootkit…”) analyses KLAC and finds that some solutions behave very similarly to rootkits: intercepting kernel calls, hiding modules, monitoring broad system activity. � arXiv Articles note that allowing game companies to insert drivers at boot time that monitor “outside the game” sets a “potentially dangerous precedent”. � Lesson: Even when everything is “legal”, the architectural model has intrinsic risk: trusted code has extremely high privileges; if trust is misplaced (malicious dev, insider threat, compromise) you have huge exposure. How-To Geek
- Example of “residual services” / bad uninstall behaviour A Steam forum post (for game “Delta Force (2025 video game)”) reported that the anti-cheat driver “ACE-BASE / AntiCheatExpert” remained active even after game uninstall, caused conflicts, etc. � Lesson: When kernel-level drivers aren’t cleanly managed/uninstalled, they can linger as “shadow” privileged components, increasing risk surface. Steam Community
- Corporate/State concerns & data-privacy An article points out that KLAC by its nature has full system visibility (“what this means is that this type of spyware can exfiltrate sensitive information…”) and calls out potential misuse—especially worrying when combined with acquisitions or state-influence (e.g., the purchase of a KLAC-provider by a sovereign entity). � Lesson: Beyond just “can it crash my PC”, there’s question of what else the driver could observe (system activity, other processes, telemetry) and whether user has meaningful control.
That’s a lot of “it possibly could, but it never has happened with huge reputable billion dollar companies”. Also seems like an AI generated list, or copied from Wikipedia? If that’s the best you can find, yeah there’s no issue.
No one should be giving some random anti-cheat program made by who knows who kennel level access, but one by EA? Fine. EA aren’t in the business of getting bankrupted by installing rootkit malware with their video game anti-cheat.
Calling anti-cheat “spyware” is dumb.
Good, but native would be better. At least they can’t kill Linux the way they did os/2
Ummmm sure?
I don’t want to start that extremely old flame war of native VS jit code but…
Proton is not an emulation, it is a translation to native code, and while it has some drawbacks (more memory usage, more time at start up to compile things) it can unlocks a lot of potential when the hw support new capabilities, this is the reason that some dx10 games run faster on Linux…
I might be wrong, but I don’t think proton is either? It’s running x86 instructions either way, wine just provides a way to load it from the windows executable and library formats, and together with proton they provide implementations of windows libraries for those executables to use.
As far as I know for the new Vulkans layers and dx12 implementation there is a “translation layer” from the old dx implementation to the most updated one. This is the main reason why old games runs faster on Proton than in w7 for the same hw. Even if they were designed for w7 specifically.
Last time I checked this was done during the booting of the game, but i have to admit this was time ago and it could have been changed.
It is a translation layer, but the bit you added “to native code” sounds like you’re misunderstanding what translation layer means.
Games use a collection of APIs (DirectX is a set of APIs, but there’s others to handle offer operations like network access and such) to interact with OS functionality, and also receive communicarion back from the OS (the windows message loop). Proton and wine are implementations of those APIs that translate the API calls to their equivalent in linux, as well as setting up their own message loop that translates messages from the linux kernel and UI system into their windows equivalent before sending them to the registered windows messaging loop functions.
A simple example would be if a function header in windows looks like int32 SomeFuncWin( int64 index, char* name ), but looks like int32 SomeFuncLinux( std::string name, int64 index ), then the translation would be something like:
int32 SomeFuncWin( int64 index, char* name ) {
std:string TranslatedName( name );
return SomeFuncLinux( TranslatedName, index );
}So it doesn’t change/translate any of the code of the program itself, it just provides the environment that behaves exactly like a windows environment by translating the “hey could the OS do this for me?” requests from windows to linux. Note that not all translations are that simple, there might need to be more processing on the values, missing arguments might need to be filled in, irrelevant arguments ignored, sometimes data needs to be translated to another format, etc.
The speed ups can come from improved efficiency in the underlying implementations (which Vulkan has, as I understand even using a translation layer from DX to Vulkan in windows can result in better performance) or having fewer services running in the background.
You are partially right, I was fast and sloppy and I gave the impression all is jitted and it is not the reality.
The part of the translation is fine. However there are parts that are compiled beforehand (shaders for example and I can recall something about arm or other architectures, not sure now). And this is a crucial point of the extra performance, because some parts can be ported to more updated/efficient implementations, not because there are less services in the background.
I guess most of the process is just using a wrapper to translate the call to a Windows library to the equivalent call to a Linux library.
I think most of the work is in the fact that there often isn’t an “equivalent call”, and it can be quite a lot of code to make it work. One funny thing is the whole esync-fsync-ntsync issue, where synchronization is done differently on Linux and on windows, and translating it was a big performance hit, and difficult to do accurately. If I understood correctly, esync, fsync and ntsync were a series of kernel patches implementing additional synchronization code in the kernel, with ntsync actually replicating the windows style.
