HI version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
84% Positive
Analyzed from 2783 words in the discussion.
Trending Topics
#macos#apple#container#linux#run#orbstack#containers#docker#memory#https

Discussion (147 Comments)Read Original on HackerNews
Which kernel is running, and is it hosted in hypervisor.framework, as is done with UTM (when not using the qemu mode)?
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.
I gave Container Machines a try and it seems to be much closer to OCI containers with a default bind mount than OrbStack machines. It has fewer integrations and doesn't run systemd or any other normal init system, so it's hard to run services.
> I gave Container Machines a try and it seems to be much closer to OCI containers with a default bind mount than OrbStack machines. It has fewer integrations and doesn't run systemd or any other normal init system, so it's hard to run services.
The linked md document says:
> Real Linux services for testing. Run a database or whatever your stack needs as a system service — systemctl start postgresql works on images with systemd installed.
Was that not the case when you used container machines?
If the guest image has /sbin/init, we use that.
We'd recommend using a base image for the guest that includes systemd. ie: https://github.com/apple/container/blob/main/docs/container-...
Wow, missed this when reviewing OrbStack. I assumed that you just used Containerization and therefore would have the same limitation.
"Real Linux services for testing. Run a database or whatever your stack needs as a system service — systemctl start postgresql works on images with systemd installed."
I wanted to make its VM/machine our default secure agent sandbox, but I couldn’t figure out how to isolate this VM from the host properly. This thread prompted me to find the issue though, and I saw this was recently implemented! https://github.com/orbstack/orbstack/issues/169
AFAICT it's pretty similar.
The Containerization framework is a library that sits as a layer on top of the virtualization framework. So each container is its own VM.
Machine is tooling above the containerization framework to run multiple things in a container in a vm.
Which for many folks is good enough for what they are doing, thus the status quo of desktop platforms will hardly change for current form factors.
Edit: It's a VM per container. https://github.com/apple/container/blob/main/docs/technical-...
BSD actually has this already.
There's also simply the possibility of using linux software directly in macos without doing OS dependent changes to the software.
Running VMs is really really easy and low maintenance demand on Apple. And it’s guaranteed compatibility.
Wasn’t compatibility what really sunk WSL1?
That said, colima still has the expensive VM that upthread is mentioning.
I did an experiment migrating my Podman workload to Apple's container @ https://gist.github.com/jmonster/39e14585e107dbf990a90966c0f...
TL;DR reduces ram/storage usage; minimizes it's existence
> Memory defaults to half of host memory
That's the most expensive part of the whole transaction, b/c AFAIK, RAM is then dedicated to the VM. It can be swapped out, I suppose, but that's not great.
The pain of working around Docker Desktop is bad.
I am trying it on but its brekaing on homebrew 1.0.0. The formula puts plugins at opt/container/libexec/container-plugins/ and the apiserver looks in libexec/container/plugins/
This can be solved through a symlink or smth
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
I have made it a MCP so that it's easily discoverable by all the coding agents
https://github.com/instavm/coderunner
https://github.com/devcontainers/ https://containers.dev/
Why would any serious developer use closed-source code they can't debug and modify? Especially for a production server?
It's the same reason no serious developers or hackers use macOS, like part of the point of being a developer is being able to dig into the code at any layer and debug and fix things.
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, the firewall code was probably last updated in Snow Leopard, and what Apple happily shows off on WWDC is a wrapper around Linux. Something functionally equal can be cobbled up together by anyone sufficiently experienced in minutes, using just Bash, OpenSSH, and QEMU.
I really wish macOS would let me have a similar level of control over applications as Linux with namespaces, without me having to do all the heavy lifting.
Even Microsoft gave up on Windows and just runs Linux most things except niche cases. Heck, even SQL Server which is expensive piece of machinery got ported to Linux and that's the default target now in their docs.
With that said, one can't deny Apple's success on the b2c side of things so it feels wrong to call their strategy a failure.
If they were to support darwin containers, what would be the point? Literally nobody would build to it, Linux won.
because nobody does ci/cd against macOS or iOS apps right?
There aren’t any app developers avoiding the Apple ecosystem because there aren’t Darwin containers. They don’t sell server hardware and by all accounts have no intention of ever reentering that space. So they’d spend a bunch of developer cycles to reduce their own revenue stream with no apparent upside beyond “goodwill” which they’ve never been overly concerned about.
Discover container machines
https://developer.apple.com/videos/play/wwdc2026/389/
Blog post soon
* need a usb sdcard reader for macbook pro cause the builtin is not usb)
Basically: they’ve moved on.
Apple has never been about supporting legacy platforms with new features. And with over a quarter of revenue and two fifths of Apple's gross profits coming from services, one could argue the incentives run either way.
Enterprise ARM servers are still a niche product, and so are the ARM developer machines running Linux or Windows. Until this significantly changes, Apple will have to provide good x86 interop - or lose the developer market entirely.
Forcing people towards Apple silicon is of course an attractive approach when targeting the large portion of the market using their MacBooks as Facebook browsing machines, but (especially with the new MacBook Neo) what's going to happen when a large portion of the market for high-end MBPs disappears because it turned from the default no-brainer into a liability?
It’s the only legal way to do so, due to the software license on MacOS.
you can now run linux containers on your mac
... but it could be better.
what about (totally contrived):
I'm saying the older version of macos could build/run INSIDE the container
just like on a ubuntu 24.04 system you can do:
or and though I haven't tried it, I believe docker can do arm in x86 using an emulator (like rosetta)So it seems like in theory that should be doable if someone just made the container images right?
This is a step in the right direction but requires any given developer’s buy-in first, right?