Comment by paxys

In case you're wondering, the Hypervisor.framework C API is really neat and straightforward:

1. Creating and configuring a virtual machine:

    hv_vm_create(HV_VM_DEFAULT);

2. Allocating guest memory:

    void* memory = mmap(...);
    hv_vm_map(memory, guest_physical_address, size, HV_MEMORY_READ | HV_MEMORY_WRITE | HV_MEMORY_EXEC);

3. Creating virtual CPUs:

    hv_vcpu_create(&vcpu, HV_VCPU_DEFAULT);

4. Setting registers:

    hv_vcpu_write_register(vcpu, HV_X86_RIP, 0x1000); // Set instruction pointer
    hv_vcpu_write_register(vcpu, HV_X86_RSP, 0x8000); // Stack pointer

5. Running guest code:

    hv_vcpu_run(vcpu);

6. Handling VM exits:

    hv_vcpu_exit_reason_t reason;
    hv_vcpu_read_register(vcpu, HV_X86_EXIT_REASON, &reason);

One of the reasons OrbStack is so great is because they implement their own hypervisor: https://orbstack.dev/

Apple’s stack gives you low-level access to ARM virtualization, and from there Apple has high-level convenience frameworks on top. OrbStack implements all of the high-level code themselves.

Using a hypervisor means just running a Linux VM, like WSL2 does on Windows. There is nothing native about it.

Native Linux (and Docker) support would be something like WSL1, where Windows kernel implemented Linux syscalls.

Every container system is "docker-like". Some (like Podman) even have a drop-in replacement for the Docker CLI. Ultimately there are always subtle differences which make swapping between Docker <> Podman <> LXC or whatever else impossible without introducing messy bugs in your workflow, so you need to pick one and stick to it.

Yeah, from a quick glance the options are 1:1 mapped so an

  alias docker='container'

Should work, at least for basic and common operations

OS X pulls some components of FreeBSD into kernel space, but not all (and those are very old at this point). It also uses various BSD bits for userspace.

Good read from horse mouth:

https://developer.apple.com/library/archive/documentation/Da...

„Container“ is sort of synonymous with „OCI-compatible container“ these days, and OCI itself is basically a retcon standard for docker (runtime, images etc.). So from that perspective every „container system“ is necessarily „docker-like“ and that means Linux namespaces and cgroups.

Conceptually similar but different implementations. Containers uses cgroups in Linux and there is also file system and network virtualization as well. It's not impossible but it would require quite a bit of work.

Another really good read about containers, jails and zones.

https://blog.jessfraz.com/post/containers-zones-jails-vms/

BSD jails are architected wholly differently from what something like Docker provides.

Jails are first-class citizens that are baked deep into the system.

A tool like Docker relies using multiple Linux features/tools to assemble/create isolation.

Additionally, iirc, the logic for FreeBSD jails never made it into the Darwin kernel.

Someone correct me please.

Unless you need to have a working video or audio config as well.

Using the Linux filesystem has almost no performance penalty under WSL2 since it is a VM. Docker Desktop automatically mounts the correct filesystem. Crossing the OS boundary for Windows files has some overhead of course but that's not the usecase WSL2 is optimized for.

With WSL2 you get the best of both worlds. A system with perfect driver and application support and a Linux-native environment. Hybrid GPUs, webcams, lap sensors etc. all work without any configuration effort. You get good battery life. You can run Autodesk or Photoshop but at the same time you can run Linux apps with almost no performance loss.

Aren't the syscalls a constant moving target? Didn't even Microsoft fail at keeping up with them in WSL?

FreeBSD and NetBSD do this.

They didn't.

It would probably be slower than just running a VM.