Hacker News Reader

Comment by rafaelmn | Hacker News Reader

>Remote editing does not work on Windows (its not implemented at all), so if you are on windows, you cannot ssh into anything with the editor remote editing feature. This means you cannot use your PC as a thin client to the actual chunky big work machine like you can with vscode.

Does this work on anything other than VSCode ? I have been trying to use JetBrains stuff for this but it has been bad for years with little improvement. Honestly JetBrains feels like they are falling behind further and further in terms of adapting to providing a modern workflow - bad remote work, bad gen AI integration. I'm using VS code even where I wouldn't consider it before because of this, and I would like to see what the alternatives have to offer because VSCode is not perfect either.

View on HN

As someone that is old enough to have used UNIX development servers for the whole company, with PC thin clients, reading about remote development as modern workflow is kind of hilarious.

The remote development feature implemented in VS Code—and I believe also in beta in Zed—is a million times better than what you're used to. The UI is local, the storage and computation (including the language server) are remote. This takes away the lag when connected to a far-away server while still allowing things like platform-dependent compilation to work correctly and efficiently.

For the last 35 years, X Windows, Citrix and RDP have done the job just fine, in what I am concerned.

No, they aren't anything better than what I am used to.

Also, as compromise, a cloud shell, browser based IDE setup, and dev containers, also does the job in what concerns cloud deployments, which should be driven from CI/CD and don't have shells on containers anyway.

Good for you, I guess? For me, regressing to having a round trip between a keypress and its result would be completely unacceptable. The speed of light in a vacuum doesn't change; paths are not getting significantly more direct; the improved index of refraction from switching to hollow-core fiber or low-orbit satellites could in theory help but is a one-time, limited improvement that has yet to be delivered to my fingertips. Having the network boundary in the correct place to account for the fundamental physics of the situation is the only real answer.

Winscp open file + copy back on write detect was very useful for local-speed relote editing 10 years ago. Only issue now would be no lsp.

Also using gold audio cables, I guess. Lets not let go aways of those Hz that hardly any human notices.

I mean you do get slower with age so maybe that could explain it - personally I get nauseous working on 30hz (was stuck on this in a BnB once because of an old HDMI dongle), and that's like best case scenario for internet latency without all of your local I/O and encode/decode overhead.

No they haven't done the job just fine. Remote X has always been a pain to set up, and slow. NX was much better but not free.

Remote VSCode is far better than any of those options. If you don't want to try it that's fine, but don't pretend you know better.

I do not remember anything particularly difficult to get X11 up and running remotely, other than the XAuth stuff which was annoying enough in hardened environments, although those have not been commonplace, and X11 tunnelling via ssh has automagically taken care of XAuth.

The ultimate deal breaker, however, is X11 not being proxied by corporate firewalls, even though the protocol is extensively documented and the source is available. But that is because RDP has won over, and demand for X11 has diminished.

But, yes, X11 prefers local networks with flat topologies, and the protocol is chatty (again, not as big of an issue anymore unless run over a mobile connection with a high latency, but the X11 protocol compression helps with that).

What was so complicated about configuring an environment variable, and investing into good tooling like Hummingbird?

It was never as simple as configuring an environment variable.

Except doing it over LAN vs Internet is a very different thing - editing over SSH with >100 ping is annoying as hell, especially if you have packet drops (like a mobile connection). Using a thin client editor with remote server is a much smoother experience.

Works good enough with hyperscalers.

Use mosh??

sounds like an old stubber person comment. "we had fax in the 70s, why do we need anything more, now get off my lawn!"

vscode's remote services is far beyond your old remote experience, an experience I share

More like someone that is hardly impressed by kids on the school playground rediscovering history, like all those TikTok videos that are actually resampling 1970's music, and folks dancing to them cheering them for cool new modern music.

It’s not exactly the same paradigm as remote editing, but neovim in tmux accessed over mosh is my preferred way of accomplishing the same task. I have also gotten a neovim gui to connect with a neovim instance over ssh, which worked pretty well until the ssh connection broke. But I prefer my editor in a terminal rather than terminals in my editor, so I switched back to my tmux based workflow.

If you are already using tmux, what is the value of using mosh? Sincere question.

Basically the benefit is not losing context when I close my laptop lid or if I lose network briefly. I actually use multiple tmux sessions in my workflow, so it also saves me having to remember which one I was working in. This is especially useful if I am on a spotty connection such as tethered through my phone.

tmux is session management. Mosh is low latency udp transport.

Works on JetBrains, vscode, any terminal editor (neovim, vim, nano, etc.). Is it any good? It's fine on JetBrains, great on vscode, the rest is more or less great. Zed does not have it. You want to edit a remote file? You download it, edit it, upload it. That's much worse than a half baked implementation.

For clarity, this does work with the mac os version of Zed. I use it frequently to work on my GPU nodes. The one tradeoff that is a bit of a smell for me is that the preview version of the feature requires you talk to a centralized broker on Zed's servers rather than fully p2p between your local IDE and your own server.

This is supposedly temporary though IIRC (may even be changed already in a dev branch, not sure).

Reply on news.ycombinator.com