Live data from Hacker News

Mosh

jefftk.com

141–150 of 152 posts

Re: Mosh

#141
post #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...

I would also love this feature, but I understand the argument that it's major feature-creep for this project - as I understand, with mosh as implemented it would be difficult to integrate. IIRC they would have to roll some kind of TCP over UDP? I'm not sure, it's been a while since I looked at it. I'm willing to accept a good tool missing features over a poorly maintained tool that at some point had all the features I care about.

And realistically $600 is a pittance compared to the long-term cost of maintaining a feature that has the potential to dramatically increase the size of the code base.

Re: Mosh

#142
post #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...

EternalTerminal[1] was mentioned in a comment below. It supports port forwarding, and other goodies like native scrollback, at the cost of latency on laggy connections (because it doesn't do full terminal emulation). If that tradeoff sounds good to you, try it!

[1] https://eternalterminal.dev/

Re: Mosh

#143

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…

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.

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

Re: Mosh

#144

Earlier quoted context omitted.

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 r…

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.

Re: Mosh

#145

Earlier quoted context omitted.

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'…

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

Re: Mosh

#146
post #63

Earlier quoted context omitted.

If I just want a persistent connection, then the nested tmux that takes 2+ useless lines in the bottom already falls into the "it doesn't work well" category. And I what I said that the problem was the moment I have to have different tmux config for every machine, just like she/he is doing.

I guess I just don't understand why you need the tmux command key at all. If you pretended it didn't exist, what feature would you be losing out on that mosh has? And when you're setting up a server it's easy to turn off the tmux status bar.

indeed. the only thing i need to do is copy a config file to set up the command key. the main use of the command key is to switch terminals and to access scrollback. beyond that, the key is rarely needed. working in any terminal is the same no matter how deep the nesting. i don't notice it.

the multiple toolbars don't bother me either. they can serve as a visual aid to recognize where i am. each terminal looks different. but in reality i don't pay much attention to them.

Re: Mosh

#147

Earlier quoted context omitted.

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'…

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).

Re: Mosh

#148
post #106

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

Why isn't mosh being maintained?

Re: Mosh

#149

Earlier quoted context omitted.

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.

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.

Re: Mosh

#150

Earlier quoted context omitted.

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.

Post reply on HN