Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Coding Agent VMs on NixOS with Microvm.nix

michael.stapelberg.ch

Post reply on HN
Print view View original

51–58 of 58 posts

Re: Coding Agent VMs on NixOS with Microvm.nix

#51

Post by 0x457 »

Cyph0n wrote: post #45
0x457 wrote: post #43

Earlier quoted context omitted.

I know that part is easy, i just nix-anywhere just yesterday to reinstall one of my servers. It's not what I'm talking about.

Okay, so your idea is that cloud providers should make this even easier? $ nixos-rebuild build-image --flake .#myhost --image-variant amazon $ aws-cli image upload

Less about IaaS providers, more about PaaS providers that often abstract away image you're running and tell you "just run pip/apt/gem install whatever".

Same with the CI platforms, instead of `setup-*` steps in GHA it could have just take flake in. Yes, I know I can build OCI image with nix, again, not the issue.

My private CI runs on top of nix, all workers on the same host share /nix/store. My pipelines focused on running actual things rather than getting a worker ready to run things. If I didn't want output to be parsed by CI, I could have just reduced my pipeline to `nix flake check`.

I share the exact same pipeline and worker image across multiple projects in multiple languages, all because everything is hidden behind devenv's tasks. When I switched project different rust and node versions, I didn't have to touch my CI at all. When I added a bunch of native deps that usually needed to be installed separately on GHA - again, didn't have to touch anything beyond my nix env once.

Re: Coding Agent VMs on NixOS with Microvm.nix

#53

Post by robcholz »

phrotoma wrote: post #21
NJL3000 wrote: post #16

A pair of containers felt a bit cheaper than a VM: https://github.com/5L-Labs/amp_in_a_box I was going to add Gemini / OpenCode Kilo next. There is some upfront cost to define what endpoints to map inside, but it definitely adds a veneer of preventing the crazy…

One problem with using containers as an isolation environment for a coding assistant is that it becomes challenging to have the agent work on a containerized project. You often need some janky "docker-in-docker" nonsense that hampers efforts.

[dead]

Re: Coding Agent VMs on NixOS with Microvm.nix

#54

Post by alexzenla »

syzcowboy99 wrote: post #50
alexzenla wrote: post #26

Earlier quoted context omitted.

The reason why virtualization approaches with true Linux kernels is still important is what you do allow via syscalls ultimately does result in a syscall on the host system, even if through layers of indirection. Ultimately, if you fork() in gVisor, that calls fork() on the host (btw fork() execve() is expensive on gVisor still). The middle ground we've built is that a real Linux kernel interfaces with your applicati…

> Ultimately, if you fork() in gVisor, that calls fork() on the host This isn't true. You can look at the code right here[1], there is no code path in gVisor that calls fork() on the host. In fact, the only syscalls gVisor is allowed to make to the host are listed right here in their seccomp filters[2]. [1] https://github.com/google/gvisor/blob/master/pkg/sentry/sysc... [2] https://github.com/google/gvisor/tree/maste…

I was more specifically referring to the fact that to implement threads in gVisor, it calls to the go runtime, which does make calls to clone() (not fork()), but I see the pushback :)

I think it's a small distinction. fork() itself isn't all that useful anyways.

However, consider reading a file in gVisor. This passes through the IO layers, which ultimately will end up a read in the kernel, through one of the many interfaces to do so.

Re: Coding Agent VMs on NixOS with Microvm.nix

#55

Post by alexzenla »

souvik1997 wrote: post #31
alexzenla wrote: post #24

Earlier quoted context omitted.

This is a big reason for our strategy at Edera ( https://edera.dev ) of building hypervisor technology that eliminates the standard x86/ARM kernel overhead in favor of deep para-virtualization. The performance of gVisor is often a big limiting factor in deployment.

Edera looks very cool! Awesome team too. I read the thesis on arxiv. Do you see any limitations from using Xen instead of KVM? I think that was the biggest surprise for me as I have very rarely seen teams build on Xen.

I'd say the limitation has been that sometimes we have to implement things by hand. But it has enabled us to do things that others can't achieve since KVM is a singular stack in many ways. For example, VFIO-PCI is largely the same across all VMMs, but we have true full control over the PCI passthrough on our platform which has allowed us to do things KVM VMMs can't.

Re: Coding Agent VMs on NixOS with Microvm.nix

#56

Post by alexzenla »

yearolinuxdsktp wrote: post #46
alexzenla wrote: post #24

Earlier quoted context omitted.

This is a big reason for our strategy at Edera ( https://edera.dev ) of building hypervisor technology that eliminates the standard x86/ARM kernel overhead in favor of deep para-virtualization. The performance of gVisor is often a big limiting factor in deployment.

How do you compete with Nitro-based VMs on AWS with 0.5% overhead?

When running on bare metal, the CPU performance is within 1%, so usually quite well! Hardest thing is I/O, but we do a lot to help with that too.

Re: Coding Agent VMs on NixOS with Microvm.nix

#57

Post by the_harpia_io »

giancarlostoro wrote: post #33
nh2 wrote: post #29

Earlier quoted context omitted.

I find that a bit of a weird point. The goal of such sandboxing is that you can allow the agent to freely write/execute/test code during development, so that it can propose a solution/commit without the human having to approve every dangerous step ("write a Python file, then execute it" is already a dangerous step). As the post says: "To safely run a coding agent without review". You would then review the code, and u…

If that's the goal, why not just have Claude Code do it all from your phone at that point? Test it when its done locally you pull down the branch. Not 100% frictionless, but if it messes up an OS it would be anthropic's not yours.

[flagged]

Re: Coding Agent VMs on NixOS with Microvm.nix

#58

Post by the_harpia_io »

ryanrasti wrote: post #17
the_harpia_io wrote: post #6

[flagged]

Precisely! There's a fundamental tension: 1. Agents need to interact with the outside world to be useful 2. Interacting with the outside world is dangerous Sandboxes provide a "default-deny policy" which is the right starting point. But, current tools lack the right primitives to make fine grained data-access and data policy a reality. Object-capabilities provide the primitive for fine-grained access. IFC (informatio…

[flagged]
Post reply on HN