cross-posted from: https://lemmy.world/post/39342270
Well folks, it’s the beginning of a new era: after nearly three decades of KDE desktop environments running on X11, the future KDE Plasma 6.8 release will be Wayland-exclusive! Support for X11 applications will be fully entrusted to Xwayland, and the Plasma X11 session will no longer be included.
It’s hilarious that all of this was foreseen 17 years ago by basically everyone, and here is a nice list providing just those exact points. I’ve never seen a better structured ”told ya so” in my life.
The point isn’t that the features are there or not, but how horrendously fragmented the ecosystem is. Implementing anything trying to use that mess of API surface would be insane to attempt for any open source project, even when ignoring that the compositors are still moving targets.
(Also, holy shit the Gnome people really wants everyone to use dbus for everything.)
Edit: 17 years. Seventeen years. This is what we got. While the list is status quo, it’s telling that it took 17 years to implement most of the features expected of a display server back in the last millenium. Most features, but not all.
Pretty good for mostly volunteers, hampered by recalcitrant project leads that actively sabotage any progress and consider “told you so” appropriate.
If anyone cared enough, they could have made that list 17 years ago, and pushed through a set of protocol extensions that allow talon to work.
Why did nobody do that?
It’s crazy to me that people complain now. It’s far too late for complaints.
Oh no, people wrote lists like that 17 years ago. That’s the fun part. We have been complaining all along.
Maybe you didn’t do it right. Everything Wayland I ever complained about is fixed now.
I fell like if you had put this list into a Wayland protocol extension request, then put a link to that request into KDE’s showstoppers list, this would have been fixed long long ago.
It’s great that most showstoppers are fixed now. Seventeen years later.
But I’ll bite: Viable software rendered and/or hardware accelerated remote deskop support with load balancing and multiple users per server (headless and GPU-less). So far - maybe possible. But then you need to allow different users to select different desktop environments (due to either user preferences or actual business requirements). All this may be technically possible, but the architecture of Wayland makes this very hard to implement and support in practice. And if you get it going, the hard focus on GPU acceleration yields an extreme cost increase, as you now need to buy expensive Nvidia-GPUs for VDI with even more expensive licenses. Every frame can’t be perfect over a WAN link.
This is trivial with X, multiple commercially supported solutions exist, see for example Thinlinc. This is deployable in literally ten minutes. Battle tested and works well. I know of multiple institutional users actively selecting X in current greenfield deployments due to this, rolling out to thousands of users in well funded high profile projects.
As for the KDE showstopper list - that’s exactly my point. I can’t put my showstoppers in a single place, I need to report to KDE, Gnome and wlroots and then track all of them, that’s the huge architectural flaw here. We can barely get commercial vendors to interact with a single project, and the Wayland architecture requires commercial vendors to interact with a shitton of issue trackers and different APIs (apparently also dbus). Suddenly you have a CAD suite that only works on KDE and some FEM software that only runs on a particular version of Gnome, with a user that wants both running at the same time. I don’t care about how well KDE works. I care that users can run the software they need, the desktop environment is just a tool to do that. The fragmentation between compositors really fucks this up by coupling software to display manager. Eventually, this will focus commercial efforts on the biggest commercial desktop environment (i.e. whatever RHEL uses), leaving the rest behind.
(Fun story, one of my colleagues using Wayland had a postit with ”DO NOT TURN OFF” on his monitor the entire pandemic - his VNC session died if the DisplayPort link went down.)
Thanks, this is a much more nuanced take than what I’m used to.
Regarding thinlinc: They seem to be on it: https://community.thinlinc.com/t/wayland-tigervnc-and-thinlinc-the-future-of-remote-desktops-in-linux/1755.
Regarding fragmented support: is that true? Why would some CAD software not work everywhere when most other software does? Does the thing really need some specific niche Wayland protocol that’s only implemented on one DE for the time being? And if yes, will that protocol really be the first relevant one to not be implemented across the board? I feel like you’re conjuring to a problem that doesn’t necessarily exist. Do you have an actual concrete example that goes beyond “the subwindow placement for this multi-window program is a bit wonky without impeding usability in the slightest”?
Software compatibility is a problem on X as well, so I’m extrapolating. I don’t expect the situation to get better though. I’ve managed software that caused fucking kernel panics unless it ran on Gnome. The support window for this type of software is extremely narrow and some vendors will tell you to go pound sand unless you run exactly what they want.
I’m no longer working with either educational or research IT, so at least it’s someone else’s problem.
As for ThinLinc, their customers have asked about what their plan is for the past decade, but to quote them: ”Fundamentally, Wayland is not compatible with remote desktops in its core design.” (And that was made clear by everyone back in 2008)
Edit: tangentially related, the only reasonable way to run VNC now against Wayland is to use the tightly coupled VNC-server within the compositor (as you want intel on window placements and redraws and such, encoding the framebuffer is just bad). If you want to build a system on top of that, you need to integrate with every compositor separately, even though they all support ”VNC” in some capacity. The result is that vendors will go for the common denominatior, which is running in a VM and grabbing the framebuffer from the hypervisor. The user experience is absolute hot garbage compared to TigerVNC on X.