Forgive my ignorance, but what *does* VSCode do?

kristjansson · 2025-06-23T17:44:25 1750700665

Download a copy of itself onto the remote, run it there, and allow interaction with that copy

ants_everywhere · 2025-06-23T18:18:04 1750702684

Editing a remote file is very common. Wanting to download and run a remote server every time you edit a remote file is far less common.

E.g. editing a config on an embedded device such as a router, editing a file inside a docker container, editing a file on a headless server, etc etc.

The only reasonable use case I can see for the vscode approach is if you're SSHing into your main development machine from another machine.

The remote server requirements include

> 1 GB RAM is required for remote hosts, but at least 2 GB RAM and a 2-core CPU is recommended.

That's pretty far from the SSH+vi use case that TRAMP replaces.

kristjansson · 2025-06-23T18:25:40 1750703140

Correct. I didn't say it was a good thing :)

FWIW it is a one-time download on the remote, but still feels yucky, esp. for resource constrained settings (Pi like you mentioned, but also quota-limited containers etc.)

ants_everywhere · 2025-06-23T18:47:04 1750704424

> Correct. I didn't say it was a good thing :)

Fair enough :)

zelphirkalt · 2025-06-24T08:36:04 1750754164

The typical web dev won't care though, and go ahead downloading and installing a telemetry encumbered server onto the remote machine. All they need is the justification: "But it works!"

DevOps can tell them no all day long, they'll think they know better and give in to convenience over security every time.

What one could do is to block the download of VS Code on all infrastructure.

SoftTalker · 2025-06-23T18:53:05 1750704785

Emacs can run as a server, and you can connect multiple local clients to it. I've tried various ways to have an emacs client connect to a remote emacs server (forwarding a socket over ssh, etc.) but never gotten it to work so there must be more to it than just the socket.

sexyman48 · 2025-06-23T19:14:29 1750706069

No, emacs in server-mode does not do what you'd expect. It is only useful to accelerate local start-up. Nothing to do with remote operations.

kleiba · 2025-06-24T19:35:40 1750793740

But it does run in terminal mode - I used to ssh into a remote machine and just run emacs in a terminal there. Actually, there was also some `screen' in the mix, but you get the idea. I preferred that over TRAMP because of the speed.

sexyman48 · 2025-06-24T21:13:30 1750799610

No I don't get the idea. I was disabusing people of the widely believed myth that an emacs server instance could host remote connections. That one can ssh into a remote machine and run emacs in tty mode is manifestly obvious.

kleiba · 2025-06-25T08:18:09 1750839489

To you, certainly, but perhaps not to everyone. And it can be a good third option in addition to TRAMP or "what vs code does".

ParetoOptimal · 2025-06-23T19:26:21 1750706781

I think it doesn't work over tcp but try with the other GUI library.

skydhash · 2025-06-23T19:15:48 1750706148

To be fair, for some dev workflows, TRAMP is lacking (LSPs), but it's more than enough if you're fine with grepping and ctags, I think. For the former scenario, I either run terminal emacs or use distrobox/toolbox (they setup everything for the wayland socket that graphical emacs needs)

anyfoo · 2025-06-23T22:35:58 1750718158

LSPs should work fine with TRAMP. In practice I have a problem with it, since there is some bad interaction between eglot, TRAMP, and clangd in certain cases, but that is a specific situation and a bug.

skydhash · 2025-06-23T22:57:53 1750719473

gopls was a bit of a pain. By default it uses stdio, and there were some integration issues with eglot, tramp, amd gopls. I also had some issues trying to use tcp ports. I switched to terminal emacs over ssh, the. use distrobox (I didn’t want to install dev tools locally).