Just alias pdoman=podman. I do that with all my common typos.

I like how simple it is. It’s made distrohopping very, very simple for me over the years. The only pet machines I have are my actual dev boxes. The rest are cattle I manage with other tools. Galaxy has also made it much simpler to consume other Ansible which used to be really annoying.

I’m on the fence about Nix. When I first saw years ago it was yet another package management system. I’ve seen enough interesting things with it now that I’ll probably try it out the next time I want to rebuild my configs from scratch.

I really like Ansible and have used it for my personal dotfiles for years. I don’t think it’s a silver bullet and I’m aware of a lot of the criticism. Containerization or immutable infra solves more production problems so I don’t really use it much at work.

At least in the devops/SRE circles I work in, we know there are different tools for different jobs. While we might fight about which is the best, I haven’t seen the ossification you’re describing.

A problem so common it has an official page

It’s also offered as part of the installation process at least for Ubuntu server. If you don’t know better it bites you real quick.

The issue here is that Canonical pushed the snap install without warning about its reduced functionality. I don’t think highlighting a wildly different experience between a snap install and the Docker experience people are used to from the standard package install is “bashing it just because it’s popular to hate on snap.” For example, if you take a fresh Ubuntu server 22 install and use the snap package, not realizing that snaps have serious limitations which are not explicitly called out when the snap is offered in the installation process, you’re going to be confused unless you already have that knowledge. It also very helpfully masks everything so debugging is incredibly difficult if you are not already aware of the snap limitations.

This is really dependent on whether or not you want to interact with mounted volumes. In a production setting, containers are ephemeral and should essentially never be touched. Data is abstracted into stores like a database or object storage. If you’re interacting with mounted volumes, it’s usually through a different layer of abstraction like Kibana reading Elastic indices. In a self-hosted setting, you might be sidestepping dependency hell on a local system by containerizing. Data is often tightly coupled to the local filesystem. It is much easier to match the container user to the desired local user to avoid constant sudo calls.

I had to check the community before responding. Since we’re talking self-hosted, your advice is largely overkill.

If you’re only on Linux and don’t ever touch containers on Windows or Mac, podman can work fairly well. You need to be comfortable with orchestration tools like k8s to replace compose (or just do a ton of containers) and you can’t use a lot of COTS that has hardcoded dockerisms (localstack, for example, does not work well with podman).

If you have to use Windows or Mac, podman makes life really difficult because you’re running through a VM and it’s just not worth it yet.

You can get free offers from most places. If you juggle accounts and don’t do a ton, you can use AWS for free perpetually without dealing with this odd idle fandango.

What about Oracle made it work for you over others? Have you looked at the minors like Linode or DigitalOcean?

I think a good question for newcool1230@lemm.ee is why Oracle. If they don’t have a reason to be using it, this is a great suggestion.