Hacker News Reader

Comment by frabonacci | Hacker News Reader

Correct. Docker in this case acts more as a delivery and management plane, rather than providing process isolation. Similar to how dockur/windows or qemus/qemu rely on --device=/dev/kvm to spin up VMs on Linux hosts, we use a background service that interfaces with Apple’s Virtualization Framework (Vz) to provision real VMs on the macOS host. The container connects to this service via host.docker.internal, allowing full interop between the Docker-based interface and the host-based virtualization layer

View on HN

The title is a bit misleading then :)

What’s the difference between this vs just using your lume CLI? Right now it feels like a worse interface to lume, but maybe I’m not getting a use case for this.

Also, any thoughts on https://github.com/cirruslabs/tart? (alas, not open source)

You’re right, Lumier might seem similar to Lume CLI, but it adds browser-based desktop streaming via noVNC and integrates with Docker for easier management, which is a familiar interface for many developers. Since our parent project C/ua will use KVM-based containers on x86/x64 hosts, aligning to a container interface here seems a natural step for us. Docker also allows packaging noVNC as a self-contained dependency, streamlining setup for some users.

On a comparison with Tart, UTM, Lima, we actually touch it in this GitHub discussion: https://github.com/trycua/cua/issues/10

There’s no mention of Tart in there, but I’ve looked into Lume CLI some more and it seems it’s basically a superset of Tart in functionality. (And both use container registries as the VM image store, neat!)

> aligning to a container interface here seems a natural step for us

It might be tricky since you do have to escape from the container to run the actual VM, though I guess you can figure something out here. I still think it’s the wrong layer to build your abstractions upon, but let’s see how it goes! Just don’t discontinue the CLI, it’s really cool :-)

Thank you for the support! One idea we’ve been exploring is reusing the same Apple VZ backend that Docker itself uses to run a nested macOS VM from inside the container. That would avoid the need for a background service on the host, but it would require patching parts of Docker and only work on M3+ chips, since earlier Apple Silicon doesn’t support nested virtualization

Reply on news.ycombinator.com