To have this laundry list of negatives get a reply basically saying “yeah, it’s bad, but we need to impress the stakeholders by forcing a Wayland default even if it doesn’t work correctly” is baffling.

I use SDL so this hits a bit closer to home. Hopefully they can arrive at a conclusion that isn’t harmful to us devs. It’s already kind of a tossup whether it’s even worth it to provide a native Linux build when Proton works so well anyway. I can’t imagine this will help.

What kernel version are you seeing that lockup bug on? I have a similar bug on Ryzen 5 2600x with kernel versions >= 6.7. 6.6 is fine.

More directly: Buy used. Lots of reputable sellers on eBay and their returns policy for defective products is unbeatable.

Check out Normcap.

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.

That’s an interesting idea. I’ll have to look into whether it’s a viable option first, though.

This will be my last resort mostly because I’m fairly certain it’s a kernel issue, but yes, I’ve never ran an extended memtest on this build and should probably let it run overnight at some point just to make sure.

This was a solved problem on other sites via wikis and weekly threads. There’s no value in another “what distro should I use?” post. It’s great that people want to contribute, but there should be a more centralized resource we can refer people to where people can focus this energy.

As for the Windows threads, they’ve been a staple of every Linux-focused community for as long as I’ve been browsing them. I guess if it makes people feel better then I suppose that’s enough of a reason to keep them around.

I recommend an RX 580. Older card, but better than the 1060 and 8GB instead of 6GB. Good for 1080p gaming at 60fps and can be workable up to 1440 if you lower settings. Used price is around $60 - $90 USD (down from $110 when I bought it earlier this year used on eBay.) Only thing to look out for is the bios switch, which downclocks memory if in the wrong position. I drive 3 displays with it and used to do 4 with no issue on Wayland. Highly recommended for a budget card.

Switched from BORE to EEVDF (which is now the stock scheduler after 6.6 IIRC.) EEVDF works better under load.

Wayland has mostly positive user reviews because it presents nicely to the user (VRR, scaling, etc.) On the developer front it seems there’s a lot of struggle over things that were solved in X11 but for some reason require a lot of debate in Wayland.

• There’s still no way to universally configure monitors and input devices, so the startup cost to checking out a new “WM” (compositor in Wayland terms) is non-zero - you have to reconfigure everything from the ground up, and for anyone with complex input systems (see: accessibility devices) this will take a lot of time because each compositor insists on using a different format for configuring these things.
• Each compositor is tasked with coming up with solutions for all parts of the user experience (hence the last point) and thus anyone who wants to experiment with making their own WM now has to worry about a billion things that wouldn’t have had to deal with in X11. Yeah, there’s libraries for dealing with that stuff, but it’s not as simple as it was and lot of innovative WMs won’t ever be able to make the jump.

These are the two biggest issues I can see that are entirely chalked up to its design. Technical issues (like the “load balancer” thing that keeps Firefox from crashing on Wayland) will be solved in time. However, the above points are unlikely to ever be addressed. Should they be? I don’t know.

This looks cool.

What is it?

edit: About an hour later of clicking around and watching videos. Whatever it is, it’s a treasure trove of interesting/innovative programs and utilities built around some kind of experimental display server. At times it’s like watching Hollywood’s interpretation of a future operating system. Much of it is beyond comprehension. Whoever is working on this clearly has a vision and I applaud them for it.

Every major update has broken something or fundamentally changed my workflow to such a degree that I no longer feel I understand the program. I currently use it in a semi-automated setup and I’ll likely have my package manager ignore its upgrades in the future barring total breakage of the package. Note: I’m not saying the program is bad, it’s just not something I’m interested in constantly tweaking/relearning if a future update is just going to break it.

I just learned about Ansel, which is a fork by someone who did a ton of work for DT but was ultimately too opinionated and got the boot. Apparently it’s way more streamlined and easier to work with. YMMV.

I’ve also heard about vkdt, which is very early, but still something to look at.

Nvtop is really solid. I like that it can show hardware encode/decode percentages too.

Horribly offensive term. Webster’s Dictionary defines ricing as a tiling window manger with 64px gaps, minimalist Naruto/anime background, useless bouncing bar EQ meter, entire window dedicated to song lyrics, obnoxious monospace fonts, nonsensical colors, task bar showing time/date/IP+MAC address/GPS coords/moon phase/crop yield/barometric pressure, and a Vim buffer with Rust’s “hello world” tutorial.

It’s good! I don’t think I felt any jump in performance from X/i3 -> Sway, though, but have definitely seen people reporting that.

It’s taken a while to get everything set up how I like but multiple games behave well here and not on X

In my experience most games still run under XWayland. It’s possible some aspect of your X11/herbstluftwm config was causing your issues in that regard.