Live data from Hacker News

Podman v6.0.0

blog.podman.io

171–180 of 269 posts

Re: Podman v6.0.0

#171
post #73

Earlier quoted context omitted.

I’d wager it’s mainly just that deployment is mildly more annoying and requires more disparate steps. Especially if you want to go rootless (and you should). For someone that isn’t “Linux first” (like a baby developer learning to containerize their apps), the idea of dealing with systemd unit files or kublet configs, and having to created dedicated local service accounts (and remembering to enable linger) is somewhat…

It's not just mildly annoying, it completely ruins a great thing. Docker Compose is to stacks what Dockerfiles are to a single application. Podmans solution is to not commit to compose, but instead to create a bespoke mechanism involving a bunch of tiny files, all of which is insanely system (linux) specific, and therefore completely non-portable. I genuinely don't understand how someone can see the value of Docker,…

Depends on your point of view.

It can be argued that it’s Docker that is reinventing the wheel and doing its own bespoke process management, journal management etc when all of these are solved problems on Linux. Podman is instead reusing the platform which exists, Quadlets are just reusing systemd, so as a sysadmin I can manage, control and monitor docker containers using the same standard tooling that I already use to manage, control and monitor all the other processes which are running on the system.

Architecturally I find the above argument attractive. The problem is chronology. Docker and docker compose came before systems was ubiquitous and long before Quadlets, so it’s natural to think of Quadlets as reinventing the wheel.

Personally I wish docker had not rejected composition/integration around systemd. Would have made everyone’s job a lot easier in the long term.

Re: Podman v6.0.0

#172
post #4

No idea why Docker is still so much more popular than Podman. Podman is obviously the better implementation. The new network stuff is a welcome improvement.

One answer is ECR/ECS/Fargate ie AWS. You’re not gonna split the ops stories between local and remote.

Re: Podman v6.0.0

#173
post #73

Earlier quoted context omitted.

I’d wager it’s mainly just that deployment is mildly more annoying and requires more disparate steps. Especially if you want to go rootless (and you should). For someone that isn’t “Linux first” (like a baby developer learning to containerize their apps), the idea of dealing with systemd unit files or kublet configs, and having to created dedicated local service accounts (and remembering to enable linger) is somewhat…

It's not just mildly annoying, it completely ruins a great thing. Docker Compose is to stacks what Dockerfiles are to a single application. Podmans solution is to not commit to compose, but instead to create a bespoke mechanism involving a bunch of tiny files, all of which is insanely system (linux) specific, and therefore completely non-portable. I genuinely don't understand how someone can see the value of Docker,…

> Docker Compose is to stacks what Dockerfiles are to a single application. Podmans solution is to not commit to compose

This isn't (completely) true. I found podman-compose to be a more or less drop-in replacement for docker-compose. I know that in the past support was patchy, but things are rather good now.

Re: Podman v6.0.0

#174

Earlier quoted context omitted.

Can you elaborate on SELinux? It affected me too but I just had to add :Z to my mount argument. Curious about whether there's further impact I'm unaware of.

This is my biggest gripe. If you're using docker-compose.yml on a team that mostly uses docker, you can't use use that same docker-compose.yml with rootless podman. Any volume mounts that need to be writable (like the app, or databases) need to have `:X` or `:x` as a suffix, or podman won't set the SELinux label correctly to make it writable. But if you add those, docker blows up because it doesn't understand them.

I've recently been using podman on SELinux... :Z and :z seem to work fine across both podman and docker for writeable volumes. Am I missing something?

Re: Podman v6.0.0

#175
post #4

No idea why Docker is still so much more popular than Podman. Podman is obviously the better implementation. The new network stuff is a welcome improvement.

I went all in on podman compose last year but went all back because off constant permission errors. I thought it was going to be better than docker because I run the containers as a user… but man the amount of time I wasted on files that either I or the container itself or some other container couldn’t read… With docker I felt that stuff just works. And then there are the extra steps: Enable user lingering, make a sy…

> I went all in on podman compose last year but went all back because off constant permission errors.

The issue is that "ease of use" and "it just works" come at the expensive of security and the principle of least privilege. Docker makes things easy by running a daemon as root. Rootless Podman forces you to think about permissions and does not stab you in the back by overwriting your firewall rules.

Re: Podman v6.0.0

#176
post #164

Earlier quoted context omitted.

> As long as they refuse to support installing on Ubuntu (and other popular distros), without relying on the distro repos which are always out of date, they will continue to lose to Docker. Your needs are incomprehensible to me: that is exactly why I use podman: a predictable version of it is in my distro's repos. I go to docker.com and how do I even install the thing? What's "docker sandboxes"? Get the latest versio…

I run Ubuntu 24.04 on my laptop and servers. The Podman version is 4.9.3. It may be incompressible to you, but I'm not alone in thinking it's a problem: https://github.com/podman-container-tools/podman/issues/2707...

I'm sorry this is happening to you. I'm on the team that helped bring podman into the CNCF and I worked on ubuntu for over a decade, this isn't a technical problem this is a business one.

Podman is in universe, so Canonical doesn't care unless you pay. Fair enough, good engineers cost money. RH isn't going to pay.

Podman engineers would love to be in Ubuntu, the Red Hat engineers would love to directly upload into Universe. Everything in this thread makes sense, it's a matter of who wants to pay for it. End users have been asking for this for years.

The engineers don't make the decisions. Canonical doesn't want to pay, Red Hat doesn't want to pay. Users stuck in the middle.

I get podman from brew even on Linux because the idea that vendors fighting over uploading tarballs to a server is stupid. Fuck distros.

Re: Podman v6.0.0

#177
post #164

Earlier quoted context omitted.

> As long as they refuse to support installing on Ubuntu (and other popular distros), without relying on the distro repos which are always out of date, they will continue to lose to Docker. Your needs are incomprehensible to me: that is exactly why I use podman: a predictable version of it is in my distro's repos. I go to docker.com and how do I even install the thing? What's "docker sandboxes"? Get the latest versio…

I run Ubuntu 24.04 on my laptop and servers. The Podman version is 4.9.3. It may be incompressible to you, but I'm not alone in thinking it's a problem: https://github.com/podman-container-tools/podman/issues/2707...

And that issue shows the problem with OSS.

Nothing is ever good enough.

> Please report this to your distribution

And the reply:

> but you could create your own .deb packages for each github release, which can be installed much quicker than downloading and compiling source code and all its dependencies.

This is why OSS maintainers have burn out. Always wanting more and more. Not even the source code is good enough.

Re: Podman v6.0.0

#178

Earlier quoted context omitted.

I run Ubuntu 24.04 on my laptop and servers. The Podman version is 4.9.3. It may be incompressible to you, but I'm not alone in thinking it's a problem: https://github.com/podman-container-tools/podman/issues/2707...

I'm sorry this is happening to you. I'm on the team that helped bring podman into the CNCF and I worked on ubuntu for over a decade, this isn't a technical problem this is a business one. Podman is in universe, so Canonical doesn't care unless you pay. Fair enough, good engineers cost money. RH isn't going to pay. Podman engineers would love to be in Ubuntu, the Red Hat engineers would love to directly upload into Un…

I'm confused, the latest LTS version of Ubuntu is 26.04 (released on 2026/04/23) and has Podman v5.7.0 (released on 2025/11/11). [1]

If they're on a 24.04 LTS release is there any reason they would be on a newer version of Podman (without jumping through hoops)? Ubuntu 24.04LTS released on 2024/04/25 and the Debian Import Freeze was on 2024/02/29.

The bleeding edge Podman release at that time was a pre-release v5.0.0-RC3 (2024/02/22) and the latest actual release was v4.9.3 (2024/02/13). That's the version Ubuntu 24.04LTS has. [2][3][4]

So aren't they on the exact version of Podman they're supposed to be on for the operating system version they're running?

[1] https://packages.ubuntu.com/resolute/podman

[2] https://packages.ubuntu.com/noble/podman

[3] https://documentation.ubuntu.com/release-notes/24.04/schedul...

[4] https://github.com/podman-container-tools/podman/releases?pa...

Re: Podman v6.0.0

#179
post #178

Earlier quoted context omitted.

I'm sorry this is happening to you. I'm on the team that helped bring podman into the CNCF and I worked on ubuntu for over a decade, this isn't a technical problem this is a business one. Podman is in universe, so Canonical doesn't care unless you pay. Fair enough, good engineers cost money. RH isn't going to pay. Podman engineers would love to be in Ubuntu, the Red Hat engineers would love to directly upload into Un…

I'm confused, the latest LTS version of Ubuntu is 26.04 (released on 2026/04/23) and has Podman v5.7.0 (released on 2025/11/11). [1] If they're on a 24.04 LTS release is there any reason they would be on a newer version of Podman (without jumping through hoops)? Ubuntu 24.04LTS released on 2024/04/25 and the Debian Import Freeze was on 2024/02/29. The bleeding edge Podman release at that time was a pre-release v5.0.0…

> 5.7.0+ds2-3build1

No thanks I'll get it from podman.

Re: Podman v6.0.0

#180
I wanted to love Podman, but unfortunately, in my current employer's we have macOS machines.

I had issues like when Podman randomly stopped responding and I had to "kill" the podman machine more than once or some container randomly built differently or failed (due to architecture diff).

This was not the case with Orbstack, but they are license-only, closed source and macOS only oriented.

I wish I could find a consistently good container management system that is multiplatform, ideally open source as well.

Having said this, I think I will try Podman (6.0) again, in macOS :)

Post reply on HN