Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
> Simply use alias docker=podman and you’ll never know the difference.
Unless you use Docker Swarm, in which case you'll lose access to simple orchestration that's not overengineered, unlike Kubernetes which you'll now be forced to use.
Or unless you use software that depends on the Docker socket being available (such as for Portainer, a graphical management utility [1]), in which case you'll lose the ability to use such software.
Or maybe you're one of the countless folks who tried using Podman but ran into a variety of issues that still haven't been addressed in many cases [2].
Or maybe you use Docker Compose and now have just lost the ability to run simple single node orchestration with YAML files, because Podman Compose is oftentimes flawed as well [3].
That's not to say that what Podman is attempting to do shouldn't be applauded, yet claiming that exchanging one set of leaky abstractions for another set of leaky abstractions is painless and will work for all of the people out there simply isn't true. I don't see Podman being a backwards compatible alternative to Docker on an API level, it'll simply kill it off eventually by supporting the OCI standard for containers and being a Kubernetes runtime at the lower level. Lots of people will need to re-engineer their approach to running containers and lots of time will be necessary to migrate away from Docker.
[1] https://www.portainer.io/
[2] https://github.com/containers/podman/issues
[3] https://github.com/containers/podman-compose/issues
The Docker Toolbox repo is still hanging around, although in archived form: https://github.com/docker/toolbox
With 19.03 it should still be possible to access the public hub, I think.
People didn't "ask for this feature".
People asked for the feature to be disabled. There was a lengthy discussion in GH [0] aptly named "Please don't upgrade docker without asking first" few months back regarding why this shouldn't happen (auto updates, that is).
Considering that the team that codes the software acknowledged they screwed up [1] having to pay for this I have to agree with the comment that says this amounts to ransomware. "Pay us or risk getting f*ked up by our updates".
[0] https://github.com/docker/roadmap/issues/183
> Simply use alias docker=podman and you’ll never know the difference.
Unless you use Docker Swarm, in which case you'll lose access to simple orchestration that's not overengineered, unlike Kubernetes which you'll now be forced to use.
Or unless you use software that depends on the Docker socket being available (such as for Portainer, a graphical management utility [1]), in which case you'll lose the ability to use such software.
Or maybe you're one of the countless folks who tried using Podman but ran into a variety of issues that still haven't been addressed in many cases [2].
Or maybe you use Docker Compose and now have just lost the ability to run simple single node orchestration with YAML files, because Podman Compose is oftentimes flawed as well [3].
That's not to say that what Podman is attempting to do shouldn't be applauded, yet claiming that exchanging one set of leaky abstractions for another set of leaky abstractions is painless and will work for all of the people out there simply isn't true. I don't see Podman being a backwards compatible alternative to Docker on an API level, it'll simply kill it off eventually by supporting the OCI standard for containers and being a Kubernetes runtime at the lower level. Lots of people will need to re-engineer their approach to running containers and lots of time will be necessary to migrate away from Docker.
[1] https://www.portainer.io/
[2] https://github.com/containers/podman/issues
[3] https://github.com/containers/podman-compose/issues
> Simply use alias docker=podman and you’ll never know the difference.
Unless you use Docker Swarm, in which case you'll lose access to simple orchestration that's not overengineered, unlike Kubernetes which you'll now be forced to use.
Or unless you use software that depends on the Docker socket being available (such as for Portainer, a graphical management utility [1]), in which case you'll lose the ability to use such software.
Or maybe you're one of the countless folks who tried using Podman but ran into a variety of issues that still haven't been addressed in many cases [2].
Or maybe you use Docker Compose and now have just lost the ability to run simple single node orchestration with YAML files, because Podman Compose is oftentimes flawed as well [3].
That's not to say that what Podman is attempting to do shouldn't be applauded, yet claiming that exchanging one set of leaky abstractions for another set of leaky abstractions is painless and will work for all of the people out there simply isn't true. I don't see Podman being a backwards compatible alternative to Docker on an API level, it'll simply kill it off eventually by supporting the OCI standard for containers and being a Kubernetes runtime at the lower level. Lots of people will need to re-engineer their approach to running containers and lots of time will be necessary to migrate away from Docker.
[1] https://www.portainer.io/
[2] https://github.com/containers/podman/issues
[3] https://github.com/containers/podman-compose/issues
Build img from source is an option for mac osx.
https://github.com/genuinetools/img
A few rootless feature may not work. But as root i haven't seen problems so far.
I opened this ticket 3.5 years ago and they still violate GDPR https://github.com/docker/for-mac/issues/2122