(#mna5wlq) @movq Your right, neither Rust nor Go work that way. They use (_or at least in Go's case, I'm not sure about Rust to be hoenst_) Git really as a way to fetch packages. The plus side of this is you get all the nice benefits of Git

(#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) In general, I try to use as little dependencies as possible. I rather read a deps source to see how it’s implemented and then implement it myself. But this isn’t enough. Transitive dependencies make everything horrible. For example, that Rust program I mentioned has two direct dependencies, which pull in four transitive ones. So the amount of work, that I have to do to make sure that all those deps don’t screw up, increases rapidly. If that stuff came from my distro, I’d at least have another person to help me with that.

(#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) Read this @eaplmx: Is There A Way To Prevent Psychopaths From Getting Into Positions Of Power?

(#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 let's introduce politics into the conversation

(#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) Whaaaaatttt?! 😱 Why?! 😳