Live data from Hacker News

macOS Container Machines

github.com

281–290 of 457 posts

Re: macOS Container Machines

#281

Will this be able to replace docker desktop an equivalents, removing the expensive Linux VM that runs alongside them?

This explicitly provides a Linux VM, which seems hard to do without providing a Linux VM.

The use case is actually the opposite of what you seem to want (i.e. running Linux containers on macOS without a Linux VM); this uses a Linux-based container implementation of macOS to provide a long-lived Linux VM that looks more like a VM itself than a container.

Re: macOS Container Machines

#282
post #135

Earlier quoted context omitted.

Potentially faster application execution along much lower memory requirements. In the case of docker, even a possibility of shared library loading further reducing runtime costs (For example, containers based on the same base image could load glibc into memory only once). There's also simply the possibility of using linux software directly in macos without doing OS dependent changes to the software.

Yeah. But in exchange it’s a lot of work to keep up with. For GUI stuff you’re now having to have some sort of Wayland layer/driver. Running VMs is really really easy and low maintenance demand on Apple. And it’s guaranteed compatibility. Wasn’t compatibility what really sunk WSL1?

>for GUI stuff you’re now having to have some sort of Wayland layer/driver.

The target for this isn't GUI stuff.

Re: macOS Container Machines

#283

How is this different from Virtualbox or similar products with a shared folder with the host machine? I expected that existing virtualization tech for Macs already did that. Maybe the improvement is having nothing to configure. By the way, is it headless or can it run a full Linux desktop? Use case: buy a Mac, uninistall whatever can be uninstalled, run the Linux VM as primary desktop forgetting MacOS and without goi…

it differs by lacking all the cool options that makes vmware and virtualbox good products, but apple users will praise it as a benefit "bind mounts? I'm better without it"

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

Re: macOS Container Machines

#284
post #119

Earlier quoted context omitted.

OpenDarwin was a thing at one point, with mailing lists and other infrastructure hosted by Apple. That being said, my point isn't that Apple should absolutely focus on making a server OS again. It just saddens me how far behind macOS has fallen as they stopped caring about the fundamentals; back in the day, it would be Linux trailing behind macOS. Nowadays, you can't even have multiple routing tables on the latter, t…

> Nowadays, you can't even have multiple routing tables on the latter, the firewall code was probably last updated in Snow Leopard Apple uses OpenBSD's Packet Filter [1]; I doubt multiple routing tables are a problem. Back in the Snow Leopard days, it was FreeBSD's IPFW, which is also no slouch. Whatever a firewall can do, PF can do it. You can also get a nice GUI for PF [2]. [1]: https://www.openbsd.org/faq/pf/index…

Yes, I meant pf. Indeed, it was there in the source tree in 10.6 but they only flipped it on it in release builds in 10.7. My bad. Either way, it has hardly changed since then, while the OpenBSD upstream continued to progress.

> I doubt multiple routing tables are a problem.

The lack of them is a limitation for me (complex VM + VPN setup), which requires me to do pretty unholy static routing and address rewriting with pf.

I think even Apple has come across this; they added "scoped routing" (which IMO is a hacky workaround providing some of the functionality you'd get with multiple routing tables) just before iOS shipped with MMS support. Android, for comparison, uses Linux's routing policies and tables to send and receive MMS.

Re: macOS Container Machines

#285

Earlier quoted context omitted.

Understand. And yeah that‘s annoying. I use containers only for development and to keep my main system secure from supply chain attacks. I have almost no build tooling in my Mac anymore. No npm, no cargo, no uv. Nothing. They all live inside the container which is completely isolated. I guess my use case is not that important for the main user of these tools.

I wouldn't say your use case is not important. That is a completely reasonable way to work. I just wouldn't say mounting home directories is an anti-feature. There just should be a way to turn it off.

Well, maybe I should have used relativity unimportant. And yes there should be a way to turn them off. In OrbStack it was not possible to do that until lately.

Re: macOS Container Machines

#287

Earlier quoted context omitted.

Well, you can avoid the Docker Desktop tax by not running Docker Desktop. colima is a perfectly usable implementation of Docker for macOS, without the bloat of Docker Desktop. That said, colima still has the expensive VM that upthread is mentioning.

OrbStack is great also

until they remove the free tier and raise prices, once their user base is sufficiently reliant on it.

Re: macOS Container Machines

#288

Earlier quoted context omitted.

macOS sandboxing is deliberately limited just enough to prevent anyone from truly implement Darwin-on-Darwin containers. People have been discussing about this for a while, see https://github.com/apple/container/discussions/611 In general I understand the rationale behind Apple's decision. They sell hardware, and there's real demand for macOS on servers to run build jobs and other Mac-only tools. Giving you the abili…

I doubt this insignificant statistically speaking market (compared to the overall units they move) is what prevents them.

Domino theory as applied to business, plus one should never underestimate the lengths to which a company will go to wring the last ounce of profit from a market.

Re: macOS Container Machines

#289

Just to clarify, this requires Mac OS 26 Tahoe for "container" doesn't it? So those of us holding out on Sequoia who can't stand the broken glass UI or what's called and the other undesired features need to stick to Docker desktop.

It seems macOS Golden Gate (the upcoming version) fixes quite a few of the problems with Tahoe, so you might consider skipping Tahoe entirely.

Re: macOS Container Machines

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

What kind of virtualization do you use internally? I assume some kind of LXD fork? OrbStack really feels like a single-node Incus host.
Post reply on HN