I’ll take the L on this one. It’s a combination of the article only using the screenshot of the first view as evidence and me late night posting on Lemmy while falling asleep via NyQuil.

It’s because SteamOS identifies itself as Arch. Omitting this information is either dishonest or uninformed.

Anecdotally, more of my techy friends are at least entertaining the thought of switching to Linux when they never did before. Great job, Microsoft!

The cheat in this case would send legitimate actions. Like maybe you, the human, would have missed the headshot, but your cheat corrected to the inputs that would have landed one.

It’s also got great VOIP functionality. And it’s been a hot minute since I’ve used IRC, but you can automate tons of things in Discord around things like user roles. I play an old fighting game that has no ranked system, and all of that functionality, including running weekly tournaments, is handled by a Discord bot that runs on a Raspberri Pi.

Based on their web page, I think what you’re paying for is not having to learn how to configure this stuff.

I haven’t had any problems here. From what I can tell, it just hands all the input and display off to your configured emulator of choice once you make the selection, so once you boot the game, it’s however you’ve got that emulator configured.

This is not just a Lemmy problem, as the same thing exists in Reddit, too, but crowd-sourced news sites like these are so problematic at their core that it got me to buy a news subscription to NYT. No, it is not news that JD Vance told his kid to “shut the hell up”.

I’m no fan of kernel level anti cheat either, but that “capable” anti cheat still sucks. At this point, I’m convinced that good anti cheat is actually impossible, so you may as well just not put it in the kernel. There are so many ways to cheat that an anti cheat will never detect.

The cloud save support is a beta feature. When I tried it with Alone in the Dark earlier this year, it didn’t work.

I can give it a try. LTS is from the Linux Foundation then, rather than Canonical?

24.04 is an LTS distro release. Is my kernel not the LTS kernel? It’s 6.8.0-39-generic, according to neofetch.

Thanks, I’ll give it a try, probably over the weekend with Nobara.

EDIT: In case anyone finds this later, I just tested this with Nobara 40 and had a similar result. Nobara was on kernel 6.10 compared to my 6.8. The game ran fine from beginning to end on SteamOS with a custom kernel branched off of 6.1.52. I’m still operating under the assumption that this is a mesa bug. I don’t have another machine to test this with and rule out hardware issues, but this is the information I collected, and besides, it’s the only game exhibiting problems for me at this point in time.

EDIT to that EDIT: The New Order didn’t run perfectly from beginning to end, I just remembered. It crashed back to the SteamOS menu once and hard froze much like my desktop once, but even that freeze was gracefully caught well enough that I could still use the Steam menu to force quit the program, unlike my experience on desktop.

I understand the nature of troubleshooting, but I don’t think testing a 45 GB game is feasible off of a live distro, and any way to test it on my hardware outside of logs is a whole lot of work to get one game working; I don’t have a spare drive around either. I just figured these errors would mean something to someone who could take action on it to make a better Proton for everyone. I haven’t checked the kernel yet, but my version of mesa matches the latest stable version in your link.

EDIT: I did find this link that sounds like it’s a mesa bug. I’m on the same major version but a different minor version.

I’m not in a position to test on more than just these two machines/distros. Once upon a time, I tried switching to Fedora, but some of the behaviors were not to my liking, so I went back to Kubuntu.

Thanks. I’ll give it a go. I don’t think I’m convinced it’s a hardware issue, since that error says something about permissions and faulty IDs, but what do I know? Couldn’t hurt to check.

I could give it a shot. Will it test VRAM too? Last I ran memtest was years ago. It needs a boot device like a USB, right?

To be fair, I can’t find evidence of anyone on the internet experiencing this same freeze, so it’s probably more specific to me than AMD in general. When I saw freezes like this in Monster Hunter, years ago, I was on Nvidia.

Alright, from journalctl, I can for sure identify exactly where my computer hung. That last line that repeats itself? It repeats itself thousands of times until I shut the machine down. Does that mean anything to you?

Aug 03 12:58:26 Compy-5600X steam[4057]: 08/03 12:58:26 minidumps folder is set to /tmp/dumps
Aug 03 12:58:26 Compy-5600X steam[4057]: 08/03 12:58:26 Init: Installing breakpad exception handler for appid(gameoverlayui)/version(20240716232148)/tid(1798223)
Aug 03 12:58:26 Compy-5600X steam[4057]: 08/03 12:58:26 Init: Installing breakpad exception handler for appid(gameoverlayui)/version(1.0)/tid(1798223)
Aug 03 12:58:36 Compy-5600X kernel: input: Microsoft X-Box 360 pad 0 as /devices/virtual/input/input105
Aug 03 13:00:04 Compy-5600X systemd[1]: Starting sysstat-collect.service - system activity accounting tool...
Aug 03 13:00:04 Compy-5600X systemd[1]: sysstat-collect.service: Deactivated successfully.
Aug 03 13:00:04 Compy-5600X systemd[1]: Finished sysstat-collect.service - system activity accounting tool.
Aug 03 13:00:33 Compy-5600X kernel: amdgpu 0000:0a:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:4 pasid:32798, for process WolfNewOrder_x6 pid 1798131 thread WolfNewOrd:cs0 pid 1798172)
Aug 03 13:00:33 Compy-5600X kernel: amdgpu 0000:0a:00.0: amdgpu:   in page starting at address 0x0000e8674353a000 from client 0x1b (UTCL2)
Aug 03 13:00:33 Compy-5600X kernel: amdgpu 0000:0a:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00401430
Aug 03 13:00:33 Compy-5600X kernel: amdgpu 0000:0a:00.0: amdgpu:          Faulty UTCL2 client ID: SQC (data) (0xa)
Aug 03 13:00:33 Compy-5600X kernel: amdgpu 0000:0a:00.0: amdgpu:          MORE_FAULTS: 0x0
Aug 03 13:00:33 Compy-5600X kernel: amdgpu 0000:0a:00.0: amdgpu:          WALKER_ERROR: 0x0
Aug 03 13:00:33 Compy-5600X kernel: amdgpu 0000:0a:00.0: amdgpu:          PERMISSION_FAULTS: 0x3
Aug 03 13:00:33 Compy-5600X kernel: amdgpu 0000:0a:00.0: amdgpu:          MAPPING_ERROR: 0x0
Aug 03 13:00:33 Compy-5600X kernel: amdgpu 0000:0a:00.0: amdgpu:          RW: 0x0
Aug 03 13:00:43 Compy-5600X kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 timeout, signaled seq=815617255, emitted seq=815617257
Aug 03 13:00:43 Compy-5600X kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process WolfNewOrder_x6 pid 1798131 thread WolfNewOrd:cs0 pid 1798172
Aug 03 13:00:43 Compy-5600X kernel: amdgpu 0000:0a:00.0: amdgpu: GPU reset begin!
Aug 03 13:00:44 Compy-5600X kernel: amdgpu 0000:0a:00.0: amdgpu: MODE1 reset
Aug 03 13:00:44 Compy-5600X kernel: amdgpu 0000:0a:00.0: amdgpu: GPU mode1 reset
Aug 03 13:00:44 Compy-5600X kernel: amdgpu 0000:0a:00.0: amdgpu: GPU smu mode1 reset
Aug 03 13:00:44 Compy-5600X kernel: amdgpu 0000:0a:00.0: amdgpu: GPU reset succeeded, trying to resume
Aug 03 13:00:44 Compy-5600X kernel: [drm] PCIE GART of 512M enabled (table at 0x0000008000F00000).
Aug 03 13:00:44 Compy-5600X kernel: [drm] VRAM is lost due to GPU reset!
Aug 03 13:00:44 Compy-5600X kernel: [drm] PSP is resuming...
Aug 03 13:00:44 Compy-5600X kernel: [drm] reserve 0xa00000 from 0x83fd000000 for PSP TMR
Aug 03 13:00:45 Compy-5600X plasmashell[1970]: amdgpu: amdgpu_cs_query_fence_status failed.
Aug 03 13:00:45 Compy-5600X steam[4057]: amdgpu: amdgpu_cs_query_fence_status failed.
Aug 03 13:00:45 Compy-5600X steam[4057]: amdgpu: amdgpu_cs_query_fence_status failed.
Aug 03 13:00:45 Compy-5600X steam[4057]: amdgpu: amdgpu_cs_query_fence_status failed.
Aug 03 13:00:45 Compy-5600X steam[4057]: amdgpu: amdgpu_cs_query_fence_status failed.
Aug 03 13:00:45 Compy-5600X steam[4057]: amdgpu: amdgpu_cs_query_fence_status failed.

I can also get the Proton logs if you still need them, but that will have to come later, since it’s an ordeal to plan for a scenario where my desktop will crash.

Absolutely not correct.

Feel free to price out the build that beats these things by a wide margin.

All of which you can run on an ATX…?

Try carrying around a dozen ATX machines while I carry around a dozen of these. You’ll see why TOs prefer the smaller, lighter machine.

This is not complicated.

It sure isn’t.