301–310 of 457 posts
Earlier quoted context omitted.
https://github.com/apple/container/blob/main/docs/technical-... read documentation mr. rare breed
Like, this doesn’t answer when to use this vs Docker. Any reference there?
Earlier quoted context omitted.
it differs by lacking all the cool options that makes vmware and virtualbox good products, but apple users will praise it as a benefit "bind mounts? I'm better without it"
Funny how confidently people can mock while knowing nothing about the specific tech discussed and the different targets. I'd google: VirtualBox vs containers.
> container runs containers differently. Using the open source Containerization package, it runs a lightweight VM for each container that you create. This approach has the following properties:
> * Security: Each container has the isolation properties of a full VM, using a minimal set of core utilities and dynamic libraries to reduce resource utilization and attack surface.
> * Privacy: When sharing host data using container, you mount only necessary data into each VM. With a shared VM, you need to mount all data that you may ever want to use into the VM, so that it can be mounted selectively into containers.
> * Performance: Containers created using container require less memory than full VMs, with boot times that are comparable to containers running in a shared VM.
So: you build it as a container image and MacOS starts a VM to run it.
Edit: quite unusually for a container it runs systemd. They give an example "systemctl start postgresql".
Earlier quoted context omitted.
sandbox profiles?
macOS sandboxing is deliberately limited just enough to prevent anyone from truly implement Darwin-on-Darwin containers. People have been discussing about this for a while, see https://github.com/apple/container/discussions/611 In general I understand the rationale behind Apple's decision. They sell hardware, and there's real demand for macOS on servers to run build jobs and other Mac-only tools. Giving you the abili…
Earlier quoted context omitted.
Ah, the Darwin/BSD Subsystem for Linux.
Not quite, it’s still a VM. And while it supports virtio balloon for growing RAM, it doesn’t yet support releasing that RAM back to the host. And there isn’t a convenient way to shrink the sparse disk images as they grow yet, either.
To clarify a few comments here: this is not only OCI containers: container machines add support for persistence and filesystem mounting, making container machines a great lightweight Linux environment for developers using macOS. More details here: https://developer.apple.com/videos/play/wwdc2026/389
Still feels like a apple-ified microvm
Earlier quoted context omitted.
Very different: Linux running in a virtual machine can't bind mount into a macOS host's filesystem. So they use virtiofs.
This applies to both containers and container machines though, right?
Depending on your threat model, that's fine, but a lot of people (including me) will say that containers are not a security mechanism.
But macOS requires[1] virtualisation for containers anyway; the security is just a bonus.
[1] at least for a real Linux kernel...
OrbStack works really well for me. I wonder how it’s compared to this performance wise
(OrbStack dev here.) Instead of Virtualization.framework, we have a custom Rust virtualization stack with custom devices and protocols for things like filesystem sharing. It's a highly optimized vertically integrated stack specifically for running our Linux machines and containers. Our biggest perf/resource gain is dynamic memory, which reduces memory usage a lot by releasing unused memory back to macOS. Nothing else…
This is all fine and dandy, but where are the native Darwin Jails Apple? Still scared that people will filling whole rooms of Mac Minis if you allow them to have multiple macOS containers and not only up to two fat VMs per machine?