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.
And the network transparency argument is long gone. While you can indeed network windows over the wire, most toolkits use client side rendering/decorations. So you’re just sending bloated pixmaps across the wire when things like RDP , VNC, etc deal better with compression, damage to the window, etc. And anything relying or accelerated with DRI3 is just NOT network transparent.
Most modern toolkits have moved past X11 because the X protocol was severely lacking, and there wasn’t a good way as a committee to modify the protocol in an unified manner. I mean look at the entire moving Earth that it took for XFixes and Damage extensions. Toolkits wanted deep access to the underlying hardware and so they would go out of their way to work around X, because it just could not keep up.
Tell me you never deployed remote linux desktop in an enterprise environment without telling me you never deployed remote desktop linux in an enterprise environment.
After these decades of Wayland prosperity, I still can’t get a commercially supported remote desktop solution that works properly for a few hundred users. Why? Because on X, you could highjack the display server itself and feed that into your nice TigerVNC-server, regardless of desktop environment. Nowadays, you need to implement this in each separate compositor to do it correctly (i.e. damage tracking). Also, unlike X, Wayland generally expects a GPU in your remote desktop servers, and have you seen the prices for those lately?
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.
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.
If you deal with the fundamental problems of the protocol itself and also provide backwards compatibility… Congrats, you’ve just reinvented Wayland and XWayland.
Dealing with X11’s problems while still being X11, when X11 is the problem? Yeah, I wouldn’t hold my breath either.
The fundamental architectural issue with Wayland is expecting everyone to implement a compositor for a half baked, changing, protocol instead of implementing a common platform to develop on. Wayland doesn’t really exist, it’s just a few distinct developer teams playing catch-up, pretending to be compatible with each other.
Implementing the hard part once and allowing someone to write a window manager in 100 lines of C is what X did right. Plenty of other things that are bad with X, but not that.
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?
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.
And the network transparency argument is long gone. While you can indeed network windows over the wire, most toolkits use client side rendering/decorations. So you’re just sending bloated pixmaps across the wire when things like RDP , VNC, etc deal better with compression, damage to the window, etc. And anything relying or accelerated with DRI3 is just NOT network transparent.
Most modern toolkits have moved past X11 because the X protocol was severely lacking, and there wasn’t a good way as a committee to modify the protocol in an unified manner. I mean look at the entire moving Earth that it took for XFixes and Damage extensions. Toolkits wanted deep access to the underlying hardware and so they would go out of their way to work around X, because it just could not keep up.
Tell me you never deployed remote linux desktop in an enterprise environment without telling me you never deployed remote desktop linux in an enterprise environment.
After these decades of Wayland prosperity, I still can’t get a commercially supported remote desktop solution that works properly for a few hundred users. Why? Because on X, you could highjack the display server itself and feed that into your nice TigerVNC-server, regardless of desktop environment. Nowadays, you need to implement this in each separate compositor to do it correctly (i.e. damage tracking). Also, unlike X, Wayland generally expects a GPU in your remote desktop servers, and have you seen the prices for those lately?
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.
Plenty life in X11 yet.
Xlibre running around.
Pheonix on the horizon. (Zig!)
xlibre is xorg with some half baked commits that had to be removed from xorg for breaking too much and a guy who is kind of a nutcase.
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.
If you deal with the fundamental problems of the protocol itself and also provide backwards compatibility… Congrats, you’ve just reinvented Wayland and XWayland.
Dealing with X11’s problems while still being X11, when X11 is the problem? Yeah, I wouldn’t hold my breath either.
The fundamental architectural issue with Wayland is expecting everyone to implement a compositor for a half baked, changing, protocol instead of implementing a common platform to develop on. Wayland doesn’t really exist, it’s just a few distinct developer teams playing catch-up, pretending to be compatible with each other.
Implementing the hard part once and allowing someone to write a window manager in 100 lines of C is what X did right. Plenty of other things that are bad with X, but not that.
No KMag + KDE Connect remote input, no Wayland.
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?