(#mna5wlq) @movq I _think_ overall there are two issues at play here we can agree on, whether or not it's "managed" by a distro (_I think that's kind of irrelevant here, I use/develop on macOS for example and use `brew` but I don't want my deps to come from Homebrew uggh yuck_) -- Anyway There are two issues I see: - Supply Chain -- Being able to vet, validate and verify everything that goes into a piece of software or product/service - Library hygiene -- Being prudent about libraries as a Library author and reducing or eliminating "transitive" dependencies.

(#mna5wlq) TBH, I’m not sure if all of this is “dynamic linking vs. static linking”. The distro *could* theoretically provide packages with something like `.a` files and then my program could be statically linked. But the reality is that Rust (and probably not Go, either?) just don’t work that way. (And even if it was *technically* possible: People don’t do it.)

(#mna5wlq) @prologic There appears to be a backstory: And then he probably got upset that is work is used so much, but nobody ever pays him? Hard to tell if any of this is true. It just shows how broken the modern software world is. People are surprised that pulling tons of dependencies without *any* kind of review process breaks stuff? Really? Maintainers matter. Distributions matter. This is what irks me *a lot* about Rust, Go (and Python, to some degree): They all promote their own package management solution, none of which have any kind of review/testing process like a distro has. This is bad. (With Python, distros can at least provide a package and you can use that. That doesn’t work with Rust (and probably not with Go), because they hate dynamic linking so much.) I’m just glad I don’t have anything to do with the JS world.

(#mna5wlq) @movq That’s actually not a bad thing though. Static linking has its advantages really and the belief that dynamic linking makes security patching easier is really quite rubbish. You are right though it all comes down to how good your processes are (or not)

(#mna5wlq) @prologic My concern/point is to have a review and/or testing process by a maintainer of my distribution. And I want to have this process for *libraries* (or “dependencies”, in general), not just for programs. Here’s an example: I’m writing a Rust program that uses the “chrono” library: In the source code of my program, I add this lib as a dependency. What happens then is that the Rust tooling downloads this library *directly from upstream*. Another program that I’m writing is using Python. Again, I have a dependency and I state that in my source code. But here, this dependency can either be installed directly from upstream or *through a package of my distribution*. When I do the latter (install the distro package), I don’t get *some* upstream version, but I get a *maintained version* from my distro. I think it’s pretty obvious that using a distro package is the more robust way. There simply is a second pair of eyes to catch mistakes. When stuff comes from the distro, then the distro maintainer has already done a good deal of work (catch stupid stuff like in the article on slashdot; maybe hold back versions that are known to be broken; maybe apply local patches to make the thing work with this distribution; …). Devs/users can rely on that work and it makes their life easier. But when everyone installs everything directly from upstream, *everybody* has to do the distro maintainer’s work.

(#mna5wlq) @eaplmx LOL even worse 🤣 🤦‍♂️ So no 🤪

(#mna5wlq) @movq Yeah I get your points. I used to maintain hundreds of packages for the CRUX distro once upon a time, so I get it. Your points about having a "2nd pair of eyes" are somewhat valid, but I say that because I've been a maintainer myself, we don't often do the "right" things as a maintainer and we sometimes get sloppy/lazy....

(#mna5wlq) @prologic let's introduce politics into the conversation

(#mna5wlq) @prologic Smoot Poderator 🎶 Poderator is brilliant! Reminds me of the Podcast and the concept of Pod itself, Ham radio and such.