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

Quickemu: Quickly create and run optimised Win-10,11/macOS/Linux on Linux

github.com

Post reply on HN
Print view View original

61–70 of 123 posts

Re: Quickemu: Quickly create and run optimised Win-10,11/macOS/Linux on Linux

#61

Post by acatton »

geniium wrote: post #57
acatton wrote: post #34

While I appreciate the effort, and the code is very readable. I just want to give a friendly warning that these shell scripts just download random stuff from the internet and run this random stuff without checking any integrity/signature. Apart from that, I will definitely use that project as a documentation for "how to run MacOS/Windows in KVM". Cool project :) .

It’s a good feedback, while not open an issue to give feedback on GitHub or better, create a PR?

Somebody else already opened an issue https://github.com/wimpysworld/quickemu/issues/70

Re: Quickemu: Quickly create and run optimised Win-10,11/macOS/Linux on Linux

#62

Post by yjftsjthsd-h »

skissane wrote: post #53
TimTheTinker wrote: post #45

Earlier quoted context omitted.

I don't see why someone would opt for option 2 when virtualizing macOS on an Apple machine.

So my understanding – if you run VirtualBox on macOS, and you choose macOS as Guest OS type when creating your VM, it automatically turns GetKeyFromRealSMC on. That means you are using option (2) by default. You can always switch to option (1) instead if you want to, but if you are virtualising macOS-on-macOS, there is little reason to. From reading the VirtualBox source code [0] – it also automatically enables GetKe…

> but if you are virtualising macOS-on-macOS, there is little reason to.

Not needing to run a kext just to retrieve a known hardcoded string seems like a very good reason.

Re: Quickemu: Quickly create and run optimised Win-10,11/macOS/Linux on Linux

#63

Post by rcarmo »

maccolgan wrote: post #46
rcarmo wrote: post #14

This is pretty handy. I set up a KVM guest the other day and it was a very straightforward affair, but I can see how this can streamline testing. I do wonder if it can use KVM directly instead of QEMU (I can always move the .qcow after, just curious as to how it would work with virsh)

What do you mean by using KVM directly? Using the KVM module directly, without an userspace component?

Using virsh and virt-manager instead of qemu.

Re: Quickemu: Quickly create and run optimised Win-10,11/macOS/Linux on Linux

#64

Post by q3k »

londons_explore wrote: post #47
maccolgan wrote: post #44

Earlier quoted context omitted.

You are not really supposed to run QEMU directly if you are looking for that kind of experience, that's why libvirt exists. Other than that, QEMU should really be a generic emulator rather than being infested with platform-specific stuff, everything else should be independently maintained and pluggable. (Autodetection is also extremely fragile, and takes away from keeping a VM a VM)

But it would be easy to design qemu to have 1000+ config options which are on/off/auto settings, and the 'auto' mode is autodetected based on which OS is probably running. Nothing stops someone overriding some or all of those flags to whatever values they like. It's still a power user tool, just one that also 'just works' for common usecases of people who don't want to manually set the IRQ number for the DMA controll…

> But it would be easy to design qemu to have 1000+ config options which are on/off/auto settings, and the 'auto' mode is autodetected based on which OS is probably running.

That would add a ton of new responsibility to a codebase that so far has been doing none of this. It would have to be aware of different operating systems, operating system image formats for autodetection, OS releases and their corresponding quirks, ... And some way to test this, and test this automatically, so that this stuff doesn't immediately rot away. People would begin to depend on this, and any change in this behaviour would be a breaking bug, and would introduce implicit stability contracts for complex scenarios.

Let qemu be low-level emulator and make zero assumptions about how it's being used - that makes life so much easier for those of us who integrate it into non-standard scenarios. Libvirt gives you everything needed for typical 'I wanna run a commercial OS in a VM on my desktop/server', and can afford to make assumptions about its usage scenario.

Re: Quickemu: Quickly create and run optimised Win-10,11/macOS/Linux on Linux

#65

Post by hunter2_ »

alfiedotwtf wrote: post #49
lelanthran wrote: post #10

Earlier quoted context omitted.

ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc

Bonus points if you also know these ones (without searching for them): K4HVD... 09 F9 11 02 9D...

The first looks like a Windows VLK (maybe XP?)

Re: Quickemu: Quickly create and run optimised Win-10,11/macOS/Linux on Linux

#66

Post by ben_w »

CTDOCodebases wrote: post #43
JasonFruit wrote: post #37

Earlier quoted context omitted.

Control is a part of ownership. If you don't control how something is used and by whom, you don't really own it. So either using it in unauthorized ways is in a manner theft, or Apple's "ownership" is not real ownership. I'm not sure what the solution is, but IP is a tricky concept no matter your position.

It sounds like Apple don’t even own it then if they can’t prevent people from pirating it.

I can’t prevent someone from robbing me, just make it harder for them to do so and have legal recourse if they do it anyway.

This still counts as “having control”.

Re: Quickemu: Quickly create and run optimised Win-10,11/macOS/Linux on Linux

#67

Post by yjftsjthsd-h »

rcarmo wrote: post #63
maccolgan wrote: post #46

Earlier quoted context omitted.

What do you mean by using KVM directly? Using the KVM module directly, without an userspace component?

Using virsh and virt-manager instead of qemu.

I'm pretty sure that's less direct; libvirt wraps qemu

Re: Quickemu: Quickly create and run optimised Win-10,11/macOS/Linux on Linux

#68

Post by mc32 »

alfiedotwtf wrote: post #49
lelanthran wrote: post #10

Earlier quoted context omitted.

ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc

Bonus points if you also know these ones (without searching for them): K4HVD... 09 F9 11 02 9D...

I guess you're just missing the Adobe CS Keys that didn't need the license server after they shut them down.

Re: Quickemu: Quickly create and run optimised Win-10,11/macOS/Linux on Linux

#69

Post by skissane »

yjftsjthsd-h wrote: post #62
skissane wrote: post #53

Earlier quoted context omitted.

So my understanding – if you run VirtualBox on macOS, and you choose macOS as Guest OS type when creating your VM, it automatically turns GetKeyFromRealSMC on. That means you are using option (2) by default. You can always switch to option (1) instead if you want to, but if you are virtualising macOS-on-macOS, there is little reason to. From reading the VirtualBox source code [0] – it also automatically enables GetKe…

> but if you are virtualising macOS-on-macOS, there is little reason to. Not needing to run a kext just to retrieve a known hardcoded string seems like a very good reason.

You don't need to use a kext. You can instead use IOKit to talk to the AppleSMC driver over a Mach port. Works even without root: https://gist.github.com/vagelim/dd5be2802ecb097b81cf07711f6a...

VirtualBox has code to do the above. But it also has code in one of its kexts to do it by talking directly to the hardware, in case (for whatever reason) this API doesn't work; it tries IOKit first and then calls the kext as a fallback. And, the kext doesn't solely exist to talk to the SMC, it does a bunch of other things too. I'm not sure whether VirtualBox works without its kexts, but if it doesn't, it isn't because of this reason.

(When I wrote my original comment above, I didn't know you could do this through the IOKit API, although I've since edited that comment to mention it.)

Post reply on HN