I don’t believe your analogy holds water. I believe computers are a lot closer to steel than “AI” is, in that they’re both foundational technologies with a very very wide array of proven uses such that the benefits of the development and use of steel/computers far outweigh the associated costs. Weapons/“AI” on the otherhand are both specific, narrower applications of steel/computer technology with a few particular beneficial uses, but those uses pale in comparison to costs of the existence and development these technologies, so much so that both weapons and “AI” should be put on a metaphorical shelf out of reach until we as a global society can grow up to develop and use these technologies in a more responsible and conscientious manner.

As much as I hate “AI” myself, rhetoric like this does more harm to movements resisting “AI” than to help them.

I used KDE for my forays into Wayland.

Bear in mind that each desktop environment has its own implementation of Wayland, meaning each can offer vastly different user experiences

Funny you mention that, as that’s (at least closely related to) one of the things I was alluding to when I mentioned design deficiencies in Wayland. The way I understand it is each individual Wayland compositor is free to create their own protocol for stuff like screenshots, and then the Wayland team will take the parts of those protocols and then combine them into the Wayland protocol for e.g. screenshots, which compositors then go back and replace their protocol with that one. Which sounds great on paper, but it leads to a problem I’ll call Ecosystem Lock-in, I don’t quite like that term, I don’t think its fully accurate, but it’s all I can think of for now. What happens is in order for a screenshot program to work on a given compositor they have to interface with that compositor’s screenshot protocol, and it’s a lot of work to support every compositor under the sun, so most devs just won’t. (Which is fine, great even, I think devs these days try to support too much stuff). But say you don’t like Spectacle (Spektacle? I don’t remember), your options are limited to whatever supports KDE’s screenshot protocol.

Or say you’re just moving from an X11 based DE and giving Wayland a try. In the process of moving over you discover your nifty little scrot based screenshot script no longer works. After some research you discover that scrot is X11 only, and the Wayland equivalent is grim, so you get your scripts converted over but they still don’t work. More research later you learn that grim doesn’t support KDE’s screenshot protocol, and Wayland compositors basically get to do whatever they want in terms of protocol design/implementation. This is what happened to me, and caused me to give up on Wayland.

I’m still using xfce; after running into problems with Wayland the three times I tried it, I decided Wayland isn’t really for me. (In fairness one of those was nvidia being nvidia, but the other two are what I consider design deficiencies in Wayland itself)

Well that explains the strange bug I started encountering in xfce recently. I guess I’ll be spending tomorrow researching DEs, though I’ll probably end up just using TDE or maybe CDE.

EDIT: clarified that the bug is in xfce, not xfwl.

Honestly, same. I initially dismissed Zig due to their insistence on making unused variables an error even in debug builds but if they keep this up I may have to just Get Over It.