Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mosh

jefftk.com

Post reply on HN
Print view View original

101–110 of 152 posts

Re: Mosh

#101

Post by X6S1x6Okd1st »

CJefferson wrote: post #76
polote wrote: post #53

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…

Drawbacks: - No commits in github in over 9 months, PRs and issues are stacking up. - I've had friends report clipboard broken in latest Mac OS X version. Don't get too attached to mosh.

New commits are not a necessary part of good software. Your second point is a much better point

Re: Mosh

#102

Post by okhan »

I used to live in SE Asia and was regularly SSH-ing into servers running in the US. The latency was awful. Mosh made everything far more pleasant. The only downside is that you have to install extra software server-side.

Re: Mosh

#103

Post by kitotik »

clarry wrote: post #58
polote wrote: post #53

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?

Not OP, but I frequently code remotely from an iPad and from laptops that may not have a full dev environment available.

It didn’t even occur to me that this was a foreign concept to folks!

Re: Mosh

#104

Post by alexhutcheson »

If you're an Emacs user (like the author apparently is), I would recommend trying out TRAMP: https://www.gnu.org/software/tramp/#Overview

Emacs will transparently handle SSH connections and let you edit remote files as if they are local. Just as importantly, if you run commands like M-x compile or M-! (aka M-x shell-command) while you're looking at a remote file, Emacs will "do the right thing" and run the process on the remote machine, rather than on your local machine.

This gives you the benefits that the author mentions about mosh - characters will appear as you type without waiting on a server round-trip. Additionally, you also won't have to wait for a server round-trip to see your cursor jump to the minibuffer, which the author mentions as a pain point.

If you need to run things at the command-line, you can do so in a "shell" buffer via M-x shell (or M-x term if you need to run something curses-like).

The major downsides:

- I/O operations (including opening and saving files) can be much slower than if you were running Emacs in a terminal, because the bytes need to be sent over SSH.

- It's not always easy to keep track of which buffers are "remote" and which are "local", so sometimes you'll run a command and it will run a process on a different machine than you expected.

Re: Mosh

#105

Post by rkangel »

grogenaut wrote: post #100
rkangel wrote: post #93

Earlier quoted context omitted.

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.

That doesnt answer why. I have a table saw that works really well, doesn't mean I use it all day every day.

That's a good point that I didn't make clear, in my head it was implied from context.

Using VSCode in this way makes you much less dependent on good SSH. When using emacs in a terminal over SSH, your whole UI is being rendered over SSH and any latency or packet loss is going to affect UI feedback and rendering.

If you use VSCode Remote-SSH, you UI is rendered locally, so typing and editing work smoothly, and you don't really notice a bit of network latency on a request to "find in files" for instance.

Running your emacs locally and then using Tramp to edit remote files (as suggested elsewhere) gives you some of that benefit but is a much more limited development experience, and (in my experience) flakier.

Re: Mosh

#106

Post by Eldt »

X6S1x6Okd1st wrote: post #101
CJefferson wrote: post #76

Earlier quoted context omitted.

Drawbacks: - No commits in github in over 9 months, PRs and issues are stacking up. - I've had friends report clipboard broken in latest Mac OS X version. Don't get too attached to mosh.

New commits are not a necessary part of good software. Your second point is a much better point

It kind of is when the issues continue to climb as suggested in the post you responded to

Re: Mosh

#107

Post by X6S1x6Okd1st »

Eldt wrote: post #106
X6S1x6Okd1st wrote: post #101

Earlier quoted context omitted.

New commits are not a necessary part of good software. Your second point is a much better point

It kind of is when the issues continue to climb as suggested in the post you responded to

I used to use mosh fairly extensively and only really had two problems I wanted solved. I didn't care enough to learn to code them myself so I called it good enough.

Re: Mosh

#108

Post by neurostimulant »

I've been using Mosh for years and it's one of the first things I install on all servers I setup. I also install the client on my android phone via Termux and it's absolutely great on laggy and unreliable mobile connection. My only gripes are the lack of scrolling buffer (need to remember to use tmux) and the lack of support on iTerm's fancy tmux integration. Other than that it's an absolutely fantastic tool!

Re: Mosh

#109

Post by mprovost »

Dylan16807 wrote: post #60
mprovost wrote: post #17

Earlier quoted context omitted.

Terminal emulators (xterm, iterm2 etc) are emulating something like a VT220 which were called "glass terminals" to differentiate them from earlier terminals which were keyboards attached to printers. So there's still this underlying concept of an endless spool of paper, and that's what you see when you scroll back. A scroll is literally a long piece of paper. Anyway that means if you cat some long file and then hit c…

Mosh could easily load the skipped-over lines in the background. It's not incompatible with the design. It just requires a developer to put in the effort.

Can it though? How can a program manipulate the scrollback buffer of the terminal that it's running in? Other than by printing more output. But once it's updated the current line, it can't go back and add more lines - those lines have already been printed on the scroll.

Re: Mosh

#110

Post by AdamGibbins »

jefftk wrote: post #54
kbumsik wrote: post #8

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. When this is not so appealing to desktop users, it is a godsend feature for laptop/mobile users. Especially, if you are an iPad user you should try Blink shell app [1] with Mosh. This combination turns the iPad your favor…

(author) I was already using tmux for session persistence, so the local echo and handling of congested networks were the two features that made me wish I'd switched to mosh earlier.

mosh does persistence better, if you're connected to tmux over SSH it'll still disconnect as your IP changes on a roaming connection (like it does on my daily commute on the train). mosh does not, it stays no matter what. Also no need for autossh or similar to reconnect when you unsuspend your computer.
Post reply on HN