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.

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.)

Oh no, people wrote lists like that 17 years ago. That’s the fun part. We have been complaining all along.

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.

That list is hilarious. I especially love how gnome just gives up on Wayland protocols and wants everyone to run a sidechannel over dbus instead.

This is why we can’t have nice things.

Because instead of just using a common well defined API, every developer is supposed to ”work together with Wayland compositors”, of which there are many, none of which are up to feature parity with X. Working together with the (at least) three major compositors is far top much work for most projects, if you can even get them on board.

Every compositor must reimplement everything previously covered by third party software, or at least define and reimplement APIs to cover that functionality. We have been screaming about this obvious design fuckup since Wayland was first introduced, but nooo, every frame is perfect.

Take a look at https://arcan-fe.com/ for what a properly architected display server could look like instead of the mess we currently have with Wayland. I’m holding off on moving to Wayland for many reasons, and it wouldn’t surprise me if Arcan becomes mature and fully usable before Wayland. If I get to place a bet on either on Wayland or a few guys in a basement with a proper architecture, I know what I’ll put my money on.

All connectors are compatible given enough violence.

The VGA connector is actually reversible! Once. given enough force. It also doesn’t actually work properly when installed upside down.

Friends don’t let friends run erasure coding on BTRFS.

Personally, I don’t run anything on BTRFS. I like having my data intact and I also want two parity drives in my pools.

The thing is - wayland does kind of prevent it by forcing the GPU into the rendering pipeline far harder than Xorg. The GPU-assumptions throughout the code base(s) makes latency shoot through the roof when running software rendered. If you want decent latency, you need a GPU, and if you want to run multiuser you are going to pay Nvidia a shitton of money.

I can also imagine it’s hard (impossible?) to do performant damage tracking in a VNC server without implementing at least parts of the VNC server inside the compositor. This means that the compositor and VNC server gets tightly coupled by necessity. Choice will be limited. Would you like the bad DE with the good VNC server or the good DE with the bad VNC server? Bad damage tracking means shit latency and high bandwidth usage, or other tradeoffs. So even if someone managed to implement what I want on Wayland, it would most likely be limited to a single compositor and not a general solution allowing a free choice of compositor.

Best software suite I know of for it is Cendio Thinlinc, on top of TigerVNC. Free for up to 5 users. There are some others in the same niche. My recommendation would be to try Thinlinc on Rocky 9 or Ubuntu 24, and configure it to use XFCE. Mate, KDE, or Cinnamon, all work fine. Turn off compositing! Over a good WAN-link it feels mostly local unless playing fullscreen videos. On a LAN-link, the only thing giving it away is extra tearing and compression artifacts when playing youtube-videos fullscreen. Compared to many others solutions I have tried, the latency and ”immersion” is incredible.

As for me, I’ll try to never manage linux desktop fleets or remote desktops again.

What I’ve seen of rustdesk so far is that it’s absolutely not even close to the options available for X. It replaces TeamViewer, not thin clients.

You would need the following to get viability in my eyes:

• Multiple users per server (~50 users)
• Enterprise SSO authentication, working kerberos on desktop
• Good and easily deployable native clients for Windows, Linux and Mac, plus html5 client
• Performant headless software rendered desktops
• GPU acceleration possible but not required
• Clustering, HA control plane, load balancing
• Configuration management available

This isn’t even an edge case. Current and upcoming regulations on information security drags the entire industry this way. Medical, research, defence, banking, basically every regulated landscape gets easier to work in when going down this route. Close to zero worries about endpoint security. Microsoft is working hard on this. It’s easy to do with X. And the best thing on Wayland is RustDesk? As stated earlier, these issues were brought up and discarded as FUD in 2008, and here we are.

Wayland isn’t a better replacement, after 15 years it’s still not a replacement. The Wayland implementations certainly haven’t been rushed, but the architecture was. At this point, fucking Arcan will be viable before Wayland.

Exactly my point. The issues people consider ”solved” with wayland today will be solved in production in 3-5 years.

People are still running RHEL 7, and Wayland in RHEL 9 isn’t that polished. In 4-5 years when RHEL 10 lands, it might start to be usable. Oh right, then we need another few years for vendors to port garbage software that’s absolutely mission critical and barely works on Xorg, sure as fuck won’t work in xwayland. I’m betting several large RHEL-clients will either remain on RHEL8 far past EOL or just switch to alternative distros.

Basically, Xorg might be dead, but in some (paying commercial) contexts, Wayland won’t be a viable option within the next 5-10 years.

Yeah, the few thousand users I managed desktops for will remain on X for the next few years last I heard from my old colleagues.

Because of my points above

But good that your laptop works now and that I can help my grandma over teamviewer again.

There is actually less to ’xkill’. It nukes the X window from orbit in a very violent manner. The owning process(-tree) will usually just instantly curl up and die.

The main benefit is that it doesn’t actually kill the process, it only nukes the window. As such, you can get rid of windows belonging to otherwise unkillable processes (zombies, etc).

Also, it’s fun. Just don’t miss the window and accidentally kill your WM. (Beat that Wayland)

Now consider that most enterprises are about five years behind that. Takes a few years before what’s available in Fedora trickles down to RHEL, and a few more years before it’s rolled out to clients. Ubuntu is on a similar timeline.

The fixes you got two years ago might be rolled out in 3 years in these places. Oh, and these are the people forking up much of the money for the Wayland development efforts. The current state of Wayland if you pay for it is kinda meh.

I’ll bite. It’s getting better, but still a long way to go.

• No commercially viable remote desktop or thin client solutions. I’m not talking about just VNC, take a look at for example ThinLinc to see what I’m looking for - a complete solution. (Also, it took like ten rough years before basic unencrypted single user VNC was available at all.) Free multimillion dollar business idea right here folks!
• Related to the above point - software rendered wayland is painful. To experience this yourselves, install any distro in VirtualBox or VMWare or whatever and compare the usability between a Xorg DE (with compositing turned off) and the same Wayland DE. Just look at the click-to-photon latency and weep. I’ve seen X11 perform better with VNC over WAN.
• ”We don’t need network transparency, VNC will save us”. See points above.
• ”Every frame is perfect” went just as well as can be expected, there is a reason VSYNC is an option in games and professional graphics applications. Thanks Valve.
• I’m assuming wlroots still won’t work on Nvidia, and that the Gnome/KDE implementations are still a hodgepodge, and that Nvidia will still ask me to install the supported Xorg drivers. If I’m wrong, it only took a decade or so to get a desktop working on hardware from the dominant GPU vendor. (Tangentially related - historically the only vendor with product lines specifically for serving GPU-accelerated desktops to thin clients)
• After over a decade of struggles, we can finally (mostly) share out screens in Zoom. Or so I’m told.

But what do I know, I’ve only deployed and managed desktop linux for a few thousand people. People were screaming about these design flaws back in 2008 when this all started. The criticisms above were known and dismissed as FUD, and here we are. A few architectural changes back then, and we could have done this migration a decade faster. Just imagine, screen sharing during the pandemic!

As an example, see Arcan, a small research project with an impressively large subset of features from both X11 and Wayland (including working screen sharing, network transparency and a functioning security model). I wouldn’t use it in production, but if it was more than one guy in a basement working on it, it would probably be very usable fairly fast, compared to the decade and half that RedHat and friends have poured into Wayland thus far. Using a good architecture from the start would have done wonders. And Wayland isn’t even close to a good architecture. It’s just what we have to work with now.

Hopefully Xorg can die at some point, a decade or so from now. I’m just glad I don’t work with desktops anymore, the swap to Wayland will be painful for a lot of organisations.

Rough start? It’s been over a decade and it’s still rough.

You have FreeIPA if you want a ”product”.

But honestly, if I, as a Linux admin, would do this kind of thing at this scale, I’d probably elect to remain on AD.

Here be dragons. But basically:

• Run a VM from contents of a physical disk: use ’dd’ to create disk image. If on linux, try to boot and fix all the errors, hopefully few.

• Run VM as physical machine: other way around.

You won’t find this in a tutorial. You need to understand concepts, read manuals, fit everything together, execute, fail and retry until it works.

For Windows, I have no idea. Conceptually, I figure it’s similar.

It mostly affects people working with ”fun” enterprise hardware or special purpose things.

But to take one example, proprietary drivers for high performance network cards, most likely from Nvidia.