Here's my 2cts as someone who (used to) hate Wayland:
The main reason is frustration. Using Xorg was simple. You install xorg-server (and its million dependencies), a window manager and you're good to go.
Fire up the server, and then run all the software you need. The window manager is just one of them (and is entirely optional).
Wayland is another story though. You don't "install Wayland". It's only a spec. Just like you don't install HTTP to browse the web. You either install Firefox, epiphany or dillo, which all support a different amount of that spec. For example dillo is ultra light but doesn't support javascript.
It's the same with Wayland compositors, except that the spec changes every week (or used to, back in Wayland's early days). And it was so frustrating to come from Xorg where everything works to another system where you couldn't even copy/paste between windows !
Wayland being only a protocol is it's greatest strength and main weakness. It's good because it's extensible and everyone's free to implement whatever extension they need. Unfortunately it went in all directions with everyone coming up with new extension everyday, causing fragmentation when there was barely 3 competitors (kde, gnome and wlroots). As a developer, it's ultra confusing, just like on the web when you used to add support for chrome, mozilla and IE. And requires a lot of effort because the landscape is constantly changing. So if devs are lost, imagine users...
Hopefully nowadays there's some kind of consortium that's voting Wayland extensions, which is a great thing. Things move at a pace that is okayish to keep up with, and most basic expected features are there (copy/paste, screen save/lock, desktop shells, etc...).
This is very good news as I love and use both software a lot.
Reading the original post from rsadowski@, it turns out the motivation behind it all is a pretext to use LLMs. Given the amount of patches submitted, I truly hope this code was thoroughly reviewed and remains (even if machine-generated) secure and at the same quality level as what we're used to with OpenBSD software.
My dear friend, this is (again!) some beautiful art you got there ! This could easily be the artwork for openbsd 7.6 !
If you don't mind me I'd like to mention it on /c/openbsd so your work doesn't go unnoticed? :D
Nope. But I'm eager to know how you can be so confident saying that ?
(FYI the WiFi is served by a hotspot from my phone, which uses a randomized MAC address)
Right now overlays requires elevated privilèges, but ideally it shouldn't. Rewriting the Linux kernel to implement per user namespaces like plan9 does would allow unprivileged actions from any user (just like if any user was sitting in a container, overlayed from the base system).
I know we're not there, and that's not the direction development is going, but this thread is about dreams, right ? 😉
About the XDG specs, they serve a totally different purpose so they're out of the discussion IMO. I'm not advocating against env variables. Just $PATH which is a workaround as I see it, but your mileage may vary.
As for your "issue" with steam, of course this is the best way to solve it. Because of today's OS limitation. My point is that with a better designed namespacing implementation, there would be more elegant solutions to solve it (and would get rid of the need to use LD_LIBRARY_PATH too, or literally any *_PATH env variable)
Here's my 2cts as someone who (used to) hate Wayland:
The main reason is frustration. Using Xorg was simple. You install
xorg-server(and its million dependencies), a window manager and you're good to go. Fire up the server, and then run all the software you need. The window manager is just one of them (and is entirely optional).Wayland is another story though. You don't "install Wayland". It's only a spec. Just like you don't install HTTP to browse the web. You either install Firefox, epiphany or dillo, which all support a different amount of that spec. For example dillo is ultra light but doesn't support javascript. It's the same with Wayland compositors, except that the spec changes every week (or used to, back in Wayland's early days). And it was so frustrating to come from Xorg where everything works to another system where you couldn't even copy/paste between windows !
Wayland being only a protocol is it's greatest strength and main weakness. It's good because it's extensible and everyone's free to implement whatever extension they need. Unfortunately it went in all directions with everyone coming up with new extension everyday, causing fragmentation when there was barely 3 competitors (kde, gnome and wlroots). As a developer, it's ultra confusing, just like on the web when you used to add support for chrome, mozilla and IE. And requires a lot of effort because the landscape is constantly changing. So if devs are lost, imagine users...
Hopefully nowadays there's some kind of consortium that's voting Wayland extensions, which is a great thing. Things move at a pace that is okayish to keep up with, and most basic expected features are there (copy/paste, screen save/lock, desktop shells, etc...).
There is arcan which is its own thing. I'm not aware of any mature application using it for the desktop though.
Otherwise if you assume that every wayland compositor basically endorse the role of a display server, there are plenty of them.
Now that you say it, I may have misinterpreted that :
Thanks for correcting me.
This is very good news as I love and use both software a lot.
Reading the original post from rsadowski@, it turns out the motivation behind it all is a pretext to use LLMs. Given the amount of patches submitted, I truly hope this code was thoroughly reviewed and remains (even if machine-generated) secure and at the same quality level as what we're used to with OpenBSD software.
Did you seriously bring a gun to a sword fight !?
C'est pas illégal de le demander à ton/ta collègue cela dit.
My dear friend, this is (again!) some beautiful art you got there ! This could easily be the artwork for openbsd 7.6 ! If you don't mind me I'd like to mention it on /c/openbsd so your work doesn't go unnoticed? :D
I cannot speak for prahou, but I'm fairly sure we both agree on this:
masterPuffy rocks.We call them crowdstals down there. They used to only target ancients NT kernels but apparently they evolved to infect other environments. Eh, nature.
Nope. But I'm eager to know how you can be so confident saying that ? (FYI the WiFi is served by a hotspot from my phone, which uses a randomized MAC address)
Oh I love this style <3 It's refreshing and yet so comforting because it's still girl :D
You don't have any plugins on surf. I personally use a DNS based ad blocker.
It is usable for me, I don't have issues.
Thanks !
Gotta punch holes in the screen and hammer the keyboard a bit haha. But remember friends, Hardware is forever.
Easy, become a Magnetic Nymph today !
Une dictature, comme vous y allez !
The real answer here.
Worth it.
Right now overlays requires elevated privilèges, but ideally it shouldn't. Rewriting the Linux kernel to implement per user namespaces like plan9 does would allow unprivileged actions from any user (just like if any user was sitting in a container, overlayed from the base system).
I know we're not there, and that's not the direction development is going, but this thread is about dreams, right ? 😉
About the XDG specs, they serve a totally different purpose so they're out of the discussion IMO. I'm not advocating against env variables. Just
$PATHwhich is a workaround as I see it, but your mileage may vary. As for your "issue" with steam, of course this is the best way to solve it. Because of today's OS limitation. My point is that with a better designed namespacing implementation, there would be more elegant solutions to solve it (and would get rid of the need to useLD_LIBRARY_PATHtoo, or literally any*_PATHenv variable)