Why does bluefin use docker in preference to podman?

NOTE: this is not intended as a podman vs docker ideology post

I’ve been using bluefin on the framework for a few months now and I couldn’t be happier – this is now my OS recommendation for all devs. I feel very comfortable in the workflow and (I think) understand most of the decisions made even if I may disagree with some on matters of taste.

The fairly big one that I don’t understand is the re-introduction of docker on top of an otherwise very podman/OCI oriented base system. I’ve looked through the relevant docs (e.g. Developer Mode | Bluefin) and announcements that I could find but couldn’t find a conclusive answer.

As far as I could tell, the main motivations could be:

  • devcontainers prefers docker (though podman seems to work OK with that system these days)
  • more 1:1 to production environments using docker (this seems to be rapidly narrowing except a few areas where the architecture differences stand in the way, mainly namespaces and capabilities, and of course many organizations are moving over to podman these days)
  • negative feelings about toolbx UX (I kinda agree on this one, for example toolbox create should absolutely not let you use incompatible base images as it does currently)
  • potentially stability/performance differences due to more mature docker codebase

I would mainly like to understand:

  • what would I be missing by overlay removing docker related packages?
  • is there a bigger picture that I’m missing?

Developers use docker so we include it and there’s an entire ecosystem of compose files, etc that we need to support.

1 Like

Fair enough! I guess I was overthinking it :smiley:

Not on mobile so I can add more now. We actually experimented with this in the early days. We tried podman-compose and purposely avoided the “just alias podman to docker” trap. We also had podman listening on a socket so that the docker CLI could listen to it. The problem with that is it was different from everything else.

At some point when you run into a README it’s nice to be able to copy and paste a command and have that Just Work™. Also many tools still expect docker ootb. So we just ship both.

From interviewing folks it trends towards ops oriented people prefering podman, and your average app developer learned with Docker. Overwhelmingly most folks were like “just ship both, we have to use both anyway” so that’s what we do lol.

Podman Desktop will manage both in the GUI.

Here’s how I see the two paths:

  • podman: if someone is starting off from scratch and leans towards ops, podman with quadlets is 100% the way to go. It works just like any other service unit, and is a natural starting point to kubernetes. It joining K8s in the CNCF will ensure it’s always a neutral, supported choice in the container ecosystem, so from a long term perspective, you should be good.

  • docker: you have lots of coworkers on macs. :smile: But likely it’s an ecosystem thing, there’s so much of it everywhere.

From a product perspective for Bluefin, we know Ubuntu will always push LXD instead, and Red Hat will never ship Docker in anything, so Bluefin DX can provide a home for Podman, Docker, and Incus.

For me personally I automated my home stuff so long ago it’s going to remain docker compose forever (heh), I find immense value in linuxserver.io’s images, so I use docker for that.

Thank you for the extended reply, I felt a bit awkward asking but all these reasons make total sense. I think I’m going to rpm-ostree override remove the docker-* packages in my case as my entire workflow is very OCI focused (aside from truenas, sigh – I have a fantasy of trying to port their middleware onto coreos)

As someone deeply entrenched in the Docker ecosystem, I greatly appreciate having access to docker on aurora-dx haha

I have to ask, since I run Bazzite on my home machine, is there a best-practice way to run Docker when its not included in the base image? I know there was discussion for a bazzite-dx image on Github and the forums, though I totally understand that there’s probably other priorities at the moment.