Unfortunately this is an ideological hill that many Linux devs are willing to die on, so we're at an impasse. Valve claimed to be working on a solution, and if there is any company which can negotiate an accord, it's them.
But why? They're just video games. Why are they important, especially when a lot of them are designed to be addictive.
A lot of people love smoking but that's not important either and it's better to give it up.
When your grandkids ask you what you did with your finite time, is "I pwned noobs" the answer you want to give?
Sure, let me just quickly hop on a plane to australia to meet with some. I assume youre paying?
> When your grandkids ask you what you did with your finite time, is "I pwned noobs" the answer you want to give?
Yes? What kind of question is that? Youre just gonna start talking about the value you created for shareholders or your business?
The question is what value are video games. The answer seems to be "not much".
They look much more like addictive distractions than anything valuable.
Feel free to list out all of your hobbies and what you do in your free time and we will all critique it for you.
Ultimately, everyone spends their time on what they enjoy; there's no award when you die for doing more x than y while you were alive.
I enjoy playing games, gardening, and riding motorcycles. My cousin enjoys socializing at bars, playing games, and doing woodwork.
Is one of our hobby sets more legitimate than the other's?
How are video games a hobby? Is playing slot machines also a hobby?
What's the difference between video games and slot machines? They look real similar to me.
As others have said, why don't you list out your hobbies (as I did mine), so we can understand exactly what recreational activities you think constitute "valid" hobbies? That will also make it easier for me to explain the difference between video games and slot machines to you.
[1] https://store.steampowered.com/app/716490/EXAPUNKS/
[2] https://store.steampowered.com/app/1989270/Slay_the_Princess...
Video games don't even appear to be productive of good discussion.
Why are you trying so hard to "prove" that someone's hobby is a waste of time?
That's the question. What is the reason?
People also play slot machines. Are slot machines fulfilling?
You are being ridiculous. First, unless the person was a professional gamer they would probably answer with the time they spend at work and time time they spend raising their family. But let's assume the grandkids specifically asked what they did for entertainment.
The answer would then be something like "I got together with my friends and we played the popular online games together". They would probably also mention any other things they did a lot of entertainment, too.
I don't want kernel level anti-cheat, though. All the games with it have cheaters anyway.
I've watched people play slot machines. They sit there and pump money into the machine for no real benefit to themselves. Why are video games any different to that?
People who enjoy reading get the same dopamine reaction from that as people who enjoy video games. Or slot machines.
The difference with slot machines is that the purpose of them is solely to tie that dopamine release to giving away money predicated on deception (specifically, both by not disclosing actual odds, and by lying about them).
A slot game that requires no money to play isn't a problem, because it's not tricking old people into giving away their pensions.
So just like loot boxes in video games.
> A slot game that requires no money to play isn't a problem
So similarly you should only be playing opensource and freeware video games that aren't designed to extract money from you.
> So similarly you should only be playing opensource and freeware video games that aren't designed to extract money from you.
"Paying to purchase a game", and "paying to wager money on or in a game" are 2 different things.
I'd also have no issue with someone buying an actual slot machine to sit in their house, so they put in money but also keep the money they put in. But people don't do that because they're not playing for the gameplay, they're playing for the gamble.
True story: I know a woman who built a relationship with her tween nephew on the other side of the world mainly by playing Fortnite with him ever week for two years - all for free because she never bought a skin.
It does not affect "multiplayer" in general, to the contrary, most multiplayer games are not affected (coop games, MMOs, RTS).
| It's nearly impossible to play multiplayer games now without KLAC. The cheating is out of control.
Ofc, cheating is also present with KLAC, its just the next level of the cat and mouse game (Driver exploits, DMA access via PCIe, Network Packet analysis, ...) | Unfortunately this is an ideological hill that many Linux devs are willing to die on
Nonsense. 1. Almost no anticheat is implemented on Linux in the first place. Most "working" anti-cheat solutions for Linux are just a #if Linux doNothing(); #else ... 2. KLAC requires SecureBoot/ChainOfTrust + closed source code running with highest privileges. This does not make sense for any PC, but I dont see why it would be harder to do on Linux than on Windows, Linux just has a smaller install base in general and a lower acceptance rate for KLAC, therefore its not worth it to implement.> I want to clarify to anyone reading this that this only effects high-competitive games, like LoL, Valorant, PUBG, R6S; and not all of them (e.g. Counter Strike).
It affected a game I really care about: Arc Raiders. That's not a "high-competitive" game. It's PvPvE, shooting at funny robots and scavenging rubber duckies. Cheating killed the game. [It's down to 6% of its peak.](https://steamcharts.com/app/1808500#All) Just because this hasn't affected the games you love doesn't mean it's not affecting many games. See Titanfall, H1Z1, and The Cycle: Frontier, among many more.
> It does not affect "multiplayer" in general, to the contrary, most multiplayer games are not affected (coop games, MMOs, RTS).
I was going to ask you to back that up, but I realise I made a broad claim and can also not back it up, so we're just giving each other our opinions, I suppose.
> Ofc, cheating is also present with KLAC, its just the next level of the cat and mouse game (Driver exploits, DMA access via PCIe, Network Packet analysis, ...)
Indeed. The goal is to reduce cheating to a manageable level. It is impossible to eliminate.
> Nonsense. 1. Almost no anticheat is implemented on Linux in the first place. Most "working" anti-cheat solutions for Linux are just a #if Linux doNothing(); #else ... 2. KLAC requires SecureBoot/ChainOfTrust + closed source code running with highest privileges. This does not make sense for any PC, but I dont see why it would be harder to do on Linux than on Windows, Linux just has a smaller install base in general and a lower acceptance rate for KLAC, therefore its not worth it to implement.
Linux does not properly support KLAC because its architecture and development philosophy work against it. For example, Valve explicitly recommends user-space anti-cheat for Proton and says kernel-space anti-cheat is “not currently supported and is not recommended”.
The Linux kernel also deliberately does not provide a stable binary kernel-driver interface. Kernel maintainer Greg Kroah-Hartman has said that Linux has neither a stable in-kernel API nor a stable binary kernel interface, because maintainers want the freedom to change kernel internals rather than permanently support proprietary out-of-tree drivers.
Riot is on the record as explaining that Linux does not give Vanguard sufficient ability to attest boot state and kernel modules. They also claim that distribution differences make enforcement harder, and that cheats can potentially operate outside an emulated environment where the anti-cheat cannot see them. Riot is on the record saying that anti-cheat is “extremely hard on Linux by design”.
So you're technically correct, but I think you misunderstand a lot of the architecture which underpins this issue, and the ideological boundaries which many developers prefer to enforce around security, FOSS, and ownership.
| I would like to respond because you're speaking authoritatively but this is mostly your opinion.
Sorry, I felt inclined to respond to your broad claim "It's nearly impossible to play multiplayer games now without KLAC".
XKCD 'Wait, Honey, sb. is wrong on the internet', we both know it. | Indeed. The goal is to reduce cheating to a manageable level. It is impossible to eliminate.
I agree with the goal, but KLAC is not an acceptable way to get there. I would rather suggest to: - dont trust the client
- really dont trust the client
- support / let customers host the servers (they are the ones who will put in the time required to deal with cheaters, and they will also be there once the devs/publisher have abandoned a game)
- Use statistics a lot more: mark outliers for review, and until review, aggressively move them to their own matchmaking bracket.
- Implement a "demo"-style replay format for matches/sessions (which therefore contains all inputs of all parties). Make all "ranked" or eq. matches publicly available (no names/chat, just the gameplay) and people will develop tools in their free time to detect cheaters.
Also: Have a simple trust score (Account age * Money spent), and act more aggressive on people with low trust score.
Let new people improve their trust score by reserving ~$100 on a credit card which will be billed if the account gets banned for cheating.To be clear, I welcome the attempt, but I think it just results in the same cat and mouse arms race we've seen for 20 years. Inference has been beaten time and time again. Until it is proven to work I will stick with the best options we have right now.
ImO, the goal is to find the statistic cheaters will skew since they are cheating.
Lets say, one is wall-hacking in Counter-Strike. In Counter-Strike, many maps have a central location/lane called "mid". There is often a kind of mind-game of limited information going on:
- Does 0, 1, or both teams have an AWP(=one-shot kill sniper)
- Is the enemy sniper guarding mid?
- Which entrance to mid is the enemy sniper currently watching?
- Has the enemy sniper guarded mid in the beginning, but has now left?
Any wall-hacker will be a major outlier regarding not running into mid while the enemy sniper is watching.If you can accurately dissect/classify/log player behavior, I expect the statistics to look similar to those of poker players who cheat and know the cards of the other players on the table: https://media.pokertube.com/uploads/2025/12/5d96fe17d39043a0...
It's fair to argue I have no evidence of the cause of decline. I cite my frequent interactions with hundreds of players in the community, and streamers like Burnt Peanut. However this is qualitative, not quantitative. Me and my friends stopped playing because of the cheating, and so did every other one of my friends who picked it up. It wasn't that we wanted to stop playing the game. It was the cheating.
But I don't know since I don't play Arc. I'm just aware of a number of other games rife with cheating that remain wildly popular.
There are hardware cheats that are not detectable by KLAC, so it doesn't solve the problem, just improves the situation.
The only way to avoid cheaters is to play with people you trust.
Play single player games, then you can complain about cheating AI opponents.
If you're not willing to stop using harmful software that's your problem.
And let's not forget that cheating in online games is only an issue because companies have co-opted what was a social activity between people you know (or at least can get to know) into a more profitable asocial e-peen measuring contest between randoms.
I think equating having the option of KLAC with Windows is totally disingenuous. There are countless other differentiators. You would be free to just not use KLAC if you so desired.
I don't know if enabling KLAC in Linux can happen without opening nasty doors for other software. If it existed, perhaps one could have different kernels to boot into: One for the invasive software that one boots into for gaming and a secure kernel for normal work, perhaps even with different userspaces.
I will 100% give Linux evangelists the guff they deserve on shitty UX in GUIs and their insistence upon a dozen slightly-tweaked solutions to the same core problem that prevents the industry from consolidating into widescale popularity on endpoints, but the incompetence and/or laziness of major devs to support even something like Debian is not a failing of Linux.
However, KVM does not solve the problem. In fact, Riot explicitly explains why virtualisation can make the problem worse: if Vanguard runs inside a guest, a cheat can run on the host and manipulate the VM in ways the anti-cheat cannot see. Riot says Linux currently does not give it sufficient ability to attest the boot state or kernel modules, with distro differences making the problem harder.
Linux also deliberately does not provide a stable in-kernel ABI for proprietary out-of-tree drivers. The kernel documentation explicitly says there is neither a stable binary kernel interface nor a stable internal kernel interface. The preferred model is for drivers to be upstreamed and maintained with the kernel, which is almost the opposite of how closed-source kernel anti-cheat is normally deployed.
And this isn't just Riot. EA actually supported EAC through Proton for Apex and then removed Linux access because its anti-cheat team said Linux was being used for impactful cheats, that Linux cheats were harder to detect, and that they couldn't reliably distinguish a legitimate Steam Deck from a malicious Linux client pretending to be one.
Valve itself tells developers that Proton's recommended solution is user-space anti-cheat and that kernel-space anti-cheat is “not currently supported and is not recommended”.
So I guess it's technically possible for a game dev to effectively create their own Linux distro, but I hope we agree that's never going to happen. They're game devs, not Linux devs. Anti-cheat needs a trust chain that the hostile user cannot control and not just an API through which it can inspect the system. Linux deliberately gives the machine owner far more control over the kernel and environment, which is exactly what makes strong client-side attestation difficult.
FYI bhyve isn't a Linux hypervisor. It's part of FreeBSD.
Why would a game developer have the power to approve what I boot on my hardware?
Especially a peddler of live service free to play.
kernel level invasive garbage would be beyond destructive and still not solve the problem
Ideally you would be free to not play KLAC games, and I would be free to play KLAC games. I just hope for the option one day, as I would very much like to make the move to Linux.
If you choose to play Windows-only games because you think that is protecting you from some nebulous group of cheaters who moved to Linux to aid their cheating, I think you don't know the cheat landscape well.
Cheat makers primarily operate on Windows, not because it's easier, but because that's what most players still use. This idea that you're going to avoid cheaters by staying on Windows is honestly the opposite of true. MP games with Linux clients are not the games with massive cheating problems.
For me, it is no problem at all since the games I play have no issues. That includes the multiplayer games I play.
This is no longer the reason, as FLOSS implementation exists now: https://arxiv.org/abs/2609.20909
If you are fine with that, fine.
If this post bothers you and you feel the need to defend yourself against it or something, realize I'm not the one making it true. Nothing you say to me can change this.
To be honest I don’t really understand the hysteria re KLAC. Installing something in kernel space requires trust, but so does installing something in user space. If you don’t trust the developer, don’t use their software. A malicious app installed in user space can steal, encrypt, delete or exfiltrate anything the user can access. It can abuse their applications, credentials and resources. Kernel access is worse, but both are very bad.
I certainly would not feel I owned my system if I accepted the full suite of attempts by these companies to replace and subvert existing standards. I do feel I have control with non-systemd init and service management, and source based packaging.
And the wifi is easily fixable either buying a non expensive dongle or waiting for the next release.
Also running bhyve as daily driver with Ubuntu for development purposes. Everything works without issues, perfectly.
If you meant the lastest of the latest GPU, processor, chipset and so you you might better off with Linux.
But the fact that the computer that was given to me was boxed from factory and bought after two weeks after started is a sign of recent hardware. I haven't tried it but two other person where I work have high end brand new ThinkPads and I'm confident FreeBSD can be run on those well too.
| Ryzen 7 and an AMD GPU
Ryzen 7 is a 9 year old, AMD GPU a 20 year old generic term.
If Notebookcheck is correct, the "Lenovo ThinkBook 16 G7 ARP" comes with a Zen3(+) CPU and a RDNA 2 GPU, both released 6 years ago.If Zen3+ vs Zen3 is a significant architectural difference, than it would slightly miss the 5 year mark, since it was released 4.5 years ago.
The laptop mentioned is fine. But it is hardware that is just at that mark where I'd normally replace it.
As I said, I think it's still OK if my goal is to run FreeBSD. But if my goal is to get the best hardware now that will last me the next 3-5 years then it's dated and I'll have to compromise just to be able to use FreeBSD with it. I don't have to do that with Linux.
I think if I am going to compromise on hardware because I want a particular OS on it, it'll probably be Haiku over one of the BSDs because I don't get the sense BSD offers enough of a difference vs Linux to justify that compromise.
Maybe with the rise of immutable distributions like SteamOS, Bazzite, GnomeOS and KDELinux.
But the other "user-friendly" distributions are just not good enough for a non-techy.
We need better and more A/B partitioned immutable distributions and we need a new implementation of Flatpak.
I recently had to repair my parents their Linux Mint installation because it powered off during an upgrade. Apt does not handle that well, Linux Mint has no snapshotting, you cannot apt autoconfigure -a through the UI. Also the UI does not explain why the machine is getting hot while it's building dkms modules for an hour.
Just this week I saw someone with Fedora get a buggy graphics driver that made the whole system glitchy, they had to downgrade the kernel.
The week before I had to repair a manjaro installation from a friend because getting nvidia to work on ArchLinux isn't trivial even if Manjaro pretends it to be.
To be frank, desktop linux is still in a pretty bad state.
I'd also rgue Mint is easier to navigate than Windows with it's 3+ different context menus and baked in ads.
Desktop computing is just in a bad state.
And I agree, Linux Mints DE (Cinnamon) is very user-friendly!
My gut is we'll have to start learning BSD soon.
That's the problem with BSD, the community holds a large amount of radical ideologies that led them to BSD. Like a deep hatred for systemd or the GPL.
Not the core developers though, just the community surrounding them.
However in the context of the constant restrictions of general purpose computing, GPL has my back. BSD at best doesn't care about restrictive forks and at worst even welcomes them as 'good business'.
Two different approaches, they both have their place but as a user, I feel GPL was written for me. BSD (license) was written for the developer.
> I find the GPL to be hypocritical in the way it restricts freedom while talking about promoting freedom. If I'm giving a gift to the commons, then I want it to be a true gift, not something with strings attached.
The right to free speech is a freedom too, yet it has strings attached. Namely it's no longer a freedom the moment it crosses a certain line into endangering someone else and their freedoms. That's sort of the view the GPL takes, but it gets into how different political philosophies view the concept of freedom. Is it freedom to pay whatever the free market (in practice monopolies) demand for commodities critical to survival (BSD view of freedom) or is it freedom not to have to worry about not being able to afford commodities critical to survival (GPL view of freedom).
I do agree the BSD freedoms is simpler to grasp.
> It hurts nobody if someone chooses to make a closed source fork - software is a non-rivalrous good, so whatever someone else does cannot take away the free version that I have provided
True in theory, trickier in practice. 'It hurts nobody' only goes so far because if a closed source fork starts collecting telemetry then it actively hurts its users, unless very much opt in. Now how many average computer users are going to know that there's an open version that doesn't do that? A small number. Trickier still, because the fork is closed, it's likely going to be quite hard to replace it or block the telemetry, at least without loosing some features. So again, the difference is in what is viewed as the commons. BSD views the commons as everyone, including capital interests best in a position to take that the software and twist it into a tool in the ongoing war on general purpose computing, ability to repair etc. GPL views the commons as the users, so it aims to grants freedoms to them, even at the cost of restricting the freedom of capital in the process.
In short, I do understand and even appreciate the BSD concept of freedom and its simplicity, yet I find it insufficient to protect my freedom in a system full of monopoly power, corruption and exploitation.
In an ideal world where the behaviour the GPL aims to protect doesn't exist, I'd agree the BSD is more free. In the current world, I'd argue that BSD gives freedom to exploit computer users to those with the means to do so.
With that said, also or instead using *BSD won't do any harm.