An anti-DEI fork by a wingnut and a project that isn’t even half way ready to use starting from scratch in a niche language. Neither of which are capable of dealing with the fundamental problem of X, the protocol itself, without becoming something entirely different.

… I’m not holding my breath.

Agreed. I was an early Wayland convert because once upon a time I started writing a WM and taking an interest in X internals… And then my face melted off like I’d opened the Ark of the Covenant.

Things are so much simpler now.

I use KDE Connect remote input on Wayland all the time…

KMag is broken (simply has not been updated, not like it couldn’t work) but you can zoom the entire screen in KDE with super +/- is that not good enough?

Didn’t they straighten out Wayland support? I thought this was a thing of the past as of 555, but I also haven’t run Nvidia myself in years and years.

Wayland is a sports car - modern, tailor made for performance. X is like a '99 Civic that’s had the seatbelts stripped out and the airbags replaced with cameras that let all the other cars on the road see you naked.

It’s fine to prefer X, but the older it gets the more people are going to roll their eyes at you. XWayland is fine for random old stuff, but there is zero reason X should be running your whole display these days.

Inb4 someone mentions network transparency that gimps the rest of the system or some 5000 year old app that needs to sniff events sent to every other program.

I have a giant FLAC collection and I sometimes wish I could use these local players because I used Winamp/XMMS/quod libet back in the day, but I feel like I just can’t give up consistent access from outside the house.

I ran Tauon for a while (and have run a few of the others over the years) but I always end up back at my Airsonic setup. Works in any browser, works in a few different Android apps (Subsonic compatible), less of a pain than mpd.

Maybe it’d be different if I was still sitting in front of my computer virtually all the time, but nowadays phone to Bluetooth speaker/car/Chromecast is like 90% of my listening.

Basically, the executing thread might get interrupted in a window of code where the interrupt flags are wrong. Not looking at the specifics, but this could lead to various things from mostly harmless (e.g. potentially holding a lock for many times longer than expected but eventually releasing it) to program crashing (e.g. if taking an interrupt while handling the fault leaves the data structures in an inconsistent state).

This is likely the first one, since it was missed for so long in a very well exercised piece of code.

Are you running the native version or through Proton? When I played Civ VI the Linux native version performed worse than using Proton, ironically. Either way, maybe try switching?

Since you specified multiplayer I’m guessing it’s not time to load from disk or anything.

For ancient stuff, maybe, but AMD is also active in enabling new stuff in the kernel and userspace. AMD basically invented Vulkan, and have had the best open source driver stack for years at this point.

I love what Valve has done for Linux, but it’s the last mile of track at the end of huge amounts of outside work enabling the hardware to work in the first place.

Linus’ apathy may keep ten different competing security ideas from each being mainlined, but it’s not impossible for them to continue and prove their worth out of tree until some sort of coherent best practices are established.

Meanwhile, actual security issues will continue to be patched as needed and Linux remains the most analyzed and targeted kernel in the world.

Look on my works Sim Mayor and

I agree, but I can envision scenarios where you are integrating into someone else’s workflow/machine and they (or their build system etc.) are expecting a shell script. Python is ubiquitous but sometimes you just want to work like everything else.

Seriously. I want a personal HUD for navigation and reminders that also corrects my vision (like normal glasses), not to become a walking surveillance device / info mine.

Yes. It has basically the same issue that any compatibility layer is going to have. It will either faithfully reproduce X11 so well it will bring all of the nonsense Wayland was meant to do a way with (everything not directly related to displaying graphics, like font and geometry rendering from the '80s, network transparency, insecure event handling) OR it will attempt to get a reasonable subset working for modern X apps and it won’t be compatible with dusty old binaries and X forwarding etc.

Right now it looks like a shim for Xwayland so it’s the first one, but as it matures we’ll see.

I couldn’t find the specific reasoning for this change, but I feel like QEMU is probably just too holistic to be appropriate for this kind of project.

QEMU needs to be able to emulate all the ARM hardware with enough fidelity to boot a naive operating system. For the purposes of running userspace applications almost all of that is not required, you really just need to convert one ABI to the other and translate the instructions. No need to handle firmware, the MMU, interrupts, disks etc.

Yes! It used to be so hit or miss with Wine, but I played WoW in it around the same time and it was crazy that it worked (at least most of the time).

There’s just no reason to do this work. Even if you ignore the fork’s controversial maintainer, and just favor the fact that it’s maintained at all (which is what the proposal’s author is suggesting) just… Why?

X11 is basically over at this point, why throw a last minute wrench into the existing, working Xorg infrastructure?

When we dropped XFree86 back in the day there were license issues, packaging issues and a real alternative didn’t exist - all justifying the effort to switch. None of these are a problem today.

I wouldn’t do a mailing list these days, but as someone who spent the early part of my career interacting with devs that preferred this method, it’s actually pretty ergonomic by a 2005 standard. A message thread aware, text based email client that can turn messages into patches in a keystroke makes it actually pretty comparable to modern code review…

I think it’s hard for younger devs to get this because they’re used to email being stuck in a crappy, unthreaded browser interface or Outlook etc. (which are terrible for mailing lists) and most collaboration taking place in code review and chat platforms like Teams/Slack but for decades before these were feasible, email was the way…