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 ditched Docker for Podman
321–330 of 670 posts
Re: I ditched Docker for Podman
#322I 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.
Re: I ditched Docker for Podman
#323This 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.
Re: I ditched Docker for Podman
#324Earlier quoted context omitted.
It becomes a pain point when the IT team never heard of docker, all new licenses need to be approved by the legal department, and your manager is afraid to ask for any extra budget. Also, I don't want to have to troubleshoot why the docker daemon isn't running every time I need it
>It becomes a pain point when the IT team never heard of docker Where do you work ? Is that even possible in 2025?
Apparently they work in the past...
Re: I ditched Docker for Podman
#325Earlier quoted context omitted.
There's no need if all your devs use desktop Linux as their primary devices like we do where I work :)
On Mac we just switched to podman and didn't have anything to worry about.
I am using MacOS and like a year ago I uninstalled docker and docker desktop, installed podman and podman-compose, and have changed literally nothing else about how I use containers and docker image building/running locally. It was a drop-in replacement for me.
Re: I ditched Docker for Podman
#326Earlier quoted context omitted.
Use an LLM is not a solution. It's effectively telling you to switch your brain off and hope nothing goes wrong in the future. In reality things do go wrong and any conversation should be done with a good understanding of the system involved.
While I agree with this concept, I don't think it is applicable here. Docker compose files and k8s yaml are basically just two different syntaxes, saying the same thing. Translating from one syntax to another is one of the best use cases for an LLM in my opinion. Like anything else you should read it and understand it after the machine has done the busy work.
> Translating from one syntax to another is one of the best use cases for an LLM in my opinion.
Have a look at https://kompose.io/ as well.
Re: I ditched Docker for Podman
#327Earlier quoted context omitted.
> On the plus side, any company I work for doesn't have to worry about licences. Win win! Was this a deal breaker for any company? I ask because the Docker Desktop paid license requirement is quite reasonable. If you have less than 250 employees and make less than $10 million in annual revenue it's free. If you have a dev team of 10 people and are extremely profitable to where you need licenses you'd end up paying $9…
Docker Desktop is also (imo) useless and helps be ignorant. Most Mac users I see using it struggle to see the difference between "image" and "container". Complete lack of understanding. All the same stuff can easily be done from cli.
> Most Mac users I see using it struggle to see the difference between "image" and "container". Complete lack of understanding.
Because they just want their software package to run and they have been given some magic docker incantation that, if they are lucky, actually launches everything correctly.
The first time I used Docker I had so many damn issues getting anything to work I was put off of it for a long time. Heck even now I am having issues getting GPU pass through working, but only for certain containers, other containers it is working fine for. No idea what I am even supposed to do about that particular bit of joy in my life.
> All the same stuff can easily be done from cli.
If a piece of technology is being forced down a user's throat, users just wants it to work and go out of their way so they can get back to doing their actual job.
Re: I ditched Docker for Podman
#328I already use podman for local development. While docker can run under rootless mode [1] and alleviate the security concern. The concern about docker being resource intensive is still quite true (which is why I avoid using it in my self hosted setup). Rather _declaratively_ define configuration with nix. Deploy nixOS to machines (rpi4/5, x86, arm) and vms (proxmox) and manage remotely with nixos-anywhere. One of thes…
Or if you are on macOS, there is https://github.com/juspay/services-flake which is based on process-compose. So you get an unified alternative to docker-compose but based on Nix and works on both platforms.
Re: I ditched Docker for Podman
#329I 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.
Containers and container orchestrators are complex tools. The constant cost of using them is pretty high compared to bash scripts. However the scale / maintenance factor is significantly lower, so for a 100 boxes simplicity of bash scripts might still win out over the containers. At 1000 machines it is highly likely that simplest and least maintenance overall solution will be using an orchestrator.
Re: I ditched Docker for Podman
#330Rootless 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.