> It's interesting that Apple said they were working with Docker to make sure MacOS on ARM is a first class host for Linux Docker containers.

I wish Apple would actually natively support containers, rather than supporting containers via a linux VM.

I only presume this will be called Apple Orchards.

what do you mean? docker for Mac uses xhyve, which uses Hypervisor.framework aka “kvm”. wsl1 had a wine-style syscall shim but they switched to virtualization too for wsl2.

Right, and and xhyve, Hypervisor.framework, and kvm are all frameworks for creating and running virtual machines. In contrast, Docker for linux runs using a native container mechanism without using a VM at all. macOS doesn't support containers, but it could.

The general case is developing software on a desktop OS in containers that are intended to be deployed on Linux boxes. Since the whole point of containers is that the container runs against the host OS kernel directly, clearly that is not really possible on a desktop that isn't running Linux as there isn't a Linux kernel there to run against. there are two ways past this. Emulate a Linux kernel, or run a real linux kernel in virtualisation for the container to run against

WSL 1 chose the first approach so the container thought it was running against a Linux kernel but it was actually a windows kernel plus a syscall shim. That's all fine and dandy in theory, but not running against real Linux means there was always the risk of different behaviour on Windows versus on the Linux deployment host. In WSL 2 Microsoft switched to running a real linux kernel in a hypervisor, which is basically the same approach as on the Mac.

> xhyve, Hypervisor.framework, and kvm are all frameworks for creating and running virtual machines

> In contrast, Docker for linux runs using a native container mechanism without using a VM at all

Thanks for pointing this out. As I'm slowly getting familiar with container-based workflows and underlying technology, your statement helped clear up my confusion about the essential differences between containers and VMs.

I found an informative table in Microsoft's documentation for "Containers on Windows", that compares and contrasts the two approaches:

Containers vs. virtual machines - https://docs.microsoft.com/en-us/virtualization/windowsconta...

This helped me understand how Docker for Mac using xHyve is different from Docker on Linux with native containers as a much thinner layer with a shared kernel.

---

According to this article:

Beating some performance into Docker for Mac - https://medium.com/homullus/beating-some-performance-into-do... (July 2020)

Aside from the container/VM architecture, a performance bottleneck of Docker for Mac is (apparently) how mounted volumes work, on the file system level.

---

> macOS doesn't support containers, but it could

According to a random Reddit thread (so, with a grain of salt) I found on this topic:

Docker on the new Mac Big Sur - https://www.reddit.com/r/docker/comments/he0v5c/docker_on_th...

> Using a shared kernel container (via cgroups, for example) isn't feasible with macOS because of licensing restrictions and because the Linux syscall interface isn't compatible with macOS.

Which seems to imply that there's some fundamental reason why Docker for Mac must rely on VMs, that macOS is not (yet?) capable of providing containers that are as native as on Linux.

They also mention how the file system on macOS has design limitations that make containers more difficult.

> The net result is that performance is probably going to be near-native for light workloads, but macOS depends on other fundamental technologies like APFS which aren't designed for datacenter type workloads.

---

EDIT: Aah, right, this is why a comment higher up mentioned:

> Apple said they were working with Docker to make sure MacOS on ARM is a first class host for Linux Docker containers.

I thought docker on Mac used a virtual machine + disk resulting in slower file io? As opposed to running containers directly against the host kernel / file system like Linux.

MS hasn’t stolen anything. WSL is still just that, a subsystem. Not native Unix.