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).
Well worth checking out.
Other than that, it's pretty great.
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?
Windows and Mac use similar terminology to "display server" too, but I guess those are proprietary components that few people look into...
1. Heavy Work
2. Interface Logic and Trivial Work
3. Interface Rendering
Some other people want 1 to run on compute servers and 2,3 to run locally.
I really don't think it matters where 2 runs as long as 1 is fast and 3 is responsive.
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…
I.e. both methods have their trade-offs. I find using remote nvim easier, even if you have to install and configure it first. At least if we are talking about some stable commonly used environment, and not about ad-hoc editing, in which case remote mounting might be a better option.
Yes, this is the basis of the very popular and widely used TRAMP component in Emacs.
>Imagine if you could type ‘edit foo.conf’ on the server and have it pop open a native editor on the client side.
Yes, this is possible with emacsclient.
> Yes, this is the basis of the very popular and widely used TRAMP component in Emacs.
I’m sure TRAMP is better than vim’s netrw, but at least according to [1] it’s not fully asynchronous. It also seems to require a separate SSH invocation; I know you can configure SSH to reuse physical connections, but at least when I once tried it, it didn’t work very well…
> Yes, this is possible with emacsclient.
Judging by [2], it doesn’t seem to work well for that use case (talking to emacs over an SSH tunnel)… Assuming you can get it to work, can you make it work with multiple SSH connections to arbitrary servers, without any per-server configuration? If so, that’s quite interesting and maybe I should check it out. If not, then it still may be quite useful, but it wouldn’t be versatile enough to truly render editor-over-SSH unnecessary.
[1] https://www.reddit.com/r/emacs/comments/23dm4c/is_it_possibl...
[2] https://emacs.stackexchange.com/questions/15144/emacsclient-...
It has a lot of what you're talking about. Typing `atom foo.conf` to open up files locally. Keeping the same connection open and reconnecting without needing to reauthenticate with SSH.
There's also a lot of other stuff that needs to be handled. File searching needs to be hooked up a reasonable way. Language services do as well.
Facebook has done a great job with remote editing (although I don't think the open source version of Nuclide is a priority).
A split editor, with a local ui and filesystem remote can be made to work, but you do have to install something on the remote end, which brings you back to the remote end doesn't have the environment you want, so you just suffer with whatever is there problem.
It seems when you connect on a remote box many times what you really want is to import its files. But despite there have been a lot of network shared file systems none seams to have become the obvious solution, supposedly because it's hard to fix that problem efficiently in the general case, especially for an operation system, Unix, that attach to files an API that have not been designed for this.
Standard DLNA is easy to remember, however, as long as you know the terms--[file]server, renderer, and controller. It even uses http for the fileserver (not sure if that's part of the standard or not though)
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?"Mechanism not policy" my ass. X window borders are an archetypal example of the hollowness of that oft-repeated slogan. The slogan should have been "We must strengthen our borders to protect our precious bodily fluids!" ;)
X windows all have a bunch of properties and messages and parameters relating to how to draw window borders in the server.
They have a border width, and a pixel value. They can even have a border pixmap that is tiled with the same origin as the background tile origin (hope that works for you!).
The rationale was that the server could instantly draw window borders and backgrounds before the client refreshed, to give you a bunch of stippled rectangles to look at while you waited for the client to send some drawing commands.
While NeWS's solution was simply for the server to call a PostScript procedure to instantly draw whatever kind of elaborate border plus anything else it wants the user to see (and interact with), without waiting for the client.
Nobody, but NOBODY uses window borders any more. Only the earliest ugliest toolkits like Athena (Anathema) widgets did. It was a terrible idea to build borders into the window system at that level (POLICY!!!), because nobody ever wants to draw borders in a special but extremely limited way built into the window system at a low level, and then draw the rest of the user interface some other way.
X window borders were totally useless for drawing the brutal beveled edges that were fashionable at the time, or even rounded rectangles. Supporting that would be policy! But go to town and express yourself with tiled pixmap borders, that's pure mechanism baby!
https://tronche.com/gui/x/xlib/window/attributes/border.html
https://tronche.com/gui/x/xlib/window/XSetWindowBorder.html
https://tronche.com/gui/x/xlib/window/XSetWindowBorderPixmap...
Then along came the SHAPE extension.
You'd think it would be straightforward to make an extension that lets you simply set the shape of a window by defining a region somehow.
But no, thanks to borders, each window's shape is defined by TWO regions: the smaller inner client clipping region and the larger outer border bounding region. Well actually it's more than two -- a lot more: There's also their rectangular default core protocol size (both with and without borders), which can be totally different than either of those two other regions's sizes, and modify the effective region.
In summary there are bounding, clip, default bounding, default clip, client bounding, client clip, effective bounding, and effective clip regions. Got it?
Of course all of those regions will almost always be the same since nobody actually uses borders, but thanks to the borders on every window that nobody uses, the SHAPE extension is an order of magnitude more complicated than it needs to be, and even includes a handy glossary and travel guide to all of its various regions.
https://en.wikipedia.org/wiki/Shape_extension
The extension allows defining the shape of two separate regions: the clipping and the bounding regions. These two areas are defined even for windows not using the shape extension: the clipping region is the area that can be used for drawing, the bounding region is the total area covered by the window (that is, the clipping region plus the border). The shape extension allows defining two independent shapes for these two regions.
Both the clipping and bounding are associated, in the shape extension, two areas: a default rectangular region and a possibly non-rectangular client region, defined and changed by the client as specified above. The effective region, which is the actual shape of the window, is the intersection of these two areas. This intersection is performed every time either region is changed: for example, if the client regions contains parts that are outside the default region but the default region is then enlarged, the effective region will include these parts.
https://www.x.org/releases/current/doc/libXext/shapelib.html
Status XShapeQueryExtents(Display display, Window window, Bool bounding_shaped, int x_bounding, int y_bounding, unsigned int w_bounding, unsigned int h_bounding, Bool clip_shaped, int x_clip, int y_clip, unsigned int w_clip, unsigned int *h_clip);
The border of a window is defined to be the difference between the effective bounding region and the effective clip region. If this region is empty, no border is displayed. If this region is nonempty, the border is filled using the border-tile or border-pixel of the window as specified in the core protocol. Note that a window with a nonzero border width will never be able to draw beyond the default clip region of the window. Also note that a zero border width does not prevent a window from having a border, since the clip shape can still be made smaller than the bounding shape.
Glossary
bounding region: The area of the parent window that this window will occupy. This area is divided into two parts: the border and the interior.
clip region: The interior of the window, as a subset of the bounding region. This region describes the area that will be painted with the window background when the window is cleared, will contain all graphics output to the window, and will clip any subwindows.
default bounding region: The rectangular area, as described by the core protocol window size, that covers the interior of the window and its border.
default clip region: The rectangular area, as described by the core protocol window size, that covers the interior of the window and excludes the border.
client bounding region: The region associated with a window that is directly modified via this extension when specified by ShapeBounding This region is used in conjunction with the default bounding region to produce the effective bounding region.
client clip region: The region associated with a window that is directly modified via this extension when specified by ShapeClip This region is used in conjunction with the default clip region and the client bounding region to produce the effective clip region.
effective bounding region: The actual shape of the window on the screen, including border and interior (but excluding the effects of overlapping windows). When a window has a client bounding region, the effective bounding region is the intersection of the default bounding region and the client bounding region. Otherwise, the effective bounding region is the same as the default bounding region.
effective clip region: The actual shape of the interior of the window on the screen (excluding the effects of overlapping windows). When a window has a client clip region or a client bounding region, the effective clip region is the intersection of the default clip region, the client clip region (if any) and the client bounding region (if any). Otherwise, the effective clip region is the same as the default clip region.
Actually, I think of the client/server relationship as a higher level abstraction above the mechanics of the actual socket connection, which can go either way, or both, or many relationships at the same time in different directions and between different sites.
All sites can offer any number of different asynchronous message based services to each other at all times.
It shouldn't matter who was listening, who connected first or how they connected, just that all sites can send messages back and forth on the same channel. It could be UDP, multicast, WebRTC, distributed peer to peer, or a central message dispatcher.
A (web client / X server) site with the display and GPU and mouse offers presentation and rendering and input services to different (web server / X client) sites, which themselves offer database and storage and computing services the other way, at the same time over the same channels.
That's just false. A web server listen(2)s/accept(2)s. A web browser or other HTTP client connect(2)s. An X server listen(2)s/accept(2)s. An X client connect(2)s.
In either case it would not make sense to invert this relationship. In both cases a server is an endpoint that serves its resources to multiple clients. Are people advocating conceptually that the graphics card connect to its programs, and not the program request access to it? That makes very little sense. Just like a web server would not proactively connect to its end user web browsers. The requests happen in the other direction.
For example, whether you weed dealer "Dave" calls you on the phone and tells you he can drop by if you're interested, or if you call "Dave" and ask him to drop by, "Dave" is still the server, and you're still the client.
>Can you make it work with multiple SSH connections to arbitrary servers, without any per-server configuration?
Certainly, of course. Depending on your level of hackery, you can: - Make ssh automatically copy an emacsclient wrapper script over which does the correct thing - Use OpenSSH's Unix socket forwarding on each connection to connect emacsclient to your local Emacs server - Use https://github.com/magit/with-editor
I've never bothered, though, because I run all my shells on remote hosts via TRAMP within Emacs, so when I am in a shell, I can just use open the remote files through the normal Emacs keybindings, rather than typing "emacsclient filename". Thanks to with-editor, this also extends automatically to commands invoked on the remote host which run $EDITOR.
>I don’t have any experience with Emacs, but…
It's not surprising. :) You said "using vi over ssh - or any editor - has always struck me as a hack", "is an unpopular opinion". In fact, it's the consensus in Emacs land. :) Though perhaps that doesn't prevent it from being an unpopular opinion, these days. :)