It might be because an intern wrote it? I read it myself and I definitely think it’s not an easy read, borderline not make any sense at all, but I don’t think it’s AI because as crazy as it may be, I think an AI would have done a better job at this.
Having a daemon is inherently faster, period. I was disappointed by Podman because almost all operations including `podman ps`, `podman run` were slower than their Docker counterparts. After many releases Podman got faster, but still not on a par with Docker.
1. You need a watchdog process anyways to handle stdout/stderr processing (to not block those pipes), namespace setup and teardown, etc. Why not have 1 daemon, rather than 1 daemon per container?
2. You need root to setup networking and various security controls (seccomp etc). Having a daemon lets an unprivileged user delegate to a privileged daemon. This was especially important in the early days when rootless containers and slipr4netns didn't exist or were immature.
3. You need to avoid contention between two "docker run" commands, such as avoiding downloading the same image twice, or running the same name twice, or so on. In-memory locks are really easy to get right and cheap
4. You need to be able to efficiently gather state for things like "docker ps" etc to work. A daemon lets you cache a lot of information very easily.
5. A daemon lets you provide a clean rest API to other components that want to "exec" or "list containers" or so on. Without a daemon, your API is just "exec this command, use stderr/stdout", which is worse, right? An API also helps immensely with "docker desktop" like stuff, where you want to run a client on the host, and run containers on a linux VM. I guess the daemonless answer there is "exec over ssh", which is slow, and also eww.
So, how does podman solve these? I'll number them the same:
1. Watchdog process per container (N daemons) plus centralized systemd daemon if you want to background a container, or for restarts to actually work.
2. slipr4netns, which is buggy and still less featureful than docker networking. It also just doesn't implement various security features that would require a privileged component to setup, and makes it harder to run root-ful containers.
3. Contention is avoided with an incredibly over-engineered filesystem locking scheme that has had a long history of deadlocks and bugs.
4. Again, the filesystem locking scheme and api. It's slow, can't cache well, and also has a long history of deadlocks
5. The API for podman is uh... "run a daemon" https://docs.podman.io/en/latest/markdown/podman-system-serv... lol. Except how does another app know if you ran the API because it's optional? This makes it so other applications that want to integrate with podman have to say "use podman and also run the podman daemon if you're not, and if you forget we won't auto-detect podman sorry".
In general, podman's answer to all the problems the daemon solves seem materially worse, and more overengineered. Except to the API bit, where their answer is to post all over the place "podman is daemonless", but then to package a daemon, which is just funny.
This is good. I felt really annoyed that Ubuntu versions of podman lagged significantly and podman's official stance is basically just "deal with it" while they provide support for every other platform.
I don’t think I understand the author completely. First, she mentions that Podman is not a replacement for Docker but then mentions multiple reasons why Podman is better than Docker. I.e. why you should replace Docker with Podman.
What did the author mean by Podman is not a replacement of Docker?
I tried Podman on 2 MacBook Pros: my personal one (Intel) and my work one (M1) and it basically doesn’t work well at all.
Podman Desktop simply doesn’t work, on first run it loops forever on initializing stuff (I guess it tries to create the Podman machine but fails? No idea because it doesn’t say what’s wrong, nor where to look). So I tried Podman bare without Podman desktop and it’s not a lot better, the machine starts fine and I can run containers, but every time my computer wakes up from hibernate, the containers and the machine are stuck. I have to recreate the whole Podman machine from scratch.
I loved the idea of rootless but it doesn’t work on Mac. And I won’t believe I’m the only person having the exact same set of issues on 2 different MacBooks
These types of papercuts (see other comments on how podman-compose and any sort of custom networking have issues, too) are why I have mostly avoided Podman so far. I find myself just using Docker rootless on Linux workstations and the Docker Engine on servers. On MacOS, I use Colima and it has worked well for me.
> I loved the idea of rootless but it doesn't work on Mac
One clarification I think is worth making in case you weren't aware is that the "rootless" approach isn't really a factor for any Linux container runtime on MacOS since all the container solutions on MacOS run in a VM (since Linux containers rely on Linux kernel features). I.E. Docker Desktop, Podman Desktop, etc. can't run as root on MacOS because they rely on a user-level Linux VM.
You are not - it is basically non-functional on Mac. I try to stick with it but the reliability of Podman Desktop on Mac is awful - it can’t be doing RedHat’s brand any good releasing and promoting something so poor.
I've tried Podman for a few weeks, and I have to say that first experience is fine, I get that there are some differences in the setup. Aaaand then you come across all sorts of the small and medium cross-incompatibilities (flags, parameter handling, different syntax parsing, drivers..), long standing bugs, Podman Compose is at least subjectively poorly supported/aims at compatibility at all, the list goes on. Docker itself isn't perfect, but it's totally not such a mess.
I came accross a lot of such info from redhat. And I tried podman which is not bad because my scenario was not complicated. But days before, I tried podman-compose which behaved so poor. That's a pitty. After years, podman's ecosystem is so poor. I don't want to be trapped by sorts of small/hidden pitfalls. I have to switch back docker then. The quality prevails, not the advertisement. PS: I did not read the passage. The title is enough.
I started using docker a bit late, only about 3 years ago. My big question is if it is common knowledge that Docker Desktop creates a separate VM in which one's Docker Engine runs, not your host running Docker, but that VM inside your host. That separate VM indirection does not appear to be common knowledge, especially for 3rd party developers, because utilities that are supposed to work with Docker only work without Docker Desktop, or are unaware of Docker Desktop's VM and when installed claim there is no Docker on the host. It's really messed up, and as I tried to figure out what was going on I find nobody recognizes this gargantuan difference between these implementations with and without the "desktop" Docker is internally significantly different, requiring completely different runtime configurations for 3rd party integration.
It has an annoying table of contents system that seems to move you to new urls constantly as you scroll up and down, so back just takes you to different parts of the page for a while till you finally leave.
I'm surprised to see RedHat thinking that programmers will prefer a desktop GUI interface to CLI for operations like starting containers. I thought that thinking had died out 20 years ago and that even Java and Windows people understood that it wasn't what programmers wanted.
I'll bite. I'm assuming you're talking about RH removing source availability for RHEL[0]? If not, would love to be informed on the licensing "shxt show" you're referring to.
Some background: I avoid most of the Enterprise Linux ecosystem (CentOS, RHEL, AlmaLinux, etc.) as my mentality to sysadmin is often quite different than the average RHEL lover. I run NixOS everywhere and supplement with Arch Linux or Ubuntu when I can't use NixOS. So I am in no way a part of the target demographic of RHEL or derivatives.
But, I actually agree with Red Hat's view on the RHEL clones[1]: they should start using CentOS Stream as their upstream base. CentOS Stream is upstream of RHEL, so if the RHEL-compatible distros start snapshotting from CentOS Stream, then all of the Enterprise Linux ecosystem will benefit from bug-fixes, improvements, etc. that they all contribute into CentOS Stream. Unfortunately, for the RHEL-clones, if they adopt this approach they wouldn't have bug-for-bug compatibility with major RHEL releases, and they would have to do more work in making an LTS off of CentOS Stream. But, everyone benefits (theoretically) in contributing to the same upstream codebase -- and I can't think of many instances where an application that works on RHEL wouldn't work on CentOS Stream or a downstream derivative.
AlmaLinux has chosen to rebase off of CentOS Stream[2] and I think it's the right choice. Rocky Linux has chosen to try to workaround Red Hat's removal of source availability by relying on loopholes to obtain RHEL source code via UBI containers and cloud images[3]. I can't imagine this (seemingly fragile) approach being sustainable and it feels counterintuitive to continue building a distro based on the work of a company whose mentality that you fundamentally disagree with.
Long-winded response, but I guess I don't love the FUD surrounding Red Hat. Red Hat's work benefits me as a Linux user with tooling like Network Manager, systemd and GNOME. I don't think Linux would be as serious of a contender in certain spheres without Red Hat's open source work that the entire Linux ecosystem benefits from.
I've been having an ok time with Rancher Desktop, I stopped using Docker Desktop on Windows after they forced me to update to a known broken build with no way to go back (unless I paid for their enterprise version)
Seemed great when I first tried it, but I ran into inconveniences I wasn't willing to put up with (can't remember exactly what they were, but I think all involved pulling from registries).
Colima on the other hand, is install-and-forget (so much so that I had to look up what it was called again). It uses Lima, which means you can do more with it it if you want.
I tried using Podman for about 4 or 5 months on my M1 Mac, but eventually just gave up in frustration. I'm not doing anything too crazy, just running Minikube for some local development, but it just isn't stable enough and requires a lot of digging into threads to find the workarounds or the proper config.
I was wasting more and more time on it. It was constantly crashing/hanging so one day I just said fuck it and switched back to Docker Desktop, which not only worked better than when I switched but seems to have improved quite a lot in the intervening time as well.
It works well, but I found I had to configure several items inside the VM to get it to work within our corporate environment. Timezones, ntpd, proxy, and arm64/amd64 cross platform all needed me to tweak some stuff. But that was quite a while ago and may be fixed now.
Colima on the other hand works pretty much seamlessly, but really works best on macOS Ventura because you can enable vz virtualization.
Edited to add: colima works seamlessly on the command line. So if you're command-line-averse, you'll need to learn some new commands and things won't be as convenient. I haven't tried rancher desktop yet.
I wanted to try a while ago so I downloaded Podman Desktop, but I couldn't get past the initial setup due to issues in the desktop app. I was able to reproduce this on two or three Macs, can't recall exactly.
Not podman but using rancher desktop and it has either nerdctl + containerd or docker and dockerd options and I have been using it a month without issue replacing docker desktop. The kubernetes options work well too
Just joined a team and received an M1 Pro laptop but licensed docker isn't in the budget... tl;dr a bit early to tell, but I think it works.
podman-desktop is pretty rough, but it gave me enough confidence to start using podman generally. podman-mac-helper solved a few docker compatibility problems I had in previous attempts in 2021 and 2022.
It seems like my problems getting started with podman just last week wete mainly due to the abundance of already outdated tutorials. Maybe those who are more active in this space can weigh-in, but fixes and common work arounds documented as recently as 6 months ago aren't necessary an longer? For me, podman works without nearly as much fuss as I remember.
It doesn't work as a 100% replacement but I'd really like to switch. They need to work on better docker compose compatibility. Anything with custom network settings and it pukes.
Far from “shiny new”, but at this time the pace of development is such that there doesn’t exist a stable version that accepts bugfixes only, make of it what you will.
As a development tool it’s awesome, and having no centralized daemon is sure a boon.
[+] [-] Hippocrates|2 years ago|reply
[+] [-] skilled|2 years ago|reply
[+] [-] stabbles|2 years ago|reply
[+] [-] xpressvideoz|2 years ago|reply
[+] [-] TheDong|2 years ago|reply
1. You need a watchdog process anyways to handle stdout/stderr processing (to not block those pipes), namespace setup and teardown, etc. Why not have 1 daemon, rather than 1 daemon per container?
2. You need root to setup networking and various security controls (seccomp etc). Having a daemon lets an unprivileged user delegate to a privileged daemon. This was especially important in the early days when rootless containers and slipr4netns didn't exist or were immature.
3. You need to avoid contention between two "docker run" commands, such as avoiding downloading the same image twice, or running the same name twice, or so on. In-memory locks are really easy to get right and cheap
4. You need to be able to efficiently gather state for things like "docker ps" etc to work. A daemon lets you cache a lot of information very easily.
5. A daemon lets you provide a clean rest API to other components that want to "exec" or "list containers" or so on. Without a daemon, your API is just "exec this command, use stderr/stdout", which is worse, right? An API also helps immensely with "docker desktop" like stuff, where you want to run a client on the host, and run containers on a linux VM. I guess the daemonless answer there is "exec over ssh", which is slow, and also eww.
So, how does podman solve these? I'll number them the same:
1. Watchdog process per container (N daemons) plus centralized systemd daemon if you want to background a container, or for restarts to actually work.
2. slipr4netns, which is buggy and still less featureful than docker networking. It also just doesn't implement various security features that would require a privileged component to setup, and makes it harder to run root-ful containers.
3. Contention is avoided with an incredibly over-engineered filesystem locking scheme that has had a long history of deadlocks and bugs.
4. Again, the filesystem locking scheme and api. It's slow, can't cache well, and also has a long history of deadlocks
5. The API for podman is uh... "run a daemon" https://docs.podman.io/en/latest/markdown/podman-system-serv... lol. Except how does another app know if you ran the API because it's optional? This makes it so other applications that want to integrate with podman have to say "use podman and also run the podman daemon if you're not, and if you forget we won't auto-detect podman sorry".
In general, podman's answer to all the problems the daemon solves seem materially worse, and more overengineered. Except to the API bit, where their answer is to post all over the place "podman is daemonless", but then to package a daemon, which is just funny.
[+] [-] jackweirdy|2 years ago|reply
GitHub actions auto build new version releases for me so major versions become available as soon as they are released and I click the button
[+] [-] pydry|2 years ago|reply
[+] [-] Zariff|2 years ago|reply
What did the author mean by Podman is not a replacement of Docker?
[+] [-] brazzy|2 years ago|reply
It works differently, and (in her opinion) in some ways better.
But you will likely have to change your workflow to use it.
[+] [-] thiht|2 years ago|reply
Podman Desktop simply doesn’t work, on first run it loops forever on initializing stuff (I guess it tries to create the Podman machine but fails? No idea because it doesn’t say what’s wrong, nor where to look). So I tried Podman bare without Podman desktop and it’s not a lot better, the machine starts fine and I can run containers, but every time my computer wakes up from hibernate, the containers and the machine are stuck. I have to recreate the whole Podman machine from scratch.
I loved the idea of rootless but it doesn’t work on Mac. And I won’t believe I’m the only person having the exact same set of issues on 2 different MacBooks
[+] [-] heywoodlh|2 years ago|reply
> I loved the idea of rootless but it doesn't work on Mac
One clarification I think is worth making in case you weren't aware is that the "rootless" approach isn't really a factor for any Linux container runtime on MacOS since all the container solutions on MacOS run in a VM (since Linux containers rely on Linux kernel features). I.E. Docker Desktop, Podman Desktop, etc. can't run as root on MacOS because they rely on a user-level Linux VM.
[+] [-] LightFog|2 years ago|reply
[+] [-] ac130kz|2 years ago|reply
[+] [-] mikewang|2 years ago|reply
[+] [-] bsenftner|2 years ago|reply
[+] [-] Etheryte|2 years ago|reply
[+] [-] kynetic|2 years ago|reply
[+] [-] rounakdatta|2 years ago|reply
[+] [-] da39a3ee|2 years ago|reply
[+] [-] methou|2 years ago|reply
[+] [-] heywoodlh|2 years ago|reply
Some background: I avoid most of the Enterprise Linux ecosystem (CentOS, RHEL, AlmaLinux, etc.) as my mentality to sysadmin is often quite different than the average RHEL lover. I run NixOS everywhere and supplement with Arch Linux or Ubuntu when I can't use NixOS. So I am in no way a part of the target demographic of RHEL or derivatives.
But, I actually agree with Red Hat's view on the RHEL clones[1]: they should start using CentOS Stream as their upstream base. CentOS Stream is upstream of RHEL, so if the RHEL-compatible distros start snapshotting from CentOS Stream, then all of the Enterprise Linux ecosystem will benefit from bug-fixes, improvements, etc. that they all contribute into CentOS Stream. Unfortunately, for the RHEL-clones, if they adopt this approach they wouldn't have bug-for-bug compatibility with major RHEL releases, and they would have to do more work in making an LTS off of CentOS Stream. But, everyone benefits (theoretically) in contributing to the same upstream codebase -- and I can't think of many instances where an application that works on RHEL wouldn't work on CentOS Stream or a downstream derivative.
AlmaLinux has chosen to rebase off of CentOS Stream[2] and I think it's the right choice. Rocky Linux has chosen to try to workaround Red Hat's removal of source availability by relying on loopholes to obtain RHEL source code via UBI containers and cloud images[3]. I can't imagine this (seemingly fragile) approach being sustainable and it feels counterintuitive to continue building a distro based on the work of a company whose mentality that you fundamentally disagree with.
Long-winded response, but I guess I don't love the FUD surrounding Red Hat. Red Hat's work benefits me as a Linux user with tooling like Network Manager, systemd and GNOME. I don't think Linux would be as serious of a contender in certain spheres without Red Hat's open source work that the entire Linux ecosystem benefits from.
[0] https://www.redhat.com/en/blog/furthering-evolution-centos-s...
[1] https://www.redhat.com/en/blog/red-hats-commitment-open-sour...
[2] https://almalinux.org/blog/future-of-almalinux/
[3] https://rockylinux.org/news/keeping-open-source-open/
EDIT(s):
Some minor grammar fixes.
Also, I would recommend looking at the the AlmaLinux link's footnote for ABI compatibility and what that means.
[+] [-] nullify88|2 years ago|reply
Good progress though and I'll revisit it again soon.
[+] [-] sonu27|2 years ago|reply
[+] [-] Hamcha|2 years ago|reply
[+] [-] ghusto|2 years ago|reply
Colima on the other hand, is install-and-forget (so much so that I had to look up what it was called again). It uses Lima, which means you can do more with it it if you want.
[+] [-] arun-mani-j|2 years ago|reply
What does cloud-native mean actually?
[+] [-] esamatti|2 years ago|reply
[+] [-] throw__away7391|2 years ago|reply
I was wasting more and more time on it. It was constantly crashing/hanging so one day I just said fuck it and switched back to Docker Desktop, which not only worked better than when I switched but seems to have improved quite a lot in the intervening time as well.
[+] [-] infinitezest|2 years ago|reply
[+] [-] bloopernova|2 years ago|reply
Colima on the other hand works pretty much seamlessly, but really works best on macOS Ventura because you can enable vz virtualization.
Edited to add: colima works seamlessly on the command line. So if you're command-line-averse, you'll need to learn some new commands and things won't be as convenient. I haven't tried rancher desktop yet.
[+] [-] traceroute66|2 years ago|reply
Don't forget there is also Rancher Desktop[1]
[1] https://rancherdesktop.io
[+] [-] tomashubelbauer|2 years ago|reply
It has been a long-standing issue but seems as though it is on its way to resolution: https://github.com/containers/podman-desktop/issues/1633.
I am waiting for a few months to make sure it is all sorted and will try again to see if it works then.
[+] [-] pydry|2 years ago|reply
* podman with --network host won't expose the ports.
* If you suspend the laptop the time on the VM goes haywire.
I always found docker to be unreasonably buggy too so am not sure how I feel about this.
[+] [-] Zizizizz|2 years ago|reply
[+] [-] _ix|2 years ago|reply
podman-desktop is pretty rough, but it gave me enough confidence to start using podman generally. podman-mac-helper solved a few docker compatibility problems I had in previous attempts in 2021 and 2022.
It seems like my problems getting started with podman just last week wete mainly due to the abundance of already outdated tutorials. Maybe those who are more active in this space can weigh-in, but fixes and common work arounds documented as recently as 6 months ago aren't necessary an longer? For me, podman works without nearly as much fuss as I remember.
[+] [-] polski-g|2 years ago|reply
[+] [-] quickthrower2|2 years ago|reply
[+] [-] lstep1234|2 years ago|reply
[+] [-] richardpetersen|2 years ago|reply
[+] [-] bobmaxup|2 years ago|reply
[+] [-] WesolyKubeczek|2 years ago|reply
As a development tool it’s awesome, and having no centralized daemon is sure a boon.
[+] [-] ThatMedicIsASpy|2 years ago|reply
I do use podman daily in the form of distrobox since both the steam deck and my desktop are immutable systems.
[+] [-] otabdeveloper4|2 years ago|reply
[+] [-] Fire-Dragon-DoL|2 years ago|reply