container

Traditional containers like docker desktop need a vm to run its each container. So all container you spin up is store in this always on shared Linux kernel.apple introduced a opensource container project that creates tiny, light weight vm for each of the container you spin up, so when container stopps vm stops.This uses macos virtualisation framework(inbuilt mac os hyperviser{like virtual box, VMware,parallels etc} for M series) , vmnet framework (networking, how processes inside vm will connect to outside world), xpc(cross process communication,using it inter software process communicates with each other). But one question so if this new method of running docker images with each having its own vm, how buildkit will work because it needed to be in kernal environment to build your image and there is no shared vm linux environment alrea

I am skeptical there are many real use cases that require native macOS not arbitrary unix. For files, use a readonly mount https://github.com/apple/container/blob/main/docs/how-to.md#... (ie. /path:ro)

recommend converting to https://github.com/apple/container

I am not (purposefully) granting them the benefit of the doubt. In my comment I simply noted that the comments there are extremely anti-Apple yet without any solid arguments behind them, and I also noted that the whole thing is just because of an APFS flag which could be fixed from Asahi's side. The main reason I made the comment is because I am shocked at how poorly backed the arguments are. As for Apple not helping the Linux team, why would they, or any major OEM? Apple is perfectly happy with https://github.com/apple/container

> 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. More details, including technical limitations (they’re looking for bug re

> Just to clarify, this requires Mac OS 26 Tahoe for "container" doesn't it? Yes’n’t: https://github.com/apple/container/blob/main/docs/technical-... > container relies on the new features and enhancements present in macOS 26. You can run container on macOS 15, but you will need to be aware of some user experience and functional limitations. There is no plan to address issues found with macOS 15 that cannot be reproduced on macOS 26. The issues are around networking.

It's called a container machine but it's a virtual machine. I quote from https://github.com/apple/container/blob/main/docs/technical-... > 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

Apple does have an OCI variant of this: https://github.com/apple/container Doesn’t seem to have Compose support though, but it’s probably not impossible to build upon. And of course, it also uses VMs, though unlike Docker, it’s one (micro-?) VM per container: https://github.com/apple/container/blob/main/docs/technical-...

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 ability to run multiple containers on a single Mac would end up turning a 10 Mac Mini order into a 2 Mac Minis order for most people. Rest assured, even if it would be technically possible they'd find a way to cap it somehow via the EULA or whatever

https://github.com/apple/container/blob/main/docs/technical-... read documentation mr. rare breed

It's funny that the system config page (https://github.com/apple/container/blob/main/docs/container-...) lists pebibytes for RAM configurations... in this day and age where buying a 16GB stick for workstation would cause me to eat instant ramen for a couple of months because my dentist needs an LLM chatbot on their page to stay competitive! UX wise it looks kinda neat though!

Thanks for the info kdrag0n! Big fan of OrbStack; good call out on dynamic memory. If the guest image has /sbin/init, we use that. We'd recommend using a base image for the guest that includes systemd. ie: https://github.com/apple/container/blob/main/docs/container-...

Is this new? I thought we had this already In my testing (iirc) filesystem performance was not good enough to be usable with node/rust dev where lots of small files get stat-ed update: what's new is the `container machine` subcommand. I went to test it out, but container failed to run at all for me: https://github.com/apple/container/issues/1681

Do these containers share a common kernel? Or are they each ran in a separate VM? Edit: It's a VM per container. https://github.com/apple/container/blob/main/docs/technical-...