←back to thread

Making TRAMP faster

(coredumped.dev)
226 points celeritascelery | 4 comments | 23 Jun 25 14:46 UTC | HN request time: 0.856s | source
Show context
IceDane ◴[23 Jun 25 16:53 UTC] No.44357681[source]▶
Tramp is tolerable, but it is absolutely not great. You went on to demonstrate that right after making that claim, where you manually (and insufficiently) hack around its issues to arrive at something that is only barely comparable to eg what vs code can do.
replies(1): >>44357713 #
kleiba ◴[23 Jun 25 16:57 UTC] No.44357713[source]▶
Forgive my ignorance, but what does VSCode do?
replies(1): >>44358232 #
kristjansson ◴[23 Jun 25 17:44 UTC] No.44358232[source]▶
Download a copy of itself onto the remote, run it there, and allow interaction with that copy
replies(3): >>44358522 #>>44358844 #>>44359062 #
1. ants_everywhere ◴[23 Jun 25 18:18 UTC] No.44358522[source]▶
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.

replies(2): >>44358584 #>>44364039 #
2. kristjansson ◴[23 Jun 25 18:25 UTC] No.44358584[source]▶
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.)

replies(1): >>44358785 #
3. ants_everywhere ◴[23 Jun 25 18:47 UTC] No.44358785[source]▶
> Correct. I didn't say it was a good thing :)

Fair enough :)

4. zelphirkalt ◴[24 Jun 25 08:36 UTC] No.44364039[source]▶
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.