On one hand, a docker container will include duplicates of libraries, many versions, and sometimes unnecessary stuff.

On the other hand, I can run a lot of software on my machine by running a single command, without installing tools and libraries in my system I won't ever use again, and I can, with reasonable confidence, get rid of everything with another.

A lot of people prefer wasted disk space, and potentially memory and cycles, to wasted time and patience.

it's the same overhead/bloat as launching any normal process in the default cgroup and contexts.

> ... wrapped in a docker container because the developer loves docker

I think you maybe don't love Docker and that's coloring some things for you, unjustly.

Docker method is supported. Non-Docker method is available but unsupported, at your own risk.

It reduces the community support load. Eliminates massive amounts of wasted time dealing with distro specific configuration issues. These are volunteers who have better things to do with their spare time than debug that pointless soul destroying shit that Docker eliminates.

Right. But one example doesn’t mean the entire world of containers is “bloat and unnecessary”.

I’ve encountered many use cases where packaging dependencies and deployments become significantly simpler due to containers.

True that there are possibly several other solutions that also solve similar problems. But that doesn’t mean containers don’t also solve actual problems.

Not least because you don't even need to run the container at all when developing.

Here the reward for the developer is not needing to debug your operating system installation, because the container specifies what, as far as the application can see, is the operating system installation. Your reward is an application that has been tested in the environment it is running in.

Seems fair to me.

https://docs.btcpayserver.org/Deployment/ManualDeployment/