SoylentNews is people
SoylentNews
Russ Cox, who developed the dependency/package management system for Go, writes about the problems with software dependencies. A choice excerpt:
Dependency managers now exist for essentially every programming language. [...] The arrival of this kind of fine-grained, widespread software reuse is one of the most consequential shifts in software development over the past two decades. And if we’re not more careful, it will lead to serious problems.
A package, for this discussion, is code you download from the internet. Adding a package as a dependency outsources the work of developing that code [...] to someone else on the internet, someone you often don’t know. By using that code, you are exposing your own program to all the failures and flaws in the dependency. Your program’s execution now literally depends on code downloaded from this stranger on the internet. Presented this way, it sounds incredibly unsafe. Why would anyone do this?
(Score: 2) by c0lo on Thursday January 24 2019, @11:32PM (7 children)
Because reinventing the wheel is so... pleasurable. I can spend my entire life re-implementing loggers and HTTP client-end libs and what not.
The main software one has in mind can wait for as long as necessary, "delayed gratification" is a virtue. That software one would like to see created? That's a nothing in the bigger picture - one can wait for around 60+ years to become financial independent enough to escape the rat race.
Ah! If rewriting utility libraries doesn't excite you enough, making sure a new version of such a dependency does patch the older bugs and doesn't reintroduce other surely will surely bring you to orgasm.
https://www.youtube.com/@ProfSteveKeen https://soylentnews.org/~MichaelDavidCrawford
(Score: 1, Funny) by Anonymous Coward on Friday January 25 2019, @04:15AM (2 children)
Why would it take you a lifetime to write a logger and an http client? Are you using an iPhone with autocorrect to code?
(Score: 3, Touché) by c0lo on Friday January 25 2019, @04:35AM (1 child)
Those two, won't. "What not" on the other side... I mean, look, try writing whatnots yourself and you'll see.
I don't get this one. Maybe because I never used an iPhone.
https://www.youtube.com/@ProfSteveKeen https://soylentnews.org/~MichaelDavidCrawford
(Score: 2) by kazzie on Friday January 25 2019, @08:12AM
It's a reference to https://soylentnews.org/article.pl?sid=19/01/24/214255 [soylentnews.org]
(Score: 0) by Anonymous Coward on Friday January 25 2019, @04:39AM
I think there is a balance here. There is a difference between using the standard HTTP client-end libs and something like left-pad or is-odd. For goodness sakes, there are packages on npm that are literally one line negations of other packages.
(Score: 2) by Immerman on Friday January 25 2019, @08:13PM (2 children)
I've got to disagree about accepting dependency updates un-verified. That's a really big source of potential new bugs that can sometimes be a problem even with professional packages, much less those developed and updated by "someone on the internet". Especially since all you need to do is run your unit tests to verify that everything still works correctly. You do have comprehensive a unit test suite, right? Okay fine, I admit it, neither do I. And I'd bet good money that neither do many/most of the authors of all those dependencies that you're trusting not to break.
(Score: 0) by Anonymous Coward on Friday January 25 2019, @10:37PM (1 child)
What is one to do if a dependency 5-steps removed from the software one develops uses a vulnerable OpenSSL version? Vuln that one learns long after the software one has been released?
(Score: 2) by Immerman on Saturday January 26 2019, @01:01AM
Then it behooves you to update your library, doesn't it? The point is not to not update your libraries, it's to not update them automatically without first verifying that the update doesn't break anything.
I've thought that the ideal way to handle external library updates is for the executable to specify the latest "certified-good" version of the libraries it uses, even supply a copy in it's internal program space. And then let users decide whether they want to use that version, or the latest independently updated version, based on default or program-specific library settings. Probably you'd usually default to "use latest", but having the option to switch to the "certified good" or "last working" version at the press of a button would be very valuable. Ideally the OS would even keep track of library updates so that you could flag a program as buggy and have it automatically revert (for that program) any libraries that were updated since the last non-buggy use.