Cautionary Tale of "Unpublished" 17 Lines of Code

  • Thread starter Thread starter jedishrfu
  • Start date Start date
  • Tags Tags
    Code Lines
AI Thread Summary
The article discusses the complexities and risks associated with modern software development, particularly in the context of JavaScript libraries and components. Developers often find themselves as mere users of the software they create, facing challenges due to the increasing complexity of systems and dependencies. While well-implemented libraries can enhance productivity, they also pose risks when they become uncontrollable, especially when developers rely on external sources for the latest versions. The conversation highlights the importance of archiving third-party libraries to mitigate potential issues. Additionally, it raises concerns about the security implications of software dependencies, suggesting that making systems read-only after deployment could reduce vulnerabilities. The discussion also touches on the potential benefits of static systems, using examples like Chromebooks and PLCs to illustrate how limiting changes could prevent malware and bugs. The mention of a JavaScript book, "JavaScript: The Good Parts," underscores the ongoing conversation about the language's complexities and risks.
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 jedishrfu
Last edited by a moderator:
  • Like
Likes 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.
 
Back
Top