What I really miss when I don't have X across the network

November 21, 2018

For reasons beyond the scope of this entry, I spent a couple of days last week working from home. One of the big differences when I do this is that I don't have remote X; instead I wind up doing everything over SSH. At a nominal level the experience is much the same, partly because I've deliberately arranged it that way; using sshterm to start a SSH session to a host is very similar to using rxterm to start an xterm on it, for example. But at a deeper level there are two things I wound up really missing.

The obvious thing I missed was exmh, which is the core of how I efficiently deal with email at work. Exmh is text based so it works well within the limitations of modern X network transparency; at work I run it on one of our login servers, with direct access to my email, and it displays on my desktop. In theory the modern replacement for exmh and this style of working would be a local IMAP mail client, if I could find a Linux one that I liked.

(I mean, apart from the whole thing where I'm extremely attached to (N)MH and don't want to move to IMAP any sooner than I have to. An alternate approach would be to find and set up some good text-mode MH visual client, probably GNU Emacs' MH-E, which I used to use years ago.)

But the surprising subtle thing that I wound up missing was the ability to open up a new xterm on the remote machine from within my current session. While starting an xterm this way obviously skips logging in, the real great advantage of doing this is that the new xterm completely inherits my current context, both my current directory and my current privileges (if I'm su'd to root, for example, which is when this is especially handy). It is in a way the Unix shell session equivalent of a browser's 'Open in New Tab/Window', and it's useful for much the same reasons; it gives you an additional view on what you're currently doing or about to do.

There is no good replacement for this that I can see outside of remote X or something very similar to it. You can't get it with job control and you can't really get it with screen or tmux, and a remote windowing protocol that deals with entire desktops instead of individual windows would create a completely different environment in general. This makes me sad that in the brave future world of Wayland, there still doesn't seem to be much prospect of remote windows.

(This entry is sort of prompted by reading The X Network Transparency Myth.)

PS: If you want, you can consider this the flipside of my entry X's network transparency has wound up mostly being a failure. X's network transparency is not anywhere near complete, but within the domain of mostly text-focused programs running over 1G LANs it can still deliver very nice benefits. I take advantage of them every day that I'm at work, and miss them when I'm not.

Comments on this page:

By Tom Buskey at 2018-11-22 11:18:39:

I have something similar to your sshterm. I start xterm locally and ssh to a remote system. Sometimes I want to run an X app over there and have it display to my local X screen. Maybe it's an app that is only on the remote, maybe the app needs to access stuff on the remote and that's the only way to do it.

I use Linux, Mac, Windows which I can get an X server for. I would like to have an X server on Android and Chromebooks, but I don't think that will come.

I don't think you need gigabit to make things really work. But I started using X11 in the era of shared 1 Mb ethernet. 100Mb was much more usable but on rare occasions, I had to work across a dialup at 28k (with Interleaf). I found protocol compression like dxpc and Slirp to help with dialup.


I'm the author of the linked 'transparency myth' article. Although there are things to do before it is in the scope of the informed public, the corresponding mode of remoting in the arcan ecosystem is getting quite close to working within the ecosystem of arcan tools, including the case you mentioned (I also have a similar pattern).

The improvement, hopefully, will be adaptive compression based on window type, and specialized packing formats for text-oriented applications etc. to facilitate server-side rendering.

By Greg A. Woods at 2018-11-25 21:38:43:

I'm usually the first person to forget about SSH's networking capabilities, but I never ever forget to use "ssh -Y -C remote.host", and that way I can "transparently" start remote X11 apps just as if I was starting them on a nearby LAN server, or indeed on my desktop itself.

Starting something like Emacs over a higher-latency WAN link can take a lot longer than usual, and of course anything that needs to find out more about fonts, e.g. when emacs needs to use a new font face, has excessive delay, but once that's all done then I find editing in an X11 Emacs window via compressed SSH X11 tunnel to be more or less transparent at up to 100 ms RTT, and not too annoying even as high as 180 ms RTT (at 160 ms RTT opening the first window with a non-standard default font face in a new Emacs process takes as much as 2.5 min, and creating a new frame is about 60s, but typing and navigating text is quite usable, though a bit more laggy than the direct SSH terminal connection).

Generally I find X11 Emacs via a WAN link to be far preferable to using Emacs in a terminal-only session with a local xterm at anywhere under 200 ms RTT, especially for any longer term or more intensive editing tasks).

(FYI I'm about 160 ms RTT from the main work servers I use daily, and about 80 ms from my personal remote server. Generally though since the advent of tools like rsync and git I don't do so much on the remote systems beyond normal command-line work.)

Written on 21 November 2018.
« When Prometheus Alertmanager will tell you about resolved alerts
Some views on more flexible (Illumos) kernel crash dumps »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Nov 21 00:14:25 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.