Hacker News Reader

Comment by wicket | Hacker News Reader

> For comparison, you can rent an equivalent Mac Mini from MacStadium for $139/month, $1,668/year. Or you can rent their cheapest model for $59/month, $708/year.

> You can also buy the equivalent Mac Mini for $1,899.

Not only that, but MacStadium lets you run multiple VMs on a single Mac at no extra cost. Amazon's offering is seriously underwhelming.

The more I use or learn about MacStadium, the less impressed I am with it (3 layers of virtualisation is overkill in my opinion!), but it beats the hell out of what Amazon has just announced.

The big problem with CI/CD on Mac is that Xcode does not allow you to run builds in parallel, so you need one Mac per build unless you use virtualisation.

To be honest I'm surprised that no one has added namespace/jail support to macOS yet. The XNU kernel is open source so this should be possible. In fact, can someone explain to me why there doesn't seem to be any sort of XNU hacking community?

View on HN

Not only that, but MacStadium lets you run multiple VMs on a single Mac at no extra cost. Amazon's offering is seriously underwhelming

To the hobbiest market, yes. But large companies, at which this seem to be aimed, work with names they know, not names they don't.

The company I work for would pay more to use Amazon than MacStadium for equivalent products. That's just how corporate bureaucracy works. It shouldn't, but it almost always does.

As far as I'm aware, if you go for Orka Cloud, you only pay for the physical Mac, not the VMs. I've no idea about the hobbiest market, I've only used MacStadium for a large company. I didn't personally make the purchase but that's the information that has been relayed to me.

> The big problem with CI/CD on Mac is that Xcode does not allow you to run builds in parallel, so you need one Mac per build unless you use virtualisation.

Yes it does. The Xcode GUI only allows one build at a time, but you can run multiple `xcodebuild` command line builds using the same or different versions of Xcode in parallel, even under the same macOS user.

For running tests, there used to be problems if you were trying to invoke the iOS Simulator for different versions of Xcode in parallel, but those issues were fixed 4 or 5 years ago.

I've setup and used a set of bare-metal Mac mini CI runner, each configured to run two jobs in parallel, and the Xcode pieces of that are rock solid and didn't need _any_ workarounds to enable parallel jobs.

> Yes it does. The Xcode GUI only allows one build at a time, but you can run multiple `xcodebuild` command line builds using the same or different versions of Xcode in parallel, even under the same macOS user.

This isn't true. "xcode-select" forces you to set a system-wide Xcode version. If you have a job that uses one version and a concurrent job selects another version, it will potentially break the first job.

> there doesn't seem to be any sort of XNU hacking community

Probably because (from what I've heard), even using xnu is extremely painful, let alone hacking on it.

And it's not like you can re-compile your changes to xnu back into a working MacOS machine

> And it's not like you can re-compile your changes to xnu back into a working MacOS machine

Wow, that's just awful, but it would it explain it. Thanks!

That’s not true. You can run macOS with a custom-built kernel and it should work fine, although it won’t be exactly the same as the stock one (the released source is missing some bits).

Okay, so it should be possible then. That brings me back to me original question of why isn't there a XNU hacking community?

The Hackintosh community sometimes uses custom kernels, although much less often nowadays than they once did. There are custom kernels to add support for AMD processors (most common by far), and kernels to add compatibility with Intel processors that don't work natively (e.g. Atom). These do work on real Macs too, I used one a couple months ago for something stupid: https://apple.stackexchange.com/questions/402726/how-can-i-a...

Nowadays, however, Hackintosh tends to rely entirely on patching the kernel in memory, even on esoteric platforms like AMD. Custom kernels are really inconvenient for a few reasons—they get set back to stock after every update (which potentially means your computer won't boot, if you forget to put the custom kernel back before your machine restarts), and Apple releases XNU's source on a ~6 month delay.

I would love to see more kernel experimentation, but I think there's just not a lot of reason to do it? If you're on a Mac, you don't need to add support for new hardware.

That said, it would be great to get a kernel which e.g. disables TCC, or maybe which removes Big Sur's signed snapshot stuff. Both of those feel like achievable tasks, and they would have a real use!

Reply on news.ycombinator.com