I've only used it with Linux kernels, but that has not been my experience with the new Virtualization.framework. The perf of virtio shares is reasonably fast.

I can see how you'd need a crap ton of disk for MacOS virtualization, but again, why do you need it?

If it's isolation for builds, fix your build. If it's isolation for tests, live with it. If it's for running your app, write your app to properly run in the app sandbox.

> reasonably fast.

But still not "as fast as it gets". And I want it to be as fast as it gets.

Neither is using macfuse as a stand in for overlayfs and bind mounts.

My point is "as fast as it gets" is using MacOS how MacOS is designed: ie, through sandboxing and not containerization that pretends the MacOS userspace is Linux. It's not Linux.

There is a fundamental trade off between isolation and performance. You cannot securely share resources without overhead.

FUSE is only used for bind mounts. If you write to a directory that belongs to container, you get the raw speed of host OS.

How do you support layers without overlayfs?

It's not me, it's containerd "native" snapshotter. It turns to be efficient on macOS thanks to `clonefile` syscall.

> If it's isolation for builds, fix your build

Isolation fixes the problem for free and is more similar to how I build for Linux. Why would I want another solution?

MacOS apps are designed to be self contained and not require isolation, unlike most Linux distros, which are designed to use FHS and share their state/dependencies with everything else on the system.

Further you can sandbox processes just fine on MacOS without needing to mock the whole userspace, like you do on Linux. This will give you the same degree of isolation that a container does.