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.)
(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
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.
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.
Not sure that would be the case since it also includes this part
Running Linux on Apple hardware would not follow that part of the EULA.
good thing I can't think of any reason to run macos.
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
well put.
Some unfortunately needs Xcode for building iOS or macOS apps locally even if you are coding in unity, flutter, react native, qt, unreal
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.
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.
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.
This requires kvm exposed in the container. Does docker on mac support kvm?
AFAICT, with QEMU, access to KVM is only required if you care about performance %) Otherwise it can emulate everything for you.
This dockerfile explicitly enables kvm in a way that will cause qemu to fail if it's not present.
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.)
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.
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.
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/
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.
Via surprise audits from organisations like BSA, in collaboration with the police.
https://www.bsa.org/
For organizations, sure, but has this ever been done to an individual?
Individuals most likely not.
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.
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).
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.
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.
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.
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
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.
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.
This youtube-dl?
https://github.com/ytdl-org/youtube-dl
Did it get taken down again? The takedown I remember was a few years ago, and GitHub announced some policy changes to make it harder for that to happen when they very loudly reinstated it:
https://github.blog/news-insights/policy-news-and-insights/s...
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.
Ubuntu 24.04 is a disaster in my mid-2015 MBP. Ubuntu 22.04 is surprisingly good though.
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.
How do you define "veteran"? I've been a Linux-only user for 10 years, and 9.5 of it is strictly with Kubuntu.
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.
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.
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.
My guess is that macOS on Hyper-V is faster.
Who cares lol
I don’t think Apple would feel very threatened by this indeed. I share the who cares lol
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?
i remember making this joke a decade ago on the tonymacx86 forums, lots of people did it for the lulz
I like the moaning sound the EULA makes when it gets violated.
Hey, not if you run it on a mac running Asahi
Why are you talking as though this is a new project. It's been around for years
This repo is 4 years old... I don't think it's coming.