Option Z) Everyone vibe codes their own custom OS. Each implements and exposes only what they want. Hacker has to beat up on it online to find vulnerabilities. He finds one and he only owns that one machine.
There's probably some middle ground between A and Z, but monocultures are fragile. All eggs in one basket, potato famines, banana fungus, etc...
That is also why I believe the namespace approach, and by extension Docker-like containerization, is a dead end when it comes to isolation. I hope something like gVisor will win.
This is even more important since agents have turned isolation from a datacenter topic into everyone's concern.
This is incorrect. If you can't trust Linux because it is gigantic, you can't trust a whole another new kernel. Userspace is not blackmagic.
I do wonder what problem it solves, as I don’t think that it provides the same security guarantees that micro-VMs like firecracker do?
Edit: at least with gvisor you get close to a decade of work on compat. gVisor can support some rootless containers scenarios and systemd these days.
But I’m not sure if that is really possible.
The use case I’m thinking about is a sandbox exec isolation on an HPC cluster without Docker. I know singularity/apptainer exist, but I’m always looking for something that could make that environment more flexible. It is a tight security environment, so we are always limited in what we can do.
OTOH, running a messy environment with rollback support is much easier with a VM than a container.
Containers are fun for packing messy executables into their own environment and run them now and then, though.
Rolling back is easy as long as you understand where the state, if any, is which is actually the hard part of any application. At least with containers you have all of them stored in a well defined registry, while with VMs you would be rolling your own VM snapshot storage system. Not super complicated to do in the grand scheme of things, but it’s another thing you need to get right. But VMs/applications that can rollback would be just as easy (if not easier) to rollback with containers.
Remember the submission about how Auto Review is safe? Their standard of safe is that it will take a playwright dependency of another project in your home directory and add playwright based tests to your current project that hasn't declared playwright as a dependency. Amazing.
The issue literally isn't even about a hypothetical security argument anymore. Your sandbox is now a policy that tells the agent what it is allowed to do or not.
Breaking this layer doesn;t automatically give ring0 privs across the hardware.
Never change, HN, never change :D
> That research phase is complete.
So not sure what part of it now constitutes "research and exploration".
> The current implementation includes a security-focused x86-64 interpreter and a balanced native ptrace backend;
ptrace allows you to have the kernel redirect syscalls back to userspace, mostly for debugging purposes. "balanced" here refers to speed, but the overhead is still quite high.
More seriously, it is a great use of indirection insofar as replacing the full Linux kernel is a gargantuan task. A userspace kernel per task or task group.. makes a lot of sense. I'd be interested to know how it captures syscalls - eBPF? It wasn't obvious from a skim of the readme.
This kind of give-me-this-interface work seems pretty perfect for LLMs, too.
I’m still trying to figure out exactly what it is.
A project picked up casually, for a short time, is likely to be dropped casually, in a short time.
The slop problem is also a challenge to overcome. The project barely existed and has already pivoted in a completely new direction. Who knows when this direction bores the author and we get yet another pivot. Or the author loses interest and we end up with a dead pile of abandoned code like so many other LLM generated projects.
The previous state of the project could've made for an interesting VM runtime (safety of Rust without the issues that come with the lack of ported drivers). For this new direction, I don't think there's a similar sort of demand.
Stating that nobody will take it seriously is probably an exaggeration, but I consider these projects to be toys for the author to play with, I don't see why you would take more interest than going "huh, neat I guess".
You could probably work around this partially by having contracts with people, but these in turn also depend on the AI slop then, so the problem is just shifted.