3 ms·

code-server, instead of VSCode. I can build my own podman image on top of it with whatever dev tools I need for whatever languages I'm working with, and if I ha

by 4oo4 6mo ago

code-server, instead of VSCode. I can build my own podman image on top of it with whatever dev tools I need for whatever languages I'm working with, and if I have to install something weird or something breaks I can just restart the container. Especially on my work machine that isn't Linux, I have this running in a VM and can just use in my browser and don't have to jump through hoops to get the dev environment I want. On my personal instance I also use it for automating building stuff from source. Before I had this, I just had build tools on pretty much every single machine I was building for and it was a hot mess. https://github.com/coder/code-server https://github.com/coder/code-server

Antitoxic6185 6mo ago
so... devcontainers but in a different way? Why not just devcontainers? I know its a PITA to setup on podman.
- 4oo4 6mo ago
  Yes and no, in this case you don't need a local vscode instance to connect to your vscode container, just a browser. It's more similar to self-hosted Github Codespaces, and but I believe code-server was actually released first. Personally I've fiddled enough with podman that that part of it doesn't bother me, and I don't like Docker/Podman desktop (which I think is what devcontainers assume the setup is) and just want to use the docker/podman daemon/cli, so that's something I also don't want to have to mess with. I know you can also point devcontainers at a remote or local docker daemon, but that means giving it full control of the daemon, which is a nonstarter and too risky for me from a security standpoint. I really like to have my podman containers really locked down in terms of capabilities, userns, gvisor, etc. and given that it just wants full control of docker I'm guessing it takes none of that into consideration (or, painful to try and graft on). I also really don't trust VSCode's remoting protocols (especially remote tunnels, which is basically just a reverse shell). So for me it's a matter of having more control over container runtime security (the docker/podman ecosystem usually treats it as an afterthought in favor of convenience, and devcontainers appears to be no different), and it doesn't depend on anything on my machine I'm accessing it from. Since VSCode just a becomes another self-hosted web app this way, it's pretty much the exact same experience no matter where I'm connecting from.

by 4oo4 6mo ago

Antitoxic6185 6mo ago

so... devcontainers but in a different way? Why not just devcontainers? I know its a PITA to setup on podman.

4oo4 6mo ago
Yes and no, in this case you don't need a local vscode instance to connect to your vscode container, just a browser. It's more similar to self-hosted Github Codespaces, and but I believe code-server was actually released first. Personally I've fiddled enough with podman that that part of it doesn't bother me, and I don't like Docker/Podman desktop (which I think is what devcontainers assume the setup is) and just want to use the docker/podman daemon/cli, so that's something I also don't want to have to mess with. I know you can also point devcontainers at a remote or local docker daemon, but that means giving it full control of the daemon, which is a nonstarter and too risky for me from a security standpoint. I really like to have my podman containers really locked down in terms of capabilities, userns, gvisor, etc. and given that it just wants full control of docker I'm guessing it takes none of that into consideration (or, painful to try and graft on). I also really don't trust VSCode's remoting protocols (especially remote tunnels, which is basically just a reverse shell). So for me it's a matter of having more control over container runtime security (the docker/podman ecosystem usually treats it as an afterthought in favor of convenience, and devcontainers appears to be no different), and it doesn't depend on anything on my machine I'm accessing it from. Since VSCode just a becomes another self-hosted web app this way, it's pretty much the exact same experience no matter where I'm connecting from.