zlacker

Interesting choice to use native Apple Containers over Docker.

I assume this is to keep the footprint minimal on a Mac Mini without the overhead of the Docker VM, but does this limit the agent's ability to run standard Linux tooling? Or are you relying on the AI to just figure out the BSD/macOS equivalents of standard commands?

>>treelo+(OP)
If only there were some way to answer your own question. Maybe with some kind of engine that searches.

>>treelo+(OP)
Not sure if it's intended, but Apple Container is a microvm, providing mich better isolation than containers (while retaining the familiar interface)

>>selkin+Rk
"much better isolation than containers"

If you've got an exploit for docker / linux containers, please share it with the class.

What I'm saying is that in practice, containers and VMs have both been quite secure.

Also, you can configure docker to run microvms too https://github.com/firecracker-microvm/firecracker-container...

>>treelo+(OP)
>does this limit the agent's ability to run standard Linux tooling? Or are you relying on the AI to just figure out the BSD/macOS equivalents of standard commands?

Slightly counterintuitively, Apple Containers spawns linux VMs.

There doesn't appear to be any way to spawn a native macOS container... which is a pity, it'd be nice to have ultra-low-overhead containers on macOS (but I suspect all the interesting macOS stuff relies on a bunch of services/gui access that'd make it not-lightweight anyway)

FYI: it's easy enough to install GNU tools with homebrew; technically there's a risk of problems if applications spawn commandline tools and expect the BSD args/output but I've not run into any issues in the several years I've been doing it).

>>TheDon+PC
We want to protect against the unknown, not the known. The less surface area, the better, and containers have much wider surface area than VMs. Both had their faults, of course.