Docker-OSX: Run macOS VM in a Docker
github.com
github.com
https://www.vice.com/en/article/akdmb8/open-source-app-lets-...
Apple allows you to run a maximum of 2 virtual machines on Apple hardware.
Someone is going to get sued by Apple for going against this part of the license agreement and I must say I really like that thought because the result of that trial will give clarity to the rest of us.
We had to deal with a gray area in our project as well. DeepL does not allow use of their translator in critical infrastructure. Our client is in the transportation business and has been using DeepL for years to translate emails. They wanted to integrate DeepL into a customer portal that we develop for them. When we told them that we will not be complicit in breaking DeepL’s license agreement, they weren’t too happy.
Shortly after the M1 released, this happened: https://news.ycombinator.com/item?id=25064593
For me, back in the day, it was about power: I wanted a Trash Can Pro for development (I had a fully-specced retina MacBook Pro) but I didn’t want to pay Apple tax; I already had a gaming rig. So I dual booted.
For myself, I needed a lot of parallel processing, and Mac Pro back then just got you so far.
For friends, it was because I’m a Mac shill. This was my way of getting them to buy a Mac when the future of the platform was still a little uncertain.
I still have a “MacBook Nano” which was an ASUS netbook that dual booted
... And hacking entire operating systems under virtual machines is just fun :).
This is the myth that just won't die even though every fair comparison of Mac hardware to available PC hardware, carefully matching feature for feature, reveals prices within $100 of each other. What you don't want to pay for is the features that you're not interested in, such as perhaps Thunderbolt ports.
Apple still makes a 40-50% margin on every iPhone sold. The iPhone could be the cheapest smartphone around, and it would still be generally agreeable that Apple has enormous profit margins.
Show me this put together beige box, and I will show you a machine with missing features found in the Mac Pro. Then you will say, "I didn't want that stuff, I would never use it," but when added in, the prices will be within a close margin.
I do see your point, but even if that's so, the problem of Apple hardware inaccessibility to an average computer hardware buyer cannot be considered as "resolved" or "unavoidable", but only pivots from the circumstance of "Apple forcing high profit margins on hardware buyers" to "Apple forcing a set of (unwanted, yet costly) hardware features on hardware buyers" (through the lack of appropriately varied hardware models and hardware configuration options).
Which is too bad, because if Apple hardware was appropriately inexpensive while delivering the features that I do care about, I would probably consider switching to their hardware and macOS as my primary O/S. (... But then again, maybe not - I really like the latest Linux KDE/Plasma.)
https://www.researchgate.net/publication/233647272_The_Cult_...
If you had told me thirty years ago that one day I’d be developing on a Mac I would have laughed, but once I had one I realized developing under Windows was a pain - everything is unnecessarily difficult because Microsoft wants you to develop FOR windows and they want you giving money to all their partners who forever have their hands out, and they make everything else hard.
It’s like a pain that never goes away - you can learn to ignore it but at some level it’s always there.
While _this_ usecase obviously isn't officially supported, it does seem like they support VMs in some capacity officially.
"Do you have a Facebook? Or an insta?"
No one cares about correctness at all, anymore.
P.S. For bonus points, ask me how I pronounce INXS :-D
However, it's no less serious than the GGP's arms in the air upsettedness about calling the 'gram insta. oops, see, i called it two different shortened names back-to-back. uh-oh, somebody's going to be upset!! ;-)
If you don't pronounce INXS as INXS, you're doing it wrong.
Edit: the name I just gave up trying to understand is Musk's kid's name. talking about a name that a kid will grow up to resent their parents about.
These abbreviations are location/culture dependent. For example, here when you say "I'll app you", it means sending a message on whatsapp.
If that’s possible then it’s huge.
Edit: Best way to know is to just do it. I’ll try this and report back.
Great they have that now!
I’ve considered using this for running simulators but I always get asked about how legal this is.
So if it's on an Apple device (even one not running MacOS as the host) it's fine, otherwise it's a violation of the EULA, and something a business probably doesn't want to get tangled in.
I personally wouldn't have any scruples using this for testing/building OSS, but I would also think twice about using it at my job.
I set up OSX-KVM (https://github.com/kholia/OSX-KVM) and it worked really well. Having archlinux is a huge plus for this (it's why the docker image uses it), as qemu is super simple to setup and get running. Was surprised how easy it was, but given how much effort the bootloaders have had over the recent years for Hackintosh, qemu users can just yoink that bootloader and use it.
Seems like this solution would make it much simpler, as we used Docker for everything else.
I've set up some tests that require OS X and usually set up remote VMs for that. This could be a nice alternative to run those using regular (and cheaper) linux instances.
I know you can do the same with KVM but nothing beats a one liner command.
> docker: Error response from daemon: error gathering device information while adding custom device "/dev/kvm": no such file or directory.
On Linux, this project doesn't require nested virtualization. On any other operating system, it does. In that way, the host OS ends up mattering.
Docker Desktop makes me wanna scream.
Might even be able to modify `gon` to use that instead of Apple's `codesign` and then you'll have notarization too: https://github.com/mitchellh/gon
I'm not submitting to the app store though.
GPU passthrough from a Linux host to a Mac VM is already possible. Even with Docker in the sandwich. Then it’s a question of Docker-OSX being furnished for it.
I believe the GPU passthrough foundation is already there:
PR #132: https://github.com/sickcodes/Docker-OSX/pull/132
”[…] this PR introduces GPU passthrough support. This requires extensive configuration on the host”
—
Then there’s “paravirtualized” graphics. I don’t get the name; as far as I know, this is when the guest OS has a virtual graphics device and a driver for it – with acceleration — and the virtual graphics device is actually served and accelerated like any other graphics-accelerated software by a GPU on the host.
As mentioned elsewhere, paravirtualized graphics are available on mac-host-to-mac-guest, and to my knowledge only mac-inside-mac.
(But the “outside” mac can probably be a virtual machine as long as it has a GPU. Even if it’s a passthrough device. Should be technically possible at least and I would guess that it just works.)
Finally, un-accelerated graphics in a macOS VM are surprisingly fast these days. At least on my Linux machine in qemu-kvm, recent versions of kernel / qemu etc. It’s noticeably slower than having properly accelerated graphics but muuuuch faster than I was expecting from macOS VMs I’ve used before.
Finally, headless access to virtualized macOS goes really fast. Working on a mac VM through mosh-shell is excellent.
In the README there's a blurb with:
> Run Mac OS X in Docker with near-native performance! X11 Forwarding! iMessage security research! iPhone USB working! macOS in a Docker container!
> Conduct Security Research on macOS using both Linux & Windows!
*they = Apple
If I had to venture a guess as to why macOS doesn't support its own containers in any way, though, I'd say:
The core use case for containers is deploying apps to servers, and macOS isn't really used on the server. Apple themselves abandoned supporting macOS as a server operating system many years ago.
Which includes servers that build applications with Xcode.
This isn't new, and Apple has rolled with it; they gave up making server hardware more than 10 years ago. They finally completely EOL'd the software package they called 'macOS server' like a year or two ago.
Compare all the macOS changes from a 2 year period to the equivalent changelogs to the Linux kernel. It's very clear that macOS is neither widely used as a server operating system nor developed as one.
If macOS were widely deployed as a general-purpose server operating system, Apple would have implemented some kind of container support years ago.
This isn't the only server-centric area in which macOS lags compared to other operating systems. APFS' featureset is anemic for such a recent filesystem with a copy-on-write design.
The core use case of containers is central neither to existing macOS usage nor to Apple's vision for macOS. If there's a question here, it has to be why that is so, not the fact that it is.