Hacker News Reader

Comment by polote | Hacker News Reader

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 after hibernation your session is preserved

Drawbacks:

- you can't scroll , but if you use tmux then it is possible . I've tried using Eternal terminal, as it allows to scroll but it doesn't perform well at all on laggy connections

- You can't detach and re attach mosh connections (same for ET)

- I'm not sure it is possible to preserve middle-click copy/paste (at least I've not managed to make it work)

- time to connect is a bit longer than normal ssh

View on HN

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 you run tmux on the remote server. I really wanted to like/use mosh, but there's too many issues of reality that it can't gloss over.

If you're just maintaining basic SSH sessions into remote servers, then it's great. But if you have a nice, interactive remote development environment then you still get the same lag and latency issues.

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 case, using a mosh client makes me less likely to throw my laptop or iPad down in anger every 5 minutes.

>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

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

https://blink.sh/

This sounds like a joke but is entirely serious:

How is mouse support in Blink? I've been searching online and can't find a good answer. I regularly use the mouse in Terminal.app to manipulate Tmux windows and move around in the Micro text editor. I am curious about Blink, but hesitant to drop $20 if it turns out it doesn't work the way I need it to for terminal usage.

It isn’t great at the moment. Something broke in the recent update to break text selection, which is what I was trying to use a mouse for. But, the author is working on a fix. I don’t know how good the mouse works uses other than selection, but mouse support in general isn’t great at the moment.

But Blink is the app I use for SSH/mosh on the iPad too.

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

That basically describes TRAMP mode, right? It works well.

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.

Or, get so attached that you become the new maintainer either amicably or by fork.

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.

Why isn't mosh being maintained?

What does mosh have to do with the clipboard?

I went and found the issue. Some terminal apps interact with the system clipboard and mosh isnt forwarding this correctly.

https://github.com/mobile-shell/mosh/issues/967

Why do you code on a remote server?

I'm creating a PoC (well more the MVP of a company) and this includes a scrapper which requires a very reliable connection, which I don't have locally

There are solutions to mount the remote filesystem locally and use any regular code editor

There are also editors that can use a plenty of various protocols to read & save remote files while performing editing locally.

And most of them either rely on SSH+rsync, syncthing, or something along those lines - in other words, tools that will sync the files reliably, even on bad links...eventually. Never have I seen a backend that's built for editing...the remote-mount abstraction mostly works, but leaks specifically in these edge cases.

You can code locally, push to a repository, and have the changes almost instantly on your server ready to be run.

yes, i prefer to save those 10 seconds as I do that a thousand times a day

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.

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 makefile depending on which project I am working on. If I try to compile locally based on remote files, my compile times go through the roof. I suppose I could have opened an ssh session in which to run make, but it was easier to open emacs remotely.

The other advantage is that I could use tmux+emacs to have everything remote, and to connect to that same session from multiple computers. A typical day during an experiment might have me start in an office, later head to an experiment monitoring room, and later head down to the experiment vault to see if an issue is being caused by hardware. With remote editing, I could have the the entire session, including any files that I have already opened, no matter where I am physically located.

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.

Tips if you're writing your own elisp:

- If you're walking the filesystem, make sure you start from the "default-directory" variable.

- If you call other programs, make sure you use "process-file" (for synchronous processes) or "start-file-process" (for async). Using "call-process" or "start-process" unfortunately won't do the right thing, but the two functions I mentioned are mostly drop-in replacements.

Those sound pretty useful, and I will need to try those out. I used (file-name-directory buffer-file-name) as the base for walking the filesystem, which may have caused some issues. I also have a cd in the shell command passed to compile, which probably doesn't play nicely.

Unfortunately, my current job doesn't use Linux as much, and so it has been too long since I've spent time improving my .emacs file, as it is only home projects at this point.

This is actually the root of my italicized "may"; I've seen Tramp do surprising miracles in terms of working remotely with things like this, but I've also seen other things not work because of the various complexities involved. It's at least worth a try, but I've never actually learned elisp to speak of so I have no idea how hard it would be to fix any issues you may find.

I coded PHP like that a long time ago. There was a great editor, maybe called E or something to that tune that would made it seem as if your files were right there locally.

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.

why do you work remotely at all instead of just doing it all on your pc?

There are a number of situations where you don't want to compile or run code on the same machine that you develop on. Use of containers or VMs can mitigate a lot of them (differing environment or platform), but not all. I have 3 different causes at different times:

Developing a python framework for running system tests on hardware. This can only be run on the machine that is in the lab connected to the hardware. For various reasons related to the network latency of being at home, the easiest way to iterate on that is to checkout and develop on the machine itself.

Developing on Linux, from home. My work laptop is a (small) Windows machine. Normally it doesn't get heavy use - some presentations and email reading when I travel. Now I'm WfH it's my primary machine. By SSHing to my Linux desktop at work (for terminal and for VSCode), I get the development experience of Linux on my Windows machine (there are some other benefits to do with that machine being on the right network and close to the stuff it needs to talk to a lot).

Developing FPGA code. This requires a hugely powerful machine to compile on if you want a reasonable compile speed. The Hardware group have a few specialised machines for this that are shared, so that we can have laptops and get the benefit (also means you can leave a synthesis going overnight/over the weekend easily).

I usually don't even have a PC when remote, it's an Android phone. And when I do, it's a ~2005 x86 netbook - good enough for a thin client, not powerful enough to run the dev stack (which is x64 anyway).

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 "locally".

Yes, this means I need to be online to work, but almost nobody works offline anymore - between googling issues, downloading/updating dependencies, and browsing while compiling, having an internet connection is assumed.

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.

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.

You run your IDE over VNC?

I've been wanting to try out remote developing for multiple years now, it would allow me to get an iPad with a perfect battery life or an Macbook Air that would tag along all day without charging. But because I cannot work with vim/emacs and my IDEs (IntelliJ) do not support anything like remote development I am stuck with a huge Macbook Pro including a battery draining IDE that cannot be ran remotely. VNC added too much lag for me to use all day.

I used to use Eclipse over X11 over Wifi within my house and it worked fine, no noticable latency.

Latency is a problem indeed, I am lucky to be close to work and have massive bandwidth all the way to my dev box. Without that the experience is pretty poor, and I used to make it work by dropping bit depth to the minimum bearable level.

This is why I love Visual Studio Code. With SSH remote connection it's basically the best of both worlds.

mosh is very useful for intermittent connectivity. Anytime I had to rely on spotty 2G/3G/wifi, the usual workflow "work locally ; git push" failed, as it's TLS/TCP and not resumable. Had to autossh+rsync the diffs out onto a stable host in the cloud, and then essentially worked from there.

Also, I have a mosh client on my smartphone; setting up the dev environment there would be a bear. Essentially the mainframe model ;)

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!

He might be asking why your laptop does not have a full dev environment.

Space? Performance? Builds typically perform best directly adjacent to storage, and if you're working with a large project syncing that back and forth may be slow.

Ah fair enough.

As someone who’s been fairly mobile/nomadic most of my career, I have always enjoyed the thin client approach.

I can get many more years of service from my client hardware when offloading the bulk of compute, storage, and stable bandwidth needs to beefy servers.

I’ve found that it’s just generally more economical and efficient this way.

Plus, the few times I’ve had laptops die, get stolen, damaged etc to have a much lower impact when they don’t have anything all that important on them.

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.

Since no one has put this reason out there: to have one's development OS mirror production[1]. IME, the "develop on Mac, break on Linux" problem is not uncommon, even with high level abstractions. Plus, things like docker are native.

This can be all done in a VM, of course. I personally like the remote server, especially since they can be spun up so easily with cloud services now.

[1] - Though sometimes that's impossible. I.e. embedded.

My work prefers their IP be kept inside their network, so to speak. Yes, nothing really prevents me from cloning my work git over the VPN and doing the work locally, except for norms and limited local disk space.

My laptop does not have enough disk space to check out my repository.

Also, security policies. But I like the first reason more.

Then again, my laptop won't run friggin mosh, because of security policies.

Because I can literally walk away in the middle of a debugging session, grab any random notebook in the house, travel to Djibouti and resume exactly where I left off (ok, replace Djibouti with a random coffee shop). It has completely changed how I work and I love it (mosh + tmux = <3).

ADD: I do switch frequently between my desktop and multiple notebooks. Working this way means I can have a beefy/noisy development server and a light & quiet notebook which just needs mosh.

I detach/reattach mosh sessions all the time, using the excellent dtach tool.

Reply on news.ycombinator.com