Does this project aim for docker cli and api compatibility? Searching for Docker on that page yields no results. Though in their example, they do show an example of a Dockerfile referencing docker.io without shame.
Typical Apple behavior, I guess, but grating to see in a OSS tool.
This is a weird take, imho. Should they feel shame for using Dockerfiles in their OCI-standard-compliant tool? Would you be happier if they introduced subtly incompatible Applefiles?
Why are they obliged to emulate the Docker CLI? This limits them to just shadowing someone else's product. Just use Docker if you want their CLI/API, it uses the same virtualization framework under the hood on Macs.
Here's an example of how to build a simple Alpine Linux container using Apple's containerization CLI. It also demonstrates how to connect to the container through Tailscale SSH using a Tailscale auth key stored in Apple Keychain:
The macOS app manages the host Tailscale service, while this example demonstrates how to connect with a *macOS container* using Tailscale SSH based on the Tailscale service under userspace networking mode. This gives the container its own dedicated Tailnet IP and identity without needing to port-forward through the host.
edit: For example, I can create a container on my MacBook to run an application. A colleague *in my Tailnet* can then connect to this container to interact with that application from a coffeeshop or airliner while not exposing the rest of my MacBook.
Recently got a Mac Mini for local CI purposes (together with Forgejo Actions), took a broad look at the ecosystem and decided to just roll with "build on host" instead. Setting up signing/notarization just looked like an insurmountably task together with isolating it from the host, even with agents. At least the macOS builds are really fast now and the signing/notarization just ~200 lines of Bash...
From the top of my head, unlocking the keychain, finding the right identity, notarizing two parts, the binary itself and the .dmg that the .app ships in and some other stuff I'm sure. Can do a deeper look in a bit when I can. Most of the hassle is because it's 100% unattended and I had to do stuff to avoid GUI-prompts for passwords/unlocks, and that the Forgejo Runner has a different security context.
This matches my experience. Keychain + fully unattended increases the complexity and adds a bunch of landmines that need to be dodged (e.g. GUI prompts like you mentioned).
> unlocking the keychain, finding the right identity
You don’t need to do that, you can give options to the CLI to define what profile to use.
> Most of the hassle is because it's 100% unattended and I had to do stuff to avoid GUI-prompts for passwords/unlocks
I have a shell function to which I point my code and it compiles, signs, and notarises it without any more intervention, GUI or password prompts, and I’m pretty sure signing and notarising are literally two lines.
Unfortunately I’m not at my computer now or I’d paste them, but from your description that script is definitely too long.
OrbStack is impressive on the performance and energy efficiency fronts. I'm not aware of anything that comes close. But they're doing something funky under the covers. You can't just start any OS in a VM. It has to be somehow mangled to suit their VM. Thankfully NixOS is available so I'm fine for my use cases. It's still remarkable how efficient it is.
Yeah, it's like WSL. It starts just one VM and then your individual "machines" are LXC containers underneath. If you peek at the vendor-supplied file your NixOS OrbStack Machine includes you can see some of it.
They're constantly doing other optimizations in other ways, too. But that's the one you were pointing at, I think.
OrbStack isn't open-source though and I can't justify buying a license for every single person in my company just for something functionally equivalent but performing better.
These kinds of things should just be provided by Apple as a first-class thing.
