881–890 of 1001 posts
Earlier quoted context omitted.
One upvote is not enough. We need enough upvotes to fix the problem. You can’t shape a big pile of shit into success. HTTP and JS will never serve as a proper application framework.
Upvotes won't fix the problem. Build the future you want, then people will come.
Isn’t this a good case for LLMs? Audit at compile time all of the dependencies?
> Using CVE reports as a weapon
Be accountable for what deploy if paid, except explicit other deal. Like in real jobs. Next...
Earlier quoted context omitted.
The "solution" would be using a language with a strong standard library and then having a trusted 3rd party manually audit any approved packages. THEN use artifactory on top of that. That's boring and slow though. Whatever I want my packages and I want them now. Apart of the issue is the whole industry is built upon goodwill and hope. Some 19 year old hacked together a new front end framework last week, better use it…
I don’t recall hearing about constant supply chain attacks with CPAN
Earlier quoted context omitted.
That doesn't make sense. The most it could be is 3: regex 0.1.x, regex 0.2.y and regex 1.a.b. You can't have more because Cargo unifies on semver compatible versions and regex only has 3 semver incompatible releases. Plus, regex 1.0 has been out for eons. Pretty much everyone has moved off of 0.1 and 0.2.
The reason he went down this rabbit hole was because he was chronically running low on disk space, and his target dir was one of the largest contributors. Not sure how he actually got the number; this was just a frustrated Slack message like 4 years ago A sibling comment mentions we could have been using Cargo workspaces wrong... So, maybe?
But you definitely aren't finding hundreds of versions of `regex` in the same dependency tree.
Earlier quoted context omitted.
As a security guy, for years, you get laughed out of the room suggesting devs limit their dependencies and don't download half of the internet while building. You are an obstruction for making profit. And obviously reading the code does very little since modern (and especially Javascript) code just glues together frameworks and libraries, and there's no way a single human being is going to read a couple million lines…
The "solution" would be using a language with a strong standard library and then having a trusted 3rd party manually audit any approved packages. THEN use artifactory on top of that. That's boring and slow though. Whatever I want my packages and I want them now. Apart of the issue is the whole industry is built upon goodwill and hope. Some 19 year old hacked together a new front end framework last week, better use it…
Earlier quoted context omitted.
The "solution" would be using a language with a strong standard library and then having a trusted 3rd party manually audit any approved packages. THEN use artifactory on top of that. That's boring and slow though. Whatever I want my packages and I want them now. Apart of the issue is the whole industry is built upon goodwill and hope. Some 19 year old hacked together a new front end framework last week, better use it…
This is the right answer. I'm willing to stick my head out and assert that languages with a "minimal" standard library are defective by design. The argument of APIs being stuck is mood with approaches like Rust's epocs or "strict mode". Standard libraries should include everything needed to interact with modern systems. This means HTTP parsing, HTTP requests, and JSON parsing. Some laguages are excellent (like python…
Where do you draw the line though? It seems like you mostly spend your time writing HTTP servers reading/writing JSON, but is that what everyone else also spends their time doing? You'll end up with a standard library weighing GBs, just because "most developers write HTTP servers", which doesn't sound like a better solution.
I'm willing to stick my head the other way, and say I think the languages today are too large. Instead, they should have a smaller core, and the language designed in a way that you can extend the language via libraries. Basically more languages should be inspired by Lisps and everything should be a library.
Earlier quoted context omitted.
As a security guy, for years, you get laughed out of the room suggesting devs limit their dependencies and don't download half of the internet while building. You are an obstruction for making profit. And obviously reading the code does very little since modern (and especially Javascript) code just glues together frameworks and libraries, and there's no way a single human being is going to read a couple million lines…
> You are an obstruction for making profit. This explains a lot. Really, this is the great reason of why the society is collapsing as we speak. "There should be no DRM in phones" - "You Are An Obstruction To Making Profit". "People should own their devices, we must not disallow custom software on it" - "YAAOTMP" "sir, the application will weigh 2G and do almost nothing yet, should we minify it or use different framew…
Earlier quoted context omitted.
The "solution" would be using a language with a strong standard library and then having a trusted 3rd party manually audit any approved packages. THEN use artifactory on top of that. That's boring and slow though. Whatever I want my packages and I want them now. Apart of the issue is the whole industry is built upon goodwill and hope. Some 19 year old hacked together a new front end framework last week, better use it…
This is the right answer. I'm willing to stick my head out and assert that languages with a "minimal" standard library are defective by design. The argument of APIs being stuck is mood with approaches like Rust's epocs or "strict mode". Standard libraries should include everything needed to interact with modern systems. This means HTTP parsing, HTTP requests, and JSON parsing. Some laguages are excellent (like python…
So, databases? Which then begs the question, which - Postgres, MySQL, SQLite, MS SQL, etc.? And some NoSQL, because modern systems might need it.
That basically means you need to pull in everything and the kitchen sink. And freeze it in time (because of backwards compatibility). HTML, HTTP parsing, and SHA1024 are perfectly reasonable now; wait two decades, and they might be as antiquated as XML.
So what your language designers end up, is having to work on XML parsing, HTTP, JSON libraries rather than designing a language.
If JS way is madness, having everything available is another form of madness.