Comment by lrvick
1 hour ago
> It's an aftermarket mod
Unfortunately one I have never seen a MacOS production engineering guide that does not say "install brew" as like step one, exactly because Apple failed to provide a software suite sufficient to meet developer needs on par with that of major linux distributions. Macports is at least maintained by current/former apple employees and signs their packages, but in practice no one knows macports exists.
> I'd be extremely careful before allowing anyone to manage prod from anything other than a Mac.
I would never even consider letting anyone near production Linux servers if they are not comfortable enough to maintain and secure Linux on the computer in front of them.
> I think there's a business opportunity in fixing that.
Me too! I am in the current YC batch for exactly that reason with https://caution.co , built with https://stagex.tools.
Ah, neat. I did something like Caution a few years ago but for Intel SGX, called Conclave. It made it much easier to deploy apps to enclaves, get remote attestations and communicate with them securely.
Unfortunately it's a difficult space to work in. SGX tries to remove the kernel and hardware from the TCB but there are a lot of obscure attacks to do with tampering with the enclave's sense of time. It's not an SGX problem, it's inherent to enclaves not having enough trusted hardware like signed clocks, tamper-resistant counters and so on.
Also the programming model has to be adapted but most customers just want a button to click for a box to tick, then they can say they're protected. Very few want to change their app architecture to be more secure.
Homebrew is far from ideal, indeed, but MacOS was never really marketed as an OS for people to manage remote server clusters. If you stick within their designed ecosystem and only do software dev for native Apple desktop/mobile apps using XCode, then you don't need homebrew.