macOS Container Machines(github.com) |
macOS Container Machines(github.com) |
you can now run linux containers on your mac
... but it could be better.
what about (totally contrived):
FROM apple/macos:10.11.6
RUN xcodebuild -project myapp.xcodeproj -scheme MyScheme -configuration Release services:
macos:
image: dockurr/macos
container_name: macos
environment:
VERSION: "15"
ENV XCODE_FRONTEND=unattended
ENV XCODE_LICENSES=accept,firstborn,applepay,appleid=sjobs@me.comI'm saying the older version of macos could build/run INSIDE the container
just like on a ubuntu 24.04 system you can do:
FROM ubuntu:16.04
docker run ubuntu:16.04
This is a step in the right direction but requires any given developer’s buy-in first, right?
So it seems like in theory that should be doable if someone just made the container images right?
Which kernel is running, and is it hosted in hypervisor.framework, as is done with UTM (when not using the qemu mode)?
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.
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.
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.
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
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.
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?
Discover container machines
Blog post soon
* need a usb sdcard reader for macbook pro cause the builtin is not usb)
Basically: they’ve moved on.
It’s the only legal way to do so, due to the software license on MacOS.
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.
Running VMs is really really easy and low maintenance demand on Apple. And it’s guaranteed compatibility.
Wasn’t compatibility what really sunk WSL1?
Yes, but a big part of the problem with WSL1 was the size of the conceptual gap between POSIX and Windows NT that WSL1 had to bridge. An “MSL1” would likely have fewer problems because the gap between macOS and Linux is smaller, given they are both POSIX
The other thing Apple could potentially do, is add Linux-compatible APIs to macOS. IBM wanted to support Kubernetes on their z/OS mainframe operating system, so they implemented on it a clone of Linux namespace APIs, e.g. unshare. Then we could have macOS nodes in a K8S cluster-which might actually be useful for some people, e.g. if you have a Jenkins CI farm, the Linux nodes can run on K8S, but currently macOS nodes (which you need if you are targeting iOS or macOS) can’t, they have to be bare metal or VMs.
More Linux-macOS source compatibility would also benefit macOS by making it less work to port software to it from Linux
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?
I'm very, very skeptical of this analysis. Certainly "entirely" is hyperbole.
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.
If they're investing resources into it regardless, they might at least try making something that Docker for macOS and co. haven't solved the same exact way already. Something that, due to their almost unhealthy obsession with "system integrity", only they can realistically make. Like native containers.
Which is a ton of ‘em.
I never want to deal with that again ;)
[edit] fwiw, Termux on Android is similarly a fun pseudo-environment. It's a nice and helpful toy.
That's handy when you're entering paths in a Cygwin/MSYS Bash shell, but might not help much if you're trying to parse or otherwise work with existing patgh variables composed with backslashes.