11–20 of 147 posts
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)
is there a way to forward usb/serial ports from my local machine to the dev container? maintaining consistent firmware development environments using containers is a great idea, and current solutions involving proxying the compiled binary work well for flashing quickly, but switching back and forth between UART and Serial Debug is always more convenient when the IDE can handle it all
Otherwise you could pipe serial over TCP
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…
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 have used a Virtual Box VM with a Ubuntu guest for years and it has worked great. It's as close to the VM's in prod you can get.
I used to do that, but now that all of our microservices are dockerized every microservice has its own docker container 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…
I do something similar but using WSL on Windows. But something I really, really hate is dealing with special certificate handling required to pass the corporate Zscaler proxy. I think it works somewhat transparent on the Windows host, but repeating the setup in every VM is such a pain.
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.
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…
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 memor…
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.
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…
Earlier quoted context omitted.
I used to do that, but now that all of our microservices are dockerized every microservice has its own docker container 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…
What do devs who don't use VSCode do to work in this environment?
Not sure how GP's company does it, but that is how I would configure it.
Caveat: the default devcontainer initialization workflow does _not_ create the Dockerfile, only the .json.
At $work we don't use devcontainer.json, but we can launch the development environment image such that you can SSH into it as if it was a regular VM.
My specific setup is that I use an authorized_keys entry on the host that restricts the guest to running a specific command, which limits what a compromised guest can do to the host. The command is set to a script that has a list of specific permitted actions. This is a good option if you’re looking for a bit of additional isolation between host and guest.
We reach our VMs via VDI.