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.
> 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....
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?
However, if you buy a Mac, install Linux and use it to run the pipelines, that'd be strictly legal I believe.
Still, very interesting idea!
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.
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
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.
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..."
But don't be sad, their new Mac Pro is fantastic.
Not exactly ideal for hobbyists.
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
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.
... 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".
Pretty sure these terms are not enforceable in Europe so safe to ignore.
I take it you'd have no objection to Google forking the Linux kernel for Android and refusing all requests for the source code.
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?
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.
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.
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!
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?
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...
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.
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.
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.
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... ¯\_(ツ)_/¯
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.
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.