5 ms·

Why does the author need a “remote ssh” plugin in their VSCode? I usually develop inside a VM as well, with my IDE running in the host… but what I do is to mou

Why does the author need a “remote ssh” plugin in their VSCode? I usually develop inside a VM as well, with my IDE running in the host… but what I do is to mount a shared directory for the code between the host and the VM. Works pretty fast. Don’t understand the need for Tailscale either. When I’m running services or dbs inside the VM, I can easily access them if needed from the host (either by IP or by the hostname I gave to the VM on start up)

kevingadd 2y ago
SSH remote in VS code has way better latency and performance characteristics than mounting a shared directory. Stuff like disk change monitoring also works a lot better. The one mixed/negative thing is that language servers will run inside the VM instead of the host where the editor is "running", which can defy your expectations. I find that a plus since language servers love to tie up multiple cores and eat up memory and having that happen inside the constrained VM environment stops my host system from getting bogged down. I used to edit in a shared mount before and moving to the vscode ssh remote model was a noticeable improvement. It's just faster.
- kijin 2y ago
  SSH remote absolutely rocks. It's the #1 reason I chose VS code instead of some other editor with an SFTP plugin. I'm working on a Windows host with a bunch of Linux VMs. Although I can share directories between the host and guests, I prefer to rely on SSH remote because I want to work in the VM's filesystem and its environment. For example, I don't want to care which version of python and what kind of libraries are installed on the host. The VM is supposed to be a container for all that stuff, and different projects have different requirements.
- 1718627440 2y ago
  What would prevent you from mounting your directory with ssh?
askonomm 2y ago
So how does your IDE pick up on the tooling inside the VM? E.g if you build Python projects, how does it pick up the Python executable, .venv, etc? Or if PHP, then the PHP runtime, or if C then its stuff ... etc? If you install these on your host machine to make your IDE work well then I'm afraid that defeats the point of having a VM.
- deleted 2y ago
  [deleted]
disintegrator 2y ago
As others have mentioned, I’ve not had great performance with shared folders and the SSH extension in VS Code is so damn good. Over time, you forget it’s even running because you open recent projects and it remembers which were local (on host) and which are on the guest and SSH’s in automatically. I could probably revise my use of Tailscale. My vague recollection is that I had networking issues when my laptop woke up and Tailscale didn’t have the same issues. Probably a debugging skill issue on my part.
deleted 2y ago
[deleted]
tomjen3 2y ago
So, VSCode has remote development, which any nerd would instantly think: "oh, that just means it copies files transparently", but it doesn't. It actually runs the code, including plugins you download from the internet. All your development tools, compilers, etc. are on the remote. And then you just have a blazing fast editor on the front end. It's really unique - you can use Tramp mode in Emacs, but it is extremely slow to copy back and forth. SSH into a remote server? let's just say 200 milliseconds lag when you're trying to input characters is not a good experience. The highest praise I can give Visual Studio Code is that remote development felt so much like local development that I wondered why it suddenly froze. Well, it turns out it's good, but it still can't deal with a network that's down. That was obvious in retrospect, however I hadn't thought of it at the time because I had completely forgotten I was doing remote development.

kevingadd 2y ago

SSH remote in VS code has way better latency and performance characteristics than mounting a shared directory. Stuff like disk change monitoring also works a lot better. The one mixed/negative thing is that language servers will run inside the VM instead of the host where the editor is "running", which can defy your expectations. I find that a plus since language servers love to tie up multiple cores and eat up memory and having that happen inside the constrained VM environment stops my host system from getting bogged down. I used to edit in a shared mount before and moving to the vscode ssh remote model was a noticeable improvement. It's just faster.

kijin 2y ago
SSH remote absolutely rocks. It's the #1 reason I chose VS code instead of some other editor with an SFTP plugin. I'm working on a Windows host with a bunch of Linux VMs. Although I can share directories between the host and guests, I prefer to rely on SSH remote because I want to work in the VM's filesystem and its environment. For example, I don't want to care which version of python and what kind of libraries are installed on the host. The VM is supposed to be a container for all that stuff, and different projects have different requirements.
1718627440 2y ago
What would prevent you from mounting your directory with ssh?

askonomm 2y ago

So how does your IDE pick up on the tooling inside the VM? E.g if you build Python projects, how does it pick up the Python executable, .venv, etc? Or if PHP, then the PHP runtime, or if C then its stuff ... etc? If you install these on your host machine to make your IDE work well then I'm afraid that defeats the point of having a VM.

deleted 2y ago
[deleted]

disintegrator 2y ago

As others have mentioned, I’ve not had great performance with shared folders and the SSH extension in VS Code is so damn good. Over time, you forget it’s even running because you open recent projects and it remembers which were local (on host) and which are on the guest and SSH’s in automatically. I could probably revise my use of Tailscale. My vague recollection is that I had networking issues when my laptop woke up and Tailscale didn’t have the same issues. Probably a debugging skill issue on my part.

deleted 2y ago

[deleted]

tomjen3 2y ago

So, VSCode has remote development, which any nerd would instantly think: "oh, that just means it copies files transparently", but it doesn't. It actually runs the code, including plugins you download from the internet. All your development tools, compilers, etc. are on the remote. And then you just have a blazing fast editor on the front end. It's really unique - you can use Tramp mode in Emacs, but it is extremely slow to copy back and forth. SSH into a remote server? let's just say 200 milliseconds lag when you're trying to input characters is not a good experience. The highest praise I can give Visual Studio Code is that remote development felt so much like local development that I wondered why it suddenly froze. Well, it turns out it's good, but it still can't deal with a network that's down. That was obvious in retrospect, however I hadn't thought of it at the time because I had completely forgotten I was doing remote development.