This is the most surprising and interesting part, imo:
> Contributions to `container` are welcomed and encouraged. Please see our main contributing guide for more information.
This is quite unusual for Apple, isn't it? WebKit was basically a hostile fork of KHTML, Darwin has been basically been something they throw parts of over the wall every now and then, etc.
I hope this and other projects Apple has recently put up on GitHub see fruitful collaboration from user-developers.
I'm a F/OSS guy at heart who has reluctantly become a daily Mac user due to corporate constraints that preclude Linux. Over the past couple of years, Apple Silicon has convinced me to use an Apple computer as my main laptop at home (nowadays more comparable, Linux-friendly alternatives seem closer now than when I got my personal MacBook, and I'm still excited for them). This kind of thing seems like a positive change that lets me feel less conflicted.
Anyway, success here could perhaps be part of a virtuous cycle of increasing community collaboration in the way Apple engages with open-source. I imagine a lot of developers, like me, would both personally benefit from this and respect Apple for it.
zapzupnz · 1h ago
It's not that surprising. Much of Swift and its frameworks are contributed by the open source community.
pxc · 1h ago
That's true, but I always thought of Swift as exceptional in this because Swift is a programming language, and this has become the norm for programming languages in my lifetime.
If my biases are already outdated, I'm happy to learn that. Either way, my hopes are the same. :)
samtheprogram · 35m ago
Jai has been one exception I can think of here. It hasn’t been publicly released yet, either (you can email/request pre-release access, though)
overfeed · 1h ago
> I'm a F/OSS guy at heart who has reluctantly become a daily Mac user due to corporate constraints that preclude Linux
I suspect this move was designed to stop losing people like you to WSL.
mikepurvis · 10m ago
I'm in that camp— I was an Intel Mac user for a decade across three different laptops, and switched to WSL about six years ago. Haven't strongly considered returning.
guztaver · 40m ago
As a long-time Linux user, I can confidently say that the experience of using a M1 Pro is significantly superior to WSL on Windows!
I can happily use my Mac as my primary machine without much hassle, just like I would often do with WSL.
nhumrich · 1h ago
Since this is touching Linux, and Linux is copy left, they _have_ to do this.
mirashii · 59m ago
In addition to the other comments about the fact that this wasn't forced to adopt the GPL, even if it were, there's nothing in the license that forces you to work with the community to take contributions from the public. You can have an entirely closed development process, take no feedback, accept no patches, and release no source code until specifically asked to do so.
They don't have to do literally any of this.
pxc · 56m ago
Right! The exciting thing is the approach, not the license.
pxc · 1h ago
If the license of this project were determined by obligations to the Linux kernel, it would be GPLv2, not Apache License 2.0!
n2d4 · 1h ago
Touching Linux would not be enough. It would have to be a derivative work, which this is (probably?) not.
Besides, I think OP wasn't talking about licenses; Apple has a lot of software under FOSS licenses. But usually, with their open-source projects, they reject most incoming contributions and don't really foster a community for them.
TimTheTinker · 9m ago
> derivative work
Or distributing builds of something that statically links to it. (Which some would argue creates a derivative work.)
Aurornis · 31m ago
The comment was about them welcoming contributions, not making it open source.
The former is the framework enabling Linux containers on lightweight VMs and the latter is a tool using that framework.
zmmmmm · 55m ago
interesting choice - doesn't that then mean that container to container integration is going to be harder and a lot of overhead per-container? I would have thought a shared VM made more sense. I wonder what attracted them to this.
paxys · 2h ago
Also works on macOS 15, but they mentioned that some networking features will be limited.
SamuelAdams · 16m ago
I wonder if this will dramatically improve gaming on a Mac? Valve has been making games more reliable due to Steam Deck, and gaming on Linux is getting better every year.
Could games be run inside a virtual Linux environment, rather than Apple’s Metal or similar tool?
This would also help game developers - now they only need to build for Windows, Linux, and consoles.
sangeeth96 · 3h ago
The CLI from the press release/WWDC session is at https://github.com/apple/container which I think is what many like myself would be interested in. I was hoping this'd be shipped with the newest Xcode Beta but that doesn't seem to be the case. Prebuilt packages are missing at the moment but they are working on it: https://github.com/apple/container/issues/54
Wonder how Docker feels about this. I'd assume a decent amount of Docker for Desktop is on Mac...
paxys · 4h ago
Well it makes developing Docker Desktop infinitely easier for them, since they no longer need to start their own Linux VM under the hood. I think the software is "sticky" enough that people will still prefer to use Docker Desktop for the familiar CLI and UX, Docker Compose, and all the Docker-specific quirks that make migrating to a different container runtime basically impossible.
pxc · 2h ago
Docker Desktop on Windows uses WSL to provide the Docker daemon, doesn't it? So Docker Desktop has a history of leaning into OS offerings for virtualizing Linux like this where they can.
prmoustache · 3h ago
I never used docker desktop and am struggling to understand what you are supposed to be doing with a gui in a docker/container context.
stackskipton · 3h ago
GUI lets you look at logs quickly, there is buttons to click quickly open http://localhost:<port>, stop and start containers, get shell in container and bunch of other stuff that people developing or testing against containers need locally.
prmoustache · 3h ago
I am surprised a developer would not have chosen to redirect the port at run time already and would not be running the containers in the foreground in the first place.
stackskipton · 2h ago
So many developers don't learn docker. I'm Ops type person, outside FAANG, most devs are just flinging code at screen to close JIRA tickets, get the build to go green and collect a paycheck to go home. Docker, that's for us Ops people who have build that rickety pipeline that somehow manages to get your code into a container and into the Kubernetes cluster.
phinnaeus · 3h ago
Dropbox copypasta goes here
Spivak · 3h ago
I mean maybe but if you run your containers not via a GUI you get most of that for free or at worst with a docker logs or docker exec command.
Do people learn docker not via the CLI?
DanHulton · 11m ago
I did. Well, I did until I found lazydocker, a TUI that handles the majority of the day-to-day stuff that I need to do that isn't already written into tasks in my justfile: https://github.com/jesseduffield/lazydocker
lenerdenator · 41m ago
They do, then they realize that it's not the core component of their jobs (unless they're ops) and it is easier to press a "stop" button to kill containers, at least in their use case.
queenkjuul · 2h ago
I for one have been using docker on Linux for years and have to use a Mac at work, and I'm totally baffled by the fact i need to install docker desktop to use the CLI and don't get why you'd need or want the GUI.
And like I'm not all anti-GUI, it's just that docker is one of those things I've never even imagined using a GUI for
selcuka · 2h ago
I mean, it's nice to have a GUI when running multiple containers on Docker, or Kubernetes, but I've never used Docker Desktop on my work Mac either.
For Kubernetes, something like K9s [1] or Headlamp [2] works fine. I remember seeing something similar for Docker but I can't remember the name.
For me, Docker Desktop is simply an easy way to launch the Docker daemon and inspect some created images and their corresponding logs. Other than that, the cli suffices.
hiccuphippo · 3h ago
We had to remove Docker Desktop at my job (I think they started asking for money?) and moved to Lima/Colima.
If this project means one less program to configure to get my docker containers running then I'm all for it.
queenkjuul · 2h ago
Docker desktop for commercial use requires a license and they don't release binaries for Mac other than desktop. Seems like their one route to monetization. I use docker for literally only one build that doesn't work on native macOS so i love the idea of switching to a simple standalone CLI
pxc · 1h ago
Imo, the GUI isn't really the most important part of things like Docker Desktop.
The nice part is that they (a) set up the Linux VM that runs the Docker daemon for you and (b) handle the socket forwarding magic that lets you communicate with it "directly" by running the Docker client on the host OS. This is likewise true for Podman Desktop, Rancher Desktop, etc.
The GUI is icing on the cake, imo.
bdcravens · 2h ago
Very few use the GUI for things other than configuring Docker engine settings like memory, etc.
n2d4 · 1h ago
This doesn't compete with Docker for Desktop, as more low-level than that.
Docker for Desktop sits on-top of container/virtualization software (Hypervisor.framework and QEMU on Mac, WSL on Windows, containerd on Linux). So there's a good chance that future versions of Docker for Desktop will use this library, but they don't really compete with each other.
cogman10 · 4h ago
Probably about the same way they feel about podman.
baby_souffle · 2h ago
I guess it'll depend on whether or not this starts shipping by default with newacOS installs.
If it doesn't, then it's still a toss-up whether or not user chooses docker/podman/this...etc.
If it ends up shipping by default and is largely compatible with the same command line flags and socket API... Then docker has a problem.
For what it's worth, I prefer podman but even on Linux where the differentiators should be close to zero, I still find certain things that only docker does.
Kwpolska · 3h ago
Podman is fairly niche. This is an Apple product that Apple developer circles will push hard.
hocuspocus · 2h ago
Alternatives to Docker Desktop aren't niche at all since Docker started charging money.
My org's management wasn't taking the issue seriously, but once the subscription cost reached one FTE's salary, they started listening to people who had already switched to Podman, Rancher or (Co)Lima.
m463 · 2h ago
and telemetry on macos
cogman10 · 3h ago
I agree, Apple has a lot of weight. Podman, however, also has a fair bit of heft behind it (IBM via Redhat).
I'll not deny that it's a bit niche, but not so much so that it's completely unknown.
xp84 · 2h ago
I apologize if this sounds like a hot take, but "Apple developer circles," as in, people who use XCode at all and care about any part of Apple's toolchain[0], is a very small number of people compared to "All developers who happen to code on Macs." In my experience at least, the typical developer who uses macOS codes in VSCode on JS, Python, etc., groans when some file association accidentally launches XCode, and would likely prefer to use normal Docker like the do on their Linux servers, rather than proprietary Darwin weirdness.
"Apple developer circles" to me means the few mostly indies who build non-electron Mac apps and non-ReactNative ios apps, but those developers mostly are writing client code and don't even touch servers.
All this said, my above "gut feelings" don't explain why Apple would have bothered spending their time making this when Orbstack, Docker, etc. already meet the needs of the developers on Mac who actually need and use containers.
[0]: besides the "Command line tools" that allow compilation to work, of course.
blinded · 54m ago
Also the second they started charging podman dev picked up and that has gotten real good.
sneak · 4h ago
Docker Desktop is closed source proprietary software and this is free software, so this is a win (for us, at least).
sho_hn · 2h ago
So both of the other big two desktop OSs now have official mechanisms to run Linux VMs to host Linux-native applications.
You can make some kind of argument from this that Linux has won; certainly the Linux syscall API is now perhaps the most ubiquitous application API.
sangeeth96 · 2h ago
> Linux has won
Needing two of the most famous non-Linux operating systems for the layman to sanely develop programs for Linux systems is not particularly a victory if you look at it from that perspective. Just highlights the piss-poor state of Linux desktop even after all these years. For the average person, it's still terrible on every front and something I still have a hard time recommending when things so often go belly up.
Before you jump on me, every year, I install the latest Fedora/Ubuntu (supposedly the noob-friendly recommendations) on a relatively modern PC/Laptop and not once have I stopped and thought "huh, this is actually pretty usable and stable".
bigstrat2003 · 38m ago
> not once have I stopped and thought "huh, this is actually pretty usable and stable".
I think we need to have a specific audience in mind when saying whether or not it's stable. My Arch desktop (user: me) is actually really stable, despite the reputation. I have something that goes sideways maybe once a year or so, and it's a fairly easy fix for me when that does happen. But despite that, I would never give my non-techy parents an Arch desktop. Different users can have different ideas of stable.
sho_hn · 1h ago
I'd say that's a fairly web development-centric take. I work at an embedded shop that happily puts a few million cars running Linux on the road every year, and we have hundreds of devs mainly running Linux to develop for Linux.
sangeeth96 · 1h ago
The average person is not dishing out software that runs on millions of cars from the average PC/laptop they got off the shelves from their bestbuy equivalent. I’d say the same for the average developer. I’d also guess if given a choice and unless there are technical limitations that prevent it from being so, even the devs in your shop would rather prefer to switch to a usable daily driver OS to get things done.
The desktop marketshare stats back me up on the earlier point and last I checked, no distro got anywhere close?
Sure, Android is the exception (if we agree to consider) but until we get serious dev going there and until Android morphs into a full-fledged desktop OS, my point stands.
etra0 · 22m ago
well, don't forget there's a fully fledged console now too, which by the way, runs games made for windows on linux, with better performance.
And yes, that's bought by the 'average person'.
sfpotter · 40m ago
Terrible on every front? I'm sorry, but it's hard to take this seriously. I've been daily driving Fedora with Cinnamon for the past 4 years and it works just fine. I use Mac and Windows on a regular basis and both are chock full of AI bloatware and random BS. On the same hardware, Linux absolutely runs circles around Windows 10 and Windows 11. If the application you need to use doesn't run on Linux; well, OK... not much you can do about that. But to promote that grievance to "terrible on every front" is ridiculous.
aljgz · 2h ago
Well. It can also be argued that the other two platforms are finding ways to allow using Linux without leaving those platforms, which slows down market share of Linux on desktop as the primary OS.
selcuka · 2h ago
> which slows down market share of Linux on desktop as the primary OS
I think what slows down market share of Linux on desktop is Linux on desktop itself.
I use Linux, and I understand that it's a very hard job to take it to the level of Windows or macOS, but it is what it is.
duped · 2h ago
Except for graphics, audio, and GUIs for which no good solutions exist
paxys · 2h ago
Is it winning if you are the only one playing the game?
Brag about this to an average Windows or Mac user and they will go "huh?" and "what is Linux?"
sho_hn · 1h ago
> Is it winning if you are the only one playing the game?
Depending on what you mean with "the game", I'd say even more so.
MS/Apple used to villify or ridicule Linux, now they need to distribute it to make their own product whole, because it turns out having an Open Source general purpose OS is so convenient and useful it's been utilized in lots of interesting ways - containers, for example - that the proprietary OS implementations simply weren't available for. I'd say it's a remarkable development.
yjftsjthsd-h · 1h ago
By that logic, this feature and WSL shouldn't exist.
OJFord · 2h ago
'Linux with macOS.'
roberttod · 3h ago
I need to look into this a little more, but can anyone tell me if this could be used to bundle a Linux container into a MacOS app? I can think of a couple of places that might be useful, for example giving a GPT access to a Linux environment without it having access to run root CLI commands.
paxys · 2h ago
Yes, as long as you are okay with your app only working on macOS 26. Otherwise you can already achieve what you want using Virtualization.framework directly, though it'll be a little more work.
OJFord · 2h ago
Yes, that's exactly what it's for.
sitole · 1h ago
Has anyone tried turning on nested virt yet? Since the new container CLI spins each container in its own lightweight Linux VM via Virtualization.framework, I’m wondering whether the framework will pass the virtualization extensions through so we can modprobe kvm inside the guest.
Apple’s docs say nested virtualization is only available on M3-class Macs and newer (VZGenericPlatformConfiguration.isNestedVirtualizationSupported)
developer.apple.com, but I don’t see an obvious flag in the container tooling to enable it. Would love to hear if anyone’s managed to get KVM (or even qemu-kvm) running inside one of these VMs.
paxys · 2h ago
Thinking more about this a bit, one immediate issue I see with adoption is that the idea of launching each container in its own VM to fully isolate it and give it its own IP, while neat, doesn't really translate to Linux or Windows. This means if you have a team of developers and a single one of them doesn't have a mac, your local dev model is already broken. So I can't see a way to easily replace Docker/Compose with this.
dontdoxxme · 38m ago
It translates exactly to Kubernetes though, except without the concept of pods, I don't see anything in this that would stop them adding pods on top later, which would allow Kubernetes or compose like setups (multiple containers in the same pod).
outcoldman · 4h ago
Not sure what exactly is happening, but feels very slow. Builds are taking way longer. Tried to run builder with -c and -m to add more CPU and memory.
tibbar · 4h ago
What setup are you comparing this to? In the past silicon Macs plus, say, Rancher Desktop have been happy to pretend to build an x86 image for me, but those images have generally not actually worked for me on actual x86 hardware.
outcoldman · 3h ago
Comparing to Docker for Mac. Running on MBA M2. Building a 5GB image (packaging enterprise software).
Docker for Mac builds it in 4 minutes.
container tool... 17 minutes. Maybe even more. And I did set the cpu and memory for the builder as well to higher number than defaults (similar what Docker for Mac is set for). And in reality it is not the build stage, but "=> exporting to oci image format" that takes forever.
Running containers - have not seen any issues yet.
solomatov · 3h ago
Does anyone know whether they have optimized memory management, i.e. virt machine not consuming more RAM than required?
filleokus · 3h ago
Looks cool! In the short demo [0] they mention "within a few hundred milliseconds" as VM boot time (I assume?). I wonder how much tweaking they had to do, because this is using the Virtualization.framework, which has been around a while and used by Docker dekstop / Colima / UTM (as an option).
I wonder what the memory overhead is, especially if running multiple containers - as that would spin up multiple VM's.
> Containers achieve sub-second start times using an optimized Linux kernel configuration[0] and a minimal root filesystem with a lightweight init system.
This does not support memory ballooning yet. But they have documented custom kernel support, so, goodbye OrbStack.
worldsavior · 4h ago
Orbstack is docker. People might still prefer docker.
newman314 · 4h ago
I wonder how this will affect apps like Orbstack
9dev · 4h ago
Huh. I suppose it’s a good thing I never came around to migrating our team from docker desktop to Orbstack, even though it seems like they pioneered a lot of the Apple implementation perks…
xp84 · 2h ago
I still haven't heard why anyone would prefer the new Apple-proprietary thing vs Orbstack. I would not hold my breath on it being better.
zshrc · 2h ago
Wild because "Apple proprietary" is on GitHub and Orbstack is closed source but go off I guess.
xp84 · 2h ago
You got me. It was super inaccurate to use "proprietary" here (though if i understand correctly, podman is another option that is FOSS).
License aside, though, I would still bet that relying on the Apple-specific version of something like this will cause headaches for teams unless you're operating in an environment that's all-in on Apple. Like, your CI tooling in the cloud runs on a Mac, that degree of vendor loyalty. I've never seen any shop like that.
Plus when this tooling does have interoperability bugs, I do not trust Apple to prioritize or even notice the needs of people like me, and they're the ones in charge of the releases.
jpgvm · 2h ago
It's the other way around, the Apple code is FOSS, Apache 2 to be specific.
Presumably it's not as good right now but where it ends up depends entirely on Apple's motivation. When they are determined they can build very good things.
st3fan · 2h ago
Here here .. i prefer these new built-in tools. Who cares it is proprietary open source. It works with standard OCI containers. Goodbye Docker.app
SparkyMcUnicorn · 4h ago
My guess is that Orbstack might switch to using this, and it'll just be a more competitive space with better open source options popping up.
People still want the nice UI/UX, and this is just a Swift package.
jbverschoor · 3h ago
Orbstack also does kubernetes etc
bdcravens · 2h ago
They could replace their underlying implementations with this, and for most users, they wouldn't notice the difference, other than any performance gains.
jbverschoor · 3h ago
In my opinion this is a step towards the Apple cloud hosting.
They have Xcode cloud.
The $4B contract with Amazon ends, and it’s highly profitable.
Build a container, deploy on Apple, perhaps with access to their CPU’s
paxys · 3h ago
It's quite a stretch to go from Apple launching container support for macOS to "they are going to compete with AWS". Especially considering Apple's own server workloads and data storage are mostly on GCP.
n2d4 · 1h ago
It's still virtualization, so it'll necessarily be (slightly) slower than just running Linux natively. I don't think Apple's hardware makes up for that, certainly not at the price point at which they sell it.
joshdavham · 3h ago
Will this likely have any implications for tools like ‘act’ for running local GitHub actions? I’ve had some trouble running act on apple silicon in the past.
OJFord · 2h ago
In theory could make it more seamless, so installation instructions didn't include 'you must have a functioning docker engine' etc. - but in practice I assume it's a platform-agnostic non-Swift tool that isn't interested in a macOS-specific framework to make it smoother on just one platform.
sampton · 3h ago
Apple please expose GPU cores to the VMs.
lisperforlife · 34m ago
You can use libkrun to pretty much do the same thing.
emmelaich · 2h ago
I've used pytorch successfully in a MacOS VM on MacOS using https://tart.run/ so I'd expect it to work here too.
m463 · 2h ago
I think this is purely a checkbox feature to compare against wsl. Otherwise apple just wouldn't get involved (not engineers, who would do lots of good things, but management that let this out)
m3kw9 · 1h ago
I’m already running docker on macOS what’s the difference?
sneak · 4h ago
Surprising to me that this uses swift CLI tools (free software) and make, not Xcode.
detourdog · 4h ago
Xcode also has command line tools that can do the same.
sneak · 3h ago
Obtaining and using Xcode requires submitting to an additional license contract from Apple. Swift and Make do not.
detourdog · 3h ago
Are you sure about that? I mean accepting license aggreements is pretty standard and doesn't bother me.
This guide seems to have no specific license agreement.
Containers are mainly for CI+testing and for Linux workflows, so xcodebuild is not really an option.
IshKebab · 4h ago
Getting worried about WSL I see!
SkepticalWhale · 3h ago
Whenever I have to develop on Windows, I clone my repos and run neovim / docker inside of WSL, for the improved performance (versus copying / mounting files from windows host) and linux. The dev experience is actually pretty good once you get there.
I'm not sure this is the same, though. This feels more like docker for desktop running on a lightweight vm like Colima. Am I wrong?
metaltyphoon · 59m ago
This is my same workflow even for C#
jamie0 · 4h ago
disappointing theres still no namespacing in darwin for macos containers. would be great to run xcodebuild in a container
rvz · 4h ago
Requires an Apple Silicon Mac to run.
> You need an Apple silicon Mac to build and run Containerization.
> To build the Containerization package, your system needs either:
> macOS 15 or newer and Xcode 26 Beta
> macOS 26 Beta 1 or newer
Those on Intel Macs, this is your last chance to switch to Apple Silicon, (Sequoia was the second last)[0] as macOS Tahoe is the last version to support Intel Macs.
Also, there are some really amazing deals on used/refurb M2 Macs out there. ~$700 for a Macbook Air is a pretty great value, if you can live with 16GB of RAM and a okay but not amazing screen.
paxys · 3h ago
$450 for a M4 Mac mini (at Microcenter, but Best Buy will price match) is possibly the best computer hardware deal out there. It is an incredible machine.
xp84 · 2h ago
Having run a Mac Mini with a 256GB internal drive for 2-3 years I will dispute that anyone should buy base models for that reason. MacOS makes it as painful as possible for you to use external drives. For instance, no software for "cloud" drives (google drive, onedrive, icloud drive) is allowed to locate its local copy on an "External" drive, so you can't keep your files locally and in the cloud, have to pick one. Photos can have its library moved at least.
I like the hardware, hate the absurd greedy storage and RAM prices.
paxys · 2h ago
AI FOMO at least made them bump the base RAM to 16GB. 256GB is pitiful but manageable if you don't need to handle large files. And jumping up to $800 just for another 256GB is absolutely not worth it.
xp84 · 2h ago
I agree on your second point, which is why unless Apple ever moves away from only having 2010-era storage amounts and absurd prices to size up, from now on I'll be buying used only. Just picked up an M3 MacBook Air with 16GB and 1TB SSD, mint condition, for under a grand.
xp84 · 2h ago
Indeed. I just grabbed a mint M3 MBA on ebay for about $950 with a 1TB ssd (which tbh was my main need to upgrade this family member in the first place, as they weren't CPU-bound on the old M1). Wild deals to be had!
socalgal2 · 4h ago
a 30% discount for a 3 yr old machine is good? A new one is $999.
DrBenCarson · 4h ago
When the 3yo machine does 100% of what you need without missing a beat and has 8h screen-on battery life, yes, yes, it is
nicoburns · 4h ago
Even better deals on M1s which aren't much slower than M2s
keysdev · 4h ago
Any linux or bsd that has goodhardwawe support for intel mac?
bjackman · 4h ago
For the older ones with Broadcom WiFi I was able to get stock Ubuntu working great by following this:
Gathering this information and putting together a distro to rescue old Macbooks from the e-waste bin would be a worthwhile project. As far as I can tell they're great hardware.
I imagine things get harder once you get into the USB-C era.
monkey_monkey · 4h ago
This site is very useful for getting Linux on more recent Intel Macs - I was able to get Ubuntu running on a 2018 MBA
Wouldn't be surprised if this goes through the same process Windows users did with WSL. Starting out with no systemd, to community-developed systemd-in-a-bottle setups, to proper systemd integration
TacticalCoder · 4h ago
> I'm excited to run Systemd on mac!
OCI containers are supposed to be "one container, one PID": at the very least the container's server is PID1 (at times other processes may be spawned but typically the container's main process is going to be PID1).
Containerization is literally the antithesis of systemd.
So I don't understand your comment.
No comments yet
bdcravens · 2h ago
Cool, but until someone (Apple or otherwise) implements Docker Compose on top of this, it's unlikely to see much use.
9d · 3h ago
At what point will this Russian doll set of virtualization reach an end?
Let's run linux inside a container inside docker inside macos inside an ec2 macos instance inside a aws internal linux host inside a windows pc inside the dreaming mind of a child.
> Let's run linux inside a container inside docker inside macos inside an ec2 macos instance inside a aws internal linux host inside a windows pc inside the dreaming mind of a child.
Not even the first non-hyperbolic part of what you wrote is correct. "Container" most often refers to OS-level virtualization on Linux hosts using a combination of cgroups, resource groups, SDN, and some mount magic (among other things). MacOS is BSD-based and therefore doesn't support the first two things in that list. Apple can either write a compatibility shim that emulates this functionality or virtualize the Linux kernel to support it. They chose the latter. There is no Docker involved.
This is a completely sane and smart thing for them to do. Given the choice I'd still much rather run Linux but this brings macOS a step closer to parity with such.
9d · 2h ago
To be honest, I don't know what Docker or any of these things are. I just wanted to sound smart so I could fit in and people would like me.
> Contributions to `container` are welcomed and encouraged. Please see our main contributing guide for more information.
This is quite unusual for Apple, isn't it? WebKit was basically a hostile fork of KHTML, Darwin has been basically been something they throw parts of over the wall every now and then, etc.
I hope this and other projects Apple has recently put up on GitHub see fruitful collaboration from user-developers.
I'm a F/OSS guy at heart who has reluctantly become a daily Mac user due to corporate constraints that preclude Linux. Over the past couple of years, Apple Silicon has convinced me to use an Apple computer as my main laptop at home (nowadays more comparable, Linux-friendly alternatives seem closer now than when I got my personal MacBook, and I'm still excited for them). This kind of thing seems like a positive change that lets me feel less conflicted.
Anyway, success here could perhaps be part of a virtuous cycle of increasing community collaboration in the way Apple engages with open-source. I imagine a lot of developers, like me, would both personally benefit from this and respect Apple for it.
If my biases are already outdated, I'm happy to learn that. Either way, my hopes are the same. :)
I suspect this move was designed to stop losing people like you to WSL.
I can happily use my Mac as my primary machine without much hassle, just like I would often do with WSL.
They don't have to do literally any of this.
Besides, I think OP wasn't talking about licenses; Apple has a lot of software under FOSS licenses. But usually, with their open-source projects, they reject most incoming contributions and don't really foster a community for them.
Or distributing builds of something that statically links to it. (Which some would argue creates a derivative work.)
Looks like each container gets its own lightweight Linux VM.
Can take it for a spin by downloading the container tool from here: https://github.com/apple/container/releases (needs macOS 26)
The former is for apps to ship with container sidecars (and cooler news IMO); the latter is 'I am a developer and I want to `docker run ...`'.
(Oh, and container has a submission here: https://news.ycombinator.com/item?id=44229239)
Could games be run inside a virtual Linux environment, rather than Apple’s Metal or similar tool?
This would also help game developers - now they only need to build for Windows, Linux, and consoles.
Do people learn docker not via the CLI?
And like I'm not all anti-GUI, it's just that docker is one of those things I've never even imagined using a GUI for
For Kubernetes, something like K9s [1] or Headlamp [2] works fine. I remember seeing something similar for Docker but I can't remember the name.
[1] https://k9scli.io/ [2] https://headlamp.dev/
The nice part is that they (a) set up the Linux VM that runs the Docker daemon for you and (b) handle the socket forwarding magic that lets you communicate with it "directly" by running the Docker client on the host OS. This is likewise true for Podman Desktop, Rancher Desktop, etc.
The GUI is icing on the cake, imo.
Docker for Desktop sits on-top of container/virtualization software (Hypervisor.framework and QEMU on Mac, WSL on Windows, containerd on Linux). So there's a good chance that future versions of Docker for Desktop will use this library, but they don't really compete with each other.
If it doesn't, then it's still a toss-up whether or not user chooses docker/podman/this...etc.
If it ends up shipping by default and is largely compatible with the same command line flags and socket API... Then docker has a problem.
For what it's worth, I prefer podman but even on Linux where the differentiators should be close to zero, I still find certain things that only docker does.
My org's management wasn't taking the issue seriously, but once the subscription cost reached one FTE's salary, they started listening to people who had already switched to Podman, Rancher or (Co)Lima.
I'll not deny that it's a bit niche, but not so much so that it's completely unknown.
"Apple developer circles" to me means the few mostly indies who build non-electron Mac apps and non-ReactNative ios apps, but those developers mostly are writing client code and don't even touch servers.
All this said, my above "gut feelings" don't explain why Apple would have bothered spending their time making this when Orbstack, Docker, etc. already meet the needs of the developers on Mac who actually need and use containers.
[0]: besides the "Command line tools" that allow compilation to work, of course.
You can make some kind of argument from this that Linux has won; certainly the Linux syscall API is now perhaps the most ubiquitous application API.
Needing two of the most famous non-Linux operating systems for the layman to sanely develop programs for Linux systems is not particularly a victory if you look at it from that perspective. Just highlights the piss-poor state of Linux desktop even after all these years. For the average person, it's still terrible on every front and something I still have a hard time recommending when things so often go belly up.
Before you jump on me, every year, I install the latest Fedora/Ubuntu (supposedly the noob-friendly recommendations) on a relatively modern PC/Laptop and not once have I stopped and thought "huh, this is actually pretty usable and stable".
I think we need to have a specific audience in mind when saying whether or not it's stable. My Arch desktop (user: me) is actually really stable, despite the reputation. I have something that goes sideways maybe once a year or so, and it's a fairly easy fix for me when that does happen. But despite that, I would never give my non-techy parents an Arch desktop. Different users can have different ideas of stable.
The desktop marketshare stats back me up on the earlier point and last I checked, no distro got anywhere close?
Sure, Android is the exception (if we agree to consider) but until we get serious dev going there and until Android morphs into a full-fledged desktop OS, my point stands.
And yes, that's bought by the 'average person'.
I think what slows down market share of Linux on desktop is Linux on desktop itself.
I use Linux, and I understand that it's a very hard job to take it to the level of Windows or macOS, but it is what it is.
Brag about this to an average Windows or Mac user and they will go "huh?" and "what is Linux?"
Depending on what you mean with "the game", I'd say even more so.
MS/Apple used to villify or ridicule Linux, now they need to distribute it to make their own product whole, because it turns out having an Open Source general purpose OS is so convenient and useful it's been utilized in lots of interesting ways - containers, for example - that the proprietary OS implementations simply weren't available for. I'd say it's a remarkable development.
Apple’s docs say nested virtualization is only available on M3-class Macs and newer (VZGenericPlatformConfiguration.isNestedVirtualizationSupported) developer.apple.com, but I don’t see an obvious flag in the container tooling to enable it. Would love to hear if anyone’s managed to get KVM (or even qemu-kvm) running inside one of these VMs.
Docker for Mac builds it in 4 minutes.
container tool... 17 minutes. Maybe even more. And I did set the cpu and memory for the builder as well to higher number than defaults (similar what Docker for Mac is set for). And in reality it is not the build stage, but "=> exporting to oci image format" that takes forever.
Running containers - have not seen any issues yet.
I wonder what the memory overhead is, especially if running multiple containers - as that would spin up multiple VM's.
[0]: https://developer.apple.com/videos/play/wwdc2025/346 10:10 and forwards
> Containers achieve sub-second start times using an optimized Linux kernel configuration[0] and a minimal root filesystem with a lightweight init system.
[0]: https://github.com/apple/containerization/blob/main/kernel/c...
License aside, though, I would still bet that relying on the Apple-specific version of something like this will cause headaches for teams unless you're operating in an environment that's all-in on Apple. Like, your CI tooling in the cloud runs on a Mac, that degree of vendor loyalty. I've never seen any shop like that.
Plus when this tooling does have interoperability bugs, I do not trust Apple to prioritize or even notice the needs of people like me, and they're the ones in charge of the releases.
Presumably it's not as good right now but where it ends up depends entirely on Apple's motivation. When they are determined they can build very good things.
People still want the nice UI/UX, and this is just a Swift package.
They have Xcode cloud.
The $4B contract with Amazon ends, and it’s highly profitable.
Build a container, deploy on Apple, perhaps with access to their CPU’s
This guide seems to have no specific license agreement.
https://www.freecodecamp.org/news/install-xcode-command-line...
I'm not sure this is the same, though. This feels more like docker for desktop running on a lightweight vm like Colima. Am I wrong?
> You need an Apple silicon Mac to build and run Containerization.
> To build the Containerization package, your system needs either:
> macOS 15 or newer and Xcode 26 Beta
> macOS 26 Beta 1 or newer
Those on Intel Macs, this is your last chance to switch to Apple Silicon, (Sequoia was the second last)[0] as macOS Tahoe is the last version to support Intel Macs.
[0] https://news.ycombinator.com/item?id=41560423
I like the hardware, hate the absurd greedy storage and RAM prices.
https://askubuntu.com/questions/55868/installing-broadcom-wi...
Not sure about the newer ones.
Gathering this information and putting together a distro to rescue old Macbooks from the e-waste bin would be a worthwhile project. As far as I can tell they're great hardware.
I imagine things get harder once you get into the USB-C era.
https://t2linux.org/
It isn't systemd:
> Containers achieve sub-second start times using an optimized Linux kernel config, minroot filesystem, and a lightweight init system, vminitd
https://github.com/apple/containerization/blob/main/vminitd
OCI containers are supposed to be "one container, one PID": at the very least the container's server is PID1 (at times other processes may be spawned but typically the container's main process is going to be PID1).
Containerization is literally the antithesis of systemd.
So I don't understand your comment.
No comments yet
Let's run linux inside a container inside docker inside macos inside an ec2 macos instance inside a aws internal linux host inside a windows pc inside the dreaming mind of a child.
And inside that linux maybe run qemu with munal os [https://github.com/Askannz/munal-os]
Not even the first non-hyperbolic part of what you wrote is correct. "Container" most often refers to OS-level virtualization on Linux hosts using a combination of cgroups, resource groups, SDN, and some mount magic (among other things). MacOS is BSD-based and therefore doesn't support the first two things in that list. Apple can either write a compatibility shim that emulates this functionality or virtualize the Linux kernel to support it. They chose the latter. There is no Docker involved.
This is a completely sane and smart thing for them to do. Given the choice I'd still much rather run Linux but this brings macOS a step closer to parity with such.