It's a shame that all of the X replacements on the horizon also ditch the network transparency part, even though that's been a killer feature for me. I hate how much of a hack Remote Desktop is on Windows machines.
I've used ssh -X many times in my life, but at the same time, I understand why network transparency doesn't make as much sense anymore.
Classically, the X protocol kept a huge amount of state on the server, and clients would just send small requests to manipulate that data. Drawing would take place server-side, and it was relatively simple drawing at that, since UI needs were fairly modest. Text rendering occurred on the server with small strings sent from the client. And overall, it made sense to send a small amount of data to produce a large amount of graphics.
These days, however, rendering occurs almost exclusively on a combination of the client and the GPU. Everything takes place via large memory buffers, and compositing. And pushing those over the wire doesn't work nearly as well; if you're going to do that, you need protocols designed for it, with compression and delta-encoding, much like modern video codecs (but optimized for remote-desktop).
So I think it makes sense that network transparency is being rethought, in favor of protocols that look a lot more like remote-video (and remote-audio).
ssh -X is useful for something like clipboard forwarding from your local desktop to remote server (and back). You can work in something like nvim remotely, and have a nice clipboard integration. What will happen with such functionality after the switch to Wayland?
In theory, a saner approach is using a local editor to edit remote files.
But people don’t do that. Why? Because the available implementations suck. NFS sucks because it’s slow and hangs your programs; sshfs is the same but worse. Vim has native remote file support in the form of scp://, which invokes the scp command every time you open or save a file - synchronously, so even if you’re saving you have to wait. This might be vaguely tolerable if you configure ssh to share connections, but in general it sucks. And with any of those, you have to set up a separate connection to the server and re-find the directory you’re in, which may or may not be time consuming. By contrast, typing vi into the SSH prompt usually just works, so that’s what people do.
But there’s no fundamental technical limitation here. Imagine if you could type ‘edit foo.conf’ on the server and have it pop open a native editor on the client side. File transfer would be tunneled through the existing SSH connection, with no setup time or need for re-authentication; it would be fully asynchronous, so the editor would never hard-block waiting for an operation to complete, but it would still indicate when saves have been completed, so you know when it’s safe to run commands on the server that use the new files. Thing is, none of what I just said is especially complex or challenging from a technical perspective; it’s just that it would require changes to a bunch of components (ssh on the client and server; vim) that weren’t designed with that use case in mind.
Anyway, I’m getting a little off topic here - but I think the point generalizes. In my ideal world, the future of X forwarding would be fixing the most common use cases so you don’t need X forwarding. For the rest, well, the ‘server sets up a tunnel over SSH’ approach could work just as well for VNC, or for an improved remote display protocol that uses a video codec.
In the real world, I suppose things will just fester, remote display support will get worse, and remote editing will continue to suck. But I can dream. Or maybe implement something myself, but there are so many other things to do…
And you may find yourself
Behind the wheel of a large Microsoft Mouse
And you may find yourself on a beautiful PC
With a beautiful Window
And you may ask yourself, well
How did I get here?