Comment by dannyw
15 hours ago
This looks pretty decent actually. Sure, you could consider it a frontend/SDK for bubblewrap/seatbelt/processcontainer; but setting em up consistently is far from trivial; and hand rolling is a really bad idea (speaking from experience).
I like the ‘learning’ mode for figuring out what perms/config a runtime needs, the MIT license, the clear optional telemetry disclosures, and somewhat light and still readable documentation.
Regardless of your views on Microsoft, this looks quite useful; serves a clear purpose, and from a quick glance, looks like a high quality project even if it’s just the first version.
It does look nice and easy.
Not sure I will give up on smolvm though.
I have scripts to launch an instance per task. Nono wraps my coding agent.
I provide the git clone for the specific task.
It works really well.
thanks
I'd also add that MXC is still sharing the host kernel.
i.e. on mac MXC uses seatbelt, so the agent shares your kernel.
but smolvm gives each task its own VM with its own kernel, same on mac, linux and windows. + additional layers like preconfigured seccomp, landlock, wherever it makes sense
Yeah, smolvm (from https://smolmachines.com) is awesome. Have you written up your setup in any detail?
I've toyed around with bubblewrap before, and I agree that it becomes pretty unwieldy when you start trying to do anything moderately complex. It's a giant bin of Legos that you can put together however you want, but in practice as an end user you probably just want a few specific sets that come prebuilt most of the time.
I agree! I can't comment on the design of the SDKs but from the looks of it this is a great option to integrate into agent harnesses/pipelines.
The "audit" and "debug" mode are specially useful. I use bubblewrap and using a new harness with it is usually a couple of rounds of wack-a-mole with strace to figure out all the harnesses dependencies.