Live data from Hacker News

macOS Container Machines

github.com

431–440 of 457 posts

Re: macOS Container Machines

#431

To clarify a few comments here: this is not only OCI containers: container machines add support for persistence and filesystem mounting, making container machines a great lightweight Linux environment for developers using macOS. More details here: https://developer.apple.com/videos/play/wwdc2026/389

Still feels like a apple-ified microvm

Basically is it sounds like

Re: macOS Container Machines

#432

Earlier quoted context omitted.

> 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…

> I'm not sure how it'd defeat the point of having their own kernel. Because then you'd need to both maintain your kernel AND your own implementation of the Linux ABI, an ABI you don't have control over and that basically forces you to reimplement half on Linux in the first place. People already get what they want by having a tiny Linux machine running at native speed. In 2026, virtualisation still isn't free, but it…

> Because then you'd need to both maintain your kernel AND your own implementation of the Linux ABI, an ABI you don't have control over and that basically forces you to reimplement half on Linux in the first place.

A very large portion of that ABI is already implemented due to both systems being POSIX. But further, a lot of what programs actually interact with is already ported to macOS. For example, you can build and use glibc.

Also, I get the lack of control, but that really isn't a major issue. The linux kernel pretty rarely adds new userspace additions. By and large the majority of work that goes into the kernel is around new drivers and fixing drivers. Even when there's kernel level features, it's very often not a userspace thing but rather things like new schedulers.

There's a reason MS didn't see the same approach as being too terribly crazy with WSL1, and those are very different systems. Heck, there's a reason cygwin continues to exist and work.

Re: macOS Container Machines

#433

Earlier quoted context omitted.

> I'm not sure how it'd defeat the point of having their own kernel. Because then you'd need to both maintain your kernel AND your own implementation of the Linux ABI, an ABI you don't have control over and that basically forces you to reimplement half on Linux in the first place. People already get what they want by having a tiny Linux machine running at native speed. In 2026, virtualisation still isn't free, but it…

> Because then you'd need to both maintain your kernel AND your own implementation of the Linux ABI, an ABI you don't have control over and that basically forces you to reimplement half on Linux in the first place. A very large portion of that ABI is already implemented due to both systems being POSIX. But further, a lot of what programs actually interact with is already ported to macOS. For example, you can build an…

> A very large portion of that ABI is already implemented due to both systems being POSIX.

POSIX provides an API, not an ABI, and that API kind of ends at libc. Being compatible with Linux at an ABI level means being able to provide the same syscalls in the same way as Linux does. Not all Linux syscalls map cleanly to POSIX APIs, and in general xnu has lots of different concepts that make it somewhat cumbersome to adapt to what the Linux kernel does. The example of this is Microsoft with WSL1; they gave up not because Windows was too shoddy but rather because people want ALL of the kernel, which is a moving target anyway. it's a waste of time not to simply run it in the first place, virtualization is cheap and you get the real thing, with no quirks

Re: macOS Container Machines

#434

Earlier quoted context omitted.

Actually Linux was very SysV like back in the day, so it was more like the stuffy OS's that people liked. GCC was the real catalyst, With even SUN which had used bundled dev tools as a early selling point was unbundling them and charging more, many x86 UNIXes like SCO didn't even come with a tcp/ip stack without an extra fee...and you couldn't take C code from HP to another system and actually have it compile. As Sol…

> IMHO the real Linux advantage is that it was using the gnu user land, and thus gcc worked well with it and companies started to sell commercial support early. IMHO what really differentiated Linux were a. the bazaar development approach, which lowered barriers to contribution, felt more transparent and "safer" with regards to what was going on in kernel land b. the GPL, which while annoying to certain companies due…

> and also a noteworthy mention was the fact the BSDs were basically sabotaged by AT&T via their nefarious set of lawsuits, which nipped in the bud any semblance of advantage they had

People keep saying that but I saw zero evidence of those lawsuits factoring into any purchasing decisions that customers made.

I saw Solaris SPARK servers purchased for running Informix RDBMS

I saw Solaris deployed for payroll systems running Oracle middleware.

I saw FreeBSD servers built for web hosting

I saw FreeBSD servers built for ISP backend services

But at no point in the 90s did I see anyone running Linux commercially. In fact the only reason I ran Linux (Slackware) in the 90s was to see what all the fuss was about from my nerdy younger peers on IRC. And even then, I just threw it on a desktop PC.

In the 90s you had NextStep workstations used to build games intended for PCs (like Id Software did with Doom and Quake). And used at CERN for the development of the WWW.

UNIX was the 90s platform of choice for computer animation. It was the platform of choice for multi-tenant web hosting. And so on and so forth.

Much as Linux had the cool hacker community, 90s UNIX systems had superior ACLs, containerisation, faster TCP/IP stacks, significantly more stable file system drivers and so on and so forth. So people naturally chose UNIX for their important systems. And that’s exactly the trend I personally experienced in the 90s.

This isn’t to say that I think the unix wars had “zero effect” on the decline of unix, but I do personally think the amount of impact it had is massively overestimated. I think Linux would have taken over regardless because the Linux culture embraced everyone’s weird ideas vs UNIX systems that did extensive gatekeeping. And the kids that played with Linux because it was fun and hacking was encouraged, grew up and became influential in decision making.

I think the culture of Linux had more to do with Linux’s growth than anything else.

Personally, I don’t think the license made any difference here. I do get the arguments people make about GPL, but GPL was around since before Linux and it didn’t gain significant traction then. But like most of the opinions I’ve shared above, it’s an impossible point to prove either way.

Re: macOS Container Machines

#435
post #383

Earlier quoted context omitted.

Different threat models. Your typical Android device (and Linux server for that matter, at home or at scale) is not usually running security-sensitive general workloads for multiple tenants in the same OS instance. :-)

I don't think that's right. The threat model for Android for example could well be a malicious third party leveraging a vulnerable app to gain access to your banking app on the same device. There's definitely (meant to be) a security boundary between apps.

These are all security boundaries of a kind, some more effective than others, balancing priorities according to threat model. Running every app on your phone in a hardware virtual machine would be... an expensive choice.

Re: macOS Container Machines

#436
post #384

Earlier quoted context omitted.

It's not substantially different from previous approaches (9pfs vs. virtiofs). My suggestion: Don't use the host filesystem from the guest at all. It'll be faster, and better isolated. It's a false convenience.

sshfs?

That's a less efficient protocol than 9pfs and virtiofs, even if you subtract the encryption.

An example of improving efficiency: virtiofs has a relatively recent feature to map pages from host memory directly into guest memory, but that's a lot of risky acrobatics if your priorities are reliability and isolation...

... but it's not supported by Virtualization Framework's built-in virtiofs "folder sharing". (sad face)

... but someone could build it on top of the new macos 27+ custom virtio device support. (intrigued face)

Re: macOS Container Machines

#437

Earlier quoted context omitted.

what do you mean? that's still the only way to work as a human in windows. wsl1 almost replaced it, but obviously they scrapped it. if you must use windows, it's because you will compile for windows. so you install MSYS, which is a linux distro-ish compiled native for windows. and do your work. wsl2 (and this apple thing) is just a meme. if you're working in it, you're better of just installing Linux or ssh'ing to a…

> wsl2 (and this apple thing) is just a meme. if you're working in it, you're better of just installing Linux or ssh'ing to a server. Many enterprises allow windows only so your way into Linux is via WSL2

There is also git-bash which usually doesn’t need to have administrator to be installed.

https://git-scm.com/install/windows

Re: macOS Container Machines

#438

Earlier quoted context omitted.

It did work quite well. The problem with the filesystem could have been solved by optimizing the Windows kernel, that would have benefit also programs run outside the WSL by the way (NTFS have performance problems and Microsoft knows, and even provided a kind of solution as far as I know with the developer FS or what they call it). The thing that I don't like of the WSL2 is that is just a VM, but a VM that is very li…

Why would you work on embedded development through a VM? Out of curiosity.

[dead]

Re: macOS Container Machines

#439

Earlier quoted context omitted.

Funny how confidently people can mock while knowing nothing about the specific tech discussed and the different targets. I'd google: VirtualBox vs containers.

It's called a container machine but it's a virtual machine. I quote from https://github.com/apple/container/blob/main/docs/technical-... > container runs containers differently. Using the open source Containerization package, it runs a lightweight VM for each container that you create. This approach has the following properties: > * Security: Each container has the isolation properties of a full VM, using a minimal s…

Obviously you still run a virtual machine to provide the Linux part.

But it's a tiny one, tightly integrated with macOS hypervisor, and the interface is standard OCI-compatible containers/images. It's not Virtualbox style VM.

Re: macOS Container Machines

#440
post #390

Earlier quoted context omitted.

Those only came to be after AT&T lawsuit was cleared, and by then Linux already had enough wind behind it. Also SCO lawsuit was more due to IBM's money than Linux. Both a different situation than Windows NT being available a decade earlier.

You’re sidestepping my point that FreeBSD was in widespread use in the 90s. My point about SCO wasn’t clear though. I was just saying FreeBSD wasn’t as embroiled in the UNIX wars as the others, ie referencing SCO vs Linux to demonstrate how even Linux suffered more time in the courts than FreeBSD did.

Not at all, except for Hotmail and Yahoo, I never saw it being used personally.

In fact, had I not bought a set of Walnut Creek CD-ROMs, I would never had used it in first place, and never again since those days, excluding derivatives like macOS and Orbis OS.

Which is why I asserted with good POSIX support, the world today probably would be Windows NT linage on the PCs, plus the commercial UNIXes everywhere else.

Post reply on HN