Somewhat off topic but still highly relevant for people who actually want to use projects like this: why oh why do so many build recipes such as Dockerfiles insist on pulling random stuff off the internet as part of the build process?
For example, the Dockerfile in this project pulls in two Git repositories and a script at build time.
Besides the obvious build failures on heavily sandboxed build servers with no access to the internet, this forces anyone with even a little concern for security to do a full audit of any build recipes before using them, as merely studying and making available the dependencies listed in READMEs and build manifests like requirements.txt, package.json etc., is no longer enough.
I find this a very worrying development, especially given the rise in critical computer infrastructure failures and supply chain attacks we've seen lately.
amelius 180 days ago [-]
I really hate it when projects pull build files from the internet. Usually this happens unexpectedly. Besides the security issues that you mentioned, it also means that packaging software that depends on it becomes much more difficult and prone to unpleasant surprises, like when there is a version issue or when there is simply no internet, and of course the worst nightmare is if the dependency is not available anymore.
Self-contained distribution should be the norm.
doublerabbit 180 days ago [-]
The usage of Github within Go projects for dependencies is one of the reasons why I back away from using Go.
iforgotmysocks 178 days ago [-]
I am not familiar with Go, but if the package manager doesn't allow for arbitrary script to run(cough NPM cough) I reckon it's fine.
dbtablesorrows 180 days ago [-]
The answer is churn, my friend.
There's so much churn in devops space that nobody has time to figure out "the correct way" anymore.
nstart 180 days ago [-]
In this case, the individual did it for their own research purposes for security stuff. I looked at their profile. They have a demo running a modded version of Doom on a John Deere tractor display. This person definitely takes the time to figure stuff out :D .
lostlogin 180 days ago [-]
> John Deere
The right to repair and the right to rampage?
eropple 180 days ago [-]
It's a berserk pack, jeez. Rampage is by Midway. ;)
BossingAround 180 days ago [-]
Well, the correct path forward would be to wait for a large OSS player, like Red Hat, SUSE, Canonical, ..., and make the build secure.
Typically, Fedora and openSUSE have a policy that distributed packages (which includes container images) have to build with only packages from the repository, or explicitly added binaries during the build. So once you can `dnf/zypper install` something (or pull it from the vendor's container registry), you know the artifacts are trusted.
If you need to be on a bleeding edge, you deal with random internet crap shrug.
Of course a random OSS developer won't create offline-ready, trusted build artifacts. They don't have the infrastructure for it. And this is why companies like Red Hat or SUSE exist - a multi-billion dollar corporation is happy to pay for someone to do the plumbing and make a random artifact from the internet a trusted, reproducible, signed artifact, which tracks CVEs and updates regularly.
imglorp 180 days ago [-]
How is this different from JS pulling in tens of thousands of dependencies to display a web page?
In the 80s we envisioned modular, reusable software components you drop in like Lego bricks (we called it CASE then), and here we have it, success! Spoiler, it comes with tradeoffs...
judge2020 180 days ago [-]
Probably mostly to retain organization (via separate git repos) - in lieu of cloning stuff in Dockerfile, you end up needing a pre-build instruction of "when you clone use --recursive or do git submodule init to get the other repos into your CWD".
idunnoman1222 180 days ago [-]
Running Mac on linux isn’t even legal* so calm your how are real orgs meant to use this
IAmLiterallyAB 180 days ago [-]
As long as it's on Apple hardware it's fine right? Or is there something else
01HNNWZ0MV43FF 180 days ago [-]
Because if you had large binaries in your repo, it would grow quickly every time they changed, and GitHub would charge you lots of money, right?
nsonha 180 days ago [-]
if you are pulling from a registry then it's already built, so your ci should not fail on docker build dependencies. Or my understanding is wrong?
dboreham 180 days ago [-]
People love them some mystery meat.
replete 181 days ago [-]
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
jeroenhd 180 days ago [-]
In theory someone could write a display driver for libvirt/kvm/qemu 3D acceleration, like the ones that exist for Windows and Linux. With those (suboptimal) GPU performance would become available to just about any GPU.
AMD has its own VT-X alternative (AMD-V) that should work just fine. There are other challenges to getting macOS to boot on AMD CPUs, though, usually fixed by loading kexts and other trickery.
I don't really see the point of using Docker for running a full OS. Just distribute an OVA or whatever virtualisation format you prefer. Even a qcow2 with a bash script to start the VM would probably work.
bpye 180 days ago [-]
Virtualization.framework can also offer a paravirtual GPU [0] - it would definitely be interesting if someone reverse engineered that…
> Also Intel VT-x is missing on AMD, so virtualization is busted on AMD hosts
Wouldn’t that work with AMD-V?
replete 181 days ago [-]
Nope. There's only ever been Intel x86 apple computers so x86 mac software is Intel specific. Most things work fine on AMD, but some things don't work without hacks, such as digital audio workstations, some adobe applications etc. And you can't run hypervisors on an AMD hackintosh, the work around for docker is to install an old version of virtualbox and make it emulate instead.
steve1977 180 days ago [-]
> And you can't run hypervisors on an AMD hackintosh
But isn't the use case here running macOS in Docker on a AMD-based computer for example? So macOS would only see what QEMU presents it.
Or are you talking about virtualization within that container? Then I probably misunderstood.
replete 180 days ago [-]
I was referring to baremetal, but the same applies if virtualized on an AMD host
zamalek 181 days ago [-]
Yeah I would expect it too. As far as I know, AMD has had better luck with hackintoshes and VMacs.
replete 181 days ago [-]
AMD is far more complicated than Intel based machines in this regard. There's never been an apple computer with an AMD CPU...
shortformblog 180 days ago [-]
I encourage you to check out the OSX-PROXMOX project, which fully supports AMD and is designed to simplify these inside-a-VM setups (though not as much as a Docker setup). https://github.com/luchina-gabriel/OSX-PROXMOX
Also, there are a couple of kext projects that allow you to use AMD graphics, even iGPUs, on Hackintoshes. I have not tested this myself, but there are rumblings you may even be able to get this to work with a Steam Deck.
A lot has changed in the Hackintosh space around AMD of late. I don’t think the automatic pessimism is as warranted as it once was.
replete 180 days ago [-]
Proxmox uses QEMU and boots opencore, so its the same set of problems. It's great to see NootedRed progress but its currently limited to RDNA2 AFAIK and there are lots of weird graphical issues in some configurations. Intel is unquestionably a lot simpler.
sim7c00 180 days ago [-]
i think for the most part the cpus should be ok. they do have different feature sets but the isa is the same. the platform chipset is a different topic i guess. they dont need to share any logic or semantics between amd/intel as those are controlled by drivers rather than having to execute programmer's machine code directly.
not 100% on this, but x86_64 between amd and intel does share a lot of overlap right? if you dont go too far into extensions perhaps.
id guess vmxon and vmxoff and vmcs structures etc. will still be the same on both? a lot of security stuff etc. is totally different (amd psp vs intel ME etc.)
(still agree ofc, but just thinking about where these differences are located as the cpus can run very similar or the same code)
replete 180 days ago [-]
It mostly works, but virtualisation (even on baremetal) isn't possible at the moment, some applications need special patches, and weird issues here and there for some situations. AMD hacks are a hobby for a lot of people
sim7c00 172 days ago [-]
thats thata given me quite a new hole to fall into and discover :D
I set this up a few months ago as an experiment. Worked pretty well until I discovered that for iMessage to work, the application phones home to Apple using your hardware IDs, and this project uses fake values. At that point I started spiraling down the Great Waterslide of Nope, slowly discovering that the fake values are flagged by Apple and they will, as a consequence, flag your iCloud ID as a potential spammer, limiting your access from other devices. Your only option is to use a hardware ID generator script they vaguely link out to, and you can just keep trying values until you find one that "works", but there's not actually a good signal that you found one that works and isn't harming your iCloud reputation.
Worked really great otherwise, though. Very useful in a pinch.
judge2020 180 days ago [-]
The "keep cycling HWIDs until one works" thing was also common to get Hackintosh iMessage to work, you'd be able to check if it works by going to checkcoverage.apple.com. I quickly realized it's easier to copy the Serial from a old but real Mac.
But I think this tool is more useful for things like build scripts (that rely on proprietary macOS frameworks) more than it is for actually using it like a personal computer.
nixpulvis 180 days ago [-]
Pro tip: In general, don’t use your main iCloud account (or other accounts) for security research.
180 days ago [-]
xandrius 181 days ago [-]
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.
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 :)
arcanemachiner 181 days ago [-]
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 181 days ago [-]
What was the speed like?
arcanemachiner 181 days ago [-]
For a basic Flutter app: tolerable
ProfessorZoom 181 days ago [-]
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 181 days ago [-]
you can! you can also run it on a real iOS device using this tech. it's explicitly documented in the repo :)
I’ve personally been using the latter on my HP Z420 Xeon; it’s very stable, especially with GPU passthrough.
daft_pink 181 days ago [-]
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.
toomuchtodo 181 days ago [-]
This might assist you in syncing this data and then either storing locally or pushing elsewhere for backups:
I've been working on a solution here that uses OSX-Docker & OSXPhotos. It's getting there, but I wanted a way to back-up all the info in iCloud, but also include the metadata changes. Turns out that iCloud doesn't update the raw photos. Makes sense, but not helpful for those who do back-ups and expected those changes to be there.
bm3 181 days ago [-]
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?
daft_pink 178 days ago [-]
The problem is that I would have to purchase a dedicated desktop with enough storage to hold all my iCloud files and iCloud no longer syncs to external drives, so it’s cost prohibitive to purchase a desktop Mac expressly for that purpose.
paranoidrobot 181 days ago [-]
> that's different than just rsync'ing your iCloud folder from a connected Mac/PC
My guess: Being able to run it on a non-Mac/Windows machine.
watusername 181 days ago [-]
This is just running macOS in a VM. For much less fiddling and more stability, you can just run Windows in a VM instead for this use case.
prmoustache 181 days ago [-]
Is the redistribution of MacOS images allowed by the license or is this project distributing illegal copies in plain sight on docker hub?
yao420 181 days ago [-]
Idk but Correlium virtualizes iOS instances and was sued by Apple before settling the case.
judge2020 180 days ago [-]
Correlium was a big commercial player and made headlines. Anyone using this privately (and especially non-commercially) probably isn't at risk of action from Apple, although I wouldn't be surprised if Apple eventually tries to go after publicly hosted images.
181 days ago [-]
meatjuice 181 days ago [-]
This is clearly illegal
diggan 181 days ago [-]
"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.
jeroenhd 180 days ago [-]
Hosting copyrighted media without a distribution license is usually illegal. Very few countries allow you to just distribute proprietary disk images like this.
You can extract the images yourself from official install media (for instance, the installers you can create from within macOS) and use it for whatever personal project you want; you'd be breaking the EULA, but that doesn't mean much. You're not allowed to throw your copy on the internet, though.
Other projects I've seen download the installer images directly from Apple, something they could probably detect and block if they wanted to. That would probably be completely legal, as nobody is unlawfully distributing the files. This is different; the Docker images contain a copy of macOS.
Apple could probably take this project down any time they want to, but if they wanted to they probably would've already.
scintill76 181 days ago [-]
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.
hadlock 181 days ago [-]
You need to prove commercial intent to profit
If a choir teacher distributes the lyrics to a Britney Spears song to their students for practice, there is nothing illegal about this
If a choir teacher starts a website britneylyrics.com and puts ads on the website, that would qualify
The EULA might prohibit redistribution, but you don't need to accept an EULA to copy-paste files, as far as I know.
scintill76 181 days ago [-]
I think you’re right for the definition of criminal infringement. I still think this image is civilly liable for infringing Apple’s copyright (not a crime as I originally said.)
> The EULA might prohibit redistribution
I don’t think it matters. Copyright law automatically forbids copying. Well, assuming Apple complied with any requirements to have a valid copyright, which seems a safe bet.
caconym_ 181 days ago [-]
My understanding is that commercialization certainly weakens a fair use argument, but that its absence does not automatically make a reproduction and/or distribution fair use.
userbinator 181 days ago [-]
You don't need to accept an EULA to download the files from Apple either.
tombert 181 days ago [-]
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.
slivanes 181 days ago [-]
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 181 days ago [-]
Theoretically you can always run qemu in full emulation mode.
itsTyrion 181 days ago [-]
And practically even a minimal debian install takes minutes to boot to TTY with qemu-aarch64 on AMD64
ProfessorZoom 181 days ago [-]
we must go deeper
fragmede 181 days ago [-]
I mean you can just do that in any supported vm program.
Izmaki 181 days ago [-]
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 181 days ago [-]
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 181 days ago [-]
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 181 days ago [-]
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 181 days ago [-]
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 181 days ago [-]
"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 181 days ago [-]
On proxmox with a USB DAC/AMP it is impossible to get correct audio without pcie passthrough of the usb controller
m463 181 days ago [-]
I've run into this too. And I had to do a bunch of investigation into iommu groups to find a controller that wasn't shared.
Izmaki 181 days ago [-]
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...).
nine_k 181 days ago [-]
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.
(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
wildzzz 181 days ago [-]
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.
angulardragon03 181 days ago [-]
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.
pjmlp 181 days ago [-]
Via surprise audits from organisations like BSA, in collaboration with the police.
For organizations, sure, but has this ever been done to an individual?
pjmlp 181 days ago [-]
Individuals most likely not.
ForOldHack 181 days ago [-]
Apple branded machine. I got some of those nifty apple stickers to brand machines. MacBooks and Macpros as well as iMacs have serial numbers. They already have their whole arm ... I will just remind them again. Do not anger Linux wizards. They put Linux on an iPod.
obituary_latte 181 days ago [-]
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 181 days ago [-]
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).
ForOldHack 181 days ago [-]
Oh thank God! Now I have use for my macplus badge. Just cut and glue, and vola apple branded. It was running system 6, so Snow leopard. I did install QuickTime and it basically destroyed my windows, but it's a port of the MacOS. This elua has more holes in it than a windows 95 login screen. I am in control.
paulmd 180 days ago [-]
maybe apple, but intel would never fall for such a simplistic ploy. their lawyer are a million billion miles ahead of you, kiddo.
(too bad they didn't pay such close attention to the power profiles their partners were attaching the intel brand name to...)
jamesrr39 180 days ago [-]
> Intel reserves the right to ask you to stop using the logo [...]
Serious stuff!
nine_k 181 days ago [-]
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.
jkaplowitz 181 days ago [-]
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:
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 181 days ago [-]
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 181 days ago [-]
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.
rbut 181 days ago [-]
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 181 days ago [-]
This requires kvm exposed in the container. Does docker on mac support kvm?
nine_k 181 days ago [-]
AFAICT, with QEMU, access to KVM is only required if you care about performance %) Otherwise it can emulate everything for you.
monocasa 181 days ago [-]
This dockerfile explicitly enables kvm in a way that will cause qemu to fail if it's not present.
exe34 181 days ago [-]
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 181 days ago [-]
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.
rfoo 181 days ago [-]
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 181 days ago [-]
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.
exe34 181 days ago [-]
good thing I can't think of any reason to run macos.
ramses0 181 days ago [-]
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."
"""
Back in 'ye olden days, people used to print out programs... nay, they even used to _hand-write!_ programs before they began typing, because keyboard-time was valuable (nevermind compilation/computation/debugging time).
Serial ports were slow, grep wasn't really a thing, so having a printout (or "listing") of your program was a more efficient way (or only way!)to debug your program after the fact. https://www.youtube.com/watch?v=tJGrie7k97c
Back in the 90's, I had some programming classes in high school where there were 30 chairs, but 15 computers (around the edge)... bring your own 360kb floppy disk! So you had a real incentive (and a strict teacher) who insisted that you wrote out your program ahead of time, show it to her for a first-pass/feedback, and _then_ you'd get to go type it on the computer and see if it worked. Submissions were via printouts (of the program, aka "listing", along with the output) which she then took home and graded.
Stick tongue firmly in cheek, empty your cup, and enjoy the ride!
Edit: ...and the relationship to the cantankerous original comment who "couldn't figure why they'd want to run OSX?", this is the zen-koan sarcastic response of: "use it as a platform for development" (ie: stack your papers on top if it)
throwaway-blaze 181 days ago [-]
They're using it as a shelf.
exe34 181 days ago [-]
well put.
pzo 181 days ago [-]
Some unfortunately needs Xcode for building iOS or macOS apps locally even if you are coding in unity, flutter, react native, qt, unreal
181 days ago [-]
prmoustache 181 days ago [-]
> 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/
hundchenkatze 181 days ago [-]
> expect a C&D letter come any moment.
This repo is 4 years old... I don't think it's coming.
riiii 181 days ago [-]
I like the moaning sound the EULA makes when it gets violated.
znpy 181 days ago [-]
> 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 181 days ago [-]
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.
promiseofbeans 181 days ago [-]
Hey, not if you run it on a mac running Asahi
Kab1r 181 days ago [-]
If only it worked on ARM
m463 181 days ago [-]
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 181 days ago [-]
Ubuntu 24.04 is a disaster in my mid-2015 MBP. Ubuntu 22.04 is surprisingly good though.
resource_waste 181 days ago [-]
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 181 days ago [-]
How do you define "veteran"? I've been a Linux-only user for 10 years, and 9.5 of it is strictly with Kubuntu.
181 days ago [-]
resource_waste 181 days ago [-]
Feeling old when I say I'm at 18 years.
But I think its an experience thing rather than 'years' thing. If you only used Ubuntu for 10 years, you wont know what modern linux is like.
You sound like a Kubunutu expert, not a linux expert.
mynameisvlad 181 days ago [-]
"Sorry a decade of use is not enough to be considered an expert. Also your experience is useless because it's on a distro I don't like."
This is just pointless gatekeeping doubled down on at this point. People can be experts and use Kubuntu. People can be veterans and use Ubuntu. People can be absolute beginners and use Arch or OpenSUSE or literally any other distro. Use of distro is in no way shape or form indicative of experience other than that some are easier to get started with for absolute beginners than others. But that doesn't make them any less good.
It's a personal choice with each options having its own pros and cons. Not some indicator of experience or knowledge.
resource_waste 180 days ago [-]
Debian-family distros are literally outdated.
Its not even gatekeeping in 2024. Linux pros are avoiding debian-family.
Why would you use a buggy, slow, outdated distro when we have fast, modern, and fewer bugs?
This is an ignorance thing, much of the linux community repeats what they did in the past, afraid to change.
mynameisvlad 180 days ago [-]
> It’s not even gatekeeping in 2024. Linux pros are avoiding debian-family.
You’re not a “Linux pro” (not that that’s a thing in the first place ffs), so your opinion doesn’t matter, as much as you might think it does.
Glad to see pointless rabid fanaticism is still a thing in 2024, even in the Linux community.
Honestly, if you care this much about what distro someone uses, you need to get a life. This is by far the most pointless hill to die on.
skeledrew 181 days ago [-]
What is it that makes one a "Linux expert"? Knowing bash/awk well? Embracing the pain that some other distros are? Using Vim? If it's any of those then I'm definitely no expert, as I primarily use Python whenever bash starts to get even a bit complex, selected Kubuntu because I didn't have to deal with a bunch of source issues I had with Ubuntu (due to licensing; also avoided Arch as I heard it's a nightmare, but occasionally work on a CentOS box as part of my job), and do almost everything re text in Emacs.
dqh 181 days ago [-]
I’ve been continually using Linux for various purposes since the late 90s, and recently wrote a non-trivial kernel module for an embedded device. So I’m veteran-ish.
I tried Ubuntu on my MBP because I thought its popularity would mean the best chance of things working out of the box. I’m long past having time to spend on getting basic things working.
ctoth 181 days ago [-]
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 181 days ago [-]
i remember making this joke a decade ago on the tonymacx86 forums, lots of people did it for the lulz
userbinator 181 days ago [-]
Hackintosh has been around for almost 2 decades and AFAIK Apple hasn't threatened legal action on anyone except those trying to profit monetarily from it (the only one that comes to mind being Psystar).
Apple now even publicly distributes macOS from its site with no authentication required, something that certainly wasn't true in the early days of Hackintosh.
Given that some Hackintoshers may be doing it for the purposes of "security research" (bug bounty chasing), which indirectly benefits Apple, I don't think they will change the unsaid stance anytime soon.
On the other hand, its attempts at destroying right-to-repair and third-party OEM parts shows what it actually worries about.
sangnoir 181 days ago [-]
> because the point is to run it not on a Mac.
Says who? My Mac Mini runs Linux as the host OS, this project allows me to run MacOS as a guest OS on Apple hardware on demand.
user_7832 181 days ago [-]
> 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 181 days ago [-]
My guess is that macOS on Hyper-V is faster.
actionfromafar 181 days ago [-]
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.
7bit 181 days ago [-]
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.
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:
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 181 days ago [-]
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].
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.
manojlds 181 days ago [-]
Why are you talking as though this is a new project. It's been around for years
180 days ago [-]
elliotto 181 days ago [-]
Who cares lol
mosselman 181 days ago [-]
I don’t think Apple would feel very threatened by this indeed. I share the who cares lol
181 days ago [-]
croemer 181 days ago [-]
Note that this project currently provides only x86-64 Docker images, and not for aarch64.
replete 181 days ago [-]
No apple silicon emulators exist yet, and probably wont for years
Yes but the host he's using is Apple Silicon, I think what he's talking about is QEMU using Apple's Hypervisor Framework, which is what vmware Parallels, etc also use nowadays. Booting an apple silicon version of MacOS on non-Apple hardware probably isn't going to possible for a while as it would require emulation.
In 2021 Blackberry, surprisingly, wrote this article about getting emulating the XNU kernel and getting it running on non-apple hardware, but its just a terminal:
Someone would have to write something that can emulate/abstract the apple iGPU to get anywhere near a usable GUI - I'm no expert but I don't think this is going to happen anytime soon, so when Intel releases of MacOS stop happening apple hardware might be the only way to virtualize MacOS for a while
userbinator 181 days ago [-]
Someone would have to write something that can emulate/abstract the apple iGPU to get anywhere near a usable GUI
I'm not familiar with what Apple's GPU architecture on its ARM SoCs looks like, but wouldn't a framebuffer be sufficient? Or does ARM macOS have absolutely no software rendering fallback and relies on the GPU to handle all of it?
I know that regular amd64 macOS runs fine without GPU acceleration in a VM (like what is shown here), and arm64 Windows likewise with an emulated EFI framebuffer in QEMU on an amd64 host (it's bloody slow, being 100% emulated, but it works well enough to play around with.)
cheptsov 181 days ago [-]
I wonder if the project makes it possible to run macOS inside a container on a macOS host?
486sx33 181 days ago [-]
Parallels already does this…
JayDustheadz 181 days ago [-]
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 181 days ago [-]
Couldn’t you use UTM to run a macOS VM?
JayDustheadz 181 days ago [-]
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."
userbinator 181 days ago [-]
All the sibling comments appear to have missed your requirement of running Big Sur (macOS 11) --- everything based on Virtualization Framework is "paravirtualisation" and requires cooperation between the host and guest.
You could run the amd64 version of macOS 11 in QEMU on the M1, but that's ARM-to-x86 emulation, which will be slow, and I suppose isn't what you're looking for.
JayDustheadz 175 days ago [-]
It doesn't matter how sluggish this is - all I'm looking is to start Big Sur, open App Store and install one app ( Final Cut Pro ). In other words, looking for a way to download the older version of FCP.
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 181 days ago [-]
+1 for Tart (and seconded on avoiding virtiofs - which as a virtualization.framework problem, not and indictment on Tart's quality).
> 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.
This is SO useful for cross-compilation, and delivering macOS binaries!
bckr 181 days ago [-]
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 181 days ago [-]
Depends on whether you have plugins requiring GPU acceleration, as there is none
synchrone 181 days ago [-]
Any word if this would run the iOS simulator?
Edit: it actually does!
evanhughes 181 days ago [-]
For some reason I was convinced this wouldn't work, I was wrong. I guess docker can run any image so that makes sense.
cranberryturkey 181 days ago [-]
Does this work with kde/wayland?
rzzzt 181 days ago [-]
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 181 days ago [-]
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.
arusahni 181 days ago [-]
Looking forward to kicking the tires on this to validate functionality in Safari.
cheptsov 181 days ago [-]
If this receives support for an Apple GPU, it will be incredibly significant!
l8rlump 180 days ago [-]
New to containers. How easy would it be to run only the OSX Reminders and Calendar apps, or as stripped-down as possible a system to get these running without the overhead of the OS? The webapp versions of these are crippled compared to the OSX/iOS apps.
dariosalvi78 181 days ago [-]
Can this run xcode?
XiS 181 days ago [-]
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 181 days ago [-]
I run full apple hardware and < 2 years old and the damn thing is still pretty slow.
KronisLV 181 days ago [-]
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.
evnix 181 days ago [-]
Next time, just get a mac mini and plug in an external ssd
prmoustache 181 days ago [-]
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.
pzo 181 days ago [-]
Honestly development in xcode is poor even on apple hardware.
slivanes 181 days ago [-]
According to the readme on github, yes, although it takes about an extra 30GB of drive space.
jayd16 181 days ago [-]
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?
adamgordonbell 181 days ago [-]
Not to be confused with native Mac OS "containers":
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.
181 days ago [-]
181 days ago [-]
mysore 181 days ago [-]
[flagged]
nottorp 181 days ago [-]
> 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 181 days ago [-]
Discussions are open on their repo...
lyu07282 180 days ago [-]
Discord has built-in forums with search. Tell me you've never used discord without telling me you've never used discord.
sebstefan 180 days ago [-]
Built-in un-googleable forums with a gate in front that nobody even uses except the Rustlang discord
nottorp 180 days ago [-]
I keep it open 24/7. Where are those forums? Have you ever seen how a forum is organized? Do you think all text based chat windows are forums?
Hint: reddit is sort of a collection of forums. Discord, whatsapp group chats, Slack and other similar things are not, they're just a discardable text chat.
Tell me you don't know what a forum is without telling me you don't know what a forum is :)
Rendered at 13:12:34 GMT+0000 (Coordinated Universal Time) with Vercel.
Besides the obvious build failures on heavily sandboxed build servers with no access to the internet, this forces anyone with even a little concern for security to do a full audit of any build recipes before using them, as merely studying and making available the dependencies listed in READMEs and build manifests like requirements.txt, package.json etc., is no longer enough.
I find this a very worrying development, especially given the rise in critical computer infrastructure failures and supply chain attacks we've seen lately.
Self-contained distribution should be the norm.
There's so much churn in devops space that nobody has time to figure out "the correct way" anymore.
The right to repair and the right to rampage?
Typically, Fedora and openSUSE have a policy that distributed packages (which includes container images) have to build with only packages from the repository, or explicitly added binaries during the build. So once you can `dnf/zypper install` something (or pull it from the vendor's container registry), you know the artifacts are trusted.
If you need to be on a bleeding edge, you deal with random internet crap shrug.
Of course a random OSS developer won't create offline-ready, trusted build artifacts. They don't have the infrastructure for it. And this is why companies like Red Hat or SUSE exist - a multi-billion dollar corporation is happy to pay for someone to do the plumbing and make a random artifact from the internet a trusted, reproducible, signed artifact, which tracks CVEs and updates regularly.
In the 80s we envisioned modular, reusable software components you drop in like Lego bricks (we called it CASE then), and here we have it, success! Spoiler, it comes with tradeoffs...
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
AMD has its own VT-X alternative (AMD-V) that should work just fine. There are other challenges to getting macOS to boot on AMD CPUs, though, usually fixed by loading kexts and other trickery.
I don't really see the point of using Docker for running a full OS. Just distribute an OVA or whatever virtualisation format you prefer. Even a qcow2 with a bash script to start the VM would probably work.
[0] - https://developer.apple.com/documentation/paravirtualizedgra...
Wouldn’t that work with AMD-V?
But isn't the use case here running macOS in Docker on a AMD-based computer for example? So macOS would only see what QEMU presents it.
Or are you talking about virtualization within that container? Then I probably misunderstood.
Also, there are a couple of kext projects that allow you to use AMD graphics, even iGPUs, on Hackintoshes. I have not tested this myself, but there are rumblings you may even be able to get this to work with a Steam Deck.
https://github.com/ChefKissInc/NootedRed
https://github.com/ChefKissInc/NootRX
A lot has changed in the Hackintosh space around AMD of late. I don’t think the automatic pessimism is as warranted as it once was.
id guess vmxon and vmxoff and vmcs structures etc. will still be the same on both? a lot of security stuff etc. is totally different (amd psp vs intel ME etc.)
(still agree ofc, but just thinking about where these differences are located as the cpus can run very similar or the same code)
Docker-OSX: Run macOS VM in a Docker - https://news.ycombinator.com/item?id=34374710 - Jan 2023 (110 comments)
macOS in QEMU in Docker - https://news.ycombinator.com/item?id=23419101 - June 2020 (186 comments)
Worked really great otherwise, though. Very useful in a pinch.
But I think this tool is more useful for things like build scripts (that rely on proprietary macOS frameworks) more than it is for actually using it like a personal computer.
This could be pretty awesome in terms of freedom, even if the build takes 5x more.
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 :)
Also wanna point out the existence of OSX-PROXMOX, which does something similar for Proxmox home servers: https://github.com/luchina-gabriel/OSX-PROXMOX
I’ve personally been using the latter on my HP Z420 Xeon; it’s very stable, especially with GPU passthrough.
https://github.com/steilerDev/icloud-photos-sync
https://github.com/icloud-photos-downloader/icloud_photos_do...
My guess: Being able to run it on a non-Mac/Windows machine.
You can extract the images yourself from official install media (for instance, the installers you can create from within macOS) and use it for whatever personal project you want; you'd be breaking the EULA, but that doesn't mean much. You're not allowed to throw your copy on the internet, though.
Other projects I've seen download the installer images directly from Apple, something they could probably detect and block if they wanted to. That would probably be completely legal, as nobody is unlawfully distributing the files. This is different; the Docker images contain a copy of macOS.
Apple could probably take this project down any time they want to, but if they wanted to they probably would've already.
If a choir teacher distributes the lyrics to a Britney Spears song to their students for practice, there is nothing illegal about this
If a choir teacher starts a website britneylyrics.com and puts ads on the website, that would qualify
The EULA might prohibit redistribution, but you don't need to accept an EULA to copy-paste files, as far as I know.
> The EULA might prohibit redistribution
I don’t think it matters. Copyright law automatically forbids copying. Well, assuming Apple complied with any requirements to have a valid copyright, which seems a safe bet.
Can I run docker inside this container to get MacOS to run inside MacOS? ;)
(However, "USB over ethernet proxy" is also a true passthrough, just one with higher latency than VirtIO.)
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.
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.
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.
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.
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.)
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.
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.
https://www.bsa.org/
I’m omitting a few details for brevity (MS licensing is nuts when you get into the weeds).
https://i.imgur.com/fop769Z.jpeg
(too bad they didn't pay such close attention to the power profiles their partners were attaching the intel brand name to...)
Serious stuff!
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.
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.)
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.
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.
> that is already running the Apple Software
Running Linux on Apple hardware would not follow that part of the EULA.
It could be in a VM.
""" "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
Serial ports were slow, grep wasn't really a thing, so having a printout (or "listing") of your program was a more efficient way (or only way!)to debug your program after the fact. https://www.youtube.com/watch?v=tJGrie7k97c
Back in the 90's, I had some programming classes in high school where there were 30 chairs, but 15 computers (around the edge)... bring your own 360kb floppy disk! So you had a real incentive (and a strict teacher) who insisted that you wrote out your program ahead of time, show it to her for a first-pass/feedback, and _then_ you'd get to go type it on the computer and see if it worked. Submissions were via printouts (of the program, aka "listing", along with the output) which she then took home and graded.
The whole document IMHO is worth a read, but is definitely a product of it's time (70's/80's/90's). https://en.wikipedia.org/wiki/The_Tao_of_Programming
Stick tongue firmly in cheek, empty your cup, and enjoy the ride!
Edit: ...and the relationship to the cantankerous original comment who "couldn't figure why they'd want to run OSX?", this is the zen-koan sarcastic response of: "use it as a platform for development" (ie: stack your papers on top if it)
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/
This repo is 4 years old... I don't think it's coming.
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.
ubuntu installs and runs easily. Other versions of linux - it depends.
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.
But I think its an experience thing rather than 'years' thing. If you only used Ubuntu for 10 years, you wont know what modern linux is like.
You sound like a Kubunutu expert, not a linux expert.
This is just pointless gatekeeping doubled down on at this point. People can be experts and use Kubuntu. People can be veterans and use Ubuntu. People can be absolute beginners and use Arch or OpenSUSE or literally any other distro. Use of distro is in no way shape or form indicative of experience other than that some are easier to get started with for absolute beginners than others. But that doesn't make them any less good.
It's a personal choice with each options having its own pros and cons. Not some indicator of experience or knowledge.
Its not even gatekeeping in 2024. Linux pros are avoiding debian-family.
Why would you use a buggy, slow, outdated distro when we have fast, modern, and fewer bugs?
This is an ignorance thing, much of the linux community repeats what they did in the past, afraid to change.
You’re not a “Linux pro” (not that that’s a thing in the first place ffs), so your opinion doesn’t matter, as much as you might think it does.
Glad to see pointless rabid fanaticism is still a thing in 2024, even in the Linux community.
Honestly, if you care this much about what distro someone uses, you need to get a life. This is by far the most pointless hill to die on.
I tried Ubuntu on my MBP because I thought its popularity would mean the best chance of things working out of the box. I’m long past having time to spend on getting basic things working.
Apple now even publicly distributes macOS from its site with no authentication required, something that certainly wasn't true in the early days of Hackintosh.
Given that some Hackintoshers may be doing it for the purposes of "security research" (bug bounty chasing), which indirectly benefits Apple, I don't think they will change the unsaid stance anytime soon.
On the other hand, its attempts at destroying right-to-repair and third-party OEM parts shows what it actually worries about.
Says who? My Mac Mini runs Linux as the host OS, this project allows me to run MacOS as a guest OS on Apple hardware on demand.
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.
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.
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...
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
In 2021 Blackberry, surprisingly, wrote this article about getting emulating the XNU kernel and getting it running on non-apple hardware, but its just a terminal:
https://blogs.blackberry.com/en/2021/05/strong-arming-with-m...
Someone would have to write something that can emulate/abstract the apple iGPU to get anywhere near a usable GUI - I'm no expert but I don't think this is going to happen anytime soon, so when Intel releases of MacOS stop happening apple hardware might be the only way to virtualize MacOS for a while
I'm not familiar with what Apple's GPU architecture on its ARM SoCs looks like, but wouldn't a framebuffer be sufficient? Or does ARM macOS have absolutely no software rendering fallback and relies on the GPU to handle all of it?
I know that regular amd64 macOS runs fine without GPU acceleration in a VM (like what is shown here), and arm64 Windows likewise with an emulated EFI framebuffer in QEMU on an amd64 host (it's bloody slow, being 100% emulated, but it works well enough to play around with.)
You could run the amd64 version of macOS 11 in QEMU on the M1, but that's ARM-to-x86 emulation, which will be slow, and I suppose isn't what you're looking for.
It uses Apples Virtualization framework and works well, besides issues with virtiofs. But those can be worked around with virtual block devices aka images.
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
Edit: it actually does!
QEMU also has its own built-in remote access capabilities (SPICE and VNC-based) but the former needs guest support.
I really hate having to also support the Apple ecosystem. Development, CI/CD integration is really poor without having to buy the hardware.
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.
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.
No forum eh? Everyone should come to the live channels and ask the same questions again :)
Hint: reddit is sort of a collection of forums. Discord, whatsapp group chats, Slack and other similar things are not, they're just a discardable text chat.
Tell me you don't know what a forum is without telling me you don't know what a forum is :)