On: Why aren’t we using SSH for everything?

[saynsedit]

While SSH seems like the ideal console application delivery platform, it suffers in a major way: no local execution.

This matters when latency matters. Processing all keystrokes remotely sucks over high-latency links like airplanes, cell phones, satellites, etc.

This can also be a pro. JavaScript is a mess in terms of design, increased client complexity, and security. It depends on what your requirements are.

[snuxoll → saynsedit]

This is actually one area where I like our IBM i system, the 5250 console may be extremely lacking in many features compared to say a VT100, but the block-based console eliminates the remote server from needing to handle redrawing or dealing with input until the user explicitly requests an action. It's pretty amazing to see a thousand users connected to the box and none of them have any latency with inputting data (getting a new screen back from the server make take a couple milliseconds) because it's all done locally until they press a function key or some other action button that pushes the data off to the server.

[wrs → snuxoll]

The same description would apply to HTML forms in the browser. In fact there are HTTP gateways that translate IBM forms to HTML on the fly.

[dbalan → saynsedit]

Mosh helps in this case, they buffer the keystrokes and liberates user frustration by giving a visual response.

[1] https://mosh.mit.edu

[icebraining → dbalan]

Yeah, but it's not SSH anymore (except for the authentication), it's a custom protocol based on UDP.

[dingaling → saynsedit]

Using compression with -C argument helps keystroke buffering on high-latency connections and also protects against several crypto attacks.

It also makes sense on LAN connections, instead of sending each character at a time...