Oh, okay.

I’d say around half of the games I play on Linux require some kind of special launch script, specific Wine version, or even different versions of Steam to run properly. It’s nowhere near as simple as people make it out to be.

Hmm, good question. I’d imagine they’re very similar (if not identical.) Don’t know, however. Mine is self-compiled from source, but when I tried Arch’s LTS package it didn’t crash either.

I believe 6.6 is the current LTS version. A similar crash to the one you describe in the OP started happening to me in the 6.7 kernel. If you check my posts, I have a writeup on it.

Try the LTS kernel. Fixed a similar crash for me.

Warframe at 28 is nice. The devs acknowledge Proton and even accept bug reports for those using it. Very cool chart overall.

Unlikely to help, but while you’re experimenting: PROTON_LOG=1 PROTON_LOG_DIR="/tmp/" WINEDEBUG="-all" fixed some extremely annoying hangs during loading screens for me. Probably a 1 in a million chance it helps in your case, but who knows.

RE: Your edit. Votes are public. OP didn’t downvote you. You, however, downvoted OP when they replied to your question. No idea why you’d do that when all they did was answer your question. FWIW I upvoted your comment so it doesn’t get buried, but yeah, people shouldn’t be downvoting posts unless they’re off topic or against the rules IMO. No need to weaponize them.

Tasks.org is great. I use it with a CalDAV server.

https://docs.beehaw.org/docs/important-questions-decisions-and-reflections/beehaw-lemmy-and-a-vision-of-the-fediverse/

Not the person you replied to BTW.

Financially the right move. If what I read was correct, it would take approx. 8 years of steady Patreon income to get to the $2.4M figure anyway.

They must know they fucked up somewhere and decided to go this route rather than get exposed for potential shenanigans. From reading comments in other communities I was surprised to see a lot of people expected this outcome, although nobody was particularly specific about why (maybe someone here can give some insight.) For the record I’ve been on team “Fuck Nintendo” after the Gamecube, but I’d take the fact that other emulators haven’t been targeted as possible hint that Nintendo got wind of something wacky going on. Who knows, maybe they’re next?

His meltdown after he launched Rust on Linux and then found out his mouse wasn’t supported by Ubuntu is one of the all-time greatest tweet threads. The fact that it was a mouse that ultimately sent him into the anti-Linux spiral that resulted in people being able to refund the game regardless of hours played is extremely funny to me.

If you give this guy money then I don’t know what to tell you. He detests Linux users and has said as much while still taking money from them.

I had a rock solid AMD RX 580 up until the release of kernel version 6.7. Now I’m lucky to get a system that can remain up for longer than thirty minutes. Sticking to 6.6 has worked for me and definitely something you should try as well, but it’s worth noting that any amount of time spent on the issue tracker for AMD GPU stuff will reveal tons of issues from 6.6 as well.

I did my first BTRFS setup over the weekend. I followed the Arch wiki to set up what I thought was RAID 1 only to find out nearly a TB of copying later that it was splitting the data between the drives, not mirroring them (only the metadata was in R1.) One command later and I’d converted the filesystem to true RAID 1. I feel like any other system would require a total redo of the entire FS, but BTRFS did it flawlessly.

I’m still confused, however, as it seems RAID 1 only works with two drives from what I’ve read. Is that true? Why?

I’m fresh off ruling out the RAM via memtest. I’ll let it do a longer soak overnight to see if anything fails then, but I’m now on to bisecting the kernel from what I believe is the last release of 6.6 (6.6.13) to hopefully whatever the offending commit is. Been a while since I’ve had to mess around with manually building the kernel without the aid of linux-tkg, but I’m off to learn it anyway. Thanks for the help!

This is what I’ll try next. I do think memory is the problem now that I’ve had a few more hours of research. Kernel 6.7 has issues with elevated RAM usage, so it’s absolutely doing something funky with memory that might be exposing underlying hardware issues. I also realized my stable kernel was a version or two away from 6.6.13 (6.6.10), so I’m running it now to see if the issue was introduced late in the 6.6 release cycle, which would be easier to bisect than 6.7.

Yeah, the qemu idea was brought up earlier in the thread and it’s very interesting. Glad you confirmed you could repro real issues there in the test environment, so it’s at least a little likely I’ll be able to do the same. Makes sense that it would work and is way better than letting the real system crash and burn. My kernel compile time is pretty short so it shouldn’t be too bad to bisect, I’m just not sure how many commits separate my stable kernel from the bugged 6.7. TBH I’m not that familiar with kernel dev., so maybe it’s way simpler than that.

I was afraid of that. Since I’m not the only one, maybe someone else is doing it already. But if it’s still an issue in a few weeks, maybe I’ll take it on as a weekend project. As for the motherboard, I believe the latest version is currently on it (2022 or 2023.)

Fixed the link. Thanks!

I’ve also tried linux-tkg, which I believe rolls in the Zen patches. If it doesn’t, I’ll definitely try it.