!til@lemmy.world

Assuming you literally just mean different versions of the kernel,

I do.

it’s highly unlikely this would help, this issue has persisted over multiple kernels and even after upgrading from fedora 42 to fedora 43.

It could help if you’re experiencing a kernel bug that has not been present forever, or was fixed upstream more recently than the kernels you have tried. If you establish that the problem does not occur when using a much older or newer kernel, it greatly narrows down where a developer would have to look for the bug.

For what it’s worth, I’m not just throwing random ideas out there. I have some experience in this area. ;)

In any case, good luck.

it froze, but I could still hear her over our call, and then it slowly advanced the display over the next couple minutes-

This means the system is not entirely frozen. The kernel is probably still running, but something is interfering with the display or some other subsystem(s). If SysRq key commands (reisub) worked on this system before the freeze, there’s a good chance they will still work after it happens.

as in the mouse was moving very slowly according to how she was moving her mouse when it froze-

I have seen behavior like this caused by a buggy video driver. You might want to experiment with different Nvidia driver versions.

If that doesn’t bear fruit, you might experiment with different kernel versions.

Edit 1: Also consider watching for kernel log messages when the problem happens (sudo dmesg --follow) or noting the time when it happens and then reviewing syslog/journalctl from that time after rebooting.

Edit 2: Also take note of anything that consistently happens shortly before the problem turns up, like the screen going to sleep and waking up. Some devices have trouble with power saving features.

Kernel-level anti-cheat can indeed be bypassed. I don’t know which methods have been packaged up and made easy for just anyone to use, but when there’s a demand, that’s generally just a matter of time.

You might find this interesting:

https://www.youtube.com/watch?v=RwzIq04vd0M

The sideload APK think might have been speculation, or do you have a video with a Valve employee saying so?

Gamers Nexus quoted Valve here:

https://www.youtube.com/watch?v=bWUxObt1efQ&t=1545s

This was in a segment about the Steam Frame, which has an ARM CPU. It’s unclear whether Valve’s quote was referring to that device alone.

A lot of the time it fizzles out or doesn’t stand up to any kind of real scrutiny.

Which times, specifically?

More importantly, it looks like Gamers Nexus (no apostrophe) is crowdfunding the deeper investigation that they want to do.

I’m inclined to think contributing to this journalism would be worthwhile.

Kind of funny: When Wikipedia was new, people often said that you couldn’t trust information on it because anyone could have written it, even if they were unqualified, biased, or deliberately deceptive. I guess that’s still true today, but with the advent of automated misinformation generators, the Wiki almost seems authoritative in comparison.

If you’re implying that I didn’t recognize someone taking a jab at a unix command, then no, not whoosh. I got that. It doesn’t make a clever or funny joke, though, because the command they chose to ridicule is easy, and is the same in other archive tools like 7z and rar.

If you think something else went over my head, then perhaps you could enlighten me by saying what you mean.

tar x is pretty easy, isn’t it? Or tar xf if they need to specify the input file/device.