[drnick1]

> the idea of dealing with systemd unit files or kublet configs, and having to created dedicated local service accounts

Podman does not require systemd (thank God). I use a simple podman compose up/down in a user systemd file to automatically bring my containers up at boot, but other mechanisms are possible, like quadlets and init scripts.

[porkloin]

Quadlets are awesome and honestly I think one of the best additive things that podman has on top of the regular docker toolset.

I use podman regularly, and despite it being a good drop-in replacement like 95% of the time, the 5% of the time where it isn't seamless are super painful. For example, skaffold (https://skaffold.dev/) pukes all over itself when you try to run podman as a drop in replacement. I'm sure there are plenty of other examples, but that one stops me from using podman at work in addition to in my personal projects.

[krick]

Well, but that's kinda the point, isn't it? You know that other mechanisms are possible, but you opted out for a user systemd file. I know that too, and I also just use systemd for that. Because the alternative doesn't look much easier. I guess it makes sense that they try to discourage it now, because for serious deployment it isn't the best option. But when I install Podman on my laptop, I really wish the systemd configs would be added automatically without me even knowing.

I mean, really, if we keep in mind that formally these are 2 totally unrelated projects, it's hard to complain. Yes, it's almost seamless. But since when installing Podman everyone thinks roughly "I am installing a newer better Docker version", and we all already have a few dozens of custom Docker containers running, it's hard no to wish it was even more seamless and backwards-compatible. I remember the transition process wasn't nearly as smooth as I hoped, and every small glitch is kinda stressful, because you know that currently all of it "somehow works", and if something breaks you probably won't even notice right away.