> Also, buildx won't commit the intermediate layers during the build. So if something fails, you can't just grab the previous intermediate layer and do `docker run --entrypoint /bin/bash` on that layer to poke around.
> Podman is designed to help with this by providing stronger default security settings compared to Docker. Features like rootless containers, user namespaces, and seccomp profiles, while available in Docker, aren't enabled by default and often require extra setup.
> Because of its daemonless architecture, Podman can perform truly rootless operations.
Daemonless isn't really relevant to rootless.
containerd/buildkitd/dockerd have been supporting rootless mode too, and lots of rootless codes have been mutually ported over across containerd/buildkitd/dockerd and Podman.
The biggest problem with Docker is that its containers are effectively running as root.
This is basically OK when the containers you want to run are more like traditional daemons. But if you allow normal users to run containers, in a shared multiuser system, you are basically giving them root to do what they want with your system.
e.g. if a normal user can execute a docker container, they can create a mount point for anywhere in your system. They can mount /etc or any other spooky place and be able to read from it like they are root.
This is also potentially bad, for example, if you have a network facing daemon, like a web server. Let's say that you bind mount a directory on the host (because yeah, you want to serve up those static HTML files). The privileges of that container (Apache httpd or whatever) are basically running as root on the host system. Not good.
There are solutions for all this, of course. But this is really where Podman was trying to bring in advantage and added-value over Docker. That and just running as a normal process rather than as a daemon.
Sure but to me, and I am obviously biased, if I want to run a container on my system I don't want to fire up multiple daemons in my homedir and then have them sitting out there using resources, when all I want to do is run a containerized application.
One beautiful thing about Podman is it can fire up, pull the image from the container registry, start the container and then go away. Leaving you with only the containerized application running in rootless mode.
To do this with Docker, you fire up the entire Docker infrastructure, then launch the docker client, once the application is up and running, you still need to shut down the docker infrastructure.
Even if you run with podman socket activated server, the podman service will not be running until someone connects to the service, once the connection to the service goes away, the podman service shuts down no longer using system resources.
I mean, that's totally fair response. I should have provided a caveat, "historically speaking", that Docker has lacked support for rootless containers. But yes, solutions have emerged recently.
Podman out the gate has had the facility, which I think it used as a means to distinguish itself. This is great, because maybe that helped push Docker in the right direction.
The older I get, the more it is that "4 years" ago feels like 4 days ago. You calling out my perspective of "recently" is totally fair, because to me, it feels like recently, whereas truthfully maybe not so. Thanks for the reply, I appreciate the facts.
Sure, but I’m pretty sure you still need root to access the Docker daemon. And if you don’t need root, like if you add your account to the Docker group, then your account is essentially always root (since having access to the Docker daemon let’s you do anything).
Podman is just an app. It’s like Vim or ffmpeg. Imagine if Vim ran as a root daemon at all times and you ran sudo to connect to it and edit text files in your home directory. That’s how silly the Docker architecture is.
The Wasm port of the Linux kernel sounds quite interesting as it may potentially help improving the syscall compatibility of elfconv.