<a href="https://github.com/macOScontainers/homebrew-formula">https://github.com/macOScontainers/homebrew-formula</a><p>"macOS <i>native</i> containers"<p>Cool, this sounds interesting.<p>"Disable System Identity Protection."<p>Eesh.
How does this work?<p>Fundamentally, containers are about namespace/isolation of a bunch of OS interfaces, so file system functions, network functions, memory management, process functions, etc, can all pretend like they're the only game in town, but crucially without having to virtualize out the kernel.<p>Does XNU have such namespacing functionality across all its interfaces?<p>Furthermore, the existing container ecosystem assumes a Linux syscall interface. [1]. Does macOS provide that? I expect not.<p>The way Docker Desktop (and podman.io) implement "containers on macOS" is a bit of a cop-out: they actually run a <i>Linux virtual machine</i> (using Hypervisor.framework/hvf), and have that just provide the container environment.<p>Is that what this project is doing? But then, how could it run a macOS container?<p>[1] based on the foundation that Linux, unlike BSDs, has a stable syscall interface!
I can't help but feel like this is an X/Y problem. Apps on MacOS shouldn't need containerization to function.<p>I get the point of isolation for build/test situations. But Apple provides a neat virtualization framework, and you get security + isolation + reproducibility + decent performance.<p>It seems like if you feel the need to containerize the userspace on MacOS you're using MacOS wrong. It's not the same thing as the Linux userspace, and doesn't have the same kernel features that would let you do so cleanly or performantly.<p>Orbstack is moving mountains to provide Linux-native perf and support for containers and it still makes me beg the question: why are devs allergic to just using Linux natively? At least I understand why Orbstack is useful, I don't know why containerizing MacOS itself is.
What's the licensing situation on this? Would I be distributing parts of macOS in my containers? I don't think Apple is OK with that.<p>Or is this <i>just</i> the fully open source Darwin core? That wouldn't likely be super compatible with a ton of production software? I need more explanation of what is actually going on here because it sounds like a good way to get sued.
Reminds me: Still waiting for native ARM support on GitHub Actions <a href="https://github.com/actions/runner-images/issues/5631">https://github.com/actions/runner-images/issues/5631</a>
<a href="https://github.com/macOScontainers/macos-jail">https://github.com/macOScontainers/macos-jail</a> - new code<p><a href="https://github.com/macOScontainers/rund">https://github.com/macOScontainers/rund</a> - new code<p><a href="https://github.com/macOScontainers/moby">https://github.com/macOScontainers/moby</a> - fork, 6 commits<p><a href="https://github.com/macOScontainers/buildkit">https://github.com/macOScontainers/buildkit</a> - fork, 4 commits<p><a href="https://github.com/macOScontainers/containerd">https://github.com/macOScontainers/containerd</a> - fork, 5 commits<p>Would be interesting to see if they can get moby/buildkit/containerd changes upstreamed
I feel cheated by Apple a little bit.<p>I bought an Apple Silicon machine after their presentation claiming that they would have first class docker support, but the reality has been that while the first docker worked well as it was translated, now it wants to default to arm containers and it has become very difficult to use because it doesn't want to use Rosetta 2 containers.<p>The whole point of using docker is to use the same containers in production as you use in development, so having docker default to these random arm containers means that my containers aren't exactly production, because they are arm based and the servers are not.<p>I understand that docker is the developer of docker software, but I really wish I could just click a button and force intel based containers in docker as the default and have to opt-in to arm.<p>If anyone has an easy solution to this let me know. I don't want to spend hours and hours figuring out docker on my mac.
This is a cool idea and an impressive project.<p>At the same time, I don't truly understand why anyone would need to use it. If your preference is to totally work with macOS, then I'm sure this would be perfect for that. Otherwise, what's the advantage?<p>VMs have really come a long way. Every major OS today has a virtualization framework that makes running another OS extremely performant. Docker on macOS uses a virtual machine, but so what? Performance of individual containers, in my experience, isn't really a problem unless you're doing something with the GPU, and even then there are ways to deal with that. Even a fully-emulated VM using QEMU (without hypervisor or KVM) won't have any noticeable performance penalties in many cases.<p>IMO, there's a much greater advantage to sticking with Linux. Even if the host isn't Linux, developing and deploying with Linux guests provides a tremendous level of consistency and portability.<p>But maybe I'll be proven wrong by this project someday soon!
What my dream is that the User Mode Linux is made into a cross-platform userspace binary that translates syscalls transparently between itself and the host. So you might get "drivers" that talk to Windows, Linux, *BSDs, Darwin, it manages memory in an efficient (for the host) way, and enables you to run any kinds of wild experiments with, say, virtualized and passed-through serial devices, USB devices, networking, bind-mounting from the host and image mounts. And yes, containers. All of that without needing host root in most cases.<p>Of course the drawback would be that the host would see just a fat Linux process and its child processes, much like you can see qemu, but it could be an interesting thing nonetheless, if even for shits and giggles of it.
When macOS runs on Unix kernel and Linux systems are the best supported for containerisation and I assume are much more lightweight than macOS, I personally don't see any reason to run macOS in a container.
Can anyone speak to how the macOS runners on GitHub actions work? It would seem from this post that containers of any kind for macOS are a brand new thing..
the amount of engineering hours wasted making macos usable for backend dev work and then wasted again from inefficiency due to that failure is staggering.<p>linux is great. macos is great. windows is great too. for their intended purposes.<p>it’s horseless carriages all the way down.
MacOS is - by choice - an Apple controlled walled garden.<p>Trying to break out of that is an exercise in futility.<p>Can you come up with situations where I would run a container instead of just running an app or sys service?
caveat: this is based on rund. Extract from the readme:<p>rund is an experimental containerd shim for running macOS containers on macOS.<p>rund doesn’t offer the usual level of container isolation that is achievable on other OSes due to limited macOS kernel API.<p>What rund provides:<p><pre><code> Filesystem isolation via chroot(2)
Cleanup of container processes using process group
OCI Runtime Specification compatibility (to the extent it is possible on macOS)
Host-network mode only
bind mounts</code></pre>
I use MacOS and am very positive about it. I have lots of reasons to run Linux containers. What are some reasons I might want to run a MacOS container?
Unrelated to containers themselves: how do you make a patch when no version was released? I mean, people call this "semantic" versioning, but then spit in the face of those semantics...
It's sad to see so many negative comments for this. I get it's not an ideal place to start for macOS containers, but it's a start. Apple isn't doing it, so the community has to. Once you have a start, you can iterate on it. It might not be great now, but hopefully this makes it possible in a year or so. Who knows, maybe this is the kick Apple needs, and maybe they'll hire the devs of this project to fully work on this.
Sorry, not disabling SIP for something that I can already do without needing to nobble security policies (and have them reset/impossible due to MDM). If there was user/networking space in Darwin then maybe I'd be interested but...
It’s remarkable that Apple doesn’t have a first party solution to this yet. They used be, or aspire to be, at the forefront of OS research.“The most advanced Unix”.<p>They’re not even trying, now.
<i>cries in Asahi Linux</i><p>macbook is the best laptop there is but macos...<p>can't wait for a stable release of Asahi and permission from corporate to install it even in a VM somehow. probably won't happen, but one can dream.