Live data from Hacker News

Mosh: the mobile shell

mosh.mit.edu

11–20 of 153 posts

Re: Mosh: the mobile shell

#11

>SSH waits for the server's reply before showing you your own typing. That can make for a lousy user interface. Mosh is different: it gives an instant response to typing, deleting, and line editing. This seems asinine. If latency is an issue I want to know it, not be fooled into thinking my input is being interpreted correctly by 'predictions'. Does this mean when I hit 'jjjjjll' in vim, I'm going to see this underli…

Only if your recent keystrokes have been getting echoed, and if you haven't done something that might disrupt echo. > Predictions are done in epochs: when the user does something that might alter the echo behavior — like hit ESC or carriage return or an up- or down-arrow — Mosh goes back into making background predictions until a prediction from the new batch can be confirmed as correct.

Yeah, this offends me - I want my terminal to have simple, predictable behavior, not be trying to reason about what the shell process is up to. If it has some predictive model, I have to worry about my predictive model (expectation of what happens when I hit a key) being in conflict.

Re: Mosh: the mobile shell

#12
I use mosh daily and love it. It's great for moving around the office and maintaining a connection - no accidental hups, no real need to use screen or nohup.

My one beef with it is that it effectively defeats my terminal emulator's scroll bar. Need to scroll back the output? Nope. You have to use less or more profusely.

Re: Mosh: the mobile shell

#13

>SSH waits for the server's reply before showing you your own typing. That can make for a lousy user interface. Mosh is different: it gives an instant response to typing, deleting, and line editing. This seems asinine. If latency is an issue I want to know it, not be fooled into thinking my input is being interpreted correctly by 'predictions'. Does this mean when I hit 'jjjjjll' in vim, I'm going to see this underli…

If that's what you want, then don't use predictive echoing (or w/e it's called exactly).

I've been using Mosh for years on spotty connections and this feature alone is an absolute game changer. Sure, when you're trying to `jjjj` and your network hiccups, it may look weird for a moment, but no more weird than not seeing any input imo. And when you're not `jjj`ing, but instead typing in edit mode, you don't notice anything, it's flawless.

Also, Mosh shows a blue banner on top if there is prolonged connectivity issues, so it's not like it is tricking you or anything. The feature merely smooths out the UX, and it does so amazingly well.

Re: Mosh: the mobile shell

#14

Earlier quoted context omitted.

Only if your recent keystrokes have been getting echoed, and if you haven't done something that might disrupt echo. > Predictions are done in epochs: when the user does something that might alter the echo behavior — like hit ESC or carriage return or an up- or down-arrow — Mosh goes back into making background predictions until a prediction from the new batch can be confirmed as correct.

Yeah, this offends me - I want my terminal to have simple, predictable behavior, not be trying to reason about what the shell process is up to. If it has some predictive model, I have to worry about my predictive model (expectation of what happens when I hit a key) being in conflict.

You really don't have to worry about that, imo. The predictive feature doesn't overlap connectivity issues long enough for you to ever wonder "Am i connected or not"?

Not to mention, it shows you in two ways that you have connectivity issues.

1. All echoing prints underlines, so you always know if it's predictive output or not. 2. Any prolonged connectivity issue displays a blue bar at the top of the session, showing how long you've been disconnected for.

edit: And of course, you can simply turn off predictive echo if it's a feature you hate. but man oh man, is it something to love, imo.

Re: Mosh: the mobile shell

#18

Earlier quoted context omitted.

Only if your recent keystrokes have been getting echoed, and if you haven't done something that might disrupt echo. > Predictions are done in epochs: when the user does something that might alter the echo behavior — like hit ESC or carriage return or an up- or down-arrow — Mosh goes back into making background predictions until a prediction from the new batch can be confirmed as correct.

Yeah, this offends me - I want my terminal to have simple, predictable behavior, not be trying to reason about what the shell process is up to. If it has some predictive model, I have to worry about my predictive model (expectation of what happens when I hit a key) being in conflict.

As opposed to having your non-predictive model be in conflict, because your connection decided to space out for a minute so you don't see any results from any of your typing?

Re: Mosh: the mobile shell

#19

I use mosh daily and love it. It's great for moving around the office and maintaining a connection - no accidental hups, no real need to use screen or nohup. My one beef with it is that it effectively defeats my terminal emulator's scroll bar. Need to scroll back the output? Nope. You have to use less or more profusely.

My solution to that is to run mosh on top of screen. tmux would also work.

Re: Mosh: the mobile shell

#20

"Why use this instead of GNU screen?" The low latency features really set this one apart. The smart local echo (it underlines unconfirmed predictions) make it much nicer to use over laggy mobile networks.

I would say they're mostly orthogonal. I use mosh and screen.
Post reply on HN