> I keep thinking about Wayland. It's really a double-edged sword. Aside from my pet peeve that it by-design blocks, for inane security reasons, my favourite feature of sdtui, which is X11 selection stealing, it also offers no mode that would work over a network—for example, to transfer picture data you can only use EGL or shared memory.
"it by-design blocks, for inane security reasons" or "for inane security reasons, my favourite feature of sdtui, which is X11 selection stealing". Either way, ik curious what the inane security reasons are. Also, why is blocking bad in Wayland?
It seems like one of the biggest complaints about Wayland is that it doesn't work over a network.
Does anyone actually work that way? I've tried it a few times, and every time I tried it it turned out to be unusably slow.
Wayland does not support network transparency because you're supposed to use a VNC server. Making the X protocol network-transparent worked because draw commands don't make for much traffic, but today you'd be hard-pressed to find any X application that does not just send entire bitmaps (or rather, OpenGL textures) to the X server. It's similar to how Mac OS moved away from a PostScript-based display architecture, if my knowledge of Mac OS history is to be trusted.
Having said that, I don't know if there are working VNC implementations for Wayland. Due to Wayland's security architecture, a VNC server (or any other thing that grabs screen contents) requires permission from (and thus cooperation with) the compositor.
GNOME and KDE have working support for remote desktop. Weston supports RDP. Sway (and other wlroots-based compositors) have been working on protocols to support it.
GTK2 apps used to work fine over a network. On a LAN connection there was almost no difference from local. If your "modern" toolkit does things the stupid way around and just sends entire bitmaps of changed windows per update, rather than using the core protocol or XRender to redraw the window, that's not X's fault.
Wayland is pretty much a project whose unstated goal is not only to raze X to the ground, but also to salt the earth where it once stood so that none of its core principles survived the transition. That's why the security reasons are "inane".
It would be possible, and desirable, to design a secure X server with zero alterations to the X protocol itself, and most clients wouldn't know the difference. But again, security isn't really the goal. The goal is to destroy X so thoroughly that no one builds anything on top of X, even from a conceptual standpoint. Otherwise they wouldn't have gone to the trouble of deliberately eliminating network transparency, server side rendering primitives, window managers, etc.
I've been looking at Wayland for a little while now, and have been slowly coming to a similar conclusion based on the limited exposure I've had to it. I hadn't quite reached the view you describe here, solely because I was holding out a little optimism that things weren't really that bad.
What I'm stuck on is the whyyyy. X has its faults, most definitely, but... X works for quite a lot of people, too.
I've found that one of the most helpful additions to my worldview has been a sense of implementational balance - and particularly the understanding that reacting to perceived extremes by counterbalancing all the way in the direction of the opposing extreme does not produce balance, but rather drowns out the old extreme by all the noise made by the new one, unless the counterbalancing effort incorporates an embrace-and-extend model.
I get the impression Wayland is only being worked on by people who've either been heavily bitten by X, influenced by those who have, or influenced by a rumor amplification-chain of toxicity about X.
The 3rd is both the saddest and likeliest part, but understandably so - there was a nontrivial amount of X11 vitriol back in the 90s and 00s.
I think this is primarily because the hardware ecosystem and the various vendor implementations were all indeed atrociously broken, so X had to be a bit broken too in order to make everything work. Graphics drivers (PCI access!) did their work in userspace, so X had to run as root. The kernel had no idea about the video mode; it was just told "if you try and print anything to the screen right now you'll confuse the GPU so badly so please just don't" and X handled the rest. GPUs were going through formative times (circa 2006) with the introduction of fundamental OpenGL functionality (now used for compositing). X wasn't modular, _and_ there were two vendors. And of course 256-bit color paletting was still something that got talked about and needed to be maintained through the whole stack.
These were simply growing pains.
Today, X.Org is modular, which is a small mercy for everyone's sanity; KMS simplifies driver development (as in, X doesn't have to be involved at all anymore); GPUs are somewhat (!) more stable and offer a more consistent GL API; nobody really complains when the display doesn't support <16bpp (ie requires paletted display) anymore. The list goes on.
Things are absolutely not perfect... who knows, there may be an XInput3 :)... but things are on fire significantly less.
So, it is IMO utterly unreasonable to lump the good parts of X in with the bits that maybe made a few core devs gnash their teeth and kill the whole thing for guilt by association!
Sadly it looks like this is what we're stuck with.
So, X11 will live on - but as a kind of negative space that future software historians will puzzle over and go "why did this Wayland thing state that they avoided such an oddly specific set of functionality?" This kind of negates the devs' apparent desire to make everyone forget it, haha. If they'd just taken the good parts and made something 11X better than X11...
The challenge for anyone looking to incrementally improve X11 is that “modern desktops” (i.e. Mac & Windows) leverage totally different design approaches vis-a-vis centralized authoritarian IPC and graphical hardware access.
I’m glad people decided to put together their heads to try to collaborate on a new standard, and horrified they decided to make it Linux-only.
I don't think than X11/Wayland should work over network at all. They don't have enough information do this efficiently. On other side it works REALLY well on toolkit(GTK/Qt) level. Try GTK Broadway
I just ran QEMU in my web browser and I feel really weird.
On the one hand, VNC suddenly just became obsolete. On the other hand... Ubuntu Core is playing with getting Webkit-GTK running directly on top of DRI (via Wayland), and I hope like mad there's never an alternate reality where Chromium takes the place of X11... eep
X2Go (the OSS fork of "nx - no machine") works really well over a network. Though I really think it might be best to do the rendering client-side and push video frames. Though I do concede that the two models are really two separate ways to do computing, based on where your actual compute resources are located. With X11 forwarding, the rendering happens server-side, at the user's terminal [1], while with e.g. VNC the rendering happens client-side on the remote machine and the video frame is presented to the user, who is basically sitting at a dumb terminal. HTML delivered over HTTP would be the most wide-spread technology that uses user-side rendering today.
[1] The terminology might seem weird to you with the server-side being the user's side, or what you'd usually term the "client", but it makes sense - you run the X11 server on your PC, then connect over the network to a remote host using e.g. SSH, so now you have an X11 server and an SSH client running on your PC, connected to an SSH server on the remote. Then you open a socket on the remote side connected to the X11 socket on the local side via the SSH tunnel and remote programs initiate connections to your X11 server. You type at your terminal, that gets picked up by your SSH client and sent to the SSH server, the SSH server relays your typing to the remote shell, which execs the remote X11 client, which connects to your X11 server. Simple!
> Does anyone actually work that way? I've tried it a few times, and every time I tried it it turned out to be unusably slow.
I use it pretty much daily at work to run interactive programs on beefy data reduction machines (just ssh in with X11 forwarding turned on and it just works). Over the local network it works pretty much as good as locally - lightyears ahead of VNC or RDP - at least when using programs that don't use ui toolkits that are built around wayland model..
> It seems like one of the biggest complaints about Wayland is that it doesn't work over a network. Does anyone actually work that way? I've tried it a few times, and every time I tried it it turned out to be unusably slow.
I spend most of my time in Emacs on Linux. At an old job I had to use a Windows desktop, so I used a full screen Cygwin X server to display an Emacs window running from one of our Linux test servers. This also had the advantage that Emacs would keep running in Screen, even after my dev machine was turned off.
"it by-design blocks, for inane security reasons" or "for inane security reasons, my favourite feature of sdtui, which is X11 selection stealing". Either way, ik curious what the inane security reasons are. Also, why is blocking bad in Wayland?
It seems like one of the biggest complaints about Wayland is that it doesn't work over a network. Does anyone actually work that way? I've tried it a few times, and every time I tried it it turned out to be unusably slow.