4 ms·

That is not Enterprise Software. It is less the language and the frameworks which are making it Enterprise but the requirements placed on them and the software

by oaiey 8y ago

That is not Enterprise Software. It is less the language and the frameworks which are making it Enterprise but the requirements placed on them and the software development lifecycles. Imagine you do a medical product and the regulations needed for FDA approval require you to check for vulnerabilities in your product and build infrastructure. Have you ever checked all packages in a npm dependency tree for vulnerabilities?

realusername 8y ago
> Imagine you do a medical product and the regulations needed for FDA approval require you to check for vulnerabilities in your product and build infrastructure. Have you ever checked all packages in a npm dependency tree for vulnerabilities? The same way as any other language? With audits? I don't get your comment.
- oaiey 8y ago
  To write the same functionality I need 10x the packages (from 9x vendors) in JavaScript compared to a Java/.NET ecosystems. The infamous left-pad packages is a sample for something found in the base class libraries of the other languages. And this does not only stand true for vulnerability analysis but also for other analyze jobs like for licenses or gdpr compliance. The amount of work is just higher with the amount of packages you use.
  - lpghatguy 8y ago
    I think the net amount of code ends up being pretty much the same, it's just spread over several repositories/sources/owners. That does mean it's more difficult without tooling to trawl through, but it's not like it's an order of magnitude or anything.
    - oaiey 8y ago
      The interesting part is how professional the packages are handled. For example in JavaScript there a thousand of authors with very different understanding of their "responsibility". Some do not even provide a license (do not even care to put a "WTFPL" or "Unlicense" on it) and do not read bugs. Others, have a emergency response team and publish CVE records. The less packages I have, the better I can select them and monitor them. Java/.NET/Python ecosystems tend to be more professional with this regards. JavaScript catches up but is not completely there yet (you can see this with the amount of repositories who add licenses in 2016/2017 timeframe, years after creation). Hence, same amount of code, much more work (it is a magnitude).

by oaiey 8y ago

realusername 8y ago

> Imagine you do a medical product and the regulations needed for FDA approval require you to check for vulnerabilities in your product and build infrastructure. Have you ever checked all packages in a npm dependency tree for vulnerabilities? The same way as any other language? With audits? I don't get your comment.

oaiey 8y ago
To write the same functionality I need 10x the packages (from 9x vendors) in JavaScript compared to a Java/.NET ecosystems. The infamous left-pad packages is a sample for something found in the base class libraries of the other languages. And this does not only stand true for vulnerability analysis but also for other analyze jobs like for licenses or gdpr compliance. The amount of work is just higher with the amount of packages you use.
- lpghatguy 8y ago
  I think the net amount of code ends up being pretty much the same, it's just spread over several repositories/sources/owners. That does mean it's more difficult without tooling to trawl through, but it's not like it's an order of magnitude or anything.
  - oaiey 8y ago
    The interesting part is how professional the packages are handled. For example in JavaScript there a thousand of authors with very different understanding of their "responsibility". Some do not even provide a license (do not even care to put a "WTFPL" or "Unlicense" on it) and do not read bugs. Others, have a emergency response team and publish CVE records. The less packages I have, the better I can select them and monitor them. Java/.NET/Python ecosystems tend to be more professional with this regards. JavaScript catches up but is not completely there yet (you can see this with the amount of repositories who add licenses in 2016/2017 timeframe, years after creation). Hence, same amount of code, much more work (it is a magnitude).