5 ms·
The point still stands, though. You need a roundtrip, even if it starts from the X server rather than the X client.
by dpassens 3y ago
The point still stands, though. You need a roundtrip, even if it starts from the X server rather than the X client.
- pjmlp 3y agoYou always need some level of round trip between keyboard and UNIX procecess. The server application isn't guessing keys, regardless of the connection format. What matters is how the communication is being compressed and local optimizations.
- johannes1234321 3y agoThe difference here is that VisualStudio code fully runs the GUI on the local machine and only file IO or external programs (compiler, the actual program being devleoped, ...) run remotely. Thus the UI reacts promptly to all interactions and many of the remote interactions happen asynchronously, thus even saving a file will not block further actions. Whereas any non trivial X application does work in the client, thus even basic interactions have a notable delay, depending on connection.
- pjmlp 3y agoIt shows you never used slow telnet sessions over modems. There is no difference between doing this over text or graphics, in terms of the whole setup regarding network communications for data input and output.
- Rusky 3y agoVS Code isn't doing this with text or graphics, though. In X terms, it's running both the client and server on your local machine. It simply doesn't put the network boundary in the same place as an X application. VS Code's "backend" that runs on the remote machine is rather only in charge of more "asynchronous" operations that aren't part of the UI's critical path, like saving files or building the project. It doesn't speak anything as granular as the X protocol.
- pjmlp 3y agoClassic UNIX program architecture in distributed systems, apparently some knowledge lacking here. Long are the days using pizza boxes for development it seems.
- Rusky 3y agoThe comparison you made wasn't to arbitrary distributed UNIX programs, though. It was to X applications, which don't work this way.
- johannes1234321 3y agoAgain: The key difference is that in VS.Code the UI runs local, thus all UI interactions are "immediate" and there is no difference between local and remote operation. Yes, IO has latency, but where possible that is hidden by the UI (possible: saving a file happens without blocking UI; not possible: loading a file requires the file to be loaded .. but even then the UI can already prepare the window layout) Thisnis very different form a system, where each keystroke and each menu action has to be transfered first, before the remote side can identify the needed UI update and send that back
- pjmlp 3y agoAgain: learn UNIX distributed computing architecture. Not going to waste more my time explaining this.
- johannes1234321 3y agoTelnet is a way more low level protocol. Please learn what you are talking about and have a good day.
- keyle 3y agoPjmlp is right. You need to read on how X was designed for remote work.
- mr_mitm 3y agoJohannes's point was, I believe, that using VSCode remotely works fundamentally different than using apps remotely via X. I don't think he is confused about how X was designed.
- throw10920 3y agoDesigned badly, in this case. Arguments to authority aren't appealing. Arguments from logic are. The fact is that X and VSCode's remote protocols are designed very differently, and in high-latency and high-jitter connections (and many low-bandwidth ones), VSCode's protocol is simply better.
- vidarh 3y agoYou're assuming someone would be running Emacs on the remote machine talking to a local X server in order to edit files on a remote machine, but people would generally not do that, but use something like TRAMP, where Emacs would be running on your local machine, but accessing remote files. TRAMP only requires ssh or telnet (or scp, rsync, any number of other methods) on the remote machine.