Hacker News Reader

Comment by scottlamb | Hacker News Reader

> While on the road, you can use your notebook to open a Gimp session on your home machine and edit an image stored there. That is, the Gimp runs on your home machine while your notebook has the GUI.

But that's never where I want the split to be when working across the network.

Remote storage? Sure, sign me up. (The POSIX APIs are horribly unsuitable for network filesystems, but I'm speaking about the concept more than the current implementations.)

Remote heavy computations, like AI workloads and compilation? Definitely.

Remote GUI code? No ugh. Compare the experience of VS Code Remote vs just running VS Code remotely with ssh X11 forwarding, using a high latency connection.

You are fighting the speed of light. It won't go well.

View on HN

I never had to do it myself, but I have a feeling it will work better with Wayland. The delay of 50-80ms introduced by the network is not terribly much (everything under 110ms is fine for playing Dota), so if your software doesn't lag itself, like X11 did, maybe it will work.

You could also use something like Zerotier-one to recover from network being shortly disrupted. This service connects your machines into a virtual network with static IPs, so the IP addresses through which your machines talk will stay the same and TCP connections will recover and ssh will keep working if a device briefly goes offline.

> The delay of 50-80ms introduced by the network is not terribly much (everything under 110ms is fine for playing Dota)

I don't think you're giving the Dota client enough credit there. Game clients don't wait for network to pretend to respond to user input, because it absolutely is noticeable at 100ms latency. Instead, they predict as much as they can client side and display it as fast as possible. For this reason, the client is not at all thin. It knows how to run the whole program by itself. Not so with remote X11. With remote X programs, the client doesn't know what happens on click for anything, so the user really does get hit with a 100ms delay for every interaction with the program.

You're right. I just tested it connecting from laptop in Sweden to a VPS in Sweden through a German VPN server. The total ping was 30-40ms, and running `waypipe ssh remote firefox` was right on the edge of being unusable. Navigating and clicking on links was fine with a bit of delay, but typing when the feedback is delayed is annoying.

Although if I connect to something that's 20ms away (within the same country), the experience is really good.

50-80ms of non-predicted input lag is not terribly much? Surely you must be joking.

Dota is fine because it has network prediction and a finite and well defined set of inputs.

And that's also ignoring video compression artefacts which are that you introduce if you send a modern GFX pipeline across the network. Computers screens can no longer be described with just filled rectangles and text.

Remote GUI code works quite well on RDP sessions.

That is how we have been giving development machines since 2011, Windows workstations on whatever cloud vendor the project is taking place.

NICE DCV works really well as a remote Linux desktop. Not sure what it runs underneath.

It's certainly possible to do better than raw X11 across the network. Other folks mentioned VLC, RDP, and NX too. I assume these protocols reduce bandwidth usage by compression. Sometimes you can even do prediction (as with mosh for ttys or Stadia for games).

The best is always going to be to use a local copy of the logic and data needed most frequently/immediately. E.g. in the VS Code example, they keep the buffer you're editing locally, the logic for cursor movements, the errors you're flipping through, and maybe even some precached autocompletion/highlight stuff. You don't have to wait for a round trip to see your keystrokes show up. That's the advantage of splitting the system in the right place.

Reply on news.ycombinator.com