[mingus88]

I run a ton of apps like this.

Look at it the other way. Why muck up my OS with a bunch of tiny apps? Who knows what version I’ll pull in my repo today. Chances are good it’s outdated with weird patches.

The docker image is built by the devs. All the proper dependencies are baked into the image. It’s going to run exactly as intended every time, no surprises.

And I can pick up the docker file and my configs and run it exactly the same on any OS.

[malux85]

I love watching this in tech, the pendulum swings, this is static linking in another dress,

Soon everyone adopts this, and then someone complains “why is there 500 libc libraries on my machine” or “there was critical bug and I had to update 388 containers - and some maintainers didn’t update and it’s a giant mess!”

Then someone will invent dynamic underlying container sharing (tm) and the pendulum will swing the other way for a bit, and in 2032, one dev will paste your comment in a slightly different form - why muck up my mindvisor with a bunch of tiny apps? Isolated runtimes are built by the devs,

And so on, back and forward forever

[sunrunner]

> And so on, back and forward forever

My god, we've discovered a genuine perpetual motion machine.

> this is static linking in another dress

Although static linking usually seems to result in small binaries that just run on the target machine while this needs all the Docket machinary (and the image sizes can get horrendous)

[7bit]

It's worse, it's reverse perpetual motion. It takes an infinite amount of energy to achieve something you could achieve with a tiny finite amount!

[vrighter]

Noooo!!! Packaging all your dependencies by static linking is bad! Packaging all your dependencies as shared libraries into one tar file, separately for each app, is the way to go and needing another runtime just to be able to run your program (not for it to actually function.... just to run it). The final artefact is still only one file, but without the benefits of link-time-optimization!

[zoobab]

We need a static linux distro, because i prefer to have a portable app that works on all linux distros.

[phatskat]

Sounds like you need an APE

[stonogo]

    The docker image is built by the devs.

Not in this case, it isn't.

All of the things you describe are just "package manager, but outside distro control," which is fine I guess but not really a meaningful answer.

[lmm]

I think the real answer is that distro packaging sucks; it tends to involve arcane distro-specific tools and introduce as many or more bugs than it fixes (with the added problem of playing hot potato with the bug reports), on top of delaying updates. Really, what do you gain by using distro packages? (I know the answer is supposedly that you get a set of well-tested versions of your applications that play nice with each other, but that's rarely been delivered in practice)

[stonogo]

I don't disagree with that assessment, but I'm not sure docker's any different. It's just a different arcane set of tools that introduces as many failure points as it fixes (with the added problem of supply chain attacks) on top of having to use all the distro stuff anyway. So, while I use the hell out of docker, I don't really regard it as an improvement on (or really an alternative to) distro packages. I think it's a better tool for solving complex deployments, but e.g. irssi isn't really in that camp.

[lmm]

I think that like it or not, Docker has managed to win mindshare in a way that no single distro's package management ever did. Application developers could never get away with publishing only RPMs or only debs (and whether the same deb would work on Debian and Ubuntu was always a risky question), but everyone runs Docker; even the alternatives like Podman or Moby feel the need to be compatible with existing Docker packages.

[stonogo]

Yeah, that's probably true among developers. Among other classes of users, providing a deb or an rpm (or some combination of package manager formats) has been pretty normal. Enterprise software like Slack has been doing this for ages, Microsoft distributed Teams that way for years, the CUDA stack is rpm/deb, etc. Outside of the dev world, docker is basically a signal that your devops people should be on the project. The most common question used to be "why no installer" but nowadays users just use the "app store" (Gnome's Software or KDE's Discover) to Get Stuff, and wouldn't be able to tell you if asked whether what they just installed was a native package or a Flatpak.

I do agree that Docker is ubiquitous in the development world, but I think the fraction of people even aware enough of packaging to have an opinion is vanishingly small.