[notpushkin]

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)

[frabonacci]

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

[notpushkin]

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 :-)

[frabonacci]

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