The former is the framework enabling Linux containers on lightweight VMs and the latter is a tool using that framework.
zoobab · 1h ago
"Looks like each container gets its own lightweight Linux VM."
Not a container "as such" then.
How hard is it to emulate linux system calls?
teruakohatu · 1h ago
> How hard is it to emulate linux system calls?
It’s doable but a lot more effort. Microsoft did it with WSL1 and abandoned it with WSL2.
tsimionescu · 28m ago
Note that they didn't "do it" for WSL1, they started doing it, realized it is far too much work to cover eveything, and abandoned the approach in favor of VMs. It's not like WSL1 was a fully functioning Linux emulator on top of Windows, it was still very far from it, even though it could do many common tasks.
paxys · 9h ago
Also works on macOS 15, but they mentioned that some networking features will be limited.
zmmmmm · 6h 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.
pxc · 5h ago
It seems great from a security perspective, and a little bit nice from a networking perspective.
sho_hn · 8h 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 · 8h 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".
omnimus · 1h ago
I am ux designer and forever Mac user. I also try Fedora on random stuff. I am not sure why but last time tried it i got Blender circa 10 years ago vibes from desktop linux gnome.
Everybody has been making fun of Blender forever but they consistently made things better step by step and suddenly few UX enhancements the wind started shift. It completely flipped and now everybody is using it.
I wouldn’t be surprised if desktop Linux days are still ahead. It’s not only Valve and gaming. Many things seems start to work in tandem. Wayland, Pipewire, Flatpack, atomic distros… hey even Gnome is starting to look pretty.
akie · 1h ago
I've been hearing that for 20 years though...
cromka · 30m ago
And that’s exactly what OP alluded to in their Blender comparison.
omnimus · 53m ago
So what? It just means aspirations have been there.
I’ve not been waiting 20 years for linux. But looking at it right now seems pretty positive to me.
sho_hn · 7h 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 · 7h 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 · 6h 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'.
bigstrat2003 · 6h 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.
cromka · 25m ago
My problem with Arch 12 years ago was exactly the fact that things would just randomly stop working and I often wouldn’t know until I needed it. What drew the line for me was when I needed to open a USB pendrive and it wouldn’t mount — if I remember correctly something related to udisk at the time and a race condition. I spent like 30 minutes looking into it and it was just embarrassing as I had someone over my shoulder waiting for those files.
This is when I gave up and switched to Apple. I am now moving back to Linux but Arch still seems like it’s too hacky and too little structured organizationally to be considered trustworthy. So, Ubuntu or Debian it is, but fully haven’t decided yet.
Still, I would be happy to be convinced otherwise. I’m particularly surprised Steam uses it for their OS.
jeroenhd · 3h ago
The problem with the Linux desktop isn't usability, it's the lack of corporate control software. Without corporate MDM and antivirus, you'll find it rather annoying to get a native Linux desktop in many companies.
For Windows and MacOS you can throw a few quick bucks over the wall and tick a whole bunch of ISO checkboxes. For Linux, you need more bespoke software customized to your specific needs, and that requires more work. Sure, the mindless checkboxes add nothing to whatever compliance you're actually trying to achieve, but in the end the auditor is coming over with a list of checkboxes that determine whether you pass or not.
I haven't had a Linux system collapse on me for years now thanks to Flatpak and all the other tools that remove the need for scarcely maintained external repositories in my package manager. I find Windows to be an incredible drag to install compared to any other operating system, though. Setup takes forever, updates take even longer, there's a pretty much mandatory cloud login now, and the desktop looks like a KDE distro tweaked to hell (in a bad way).
Gnome's "who needs a start button when there's one on the keyboard" approach may take some getting used to, but Valve's SteamOS shows that if you prevent users from mucking about with the system internals because gary0x136 on Arch Forums said you need to remove all editors but vi, you end up with a pretty stable system.
kstrauser · 2h ago
In defense of MDM, those checkboxes aren’t even entirely useless. It’s so nice being able to demonstrate that every laptop in the company has an encrypted hard drive, which you should be doing anyway. It turns a lost or stolen laptop from a major situation to a minor financial loss and inconvenience.
Yes, a lot of MDM feature are just there to check ISOwhatever boxes. Some are legitimately great, though. And yes, even though I’m personally totally comfortable running a Linux laptop, come SOC2 audit time it’s way harder to prove that a bunch of Linux boxes meet required controls when you can’t just screenshot the Jamf admin page and call it good.
HdS84 · 1h ago
We introduced MDM for our Mac boxes early this year. Over half(!) had outdated mac versions and missed multiple major updates. Before that - it was always really obvious that you needed to run the newest version ASAP (asap=All dev tools run on the newest version, which was not a given, so a few weeks delay was ok).
We have lots of linux boxes and I suspect their patch state is even worse - but how to check that? There are a dozen distros and a few self build systems...
heavyset_go · 3h ago
In my experience, Linux is great for the type of user who would be well-suited with a Chromebook. Stick a browser, office suite and Zoom on it, and enable automatic updates, and they'll be good to go.
cosmic_cheese · 2h ago
Linux is great for users on the extreme ends of the spectrum, with grandma who only needs email on one end and tiling WM terminal juggler on the other. Where it gets muddy is for everybody in the middle.
That’s not to say it can’t or doesn’t work for some people in the middle, but for this group it’s much more likely that there’s some kind of fly in the soup that’s preventing them from switching.
It’s where I’m at. I keep secondary/tertiary Linux boxes around and stay roughly apprised of the state of the Linux desktop but I don’t think I could ever use it as my “daily driver” unless I wrote my own desktop environment because nothing out there checks all of the right boxes.
heavyset_go · 1h ago
> Linux is great for users on the extreme ends of the spectrum, with grandma who only needs email on one end and tiling WM terminal juggler on the other.
> That’s not to say it can’t or doesn’t work for some people in the middle, but for this group it’s much more likely that there’s some kind of fly in the soup that’s preventing them from switching.
Generally agree with these points with some caveats when it comes to "extremes".
I think for middle to power users, as long as their apps and workflows have a happy path on Linux, their needs are served. That happy path necessarily has to exist either by default or provisioned by employers/OEMs, and excludes anything that requires more than a button push like the terminal.
This is just based on my own experience, I know several people ranging from paralegals working on RHEL without even knowing they're running Linux, to people in VFX who are technically skilled in their niche, but certainly aren't sys admins or tiling window manager users.
Then there are the ~dozen casual gamers with Steam Decks who are served well by KDE on their handhelds, a couple moved over to Linux to play games seemingly without issue.
Lio · 1h ago
I disagree. The only feature I miss on Linux is the ctrl-scroll to zoom feature of macOS.
If Gnome implemented that as well as macOS does I’d happily switch permanently.
esskay · 1h ago
The only feature? Like across the entire OS? Pretty broad. If you were right then adoption would be orders of magnitude higher.
sfpotter · 6h 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.
pjmlp · 1h ago
On the server room yes, but only in the sense UNIX has won, and Linux is the cheapest way to acquire UNIX, with the BSDs sadly looking from their little corner.
However on embedded, and desktop, the market belongs to others, like Zehyr, NutXX, Arduino, VxWorks, INTEGRITY,... and naturally Apple, Google and Microsoft offerings.
Also Linux is an implementation detail on serverless/lambda deployments, only relevant to infrastructure teams.
jeroenhd · 3h ago
Linux has already won, in the form of Android and to an extent ChromeOS. Many people just don't recognize it as such because most of the system isn't the X11/Wayland desktop stack the "normal" Linux distros use.
Hell, Samsung is delivering Linux to the masses in the form of Wayland + PulseAudio under the brand name "Tizen". Unlike desktop land, Tizen has been all-in on Wayland since 2013 and it's been doing fine.
pjmlp · 1h ago
Google could replace Linux kernel with something else and no one would notice, other than OEMs and people rooting their devices.
Likewise with ChromeOS.
They are Pyrrhic victories.
As for Tizen, interesting that Samsung hasn't yet completely lost interest on it.
aljgz · 8h 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 · 8h 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.
heavyset_go · 2h ago
It makes Linux the common denominator between all platforms, which could potentially mean that it gets adopted as a base platform API like POSIX is/was.
More software gets developed for that base Linux platform API, which makes releasing Linux-native software easier/practically free, which in turn makes desktop Linux an even more viable daily driver platform because you can run the same apps you use on macOS or Windows.
pjmlp · 1h ago
As someone that was once upon a time a FOSS zealot with M$ on email signature and all, the only reason I care about Linux on the desktop is exactly Docker containers, everything else I use the native platform software.
Eventually I got practical and fed up with ways of Linux Desktop.
heavyset_go · 51m ago
> Eventually I got practical and fed up with ways of Linux Desktop.
I was in the same boat and used macOS for a decade since it was practical for my needs.
These days I find it easier to do my work on Linux, ironically cross-platform development & audio. At least in my experience, desktop Linux is stable, works with my commercial apps, and things like collaboration over Zoom/Meet/etc with screen sharing actually work out of the box, so it ticks all of my boxes. This certainly wasn't the case several years ago, where Linux incompatibility and instability could be an issue when it comes to collaboration and just getting work done.
duped · 8h ago
Except for graphics, audio, and GUIs for which no good solutions exist
heavyset_go · 2h ago
I'd consider revisiting this. These days you can do studio level video production, graphics and pro audio on Linux using native commercial software from a bare install on modern distributions.
I do pro audio on Linux, my commercial DAWs, VSTs, etc are all Linux-native these days. I don't have to think about anything sound-wise because Pipewire handles it all automatically. IMO, Linux has arrived when it comes to this niche recently, five years ago I'd have to fuck around with JACK, install/compile a realtime kernel and wouldn't have as many DAWs & VSTs available.
Similarly, I have a friend in video production and VFX whose studio uses Linux everywhere. Blender, DaVinci Resolve, etc make that easy.
There is a lack of options when it comes to pro illustration and raster graphics. The Adobe suite reigns supreme there.
stebian_dable · 2h ago
Affinity suite has decent Wine community support by the way for raster / vector graphics.
paxys · 8h 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 · 7h 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 · 7h ago
By that logic, this feature and WSL shouldn't exist.
paxys · 3h ago
They exist because linux server developers would rather use windows or mac as their primary desktop OS rather than linux. That's not a flex for linux desktop. Quite the opposite.
Lio · 1h ago
Equally, they exist because mac and windows users would rather use Linux for their server operating system than anything else and that’s not a flex for Apple or Microsoft either.
heavyset_go · 2h ago
In my experience, it isn't Linux server developers who decide what platform their organizations provision on their employees' devices. That's up to management and IT departments who prefer the simplicity of employees using the same systems they do, and prefer to utilize the competencies in macOS/Windows administration their IT departments have.
baq · 2h ago
Trust me I’d rather use Linux than macOS, that’s after 2.5 years of full time work on a beefy MacBook Pro. The problem is that it isn’t possible to buy a machine as good as the MacBook which runs Linux. Asahi is not ready and won’t be for years, if ever.
whatevermom · 2h ago
Asahi is not that bad, did you try it out? I’ve been building a Sway configuration from scratch on it since two weeks and it’s working pretty well. Did a ton of administrative stuff with it yesterday without much trouble other than the key bindings being a bit weird coming from macOS.
OJFord · 8h ago
'Linux with macOS.'
spockz · 5h ago
At first I thought this sounded like a blend of the virtualisation framework with a firecracker style lightweight kernel.
This project had its own kernel, but it also seems to be able to use the firecracker one. I wonder what the advantages are. Even smaller? Making use of some apple silicon properties?
Has anyone tried it already and is it fast? Compared to podman on Linux or Docker Desktop for Mac?
rfoo · 1h ago
The advantage is, now there's an Apple team working on it. They will be bothered by their own bugs and hopefully get them fixed.
Virtualization.framework and co was buggy af when introduced and even after a few major macOS versions there are still lots of annoyances, for example the one documented in "Limitations on macOS 15" of this project, or half-assed memory ballooning support.
Hypervisor.framework on the other hand, is mostly okay, but then you need to write a lot more codes. Hypervisor.framework is equivalent to KVM and Virtualization.framework is equivalent to qemu.
sangeeth96 · 9h 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
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.
boxed · 4h ago
> WebKit was basically a hostile fork of KHTML
Chromiom is a hostile fork of WebKit. Webkit was a rather polite fork of KHTML, just that they had a team of full time programmers so KHTML couldn't keep up with the upstream requests and gave up since WebKit did a better job anyway.
I personally would LOVE if a corporation did this to any of my open source projects.
todotask2 · 3h ago
And the creator of KHTML is now part of WebKit team at Apple.
Even KDE eventually dropped KHTML in favor of KHTML’s own successor, WebKit-based engines (like QtWebKit and later Qt WebEngine based on Chromium).
A web engine isn’t just software — it needs to keep evolving.
Recognising the value of someone’s work is better than ignoring it and trying to build everything from scratch on your own, Microsoft's Internet Explorer did not last.
bigyabai · 3h ago
Blink is the hostile fork of WebKit. And you would not like if any corporations did this to your Open Source project; on HN alone I see a small army's worth of people who bitch about websites built for Chrome but not Safari. That's how Konquerer users felt back when Apple didn't collaborate downstream, so turnabout is truly fair play.
kergonath · 2h ago
> That's how Konquerer users felt back when Apple didn't collaborate downstream, so turnabout is truly fair play.
You are rewriting history here. The main KHTML developers were hired by Apple and Konqueror got on with the new engine. There was no fuss and no drama.
The reason why it’s fair play is that the license allows it. Google is no white knight out to avenge the poor KHTML users from 2003.
mattl · 2h ago
I think there was some perceived initial concern about the patches provided by Apple to KHTML in so much as they now had to merge a huge amount of code into the project and much of it was (IIRC) lots and lots of ifdef statements.
holycrapwhodat · 5h ago
> WebKit was basically a hostile fork of KHTML...
WebKit has been a fully proper open source project - with open bug tracker, patch review, commit history, etc - since 2005.
Swift has been a similarly open project since 2015.
Timeline-wise, a new high profile open source effort in 2025 checks out.
jen20 · 4h ago
FoundationDB is a fully proper open source project since 2018…
gigatexal · 4h ago
I too am more of a reluctant convert to Mac from Linux. It really does just work most of the time for me in the work context. It allows me to get my job done and not worry because it’s the most supported platform at the office. Shrug. But also the hardware is really really really nice.
I do have a personal MacBook pro that I maxed out (https://gigatexal.blog/pages/new-laptop/new-laptop.html) but I do miss tinkering with my i3 setup and trying out new distos etc. I might get a used thinkpad just for this.
But yeah my Mac personal or work laptop just works and as I get older that’s what I care about more.
Going to try out this container binary from them. Looks interesting.
roughly · 3h ago
If you’re looking for a hobby computer, Framework’s laptops are a lot of fun. There’s something about a machine that’s so intentionally designed to be opened up and tinkered with - it’s not my daily driver, but it’s my go to for silly projects now.
willtemperley · 3h ago
I find Apple to be very collaborative on OSS - I hacked up a feature I needed in swift-protobuf and over a couple of weeks two Apple engineers and one Google engineer spent a significant amount of time reviewing and helping me out. It was a good result and a great learning experience.
zapzupnz · 7h ago
It's not that surprising. Much of Swift and its frameworks are contributed by the open source community.
pxc · 7h 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 · 6h 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)
klausa · 1h ago
What’s Jai?
noufalibrahim · 3h ago
Apple has a lot of good stuff out there doesn't it?
Aren't llvm and cups theirs more or less?
kergonath · 2h ago
They gave up on CUPS, which was left in limbo for way too long. Now it’s been forked, but I don’t know how successful that fork is.
They took over LLVM by hiring Chris Lattner. It was still a significant investment and they keep pouring resources into it for a long while before it got really widespread adoption. And yes, that project is still going.
overfeed · 7h 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.
guztaver · 6h 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.
mikepurvis · 6h 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.
ma5ter · 5h ago
> I suspect this move was designed to stop losing people like you to WSL.
I am also thinking the same, Docker desktop experience was not that great at least on Intel Macs
nhumrich · 7h ago
Since this is touching Linux, and Linux is copy left, they _have_ to do this.
mirashii · 7h 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 · 6h ago
Right! The exciting thing is the approach, not the license.
n2d4 · 7h 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 · 6h ago
> derivative work
Or distributing builds of something that statically links to it. (Which some would argue creates a derivative work.)
jen20 · 4h ago
This doesn’t do that, though.
pxc · 7h ago
If the license of this project were determined by obligations to the Linux kernel, it would be GPLv2, not Apache License 2.0!
Aurornis · 6h ago
The comment was about them welcoming contributions, not making it open source.
candiddevmike · 10h ago
Wonder how Docker feels about this. I'd assume a decent amount of Docker for Desktop is on Mac...
paxys · 10h 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 · 8h 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.
cosmotic · 5h ago
Docker desktop on macos uses the Apple virtualization framework to run a Linux VM these days.
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 · 9h 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 · 9h 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 · 8h 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 · 9h ago
Dropbox copypasta goes here
Spivak · 9h 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 · 6h 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 · 6h 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 · 8h 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
spockz · 5h ago
You don’t have to install docker desktop. The cli can be installed via homebrew. (Co)Lima, podman, or others, can be used to create a VM running the docker engine.
It’s just that Docker Desktop makes it easy and also provides other integrations like file system sharing etc.
selcuka · 8h 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.
I think there's a difference in that dropbox was targeted at regular users, not just developers.
I think docker desktop and apple's containerization are both targeted firmly at developers only.
It's like programming, sure it's possible to write code in microsoft office or xcode or vscode, but all programmers I've met opt for ed or vi.
arjonagelhout · 9h ago
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 · 9h 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 · 8h 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
bruckie · 5h ago
I use Rancher Desktop plus the FOSS docker CLI from Homebrew. Works well, and has no licensing issues.
pxc · 7h 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 · 9h ago
Very few use the GUI for things other than configuring Docker engine settings like memory, etc.
n2d4 · 7h 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 · 10h ago
Probably about the same way they feel about podman.
baby_souffle · 8h 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 · 9h ago
Podman is fairly niche. This is an Apple product that Apple developer circles will push hard.
hocuspocus · 8h 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 · 8h ago
and telemetry on macos
cogman10 · 9h 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.
jeroenhd · 3h ago
Podman is the easy go-to for companies that don't like how Docker Desktop requires a license.
I'm sure Apple will try to push their own version of Docker but I'm not sure if they'll be able to win over any Docker Desktop businesses unless their tool also works on other operating systems.
pjmlp · 1h ago
On Windows it is Rancher Desktop that tends to be used, especially since podman only of late started making an easy GUI offering.
Sadly all of them are Electron based.
xp84 · 8h 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 · 6h ago
Also the second they started charging podman dev picked up and that has gotten real good.
sneak · 10h ago
Docker Desktop is closed source proprietary software and this is free software, so this is a win (for us, at least).
SamuelAdams · 6h 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.
pxc · 5h ago
Apple's Virtualization Framework doesn't support 3D acceleration for non-macOS guests.
throwaway127482 · 4h ago
Isn't the Linux gaming stuff really an emulator for Windows games? So it'd be like, windows emulation inside Linux virtualization inside macos?
lxgr · 4h ago
As far as I understand, it's a modified/extended version of Wine, which, as the name suggests, is not an emulator (but rather a userspace reimplementation of the Windows API, including a layer that translates DirectX to OpenGL/Vulkan).
The reverse, i.e. running Linux binaries on Windows or macOS, is not easily possible without virtualization, since Linux uses direct syscalls instead of always going through a dynamically linked static library that can take care of compatibility in the way that Wine does. (At the very least, it requires kernel support, like WSL1; Wine is all userspace.)
izacus · 2h ago
No, and with sunset of Rosetta, they'll kill off many of the few games that fun on macOS.
golf1052 · 2h ago
According to reporting Rosetta will still be supported for old games that rely on Intel code
> But after that, Rosetta will be pared back and will only be available to a limited subset of apps—specifically, older games that rely on Intel-specific libraries but are no longer being actively maintained by their developers. Devs who want their apps to continue running on macOS after that will need to transition to either Apple Silicon-native apps or universal apps that run on either architecture.
Windows games already run on macOS via WINE. Using a VM would just add overhead not reduce it.
october8140 · 5h ago
I imagine running in a VM would hurt performance a lot.
lxgr · 4h ago
Not necessarily. For example, the Xbox 360 runs every game in a hypervisor, so technically, everything is running in a VM.
It's all a question of using the right/performant hardware interfaces, e.g. IOMMU-based direct hardware access rather than going through software emulation for performance-critical devices.
roberttod · 9h 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 · 8h 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 · 8h ago
Yes, that's exactly what it's for.
paxys · 8h 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 · 6h 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).
sitole · 7h 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.
jbverschoor · 9h 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 · 9h 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 · 7h 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.
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 · 10h ago
Orbstack also does kubernetes etc
9dev · 10h 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 · 8h 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 · 8h ago
Wild because "Apple proprietary" is on GitHub and Orbstack is closed source but go off I guess.
xp84 · 8h 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.
9dev · 1h ago
If Apple is committed to containers on MacOS, it makes sense to use their implementation over a third party. They know their own platform more intimately, can push for required kernel changes internally if necessary, and will provide this feature free of charge since it's in their own interest to do so—as apparent from the fact the source is published on GitHub, under Apache.
As opposed to that, there's OrbStack, a venture-backed closed source application thriving off of user licenses, developed by a small team. As empathetic as I am with them, I know where I bet my money on in this race.
jpgvm · 8h 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 · 8h 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
bdcravens · 8h ago
They could replace their underlying implementations with this, and for most users, they wouldn't notice the difference, other than any performance gains.
peterpost2 · 56m ago
Terrible name. Look like a neat product though!
bravesoul2 · 1m ago
Tailored Swift would be better
mustache_kimono · 3h ago
This is great. Also about time, etc.
But is it also finally time to fix dtrace on MacOS[0]?
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 · 10h 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 · 9h 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.
cedws · 4h ago
Forget Linux containers on Mac, as far as I’m concerned that’s already a solved problem. What about Mac containers? We still don’t have a way to run a macOS app with its own process namespace/filesystem in 2025. And with all this AI stuff, there’s a need to minimise blast radius of a rogue app more than ever.
hadlock · 4h ago
Is there any demand for mac binaries in production? I can't think of a single major cloud provider that offers Mac hardware based k8s nor why you'd want to pay the premium over commodity hardware. Linux seems to be the lingua franca of containerized software distribution. Even windows support for containers is sketchy at best
vineyardmike · 3h ago
> I can't think of a single major cloud provider that offers Mac hardware based k8s nor why you'd want to pay the premium over commodity hardware
If you're a dev team that creates Mac/iOS/iPad/etc apps, you might want Mac hardware in your CI/CD stack. Cloud providers do offer virtual Macs for this purpose.
If you're a really big company (eg. a top-10 app, eg. Google) you might have many teams that push lots of apps or app updates. You might have a CI/CD workflow that needs to scale to a cluster of Macs.
Also, I'm pretty sure apple at least partially uses Apple hardware in the serving flow (eg. "Private Cloud Compute") and would have an interest in making this work.
Oh, and it'd be nice to be able to better sand-box untrusted software running on my personal dev machine.
alwillis · 3h ago
> uses Apple hardware in the serving flow (eg. "Private Cloud Compute")
> The root of trust for Private Cloud Compute is our compute node: custom-built server hardware that brings the power and security of Apple silicon to the data center, with the same hardware security technologies used in iPhone, including the Secure Enclave and Secure Boot. We paired this hardware with a new operating system: a hardened subset of the foundations of iOS and macOS
I would cal this "Apple Hardware" even if its not the same thing you can buy at an Apple Store.
jurip · 4h ago
I don't think the parent was asking for server side macOS containerization, but desktop. It'd be nice to put something like Cursor in a sandbox where it really couldn't rm -rf your home directory. I'd love to do the same thing with every app that comes with an installer.
hadlock · 52m ago
I've had really poor experience doing anything with container deployed consumer apps in Linux. As soon as you even look at going out of the happy path, things immediately start going sideways.
tgma · 4h ago
Mm... AppStore and Gatekeeper?
rfoo · 10h ago
This does not support memory ballooning yet. But they have documented custom kernel support, so, goodbye OrbStack.
worldsavior · 10h ago
Orbstack is docker. People might still prefer docker.
mattclarkdotnet · 4h ago
Spoiler alert: it’s not containers.
It’s some nice tooling wrapped around lightweight VMs, so basically WSL2
cromka · 18m ago
WSL1, rather.
amazingman · 2h ago
Are the lightweight VMs running containers?
filleokus · 10h 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.
Many developers I know don't use MacOS mainly because they depend on containers and virtualisation is slow, but if Apple can pull off efficient virtualisation and good system integration (port mapping, volumes), then it will eat away at a large share of linux systems.
sampton · 9h ago
Apple please expose GPU cores to the VMs.
emmelaich · 8h 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.
lisperforlife · 6h ago
You can use libkrun to pretty much do the same thing.
miovoid · 5h ago
I hope it will support nested virtualization.
joshdavham · 9h 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 · 8h 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.
m3kw9 · 7h ago
I’m already running docker on macOS what’s the difference?
sneak · 10h ago
Surprising to me that this uses swift CLI tools (free software) and make, not Xcode.
w10-1 · 9h ago
Containers are mainly for CI+testing and for Linux workflows, so xcodebuild is not really an option.
detourdog · 10h ago
Xcode also has command line tools that can do the same.
sneak · 9h ago
Obtaining and using Xcode requires submitting to an additional license contract from Apple. Swift and Make do not.
detourdog · 9h 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.
Accepting license agreements isn’t standard because EULAs aren’t standard. Each one is a contract and each one is unique.
Just because you click through them all without reading doesn’t mean they are all equivalent. Xcode has an EULA. Swift and Make do not, being free software.
They are not the same.
jamie0 · 10h ago
disappointing theres still no namespacing in darwin for macos containers. would be great to run xcodebuild in a container
rvz · 10h 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 · 10h 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 · 8h 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.
samtheprogram · 3h ago
> For instance, no software for "cloud" drives (google drive, onedrive, icloud drive) is allowed to locate its local copy on an "External" drive
Source? Is this self-imposed, or what does “allowed” mean?
Even if true, technical people can work around this by either spoofing a non-external drive or using `ln`, no?
haiku2077 · 1h ago
> Even if true, technical people can work around this by either spoofing a non-external drive or using `ln`, no?
IIRC Google Drive for Desktop won't sync the target of a symbolic link. It will sync the target of a hard link, but hard links can only target the same filesystem that the link is on, so you can't target an external drive on macOS AFAIK.
I can't speak for the other software you mentioned.
GeekyBear · 5h ago
The M4 Mini ships with 16 Gigs of RAM minimum and accepts third party SSD replacements.
xp84 · 1h ago
Not SSDs. Weird little proprietary NAND modules that someone reverse-engineered and that Apple will hopefully not issue a software update to brick. The controller part of the SSD is in the CPU. For “reasons” I guess
paxys · 8h 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 · 8h 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 · 8h 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 · 10h ago
a 30% discount for a 3 yr old machine is good? A new one is $999.
DrBenCarson · 10h 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 · 10h ago
Even better deals on M1s which aren't much slower than M2s
keysdev · 10h ago
Any linux or bsd that has goodhardwawe support for intel mac?
bjackman · 10h 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 · 10h 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 · 10h 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
IshKebab · 10h ago
Getting worried about WSL I see!
SkepticalWhale · 10h 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 · 7h ago
This is my same workflow even for C#
m463 · 8h 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)
bdcravens · 8h ago
Cool, but until someone (Apple or otherwise) implements Docker Compose on top of this, it's unlikely to see much use.
tgma · 4h ago
I'm glad this will kill the Docker Desktop clone business on Mac. Friend company got hit by using one of the free ones and got rug pulled by them.
9d · 9h 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 · 8h 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.
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)
Not a container "as such" then.
How hard is it to emulate linux system calls?
It’s doable but a lot more effort. Microsoft did it with WSL1 and abandoned it with WSL2.
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".
Everybody has been making fun of Blender forever but they consistently made things better step by step and suddenly few UX enhancements the wind started shift. It completely flipped and now everybody is using it.
I wouldn’t be surprised if desktop Linux days are still ahead. It’s not only Valve and gaming. Many things seems start to work in tandem. Wayland, Pipewire, Flatpack, atomic distros… hey even Gnome is starting to look pretty.
I’ve not been waiting 20 years for linux. But looking at it right now seems pretty positive to me.
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 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.
This is when I gave up and switched to Apple. I am now moving back to Linux but Arch still seems like it’s too hacky and too little structured organizationally to be considered trustworthy. So, Ubuntu or Debian it is, but fully haven’t decided yet.
Still, I would be happy to be convinced otherwise. I’m particularly surprised Steam uses it for their OS.
For Windows and MacOS you can throw a few quick bucks over the wall and tick a whole bunch of ISO checkboxes. For Linux, you need more bespoke software customized to your specific needs, and that requires more work. Sure, the mindless checkboxes add nothing to whatever compliance you're actually trying to achieve, but in the end the auditor is coming over with a list of checkboxes that determine whether you pass or not.
I haven't had a Linux system collapse on me for years now thanks to Flatpak and all the other tools that remove the need for scarcely maintained external repositories in my package manager. I find Windows to be an incredible drag to install compared to any other operating system, though. Setup takes forever, updates take even longer, there's a pretty much mandatory cloud login now, and the desktop looks like a KDE distro tweaked to hell (in a bad way).
Gnome's "who needs a start button when there's one on the keyboard" approach may take some getting used to, but Valve's SteamOS shows that if you prevent users from mucking about with the system internals because gary0x136 on Arch Forums said you need to remove all editors but vi, you end up with a pretty stable system.
Yes, a lot of MDM feature are just there to check ISOwhatever boxes. Some are legitimately great, though. And yes, even though I’m personally totally comfortable running a Linux laptop, come SOC2 audit time it’s way harder to prove that a bunch of Linux boxes meet required controls when you can’t just screenshot the Jamf admin page and call it good.
That’s not to say it can’t or doesn’t work for some people in the middle, but for this group it’s much more likely that there’s some kind of fly in the soup that’s preventing them from switching.
It’s where I’m at. I keep secondary/tertiary Linux boxes around and stay roughly apprised of the state of the Linux desktop but I don’t think I could ever use it as my “daily driver” unless I wrote my own desktop environment because nothing out there checks all of the right boxes.
> That’s not to say it can’t or doesn’t work for some people in the middle, but for this group it’s much more likely that there’s some kind of fly in the soup that’s preventing them from switching.
Generally agree with these points with some caveats when it comes to "extremes".
I think for middle to power users, as long as their apps and workflows have a happy path on Linux, their needs are served. That happy path necessarily has to exist either by default or provisioned by employers/OEMs, and excludes anything that requires more than a button push like the terminal.
This is just based on my own experience, I know several people ranging from paralegals working on RHEL without even knowing they're running Linux, to people in VFX who are technically skilled in their niche, but certainly aren't sys admins or tiling window manager users.
Then there are the ~dozen casual gamers with Steam Decks who are served well by KDE on their handhelds, a couple moved over to Linux to play games seemingly without issue.
If Gnome implemented that as well as macOS does I’d happily switch permanently.
However on embedded, and desktop, the market belongs to others, like Zehyr, NutXX, Arduino, VxWorks, INTEGRITY,... and naturally Apple, Google and Microsoft offerings.
Also Linux is an implementation detail on serverless/lambda deployments, only relevant to infrastructure teams.
Hell, Samsung is delivering Linux to the masses in the form of Wayland + PulseAudio under the brand name "Tizen". Unlike desktop land, Tizen has been all-in on Wayland since 2013 and it's been doing fine.
Likewise with ChromeOS.
They are Pyrrhic victories.
As for Tizen, interesting that Samsung hasn't yet completely lost interest on it.
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.
More software gets developed for that base Linux platform API, which makes releasing Linux-native software easier/practically free, which in turn makes desktop Linux an even more viable daily driver platform because you can run the same apps you use on macOS or Windows.
Eventually I got practical and fed up with ways of Linux Desktop.
I was in the same boat and used macOS for a decade since it was practical for my needs.
These days I find it easier to do my work on Linux, ironically cross-platform development & audio. At least in my experience, desktop Linux is stable, works with my commercial apps, and things like collaboration over Zoom/Meet/etc with screen sharing actually work out of the box, so it ticks all of my boxes. This certainly wasn't the case several years ago, where Linux incompatibility and instability could be an issue when it comes to collaboration and just getting work done.
I do pro audio on Linux, my commercial DAWs, VSTs, etc are all Linux-native these days. I don't have to think about anything sound-wise because Pipewire handles it all automatically. IMO, Linux has arrived when it comes to this niche recently, five years ago I'd have to fuck around with JACK, install/compile a realtime kernel and wouldn't have as many DAWs & VSTs available.
Similarly, I have a friend in video production and VFX whose studio uses Linux everywhere. Blender, DaVinci Resolve, etc make that easy.
There is a lack of options when it comes to pro illustration and raster graphics. The Adobe suite reigns supreme there.
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.
This project had its own kernel, but it also seems to be able to use the firecracker one. I wonder what the advantages are. Even smaller? Making use of some apple silicon properties?
Has anyone tried it already and is it fast? Compared to podman on Linux or Docker Desktop for Mac?
Virtualization.framework and co was buggy af when introduced and even after a few major macOS versions there are still lots of annoyances, for example the one documented in "Limitations on macOS 15" of this project, or half-assed memory ballooning support.
Hypervisor.framework on the other hand, is mostly okay, but then you need to write a lot more codes. Hypervisor.framework is equivalent to KVM and Virtualization.framework is equivalent to qemu.
> 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.
Chromiom is a hostile fork of WebKit. Webkit was a rather polite fork of KHTML, just that they had a team of full time programmers so KHTML couldn't keep up with the upstream requests and gave up since WebKit did a better job anyway.
I personally would LOVE if a corporation did this to any of my open source projects.
Even KDE eventually dropped KHTML in favor of KHTML’s own successor, WebKit-based engines (like QtWebKit and later Qt WebEngine based on Chromium).
A web engine isn’t just software — it needs to keep evolving.
Recognising the value of someone’s work is better than ignoring it and trying to build everything from scratch on your own, Microsoft's Internet Explorer did not last.
You are rewriting history here. The main KHTML developers were hired by Apple and Konqueror got on with the new engine. There was no fuss and no drama.
The reason why it’s fair play is that the license allows it. Google is no white knight out to avenge the poor KHTML users from 2003.
WebKit has been a fully proper open source project - with open bug tracker, patch review, commit history, etc - since 2005.
Swift has been a similarly open project since 2015.
Timeline-wise, a new high profile open source effort in 2025 checks out.
I do have a personal MacBook pro that I maxed out (https://gigatexal.blog/pages/new-laptop/new-laptop.html) but I do miss tinkering with my i3 setup and trying out new distos etc. I might get a used thinkpad just for this.
But yeah my Mac personal or work laptop just works and as I get older that’s what I care about more.
Going to try out this container binary from them. Looks interesting.
If my biases are already outdated, I'm happy to learn that. Either way, my hopes are the same. :)
They took over LLVM by hiring Chris Lattner. It was still a significant investment and they keep pouring resources into it for a long while before it got really widespread adoption. And yes, that project is still going.
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.
I am also thinking the same, Docker desktop experience was not that great at least on Intel Macs
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.)
https://developer.apple.com/documentation/virtualization
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
It’s just that Docker Desktop makes it easy and also provides other integrations like file system sharing etc.
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/
I think docker desktop and apple's containerization are both targeted firmly at developers only.
It's like programming, sure it's possible to write code in microsoft office or xcode or vscode, but all programmers I've met opt for ed or vi.
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.
I'm sure Apple will try to push their own version of Docker but I'm not sure if they'll be able to win over any Docker Desktop businesses unless their tool also works on other operating systems.
Sadly all of them are Electron based.
"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.
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.
The reverse, i.e. running Linux binaries on Windows or macOS, is not easily possible without virtualization, since Linux uses direct syscalls instead of always going through a dynamically linked static library that can take care of compatibility in the way that Wine does. (At the very least, it requires kernel support, like WSL1; Wine is all userspace.)
> But after that, Rosetta will be pared back and will only be available to a limited subset of apps—specifically, older games that rely on Intel-specific libraries but are no longer being actively maintained by their developers. Devs who want their apps to continue running on macOS after that will need to transition to either Apple Silicon-native apps or universal apps that run on either architecture.
https://arstechnica.com/gadgets/2025/06/apple-details-the-en...
It's all a question of using the right/performant hardware interfaces, e.g. IOMMU-based direct hardware access rather than going through software emulation for performance-critical devices.
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.
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
Container: Apple's Linux-Container Runtime - https://news.ycombinator.com/item?id=44229239 - June 2025 (11 comments)
Apple announces Foundation Models and Containerization frameworks, etc - https://news.ycombinator.com/item?id=44226978 - June 2025 (345 comments)
(Normally we'd merge them but it seems there are significant if subtle differences)
People still want the nice UI/UX, and this is just a Swift package.
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.
As opposed to that, there's OrbStack, a venture-backed closed source application thriving off of user licenses, developed by a small team. As empathetic as I am with them, I know where I bet my money on in this race.
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.
But is it also finally time to fix dtrace on MacOS[0]?
[0]: https://developer.apple.com/forums/thread/735939?answerId=76...
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.
If you're a dev team that creates Mac/iOS/iPad/etc apps, you might want Mac hardware in your CI/CD stack. Cloud providers do offer virtual Macs for this purpose.
If you're a really big company (eg. a top-10 app, eg. Google) you might have many teams that push lots of apps or app updates. You might have a CI/CD workflow that needs to scale to a cluster of Macs.
Also, I'm pretty sure apple at least partially uses Apple hardware in the serving flow (eg. "Private Cloud Compute") and would have an interest in making this work.
Oh, and it'd be nice to be able to better sand-box untrusted software running on my personal dev machine.
Private Cloud Compute is different hardware: https://security.apple.com/blog/private-cloud-compute/
I would cal this "Apple Hardware" even if its not the same thing you can buy at an Apple Store.
It’s some nice tooling wrapped around lightweight VMs, so basically WSL2
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...
Many developers I know don't use MacOS mainly because they depend on containers and virtualisation is slow, but if Apple can pull off efficient virtualisation and good system integration (port mapping, volumes), then it will eat away at a large share of linux systems.
This guide seems to have no specific license agreement.
https://www.freecodecamp.org/news/install-xcode-command-line...
Just because you click through them all without reading doesn’t mean they are all equivalent. Xcode has an EULA. Swift and Make do not, being free software.
They are not the same.
> 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.
Source? Is this self-imposed, or what does “allowed” mean?
Even if true, technical people can work around this by either spoofing a non-external drive or using `ln`, no?
IIRC Google Drive for Desktop won't sync the target of a symbolic link. It will sync the target of a hard link, but hard links can only target the same filesystem that the link is on, so you can't target an external drive on macOS AFAIK.
I can't speak for the other software you mentioned.
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
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?
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.