I know it's bad security, but I'd be more interested in this if it supported old releases, like Snow Leopard or at least Mavericks (the latter being the final release with the Acqua UI).
I have a fantasy that I'll go back to Snow Leopard some day and live the rest of my life there, but then I remember hardware support is basically nonexistent. A very lightweight VM with GPU passthrough could work around that problem.
I have a Epson Perfection 4490 with no 64bit drivers. I will need to either run Windows or a older version of Mac OS / OS X. I'm sure there are other use cases where one will need a older system. I was actually going to go down the route or building a new Hackintosh but have opted o build a Linux desktop with Mac OS VM using GPU pass through. Using this I could have the latest Mac OS and a older version when needed.
It'd also be useful for testing software on old releases. I work on scientific software. We are currently.... considering... dropping snow leopard support, but partners keep insisting that they use ancient systems. (We had a fight to drop CentOS 5 this year).
> I have a fantasy that I'll go back to Snow Leopard some day and live the rest of my life there
Why is that? Do you prefer the older macOSes? (I'm sympathetic to that viewpoint, but would like to know what about Snow Leopard specifically is what you like.)
Snow Leopard has the perfect metaphors for everything. This extends to many different areas, so I'll focus on apps as an example:
A Mac OS X app is just a particular type of file. You don't "install" apps any more than you'd install a photo or a PDF. Sure, standard practice is to copy apps to your /Applications folder, but in Snow Leopard, this directory didn't have any unique behavior. A Stack for the /Applications folder was placed on your Dock by default, but users were expected to modify the Dock's contents. I was free to organize my apps as I would would any type of file, and the OS felt built to encourage this. If I dragged an app from /Applications to my Desktop, the app got moved. If I dragged iTunes to the trash, iTunes got deleted.
You can certainly do this in later releases, but the OS will fight you! Dragging apps out of /Applications creates an alias, unless you remember to hold down the ⌘ key. Whereas I used to "install" most apps by dragging them to the same Stack I used to launch apps, doing the same with Launchpad just creates a shortcut, which will break if the original is removed.
Lion is when Apple began trying to make macOS more consistent with iOS, regardless of whether the changes were also consistent with the Mac's original UI paradigm. I realize I'm nitpicking, and to be clear, I'm mostly okay with everything through Mavericks, before they switched to an ugly and low-contrast visual style.
Snow Leopard was also my first experience with Mac OS X, so I don't know how much that affects my opinion. But my god, the first day I booted up Snow Leopard and settled into using it over the next few hours... as dumb as it sounds, I just recall a feeling of pure ecstasy.
> Snow Leopard was also my first experience with macOS, so I don't know how much that factors into things.
It's not just rose coloured glasses... I've used all of the classic Mac OS version and OS X from about 10.3 up to snow leopard, there were good, bad and ok versions, none terrible, all the way through there. But 10.6 was the best of the OS X in terms of stability and simplicity, from that point on it really felt like the whole system was being taken in a different direction, no more tick-tock feature-stability release schedule, and no more refinements, just more pseudo features to flash at prospective buyers, more bugs, more cruft, more unforgivable security mistakes, more bloat and far, far less control - basically turning into a bad iPhone as far as I was concerned.
I retreated to 10.6 for as long as I safely could then moved to a Linux desktop when they officially ended support for my machine deeming it obsolete.
Spaces on Leopard (pre-Mission Control) fit my brain like a glove. I'd love to get them back. I have 9 "spaces" in a horizontal row in Mission Control, but in the original Spaces they were in a 2D grid. The 2D gave me a sense of spacial reasoning about where things were.
Interesting! For me it wasn't until High Sierra that Spaces worked well. I have multiple monitors in a row, and want multiple spaces on each. I found unplugging screens (eg to take a laptop to a cafe) lost the apps attached to each screen. That no longer happens, and plugging it back in, each app / window returns to where it used to be.
I have the opposite problem, apps/windows don't consistently return to where they used to be - in particular Slack never does (probably something with electron) but more frustratingly Messages never does either - it always goes to the same location on my primary display.
I don't know what boot environment this is emulating exactly, but it looks like a straightforward OVMF, presumably hacked up with HFS+ support and a bunch of Apple extensions to make macOS boot. In that case, running Mavericks should be no problem. I'd have thought Snow Leopard should also run, at least in K64 mode (64-bit kernel), but I've not tried it in a long time and don't recall if there were any gotchas.
Note also that software support is now pretty weak for these old releases - you struggle to find any modern web browsers that still run, for example.
> Note also that software support is now pretty weak for these old releases - you struggle to find any modern web browsers that still run, for example.
In my fantasy land, I would browse the web with Firefox ESR 45.9.0, which as of this moment is recent enough to be mostly usable.
Other than that, I feel like software support would be a mixed bag. Newer apps wouldn't work, but I'd gain compatibility with older apps that are broken on modern macOS. And since it looks like more and more future apps are just going to be bizarre iOS ports with alien UIs...
According to the readme, jumpstart.sh has just three options: --high-sierra, --mojave, or --catalina. Looking over it again now, I'm realizing those might just be what is available on Apple's servers... is there a way to pass in my own bootable installer image?
I imagine the underlying tech would (hopefully?) work, but I find the automatic script very appealing.
I recently went the KVM MacOS/Hackintosh route (but not using this exact script) and while it functionally worked great— GPU Passthrough (Used RX580 and Vega 56), PCI Passthrough (USB Controller/Bluetooth/Wifi/Ethernet Card/SATA Controller/NVME Drive), iMessage, Handoff, AirDrop, etc. etc. I found it to be hassle on my consumer AMD motherboard with an AMD GPU.
With the AMD GPU, I had trouble resetting the GPU between VM starts/stops without restarting the whole computer. This appears to be a problem with a consumer AMD cards.
It could be specific to AMD Ryzen IOMMU Groups, but it was also pretty annoying to passthrough the PCI devices and still leave the appropriate hardware for the host machine. There aren't any native virtio drivers in OSX so you really need to pass through your sata controller/ethernet card for full performance. Might have been easier with a server motherboard with cleaner IOMMU groups, though.
I ended up just building a bare-metal Intel Hackintosh which was less of a hassle.
VMWare Fusion and ESXi support paravirtualized IO, but virtio is a specific KVM technology. Xen paravirtualized IO is similarly the same idea but not compatible.
Since Apple isn't opposed to releasing new OS flavors, I think they should release "serverOS", a variant of macOS but licensed to run anywhere, even (or especially) on non-Apple hardware and in VMs.
It's very frustrating to a lot of people that macOS VMs aren't easy (licensing/ToS-wise) to spin up on non-Apple hardware, especially since Apple doesn't sell high-end servers any longer. Yes, that calculus will be different when the new Mac Pro begins to sell, but a lot of IT departments would rather add Apple VMs for testing/build/dev to their on existing on-premise compute clouds (vSphere/etc.) than spin up brand new ones on Apple hardware.
Additionally, there's a lot of demand for local Apple VMs on Windows machines. Microsoft makes a lot of money from software that's running on my Mac - especially Office and Windows (via Parallels Desktop or Boot Camp). Why shouldn't Apple make money from VMs running on Windows and Linux machines?
I would be very surprised if they didn't already have something like this internally for hosting iCloud and various other services. I agree it would be great for them to make it more widely available as a product.
Someone mentioned on HN a few months ago that they definitely do have large banks of both Apple-branded and non-Apple machines running a special in-house flavor of macOS. In fact, the last manufacturing run of XServe hardware had a more souped-up configuration than they ever offered to customers and was reserved for internal use at Apple.
It would be ... well, kind of them to offer IT solutions they use internally to other IT departments tasked to support work on Apple platforms. At the very minimum, they could license a version of macOS (or "serverOS") tuned for server workloads, VM deployments, and Apple Remote Desktop sessions.
I don't know that it'd be worth the investment at this point. We already have our widely-supported Unixy system for that, Linux.
Furthermore, there's a longstanding (3 year) bug where the kernel would (very rarely) fail to execute a process. This would manifest as "/bin/sh: fail to execute binary file", because the posix_spawn() call returns an error (this is the actual bug), the libc interprets this as trying to execute a script, and falls back to running it through /bin/sh (this is standard Unix behavior), which can't execute it either because it's not a script.
That such a bug would persist for so long doesn't inspire confidence in the quality of the kernel.
> That such a bug would persist for so long doesn't inspire confidence in the quality of the kernel.
That says more about Apple's current priorities than anything else. Sure, Linux is more mature, but if Apple were to release serverOS for specific types of workloads that are needed, you can bet any bugs that would interfere significantly would be prioritized up.
I would pay a premium to be able to install macOS on a cloud VM that I can scale arbitrarily large (and to arbitrarily many instances, presumably with premium for each). I'd like to do scalable CI and builds for macOS.
(Also, if someone can find a maintainable method for it, I'd love to support someone who maintains a cross-compiler toolchain that targets macOS, making it possible to build Rust and C apps for macOS without having macOS installed. But that's not a complete substitute for having an actual macOS cloud build server, on which the compiled applications can run as part of the build process.)
I'm afraid the markup would have to be a lot more than that. They're banking on you buying multiple pieces of hardware over the years, not just one iMac... Hardware lock-in is their whole business model...
I don't fault them for it, they're a hardware company. Releasing the OS as a consumer product would probably destroy their hardware sales, since users (like me) wouldn't buy Apple hardware anymore.
But like I said, I would pay an outrageous fee to use MacOS on a non-Apple machine without violating the EULA. And I only want it for professional use, where I can justify certain expenses (like a $500 software license + yearly renewal for updates), but can't justify spending $2-5k on an Apple machine that won't give me the performance, maintenance, or upgrade path available from off the shelf components.
It's such a weird business calculus to develop for MacOS. I genuinely love their products and software, but it constantly feels like developers get screwed every generation (especially smaller shops that do heavy lifting on MacOS).
It would be a maintenance nightmare for Apple. MS puts a lot of resources towards making Windows run on everything. Apple controls the hardware with an iron fist so they don't have to do that.
I mean they're not selling me one now, I don't need a hot plate on my desk. But I would pay a (comparatively) obscene amount of money for just the operating system license to install on a midtower.
Very recent versions of Qemu have "experimental" support for HVF, so in theory it should work. I haven't had a chance to try it yet, however, and it's possible that there are some MSRs or similar that aren't sufficiently supported yet. If this is something you(r employer/company) care about, feel free to get in touch as I suspect it's not too difficult to fix if it doesn't currently work.
Does anyone understand why this works on AMD processors without a custom Darwin kernel, as would be needed in a native AMD Hackintosh setup? The core x86 code is still getting executed natively, right? So, what magic does the VM perform?
I've been interested in doing something like this so I can run an iMessage proxy. A lot of neat gateway apps for OSx have popped up (like https://www.wemessageapp.com) to get iMessage support on Android.
I've been doing this for years with some of my own personal projects like https://github.com/CamHenlin/imessageclient, https://github.com/CamHenlin/iMessageWebClient, and https://github.com/CamHenlin/imessagebot and some others - one thing that I'll note is that in my experience, Apple is pretty aggressive and somewhat arbitrary at banning accounts from accessing iMessages if they get on to the service from a VM - even if your usage is normal, personal iMessaging. I was trying out using VMWare and virtualbox specifically. In fact, I've been accidentally successful at getting my computer and home network banned from Apple services by accessing iMessages via VM. I strongly recommend running these types of services on bare metal Macs although ymmv.
most people don't understand the difference between a civil offence and a criminal offence (which is what i would use the term "illegal" to describe).
Violating a contract is not "illegal", but is a civil offense, and requires the other party to sue you to recover damages. Copyright infringement is also not "illegal", but is a civil offense (however, i do believe that a lot of copyright lobbies want to change copyright violations to be a criminal offence, so they won't need to sue, but instead use public prosecution to recover their damages).
This is terrible legal advice. Criminal penalties for copyright infringement offenses have existed since at least 1897 in the United States, and at least 1921 in Canada.
While I understand the point you were trying to convey WRT the differences between civil and criminal offenses, copyright infringement is not a particularly good example of this.
> The unauthorized reproduction or distribution of a copyrighted work is illegal. Criminal copyright infringement, including infringement without monetary gain, is investigated by the FBI and is punishable by fines and federal imprisonment. [0]
I believe the MacOS license requires to run on Mac hardware, so in order to be compliant with the license you'd need to launch a big VM Linux on top of a beefy Mac Server then inside the big Linux VM provision all the MacOS VM instances you want using the utility mentioned in the post.
Unfortunately, you would fall afoul of their license doing this as well. They only allow you to virtualize two instances of macOS per host machine.
(iii) to install, use and run up to two (2) additional copies or instances of the Apple Software within virtual operating system environments on each Mac Computer you own or control that is already running the Apple Software, for purposes of: (a) software development; (b) testing during software development; (c) using macOS Server; or (d) personal, non-commercial use.
Unfortunately, this is no longer the case. Linux support for WiFi, audio, and suspend/hibernate has been completely broken on 15” MacBook Pros since the 2016 models hit (WiFi still works on the 13” MBPs, afaik).
I don’t think informing people about ways to do things that go against software licenses violates the license.
Also, following these instructions doesn’t necessarily violate Apple’s license. You can run Linux on Apple hardware, and install Mac OS X on top of it, can’t you?
Finally, IANAL, but software licenses likely aren’t enforceable to consumers in large parts of the world (a shrink-wrap “take it or leave it” probably wouldn’t be considered an agreement between parties in many courts, and that’s what you need to call something a license)
This should no longer be necessary with newer Qemu versions (since 2.10 or 2.11 I think) as the USB tablet's device descriptor has been fixed to be standards-compliant in Qemu.
(Source: I'm the author of both that driver and the Qemu patch but I've not been able to spend much time on macOS virtualisation lately so it's possible things have started breaking again.)
I just bought a used dual socket (E5 V2) server to play with KVM and to try do just this... I suspect, performance is probably pretty righteous even in the VM, and old xeon's like the 2667 V2 are dirt cheap these days. MacOS doesn't need much VRAM and old AMD cards are pretty cheap (GPU passthrough is easier with AMD cards [1]).
I'm really looking forward to running this later.
[1] I could be wrong on this, but from my previous research into gpu passthrough made it seem as though NVidias consumer cards aren't generally allowed to do it because they're driver locked.
Poor unless you have a macOS-supported GPU to put through PCI passthrough. Otherwise, macOS will not use graphical acceleration and the system UI will be very glitchy (e.g. severe ghosting) and slow to respond.
For both iOS simulator and Safari, the lack of GPU acceleration can be a problem, depending on what/how you're trying to test, and also depending on OS version. I believe Xcode 11 requires a Metal-capable GPU in order to even run. As someone else has mentioned, you can however use IOMMU/PCIe passthrough with certain graphics cards to get acceleration inside the VM.
That's my question. This seems hugely useful to automate MacOS builds in a sane manner. Yet, due to licensing I do wonder if it's even worth caring about.
If I use this at work I'd be risking my job on if Apple decides to sue my work for not following MacOS licensing for our build pipelines. If I use this in OSS / private software, I risk them suing me directly.
Shame, all I want to do is streamline providing software for Apples customers. You'd think Apple would want that more than some small money from a hypothetical non-Apple user merely trying to deliver products, functionality and improved UX to Apples customers. I feel like our (my and Apples) incentives are aligned. /shrug
I think part of the reasoning, perhaps misguided, is for quality assurance. It's easier for them to say our stuff runs only on our 'certified' hardware then to try and support everything under the moon.
These days I don't think that argument holds up though, back in the early days of x86 hardware and peripherals it made more sense.
In a past life we used mac minis sitting on a shelf in a datacenter to run builds off of, it worked well enough.
Handoff requires a very specific set of Bluetooth hardware iirc, and it would need to be entirely passed through. So most likely no. And I believe that some of the iCloud services (specifically those entangled with iMessage/FaceTime) will require a valid SN (you can “generate” one by brute force though). It’ll also require that you give it two interfaces, one Ethernet and one wireless (and it’ll sometimes need to start a small wireless network for things like Airdrop).
Thanks! So if I were to build a new system just for this and could decide on the components, and had an old Mac Mini flying around whose SN I could take, then it should entirely be possible, right?
That’s generally preferable, yes, but I believe the SN needs to match the model identifier, and it’s generally best to match the model closest to the hardware you’re using. At that point, if it’s a specialized rig for this, I’d just skip out on KVM and just install it. Sites like tonymacx86 have build guides they keep up to date with the “most compatible” parts.
I assume by "new API" for VMs on macOS you mean Hypervisor.framework, which is supported by qemu 4.0.0 and xhyve, both open-source. I wrote a blog article about using qemu with Hypervisor.framework to install Debian in a VM here: https://sigmaris.info/blog/2019/04/automating-debian-install...
I have a fantasy that I'll go back to Snow Leopard some day and live the rest of my life there, but then I remember hardware support is basically nonexistent. A very lightweight VM with GPU passthrough could work around that problem.