←back to thread

532 points tempaccount420 | 6 comments | | HN request time: 0.999s | source | bottom
Show context
Zambyte ◴[] No.45396281[source]
I was skeptical of the claim that it's faster than traditional SSH, but the README specifies that it is faster at establishing a connection, and that active connections are the same speed. That makes a lot of sense and seems like a reasonable claim to make.
replies(9): >>45396495 #>>45396529 #>>45396639 #>>45396881 #>>45400344 #>>45400909 #>>45400915 #>>45403285 #>>45410927 #
notepad0x90 ◴[] No.45396639[source]
Although, dollars-to-donuts my bet is that this tool/protocol is much faster than SSH over high-latency links, simply by virtue of using UDP. Not waiting for ack's before sending more data might be a significant boost for things like scp'ing large files from part of the world to the another.
replies(6): >>45396713 #>>45396823 #>>45397014 #>>45397091 #>>45397195 #>>45402450 #
finaard ◴[] No.45396823[source]
Not really that relevant - anybody regularly using SSH over high latency links is using SSH+mosh already anyway.
replies(2): >>45397106 #>>45402528 #
1. oefrha ◴[] No.45397106[source]
The huge downside of mosh is it handles its own rendering and destroys the scrollback buffer. (Yes I know I can add tmux for a middle ground.)

But it's still irrelevant here; specifically called out in README:

> The keystroke latency in a running session is unchanged.

replies(1): >>45398729 #
2. esseph ◴[] No.45398729[source]
"huge downside" (completely mitigated by using tmux)

The YouTube and social media eras made everyone so damn dramatic. :/

Mosh solves a problem. tmux provides a "solution" for some that resolves a design decision that can impact some user workflows.

I guess what I'm saying here, is it you NEED mosh, then running tmux is not even a hard ask.

replies(2): >>45400350 #>>45402992 #
3. oefrha ◴[] No.45400350[source]
No it’s not completely mitigated by tmux. mosh has two main use cases (that I know of)

1. High latency, maybe even packet-dropping connections;

2. You’re roaming and don’t want to get disconnected all the time.

For 2, sure tmux is mostly okay, it’s not as versatile as the native buffer if you use a good terminal emulator but whatever. For 1, using tmux in mosh gives you an awful, high latency scrollback buffer compared to the local one you get with regular ssh. And you were specifically taking about 1.

For read-heavy, reconnectable workloads over high latency connections I definitely choose ssh over mosh or mosh+tmux and live with the keystroke latency. So saying it’s a huge downside is not an exaggeration at all.

replies(1): >>45405391 #
4. jeffhuys ◴[] No.45402992[source]
Honestly, it feels like the one being dramatic here is you. Because the one you’re replying to added “huge”, you added a whole sentence calling everyone “so damn dramatic”. But oh well.
replies(1): >>45405411 #
5. esseph ◴[] No.45405391{3}[source]
I believe this depends on the intent of your connection!. The first sentence of your last paragraph: "For read-heavy, reconnectable workloads" - A-ha!

From my stance, and where I've used mosh has been in performing quick actions on routers and servers that may have bad connections to them, or may be under DDoS, etc. "Read" is extremely limited.

So from that perspective and use case, the "huge downside" has never been a problem.

6. esseph ◴[] No.45405411{3}[source]
You know what has a "huge downside"? Radiation therapy.

Not a scroll back buffer workflow issue.