return to table of content

macOS in QEMU in Docker

nine_k
47 replies
11h24m

So, to clarify things: it's QEMU running in a container, and macOS running under QEMU inside it.

This is really nice WRT the ease of installation: no manual setup steps and all.

This likely expressly violates the [macOS EULA], which says: «you are granted a limited, non-exclusive license to install, use and run one (1) copy of the Apple Software on a single Apple-branded computer at any one time» — because the point is to run it not on a Mac. So, pull it and keep it around; expect a C&D letter come any moment.

[macOS EULA]: https://www.apple.com/legal/sla/docs/macOSMonterey.pdf (Other versions contain the same language.)

jbverschoor
24 replies
11h15m

(iii) to install, use and run up to two (2) additional copies or instances of the Apple Software, or any prior macOS or OS X operating system software or subsequent release of the Apple Software, within virtual operating system environments on each Apple-branded computer you own or control that is already running the Apple Software, for purposes of: (a) software development; (b) testing during software development; (c) using macOS Server; or (d) personal, non-commercial use

nine_k
16 replies
10h37m

Indeed. That would cover a conventionally installed VM, like VirtualBox.

But this is packaged as a Docker image, and Docker is Linux-specific. Linux is not officially supported by Apple on their hardware, and is certainly not prevalent on it. I doubt that the intended target audience of this project is limited to Asahi Linux.

exe34
7 replies
9h57m

I run Linux on a Mac book air, so this would allow me to run macos in a controlled environment if I could think of a good reason to do so.

EspadaV9
6 replies
8h5m

Not sure that would be the case since it also includes this part

that is already running the Apple Software

Running Linux on Apple hardware would not follow that part of the EULA.

exe34
3 replies
7h22m

good thing I can't think of any reason to run macos.

ramses0
1 replies
6h33m

The Tao of Programming, 7.3:

""" "Corporate Headquarters has commanded," continued the magician, "that everyone use this workstation as a platform for new programs. Do you agree to this?"

"Certainly," replied the master, "I will have it transported to the data center immediately!" And the magician returned to his tower, well pleased.

Several days later, a novice wandered into the office of the master programmer and said, "I cannot find the listing for my new program. Do you know where it might be?"

"Yes," replied the master, "the listings are stacked on the platform in the data center." """

https://quasi.in/digital/ttop.html#Book7

exe34
0 replies
6h28m

well put.

pzo
0 replies
4h49m

Some unfortunately needs Xcode for building iOS or macOS apps locally even if you are coding in unity, flutter, react native, qt, unreal

rfoo
1 replies
6h4m

I believe it matches the base term, as you are allowed to run only one copy of the Apple software on an Apple hardware, unconditionally.

It could be in a VM.

thfuran
0 replies
5h54m

And I guess once you've booted the VM, you are suddenly permitted to boot two more, as long as you have a lawyer on retainer just in case.

rbut
3 replies
10h22m

Docker can run on macOS (albeit in a VM), but its still running on a Mac "that is already running the Apple Software". So its a perfectly valid option for Mac owners, even if its a VM + container + VM deep.

monocasa
2 replies
8h52m

This requires kvm exposed in the container. Does docker on mac support kvm?

nine_k
1 replies
8h4m

AFAICT, with QEMU, access to KVM is only required if you care about performance %) Otherwise it can emulate everything for you.

monocasa
0 replies
7h44m

This dockerfile explicitly enables kvm in a way that will cause qemu to fail if it's not present.

jkaplowitz
2 replies
5h51m

Docker actually ships their easy-to-use and commercially supported Docker Desktop product for macOS, which uses Apple's standard virtualization framework under the hood. I think it then runs the Docker containers within a Linux VM that it manages.

For people who want an open-source CLI solution rather than a commercial product which for larger businesses requires payment, there's also colima which does roughly the same thing.

So, lots of people very successfully use Docker on macOS, including on Apple hardware.

This particular software would need nested virtualization to be highly performant, but at least on M3 or newer Macs running macOS 15 or newer, this is now supported by Apple's virtualization framework:

https://developer.apple.com/documentation/virtualization/vzg...

So, if that's not easy to do in a useful and performant way now, it will absolutely be possible in the foreseeable future. I'm sure that the longtime macOS virtualization product Parallels Desktop will add support for nested virtualization quite soon if they haven't already, in addition to whatever Docker Desktop and colima do.

(Tangent: Asahi Linux apparently supports nested virtualization on M2 chips even though macOS doesn't.)

nine_k
1 replies
3h12m

Running Linux in a VM (for Docker) to run an emulator (QEMU) in it to run macOS in that looks to me like a senseless waste of resources. Linux and Docker add no value into the mix here.

The same result can be achieved by running macOS right in the VM. This can be extra efficient since both the host OS and the guest OS are macOS, and the VM could use this fact.

It may make sense to run macOS in an emulator like QEMU under macOS, if the host version us ARM and the guest version is x64 (or vice versa). But I don't see where Linux and Docker would be useful in this case.

jkaplowitz
0 replies
34m

I agree the particular combo I was discussing is likely not very useful when compared to just directly virtualizing macOS directly, except in niche cases.

One such case, however, is when the user is already managing Linux Docker containers for other parts of their development or testing workflow and wants to manage macOS containers with the same tooling. That’s legitimate enough, especially when it ends up supporting nested virtualization of the same architecture and not true emulation, to keep the performance penalty modest enough.

prmoustache
0 replies
10h31m

I doubt that the intended target audience of this project is limited to Asahi Linux.

I guess that part of the license is meant to automatically disqualify an apple branded computer running a linux distro as host OS from running MacOS in a VM: "on each Apple-branded computer you own or control that is already running the Apple Software"

Some smart ass might argue that "already running the Apple software" doesn't mean at the exact same time but more like "I am still running it sometimes as dual boot" but I am not sure this would pass the court test.

And since I believe docker on MacOS runs on linux VM, so this would be running qemu on top of a linux vm on top of MacOS.

I can't see any legit use of this. Anyone who would need automatized and disposable environments for CI/CD would simply use UTM on mac minis: https://docs.getutm.app/scripting/scripting/

wildzzz
6 replies
3h48m

So basically you can run macOS however you want as long as you're already running macOS on Apple hardware.

The question I've always had is how enforceable is that really? Obviously the whole point of Apple making macOS freely available is to run it on Apple hardware. They don't give it out for free to run on other hardware but can they really do anything about that other than require you to enter a serial number to download an image? If they really cared, they would just do something like hashing the serial number and current date and time against a secret key (maybe inside a read-only portion of the TPM) and only Apple would be able to verify that the hardware is legit. You would need to somehow expose the TPM to the hypervisor to be able to generate hashes for macOS to verify it's license. Clearly this is not a huge problem for Apple because they would already be doing this if it was an issue.

pjmlp
2 replies
2h15m

Via surprise audits from organisations like BSA, in collaboration with the police.

https://www.bsa.org/

skeaker
1 replies
1h17m

For organizations, sure, but has this ever been done to an individual?

pjmlp
0 replies
41m

Individuals most likely not.

obituary_latte
1 replies
3h31m

Probably as enforceable as any other EULA. Windows surely has similar language. I'd guess that somewhere buried deep in the agreements, or somewhere, it says they can audit your usage somehow. Does it ever happen? I'd be curious to know.

naikrovek
0 replies
1h52m

Windows doesn’t have similar language. Not directly, anyway. Depending on the edition of Windows you purchase and how your overall license agreement works, you get anywhere from zero to ten VM licenses per paid Windows license.

I’m omitting a few details for brevity (MS licensing is nuts when you get into the weeds).

angulardragon03
0 replies
3h4m

It’s sort of enforceable - Apple’s own virtualisation framework that lots of VM providers use (on Apple Silicon) actually enforces a hard cap of two guests, and won’t allow you to spawn more.

With other hosts, it’s kind of an Adobe approach - you either weren’t gonna buy a Mac anyways, or you might be tempted to buy a Mac after using macOS in a VM. Realistically, it’s not worth Apple coming after you unless you’re an enterprise making your money by breaking the EULA.

actionfromafar
5 replies
8h20m

How much of these EULAs are actually enforceable though, and in which jurisdictions?

Also, wouldn’t it be the end user potentially in violation of the EULA, not the git repo provider?

Edit: agreed about OS images, that does not look legit.

nine_k
2 replies
7h58m

Fair. But the docker image provider would be in violation, never having received a license to redistribute macOS images. Without these, the seamless usability aspect is gone, though the repo remains pretty useful because it automates all other steps.

windexh8er
1 replies
5h31m

It's trivial to build these containers by grabbing the install images from Apple directly. Beyond that this is all covered in the documentation.

I guess I'm curious why you're so focused on this violating anything? Apple clearly doesn't care as folks like myself have used it for years. Apple's target market is hardware buyers, not people who do things like this. If this actually impacted sales, sure - but Apple doesn't sell OSX anymore.

As an aside the sickcodes work is great for people wanting to leverage Apple's "Find My" network with non-Apple devices by leveraging OpenHaystack [0].

[0] https://github.com/seemoo-lab/openhaystack

rty32
0 replies
5h6m

I assume EULA is mainly intended for preventing companies from running Hackintosh at a massive scale than aimed at individuals -- although build your business/infrastructure based on Hackintosh is a very questionable business and technical decision by itself.

7bit
1 replies
7h59m

GitHub repost are taken down all the time because they offer means to violate EULAs. See youtube-dl which was taken down couple of months back.

m463
3 replies
9h45m

You can run linux on a mac. In fact older intel used macs are inexpensive and run pretty well with little noise.

ubuntu installs and runs easily. Other versions of linux - it depends.

dqh
2 replies
6h21m

Ubuntu 24.04 is a disaster in my mid-2015 MBP. Ubuntu 22.04 is surprisingly good though.

resource_waste
1 replies
4h56m

To be fair, I'm not sure any linux veterans are using Ubuntu. Its a popular OS, but its not a good OS. (Think terrible pop music that teenagers will still listen to)

Even Debian has lost its favorability by having sooo much legacy bloat, bugs, and outdated kernels that wont run Nvidia GPUs(2023) or other recent peripherals.

I'd be much more curious how Fedora or OpenSUSE hold up.

skeledrew
0 replies
3h47m

How do you define "veteran"? I've been a Linux-only user for 10 years, and 9.5 of it is strictly with Kubuntu.

znpy
1 replies
10h9m

you are granted a limited, non-exclusive license to install, use and run one (1) copy of the Apple Software on a single Apple-branded computer at any one time»

In that case... If I run Asahi Linux on my apple-silicon macbook pro as main operating system and then run macOS in a container I should be fine.

prmoustache
0 replies
10h5m

See the rest of the license, the host must be "already running the MacOS operating system" which I understand as host OS, not as capable of still running it because the sshd hasn't been wiped of a MacOS install.

user_7832
1 replies
9h25m

So, to clarify things: it's QEMU running in a container, and macOS running under QEMU inside it.

A bit tangential but is this more performant/"better" than running MacOS on say Hyper-V? I understand my zen 4 laptop anyway won't allow GPU acceleration, I'm only looking to run a few apps (and maybe Safari) on it.

ptspts
0 replies
7h3m

My guess is that macOS on Hyper-V is faster.

elliotto
1 replies
9h37m

Who cares lol

mosselman
0 replies
6h27m

I don’t think Apple would feel very threatened by this indeed. I share the who cares lol

ctoth
1 replies
2h57m

Can I get a whole bunch of Apple stickers and brand the heck out of an old Dell r630 Server and run this on it? Or how about a cattle brand with an Apple logo?

arilotter
0 replies
24m

i remember making this joke a decade ago on the tonymacx86 forums, lots of people did it for the lulz

riiii
0 replies
5h21m

I like the moaning sound the EULA makes when it gets violated.

promiseofbeans
0 replies
5h57m

Hey, not if you run it on a mac running Asahi

manojlds
0 replies
7h22m

Why are you talking as though this is a new project. It's been around for years

hundchenkatze
0 replies
6h20m

expect a C&D letter come any moment.

This repo is 4 years old... I don't think it's coming.

dariosalvi78
8 replies
12h15m

Can this run xcode?

XiS
5 replies
11h45m

I tried this last year. It works though it's pretty slow.

I really hate having to also support the Apple ecosystem. Development, CI/CD integration is really poor without having to buy the hardware.

keyle
3 replies
11h26m

I run full apple hardware and < 2 years old and the damn thing is still pretty slow.

KronisLV
2 replies
11h23m

I have an M1 MacBook Air and the iPhone 2022 SE, so far the performance of both is pretty good!

However, the prices are definitely outside my regular budget (needed it for an iOS app project cause of walled garden ecosystem) and I only got the 8 GB MacBook which in hindsight very much feels like a mistake, even with the exorbitant pricing for the 16 GB model.

For the price of the 8 GB model I could have gotten a nice laptop with 32 GB of RAM built in. That said, I don’t hate the OS, it’s all quite pleasant and performs well.

prmoustache
0 replies
10h29m

He is meaning the performance of MacOS in docker is pretty slow on "native" MacOS hardware, not that his 2y old hardware has become slow.

evnix
0 replies
10h4m

Next time, just get a mac mini and plug in an external ssd

pzo
0 replies
4h43m

Honestly development in xcode is poor even on apple hardware.

slivanes
0 replies
12h9m

According to the readme on github, yes, although it takes about an extra 30GB of drive space.

jayd16
0 replies
1h50m

Is it needs to emulate Intel macos, I wonder how many more xcode versions will be supported. Is the full release of 16 even going to support Intel?

xandrius
7 replies
6h27m

I'd love to try and see if it's possible to simply build for iOS. Say Unity, React Native, etc.

This could be pretty awesome in terms of freedom, even if the build takes 5x more.

arcanemachiner
2 replies
6h23m

I did this. I had to share my USB port over Docker somehow (black magic I guess, instructions in the repo) and I was able to build iOS apps and run them on an iPhone.

flawn
1 replies
5h50m

What was the speed like?

arcanemachiner
0 replies
2h49m

For a basic Flutter app: tolerable

ProfessorZoom
2 replies
6h9m

That would impressive if you could build for React Native iOS (with native Swift modules) and run it on a simulator in this on a Windows machine

arilotter
0 replies
25m

you can! you can also run it on a real iOS device using this tech. it's explicitly documented in the repo :)

airstrike
0 replies
4h17m

At glacial speeds, indubitably.

shepherdjerred
0 replies
2h14m

Cross-compiling is likely a better approach: https://github.com/tpoechtrager/osxcross

This is how Godot targets iOS: https://github.com/godotengine/build-containers/blob/main/Do...

Here's a Docker image with the tools preinstalled, though you'll need some tweaks to target iOS: https://github.com/shepherdjerred/macos-cross-compiler

While at RStudio (now called Posit), I worked on cross-compiling C/C++/Fortran/Rust on a Linux host targeting x86_64/aarch64 macOS. If you download an R package with native code from Posit Package Manager (https://p3m.dev/client/), it was cross-compiled using this approach :)

Izmaki
7 replies
10h20m

I really hate when "USB Passthrough" is used in situations when, at best, a "USB over ethernet proxy" is what is happening. That's not passthrough... It introduces a whole range of disadvantages that regular passthrough does not (and advanced passthrough might not) have.

arghwhat
6 replies
9h42m

Eh? QEMU USB passthrough is true USB passthrough. The problems with USB passthrough stem from issues related to USB controllers themselves and how device enumeration works, with the only better solution being PCIe passthrough of entire USB controllers... Which then present a different set of problems. Speaking from experience in large VM test farms with a significant amount of forwarded hardware.

(However, "USB over ethernet proxy" is also a true passthrough, just one with higher latency than VirtIO.)

Izmaki
3 replies
8h52m

I skimmed the README only and just saw the big section of USB over ethernet with the video image and everything, not the tiny mentioning of VFIO above it. Lol.

But tell me please, which problems do you have with PCIe passthrough?

Also speaking from experience in large VM test farms with a significant amount of forwarded hardware. I've never experienced problems with hundreds of machines doing exactly this, for years.

arghwhat
2 replies
8h34m

PCIe passthrough has a few quirks:

1. VMs operate on a copy of certain PCIe descriptors obtained during enumeration/when forwarding was setup, meaning that some firwmare updates that depend on these changing cannot work correctly. The exact details have left my memory.

2. Foo states that only happen when forwarding. Hardware that seems so stable when used directly that bugs would seem inconceivable enter into broken states when forwarded and fail to initialize within the VM.

Hardware and drivers are both full of bugs, and things become "fun" when either get surprised. You can deal with it when you're doing the forwarding your own hardware and using your own drivers so discovered issues can be debugged and sorted out, but it's much less fun when you're forwarding stuff from other vendors out of necessity.

Dealt with this one just this morning.

3. Reset bugs. Hardware reset and sequencing is a tricky area (speaking from old FPGA experience), and some devices cannot recover without a full power cycle.

In some cases, I can recover the device by stopping the forward, removing the device (echo 1 > /sys/bus/pci/devices/.../remove), rescanning and letting the host kernel temporarily load drivers and initialize the device, and then forward it again. Did that today.

4. Host crashes. Yay.

Forwarding a single device on a user machine that still gets regular reboots tends to work fine, but things get hairy when you scale this up. I've had to do a lot of automation of things like handing devices back to the hypervisor for recovery and firmware management.

Izmaki
1 replies
8h6m

Strange... Sounds like you may be doing too many things manually or that what you're testing is the device that is connected directly to USB?

In my case I need 3rd party USB devices (that always just work(™)) to communicate and interact with hardware. Been automating/running literally hundreds of these configurations without a single issue related to USB or PCI passthrough. Even got switchable HUBs for USB in the mix sometimes, too (for power cycling specific USB devices). Works fine as well.

arghwhat
0 replies
7h29m

"Manually"? There is only QEMU/KVM, how many layers you put in between does not matter. Proxmox is just a pile of perl scripts doing the same.

My experience is in testing both USB downstream devices and PCIe devices developed in-house. Some of the forwarded devices might be 3rd-party devices like hubs, relays for power cycling and USB isolators to simulate hot-plug, but the DUTs are stuff we manufacture.

In the USB test scenarios (we have about ~100 such machines, on average connected to a dozen DUTs, some more), the symptom of failure is generally that the entire controller can discover downstream devices but permanently fail to communicate with any of them, or that the controller itself fails to initialize entirely.

The PCIe test scenarios is not something I actively work with anymore, but involves a server room full of machines with 4-7 DUTs each and much more custom handling - such as hot-unplugging the device from the VM, resetting and firmware updating the device, and hot-plugging it back as part of the test running in that VM - as testing PCIe devices themselves exercise many more issues that you don't see with standardized hardware.

I have done this for about a decade, so I've been through a few iterations and tech stacks. One can find things that work, but it's not in any way or form guaranteed to work.

ThatMedicIsASpy
1 replies
9h19m

On proxmox with a USB DAC/AMP it is impossible to get correct audio without pcie passthrough of the usb controller

Izmaki
0 replies
8h50m

Yeah, isochronous mode is unfortunately not supported for USB passthrough on Proxmox. There were experimental implementations in oVirt back in the days (that is: experimental implementations in a non-prod, only-for-evaluation solution...).

prmoustache
5 replies
11h25m

Is the redistribution of MacOS images allowed by the license or is this project distributing illegal copies in plain sight on docker hub?

meatjuice
3 replies
7h22m

This is clearly illegal

diggan
2 replies
4h45m

"Illegal" might be a bit strong, "Against the EULA" a bit more realistic, which may or may not be illegal, depending on the context and involved country.

scintill76
1 replies
1h39m

I’m not a lawyer, but pretty sure unauthorized redistribution of copyrighted material is a crime (in the US.) This docker image contains Apple copyrighted files, probably, but anyone feel free to explain if I’m wrong.

tombert
0 replies
1h9m

I suspect that it probably doesn't matter; Apple has generally not cared about Hackintoshes as long as you aren't selling pre-made Hackintoshes. Apple probably doesn't really mind for stuff like this, since this probably isn't realistically eating much into Apple's market.

yao420
0 replies
5h0m

Idk but Correlium virtualizes iOS instances and was sued by Apple before settling the case.

JayDustheadz
5 replies
10h18m

Can this be launched on an M1 Mac? I'm trying to find a way to run a Big Sur VM on my M1 Mac on Monterey/Ventura.

dyllon
1 replies
10h13m

Couldn’t you use UTM to run a macOS VM?

JayDustheadz
0 replies
10h10m

Sadly it doesn't look like it: https://mac.getutm.app/ "Note that macOS VM support is limited to ARM based Macs running macOS Monterey or higher."

bspinner
1 replies
2h56m

Checkout tart: https://tart.run/quick-start/

It uses Apples Virtualization framework and works well, besides issues with virtiofs. But those can be worked around with virtual block devices aka images.

hamandcheese
0 replies
1h41m

+1 for Tart (and seconded on avoiding virtiofs - which as a virtualization.framework problem, not and indictment on Tart's quality).

orbat
0 replies
8h13m

Have you run into Viable https://eclecticlight.co/virtualisation-on-apple-silicon/ or VirtualBuddy https://github.com/insidegui/VirtualBuddy ? I think at least Viable has some limitations though

Edit: "some" limitations is putting it lightly. From https://eclecticlight.co/2022/11/17/lightweight-virtualisati... which is apparently still current:

Apple’s current implementation of lightweight virtualisation still has no support for Apple ID, iCloud, or any service dependent on them, including Handoff and AirDrop. Perhaps the most severe limitation resulting from this is that you can’t run the great majority of App Store apps, although Apple’s free apps including Pages, Numbers and Keynote can still be copied over from the host and run in a guest macOS.

Same deal with VirtualBuddy, apparently the root of the problem is that some sort of hardware validations fail in VMs https://github.com/insidegui/VirtualBuddy/discussions/27

slivanes
4 replies
12h22m

I wonder if progress will halt once newer versions of MacOS without Intel support are released?

Can I run docker inside this container to get MacOS to run inside MacOS? ;)

vbezhenar
1 replies
11h48m

Theoretically you can always run qemu in full emulation mode.

itsTyrion
0 replies
4h8m

And practically even a minimal debian install takes minutes to boot to TTY with qemu-aarch64 on AMD64

fragmede
0 replies
11h46m

I mean you can just do that in any supported vm program.

ProfessorZoom
0 replies
6h8m

we must go deeper

daft_pink
2 replies
3h21m

This would be awesome to run iCloud sync on my homeserver. Currently, there is no good way to physically backup iCloud on a homeserver/nas, because it only runs on windows/apple.

bm3
0 replies
50m

How would this help with that? What would this let you do that's different than just rsync'ing your iCloud folder from a connected Mac/PC to your NAS?

cranberryturkey
2 replies
13h21m

Does this work with kde/wayland?

rzzzt
0 replies
12h22m

It looks like the "vnc-version" Dockerfiles will set up an Xvnc server and direct QEMU's output to it, and you can connect to that using a VNC client. The standard version sets up X11 forwarding over SSH and/or you can pass the host's X11 socket and corresponding DISPLAY variable directly to the container.

QEMU also has its own built-in remote access capabilities (SPICE and VNC-based) but the former needs guest support.

duskwuff
0 replies
11h58m

It looks like it's running macOS under qemu (i.e. contained in a window), so I don't see any reason why it wouldn't.

nottorp
1 replies
7h36m

Docker-OSX now has a Discord server & Telegram! The Discord is active on #docker-osx and anyone is welcome to come and ask questions, ideas, etc.

No forum eh? Everyone should come to the live channels and ask the same questions again :)

42lux
0 replies
7h35m

Discussions are open on their repo...

misiek08
1 replies
10h58m

How many levels possible? Did anyone already try? I mean MacOS running on docker on MacOS running on docker on MacOS running on docker on MacOS...

bckr
1 replies
6h49m

Let’s say I wanted to run a headless Logic Pro for programmatic music production. Would I use this? Or should I containerize the application itself? It’s okay if I have to run it on Apple hardware.

replete
0 replies
6h20m

Depends on whether you have plugins requiring GPU acceleration, as there is none

synchrone
0 replies
7h11m

Any word if this would run the iOS simulator?

Edit: it actually does!

replete
0 replies
7h20m

The only chance at GPU acceleration is passing through a supported dGPU (>= AMD RX 6xxx @ 14.x, no chance modern nvidia) with PCI passthrough. Intel iGPUs work up to Comet lake, and some Ice Lake, but anything newer will not work.

Apple Silicon build of MacOS probably not going to be emulatable any time soon, though there is some early work in booting ARM darwin

Also Intel VT-x is missing on AMD, so virtualization is busted on AMD hosts although some crazy hacks with old versions of virtualbox can make docker kind of work through emulation

pmarreck
0 replies
4h17m

Now I just need a flake.nix that does the same thing lol (I don't like Docker...)

mjlee
0 replies
5h13m

Huh, why does this repo have its own glibc? Let's check the commit history:

    Self-host in the repo glibc to emphasize the temporariness of this patch
        sickcodes committed Feb 12, 2021
Seriously though, this is great.

arusahni
0 replies
6h49m

Looking forward to kicking the tires on this to validate functionality in Safari.

adamgordonbell
0 replies
6h41m

Not to be confused with native Mac OS "containers":

https://darwin-containers.github.io/

This parent project is VMs of OSX with a docker interface, I think.

Darwin containers are runc reimplemented in terms of MacOS chroot, so you do some isolation on native macs in a docker style.