In my case, BTCPayServer was wrapped in a docker container because the developer loves docker... but I took the docker out of the project after I forked it because I felt putting the project in a docker container was extra bloat that was convoluted and unnecessary. In other words, a "container" didn't have to wrap the project, it was just implemented because of a dev insisting on it. That is bloat to me, extra and unnecessary.

> In my case, BTCPayServer was wrapped in a docker container because the developer loves docker...

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.

That is remarkably a non-answer.

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

It's pretty easy to Google this particular example you've cited and see that they have non-docker instructions available, and don't recommend them because you can easily screw things up.

Seems fair to me.

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

given that Docker mostly (entirely?) gives a single UI to various related Linux kernel features, I don't see how it is bloat at all. Docker just tells the kernel to create a separate cgroup and networking, CPU, and RAM namespaces and then launches one or more processes within the confines set up with those things.

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.

It has slightly higher overhead than normal process, because the process will use a different set of userland libraries than your host normally uses (increasing memory usage) and the filesystem inside the container has a high chance to be a convoluted mess of overlaysfs mounts.

That said, it is hardly a "bloat".

Bloat is relative.

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 probably depends on their income more than anything.

> That is bloat to me, extra and unnecessary.

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.

You've been downvoted but I suppose I'm willing to ask.

Why would defining the runtime dependencies needed for the execution environment of the software ever be a bad thing? Unless it's a statically linked binary as the final artifact I can't come up with a reason the stuff you ripped out would be anything but useful. Directly, or as executable documentation.

Spend the resources and get the reward, or don’t spend the resources and don’t get the reward. That’s not bloat, bloat contributes nothing, it’s just waste.

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.

BTCPayServer’s container setup was quite trivial, granted I used it last a few years ago. I had no issues with the container itself. You are free to install deps in whichever you want, but not sure how containerizing setup makes it bloat and/or unnecessary.