Hacker News Reader

Comment by altmind | Hacker News Reader

Xorg remoting was poorly designed to accomodate DRI/DRM, video card acceleration and had adequate performance to only display primitives on screen. Thats the reasons of poor Xorg remoting adoption. I dont remember seeing anyone in this decade using it - it hands down lost to vnc/nx and rdp.

View on HN

I use it, so I could care less about your "it hands down lost to vnc/nx and rdp" assessment. And until Wayland has a mechanism that has the flexibility of X remoting, it is a strictly inferior technology - for my purposes.

That doesn't mean that I may not be forced to adopt it due to market forces, but let's not pretend that this isn't a glaring hole in Wayland for many people.

couldn't care less.

They mean the same thing.

https://www.google.com/search?client=firefox-b-1-d&q=Diction...

not to mention that 'poor adoptation' is much more likely driven by 'isolated single user on ubuntu laptop that doesn't know this exists' usecase dominating in sheer numbers over 'network of unix workstations operated by group of knowledgable users' than 'application X is slightly slow over the network, boo'

Yeah, VNC is just way better. Even running a local Docker container and using X11 forwarding is extremely slow.

It depends on how you define better. VNC may be faster, but it's just because X carries a lot of historical cruft, I believe. Usability-wise, X is more flexible. I can move individual windows between computers in X. I can't do that with VNC.

I wouldn't mind doing the jump to Wayland if it were as flexible as X, but that doesn't seem to be the case. Correct me if I'm wrong.

It's not "historical cruft" that makes it slow. It's the fundamental architecture of X-Windows that makes it slow. Computers these days are network bound, not CPU or memory bound. It's not sluggish because it's executing too much code or running out of memory or too complicated. It's sluggish because it's making the wrong decisions to do the wrong things at the wrong times in the wrong places.

what's the point of running program locally, to be rendered locally, sending the primitives to Xorg server to be displayed somewhere else? is it using Xorg as a network proxy?

I think you got it kinda backwards, but due to confusing naming you wouldn’t be the first.

It’s more like I’m logging into a remote server (using stuff like SSH), starting applications there and getting the GUI up on my local desktop, like any other local window/app, due to X-forwarding (back to my Xorg server).

It’s not perfect, but it sure is a lot more “natural” and integrated into your desktop than VNC or RDP.

I hope we can keep something similar with Wayland (using maybe XWayland or other compatibility kludges). I think it’s pretty nice.

RDP has had remote app for a long time now, which is essentially the same thing: run program on remote machine, forward its window to local.

The Andrew Window Manager / Andrew User Interface System / Andrew User Environment supported remote display of windows on a workstation display before X-Windows, circa 1985. Andrew was used by lots of people at CMU where it was developed, and also externally. And a lot of the people who worked on Andrew also worked on X10, X11, NeWS, and even (much later) Java.

https://en.wikipedia.org/wiki/Andrew_Project

>Initially the system was prototyped on Sun Microsystems machines, and then to IBM RT PC series computers running a special IBM Academic Operating System. People involved in the project included James H. Morris, Nathaniel Borenstein, James Gosling, and David S. H. Rosenthal.

>The Andrew Window Manager (WM), a tiled (non-overlapping windows) window system which allowed remote display of windows on a workstation display. It was one of the first network-oriented window managers to run on Unix as a graphical display. As part of the CMU's partnership with IBM, IBM retained the licensing rights to WM. WM was meant to be licensed under reasonable terms, which CMU thought would resemble a relatively cheap UNIX license, while IBM sought a more lucrative licensing scheme. WM was later replaced by X11 from MIT. Its developers, Gosling and Rosenthal, would next develop the NeWS (Network extensible Window System).

Andrew died! Andrew is dead!

https://www.youtube.com/watch?v=nZMuBIJxmnA&feature=youtu.be...

How often mankind has wished for a world as peaceful and secure as the one Andrew provided.

Interesting, I've never heard of that facility before. I guess it wasn't promoted very heavily? Or maybe it's just because RDP comes from the MS world and I try very hard to avoid Windows and anything Windows-centric unless forced to.

Anyway, thanks for sharing that. I'll look into it.

Here's some info on RemoteApp for anybody else who's interested.

https://techcommunity.microsoft.com/t5/Enterprise-Mobility-S...

https://social.technet.microsoft.com/wiki/contents/articles/...

Thanks for the links!

Reading those though, I’m kind of underwhelmed.

You have to have a dedicated Windows Terminal Server installation (which I’m sure has expensive and complicated licensing), on that you have to “publish apps” (which seems like a process in itself), on the client you need to subscribe to feeds.

And after about 100 such individual steps... magic.

With X11 I just forward a socket, launch a normal program normally, and everything just works.

That’s just so much simpler, so much easier to work with and easier to understand. I can do it casually, on demand, when I need it. No preparation needed.

That Windows thing... looks expensive and something you which takes planning.

> Or maybe it's just because RDP comes from the MS world and I try very hard to avoid Windows and anything Windows-centric unless forced to.

It'll be due to that.

For the most part it works really well, though still not flawless after all these years.

in the usual case you ssh to a big fat box (the server) and run X clients; the X server is running on your ssh client box.

I run proxmox on one system to run a few VMs. I view the vm console displays remotely in the browser using novnc.

I thought it was pretty cool the first time I used it.

Uh? I much preferred NX instead of VNC because I didn't have to define the resolution when starting the server, plus it felt faster

> it hands down lost to vnc/nx and rdp.

Those solutions don't do what X remote desktop does, though. Namely, those let you share a desktop rather than providing independent remote desktops.

to my knowledge, to supply multiple X remote desktops, you need to SPAWN multiple X desktops. and thats no a proper way to scale its number - they all are independent and not sharing common resources(incl. incoming ports)

I think how X works with this (and a lot of other stuff) can be very fairly criticized. Despite the implementation drawbacks, though, I use this ability heavily and in practice it gives me no trouble. Plus, I'm unaware of any other solution to this use case.

It doesn't scale well if you're talking about dozens of simultaneous desktops, yes, but I rarely have more than three at a time. It's fine for that.

DRI/DRM makes the assumption that your GPU is plugged in the one and only machine hosting all your apps. This wasn't that crazy in 1998, but today the GPU is under my desk while myriad app hosts are racked in datacenters (where a GPU might be an expensive addon, but probably doesn't exist) and good remoting is so neglected that the industry is using web browsers as display servers to fill the gap.

No, web browsers are used as an application platform, not a display server. Especially with SPAs ("thick" clients).

I use ssh -X all the time.

nonono, you're simply not getting it.

I don't use it for reason X, therefore I can project this reasoning onto those that disagree, and dismiss them by calling them outdated. So, obviously your use case is irrelevant.

I've not seen anyone using VNC or remote Xorg for years. Is it really that important these days?

The bar for being important enough to not discard when it works and is the only solution to particular problems is not very high.

I know of no other method to forward individual programs GUIs to other machines. Abandoning X is abandoning a power we have.

You're right that it may not be used as much. Last time I used it was to debug why selenium tests running in chrome were failing in a server with a virtual display (Xvfb) when the tests would work in any developer's machine. I forwarded chrome's GUI from a docker container in a server in another room via my development machine. Its window was neatly tiled next to my other windows in my tiled window manager. You wouldn't be able to tell it wasn't running locally. I don't have to mess around with a desktop inside a desktop. Such neatness in UX is a comfort I'd like to keep.

I'm all for making a new, more efficient display server, but please don't take powers away.

I just use ssh/screen/emacs to work on remote servers. Why would I ever want an xterm?

I bring up remote Emacs frames (from existing sessions, using emacsclient) over ssh forwarded X11 all the time. I prefer this method over tty-only because of the better keyboard support (tty can't pass through all the modifiers or even all the ctrl combinations), image support and clipboard integration. (better colors used to be another reason but less so now that we have 24 bit color support in tty Emacs)

With the fast networks we have nowadays performance is quite good.

I dread the time (if it ever comes) when Wayland takes over to the point that X11 won't be practical to use. And I would use EXWM too which would be even more painful.

Have you tried tramp? I routinely use it to edit files on systems without emacs installed. Also you can edit files belonging to root, etc.

Yes, I use tramp as well for all those things. The remote Emacs session is more for everything else I do with Emacs, mail, chat, M-x shell sessions, dev sessions in progress with language servers running, maybe a debugger.

I use tty emacsclient plenty too (including from my phone) and I could certainly manage without remote X11 and perhaps even without EXWM (ouch) but not looking forward to the prospect of losing it, in exchange for... what? Smoother window transitions and scrolling? I don't want my windows to transition, I want jump scroll and things to pop in place instantly. I disable that shit even on Android.

So I guess I will stick with X11 as long as I can and reminisce about better days once it's gone.

(Emacs having its own remote display protocol would be a way to tackle the first part and maybe EXWM could be re-implemented for Wayland somehow too but neither of those things exist today)

> I use tty emacsclient plenty too (including from my phone)

oh my.

You can also expose the Emacs server socket and allow a local native GUI emacsclient to connect to it.

It would be amazing if it worked that way! But I don't think that it does. :(

emacsclient only tells the Emacs session it is talking to to create a new frame, either on an X11 display or on the tty where emacsclient is running. After that emacs does all the work, emacsclient just waits for emacs to tell it that it's done, it takes no active role in actually displaying stuff.

I would love to be wrong on this, please tell me if I am! I would love it if Emacs actually had its own remote display protocol.

Good point -- I haven't tried gnu emacs's X11 driver in ages, so I'll give it another try. Does gnu emacs's X11 display driver finally have a way to keep running after the X connection terminates, and reconnect to a new X server (or multiple X servers at once)?

Under screen, I keep long running emacs sessions with multiple shell buffers running for months and sometimes years, with all the files I'm working on opened up. Each shell buffer might be configured for some branch of some code, with an interactive python or whatever shell running the code connected to the database, with a bunch of useful commands and context in its history. It's a lot of work to recreate all that state.

(Digression: Bash has no way to save and merge and recreate and manage parallel history threads, does it? Or does the last shell that exits just stomp on the one history?).

Back in my Evil Software Hoarder days, I worked on the NeWS display driver for UniPress Emacs 2.20, and later on the NeWS display driver for gnu emacs. Here's a brochure from February 1988 about UniPress Emacs 2.20 and "SoftWire" (NeWS without graphics).

https://www.donhopkins.com/home/ties/scans/WhatIsEmacs.pdf

It supported multiple display drivers (text, X11, NeWS, SunView), as well as multiple window frames on each of those displays (which gnu emacs didn't support at the time), and you could disconnect and reconnect to a long running emacs later. In effect it was a "multi user emacs" since different users could type into multiple displays at the same time (although weird stuff could still happen since the classic Emacs interface wasn't designed for that).

Emacs 2.20 Demo (NeWS, multiple frames, tabbed windows, pie menus, hypermedia authoring):

https://www.youtube.com/watch?v=hhmU2B79EDU

Here are some examples of where the rubber hits the road in NeWS client/server programming of an emacs NeWS display driver. They both download a PostScript file to NeWS that handles most of the user interface, window management, menus, input handling, font measurement, text drawing, etc, and they have a corresponding C driver on the emacs side. There's also a "cps" file that defines the protocol (which is send in tokenized binary instead of plain text), and generates C headers and code stubs. Together they implement an optimized, high level, application specific "emacs protocol" that the client and server use to communicate:

Emacs 2.20 NeWS display driver (supporting multiple tabbed windows and pie menus in the NeWS Lite Toolkit):

https://www.donhopkins.com/home/code/emacs.ps.txt

https://www.donhopkins.com/home/code/TrmPS.c

Gnu Emacs 18 NeWS display driver (supporting a single tabbed windows and pie menus in The NeWS Toolkit 2.0):

https://www.donhopkins.com/home/code/emacs18/src/tnt.ps

https://www.donhopkins.com/home/code/emacs18/src/tnt.c

https://www.donhopkins.com/home/code/emacs18/src/tnt_cps.cps

  % Return the minimum size to keep emacs from core dumping
  %
  /minsize { % - => w h
    /?validate self send
    CharWidth 10 mul Border dup add add
    LineHeight 5 mul Border dup add add
    % XXX: Any smaller and it core dumps!
  } def

You're replying to a comment that gives an example of use of X11 forwarding that's not fulfilled by ssh/screen/emacs.

> Abandoning X is abandoning a power we have.

A power that literally no one uses.

Well, no one that matters anyway. For values of "matter" equivalent to "uses a modern desktop".

Whatever the case, modern development heavily favors coding for the common case, not supporting a flexible framework that can accommodate fringe cases. And in 2019, your use case is fringe.

If you abandon every feature a handful of users think nobody uses on any piece of complex software you will end up removing something that everyone uses.

People with opinions like yourself are why gnome software developers removed gui functionality for managing raid arrays from gnome disks with the explanation that people should just use btrfs or zfs. This left you with an easy gui to create a raid array that you wont be able to fix without learning cli tools.

https://web.archive.org/web/20140327002450/http://worldofgno...

At the time you couldn't insofar as I'm aware in the installer create a zfs or btrfs raid in 2014. Further reports of btrfs eating data were still disturbingly common and zfs wasn't in anyones official repos.

Regarding the "modern" desktop

"That might have been so if he had lived a few centuries earlier. At that time the humans still knew pretty well when a thing was proved and when it was not; and if it was proved they really believed it. They still connected thinking with doing and were prepared to alter their way of life as the result of a chain of reasoning. But what with the weekly press and other such weapons we have largely altered that. Your man has been accustomed, ever since he was a boy, to have a dozen incompatible philosophies dancing about together inside his head. He doesn't think of doctrines as primarily "true" of "false", but as "academic" or "practical", "outworn" or "contemporary", "conventional" or "ruthless". Jargon, not argument, is your best ally in keeping him from the Church. Don't waste time trying to make him think that materialism is true! Make him think it is strong, or stark, or courageous--that it is the philosophy of the future. That's the sort of thing he cares about."

C.S. Lewis The screwtape letters.

> A power that literally no one uses.

I just told how I used it.

> Well, no one that matters anyway.

I don't matter? That's kind of rude.

> Whatever the case, modern development heavily favors coding for the common case, not supporting a flexible framework that can accommodate fringe cases. And in 2019, your use case is fringe.

Are you going to say that accessibility features should also be discarded? Being deaf or blind are not the common case.

"Modernity", "network transparency is irrelevant in $CURRENT_YEAR" and "nobody uses those features anymore" are among the most commonly cited reasons why you must abandon X NOW and switch to Wayland. Those and "muh security". (The very real security issues with Xorg could be mitigated or eliminated completely with a more sophisticated X server design.)

Like it or not, you will have to come to grips with the fact that the Linux desktop and graphics-stack discussion is dominated by developers from the age of GNOME, who haven't put much thought in beyond how they personally use their own MacBooks. These are the ones calling the shots, and they've decided that X is obsolete, that network transparency is cruft that should be eliminated, and that Wayland is suited to task. So Wayland will be the supported solution going forward.

> Are you going to say that accessibility features should also be discarded? Being deaf or blind are not the common case.

Given the shit state of accessibility under Linux, I'd say yes, it is fringe to the people building the Linux desktop. If you're disabled, it makes much more sense to get a Mac or Windows machine.

I don't think it's really a fringe use case, I actually think it's much more common than you think.

I use ssh -X all the time.

I no longer use X, but when I did, I had to use ssh -XY

Is X over SSH that important? Not really. Is it handy enough for me to use it on a daily basis? Yes, without a doubt!

Everyone has a different use case though. I could just as well be using RemoteApp or something along those lines.

Remote Xorg is the easiest way to get GUI applications running under WSL on Windows. That's the only recent relevant application I've come across though.

Remote Xorg is important to me. I use it pretty much daily. I use VNC as well, but less often.

Reply on news.ycombinator.com