[shishirm]

yes, that's correct. With both the drivers (podman, containerd) you can run OCI containers without the need to run docker daemon.

IMO, or atleast when we were making that decision, a key factor that we considered: Since docker has been more ubiquitous as a technology and millions of users have already been running docker in their infrastructure (and containerd under the hood without even knowing that it exists), containerd has seen the test of time a lot more than e.g. podman.

Also to add, containerd as a system is very pluggable and flexible. You can swap out an entire subsystem and write (plug) your own with containerd. e.g. you can write your own custom snapshotter and use that if you don't want to go with the default. e.g. The firecracker-containerd project (https://github.com/firecracker-microvm/firecracker-container...) wrote their own devicemapper snapshotter. From my limited understanding of podman, I believe it's geared more towards security and making containers rootless, which was a pain point in docker initially, since everyone ran containers with root.

[shishirm]

One area, where containerd didn't had a first class support was CLI. the default containerd CLI "ctr" has a very naive implementation. The reason for that I believe is, containerd as a system was never meant to be consumed by humans, and was designed to be consumed by higher layers e.g. orchestration systems like nomad or k8s. However, with the deprecation of dockershim in k8s, and users moving to containerd, a new docker compatible CLI came out:

https://github.com/AkihiroSuda/nerdctl

If you just have containerd running on your system (with no docker daemon running), you can just install nerdctl and add

alias docker="nerdctl"

to your ~/.bashrc file.

Then you can just run any docker commands the way you used to with docker, and it will run those commands against the containerd API giving you the same CLI experience that you used to have with docker.

[3np]

That's really neat, thanks for the link :)