MIT's mind-reading Mosh pits itself against SSH daemons Researchers at MIT have refined the Secure Shell network protocol and boasted their replacement system overcomes some of SSH's more annoying drawbacks. Mosh (aka mobile shell) is designed to keep connections alive when clients roam across Wi-Fi networks or switch to mobile data connections. In addition the revamp eliminates …
For someone who has tried to do command line stuff to a home or hosted server from a mobile phone or netbook while on a train or in a carpark using 3G data it seems to me a bit of both, and a mismatch between the 2. It's useful to know what you have typed more rapidly on a crummy soft mobe keyboard before you press the enter key, but really there should be no need to have to wait for remote echo until you get to the enter key stage most of the time. To be really useful, this one would need to know when you are using an unbuffered input application over SSH, e.g. using Mutt or Vim, where single keystrokes have effects on the remote application without need for the enter key, as opposed to when you are using buffered input applications (e.g. typing bash commands), and can delay obtaining remote feedback until the command is entered.
"The technology predicts what users are about to type to provide intelligent local echo and line editing of keystrokes, as explained in "
Err , it already knows what the user has typed because its just intercepted the bloody keypress!
ITYM it predicts what the server will do with that particular keypress and what the server will
reply with - if anything.
Personally I think its a solution looking for a problem - either do old fashioned local echo (echo everything and to hell with it for line buffered programs) or don't bother doing it at all. I want to know if the remote machine is getting my data , what use is local echo on the client if the data is going nowhere?
Yeah, uhm, no. As in, sounds good, until you realise that for some tasks it can be downright disastrous to not know for certain what the state of the machine on the other side is. 0.9% is pretty good when the stakes are low, but not nearly good enough when they're high. For the sysadmin working on a live system under dire pressure it's one more thing to realise and deal with lest it bite you (and possibly much more) in the arse. So, well, good show, but please do now find a way to get half as good or better results without the uncertainty, lads.
+1 for misinterpreting an input, imagine the difference between rm -rf / and rm -rf * for example, yes you should be very careful if you were using root or sudo etc however sh*t happens!
Big corporates have systems that just can't go down without costing huge amounts of money if not worse. Imagine if something like this took out something important such as systems monitoring 999 networks etc.
I can see the advantages for some uses but a good proportion of them can be gained using screen* along with SSH.
Plus is it really the best business plan to be reliant on an admin who is connecting via 3g / dodgy wifi?
*http://www.ibm.com/developerworks/aix/library/au-gnu_screen/
You know how it goes: You normally work on-site, but just exactly when you're away something happens that causes immediate need for double-quick fixing, nobody else is available*, you can't hop over and will simply have to make do with whatever's available. Which might end up being, oh I don't know, a freshly dusted acoustic coupler, and a phone line made out of repurposed telegraph wire.
Right then you'd like some extra (forward) error correction and you really really don't want DWIM behaviour (look it up in the jargon file). Sure the scenarios in which it all comes together to bite you are far-fetched; didn't say it wasn't. But for "mission critical" type use, the things admins do, it is a consideration. So if the smarts are on by default, it's yet one more thing to not forget to turn off at the right time.
* That is of course the real problem.
... too much networking infrastructure is "web-optimised" now-a-days. As in, (barely) fit to transfer a couple webpages and all the other things needed to display them (html and css files, js libraries, pictures, gazillions of avatars, live ajax updates, rss feeds, json things, xml blobs, and so on), but completely useless for timely delivery of a few small packets. Nice to see tech to counteract that a bit, but I'd wish the assumptions behind the networks weren't so rotten.
Still getting used to it but it is great on a train. You can turn off the predictive bit and just use the mobile connection part which automagically reactivates the connection should it drop.
It's kind of like using SSH with screen but without having to reattach to the screen session after logging in again.
Local echo on SSH is okay but doesn't work so well with things like vim. Also, Mosh never predicts an Enter keystroke.
Could have done with this 20 years ago when I was trying to do remote support over a modem on international phone lines to systems in Saudi Arabia... 300 baud and constant drops didn't make for quick ticket resolution!
"Could have done with this 20 years ago when I was trying to do remote support over a modem on international phone lines to systems in Saudi Arabia... 300 baud and constant drops didn't make for quick ticket resolution!"
Or even I could have done with this ten years ago while I was doing remote support FROM Saudi Arabia, dialling up to a 4800 baud modem.
Not to mention the days of remote shell logins using my HP48 for a console.
God those were the days!
I don't need connections to be alive, I use screen.
"when clients roam"? There's MobileIP for that.
"UDP-based protocol"? Another fail, because I cannot channel it through ssh port forwarding/socks.
And usually I can get the job done via crappy GPRS link using ssh and screen, so thankyouverymuch, thanks for trying anyway.
Sounds interesting, I myself have found it challenging to try and use an interactive SSH session when the latency goes through the roof. And 3G is notorious for that, I've had some cases where a 33.6kbps line has been easier to use than the 3G link on latency alone. (Yes, Australia's Department of Defence are all for bleeding-edge network technology...33.6kbps PSTN is where it's at apparently.)
I think it should be possible to disable the feature, on the fly if necessary. There are times you'll want it, and times you won't, and it really needs to be a user decision as to which is which, as the software almost certainly won't have the intelligence to distinguish between the two.
Now I'm waiting to see what Microsoft's equivalent solution for their equivalent protocol (RDP) is, as that's horrid to use over a high-latency link.
Yes, most of the problems regarding "far" remote access are solved now, with screen and/or other tricks that were more prevalent a decade ago. Typing with 100ms+ feedback indeed needs some getting used to, after you were exposed to this century's LANs. It seems to be a skill these days, just like talking while hearing your own voice delayed. Telnet, that we all forgot, even had a linemode (local echo mode), that can be emulated:
rlwrap ssh $* "zsh -i"
However, the technology still sounds interesting, it appears it could be more useful than a mix of other solutions for related problems... I'm still annoyed by local uncoordinated wi-fi access points, just to make it easy for people to connect to the "closest" one for no reason. Such design decisions still make command line access awkward at times.
I agree with many of the points that have been made, but given the state of network protocols and application software I think an attempt to work around the issues to provide a streamlined user experience is warranted here.
Sure you can use screen and ssh, but even typing "ssh" again every time your link dies, waiting for it to login and bring your screen session back up, is a jolly nuisance. The point of this thing is that it avoids these little hassles.
I will have to reserve judgement on the response prediction until I try it, and I agree that we *should* simply be using line-oriented terminal disciplines with local editing if that's what we want, but given that most applications use readline and run the the terminal in raw mode, what can you do? At least these guys are trying to come up with a practical solution. Not the best solution, but one that will actually work with 90% of the software out there and tide us over until someone gets around to re-engineering the entire software stack.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
