Which cool, great, I sure love "pip install"ing every time instead of just baking a single container image with it already installed.
This isn't any sort of fancy or interesting sandboxing, this is shelling out to "docker run", and not even using docker as well as it could.
Quoting from the linked page:
> The tradeoff is ~5-10 seconds of container startup overhead
Sure, maybe it's 5-10 seconds if you use containers wrong. Unpacking a root filesystem and spinning up a clean mount namespace on linux is a few ms, and taking more than a second means something is going wrong, like "pip install"ing at runtime instead of buildtime for some reason.
I can spin up a full linux vm and run some code in quicker than 5 seconds.
The problem isn't getting an AI agent running in a sandbox. That's trivial. The problem is getting an existing enterprise project runnable inside the sandbox too, with no access to production keys or data or even test-db-that-is-actually-just-a-copy-of-prod, but with access to mock versions of all the various microservices and api's that the project depends on.
16 comments
[ 4.4 ms ] story [ 36.2 ms ] threadUnder the hood it's effectively running:
Which cool, great, I sure love "pip install"ing every time instead of just baking a single container image with it already installed.This isn't any sort of fancy or interesting sandboxing, this is shelling out to "docker run", and not even using docker as well as it could.
Quoting from the linked page:
> The tradeoff is ~5-10 seconds of container startup overhead
Sure, maybe it's 5-10 seconds if you use containers wrong. Unpacking a root filesystem and spinning up a clean mount namespace on linux is a few ms, and taking more than a second means something is going wrong, like "pip install"ing at runtime instead of buildtime for some reason.
I can spin up a full linux vm and run some code in quicker than 5 seconds.
Launch an AI agent to operate on production servers/sql safely using tmux
https://news.ycombinator.com/item?id=47411242