Most of my containers end up on k8s clusters as pods. What else would one use podman or docker for beyond local dev or maybe running a local containerized service?

Both podman and docker have pretty poor error handling in my experience. It depends on the error, but for me it often comes down to a docker compose misconfiguration, resource, permissions, etc. In docker always find the errors quite difficult to trace back to root cause. In podman you get a python a stack trace. I wish both projects would assert different assumptions/requirements at runtime and report errors/warnings in a human-readable way.

The "podman generate systemd" command from the article is deprecated. The alternative are Podman Quadlets, which are similar to (docker-)compose.yaml, but defined in systemd unit files.

I would love to love Podman, but the fact that it regularly just fails to work on my Windows laptop (the WSL2 instance seems fine, but can't be connected to, the UI just says 'starting', and none of the menu options do anything) and that I can't figure out how to make IPv6 networking work on any platform means that Docker isn't going anywhere for the foreseeable future, I'm afraid...

Last third party container I’ve built had COPY —-link statements that didn’t worked on podman. Granted it worked just fine with a normal copy but it’s not 1:1.

I have ditched docker desktop on macOS for OrbStack.

I really wish Docker didn't take over the industry like it has. In my experience not enough people know how to debug yet another layer of abstraction.

Remove layers, keep things simple.

That being said, it is here to stay. So any alternative tooling that forces Docker to get it's act together is welcome.

I've wanted to migrate multiple times. Unfortunately, it failed on multiple places.

Firstly, podman had a much worse performance compared to docker on my small cloud vps. Can't really go into details though.

Secondly, the development ecosystem isn't really fully there yet. Many tools utilizing Docker via its socket, fail to work reliably with podman. Either because the API differs or because of permission limitations. Sure, the tools could probably work around those limitations, but they haven't and podman isn't a direct 1:1 drop in replacement.

if you mount local path's, it's a pain.

I know a lot of kubernetes fans migrate to podman, but if you use dev stacks.

Use in dev: devcontainer, podman can't replace docker!

Has anyone ported distrobox to MacOS? or know of a project doing that?

I could reverse engineer all the cool user land stuff it does to make things seamless ... but who has the time ;-)

I love podman, and, like others have said here, it does not always work with every container.

I often try to run something using podman, then find strange errors, then switch back to docker. Typically this is with some large container, like gitlab, which probably relies on the entirety of the history of docker and its quirks. When I build something myself, most of the time I can get it working under podman.

This situation where any random container does not work has forced me to spin up a VM under incus and run certain troublesome containers inside that. This isn't optimal, but keeps my sanity. I know incus now permits running docker containers and I wonder if you can swap in podman as a replacement. If I could run both at the same time, that would be magical and solve a lot of problems.

There definitely is no consistency regarding GPU access in the podman and docker commands and that is frustrating.

But, all in all, I would say I do prefer podman over docker and this article is worth reading. Rootless is a big deal.

Tried to migrate (M1 MBP) a couple of times and it wasn't working well resuting in reverting to docker...

I've been on Podman since 2019 since Docker didn't support Cgroups v2 for a very long time.

Could never get rootless to work properly. I wanted to like Podman, but every time I wanted to use it there was some bump in the road that made me give up and use Docker.

To provide 1 contrary opinion to all the others saying they have a problem:

Podman rocks for me!

I find docker hard to use and full of pitfalls and podman isn't any worse. On the plus side, any company I work for doesn't have to worry about licences. Win win!

Yeah I have done this as well.

I write programs that run on the target OS again. It's much easier, turnaround time is much quicker, it's faster. Even battery lasts longer on my laptop. What the hell have we done to ourselves with these numerous layers of abstraction?!?

Podman networking is extremely unreliable. Our company made an effort to switch to get away from Docker Enterprise. We had to kill the effort because multiple people had random disconnects and packet drops with a range of services including K8S, Kafka, and even basic applications, both internal and in host network.

```

> kubectl port-forward svc/argocd-server -n argocd 8080:443

Forwarding from 127.0.0.1:8080 -> 8080

Forwarding from [::1]:8080 -> 8080

Handling connection for 8080

Handling connection for 8080

Handling connection for 8080

E0815 09:12:51.276801 27142 portforward.go:413] an error occurred forwarding 8080 -> 8080: error forwarding port 8080 to pod 87b32b48e6c729565b35ea0cefe9e25d8f0211cbefc0b63579e87a759d14c375, uid : failed to execute portforward in network namespace "/var/run/netns/cni-719d3bfa-0220-e841-bd35-fe159b48f11c": failed to connect to localhost:8080 inside namespace "87b32b48e6c729565b35ea0cefe9e25d8f0211cbefc0b63579e87a759d14c375", IPv4: dial tcp4 127.0.0.1:8080: connect: connection refused IPv6 dial tcp6 [::1]:8080: connect: connection refused

error: lost connection to pod

```

People had other issues also. It looks nice and I would love to use it, but it just currently isn't mature/stable enough.

Whenever I see portmappings I die a little inside. OrbStack makes so much more sense be default

Isn’t Portman ibm?

I tried podman for multiple times. Normal testing & sandox stuff just works and you really can do alias docker=podman. But ass soon as you add nertworking me broke for me. And for me it is really just a tool and I need my tools working. So I switched back.

Recently I did the GitLab Runner migration for a company and switched to rootless docker. Works perfectly, all devs did not notice all there runs now use rootless docker and buildkit for builds. All thanks to rootless kit. No podman problems, more secure and no workflow change needed

i'm the only one that wished docker swarm became the standard instead of k8s?

> If your Docker Compose workflow is overly complex, just convert it to Kubernetes YAML. We all use Kubernetes these days, so why even bother about this?

I find that kubernetes yaml are a lot more complex than docker compose. And while I do, no, not everybody uses kubernetes.

same, not because compose, but because I wanted a software to run containers and docker only provides a solution

Docker swarm is great on single servers. Apparently still no such thing for Podman.

Even if the tech is not top notch, Docker got a few things right on product management.

My favorite part of the blog is how the author lets us know he is pretty young to reference vagrant as old.

Yeah, no, sorry.

Too many problems with things that worked out of the box with docker.

I don't have time to waste on troubleshooting yet another issue that can be solved by simply using the thing that just works.

rootless is not an argument for me, since the hosts are dedicated docker hosts anyway.

I have been running Podman in production for a number of years now, and have been very happy with the results.

Podman pods have been super useful, and the nature of my workload is such that we just run a full pod on every host, so it's actually removed the need for an orchestrator like Kubernetes. I manage everything via Ansible and it has been great.

Don't give iXsystems (TrueNAS) ideas. 3 times was enough.

I also ditched docker when I could. In my experience...

Podman with pods is a better experience than docker-compose. It's easy to interactively create a pod and add containers to it. The containers ports will behave as if they were on the same machine. Then `podman generate kube` and you have a yaml file that you can run with `podman kube play`.

Rootless networking is very slow unless you install `passt`. With Debian, you probably should install every optional package that podman recommends.

The documentation is lacking. Officially, it's mostly man pages, with a few blog posts announcing features, though the posts are often out of date.

Podman with its docker socket is often compatible with Docker. Even docker-compose can (usually) work with podman. I've had a few failures, though.

Gitlab-runner can use podman instead of docker, but in this case the is no network aliases. So it's useless if the runner needs to orchestrate several images (e.g. code and db).

One challenge I have come across is mapping multi-UID containers to a single host user.

By default, root in the container maps to the user running the podman container on the host. Over the years, applications have adopted patterns where containers run as non-root users, for example www-data aka UID 33 (Debian) or just 1000. Those no longer map to your own user on the host, but subordinate IDs. I wish there was an easy way to just say "ALL container UIDs map to single host user". The uidmap and userns options did not work for me (crun has failed executing those containers).

I don’t see the use case for mapping to subordinate IDs. It means those files are orphaned on the host and do not belong to anyone, when used via volume mapping?

I did numerous attempts to switch from docker to podman. Latest one worked, and so far I didn't feel the need to get back to docker. There was only one issue that I had: huge uid didn't work in podman (like 1000000 I think), but I fixed the dockerfile and rest worked fine for me. podman-compose does not work well in my experience, but I don't use it anymore.

Docker daemon had been freaking me out for a while. If it's really so seamless I'll look into migrating.

Still happily using Colima as a Docker Desktop for Mac replacement. It even allows mixed architecture containers in the same compose stack. What's podman gain me besides a half baked Docker compose implementation?

To bikeshed a little, "Why I Ditched Docker for Podman, And Why You Should Too" would be better than the current headline of "Why I Ditched Docker for Podman (And You Should Too)": the "you should too" part is after all the main message of the article, not a side-point.

Tried a couple of times and gave up. Just didn’t work at all for too many containers

I had an issue where docker was not producing repeatable sha's. Somehow a time based metadata was affecting the image sha after every build.

Switching to podman immediately fixed it, never looked back

The out of the box DX on podman needs improvement, the automated image management logic is bad, but besides that it's a pretty good tool.

Sorry, but I tried and just couldn’t get compose and networking to work the way I wanted - as well as permissions, volumes and a lot of other stuff…

I don't know how podman compares to docker in terms of performance, and I do know that rootless containers can be a real pain.

But Docker is simply a non-starter. It's based on a highly privileged daemon with an enormous, hyper-complicated attack surface. It's a fundamentally bad architecture, and as far as I've been able to tell, it also comes from a project that's always shown an "Aw, shucks" attitude toward security. Nobody should be installing that anywhere, not even if there weren't an alternative.

Iv been using podman for around 2 years now without issue. Works great for my use cases.

me: great can target POSIX for stuff

them: not so fast here's glib

me: great can use debian for stuff

them: not so fast, here's rpm

me: great can use docker for "abstracting" over Linux diversity

them: not so fast, here's podman

> I'm old enough to remember when Vagrant looked like a promised land where every development environment would look the same.

Oh no... does this mean I'm old too?!? This feels just like yesterday!

I did the same first, then went with Colima, nowadays with Orbstack. My point is, there are so many great options apart from Docker Desktop

docker works well enough.

podman avoids having to deal with the Purchasing department, but doesn't work great.

would definitely suggest doing docker if you're up to dealing with the purchasing department.

I would love to switch to podman, but rely on docker's credential helpers with gcloud CLI for authentication to pull from Google Artifact Registry on Mac with hyperkit. Last time I tried I couldn't figure out how to do this with podman machine in a way that respected gcloud credentials properly and could only find some hacks that involved passing short term tokens instead of supporting proper refresh flows. Is there a guide how to do that now?

ever try to dev with it on a Mac?

haha.

Nope. No thank you. Not sure if Windows has that issue.

I use both Podman and Docker pretty regularly, and to be honest I don’t see a huge amount of differentiation or practical value in Podman for my day-to-day. It feels like another OCI runtime with some quirks compared to Docker.

One pain point for me is rootless mode: my Podman containers tend to stop randomly for no obvious reason. I tried the recommended “enable user lingering” fix and it didn’t help. I’ve never run into this with Docker.

I get the theoretical advantages, daemonless architecture, better systemd integration, rootless by default, podman generate kube, etc. But if you’re just using containers for development or straightforward deployments, Docker feels smoother and more reliable. Maybe if you’re in a security-sensitive environment or need tighter system integration Podman shines, but for my use cases I’m still not convinced.

Reminder that docker still doesn't support nftables

Does anyone here have more than "initial impressions" of systemd-nspawn? It seems chronically overlooked in these sorts of threads.

I am still on an x86 Mac.

When Docker Desktop changed licensing I tried to switch to Podman and it was a disaster, Podman was brand new and despite many blog posts that claimed it was the perfect replacement it did not work for me, and I have very simple requirements. So I ended up using Rancher Desktop instead, which was also very unstable but better.

Fast forward 1 year, Rancher was pretty good and Podman still did not work reliably on my mac.

Fast forward another year or so and I switched to colima.

I tried podman last time about one year ago and I still had issues on my old mac. So far colima has been good enough for my needs although at least two times a brew update broke colima and I had to reinstall from scratch.

I switched about 3 weeks ago. I’m not a power user of either. But I don’t smell the odor of coming enshitification anymore either. Podman doesn’t feel like a platform or an ecosystem. It’s just a tool.

Same here. Podman Desktop is great. podman/buildah and the whole ecosystem is much more reliable on the server as well.

> Privileged ports in rootless mode not working? Good! That's security working as intended. A reverse proxy setup is a better architecture anyway.

So, how are you supposed to run the proxy inside the container? Traefik for example? Genuinely curious.

Docker is failing in that trap where they feel the need to try (and mostly fail so far) to add net-new value streams (e.g. mcp catalogue, a bunch of other stuff i immediately turned off that last time i installed it) rather than focus on the core value.

It's not the case that they've maximised the utility of the core build / publish container nor the acquire / run container workflows and but they're prioritising fluff around the edges of the core problem.

Podman for its various issues is a whole lot more focussed.

I wonder if we'll see Podman running on Illumos at some point. SmartOS does currently support running Dockerized programs if I remember correctly.

Podman is really painful if you do anything interesting inside of a container, it's great and simple if all you're doing is running nginx or a scripting language runtime or something in a container, but for folks who write actual software that gets compiled to target a system and utilizes syscalls, running in Podman is a pain in the ass unless you disable most of the "benefits". Docker on the other hand pretty much just works.

My go service in podman container requires a container restart after waking up. That's the only downside I've felt after switching from docker to podman.

Podman compose isn't compatible with Docker compose, end of story.

I started working at Red Hat this past year, so obviously all Podman, all day long. It's a super easy switch. I moved to using Containerfiles in my LinkedIn courses as well, if for no other reason than it having a much more "open" naming convention!

Rootless works great, though there are some (many) images that will need to be tweaked out of the box.

Daemonless works great as well. You can still mount podman.sock like you can with Docker's docker.sock, but systemd handles dynamically generating the UNIX socket on connect() which is a much better solution than having the socket live persistently.

The only thing that I prefer Docker for is Compose. Podman has podman-compose, which works well and is much leaner than the incumbent, but it's kind of a reverse-engineered version of Docker Compose that doesn't support the full spec. (I had issues with service conditions, for example).

OP fails to understand that in practice people use Docker Desktop on their laptop and deploy to a container platform or Kubernetes cluster that uses ContainerD. So all of these so-called issues are moot. Further, Docker Inc (and the people behind Docker CLI, Compose etc), have way better UX taste and care for DX than their competitors which matters a lot in local development.

5 years ahead of you on that.

Interesting how slowly this advice has bubbled up. This is another software example where people didn’t care about resource usage and were “fine” with the Docker daemon.

Podman has full compatibility and same command syntax with docker. Perfect cockpit and kubernetes co existence. Daemonless, rootless and open source are killer features and reasons to switch.

It’s gotten a lot better on MacOS as the virtualization framework had virtio functionality added to it.

I have used Podman before, and it just works. However, for the past 8 months, I've been using orbstack, and I can confidently say that it's much better.

Any alternative for Windows containers?

On the topic of ditching Docker, has anyone else created a custom test harness with QEMU? I feel like I'm the only person doing it this way. QEMU's target userbase is emulators in general, which is a much broader audience with way more development effort going into it, therefore I don't think it can ever go "out of fashion" or get hijacked by perverse corporate interests like Docker can. Podman seems to have the same vulnerability.

I've been on Podman for about two years now. My coworkers and the entire company codebase / scripts etc are on Docker.

Podman has a number of caveats that make it not a drop in replacement out of the box, but they are mostly few and far between. Once you've learned to recognize a handful of common issues, it's quite simple to migrate.

This might sound like me trying to explain away some of the shortcomings of podman, but honestly, from my point of view, podman does it better, and the workarounds and fixes I make to our scripts and code for podman are backwards compatible and I view them as improvements.

Orbstack if you have a Mac.

The main issue is podman support on Ubuntu. Ubuntu ships outdated podman versions that don't work out of the box. So I use podman v5, GitHub actions uses podman v3, and my coworkers on Ubuntu use docker. So now my script must work with old podman, recent podman and docker

I'm interested in using podman for my homeserver because of the deamonless and rootlessnes nature, but I haven't found a convenient replacement for docker compose.

On my dev machine I do `docker compose up -d --build` in the directory of the Dockerfile, and it builds, uploads, and restarts the service on the server. In the podman world you're supposed to use Quadlets, which can be rsynced to the server, but I haven't found something simple for the build-step that doesn't involve an external registry or manually transferring the image.

What's the end-to-end solution for this?

I've been dealing with setting up Podman for work over the last week or so, and I wouldn't wish that on my worst enemy.

If you use rootless Podman on a Redhat-derived distribution (which means Selinux), along with a non-root user in your container itself, you're in for a world of pain.

I use both Podman and Docker at work, specifically I had to use the same docker images / container setup in a RHEL deployment and it worked great.

A huge pain was when I used "podman-compose" with a custom podman system storage location, two times it ended corrupted when doing an "up" and I had to completely scratch my podman system storage.

I must have missed something though ...

I like Podman with it's API for hosting (no k8s) but I reverted back to Docker for local because of docker-compose incompatibilities. This was a year or more ago so it may not still be an issue.

Rancher Desktop was far easier to get up and running on macOS than podman for me. Drop in compatible with docker compose syntax too.

What is the current way of running a dokcer container as a systemd service? Is it podman?

There can be interesting differences, I'm not sure which of them still apply but some I ran into:

- podman having a more consistent CLI API/more parameters (but I think docker did at least partially catch up)

- user-ns container allow mounting the context instead of copying it, this means that if you somehow end up with a huge build context user-ns build can be _way_ faster then "classical" docker builds (might also apply to rootless docker, idk.). We ran into that when that one person in the team using Mac+Docker asked if we can do something about the unbearable slow docker build times (no one else on the team experienced :/)

- docker implicitly always has the docker Hub as configured as source which resolves "unqualified", this might not be true for your podman default setup so some scripts etc. which should work with both might fail (but it's easy to fix, preferable always qualify your images as there are increasingly more image hosts, in worst add docker hub in the config file).

- "podman compose" supports some less feature, this might seem like a huge issue but compose doesn't seem the best choice for deploying software and if I look how it turned out in dev setups the moment things became larger/more complicated I came to the conclusion that docker/podman compose is one of the easy to start with then get trapped in a high complexity/maintenance cost "bad" corner technologies. But I'm still looking for alternatives.

- podman sometimes missing some resource management features, but also docker sometimes does have differences in how it effectively enforces them not just between version but also with the same version between OSes, this had lead to issues before where docker-rootless kills a container and docker on Mac doesn't because on Mac it didn't notice spikes in resource usage (in that specific case).

In the beginning, Docker DID have "standalone mode" where it would launch just one container as a child process. That was actually an easier way to manage the mounts and cgroups necessary to stand up a container. I made a ticket to bring it back after they removed it, and it was closed with a wontfix. The cynic in me says it was done more for commercial reasons (they wanted a more full featured daemon on the server doing things they could charge for) as opposed to just being a little shim that just did one thing.

As bad as the horror stories about switching might be, I don't see how docker can remain as is. The level of vulnerability it causes seems like a fundamental flaw. I assume docker itself hasn't changed because it took off so fast and now it'd be breaking changes galore, but eventually everyone is going to have to pull the trigger.

As much as I’d like to switch to Podman, I’m using Vite inside a container and need to monitor file changes on the host folder. It doesn’t detect them, and polling isn’t ideal. Does anyone have tips I might not know about yet?

But Apple Container is another option with direct IP network support on macOS Tahoe, not possible with macOS Sequoia.

FreeBSD jails ftw!

In addition to rootless podman / root docker there are some other options:

- rootless docker, works fine, not fully sure why it's not the default by now (I do have issues form time to time but I had the same issues with root docker)

- rootfull podman

- running docker/podman daemon as a different and non root user (but have fun trying to mount anything !?)

> With Podman, even if someone somehow escalates privileges inside a container to root level, they're still just an unprivileged user on the actual host.

As much as I like Podman (and I really do), Docker has supported rootless mode for a long time and it's not any harder to set up than Podman.

> Use podman-compose as a drop-in replacement

Oh, if only it were a drop-in replacement. There are so many ways in which it is not exactly compatible with docker-compose, especially when it comes to the network setup. I have wasted more hours on this than I can count.

I certainly like demon-less architecture; much simpler and there are less potential security issues and no single point of failure.

The one thing I don't necessarily agree:

"Privileged ports in rootless mode not working? Good! That's security working as intended. A reverse proxy setup is a better architecture anyway."

I usually use Ngix as a reverse proxy - why not have it set up in the exact same way as the rest of your apps? That's a simplicity advantage. So with Podman, I would just run this one exact container in root mode - that's still better than all of them, but quite.

I am not a fan of docker-compose - a classic example of a tool trying to do too much for me, so the lack of something similar in Podman is not a drawback for me :)

Not sure about tooling around logs and monitoring though - there is plenty for Docker.

We are are migrating back to Docker org-wide after 5 months on Podman.

I switched for local development work a couple of years back and can count on no fingers the number of times I thought about switching back. It let me stop thinking about the Docker Mac high CPU issue which was open for years with no progress, too.

I may be the odd man out, but after getting unbelievably stressed out by containers, k8s, etc., I couldn't believe how zen just spinning up a new VPS and bootstrapping it with a bash script was. That combined with systemd scripts can get you relatively far without all of the (cognitive) overhead.

The best part? Whenever there's an "uh oh," you just SSH in to a box, patch it, and carry on about your business.

This is a hell of a lot like saying you ditched driving cars to ride a monorail with only two stops in the wrong neighborhood. You’re comparing apples and oranges and selectively leaving out info to highlight that.

Rootless podman in combination with systemd quadlet works great for me. I host all my personal services like that. Having containers integrated directly into systemd makes mapping out dependencies between mounts and other non containerized services much more reliable and easier.

Man I’m tired

I use podman since I can simply enable it using home-manager:

`services.podman.enable`

This also means that it's in the reproducible part of my setup which is a bonus.

You are going to have to pry Docker from my cold dead hands.

Podman is a failed reverse-engineering of cherry-picked so-called "good" parts of Docker.

I'm probably going to finally give podman a try, but apart from the security advantages of daemonless, I pretty much have all these features solved on my Docker hosts already. For home/lab workloads I define one docker compose project in a directory, using local path mounts for directories. Then I manually define a systemd service per docker compose project, which just runs "docker compose up -d <dir>" on start, and the opposite on stop. The hundreds of containers I run at home have higher uptime than the thousands of containers in the orchestration platform I run at work has.

Does the "podman generate kube" command just define pods, or does it support other K8s components such as services and ingresses?

Is there anything like Skaffold that works with Podman?

what dot mee

I wish podman was more common in documentation. Want to use podman with your CI platform, it will probably work with socket compatibility but good luck finding instructions and anyone know if it’s tested. How about using some service with podman? Yeah the container is the same, but all the instructions or docker this or docker that, and god help you if you if they used networking or compose.

I prefer to use podman if it’s available on my system but it still hasn’t hit the critical mass needed for it to be targeted and that’s a shame.

Also is there something like a dockerfile for buildah? I’ve tried a few times to understand how to use buildah and just fall back on a dockerfile because I can’t seem to wrap my head around how to put it into something IAC like.

> just convert it to Kubernetes YAML

Either you haven't worked on k8s at scale or you're seriously suggesting an overly complex solution to elegant docker-compose. Docker compose exists because of it's simplicity and stability. I have also started using swarm and it doesn't get the recognition it deserves for the most easy-to-manage orchestration. Podman doesn't have such a thing. And yes, podman-compose is absolute garbage

Author lists vulnerabilities of Docker, but it doesn't mean podman is more secure. Maybe it's more obscure so it is not as attractive for hackers as a target.

I tried to use podman, but that was largely a waste of time and I reverted to Docker. I don't have time going through docs to figure out why something that supposed to work is not working.

How does Podman work with Alpine? Lots of talk of Ubuntu and Debian below.

We did the same. Switching was a cinch honestly - the only thing that screwed me up was some dumb page that returned a bunch of nonsense I was supposed to do to my docker-compose.yml file to make it more compatible with podman-compose. I spent a couple hours trying to figure out why things weren't working, until I finally rolled back all the stupid suggested changes, and my app fired right up.

The only impactful difference I've noticed so far is that the company is moving to an artifact repository that requires authentication, and mounting secrets using --mount doesn't support the env= parameter -- that's really it.

I treat podman like I did docker all day long and it works great.

Back in 2001/2002, I was charged with building a WiFi hotspot box. I was a fan of OpenBSD and wanted to slim down our deployment, which was running on Python, to avoid having to copy a ton of unnecessary files to the destination systems. I also wanted to avoid dependency-hell. Naturally, I turned to `chroot` and the jails concept.

My deployment code worked by running the software outside of the jail environment and monitoring the running processes using `ptrace` to see what files it was trying to open. The `ptrace` output generated a list of dependencies, which could then be copied to create a deployment package.

This worked brilliantly and kept our deployments small and immutable and somewhat immune to attack -- not that being attacked was a huge concern in 2001 as it is today. When Docker came along, I couldn't help but recall that early work and wonder whether anyone has done a similar thing to monitor file usage within Docker containers and trim them down to size after observing actual use.

In my experience Podman is better but always ends up having some wonky bug (like, the other day, secrets didn't mount anymore during builds). Rootless, daemonless is great but it's basically bound to have some extra tinkering required compared to "a stupid daemon running as root"

So did I ... But I've started writing my applications to run locally, in a WASM runtime and in a container so most of my debug and test occurs right on my OS.

The fact that people keep conflating docker desktop and the docker engine is crazy.

We were using podman at our company, and it was great for a while but we recently migrated to orb.

The UX with orb is just much easier and the small gotchas between docker/podman started to add up. Especially with buildkit issues we had run into and things like using a remote buildkit instance (which we now use), was not supported well enough.

I mean I get the overall benefits of having rootless and all, but the premise of security in this article is a bit misleading.

Obviously having a daemon running as root is larger attack surface than a program running as the user.

Going to the github.com/containers/podman/releases, the latest release is actually addressing a security risk that involves overwriting files of the host.

    # v5.6.1 (Latest)
    ## Security
    - This release addresses CVE-2025-9566, where Kubernetes YAML run by podman play kube containing ConfigMap and Secret volumes can use crafted symlinks to overwrite content on the host.

As always, the most secure computer is the one that is unplugged & turned off.

I ditched containers. After a few years it seemed like one of those things that FAANGs use because they need it, while most others are using it just because the FAANGs do.

I'm sure I've spent more time writing and troubleshooting YAML files than I ever did just installing stuff on vm's.