Hacker News Reader

Comment by dijit | Hacker News Reader

Not sure if you're aware, so I apologise if you are:

1) X11 is already a network aware display system, so it wouldn't take too much work to run remote.

2) SSH has built-in X11 forwarding with `ssh -X <host>`, when you run commands they will be rendered locally. On OSX this needs an X11 server (XQuartz) to work properly.

3) There are "better" remote desktop solutions like "parsec"[0] which run on Windows and Linux. They offer much lower latency and higher bit-depth. They're designed for games. (obviously this comes at the price of bandwidth).

[0]: https://parsecgaming.com/features/

View on HN

X11 is network aware, in that is theoretically possible to speak the protocol over a network. However, anyone considering it should be aware that it is (1) extremely chatty, (2) extremely synchronous, and (3) extremely latency sensitive. It only works well on fast local networks. SSH certainly doesn't make it any faster.

In contrast, RDP and VNC type protocols are screen-replicating designs more suited to higher latency connections.

Finally, if you're using RDP, I'd suggest Remmina as an client. It's fantastic.

To pile on against X11 over ssh, forwarding on a modern Linux workstation is spectacularly painful. I recently needed to forward a lightweight gtk app from one workstation to another over 10gbe and a single switch hop.

With ssh and X forwarding, my local gnome constantly threw up modal dialogs that the forwarded window was unresponsive, forcing me to keep clicking "Wait" to dismiss the modal, then quickly interact with the forwarded window before the next "unresponsive" modal popped up.

Forwarding Firefox over X11 _sometimes_ works. Sometimes Firefox on the remote machine will try to join the session of your local firefox -- but fail and then complain that there's Firefox already running. Adding `--new-instance` helps if Firefox is running in a container and X11 socket file is forwarded to the container but it doesn't seem to help if X11 is forwarded over SSH.

Try '-no-remote'. Or was that '--no-remote'? Anyway, that's what I've used for years and years when needing to run firefox over ssh X forwarding.

Firefox is running on the remote, connected to a different X11 session. It is not running on the local. When I use `firefox --new-session --no-remote` on the remote, I see a dialog pop up on my local machine stating Firefox is already running, but is not responding. To open a new window, you must first close the existing Firefox process, or restart your system.

Yes, this is because firefox doesn't allow multiple ff instances to use the same profile at the same time. You can ask firefox to create a new profile (`firefox -ProfileManager`) and then use a seperate profile for the remote instance

> extremely synchronous

X11, the protocol, is actually mostly asynchronous, it's the libraries and the applications that were built around it in synchronous ways. If you run older applications (like 90s to early 2000s) over X11, it's a lot less bad than modern apps.

Isn't that mostly because modern apps have richer textures and high resolution, high bit depth images by comparison?

Maybe to some degree; head of line blocking and window sizes are real issues that would cause delays; but most of the problem is around requiring more round trips. This is what has made running X servers as thin clients go from being viable on the 10M ethernet of the 90s to being a terrible idea on 1G ethernet today.

I find running GUI GNU Emacs over X11 over ssh to be really pleasant, even moreso than using tramp (which occasionally hangs for no understandable reason), with the only problem being that highlighting text is a bit slow and balky. Otherwise, it's indistinguishable from a local Emacs in responsiveness.

Thanks for suggesting remmina, it might be a teamviewer substitute for a couple old relatives PCs. However I have to solve the dynamic IP problem that doensn't exist on teamviewer, so I was attempting to build a string that sends an email with the IP as payload.

Something like this: curl --url 'smtps://smtp.gmail.com:465' --ssl-reqd --mail-from 'xyz remote IP' --mail-rcpt 'myaccount@gmail.com' --upload-file mail.txt --user 'myaccount@gmail.com:pwd'

Where rather than the mail.txt file I can send the public IP of the remote machine, such as the output of "curl ipinfo.io/ip". Unfortunately I couldn't find how to do that. Backquotes also don't work, it wants a file.

The purpose would be to build a "pre-command" one liner that sends me an email with the remote IP as payload every time the remote user accepts an external connection through remmina. The remote users are old relatives with no knowledge about computers, so the simpler (one click) the better.

>it wants a file

Have you tried process substitution?

  <(curl -s ipinfo.io/ip)

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

Worked perfectly, thanks!

Along with better performance and reliability than X11 RDP allows redirection of sound, folders, USB devices, and can present a virtual GPU which allows access to the physical GPU of the remote end.

X11 works remote, but to my knowledge only to start new applications.

Connect to an existing session and just "continue where you were" is not easy though there might be unmaintained solutions.

If you use ssh forwarding and for some reason gets disconnected, the application dies.

I'd love for you to tell me I'm wrong :-)

The way rdp works on windows is the only thing where I think windows is superior.

Vnc, TeamViewer and similar are not remotely close and they will leave your remote screen open for anyone to see.

Although with teamviewer (maybe others) I think a display driver install can black out the far-end screen.

Xpra is what you want for this: http://xpra.org/

I was hopeful that Xpra would provide reconnectable remote sessions for me on my Linux workstations but I found it pretty difficult to configure with poor documentation. If there are any better installation guides out there, I'd appreciate a pointer to them.

Isn't RDP more akin to VNC than X11? You can connected and reconnect to existing sessions, something you cannot do with X11 (but can with VNC).

I have never heard of Parsec before but it's not immediately obvious that it's an alternative to RDP (Desktop usage)

As far as connecting to existing sessions goes, yes, RDP is closer to VNC to X11. In that respect only though: you can't also simultaneously use the same session locally unlike with VNC.

However, as far as the actual implementation goes, RDP is closer to X11 than VNC. VNC is basically a remote frame buffer, akin to streaming video. This makes it very cross platform friendly, but also IMO feels very slow, even on a local network. RDP is closer to X11 in that it sends display directives (AFAIK, please correct me if I'm wrong) so that it can draw them on the client as they would be drawn on the server. Think sending a "draw button" command rather than sending an image of pixels that are how the button would be rendered. This, combined with compression, helps make RDP feel very fast compared to VNC, and can be used very well even over the internet, unlike X11. I connect to RDP servers in Azure all the time and sometimes forget I'm not working locally, while with VNC you're always aware that it's not as performant.

I really wish there was something like RDP as a server for Linux. (OP seems to be a client AFAICT?) Given Microsoft's recent investment in Linux, maybe this will happen soon?

RDP is definitely closer to the framebuffer style rendering than sending explicit draw commands. Newer versions of the RDP protocol have made this very efficient so it only ends up having to transmit compressed data of the changes per frame, but overall its still more of a video-like stream than true local rendering a la X11.

Thanks! I guess I had been misinformed on that. I was also probably thinking of the RemoteFX stuff, like GPU and media redirection: https://en.wikipedia.org/wiki/RemoteFX

No, you are not misinformed. Both RDP and X11 can send both drawing commands and bitmaps. However, as /u/moonchild says, only older programs seems to be sending drawing commands directly. Newer programs want to be fancy and uses toolkits that do their own drawing to have visual effects. (Witness the speed of Emacs vs. editor-du-jour)

> Newer programs want to be fancy and uses toolkits that do their own drawing to have visual effects

Good toolkits like WPF and UWP implement their own drawing by utilizing Direct3D. These two are using DX 9.0c and D3D 11.0 respectively, and both are supported in RDP protocol.

If you connect to a remote PC and run dxdiag.exe there, you’ll see 3D acceleration is supported, you’ll also see the GPU driver got replaced with completely different one, it’s no longer Intel, Nvidia or AMD, but the one from MS.

This has interesting consequences, e.g. all D3D APIs which move data from system RAM or VRAM or back now become network calls, the system RAM is on the server, VRAM is on the client.

P.S. Modern web browsers use Direct2D and DirectWrite to render stuff on Windows, there’s D3D 11 underneath, i.e. RDP remote rendering is fully supported for browsers and Electron apps.

> RDP is definitely closer to the framebuffer style rendering than sending explicit draw commands.

RDP has capability[1] to send draw commands directly.

From memory it has had this since the early days. At least I used RDP against NT4 servers over a single ISDN link and it was very smooth. I can't believe it could have done that by streaming bitmaps ala VNC.

[1]: https://docs.microsoft.com/en-us/openspecs/windows_protocols...

> From memory it has had this since the early days.

Found an RDesktop implementation from 2001[1] which implements the draw commands. So yeah, old stuff.

[1]: https://soulsphere.org/hacks/rdesktop-sdl/

X network protocol isn't really sending draw commands unless you're using Motif or Xaw or something equally outdated.

Parsec for Linux is only a client; you can't share a Linux desktop using Parsec.

parsec does not support multiple monitors which is a deal breaker in many use cases, so far windows rdp is the best free solution for at least windows -> windows remoting.

Reply on news.ycombinator.com