Live data from Hacker News

macOS in QEMU in Docker

github.com

181–190 of 190 posts

Re: macOS in QEMU in Docker

#181

So this is pretty misleading. It's really a full system emulator (qemu) running inside Docker, using root privileges on the container that make the isolation very weak (--privileged). 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…

its using docker as an artifact delivery mechanism, not as an isolationism mechanism.

I would say docker is primarily used as an artifact delivery mechanism where artifact presupposes inclusion of required runtime.

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.

Re: macOS in QEMU in Docker

#182
post #77

Earlier quoted context omitted.

I don't care though. What I care about is that it's a pain in the butt to do CI/CD pipelines for an application with iOS/OSX support. So if someone has a headless OS X contraption on offer, I want to hear some more about it. 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…

If we put aside the licensing issues, isn't QEMU notoriously slow? Building iOS apps seems pretty slow even on a high-end MBP, so I'd be curious how long it took under QEMU. Still, very interesting idea!

> isn't QEMU notoriously slow

No! Major cloud providers use it to provide VMs with basically zero overhead.

Re: macOS in QEMU in Docker

#183
I have always wondering how Azure, BrowserStack and such support Safari or macOS. Do they have custom licensing with Apple to allow to run it virtualised or are they actually running it on Macs?

If I remember correctly you can only run macOS on their hardware.

Re: macOS in QEMU in Docker

#184

Earlier quoted context omitted.

The EULA says you can't run Mac OS on non Apple hardware? Pretty sure these terms are not enforceable in Europe so safe to ignore.

If you don't respect Apple's software license terms, you have no moral authority to insist anyone respects the GPL's license terms. I take it you'd have no objection to Google forking the Linux kernel for Android and refusing all requests for the source code.

Apple's software license terms are monopolistic and actively harm the industry, unlike GPL.

Re: macOS in QEMU in Docker

#185
This was done by SpaceInvader for the UnRAID docker community months ago. As stated, it is just streamlining a process that has been available with KVM-OSX with various bash scripts for months or years before that.

Re: macOS in QEMU in Docker

#186
post #77

Earlier quoted context omitted.

I don't care though. What I care about is that it's a pain in the butt to do CI/CD pipelines for an application with iOS/OSX support. So if someone has a headless OS X contraption on offer, I want to hear some more about it. 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…

If we put aside the licensing issues, isn't QEMU notoriously slow? Building iOS apps seems pretty slow even on a high-end MBP, so I'd be curious how long it took under QEMU. Still, very interesting idea!

Qemu Is a bit slow when doing full system virtualization.

Qemu-kvm however is insanely fast as it offloads most of the actual virtualization to KVM and to the native virtualization instruction set .

Re: macOS in QEMU in Docker

#188

Earlier quoted context omitted.

If you don't respect Apple's software license terms, you have no moral authority to insist anyone respects the GPL's license terms. I take it you'd have no objection to Google forking the Linux kernel for Android and refusing all requests for the source code.

Apple's software license terms are monopolistic and actively harm the industry, unlike GPL.

Irrelevant. Both licenses rely on exactly the same laws, morality and principles. Either you think intellectual property can be owned and licensed, or you think it should not be.

Re: macOS in QEMU in Docker

#189

Earlier quoted context omitted.

As far as I know, it's because they do not have partners. 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.

Doesn't that seem a bit backwards? Google faces anticompetitive scrutiny because they created an open(ish) platform that others can compete on. But Apple goes all in on a walled garden where nobody even has the opportunity to compete with them. Doesn't that feel anticompetitive? 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…

Yeah, I don't really know, I'm not a lawyer.

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.

Re: macOS in QEMU in Docker

#190
post #47

Earlier quoted context omitted.

I think "docker" is an ambiguous term nowadays. 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.

> I think "docker" is an ambiguous term nowadays. 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.

English vocabulary rules - vocabulary is built of axiom schemata - are insanely complex, and still we have to rely heavily on disambiguation by context. It is the nature of NL semantics. I'm not arguing against more precise terms of art, just saying that expanding an insanely huge and complex vocabulary isn't a great way to accomplish that. Establish your context, then use your symbols in that context; thus are all utterances disambiguated.
Post reply on HN