The document is clear that the expectation from the developer is that you need to be ready for your app to be snapshotted and frozen/killed at any moment when it is not on the foreground.
Note that the fork()/execve() semantics of Linux pretty much depend on memory overcommit. You may get weird OOM crashes when there is seemingly no memory pressure, if you turn overcommit off.
In the short time between fork() and execve(), the new process duplicates the entire virtual memory of the old one. None of this is physically allocated due to copy-on-write, but still all counts as virtual memory.
Has anybody tried a compromise? Like, the program forks and overcommit is ignored for it for a 1 second grace period? I know it would be more complicated than that, but something along those general lines.
Yes, you can run Podman with different OCI runtimes, in the same way as you can run Docker with different OCI runtimes, and some of these OCI runtimes are microVM-based.
This is not what the person I was responding to is doing, though.
As for differences between the krun OCI runtime and Docker Sandbox (which also uses libkrun), let's please continue the discussion here: https://news.ycombinator.com/item?id=49240662 .
Do you mean like Docker has supported for years…? (Just configure krun as Docker's OCI runtime.)
Obviously, there's a reason why Docker released Docker Sandbox as a separate product:
- Barely anyone bothers to configure Docker/Podman with a different OCI runtime like krun. Heck, most people don't even know about OCI runtimes in the first place. Case in point: Most people here in this HN discussion are proposing using "standard" containers (with the default OCI runtime) for sandboxing. This is what I was trying to get at.
- A sandbox for agent needs tighter network control.
As for differences between the krun OCI runtime and Docker Sandbox (which also uses libkrun), let's please continue the discussion here: https://news.ycombinator.com/item?id=49240662 .
reply