Comment by mgaunard
1 day ago
My only experience with VMs on macOS is colima+docker, and it's relatively painful and inefficient (but usable).
1 day ago
My only experience with VMs on macOS is colima+docker, and it's relatively painful and inefficient (but usable).
Try Apple's container CLI. I moved a project of mine from colima+docker to it relatively easily, a couple of weekends ago.
https://github.com/apple/container
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:
https://github.com/highpost/tailscale-macos-container
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.
I'm curious to know what kind of project is macOS exclusive?
You're surprised that a project by Apple Inc that is basically a wrapper around the Mac virtualisation framework [0] is Mac exclusive?
[0] https://developer.apple.com/documentation/virtualization
container is really good, ive been using it to sandbox some CLI tools and it starts up in less than a second
AFAIK no support for Compose though
Thank you for this, will check it out!
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...
> the signing/notarization just ~200 lines of Bash
200 lines?! That’s two orders of magnitude too many. What exactly are you doing that you need so such code for signing and notarisation?
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.
3 replies →
Could you share your recipe please ? I’m interested
OrbStack is pretty good. I don't find it inefficient, really.
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.
1 reply →