Reasons to Drop Docker for Podman

"Cloud native is the software approach of building, deploying, and managing modern applications in cloud computing environments."

An example of this would be how Podman Desktop includes tooling that allows you to easily deploy and manage pods in Kubernetes.

[0] https://aws.amazon.com/what-is/cloud-native/

I think that one of the reasons many people might not be aware of the VM is because -- in my experience -- Docker Desktop works almost identically to Docker on a real Linux system. I feel like Docker has done a fantastic job at making you feel like it's running natively (i.e. despite running in a VM you can mount volumes close to the same way, you can use the docker CLI from the host, etc.). Additionally, I don't think people realize/care that Linux containers rely heavily on features the Linux kernel provides (interestingly, and less well-known, Microsoft has done a lot of work to provide Windows containers[0], too).

I am curious, though, why in your use-case of Tailscale and Traefik knowing that Docker Desktop runs in a VM would impact anything from a functional standpoint? I.E. why would the VM have even been an important factor to the support teams you reached out to?

> This industry is just a bunch of overly paid amateurs

I think, perhaps a more compassionate view is that everyone is learning and growing and it's difficult to be an expert at literally everything you use in your stack. :)

[0] https://learn.microsoft.com/en-us/virtualization/windowscont...

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.

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.