macOS in QEMU in Docker(github.com) |
macOS in QEMU in Docker(github.com) |
It also uses hardware assisted virtualization (KVM) which is not going to be available most of the time Docker is.
You can think of the Docker platform itself as subset of the Linux platform. With many common features removed by default... SYS_PTRACE, cgroups come to mind as not allowed within the container. (This "Docker as a subset of Linux" is also what you end up getting from most "Docker as a service" platforms offered by clouds, including kubernetes. I'm referring to AWS Fargate, Google Cloud Run, GKE, AKS, here.)
So don't think of this as macOS in docker wherever docker runs.
What would be a lot more analogous to macOS in docker would be running Darling in docker: https://www.darlinghq.org/ ... if that could be made to work for the entire system (highly unlikely)
Darling is more like Wine in that it runs native executables for one platform as native processes on another platform using a compatibility layer. Wine, by the way, definitely works quite well inside Docker.
Also, one final thought. I wonder if you could get macOS to boot in QEMU without hardware assisted virtualization. Then you could probably run this in a fully isolated container again. The performance would likely be abysmal though!
The last time I set this up, a manager decided he wanted a laptop like the rest of us instead of the iMac he got. He asked semi-jokingly if someone wanted the machine for anything and I said "Yes, I do" before he even got the sentence out.
There was just enough memory on the machine for me to set up a few Jenkins agents on it, one for Safari, the rest using the Selenium-maintained docker images.
This project relies on OSX-KVM, which is a thing that already exists. The dockerization of that project (what this post is about) is a gimmick as described by GP.
you still legally need to run it on an actual Mac due to Apple's terms of service though... so is there really a lot gained ?
I too would like to hear if anyone has been able to pull this off.
EDIT: And what about licensing?
Still, very interesting idea!
I an not saying it’s right or wrong. I think it’s the most practical and thus most pervasive use of docker.
The company and the project provided a great service by creating lot of shipping/container related metaphors though. That’s very much invaluable in my book. Providing thousands of developers means to talk about objects that are static and dynamic from an architectural perspective.
Depending on your point of view, it could denote a container, or source control, or a sort of makefile.
To me it is a reproducible recipe in 43 lines of Dockerfile text.
It also depends on host kernel features such as KVM settings and hardware such as CPU (good luck on AMD) much more than whatever is packaged on the container.
This is about as "reproducible" as replaying my .bash_history on a different machine. I would bet that before the end of this year this script no longer works.
Why do we do this to ourselves? Words have meaning. This should go doubly so for engineers. Our language should be as precise as possible when describing systems.
https://www.reddit.com/r/jailbreak/comments/gwg3e4/free_rele...
The developer mentions[0] that, like macOS-Simple-KVM[1], this leverages kholia's OSX-KVM[2].
[0] https://www.reddit.com/r/jailbreak/comments/gwg3e4/free_rele...
It's been a long time since I played with macos vfio passthru stuff but maybe that's a way around it nowadays. There's a little /r/vfio community that tries to tackle it pretty frequently.
Hopefully someone else has more recent details than me, I'm back to using osx hardware now that the 16" mbp lets me have 32gb.
If I remember correctly you can only run macOS on their hardware.
allowed "to install, use and run up to two (2) additional copies or instances of the Apple Software within virtual operating system environments on each Mac Computer you own or control that is already running the Apple Software"
Here is another solution posted 12 days ago that works on macOS: https://news.ycombinator.com/item?id=23284987
I didn't try it yet but I plan to use it to test Ansible playbooks targeting macOS.
With this, you can do pretty everything
Doesn't docker run a container in a single thread? So this would be running the entire MacOS in a single thread? Is there a way to tell Docker to execute this in multiple threads?
Looking at the Dockerfile in the OP, you can see it's using https://github.com/kholia/OSX-KVM/blob/master/OpenCore-Boot.... as the script to start the VM, and you can see the -smp 4,cores=2 in the qemu arguments which configures how many threads/cores/sockets to assign to the guest. Though I'm not entirely familiar with the syntax so I'm not sure what the "4" is for, but I'd guess threads.
It only works on Macs, it needs the toolchain and ROM I guess? Docker is just one step closer to porting it on the Windows and Linux platforms.
Personally, if I wanted to run MacOSX that badly, I'd buy a Mac Mini or the lowest-priced Mac they have. Much easier and worth it for the AppleCare and Warranty.
Edit: grammar and spelling.
No, it doesn't.
But don't be sad, their new Mac Pro is fantastic.
Not exactly ideal for hobbyists.
Unlike Microsoft, Apple has no motives to send the BSA after anyone. Pretty sure they've only used them for egregious copyright violations like the commercial Hackintoshes.
Pretty sure these terms are not enforceable in Europe so safe to ignore.
Of course the problem are the SDK that you need to use to build most software, they are obviously proprietary, but does its license say that they can only be used to compile software on a real Mac?
And yes, too much to ask. Apple's principal revenue source is selling hardware. They don't care if developing for their platform is not cheap; they explicitly target the premium segment, and are never uncomfortable with their well-known large margins.
The existence of companies like MacStadium filling rooms with Macs just to bend over backwards for inane license terms proves the paid demand is there. Apple could offer to license their OS for use not on Apple hardware — for a fee. They don't. The objection isn't to the price; the objection is that needing to manage physical hardware (as opposed to spinning up VMs like in the article) is a PITA to manage, comparatively. Companies would — and do — pay to not need to deal with that pain, but it would be a lot less painful to not need to get a third party involved / to be able to make use of the infra I have without having to stuff some Macs into a closet and wonder how I'm going to make that redundant.
The pipeline docs are somewhat lacking though IMHO but once you get them working, they work great.
End goal was building iOS apps w/o any mac hardware. Using some open source patches to clang, libimobiledevice, and a whole bunch of other tools, I was able to write an iOS app in "good ole C in emacs" on my linux laptop, cross compile it for the iPhone, and even code sign, upload and run it on the phone.
This was several years ago. If offered as a hosted service, do you really think anyone would pay for it enough to make it worth my while to code up and polish?
EDIT: HAH! I forgot I said all this the last time this topic came up 2 years ago: https://news.ycombinator.com/item?id=17763855
As such, it's not unusual for the OS X tests to be farther down the list and not to trigger at all if earlier stages failed. It's easier to scale up multiple subprojects if you run the first couple phases on commodity hardware and then ramp up to the more peculiar stuff only if everything else already looks good. That way, your broken build can't slow down my green build very much.
It's not so much that I like doing this, as that it prevents a number of things I most definitely do not like at all.
I've used Azure DevOps on several projects, and it's CI/CD capabilities really are fantastic.
I've also used AppCenter (and the previous incarnation, HockeyApp), and it makes for a great app distribution experience. It also has an integration with InTune, which is very useful in the enterprise, although we did find configurating it to be a total PITA and it required a domain admin to set it up.
Why not use Travis CI by adding `.travis.yml` into your GitHub repo?
You even have to install more packages in the host than in the container.
You could even just run the original script the Dockerfile is wrapping directly which will even autoinstall the packages for you.
Spooling up a docker image is low friction at a lot of places. Doing anything else can take an act of Congress.
It often seems like someone wants to use a specific hammer and tries to tailor/turn/reshape problems into nails. Some of it may be resume driven development, perhaps choosing comfortable technologies, etc. Perhaps hammers are the only tools they're familiar with and risk aversion in business leads us to only use our hammers.
Something is amiss because I keep seeing hammer problems and it never seems to stop.
Least worst is obviously subjective but for me it includes running a bunch of random stuff in roughly the same way across Linux, OSX and Windows. The launch and manage UX is significantly better than vms also (not intrinsically, for any good reason, but in practice).
I get that this container is not actually portable tho.
Looks like work in progress:
$ git clone https://aur.archlinux.org/yay.git
$ cd yay
$ makepkg -si
Makes sense as a wrapper for PKBUILD
pkgname=qemu-osx
pkgver=10.14.6
depends=(qemu libvirt dnsmasq virt-manager bridge-utils flex bison ebtables
netctl libvirt-dbus libguestfs)
...
It's really making me sad to browse HN sometimes.
Qemu-kvm however is insanely fast as it offloads most of the actual virtualization to KVM and to the native virtualization instruction set .
No! Major cloud providers use it to provide VMs with basically zero overhead.
I've no affiliation with them, but can recommend them. Never had any technical issues, and the one billing issue we had was sorted out quickly by their support people.
However, if you buy a Mac, install Linux and use it to run the pipelines, that'd be strictly legal I believe.
I'm in this boat, so there's a market for it.
> This Dockerfile automates the installation of OSX-KVM inside a docker container.
Except it automates the fetching of the macOS installation media and launching qemu, which is exactly what OSX-KVM already does. [1] This project does nothing additional to automate the actual installation of macOS inside the VM.
I wish Apple supported installation automation like Microsoft does with sysprep (or Linux with kickstart/preseed). The best I've found is Arduino USB devices that pretend to be a keyboard and mouse to manually advance the installer, which is super lame "automation"
[1] https://github.com/kholia/OSX-KVM/blob/master/OpenCore-Boot....
This one does https://github.com/myspaghetti/macos-virtualbox
Not fully, not perfectly, but does. It periodically asks you to press enter and wait.
Definitely not great as an actual process, but this sounds like a super cool project!
And you have tools like Jamf for any enterprise fleet management needs
Hypervisor.framework is an API to execute hypervised code, to build virtualisation engines that can run unprivileged; you still have to write an actual virtual machine.
My (linux) desktop has a macOS icon on it. I click on it. That starts a QEMU/KVM process which runs macOS. When I quit out of that, it is gone. When I click on it again, it runs again.
I suppose there are a few files floating around that persist between runs, and are not utterly trivial to manage. Just ... trivial to manage.
Does fiddling with BIOS parameters and installing kernel modules fall into "anything else"? Because this project doesn't work until you've done that on your docker host.
maybe "docker history" ~ "git log"?? tags=branches?
Docker isn't one thing, so it's ALL grey. It's not really make. It's not really a vm. It's not really even reproducible.
One thing is for certain - it's hard to describe docker to new folks so they get it. "it's sort of like netflix, for cows, but in space..."
If a subset such as "Boot ROM code" on the VM host was sufficient to allow for using "Apple software" beyond said subset in VM guests, then any other subset (such as "fonts") would also have to be sufficient, and no reasonable person would agree with such a thing. Therefore, it follows that the _entirety_ of "Apple software" must be "already running" on that "Mac Computer" before booting any VM guests that use "Apple software." This interpretation is supported by the use of the word "and."
But actually, even more strongly in favour of interpreting that they don't specifically license macOS for use on a Linux host via their agreement, is the syntax of 2.B.iii itself (italicisation for emphasis):
> [you are granted a license] to install, use and run up to two (2) additional copies or instances of the Apple Software within virtual operating system environments on each Mac Computer you own or control that is already running the Apple Software"
Their clear syntax of repeating "the Apple Software" in the context of both guest and host environment indicates that what is used virtually must also be used on the host.
Additionally, you probably couldn't get out of it by dual booting with Linux and saying that 'aha, see, I have mac running on the host machine I'm fine', the grammar of the words "that is already running" indicates that macOS must be running while using macOS as a guest, under their license.
I can't imagine any serious legal implications that really matter apart from to major corporation making major money off virtualising macOS somehow. To anyone else or any other angle relating to it, I don't think there's any worry whatsoever. It appears the Hackintosh community hasn't been sued into oblivion...
... until your virtualization layer starts having a material impact on their precious hardware sales.
You cannot build business-critical systems on contractual clauses being "unofficially unenforced".
Maybe I'm too old to get the appeal of "a fleet of containers" in place of a single (and potentially throw-away) VM image along with maybe even a vagrant-script to make it easily reproducible... ¯\_(ツ)_/¯
Back on topic though: it's too bad Apple doesn't allow licenses for running things headlessly like this.
You over-philosophized to the point of bringing their kitschy koan off-topic.
How I interpreted the use of the koan : Apple has no history of legally chasing those who virtualize their operating system; as this is a non-topic thusfar -- who cares?
The hammer may fall one day, but so far 'why are we worried about a legal response that doesn't seem to exist?'.
The answer, of course, is that anyone who builds product based on a legally grey area is at risk when that area begins to crumble.
>it's too bad Apple doesn't allow licenses for running things headlessly like this.
agreed, but I think Apple wants to drive everyone to a hardware solution.
At one point 'enterprise-ish' hardware was offered, but now it seems that it'd be in their interest to offer virtualization licenses while trying to smooth out whatever troubles exist between their software and the major VM hyper-visor offers out there -- mostly since there are huges holes in their hardware offerings for those seeking to do 'enterprise-ish' things en masse.
Say I have a personal project with a few dozen users. Somebody reports a bug on osx -- I don't do windows, I don't do macs, so I'd need to rely on my small community to fix it. With a pirate copy, I'd be able to do the fix -- and none would be the wiser.
Scale that up to a company, put it up on a public repo's CI, and that's when people might hear the tree fall.
When they were on rough times, everyone understood about needing to break compatibility with old hardware (that nobody really cared about anyway because, despite it's horrendous price, was super obsolete due to the rate of Moore's law back then). But nowadays, Apple is invalidating old hardware platforms for superfluous reasons, like abandoning 32-bit apps, enforcing their OEM cryptographic authority (with T2 chip) and getting into it with nVidia (granted nVidia screwed up big time with those GPU chips that blow) or more recently, getting into it with Intel (which has caused agonizing supply-chain issues for Apple). They are no longer that good about helping people support Linux either --you would think that when they deprecate a machine, they would at least have the decency to open source all of its drivers...(and have pre-negotiated the legal rights to do so).
As much as I like Github for OSS projects, I really love Azure DevOps for everything else. The CI/CD capabilities are amazing, and I haven't had any real issues with lack of documentation (a few small things here and there for sure though).
Long may it live, I hope!
Not to jackknife the thread, but most developers were born in the 90s and do not remember this Microsoft.
The engineering and dev managers DO remember this Microsoft. So while I agree somewhat they are trying to repair their image, with the younger crowd they only know MS as Minecraft, VS Code, Azure, Github. More people probably got exposure to Linux via WSL than all of the previous installs combined.
90s me would have thought hell would have frozen over, and now me knows it has.
most apple enthusiasts think that the price is spot on and in no way overblown. (i do not have an opinion on the matter as i neither own nor use apple devices)
i dont think you can convey any point about apple in a sarcastic manner while omitting a /s tag. there are always people honestly believing the point you're stating sarcastically.
this applies to both negative and positive statements
Tone of voice (and tone of face) are both essential to convey sarcasm over rich channels, and both are lost over text.
Now add Poe's Law.
In short: Welcome to the wonderful world of autism! /s
I've never spent more than £600 on a computer and never felt like I need to spend 10x that for any of my software development
Maybe not macOS yet. But the definitely chased people who virtualized iOS:
https://www.macrumors.com/2019/08/15/apple-corellium-copyrig...
We do CI for our VM images in our kubernetes clusters. The build system already was in kubernetes, so putting the OS image testing in there was a big win.
The benefit of doing this is also that on a personal machine you can start playing with an OSX vm with a single docker run command with no other dependencies and many people already have docker setup, whereas standardized qemu/virtualization tooling is now much less common on developer machines
You have to fiddle with BIOS and kernel module parameters, install packages, configure KVM, etc on your docker host for this to work. It's not something that you can just throw into kubernetes, especially if you don't manage the kubernetes deployment yourself.
> The benefit of doing this is also that on a personal machine you can start playing with an OSX vm with a single docker run command with no other dependencies
There _are_ external dependencies that you have to set up manually. It's the same amount of work to set up on docker or to use a real VM, so I can't imagine why you would prefer this method.
1. Enable hardware virtualization 2. modprobe kvm 3. docker build 4. docker run
and you have an OSX VM.
> It's not something that you can just throw into kubernetes, especially if you don't manage the kubernetes deployment yourself.
GCP and Azure support nested virtualization, so you actually could do this in a managed kubernetes cluster. It's plenty common to use privileged DaemonSets in kubernetes to load kernel modules for filesystems, storage, or iptables rules. If you're allowed to run privileged containers, it's trivial to run VMs like this in kubernetes.
How would you feel about an app like GitLab, for example, shipping a docker container that required privileges for this, I wonder?
However, if it was a product that required virtualization and that was recognized as a requirement, then also distributing a docker image that could do it would probably be useful for people in the "and if you don't have virtualization infrastructure, but have container orchestration and nodes that support virtualization, our service will also work in a privileged container" camp
For the curious - what are they?
I Need to buy a new MacBookPro and even though I can reclaim the VAT (sales tax) and it'll come out of corporate accounts the price makes me wince
Oh and I'd like one without a touch bar but screwed on that front unless I go high end MacBook Air
iPhone SE at £400 is pretty reasonably priced though and will be my next phone
Chromium is competing with Samsung internet and others on Android, because several companies sell Android. So it's not fine for Google to force the choice.
Apple is not competing with anyone else on iOS, you don't have a choice. As long as iOS does not have a monopoly in smartphones, they're in the clear.
I'm certainly no friend of Google and I'm not losing sleep over them getting fined. But it seems that Apple is just as much if not more anti competitive and anti consumer, but they get a pass because of what feels like a loophole.
I take it you'd have no objection to Google forking the Linux kernel for Android and refusing all requests for the source code.
At the same time, it makes kinda sense. No company with a product has to allow competition in. GM doesn't have to allow BMW motors in their cars.
When you join a market with a product, like Apple, then you don't have to allow competition in your product. When you create a market like Google did Android, then you to allow competition in that market.
I think that's the key difference, product vs market.
They're still playing dirty tricks on open source. They're just not stupid enough to use the ones that would do more harm than good.
When people say that "MS gets open source now", what it really means is the MS gets how OS can be used to further its goals. Not that they have fundamentally changed.
MS will have graduated to the next level of maturity when it open sources something that is strategic to the ecosystem and the ecosystem as a whole benefits (Windows NT 4?) or something that is obviously making them money.
Dotnet Core is cross-platform and fits that bill.
It introduced a huge segment of Windows-only devs to Linux.
Yes, that furthers Microsoft's goals too, as Linux is very important in the cloud, and therefore Azure. But regardless, the move has also benefited many, many developers, and the Linux ecosystem.