Live data from Hacker News

Mosh

jefftk.com

111–120 of 152 posts

Re: Mosh

#111

Earlier quoted context omitted.

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…

If you are in a buffer for a remote file, then M-x compile should run make on the remote machine. Docs are here: https://www.gnu.org/software/tramp/#index-compile

Ooh, nice. I'll have to take a look at it again. That may be something that I accidentally broke in customizing my environment. I bound `C-c C-c` to look for either a Makefile or a SConstruct in the current directory, walking upwards up the hierarchy until one is found, then to launch either make or scons depending on which one is found. That may have been the source of my remote issues.

Re: Mosh

#112
post #58

Earlier quoted context omitted.

Why do you code on a remote server?

Because my local server is my laptop at home with cheap ISP bandwidth; my remote server is in a data center with high-speed bandwidth and much more CPU/RAM/SSD than my laptop. Why do you suffer to use a local server/internet for development? I've been using the "laptop is a dumb terminal" paradigm for many, many years and I've avoided a lot of headache that I've seen in others trying to get everything to work "locall…

Why not write code locally and push to build/test remote?

I feel like this is the best of both worlds- but it does require some up front effort to build the pipeline

Re: Mosh

#113
post #97

Earlier quoted context omitted.

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…

But what’s the alternative? Local development with syncing back to a server? 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…

>But what’s the alternative? Local development with syncing back to a server?

I'd say this is a perfectly fine solution for a lot of cases. Not all, of course, like your iPad one sounds a great fit for mosh (and I'm gonna try it out!) But even a RaspberryPi can power a really powerful terminal.

You can use sshfs[0] to mount a remote drive over ssh. Obviously there will still be some lag - `ls` will require a round trip - but your local terminal will be much snappier.

[0] https://github.com/libfuse/sshfs

Re: Mosh

#114
post #112

Earlier quoted context omitted.

Because my local server is my laptop at home with cheap ISP bandwidth; my remote server is in a data center with high-speed bandwidth and much more CPU/RAM/SSD than my laptop. Why do you suffer to use a local server/internet for development? I've been using the "laptop is a dumb terminal" paradigm for many, many years and I've avoided a lot of headache that I've seen in others trying to get everything to work "locall…

Why not write code locally and push to build/test remote? I feel like this is the best of both worlds- but it does require some up front effort to build the pipeline

Yes, that works too, especially if you're using graphical IDEs/tools for development.

Re: Mosh

#115
post #113
post #97

Earlier quoted context omitted.

But what’s the alternative? Local development with syncing back to a server? 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…

>But what’s the alternative? Local development with syncing back to a server? I'd say this is a perfectly fine solution for a lot of cases. Not all, of course, like your iPad one sounds a great fit for mosh (and I'm gonna try it out!) But even a RaspberryPi can power a really powerful terminal. You can use sshfs[0] to mount a remote drive over ssh. Obviously there will still be some lag - `ls` will require a round tr…

Blink is a great and open source SSH/Mosh client for iPad.

https://blink.sh/

Re: Mosh

#116
post #58

Earlier quoted context omitted.

Why do you code on a remote server?

Because my local server is my laptop at home with cheap ISP bandwidth; my remote server is in a data center with high-speed bandwidth and much more CPU/RAM/SSD than my laptop. Why do you suffer to use a local server/internet for development? I've been using the "laptop is a dumb terminal" paradigm for many, many years and I've avoided a lot of headache that I've seen in others trying to get everything to work "locall…

For me the axis is not computer quality, it's IDE quality. My productivity in a large codebase jumped 10x when I switched from emacs to IntelliJ (for Java). Going back would be like blindfolding myself after I grew up blind and got my eyesight restored once.

Remote development is tricky indeed. Many people run the IDE locally and use its remote development functionality. I run it remotely over VNC.

Re: Mosh

#117
post #58
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?

[deleted]

Re: Mosh

#118
post #58
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?

I want to use Windows on my local machine, but my code (deep learning models) runs faster, and is better supported, on a linux server.

Re: Mosh

#119

Earlier quoted context omitted.

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.

Even if it had no way to communicate the lines to the local terminal, it could still load them and handle the scrollback itself, locally. I think that's what the eventual plan is, too.

But it wouldn't be exceptionally difficult to figure out some way to stuff lines into the scroll buffer. Especially if you got a mosh-aware terminal.

Re: Mosh

#120
Mosh is great, but it does not support port forwarding. For some people, including myself, this is a deal breaker. It has been an open issue/feature request since 2012[1] and even has a ~600 USD bounty on it[2].

[1] - https://github.com/mobile-shell/mosh/issues/337

[2] - https://www.bountysource.com/issues/4471419-ssh-port-forward...

Post reply on HN