Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

macOS in QEMU in Docker

github.com

Post reply on HN
Print view View original

161–170 of 199 posts

Re: macOS in QEMU in Docker

#161

Post by sim7c00 »

replete wrote: post #133
zamalek wrote: post #129

Earlier quoted context omitted.

Yeah I would expect it too. As far as I know, AMD has had better luck with hackintoshes and VMacs.

AMD is far more complicated than Intel based machines in this regard. There's never been an apple computer with an AMD CPU...

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)

Re: macOS in QEMU in Docker

#162

Post by steve1977 »

replete wrote: post #131
steve1977 wrote: post #124

Earlier quoted context omitted.

> Also Intel VT-x is missing on AMD, so virtualization is busted on AMD hosts Wouldn’t that work with AMD-V?

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.

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

Re: macOS in QEMU in Docker

#163

Post by nottorp »

lyu07282 wrote: post #159
nottorp wrote: post #48

> 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 :)

Discord has built-in forums with search. Tell me you've never used discord without telling me you've never used discord.

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 :)

Re: macOS in QEMU in Docker

#164

Post by BossingAround »

acka wrote: post #157

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 acces…

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.

Re: macOS in QEMU in Docker

#165

Post by nsonha »

acka wrote: post #157

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 acces…

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?

Re: macOS in QEMU in Docker

#166

Post by jeroenhd »

replete wrote: post #54

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…

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.

Re: macOS in QEMU in Docker

#167

Post by jeroenhd »

diggan wrote: post #89
meatjuice wrote: post #53

Earlier quoted context omitted.

This is clearly illegal

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

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.

Re: macOS in QEMU in Docker

#168

Post by nstart »

dbtablesorrows wrote: post #158
acka wrote: post #157

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 acces…

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.

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 .

Re: macOS in QEMU in Docker

#169

Post by replete »

shortformblog wrote: post #156
replete wrote: post #133

Earlier quoted context omitted.

AMD is far more complicated than Intel based machines in this regard. There's never been an apple computer with an AMD CPU...

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 wor…

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.

Re: macOS in QEMU in Docker

#170

Post by replete »

sim7c00 wrote: post #161
replete wrote: post #133

Earlier quoted context omitted.

AMD is far more complicated than Intel based machines in this regard. There's never been an apple computer with an AMD CPU...

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…

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
Post reply on HN