I wouldn't include those on the same list. It makes sense for various (source-form) libraries to be maintained and updated and made available independently of the OS and uniformly across operating systems. I don't see this as undermining Linux distributions - as these are used when you're making your own builds anyway.
Otherwise - yes, agreed, and it's also about redundancy and bloat when installing software; and some entities writing software that can only run on their own docker image; etc.
That's the problem: they encourage building with tons of random stuff pulled from the Internet on the fly, sidestepping OS distributions completely and providing no reproducible building, no vetting, no license review, no long-term security.
The leftpad disaster is a good example.
Also - it's not supposed to be "tons of random stuff", it's supposed to be the libraries you're relying on. Maybe I'm missing something in the point you're making?
> it's supposed to be the libraries you're relying on
When an ecosystem has poor engineering practices and encourages small libraries with many dependencies you get a quadratic explosion of indirect dependencies.
You might not care about having 100 transitive dependencies until a poor soul has to maintain your code in 4 or 10 years from now.
Indeed, the popularity of docker, flatpak and hobby/fad distributions and language-specific package managers is leading to many security nightmares and harming traditional distributions.
There are reasons for painstakingly vet and package software:
- security
- stability AKA you don't want to force feature upgrades with new bugs on servers and workstations
- legal compliance: people are unaware of the amount of license issues in docker hub, flatpaks and most distributions