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.
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?
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.
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.
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.