• 0 Posts
  • 11 Comments
Joined 6 months ago
cake
Cake day: June 4th, 2025

help-circle
  • Or perhaps it could be something other than malice?

    This person is putting up with a misbehavior they don’t have to live with. They’re presenting the perception that it’s due to the nature of the operating system.

    My Toyota engine dies when I idle, therefore all Toyotas and fundamentally flawed.

    Flawed logic, no? And yet, when it comes to tech, plenty of folks apply the same type of thought pattern.

    You’re right that one would think the issue is as it seems on the surface. Computers are actually a bit more complicated than that.

    One fail mode of memory is the occasional bit flip silently corrupting data in the background. As time goes on and new data is written to a disk, things can get weirder and weirder over time.

    We don’t know if Windows and Linux are sharing a physical disk (I hope for their sake they aren’t) and we don’t know how old the Linux deployment is, so it’s possible it hasn’t had the opportunity to get progressively messed up enough yet.

    Another key variable is that the Linux environment might not be interacting with every single piece of hardware, or that the structure of those interactions could result in symptoms manifesting differently or not at all.

    I’ve had situations where a MacBook’s keyboard and trackpad were completely functional in Linux and Windows, but absolutely dysfunctional in any MacOS based environment. The fix? Replacement trackpad cable.

    At the end of the day, the situation they’re describing is not common for the OS and indicates something is very wrong.

    There’s plenty to complain about with Windows, but if this were a typical experience people would not be putting up with it.

    A device with those symptoms coming through my shop is statistically likely to be leaving with replaced parts, a component level repair, or at the very least a complete OS and Driver reinstallation after passing extensive diagnostic testing and behavioral isolation.



  • Effectively doing that server-side would substantially increase the bandwidth requirements though.

    If we take wallhacks as an example, that takes place entirely in the local rendering pipeline. In a game like Battlefield or Counter Strike, smoke and foliage are used for tactical purposes.

    Aimbots read player location data sent from the server and send input commands to the OS to automate headshots.

    Preventing local memory from being read and modified outright prevents (well, substantially raises the skill ceiling) for performing these kinds of hacks. I have a hard time envisioning a server-side solution to those.

    security of the client against the owner of the device on which the client runs

    That’s exactly who a cheater is though


  • Way I see it, there’s two ways to address the “cheating” issue in multiplayer online games.

    First, let’s establish that game cheats typically involve using another application to modify the game’s running code while it is loaded in memory.

    Historically, anti-cheat has largely taken a “reactive” approach. Try to detect the hook / modification taking place, ban the player if it is detected. These systems and bans were often circumvented. There are entire games that I stopped playing because the experience was ruined for me - GTA Online and the late stages of Titanfall 2 are standouts in my mind.

    With how the Windows device security landscape has changed In the 2020s (MacOS has had something similar for ages), there’s now the option of taking a “proactive” approach by preventing application memory from being tapped in the first place. These technologies, notably Secure Boot and TPM, help mitigate rootkits and malware that might steal sensitive information from application memory, as well as paving the way for other protection measures like disk encryption.

    And that’s the main part they’re interested in - by ensuring the entire process up through the kernel cannot be tampered with, the anti-cheat is going to be highly effective at pre-empting anyone from attempting the cheat to begin with.

    It really sucks that, in the curent landscape, that means there are a handful of games that I can’t play on my Linux devices. But it also makes sense - Proton runs with many layers beneath it, which would make it trivial to tamper with memory and engage in cheating.

    I’m hopeful that we’ll someday see a solution that opens up the opportunity for the same degree of integrity protection in Linux so that anyone can enjoy any game on the operating system of their choosing.

    Regardless of what others have to say about EA or the franchise (and boy do they have their issues), Battlefield has always been a beloved series for me. I’m having a blast in Battlefield 6 and I have yet to encounter any cheaters. Previous entries in the series would see me hopping to a new server whenever I encountered one or, on some occasions, ending my play session out of frustration. Anecdotally, the cheating felt much more prevalent before.

    I have a lot less time to game than I used to, so that time is sacred to me. While I’d obviously prefer another way, maintaining a Windows system and enabling two BIOS settings (well, leaving them enabled - they’re on by default) has been worth it for me.