3 ms·

Not really that relevant - anybody regularly using SSH over high latency links is using SSH+mosh already anyway.

oefrha 1y ago
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.
- esseph 1y ago
  "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.
  - oefrha 1y ago
    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.
    - esseph 1y ago
      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.
  - jeffhuys 1y ago
    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.
    - esseph 1y ago
      You know what has a "huge downside"? Radiation therapy. Not a scroll back buffer workflow issue.
lxgr 1y ago
If you believe that, you clearly haven't had to work with mosh in a heavily firewalled environment. Filtering inbound UDP on one side is usually enough to break mosh, in my experience. Maybe they use better NAT traversal strategies since I last checked, but there's usually no workaround if at least one network admin involved actively blocks it.

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.

esseph 1y ago
"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.
- oefrha 1y ago
  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.
  - esseph 1y ago
    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.
- jeffhuys 1y ago
  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.
  - esseph 1y ago
    You know what has a "huge downside"? Radiation therapy. Not a scroll back buffer workflow issue.

lxgr 1y ago

If you believe that, you clearly haven't had to work with mosh in a heavily firewalled environment. Filtering inbound UDP on one side is usually enough to break mosh, in my experience. Maybe they use better NAT traversal strategies since I last checked, but there's usually no workaround if at least one network admin involved actively blocks it.