Hackintosh-KVM Guide: High Sierra+ Using QEMU's I440fx Chipset | Hacker News Reader

Hackintosh-KVM Guide: High Sierra+ Using QEMU's I440fx Chipset

passthroughpo.st

248 pointswalterbell95 comments

I'm not quite sure why they say q35 chipset has bugs, I'm currently running Mojave without bugs on a q35 configuration. Also, they're making questionable choices regarding keyboard and mouse configuration. What you should really be doing is passing through a complete USB3 controller (either from the Chipset or from an external USB3 pcie card), with a mouse and keyboard attached to it. Finally, I would recommend using an AMD RX500 series card, which has native support in macOS, and absolutely no extra Clover flags required (10.13.6 and up).

Also, the guide assumes a lot from the reader (someone who already knows how to do PCIe passthrough in qemu).

I wrote a guide here that explains everything I wrote above, and actually starts from the basics:

https://github.com/yoonsikp/macos-kvm-pci-passthrough

This is something I've considered for some time now. I have a beefy skylake Xeon with plenty of ECC-ram and VT-d, I'm considering letting it replace my Mac Pro at home using a VT-d passthrough for GPU. Basically I prefer macOS as my desktop OS but running KVM in the bottom or similar hypervisor would be so neat (I'd prefer illumos but that feels like a nogo for these usecases).

Do you know how a GTX780 would behave in macOS with VT-d, one was gifted to me from a friend and colleuge and if it's usable for this I'd like to use it (I have no real need for a beefy GPU as long as I can run a couple of high resolution monitors). If not which is the cheapest (and least powerconsuming) GPU you'd recommend?

Haven't been in the Hackintosh scene for a good 8 years so things seems to have changed quite a bit since then.

I know my 750ti worked without needing drivers in macOS, but I think it needed some fiddling with clover. 780 might not work out of box, but I think it will work the web nvidia drivers.

Oh I see. Would you recommend against using a KVM+VT-d macOS install as primary desktop/workstation?

I'd probably put passthrough on USB and use a USB-dac for audio and add some decent bluetooth hardware for handoff, keyboard, mouse/touchpad, etc. I'd really like to have zvols underneat passed to the macOS-machine, I suppose I would have to use a HFS-sparseimage or similar for primary OS disk, but it would be nice to mount the zvols directly via OpenZFS for additional partitions. I would love to leverage LZ4 for document storage etc.

I can confirm that the GTX780 works. You will need to install the nvidia web drivers after macOS installation. Tried even using it with tensorflow.

Regarding your first question: I have tried virtualized and bare metal macOS (hackintosh) and I would recommend not virtualizing it if it's gonna be your primary workstation. Currently my main workstation is a hackintosh after trying first using it in a VM.

Virtualizing works, but under a VM there are several minor annoyances here and there that might drive you crazy (most of them are UI related, some app crashes, etc.). It would be perfect for example for a xcode build server. thought. YMMV!

You could virtualize it and use it as your main. I have not noticed any issues compared to a bare metal install, at least on High Sierra.

With GPU pass through, pretty much performs the same too... I've maybe seen a 5% performance hit at most after running some benchmarks. I also passed through an NVMe drive directly to the VM which avoids having to use an emulated storage controller.

I were considering that as well but it would be very nice to run the entire system from a ZVOL for snapshots, LZ4, dataintegrity, etc. Considering maybe using a passthrough block-device only for os and use attached ZVOLs for userdata. Would be cool to be able to z-send user data to a remote backup as well.

Passing a full controller isn't always an option, some controllers don't like being passed and/or suffer from reset bugs and not all machines even have enough controllers. And of course, if you pass a full controller, you can't use your keyboard/mouse on the host until you shut down the VM.

I’ve tried two different platforms, and the integrated USB controllers worked even after multiple reattachments. But you’re right, you lose the ability to shut down the host, unless you unplug the keyboard and plug it into a USB port that hasn’t been passed to the VM. Still, this wasn’t a problem for me since I wrote a script that would ssh into the host from the VM and start the shutdown sequence.

Or you just configure your power button to shut down the computer.

The main userbase of https://passthroughpo.st are Linux users first, thus need access to the host as well. While passing a full controller would indeed be the most reliable way (if your controller doesn't have reset bugs and if you have enough controllers available), it isn't always the most practical way.

Are there a list of supported AMD cards somewhere?

Check the section "Supported eGPU configurations" on this page: https://support.apple.com/en-us/HT208544

This should also apply to internal GPUs.

Here are some other links for people who are interested in trying to run hackintoshes:

- https://github.com/geerlingguy/macos-virtualbox-vm

- https://github.com/kholia/OSX-KVM

Personally I ended up just buying a Mac Mini and upgrading it's RAM. It's unfortunate, but I was under a deadline and didn't want to risk having a technically-illegal version of MacOS prevent me from building/publishing client apps suddenly.

In the future, I'm going to just take writing iOS apps off the list of services I offer.

I've also decided to give up developing my applications for Mac and will only support Linux and Windows in the future. That's kind of ironic since I started as a Mac shareware and freeware developer.

For a more or less hobby developer like me, the running costs of developing for Mac are too high if you take into account that you have to purchase new hardware every 3 to 5 years. I've tried the Hackintosh approach, but it was overall too unstable and you never know whether some user might not send a bug report for the pre-release of some future OS version. My main program was broken and I had to fix it several times during the past two decades, every time because of changes by Apple and not a single time because of a programming bug.

Apple has a strong tendency of breaking their own APIs. That in combination with obvious attempts to lure them into their developer infrastructure and a strong deprecation of non-standard tool chains and languages (use XCode or die, get a developer account or forget it) makes developing for Macs a major pain in the ass.

No more iOS or macOS applications from me in the future. I might offer web apps for iPhone users, though.

What about using react apps? I'm not experienced in react by any means, but it seems like it would help in your situation.

React Native, Nativescript, and more recently Flutter are great for app development, but when it comes to deployment/testing, you really do have to get it on an actual device eventually.

In the end, you have to have something running OSX -- despite the fact that fact that frameworks like Flutter draw every pixel on the screen, you still usually need to (well should) test it on a real device.

Yeah I think this might be the way to go in the future -- do the web app manifest thing to make it load like a native app.

Given what you went through I'm glad I didn't try the hackintosh approach. I suspect that >90% of the people who even try the Hackintosh approach are developers who don't want to buy another computer just to target one platform.

Personally I think eventually it will be possible to develop iOS apps from non iOS computers, but maybe not anytime soon. Once Apple thinks the moat is degraded enough, I guess.

I currently use cctools (https://github.com/tpoechtrager/cctools-port.git) to cross compile iOS apps from my 32-bit Linux computer. Then I load onto my phone using Cydia Impactor.

It's much more flexible to do it this way than using the latest version of Xcode. I can compile a 32-bit app that runs on iOS 6, or I can compile a 64-bit app using the iOS 7 sdk.

I also prefer compiling OS X apps on my Linux box, because I can use whichever version of clang I want, but compile it so that it will run on Snow Leopard. The dev environment for Snow Leopard is missing a lot of the newer features of Objective-C, so I find it easier to do this, than to use the latest version of macOS and Xcode.

I only use Objective-C, I haven't tried cross compiling Swift, simply because I do not like the language.

Thanks for the pointer and explanation of how you work -- I have a ton of questions about this:

- 32bit linux, still? Is there any reason you haven't gone 64, or have you just been on some rock solid distro that never felt like it needed the upgrade?

- Cydia Impactor[0] requires a jailbroken iPhone, does it not? What version of iOS are you running on the actual device? I understand that you're compiling with iOS6/7 SDKs but I wonder how long they'll be supported, and how fluently they work on iOS12 for example.

- Are there any limitations on versions for the Cocoa SDK that you use for building OSX apps? Do you worry at all about EoLing of support or anything like that?

> I only use Objective-C, I haven't tried cross compiling Swift, simply because I do not like the language.

Could you explain this and why? While I'm not necessarily a Swift fan because I don't think it does particularly well in comparison with some of the recent languages that I really enjoy using, I found Objective-C to be pretty jarring. Clearly you know a thing or two about the toolchain and Objective C, I'd love to know why you prefer it to Swift or why you think Swift is not worth switching over to just yet (if at all).

This is kind of random but maybe the thought will be interesting -- I've often wondered why it's not possible to actually just build and run XCode (or at least the lower level toolchain) on an apple device like a phone. Has anyone heard of anything in this area?

[0]: http://www.cydiaimpactor.com/

I'm still using 32bit linux because I'm on Slackware and the multilib situation is too annoying for me to deal with. I tried to upgrade to 64bit Slackware but I need Wine, and it's much easier to set up on a 32bit machine. I don't want to switch to another distro because most of them use systemd, and I use my own custom window manager.

Cydia Impactor does not require a jailbroken iPhone, it is generally used to initiate the process of jailbreaking, by sideloading an app onto the device.

I have an SE running iOS 12, an iPad Mini running iOS 10, and a 4S running iOS 6. iOS 10 is the last version to support 32bit apps. If I compile with the iOS 7 SDK, the app will still run with later versions of iOS, it's only if you need the header files for some of the API's that are only in the later versions of iOS that you should use a more recent SDK to make your life easier, but you can still send the messages via Objective-C without the actual header files (because of introspection the API is available at runtime).

I'm not sure what you mean by limitations for the Cocoa SDK and OSX apps. I do this for my own personal code, it's not something I distribute so I don't worry about End of Life

It's just that I started with C and Objective-C, and it's a lot of work to bridge between Swift and C, so I'd rather stick to Objective-C. Also there is no 32bit Swift runtime (that I am aware of). I just like being able to run my code on older 32bit processors. Objective-C is just so dynamic and the fact that it's just a thin layer on C is very appealing to me. I'm more fond of the Objective-C runtime itself than I am of Foundation.

I have a jailbroken 4S with iOS 6, and you can install clang and all the tools you need to compile an app on the device itself. No need for Xcode at all unless you need storyboard or to submit an app to the App Store. Most of the toolchain can be downloaded from Cydia, and you can read the instruction for Theos to get an idea of how it works, but you don't need to use Theos, you can compile it with clang yourself (on the device).

As a macOS/iOS developer who more or less does things the “by the book” Apple way, using Apple HW, Xcode, etc. I don’t know whether to give you a high-5 or shake my head! It’s fascinating to know there are developers like you out there, doin’ it the hard way just to target “legacy” hardware. Very interesting setup.

I prefer if you shake your head :)

But believe it or not, I think it's easier to do it manually than to use Xcode because it gives you more flexibility. When things are hidden from you, it makes things seem more complicated than they actually are. Most of the functionality is built into clang.

> I'm still using 32bit linux because I'm on Slackware and the multilib situation is too annoying for me to deal with. I tried to upgrade to 64bit Slackware but I need Wine, and it's much easier to set up on a 32bit machine. I don't want to switch to another distro because most of them use systemd, and I use my own custom window manager.

Believe it or not, I was 100% going to guess that you were running Slackware.

> Cydia Impactor does not require a jailbroken iPhone, it is generally used to initiate the process of jailbreaking, by sideloading an app onto the device.

Thanks for clearing that up. So as long as I can find a way to build the IPA you're good to go.

> I have an SE running iOS 12, an iPad Mini running iOS 10, and a 4S running iOS 6. iOS 10 is the last version to support 32bit apps. If I compile with the iOS 7 SDK, the app will still run with later versions of iOS, it's only if you need the header files for some of the API's that are only in the later versions of iOS that you should use a more recent SDK to make your life easier, but you can still send the messages via Objective-C without the actual header files (because of introspection the API is available at runtime).

Thanks for the detailed information, it's great to see that the setup is working with such recent OS versions and on top of it all Objective C has afforded you a little bit of leeway with the magic of message passing.

> I'm not sure what you mean by limitations for the Cocoa SDK and OSX apps. I do this for my own personal code, it's not something I distribute so I don't worry about End of Life

Got it -- sorry I was assuming that it was something you distributed -- given the fact that you were running a non-mac system.

> It's just that I started with C and Objective-C, and it's a lot of work to bridge between Swift and C, so I'd rather stick to Objective-C. Also there is no 32bit Swift runtime (that I am aware of). I just like being able to run my code on older 32bit processors. Objective-C is just so dynamic and the fact that it's just a thin layer on C is very appealing to me. I'm more fond of the Objective-C runtime itself than I am of Foundation.

> I have a jailbroken 4S with iOS 6, and you can install clang and all the tools you need to compile an app on the device itself. No need for Xcode at all unless you need storyboard or to submit an app to the App Store. Most of the toolchain can be downloaded from Cydia, and you can read the instruction for Theos to get an idea of how it works, but you don't need to use Theos, you can compile it with clang yourself (on the device).

Thanks so much for sharing -- this is something I would love to look into some day. Jailbreaks have mostly kept up and since iPhones often have best-in-class hardware it seemed like a natural choice

On the multilib note: I've found that slackpkg+ makes things a lot easier nowadays, since it'll automatically prioritize multilib/compat32 packages (instead of having to use separate tools to manage those). SlackBuilds are still a pain, though (sbopkg doesn't have the tools to automatically create compat32 packages, so you'll usually have to manually build it with ARCH set, then run compat32convert or whatever it's called before installing; not terribly hard, but still annoying).

Also, 64-bit Wine is a thing now. I think the version on SlackBuilds.org is still 32-bit only, but I don't recall any issues when I downloaded and compiled/installed the upstream version myself.

> you have to purchase new hardware every 3 to 5 years

You really don’t. Generally macOS tends to extend software support (i.e. the latest release) to computers that are around 6-7 years old.

> My main program was broken and I had to fix it several times during the past two decades, every time because of changes by Apple and not a single time because of a programming bug.

Just curious: what were the problems you faced?

> use XCode or die, get a developer account or forget it

You can write Mac apps without either of these. Without Xcode the job is hard but not impossible, and you can distribute unsigned binaries and they will run on macOS.

>> you have to purchase new hardware every 3 to 5 years

> You really don’t.

That's not my experience, it depends on how lucky you get. I still have a Core Duo iMac and that one didn't last longer than 5 years.

Anyway, it would be easier for me if Apple made compelling hardware, but none of the current offers appeal to me in any way. They don't even sell iMacs with mate screens, and let's not speak about the keyboards or lack of extensibility.

I purchased an Amd 1800X machine with 32GB RAM and Geoforce 1080 together with a 42 inch monitor for peanuts. Why would I spend the same amount of money on an iMac with 8GB RAM, slower processor, and smaller, but very glary display?

Surely Apple has their customer base and appealing products for many people. I'm just not one of them any longer. (I used to have an Aluminum Powerbook Pro G4 - that was some quality. But now? They even come with power cables that are too short!)

>Just curious: what were the problems you faced?

Deprecated Carbon dependencies, deprecated GUI calls in Cocoa, problems with high DPI displays, problems with Gatekeeper and signing, problems with 32bit->64bit transition. Basically, whenever a new MacOS version came out, I wasn't sure whether my app would continue running. Sometimes it did, sometimes it didn't, sometimes the GUI was messed up.

To be fair, the real problem was more on the Hackintosh side: Every problem could eventually be fixed with a simple recompile. Unfortunately, every time I had to set up a new virtual machine with the new OS, make a new Hackintosh installation and try to get a new OS image, and as you might imagine these come with different hacks and different obscure instructions every time, especially when you run them in virtual machines.

>you can distribute unsigned binaries

That's what I do right now, but users will pester you with bug reports and you have to explain to them every time again how to manually open the application and allow Gatekeeper to run it. That's especially annoying if you believe, like I do, that Gatekeeper is fairly insecure and can be broken or circumvented by any skilled hacker anyway (as past bug reports have illustrated).

There's a Mac hardware event in 11 days that might tell us about the modular Mac Pro launching in 2019, and will likely also have a "pro-focused" Mac Mini refresh. One of those machines might be perfect for you. If not, used Mac Pro 5,1s are available for peanuts and you can throw a ton of screaming fast aftermarket hardware in them.

As contrarian anecdata, a non-trivial app (with 3-d graphics) we developed for iOS 2 still runs fine on iOS 12. (Long retired from the app store, but my retained binary still runs.)

Wouldn’t an iOS 2 app be 32-bit, which was deprecated with iOS 11?

32 bit apps were deprecated in iOS 10 and support was completely removed in 11.

Perhaps the old binary still runs on an equally outdated deployment of iOS. I remember resisting the 6 to 7 upgrade for as long as I could, but an unexpected iPhone replacement under AppleCare has foiled my plans to remain on my favorite version of the OS.

It strikes me as odd in this day and age that Apple don't just officially support macOS on non-Apple hardware. If they're concerned about instability due to poor quality drivers and its impact on users' perception just offer an "approved supplier" program where hardware manufacturers can have their drivers verified and signed, as Microsoft have done in the past.

I know it's not the same as being truly open but at least it offers more options and they could charge a fee to claw back the lost hardware revenue. Manufacturers would be falling over themselves to get on the list for a little shiny Apple sticker on their boxes.

We're talking about the biggest tech company in the world here, surely they have the resources to make it possible?

Failing all that, what about an "Open" community supported macOS like Fedora is to RHEL? (Isn't this pretty much what the Darwin project used to be about?)

Apple already tried that from 1995 - 1997. It completely cannibalized sales of their own hardware, which is where they were making their profit. Steve Jobs cancelled the licensed clone program in 1997 & Apple acquired the largest selling clone manufacturer Power Computing:

https://en.wikipedia.org/wiki/Macintosh_clone#Licensed_Macin...

I agree that it does not make sense for them. But in 1995-1997 Macs were still largely their core business. Now Mac is just a small portion of their revenue.

I’d agree that their revenue streams are more diversified now. Hopefully in the future their increased services revenue and decreased hardware sales vs r&d expenses make that appealing for them

But, I think it’s unlikely given how much they’re still investing in their hardware line.

Albeit, the hardware is not going in a direction that many longtime pro users appreciate, and they keep coming out with nightmare “improvements” like their painful butterfly keyboards and touchbar . With my issues in my hands, those things are literally causing me physical harm. :(

I highly encourage you to try going to a rock climbing gym (or outside) and doing some climbing. Fixed my hand pains almost immediately.

>It strikes me as odd in this day and age that Apple don't just officially support macOS on non-Apple hardware

Hardware is the product they sell. So it's not surprising at all. If you commodotize the OS, suddenly the huge markup for similar x86 hardware doesn't seem that appealing.

“Darwin” does not include a lick of UI or common framework code. It’s appproximately equivalent to gnu/linux or a bsd: x11 is the only option.

Although I have built Darwin 0.3 and it does run the DR2 userspace and UI. I never did try going with the later versions + 10.4.1 ...

Yes, I should have clarified that the UI/userspace runs fine, but you still need to get those compiled bits from somewhere.

> If they're concerned about instability due to poor quality drivers and its impact on users' perception just offer an "approved supplier" program where hardware manufacturers can have their drivers verified and signed, as Microsoft have done in the past.

Riiiight. And how was the stability of Windows on that "certified hardware"?

No way in hell Apple want to degrade their experience that much.

You will need a CPU with at least SSE4.1 to use macOS High Sierra/Mojave.

It's somewhat amusing to see an Apple OS behaving nicely with an emulated modern CPU connected to 20-year-old PC hardware:

https://en.wikipedia.org/wiki/Intel_440FX

Incidentally this is also how some software detects it's inside a VM --- physically impossible hardware combinations. A real 440FX doesn't support more than 1GB of RAM. Also interesting to note that it was a predecessor of the famous 440BX which was highly popular shortly before the turn of the century.

There are many, many ways for software to detect it's running in a VM, including ways much simpler than checking impossible hardware combinations. If software wants to know it's in a VM it'll always be able to tell, no matter the measures taken against it.

The "simpler" ways are also easier to spoof. I'm talking more about things like malware, which tries very hard to avoid researchers analysing it inside a VM.

If software wants to know it's in a VM it'll always be able to tell, no matter the measures taken against it.

On the contrary, the VM is what the software is running on, and can always feed the software the answers it wants.

I think I still have my BP6 with the dual Celerons somewhere... man, that was a helluva machine in '99!

No need to work so hard, VMs self-identify: https://kb.vmware.com/s/article/1009458

PCIe passthrough is great. Still a few kernel bugs to work out, but when it's working it's magnificent.

Linux/OSX/Windows VM with GPU passthrough working here. The main system can be up all the time with a "reboot" between VM's taking a few seconds.

My workstation is a Ryzen 1700x running Ubuntu. It also runs two Windows gaming machines for me and my kids. GPU passthrough is pretty much painless, and since the NPT bug fix, they are very snappy.

We have been using KVM GPU passthrough of NVIDIA Tesla cards for machine learning two years now. Works fantastically and makes such machines much easier to maintain.

I wish I could have two things from Apple:

* Rack Mountable OSX hardware

* Virtualizable OSX licenses

Continuous Integration and automated UI testing is just not possible today.

Check https://veertu.com/

On the rackmount hardware front, once upon a time there was the XServe. I still have an XServe G5 in storage (one of these days - maybe when I get around to renting some rack space somewhere - I plan to get it up and running again alongside my Sun Fire T2000 and an old Dell PowerEdge I've got). They're discontinued now, but Intel-based XServes are readily available on eBay, last I checked.

There are also rack-bracket-case-things that let you rackmount pairs of Mac Minis. Some colocation providers actually specialize in providing Mac Mini space to fill the macOS server niche.

I'm very interested in developer requests regarding what possible XServe-like hardware could do if it existed. Is it the UX or feature set or dev tools that would be desired? Is it mainly to have something more compatible with their dev cycle? How would you set up your network? Would you like to use something like Docker on MacOS? I think you are not alone in this reasoning.

It's all driven by testing needs.

On my webapps, I can use Selenium IDE to simulate basic user interaction to check for regressions in all features of an app, but also create realistic loading of frontend servers.

There are a bunch of android tools to do the same for apps that can run in the emulator distributed on a cloud.

On Desktop apps, people can use anything from MSFT Terminal Services to Citrix to pound native apps into submission.

Oh man, native containers would be awesome on OSX, bonus points if we could run a full UI.

And there's the economy of scale of "same tools" "same platform" for local development vs cloud deployment. Makes testing so much easier.

FYI, macOS also runs under VMware Workstation / VMware Player (free for personal use), provided you patch the binary to allow it [1].

[1] https://github.com/DrDonk/unlocker

> We will not be using Apple’s actual OSK(SMC) key, which is an attempt to make your virtual machine a “Real Macintosh.”

Does macOS even boot without this key?

I don't recall the details offhand, but I've used High Sierra on VBox on a Debian host. Just a few VBoxManage tweaks were needed to get it to boot. I don't recall any Apple keys being required.

I don't know how this differs with installing Hackintosh on real hardware, but then you provide a kernel extension (kext) called FakeSMC, which emulates the SMC chip present on real Apple computers.

So in a sense, he is not using an actual SMC key, but very probably replaced it by FakeSMC. You can see that it is actually included in the repo he clones: https://github.com/SRH1605/Hackintosh-KVM/tree/master/kexts/...

Yes, but some features are unavailable such as iMessage and probably iTunes DRM, which are tied to the hardware. I was very disappointed to discover this since I was installing OSX in a VM primarily to use iMessage so that I could type my texts like a sane person instead of pecking at a touchscreen sitting next to my keyboard.

Man, some reactions here...

I wouldn't recommend starting with VFIO by running macOS, there are enough hurdles without it. Start with Linux or Windows. And this guide is a bit outdated now anyway.

@hernan604 You can actually find bootable iso's online, and clover files can be edited by hand, so no need for a mac.

Watch out about using downloaded ISOs unless you have a way to verify their hash against a known good copy. The ISO you download could very well have malware.

The paradoxical thing about this is that if you get the iso from the App Store in an official way, you have to agree to the EULA which prohibits running it on a non-Mac computer. But then if you pirate the software, then you are now facing copyright laws instead...

Do you? When you download the installer from App Store, and then convert the ESD dmg to iso, you are not shown EULA yet.

Isn't it shown when installing as a first time?

It is possible to download the files directly from Apple without authenticating nor agreeing to any EULA, and create ISO from that:

https://www.insanelymac.com/forum/topic/329828-making-a-boot...

Instead of wasting your time trying to get this to work (and maintaining it when it inevitably breaks after a macOS update), how about just buying a Mac and using the time for billable work (which would pay for the Mac and still leave a hefty extra)?

I usually try not to come across as condescending on HN, so I apologize in advance, but I'm only copying your tone to get the point across.

Instead of wasting your time arguing with people that made the effort to document things, how about documenting your process on acquiring your first billable clients so that everyone else can reproduce that?

No offense intended nor taken.

I’m not actually arguing with whoever wrote this, however I’m advocating against actually trying this for anything productive, especially not your main machine - you don’t want your workstation to let you down because an update suddenly broke it and you have to screw around for hours trying to get it to work again.

Worth saying if you actually do spend a couple of hours setting it up and disable updates it works great.

Been using a hackintosh for work for 4+ years.

A Hackintosh is arguably more stable and requires less "screwing around" when something breaks, because often that something is hardware and iMacs/Macbooks are notoriously hard to repair yourself.

Unless a random software update breaks it. A Hackintosh's Achille's heel is not hardware breaking down but software updates from Apple hosing it.

I have the high end model of the MBPr 15 2017 and since getting it I had around 3 months total of down time with several replacements and repairs, at this point I would have to argue that the whole reason for a hackintosh is so that I can "use the time for billable work".

Not to mention that quite frankly my high end gaming pc running Mojave under KVM is a way more pleasant and smooth experience than my MBPr.

There is not a single machine that apple sells today that is viable for a power user IMO.

The iMac Pro seems to be plenty viable for a power user. 64 core, 128GB RAM among other things.

0 Upgradability, EXTREMELY thermal constrained, 0 self reparability.

At least for me, that's not a power user machine.

I have seen this referenced multiple times. The iMac Pro doesn't have 64 cores.

The highest end iMac Pro has 18 cores.

Reply on news.ycombinator.com