Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

macOS Container Machines

github.com

Post reply on HN
Print view View original

251–260 of 457 posts

Re: macOS Container Machines

#251

Post by mjg59 »

LoganDark wrote: post #89
gsnedders wrote: post #65

Earlier quoted context omitted.

Only WSL2; WSL1 was an actual subsystem.

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.

Re: macOS Container Machines

#252

Post by torarnv »

kdrag0n wrote: post #26
blahgeek wrote: post #10

OrbStack works really well for me. I wonder how it’s compared to this performance wise

(OrbStack dev here.) Instead of Virtualization.framework, we have a custom Rust virtualization stack with custom devices and protocols for things like filesystem sharing. It's a highly optimized vertically integrated stack specifically for running our Linux machines and containers. Our biggest perf/resource gain is dynamic memory, which reduces memory usage a lot by releasing unused memory back to macOS. Nothing else…

Those are awesome features! The one missing for me is bridge networking. Any idea why orbstack doesn’t have that?

https://github.com/orbstack/orbstack/issues/342

Re: macOS Container Machines

#253

Post by emulio »

This appears to be an LXC-style alternative for macOS; however, unlike native LXC on Linux, this tool relies on VMs. While Docker and Podman also utilize a VM on macOS, they offer the advantage of the Docker Compose format. In my view, the ability to use YAML for declarative configuration is the most critical feature for any container tool. I have nothing against CLI tools in general, but I prefer avoiding repetitive manual commands that could be easily automated via Docker Compose or Kubernetes manifests.

Re: macOS Container Machines

#254

Post by TylerE »

iririririr wrote: post #235
TylerE wrote: post #90

Earlier quoted context omitted.

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.

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…

shrug. I haven't owned a Windows machine in years at this point. It's one of those things like PHP that I just decided my life was better off without.

Re: macOS Container Machines

#255

Post by kenanfyi »

I don‘t understand why these tools always advertise about mounting the $HOME inside the container. Isn‘t it better to have a complete isolation? Isn‘t that the point of using such a thing?

Re: macOS Container Machines

#256

Post by jdub »

bogantech wrote: post #219
timsneath wrote: post #11

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

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

Re: macOS Container Machines

#257

Post by avsm »

I looked at this last year when it came out in Tahoe: https://anil.recoil.org/notes/apple-containerisation and this looks like more of the same.

They've now added a WSL-style virtual machine layer, but there's no x86 container story (Apple's killing Rosetta) so I imagine some qemu shimming will be required.

There's still no equivalent to VPNKit or GVisor for networking so you'll be bridging I think. See: https://cacm.acm.org/research/a-decade-of-docker-containers/ for how Docker for Mac does this

I can't spot any support for dynamic memory ballooning to prevent the hypervisor from gobbling up too much memory. We've had this in Xen since forever! https://xenproject.org/blog/ballooning-rebooting-and-the-fea...

And, most obviously: NO SUPPORT FOR MACOS. This is the single feature that only Apple can do, and they're choosing not to implement it deliberately, and it's so stupid given the pains we all have to go through to implement CI for macOS. In the land of OCaml, we were forced to implement a custom ZFS snapshotter to get reasonably cost effective macOS CI for our package repository: https://tarides.com/blog/2023-08-02-obuilder-on-macos/. This was fun to build, but it sucks to have to maintain it.

Also, I'm really curious what the GPU passthrough story here is for LLMs, since the Apple Silicon -> Linux kernel support is gated on Asahi's support, but that's been lagging beyond M2 due to the efforts of reverse engineering.

Do better for your developers, Apple. This is a half-baked sweep across third-party software without addressing the core needs around your own operating system.

Re: macOS Container Machines

#259

Post by notpushkin »

emulio wrote: post #253

This appears to be an LXC-style alternative for macOS; however, unlike native LXC on Linux, this tool relies on VMs. While Docker and Podman also utilize a VM on macOS, they offer the advantage of the Docker Compose format. In my view, the ability to use YAML for declarative configuration is the most critical feature for any container tool. I have nothing against CLI tools in general, but I prefer avoiding repetitive…

Apple does have an OCI variant of this: https://github.com/apple/container

Doesn’t seem to have Compose support though, but it’s probably not impossible to build upon.

And of course, it also uses VMs, though unlike Docker, it’s one (micro-?) VM per container: https://github.com/apple/container/blob/main/docs/technical-...

Re: macOS Container Machines

#260

Post by LoganDark »

mjg59 wrote: post #251
LoganDark wrote: post #89

Earlier quoted context omitted.

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

Wine achieves better performance these days due to things like... adding a module to the Linux kernel that implements NT-like synchronization primitives. So, Linux subsystem for NT synchronization basically. (a.k.a. NTSync)

Maybe this works out better because Linux is more flexible, while Windows/NT is more "set in its ways" and therefore more difficult to implement Linux on top of... Maybe?

Post reply on HN