Live data from Hacker News

macOS Container Machines

github.com

61–70 of 457 posts

Re: macOS Container Machines

#61

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

[deleted]

Re: macOS Container Machines

#63

Is this new? I thought we had this already In my testing (iirc) filesystem performance was not good enough to be usable with node/rust dev where lots of small files get stat-ed update: what's new is the `container machine` subcommand. I went to test it out, but container failed to run at all for me: https://github.com/apple/container/issues/1681

Curious if you've tried OrbStack? There's always more work to do (test workloads appreciated!) but we've put a lot of effort into optimizing for small files and other common developer workloads in OrbStack's customized filesystem sharing protocol (not standard virtiofs).

Re: macOS Container Machines

#64
post #29

Earlier quoted context omitted.

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.

Mac Subsystem for Linux 2

Re: macOS Container Machines

#65

Earlier quoted context omitted.

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.

Re: macOS Container Machines

#66
post #26

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…

> Our biggest perf/resource gain is dynamic memory, which reduces memory usage a lot by releasing unused memory back to macOS. Nothing else supports this, including Containerization.

Wow, missed this when reviewing OrbStack. I assumed that you just used Containerization and therefore would have the same limitation.

Re: macOS Container Machines

#67

Wouldn’t it be nice if services like Codespaces or Coder or Gitlab would allow you to target running on their hosted/integrated platform, or let you launch that same container completely locally? Sometimes I wanna take my “remote” dev environment off-line but still benefit from the integrated UX.

This exists. It's called devcontainers and there is a cli for managing it locally.

https://github.com/devcontainers/ https://containers.dev/

Re: macOS Container Machines

#68

Wouldn’t it be nice if services like Codespaces or Coder or Gitlab would allow you to target running on their hosted/integrated platform, or let you launch that same container completely locally? Sometimes I wanna take my “remote” dev environment off-line but still benefit from the integrated UX.

Maybe I don't understand but why doesn't Gitlabs self hosted setup work?

Re: macOS Container Machines

#70
post #49

Earlier quoted context omitted.

This is incorrect macOS is fundamentally more secure than desktop Linux operating systems and it isn't particularly close. No amount of Linux hardening will get a system even close to an M-chip Mac. Software insecurities aside, desktop Linux OS systems have almost none of the hardware-backed security benefits that Macs do.

At some point, lack of security becomes a feature. A fully secure, locked-down, T2 attested macOS is able to be controlled not just by Apple, but by increasingly evil governments, with no recourse available to users.

Conversely, a Linux system with no verified boot can be easily tampered with without the user detecting it by people lower than the government such as casual hackers. So in a world where your government is going crazy, you're opting for an operating system that can be penetrated with relative ease (e.g. with persistent root malware) both by a non-government hacker on top of a state backed one.
Post reply on HN