That’s a neat trick, thanks for mentioning this.

  command="command" ssh-ed25519 ...

On the topic of limiting the possible commands - for my use case I only needed pbcopy. Maybe think twice before letting an insecure VM or remote host read your clipboard contents with pbpaste.

I use this script with an additional seccomp filter that also denies access to privileged syscalls, but I don't remember where the filter came from, so I won't post it here — you won't be able to audit it easily as it's basically a compiled binary.

https://0x0.st/8zWK.sh

Place the script anywhere and create symlinks named 'node'/'npm'/'yarn'/etc pointing to it, putting them into the start of your $PATH. Run your commands as usual. Use a 'bash' symlink to see what it looks like inside the sandbox.

It's not as good as a VM, but much more convenient.

Yeah, but someone should try to fix this anyway. It's not a nodejs-specific problem, but it's badly needed in node. Any of the 100s of authors whose packages I depend on might have made a typo, or just been careless. Software development requires a scary level of trust.

I am also increasingly moving to VMs. I want tools (such as VSCode) to run on the main machine, but actual execution to happen in the vm. It's a bit painful and a drag on productivity, especially debugging.

The people in the trial got very little done until it was decided to pause it, and I do not have high hopes for when it’s tried again. It strikes me as basically running malware in the name of security.

Side note: I checked out your other blog post, and it resonates with my own first post, which I wrote just two days ago: https://fabiendubosson.com/blog/overcoming-perfectionism/. You’re definitely not alone in battling anxiety, perfectionism, and procrastination when it comes to blogging. Keep writing! :)

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.

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.

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.

Each project we have requires a specific tool chain version (python, elixir, ...) and specific versions of things like postgres. All dependencies are listed with some kind dependency definition file (pyproject.toml, package.json, mix.exs). If you bump a package it's done in the definition file as part of your changes and goes through CI for packaging and releasing. The rest of the team will get the new package version as soon as they pull your changes and run `just deps` or whatever. CI is the ultimate determining factor of whether your code actually "works".

We also package and deploy with containers, but this isn't the real determining factor for any of the above.

Works well enough. Better than Docker on barebone MacOS if you have lot of file access in a volume.

That's one of the thing which surprised me when I started using VMs to develop. First time was with a postgres backed app: I expected to lose performance when moving everything in a VM. But got the exact opposite result at the time. Postgres really liked the linux filesystem more than the windows one, enough to do more than offset the VM tax.

One weird quirk: networking can be peculiar. Windows creates a magic bridging between the host and WSL, and as anything magic, it can break for specific use cases.

VPN is one [0]: my WSL instances lose outgoing networking when connecting to our company VPN. There are workarounds but none are trivial.

[0] https://superuser.com/questions/1715764/wsl2-has-no-connecti...

Vscode supports remote containers, so everyone in the org just develops INSIDE a replica of the prod container

All containers run remotely on enormous machines with 800+ GB of RAM and 8+ GPUs

It’s trivial to share environments now because you just open the project and the dev container starts up and installs all the deps, devcontainer.json is just a few kb so just check it into git

Engineering, DevOps, Data science all use this setup, push around your devcontainer.json and everyone gets the same GPU accelerated dev environment with near unlimited RAM and hundreds of CPU cores, none of this hardware is local so you can code on the balcony/beach on your MacBook Air, light and easy to travel with.

We put VMs in the same country as our staff so latency has never been an issue

This is the dev setup I’ve wanted for ages, and it’s a joy to use

If you are using Docker Engine directly on Linux, you can forward a device to a container via docker-compose `devices` setting.

If you are using Docker Desktop (or similar), there is no native way. However, there are ways to share USB devices via network (USB/IP is an open source implementation of this), in which case you setup server on host device (can be macOS/Windows/Linux), and then run a client software inside a container.

Otherwise you could pipe serial over TCP

Edit: Unless you literally mean "editing code in a container with vi". In which case yes I'd go for the VM too!

I most often see this sort of thing where corporate IT can't stomach devs getting root on their own machines. It's a very specific sort of corporate dysfunction.

So I've installed proxmox on it to utilize it's resources for other stuff as well

For my personal use, I created an Arch VM with GPU and USB PCIE passthrough, all 3 monitors directly connected to that GPU

It's so seamless and fast that I don't even feel I'm working inside a virtual machine

I have other headless VMs hosted to do other things (opensense etc)