Hacker News new | past | comments | ask | show | jobs | submit login

I find switching cell phone towers to be something that happens sufficiently rarely that it doesn't matter if it skips for a second. I am willing to believe your mileage may vary. Really, if you are doing tons of work from cell phones, you may even prefer the mosh UDP protocol for its packet loss handling anyway: people should try it.

However, my experience has been that most of the people I have had go "omg, mosh sounds awesome!" are actually trying to use it from their laptop (not the phone) as they move from home to the office: mosh is not just overkill for that use case, it actually makes some "incorrect" tradeoffs. Maybe with an occasional "roaming on 3G" usage, but "from the coffee shop" not "in a train moving at 300km/h.

As for the mis-prediction issues, I guess we'll just have to differ on that one: if you like it, that's great, but the people I've talked to found the weird jerkiness that you get whenever you hit a prediction boundary awkward and jarring, especially as you end up with a boundary whenever you hit enter. I talked to the developer about the issue, and it didn't seem like something that could be worked around (semantically, I'm not even certain it is possible).

(They also may have fixed some of the more insane "visual artifacts" mosh was getting when I was using it: every time you'd hit enter in bash it would do this totally-wrong prediction of "take some characters and move them up a line, but not all of them". I thereby purposely didn't list it in my "downsides" list as the developer seemed to think that was fixable, unlike the mis-prediction boundary problem, but it certainly drove me crazy while using mosh.)




My number one use case is tethered mobile phone on a train. For everthing else I just use vanilla ssh and screen. You are right that if you just need mobility between office1, office2, coffeeshop, and home ssh with screen is probably all you really need.

I don't think mosh's developers really promote it as anything more than an experiment on improving shell connections on a high packet loss high latency mobile data plan.


I absolutely 100% agree with your final sentence: it isn't like I'm saying "the mosh people are perpetrating a plot to confuse people into doing this thing that is bad for them, a use case that no one in the world would ever have... (and trains are a communist plot: I doubt they exist)" ;P. In fact, I found the actual research paper that this was all for quite fascinating, and was glad to get a chance to talk directly to the author/developer about what he discovered.

I simply have been part of a ton of conversations about mosh, and I know that a lot of people who see mosh don't know what the design tradeoffs are towards the "high-latency w/ packet loss" use case were, and often are just looking for a tool that lets them move their shell around "between office1, office2, coffeeshop, and home".

ssh+screen by themselves simply is not a sufficient solution, as it doesn't automatically reconnect, so you either need to know how to setup autossh (which isn't marketed or optimized for this use case) or realize that the shell script isn't that difficult to build: I'm just trying to provide this information to people. At numerous points here I have been very clear: if you have interest in the features that you can only get from this integrated protocol setup, you should definitely try and possibly choose to use mosh.


I use mosh in the train = lot of cell tower switches. I've very little use for it from the laptop on a "real" connection".




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: