Do we have a way yet to tell if something on our system is compromised? There's plenty of end user software built on node, like Gemini CLI and LM Studio.

Punching down??? These people are silicon valley founders.

Does ex not count?

c++20's u8strings took a giant steaming dump on a number of existing projects, to the point that compiler flags had to be introduced to disable the feature just so c++20 would work with existing codebases. Granted that's utf-8 (not the same thing as unicode, as mentioned) but it's there.

And yet, unicode support is still abysmal throughout the standard library. I don't disagree though.

Not to talk about the other side of the holy war too much, but one of the things I appreciate about GNU ELPA is it's treated as part of the Emacs distribution and needs to follow all the rules of Emacs proper as a result.

Have you seen what passes for quality on the random power banks sold by Amazon?

I had what I thought was a pretty good implementation, but I wasn't aware of the cache line bouncing. Looks like I've got some updates to make.

Glad that it helps :)

I've heard in the past that ntsync is a big deal for audio plugins via yabridge as well. Not sure how much that's going to reduce the existing CPU penalty there.

Edit: ignore this silliness, as it sidesteps the real problem. Leaving it here because we shouldn't remove our own stupidity.

It's pretty disappointing that safetensors has existed for multiple years now but people are still distributing pth files. Yes it requires more code to handle the loading and saving of models, but you'd think it would be worth it to avoid situations like this.

safetensors is just as vulnerable to this sort of exploit using a pth file since it's a Python package.

Yeah, fair enough, the problem here is that the credentials were stolen, the fact that the exploit was packaged into a .pth is just an implementation detail.

> Not impossible, it just needs to be implemented at a different layer. The compositor needs to expose some API for global hotkeys.

That's a big problem. When things become an optional extension for a compositor, that means you cannot reliably deploy something that depends on it to Wayland.

At this moment, things in the wild are coupling themselves to libwayland-client and in practice ossifying its ABI as a standard no matter what the wayland orgs say about it.

xdg-shell is an optional extension for a compositor and yet you can reliably deploy things that depend on it. You're barking at the wrong tree.

OK so why wasn't this implemented in the first place? For that matter, why does our reinvented wheel have fundamental limitations?

It's not a core protocol's concern and the fact that it's being successfully implemented proves that there are no fundamental limitations there.

I'm not happy with how the collaboration and planning between various parties involved went over years and I do believe that a lot of these adoption pains are fully self-inflicted, but that has absolutely nothing to do with Wayland's technical design.

You can’t effectively dismiss a critique of something missing from the core protocol by declaring it to not be its concern.

I can, I just did. It's just not a thing that should be there at all, and it's obvious once you take a second to look at what's actually in it and why (spoiler: there's too much in it and not much can be done about it now).

You did not. You dismissed something, but not effectively.

Why should a display manager concern itself with routing keystrokes to every application.

Why should a display manager also have to implement window management? (I know this is a separate complaint, but I still think it's a valid one.)