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.
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.
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.
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.
The problem (as far as I can tell) is that for Windows and MacOS you can't install the docker daemon etc without installing Desktop.
I have a Mac for work and containers are a pain. I've tried Podman, UTM, colima, Docker Desktop etc and it all boils down to the same thing - run a linux VM and have the command line utils cooperate with the VM to run the containers.
It comes down to which solution has the least friction and irritations and Docker might still win there.
My current setup is UTM running a debian VM which I share my source directory with and ssh into to run docker. This is simpler for my brain to understand because the linux VM isn't a hidden component I forget to manage.
But it's not obvious how to mount the shared directory and I'm constantly running into networking problems - currently I cannot connect as myself and must sudo ssh for it to work. A reboot (of the Mac) used to fix it, but no longer does. I've given up trying to fix it and just sudo.
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.
Unless this provides an extremely compatible Docker socket implementation, this is the answer. When Docker changed the licensing for Docker Desktop, my previous employer made it harder to get permission. However, there were a few tools that were in common usage, and once you mentioned that you used them, you got your permission.
Some progress has been made to create a non-Docker implementation that integrates with all those random tools that expect to be able to yeet bytes into or out of the Docker socket, but I still hit blockers the last time I tried.
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.
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.
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.
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.
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.
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.
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.
Docker desktop on macos uses the Apple virtualization framework to run a Linux VM these days.
https://developer.apple.com/documentation/virtualization
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.
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.
14 replies →
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.
3 replies →
The problem (as far as I can tell) is that for Windows and MacOS you can't install the docker daemon etc without installing Desktop.
I have a Mac for work and containers are a pain. I've tried Podman, UTM, colima, Docker Desktop etc and it all boils down to the same thing - run a linux VM and have the command line utils cooperate with the VM to run the containers.
It comes down to which solution has the least friction and irritations and Docker might still win there.
My current setup is UTM running a debian VM which I share my source directory with and ssh into to run docker. This is simpler for my brain to understand because the linux VM isn't a hidden component I forget to manage.
But it's not obvious how to mount the shared directory and I'm constantly running into networking problems - currently I cannot connect as myself and must sudo ssh for it to work. A reboot (of the Mac) used to fix it, but no longer does. I've given up trying to fix it and just sudo.
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.
Very few use the GUI for things other than configuring Docker engine settings like memory, etc.
Unless this provides an extremely compatible Docker socket implementation, this is the answer. When Docker changed the licensing for Docker Desktop, my previous employer made it harder to get permission. However, there were a few tools that were in common usage, and once you mentioned that you used them, you got your permission.
Some progress has been made to create a non-Docker implementation that integrates with all those random tools that expect to be able to yeet bytes into or out of the Docker socket, but I still hit blockers the last time I tried.
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.
Probably about the same way they feel about podman.
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.
Podman is fairly niche. This is an Apple product that Apple developer circles will push hard.
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.
1 reply →
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.
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.
1 reply →
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.
5 replies →
Docker Desktop is closed source proprietary software and this is free software, so this is a win (for us, at least).
Also the second they started charging podman dev picked up and that has gotten real good.