Live data from Hacker News

macOS Container Machines

github.com

371–380 of 457 posts

Re: macOS Container Machines

#371
post #324

This is all fine and dandy, but where are the native Darwin Jails Apple? Still scared that people will filling whole rooms of Mac Minis if you allow them to have multiple macOS containers and not only up to two fat VMs per machine?

Darwin namespaces would be much more interesting and we are in dire need of them in the current security landscape. I don’t really understand the hype for Apple’s Containerization, it’s just another container runtime alongside many others. It’s not really any better than OrbStack - in fact it’s worse.

Thank you for answering that question because I adore OrbStack and didn't find much difference.

Re: macOS Container Machines

#374

I belong to a rare breed of very opportunistic hobby-developers that like to use MacOS but also like to use linux machines or BSDs (rpi etc) sometimes. I can create docker-images with docker compose, or use something like colima, which this seems to be close to (that should have some advantages over docker, although my hope of circumventing W^X page protection did not pan out). I was perplexed that the repository doe…

I built this tool to solve that exact problem: https://github.com/smol-machines/smolvm

Re: macOS Container Machines

#375
post #365
post #263

Earlier quoted context omitted.

You can run amd64 binaries inside an aarch64 Linux virtual machine. Although they're not supporting Rosetta for macOS apps from macOS 27, the Rosetta support in Virtualization Framework will remain.

Did Apple officially confirm this or is it based on the statement regarding games?

[dead]

Re: macOS Container Machines

#376
Handy for sure!

In production though, I've moved completely to systemd isolation of apps, rather than Docker-like containers; essentially blackboxes and present a supply chain threat. There's also a DRY principle here. Verification of a host presents a much smaller surface area.

Re: macOS Container Machines

#377

Earlier quoted context omitted.

> Wasn’t compatibility what really sunk WSL1? Yes, but a big part of the problem with WSL1 was the size of the conceptual gap between POSIX and Windows NT that WSL1 had to bridge. An “MSL1” would likely have fewer problems because the gap between macOS and Linux is smaller, given they are both POSIX The other thing Apple could potentially do, is add Linux-compatible APIs to macOS. IBM wanted to support Kubernetes on…

Linux and the BSDs take APIs one from the other all of the time. The issue with having a Linux ABI is that you don't need just the few APIs you're missing, you need to implement the WHOLE Linux API and it has to be _perfect_, otherwise stuff will randomly break. I loved the original WSL, I had to use it for a time period back in the day when I was stuck on a Windows PC, but it can't be denied it was full of random bu…

The original WSL proves that you actually don't need to be perfect or to have the entire ABI to be pretty useful.

It's true that missing ABIs will cause random crashes and problems. However, a lot of apps can run with a minimal set of ABIs.

Re: macOS Container Machines

#378

Is there any reason why macOS doesn't try a WSL1 style approach? I get why that didn't fully work out for windows, but it seems like macOS being another *nix would make a lot of what was hard for windows, easy for mac. It seems like it should be possible to run most linux applications natively on macOS with few additional new APIs. BSD actually has this already.

FreeBSD has Linuxlator because there is a lot of binary only software that was never and never will be ported to BSD, so it's necessary for them in order to avoid bleeding users away. Conversely, macOS has basically all software ported natively to it, so when you _need_ a Linux environment 95% of the time it isn't because you need $XYZ that only run Linux, but because you need a proper Linux environment with systemd,…

> Implementing that stuff on top of XNU would probably be extremely expensive and it would arguably defeat the point of having their own kernel in the first place.

I'm not sure how it'd defeat the point of having their own kernel.

As for cost, possibly, but it would really be a huge boon to macOS for software devs. It's hard for me to believe that Rosetta isn't similarly costly, but it's been done because running x86 software is still very much a necessity for MacOS.

Re: macOS Container Machines

#379

It's funny that the system config page ( https://github.com/apple/container/blob/main/docs/container-... ) lists pebibytes for RAM configurations... in this day and age where buying a 16GB stick for workstation would cause me to eat instant ramen for a couple of months because my dentist needs an LLM chatbot on their page to stay competitive! UX wise it looks kinda neat though!

Signed in just to say LoL at the dentist comment.
Post reply on HN