Cautionary Tale of "Unpublished" 17 Lines of Code

  • Thread starter Thread starter jedishrfu
  • Start date Start date
  • Tags Tags
    Code Lines
Click For Summary

Discussion Overview

The discussion revolves around the implications of using third-party libraries in software development, particularly in JavaScript. Participants explore the complexities and risks associated with dependencies, the management of libraries, and the potential consequences of relying on external resources.

Discussion Character

  • Debate/contested
  • Technical explanation
  • Conceptual clarification

Main Points Raised

  • Some participants express concern about developers becoming mere users of complex systems, highlighting the challenges posed by the increasing complexity of software and dependencies.
  • Others argue that while the complexity can be overwhelming, there are practices such as archiving third-party libraries that can mitigate risks.
  • There is a discussion about the common practice in JavaScript of referencing libraries from external sources, which can lead to significant issues if those resources change unexpectedly.
  • One participant raises the idea of making systems read-only after deployment to enhance security and reduce risks associated with dependencies.
  • Another participant questions the implications of the licensing of a package published under WTFPL, suggesting that it could have remained in the npm repository.

Areas of Agreement / Disagreement

Participants express a range of views on the management of dependencies and the implications of complexity in software development. There is no clear consensus, as differing opinions on the control developers have over their software and the risks involved are present throughout the discussion.

Contextual Notes

Participants reference specific practices and challenges related to JavaScript libraries, but there are unresolved assumptions about the effectiveness of archiving and the implications of licensing on software availability.

Computer science news on Phys.org
Nice. :oldtongue:
 
It is a sadly case of us developers being mere users and in many cases just bystanders, of what is taking place in our software, due to the logarithmically increased complexity of the systems/components we use and software demands - as a whole, that we have to face. Surely, no one can overlook the advantages of well implemented and tested libraries and components and there are good efforts and will, to overcome such issues. However, what reduces our development time and efforts, can suddenly get a real boomerang towards our heads and the worst thing is that it gradually becomes totally out of our control.
 
Last edited:
QuantumQuest said:
It is a sadly case of us developers being mere users and in many cases just bystanders, of what is taking place in our software, due to the logarithmically increased complexity of the systems/components we use and software demands - as a whole, that we have to face. Surely, no one can overlook the advantages of well implemented and tested libraries and components and there are good efforts and will, to overcome such issues. However, what reduces our development time and efforts, can suddenly get a real boomerang towards our heads and the worst thing is that it gradually becomes totally out of our control.

I wouldn't say it's out of your control. Many shops archive third party lobs and their source for just such an event. However in the JavaScript world, it's not uncommon to simply reference the needed library from wherever it's hosted to get the latest and greatest version and in this case it can become a huge problem.
 
jedishrfu said:
However in the JavaScript world, it's not uncommon to simply reference the needed library from wherever it's hosted to get the latest and greatest version and in this case it can become a huge problem.

Yes, I mainly talk about such cases with web libraries/components and versions. JavaScript has become a real messy thing in its present form of frameworks and because it's usually the case to reference what you need than to include it, things are getting really out of control or messy and upsetting at best. If archiving is an option then surely it's utilized.
 
The risks of dependencies are not limited to open source.

At least part of the risk is dependency on anything that might change in the future. I have often wondered how much security we forgo by not making some systems read-only after deployment.

For example, a Chromebook laptop with all the software and static data burned in ROM, and no mechanism for update or change, and no external links to software like javascript. Even buffer overflows could not overwrite code or static data. That would defeat a lot of future bugs and malware; not all but a lot.

Another example, if Iran had their PLCs as ROM only, would that have defeated the Stuxnet worm?
 
  • Like
Likes   Reactions: jedishrfu
Last edited by a moderator:
  • Like
Likes   Reactions: jedishrfu
HallsofIvy said:
Is that like "JavaScript: the naughty bits"?

Nah that was book two yet to be published.
 
  • #10
What I don't understand is that the package was published under WTFPL. This means that npm could've left it in their repository.
 

Similar threads

Replies
9
Views
2K
Replies
10
Views
5K
  • · Replies 15 ·
Replies
15
Views
3K
Replies
4
Views
543
Replies
3
Views
5K
  • · Replies 1 ·
Replies
1
Views
3K
  • · Replies 4 ·
Replies
4
Views
4K
  • · Replies 2 ·
Replies
2
Views
603
  • · Replies 1 ·
Replies
1
Views
4K