p3x.demacOS 26 introduces the Containerization Framework: "enables developers to create, download, or run Linux container images directly on Mac"
www.apple.com/newsroom/2025/06/apple-supercharg…
24 Comments
Comments from other communities
Ok. So now both Apple and Microsoft are distributors of the Linux kernel. What a timeline.
Cool. Podman Desktop should be easier after this. Presumably, it’s still a Linux VM driven by something written by Apple instead of qemu.
No macOS containers though. Being able to spin up macOS containers would have been nice for builds and isolating things like pkgsrc.
*Cries in 8GB Macbook*
If containers are part of your work then you wouldn't buy a 8GB RAM unupgradable device anyway.
No, but the company's IT would buy a 16GB Macbook for you that isn't even initially compatible with the images/containers you need to work with. Ask me how I know >.>
You're right. I wouldn't, but someone did for me!
HiddenLayer555If it's a work computer, tell your IT department it's getting in the way of your job.
AatubeWhen all you hire are web devs everything becomes a docker
hobbsc
jagged_circleYou're doing it wrong. I want to run a macOS container on Linux
AnUnusualRelicBut why?
I wonder if they’re going to allow GPU access from inside the VMs.
Apple being Apple, the answer is probably yes. But realistically there's going to be some stupid hurdle in the way and because they make it a PITA nobody's really going to do it.
Which really sucks because the massive GPU and "unified memory" is incredible when they work in conjunction.
Like, you can use the GPU on Linux…with Metal
virtio-gpu with Vulkan pass through for the VM with a Vulkan to Metal translator in host user space. There are various trails about this including at KVM forum: https://kvm-forum.qemu.org/2024/The_many_faces_of_virtio-gpu_F4XtKDi.pdf
Is Apple’s tech going to be using KVM machinery then, or are you just saying that it’s possible in general?
No the Apple hypervisor is called hvf, but projects like rust-vmm and QEMU can control and service guests run on that hypervisor. No KVM required.
Oh that’s cool! I thought virtio and such were KVM-specific things. I have never been super clear on the relationship between QEMU and the hypervisor itself, like where one ends and the other begins.
SuavevillainCan you run amd64 containers?
loweffortnameIt supports Rosetta2, so yes.
Sweet, that will help me, although it takes away my last blocker allowing me to use my Linux box as my primary blocker.
I guess I will have to comain about performance or something.
Pudutr0ñSo I guess now you can run some games.
YerboutiYeah, about that... Heroic game launcher is free and can run a loooooooot of pc games. It now runs pc steam directly.
☆ Yσɠƚԋσʂ ☆
Embrace <-- You are here
Extend
Extinguish
Fuck Apple
MwaDeleted by author
projectmoonmwa@thelemmy.club It is certified to be UNIX, yes. But Linux is not UNIX. Not that it would matter if Linux was certified to be UNIX anyhow. UNIX is a certification that you go through and pay for. The kernel beneath is not necessarily binary compatible with other UNIX operating systems.
PseudoSpockThis isn't a Linux post.
While I read the title I was thinking “that sounds like Linux with extra steps” - maybe that’s good enough for some discussion.
Bobby TurkalinoDeleted by author
Docker to my knowledge still requires a real Linux running somewhere, somehow. In MacOS, it has traditionally been some sort of a VM running under the hood via docker-machine. As this is emulationvirtualization, it has a rather severe overhead.
This containerization framework sounds like it might enable a more light-weight version of Linux, somewhat similar to what Windows has had via WSL for some time.
WSL for Mac?
GolfNovemberUniform
Matt The HorwoodWhy do you need WSL?
MacOS is BSD, so you can do most Linux things with an issue. But some of the BSD tools have different options the the GNU tools.
We moved to Mac years ago and it makes doing almost everything I do a simples
lime!because docker. it hard requires a linux kernel and is extremely slow on mac, just like it was on windows until they integrated with wsl.
I see, I don't use docker all that much on my works Mac. So haven't noticed the speed.
Also is it the storage share that's slow?
As docker desktop is a VM
well docker on mac is a fully emulated x86 vm. everything is slow.
The_DecryptorThat's only if you're running an x86 container right? It should be native with an ARM64 one.
Looking at the docs, I think the current docker desktop is native arm. QEMU is now deprecated
It's not that slow. https://www.imore.com/tests-show-apples-m1-emulates-x86-faster-intel-can-run-it-natively
Edit: actually I just benchmarked it and containerized x86 Linux runs at like 40% of native speed. So yeah, that's pretty freakin slow.
FWIW arm64 containers ran at nearly native speed, so it's the x86 emulation that seems to be causing the slowdown.
yeah last i worked with it i was the first person in the company to evaluate the arm macs, and it basically couldn't run our application at all. took a full 40 minutes to spin up, then crashed.
No. Mac is NOT BSD. Mac took the BSD user space from 20+ years ago. That's all.
I'm not sure why this myth keeps being repeated over and over.
If that's all it takes to "be" BSD, then windows is also BSD since the entire windows network stack was lifted from BSD
it looks like a unix system enough that I can run most of my shell scripts, Windows on the other hand can get in the bin please
That's very cool! But, my work needs to run proprietary x86 containers not ARM ones. We are sadly being "forced" (they rather still not turn to open source software) to move to Windows. It's a shame.
I haven't checked but it should be possible?
macOS has had support for x64 binaries in Linux VMs for a few years now, using their Rosetta 2 translation layer.
I've been using colima for x64 emulation. This blog talks a little bit about it, but basically you start colima in either arm or x64 mode and then can run that type of image - https://blog.barakimam.me/running-vs-code-devcontainers-with-x8664-runtime-on-apple-silicon
ElcaineVoltaI wonder if this opens up any new opportunities for cool Distrobox usecases.
You can already sort of hack distrobox-like functionality, but the biggest problem with doing so is that there's no Wayland or X11 server running on macOS, so GUI applications don't work unless you install something like XQuartz, and even then, it's a pretty janky experience.
I hope I can run ollama in a container with full power, can't install it natively on my work computer
The people complaining that Apple copied a good thing are missing the point. If Apple includes containerization on macOS by default (even if you have to enable it manually), more developers can just target Linux instead of Linux and macOS for certain types of applications (real bash scripts with GNU coreutils instead of the trash that Apple ships, servers, etc.).
macOS 26? I thought the last version was 15...
Looks like they're jumping from 15 to 26, in fact they're doing the same thing for iOS, jumping from 18 to 26 for the next release. Looks like they're synchronizing all their OS version numbers using the year they'll be primarily used(i.e. 2026) from what I can find.
I'm not an apple person, so even I saw news about iOS I thought "how the fuck are they on 26 already?"
I didn't really care, but I appreciate the explanation.
Tbh I'm not an apple person either. The comment about macOS being on 26 caught my eye and I went and did some research.
This is my preferred versioning format for user-facing software, by far.
I feel like Semver should also adopt the date inclusion, like 7.4.2-202606 or even 7.4.202606 — you can even extended it to multiple daily releases like 7.4.20260610.1233
There's too much software to mentally track when each version was released. You should be able to tell at a glance.
They're basically copying Samsung (and the auto industry) and switching to using the year of the release instead of iterative naming schemes.
I love how all the major operating systems are adding ways to run Linux. Even Android which arguably IS Linux.
I do find it funny how android is Linux yet their Linux feature is a VM
Because google doesn't want you doing anything
that they can't controlfun on the host Android system. They did the same thing with crostini on ChromeOS for "security".People say this but I'm not sure I believe that. Keep in mind Google is the only android OEM that allows you to do a bootloader unlock and root without an exploit, it's officially supported as a developer configuration.
We need to develop darling too
Darling is a cool project but I think the reason it hasn't taken off is because there isn't a lot of software people both want to use on Linux and software that isn't already covered by wine. You need an overlap between those 2 and that's a small market
Yeah, I just think that maybe, just maybe, if MacOS is also inspired by UNIX, making a compat layer is not that big of a difference. Because MacOS supports a lot of productivity programs that may attract professionals to Linux too. Mostly adobe suite.
The problem with that thought is the lower level bits are very *nix but all the higher level bits like the GUI and other surrounding APIs are all heavily Objective-C/NextStep based and aren't really all that unixy. We do have GNUStep as a base to use for that to an extent but I really don't think the unix parts of Mac, are that helpful to porting complex user facing GUI programs.
Wine is successful because of the decades of work put into it. For Darling to reach that level of support it would need a herculean amount of effort as well.
pretty scant on details. what is this doing for me that Podman or Containerd aren’t? “oPtIMizeD fOR aPPlE SiLICon” is fluff
I was wondering the same
Well it helps that its open source & apple is actually encouraging contributions: https://github.com/apple/container
A big improvement over the stupid shit Docker Desktop did (running a bigass ugly VM for all containers). I'll still stick with my Linux laptop ;)
I believe Podman uses a Fedora CoreOS VM. How does that compare?
I'm not sure. To me, the most interesting thing is that each container gets its own VM. I don't know if podman does that or not. I'd guess not, since CoreOS isn't the lightest OS around (I've used CoreOS and Flatcar extensively at my job and it's a lil chunky as far as immutable container host OSes go).
What would be the use case for each container getting its own VM?
Each VM can be sized appropriately for the demands of the container. With docker desktop, you can't have a container use all of your system cores without making the VM have access to all of your cores all the time always. One of the biggest benefits (imo) of running containers on a Linux workstation is that if you don't define a CPI limit, a container can use all the compute/memory on your system. You just can't do that with Docker desktop. This also affects multi threaded container builds when you're using buildkit.
Being able to spin up a vm to build a container with all cores accessible to it, and then run the actual container with a smaller number of cores would make container builds so much faster.
EDIT: I've looked, and it appears that podman desktop also does 1 big VM, rather than having 1 VM per container.