Live data from Hacker News

Linux gaming is faster because Windows APIs are becoming Linux kernel features

xda-developers.com

641–650 of 694 posts

Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features

#641
post #632

Earlier quoted context omitted.

Your argument appears to be nihilistic in nature: "don't bother fighting the cheating because it's inevitable." Forgive me, but I won't be giving up that easily. No anti-cheat is perfect, and we're not aiming for perfect. We're aiming for a reduction, and the harder we make cheating, the fewer cheaters there are. If cheating requires special hardware to mimic mouse and keyboard input, that significantly cuts down how…

Comprehension issue. "Quotes" of something not said directly that you are quoting is always bad. Quotes containing a summary that is entirely false are even worse. Don't do that. You can try to deal with cheating as chess.com and others _do_, or you can do something you know will not work. Kernel mods for chess.com would be stupid. Their anti-cheat strategy involves zero windows kernel mods. That is how it will go fo…

Using quotes to intentionally misrepresent someone is of course bad. I feel I accurately represented your position and nothing you have written refutes that. In fact, you double down here by claiming that chess.com's method is a reasonable solution, and vaguely gesture at "something you know will work." Chess.com relies on inference, which is wildly inaccurate, with many false positive and false negatives. There have been many scandals over the years, and you would know that if you had spent a few minutes on Google prior to this comment.

If you disagree with my interpretation of your nihilism, please go ahead and provide a workable solution for significantly suppressing cheating without the use of kernel level anticheats. Right now you're talking about of both sides of your mouth.

Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features

#642
post #632

Earlier quoted context omitted.

Comprehension issue. "Quotes" of something not said directly that you are quoting is always bad. Quotes containing a summary that is entirely false are even worse. Don't do that. You can try to deal with cheating as chess.com and others _do_, or you can do something you know will not work. Kernel mods for chess.com would be stupid. Their anti-cheat strategy involves zero windows kernel mods. That is how it will go fo…

Using quotes to intentionally misrepresent someone is of course bad. I feel I accurately represented your position and nothing you have written refutes that. In fact, you double down here by claiming that chess.com's method is a reasonable solution, and vaguely gesture at "something you know will work." Chess.com relies on inference, which is wildly inaccurate, with many false positive and false negatives. There have…

Your reading has serious issues.

“Something you know will NOT work” Is what is written right on the page. You quote it without the “not” wTH? Kernel mods won’t work much longer if they still work at all. Gotta find something else. What? Let’s see. Won’t be kernel mods.

Doesn’t make much sense to see this level of non comprehension of plain English. There’s no point talking against it what i say makes no difference if you read the opposite. Maybe this is convo with AI? Dunno.

Best.

Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features

#643

Earlier quoted context omitted.

Apple has never really cared about games unless it's on the iPhone or iPad. It's worked out well for them though. Mobile gaming is a $100 billion dollar market, PC gaming and console gaming are each about half that.

Comparing mobile games to PC and console games is like comparing film buffs to someone who only watches the latest summer blockbuster. They are technically the same on some level, but so different that they really shouldn't be considered the same category.

They're more like comparing Movies to TikTok.

Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features

#644
post #611
post #539

Earlier quoted context omitted.

I still don't understand why we aren't using server-side gameplay analysis for cheat detection. You can have some obvious inhuman-level gameplay heuristics for real time kicks/timeouts during matches and post-game analysis by AI to flag for review or outright automatically ban gameplay that deviates from normal high-level players.

Games very much are using server-side statistics analysis for cheat detection. Valve made a presentation about it and Epic has an API for feeding game state data to ML anticheat for aimbot detection (game-specific and in addition to their existing anticheat measures) It’s just that it doesn’t work.

But why doesn't it work?

Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features

#645

Earlier quoted context omitted.

how often we're using the lock matters. No, latency is what matters. And I was pointing out that a voice IPC lock is still "rare" when we use the most appropriate definition of "rare" This isn't really a point with explanation, it's just you saying 'nu uh', even though that was just a single example.

The post you originally responded to was comparing the general idea of locks that can work between processes and ones that can't. And it was criticizing the efficiency of the former, which is a measure of throughput. There's no reason for an upgraded lock to significantly change in latency. That's not what they were worried about when criticizing the idea of using the former lock as the main lock type in a game. Your…

So no, latency is not what matters. And I've explained why I say that in multiple ways,

No you haven't, you keep talking about doing something 100 times, but if you have a lock between processes, getting those processes to wake up and know the unlock happened with low latency is what matters. After the unlock whatever happens is going to be fast anyway, which in IPC is probably going to be copying memory.

What specific function call are you thinking of that would have high overhead but not latency and the latency wouldn't matter?

you originally responded to

I replied to someone saying "how often do you use a shared lock in games" and I said there are obvious uses.

Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features

#646

Earlier quoted context omitted.

The post you originally responded to was comparing the general idea of locks that can work between processes and ones that can't. And it was criticizing the efficiency of the former, which is a measure of throughput. There's no reason for an upgraded lock to significantly change in latency. That's not what they were worried about when criticizing the idea of using the former lock as the main lock type in a game. Your…

So no, latency is not what matters. And I've explained why I say that in multiple ways, No you haven't, you keep talking about doing something 100 times, but if you have a lock between processes, getting those processes to wake up and know the unlock happened with low latency is what matters. After the unlock whatever happens is going to be fast anyway, which in IPC is probably going to be copying memory. What specif…

> No you haven't, you keep talking about doing something 100 times

That has not been part of all my explanations. But just so I can make it as clear as possible I will now explain it again without mentioning how many times it's called anywhere in the rest of my comment:

> if you have a lock between processes, getting those processes to wake up and know the unlock happened with low latency is what matters

Whether it matters depends on what you're benchmarking.

When the alternative to IPC is waking up another thread, your latency should be about the same either way. It's not what they were trying to compare.

The core comparison they wanted to make was about the simplicity of using a single lock type versus the overhead of using an IPC-capable lock everywhere. A better way to phrase their actual question is about how deep those IPC needs go in contrast to their downsides, not just whether there's a single call site somewhere.

> I replied to someone saying "how often do you use a shared lock in games" and I said there are obvious uses.

You gave a perfectly good answer to the half a sentence you quoted, if that half sentence was in a vacuum. But it was not in a vacuum, and your answer was not good for what they were actually asking.

Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features

#647

Earlier quoted context omitted.

Linux is for power users. Windows 10 with Powertoys and WSL for stuff like yt-dlp is a fine stopgap, but you can get the same workflow on Linux with a leaner system. I never installed Windows 11 on any of my PCs, there's no place for it in my work or gaming regimen. If Linux is supposed to keep Windows honest, then some dev at Microsoft must have a Pinocchio nose.

The problem is that Windows power users arrive on Linux and think they know what they're doing, when in reality they don't know up from down. Very basic things like norms about user confirmation and warnings are frequent stumbling blocks.¹ Windows power users expect their habits and instincts to be right and treat the system as broken wherever they aren't. After all, they "know computers"! So when one of them hits a…

Yes. And Linux power users are also terrible at Windows.

All the operating systems are very different but also largely the same. There are a ton of dumb little things you need to learn for each of them. It’s annoying. Most people don’t spend the time and just go back to what they and works.

I don’t think your comment is particularly insightful or interesting. It’s bias way yonder too overwhelming.

Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features

#648

Earlier quoted context omitted.

I gave it a try. Got a steam deck, tries steam os on my desktop. I kept running into issues that took me time to solve. I understand that the only reason it took me time to solve these issues is because I'm new to it and that people who have been gaming on Linux for years already know how to solve them all. But what would happen was is I would sit down to play a game spend maybe an hour or two fixing issues and then…

And I'll try again when I have more time.

Do not let anybody lead you astray. If you want to just game without any bullshit install Bazzite.

Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features

#649

Earlier quoted context omitted.

So no, latency is not what matters. And I've explained why I say that in multiple ways, No you haven't, you keep talking about doing something 100 times, but if you have a lock between processes, getting those processes to wake up and know the unlock happened with low latency is what matters. After the unlock whatever happens is going to be fast anyway, which in IPC is probably going to be copying memory. What specif…

> No you haven't, you keep talking about doing something 100 times That has not been part of all my explanations. But just so I can make it as clear as possible I will now explain it again without mentioning how many times it's called anywhere in the rest of my comment: > if you have a lock between processes, getting those processes to wake up and know the unlock happened with low latency is what matters Whether it m…

You gave a perfectly good answer to the half a sentence you quoted,

Good, because that's what I meant to do, which is why that's what I quoted.

Re: Linux gaming is faster because Windows APIs are becoming Linux kernel features

#650

Earlier quoted context omitted.

> No you haven't, you keep talking about doing something 100 times That has not been part of all my explanations. But just so I can make it as clear as possible I will now explain it again without mentioning how many times it's called anywhere in the rest of my comment: > if you have a lock between processes, getting those processes to wake up and know the unlock happened with low latency is what matters Whether it m…

You gave a perfectly good answer to the half a sentence you quoted, Good, because that's what I meant to do, which is why that's what I quoted.

And so my first comment clarified that you didn't answer the question. But if answering just that half sentence was on purpose, why did you argue with me???
Post reply on HN