Hacker News new | ask | show | jobs
by timsneath 2 days ago
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
6 comments

> 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 set of core utilities and dynamic libraries to reduce resource utilization and attack surface.

> - Privacy: When sharing host data using container, you mount only necessary data into each VM. With a shared VM, you need to mount all data that you may ever want to use into the VM, so that it can be mounted selectively into containers.

> -Performance: Containers created using container require less memory than full VMs, with boot times that are comparable to containers running in a shared VM.

More details, including technical limitations (they’re looking for bug reports and contributions): “Container: Technical Overview” https://github.com/apple/container/blob/main/docs/technical-...

Sounds like a lot of the same choices/compromises that are in wsl2.
Yes, this looks similar to wslc announced at Microsoft Build. They should have joined forces, Apple and Microsoft. Can you imagine?
You mean like for the first 20 years or so of Apple and Microsoft's history?
> ... highly integrated Linux environment that works seamlessly on your Mac. ...

Which kernel is running, and is it hosted in hypervisor.framework, as is done with UTM (when not using the qemu mode)?

The katas container kernel by default.
Ah, the Darwin/BSD Subsystem for Linux.
Not quite, it’s still a VM. And while it supports virtio balloon for growing RAM, it doesn’t yet support releasing that RAM back to the host. And there isn’t a convenient way to shrink the sparse disk images as they grow yet, either.
Isn't the Windows subsystem for Linux (the reference there) also a VM?
Only WSL2; WSL1 was an actual subsystem.
So this is Darwin/BSD Subsystem for Linux 2.
Yes.
WSL1 was so cool, WSL2 made it boring and isolated.
WSL1 was very conceptually appealing, and ended up working very poorly because of the poor matching between Linux syscalls and the Windows kernel. Git suffered terribly as a result. The inverse is also somewhat true - there have been cases where Wine is much slower than native Windows because Linux simply doesn't provide a simple way to achieve the same outcome, and interestingly the Wine developers have had reasonable (if tediously slow) success in making it possible to express the same semantics to Linux and have it handle things fast. It would be fascinating to know whether WSL1 developers didn't have enough traction to get Windows internals altered to match, or whether it's just way harder to do the same under Windows.
Back in my day you to to download a couple GB worth of cygwin, and that wasn't an actual environment, basically just a GNU toolchain compiled for windows. But it got you like....grep and bash and stuff that ran natively on windows which was kinda cool.
It was soooo slow though. Practically unusable for anything i/o heavy.
WSL 1 is long gone for all practical purposes, yet it still dominates conversations.

Also everyone on FOSS gets it wrong, WSL wasn't a subsystem like classical Windows NT ones.

It was based on Drawbridge research using picoprocesses, a new approach for library OSes.

https://learn.microsoft.com/en-us/archive/blogs/wsl/pico-pro...

> Also everyone on FOSS gets it wrong, WSL wasn't a subsystem like classical Windows NT ones.

Everyone in FOSS? How about Microsoft got it wrong, since they actually named it The Windows Subsystem for Linux (WSL)? It wasn't the FOSS community who chose the name for them.

And a limited VM, for example I look at the documentation and it's not possible to share USB devices with the VM, making it perfectly useless for doing embedded development where you have to connect to the boards with USB. I will continue to use UTM for that reason...
Virtualization.framework just gained USB passthrough support in macOS 27. It might be a niche feature for containers to add, but other VM software will likely add support soon.
Mac Subsystem for Linux 2
This is not a problem at all as most Apple computers come with plenty of RAM and lots of disk space! We are so lucky that Apple engineers always think so differently into the future!
WSL is a VM too, but that's still what this is. WSL for MacOS. It's great!
So, heavier than running docker in qemu?
Exactly what I thought. The Mac equivalent to WSL. Which is a great thing for Mac devs. Lots of stuff expects Linux these days, not POSIX. Mach isn’t Linux.
> filesystem mounting

How is this different to bind mounts

Very different: Linux running in a virtual machine can't bind mount into a macOS host's filesystem. So they use virtiofs.
MacOS container filesystem/IO has been bog slow preventing even some basic dev container use cases. Hopefully this will fix the issue.
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)

This applies to both containers and container machines though, right?
Containers (those popularised on Linux by Docker) are built on Linux primitives like cgroups and namespaces, so they're running directly on the same kernel, same VFS, often the same FS, etc. Their isolation properties rely on (a) all those Linux features working as expected, and (b) the container runtime setting them up properly.

Depending on your threat model, that's fine, but a lot of people (including me) will say that containers are not a security mechanism.

But macOS requires[1] virtualisation for containers anyway; the security is just a bonus.

[1] at least for a real Linux kernel...

The surface of an OS is definitely larger than that of many hypervisors, which is e.g. why browsers often provide their own much narrower sandbox.

On the other hand, in other scenarios, people trust the security boundaries of their working as expected all the time, no? This is the basis of e.g. Android app isolation (every app runs under its own Linux UID/GID), and true multi-user Unix systems trusting the OS's security boundaries to hold have decades of history.

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. :-)
how does that compare to something like, eg, Orbstack?
Still feels like a apple-ified microvm
Well yeah it’s a simple vm…
Basically is it sounds like