Because some of us have never heard of devcontainers as a named concept with its own spec until now. I've been running my dev servers inside containers for a long time now (using JetBrains IDEs!), but have never heard of this before.
> It is well known that a container offers a sandbox and process isolation.
No, actually, it's well known that containers don't do that. It's one of the first things you learn when you start learning about containers—they are not virtual machines and are not suitable for running untrusted code, because they share a kernel with the host.
I just read through the introduction to devcontainers and there are lots of benefits it discusses but security isn't one of them:
Oh but it is. If there is harmful data-stealing software running in the container, it will remain isolated to the container. And if the kernel is shared with the host, that's a read-only share.
And what protects the production server when you deploy the evil packages?
Assuming the code that implements the containerization is 100% bug free and there are no container escapes. I would not bet my user's safety purely on that assumption.
> And if the kernel is shared with the host, that's a read-only share.
No, it's not, the kernel is reading and writing files constantly for the container. A bug in the kernel could be exploited to break the sandbox, which isn't possible in a true VM.
It's well known that the comments on HN are great for having discussions. You don't have to participate, despite your belief that you are required to. But, it's well known that having a discussion is a two way street, with people commenting and asking questions, and people replying.
