What is the value add for Docker Desktop?
In a world where podman exists, what's the point of docker on dev machines anyway?
In a world where podman exists, what's the point of docker on dev machines anyway?
I did not know that running basic Linux VMs was something you could do without downloading VMware or Virtual Box - which isn't as easy as just running a few scripts (especially in corporate environments where Brew and other tools might not be so readily available to all employees).
> downloading VMware or Virtual Box - which isn't as easy as just running a few scripts (especially in corporate environments where Brew and other tools might not be so readily available to all employees).
Docker Desktop needs the same level of access, because it runs virtual machines. If you could install it on your own, can't you install those on your own? If it was centrally managed, then IT can switch to one of those programs instead.
> Does Mac have any sort of built-in VM framework like Hyper-V?
Yosemite added Hypervisor.framework, I guess?
Two, actually. Hypervisor.framework [0] to build virtualization solutions on top of a lightweight hypervisor, without third-party kernel extensions, and Virtualization.framework, to create virtual machines and run Linux-based operating systems.
[0] https://developer.apple.com/documentation/hypervisor?languag...
[1] https://developer.apple.com/documentation/virtualization?lan...
Literally the first non-title element in your link. Just because the client is cross-platform doesn't mean the entire solution is turn-key cross-platform.
I was going to say that installing Podman on macOS/Windows leaves the VM as an exercise to the user, but per another comment, there's podman-machine[1], a new-ish built in to setup a VM. However, it's apparently already deprecated (?) and recommends simply 'Vagrant' as an alternative, so seemingly setting up the VM is back to being a user exercise for Podman?
Most of the problems that devs are facing with docker are not actually docker but this layer that tries to abstract the VM. So in the end, it's quite common that you have fix things in the VM or get rid of it. I don't know if docker on WSL2 makes the matter better, none of the devs in my team using Windows can use it because of the memory usage bug.
I don’t think that thinking like an engineer will help you understand the value add here.
Not sure the bare docker daemon VM wrapper has a defensible moat though. Maybe this does more in Windows?
Pretty sure they're used for more than that.
The biggest showstopper for podman is that it runs entirely in userspace on Linux. Having said that, I use it as a drop-in replacement for Docker and it's only become better in the past year. This is somewhat irrelevant to the Docker Desktop product, as podman doesn't provide a nice packaged up solution, but you can use podman on Windows and Mac as long as you have a Linux host available, either as a guest VM or as a machine _elsewhere_ on the network, see [1]. I only use Linux if I can, and the ability to run images without having to run a daemon with root privileges is a very big bonus for me, but it might not be for you. Now I do wonder, how hard would it be to declare a minimal nixOS VM for running as one's podman host :)
As I see it, that's the whole selling point. Need to have something with limited rights or build a container without root? Podman is the way to go.
Just `brew install podman`.
For Windows, Podman is available on many distributions in WSL2.
Why do you believe that? Docker's "root by default" design decision is the bane of Docker. Podman is even described as Docker done right in that regard.
Even for myself flying solo I can use my old desktop as a Podman server, conserving RAM/CPU in my development env. Sounds good to me.
It needs to have parity in all other pseudo-layers (3rd party tool support, support plans, OS support, someone to sign a contract with, compliance tools, etc.) We know most of these go unused or have no real meaning to devs, but they unlock enterprise procurement.
I believe podman has a linkage to RedHat which may actually bring all of the things that procurement want to hear, but the question is whether the door is open to RedHat, or not. Procurement departments can be fickle, preferring Oracle for everything or the other way round trying to eradicate Oracle while permitting a combination of others. It's all politics based on previous experiences and opinions in the end.
https://docs.podman.io/en/latest/markdown/podman-build.1.htm...
> --cache-from
> Images to utilize as potential cache sources. Podman does not currently support caching so this is a NOOP.