91–100 of 152 posts
> This is accomplished using a new protocol called the State Synchronization Protocol, for which Mosh is the first application.
This protocol has never been documented, making it "only" rather than "first", and once again putting the world in the position of one particular implementation's foibles being the only "specification".
Earlier quoted context omitted.
> The article misses the other great feature of Mosh: It never get disconnected, regardless of the client's state (IP address change, or device sleep mode), and you will never loose terminal sessions. I almost switched to mosh in the past while searching for this kind of solution to short-living ssh connections. But I've finally never made the jump, re-launching ssh/tmux being four keystrokes only (up+enter x2). Not…
Does the keepalive functionality in ssh help here? Like: ssh -o ServerAliveInterval=5 -o ServerAliveCountMax=1 $HOST
Earlier quoted context omitted.
Why do you code on a remote server?
Pretty common for physics experiments. My computer has neither direct access to the data being collected, nor the processing power to deal with it. Sure, I could code locally, push to a repo, and then test remotely, but the additional turnaround would be obnoxious. Far easier to open up a terminal and run emacs remotely.
As someone who codes on a remote server the whole day, mosh is absolutely necessary and it is fantastic Advantages: - you dont see any lag when you type, it is exactly as if you were on your local machine - when network disconnect, the terminal freeze and when network is up again, the terminal becomes interactive again preserving everything in between - connection is preserved as long as the terminal is open, so even…
Why do you code on a remote server?
Also, I have a mosh client on my smartphone; setting up the dev environment there would be a bear. Essentially the mainframe model ;)
Mosh is fantastic. And as an old-timer I am rather amused how some good ideas from a while back make its way into current hot tech again. After all, the IBM 3270 terminal was specifically designed to not transmit one character at a time. Thanks to this, a 1970s-era IBM 3033 mainframe fitted with only 16 MB of main memory was able to support up to 17,500 3270 terminals. (see https://en.wikipedia.org/wiki/IBM_3270 )
As someone who codes on a remote server the whole day, mosh is absolutely necessary and it is fantastic Advantages: - you dont see any lag when you type, it is exactly as if you were on your local machine - when network disconnect, the terminal freeze and when network is up again, the terminal becomes interactive again preserving everything in between - connection is preserved as long as the terminal is open, so even…
But you do see lag - if you have auto/tab-complete, history search, command suggestions, etc, those all will still lag because they are waiting for a response from the server. The lag that is eliminated is the local echo of characters as you type, as mosh is sending those asynchronously in the background. If you have fancy, more interactive prompt/cmdline on the remote server then you'll still see the issue. Ditto if…
The lag is something that I can deal with. For me, the killer feature is the automatic reconnects. I usually only use mosh when I’m traveling and at conferences. In that scenario, I’m either using my iPad (with keyboard) where the client might be killed anytime I switch apps or I’m using the conference WiFi, with is always spotty. In either case, using a mosh client makes me less likely to throw my laptop or iPad down in anger every 5 minutes.
Earlier quoted context omitted.
If you're using emacs, you may be able to use Tramp to remotely access the file. It depends on how IDE-ish you've got your emacs set up. As long as you've got reasonable latency I find that much nicer. (If you already know, well, I'm sure someone else just learned something today.)
Oh absolutely. I like using tramp to edit individual config files remotely. If there is one particular data acquisition computer that is performing incorrectly, I can quickly open up that file to compare, without needing to leave the editor. The issue I ran into with editing code through tramp is the integration with make. I use `M-x compile` to compile from emacs, with a few modifications to find the appropriate mak…
Docs are here: https://www.gnu.org/software/tramp/#index-compile
Mosh’s non-support of scrollback was always a deal-breaker for me. iTerm2’s tmux integration is pretty nice, though. Apparently there is iTerm2+tmux+mosh dark magic if one is into that kind of thing: https://www.gaeblogx.com/2017/10/09/Remote-Shell-Session-Set...
Earlier quoted context omitted.
Pretty common for physics experiments. My computer has neither direct access to the data being collected, nor the processing power to deal with it. Sure, I could code locally, push to a repo, and then test remotely, but the additional turnaround would be obnoxious. Far easier to open up a terminal and run emacs remotely.
I am a former Emacs user and now a VSCode user. VSCode has great 'remote SSH' capability - running a whole session locally on a codebase that is remote. Everything works seamlessly - find in files, code navigation etc.