Live data from Hacker News

Node.js needs a virtual file system

blog.platformatic.dev

211–220 of 275 posts

Re: Node.js needs a virtual file system

#211

Earlier quoted context omitted.

Considering the many hundreds of technical comments over at the PR ( https://github.com/nodejs/node/pull/61478 ), the 8 reviewers thanked by name in the article, and the stellar reputations of those involved, seems likely.

My mistake 19k lines. At 2 mins per line that’s (19000*2)/60/7=90 7-hour days to review it all, are you sure it was all read? I mean they couldn’t be bothered to write it, so what are the chances they read it all? For someone’s website or one business maybe the risk is worth it, for a widely used software project that many others build on it is horrifying to see that much plausible code generated by an LLM.

> I mean they couldn’t be bothered to write it, so what are the chances they read it all?

What kind of logic is this?

Re: Node.js needs a virtual file system

#212

Earlier quoted context omitted.

> I pointed the AI at the tedious parts, the stuff that makes a 14k-line PR possible but no human wants to hand-write: implementing every fs method variant (sync, callback, promises), wiring up test coverage, and generating docs. Is it slop if it is carefully calculated? I tire of hearing people use slop to mean anything AI, even when it is carefully reviewed.

Was 14k lines carefully reviewed? Seems unlikely.

I carefully review far more than 14k LoC a week… I’m sure many here do. Certainly the language you write in will greatly bloat those numbers though, and Node in particular can be fairly boilerplate heavy.

Re: Node.js needs a virtual file system

#213
The way I bundle into SEA is modules that need to be imported from disk (that can't be bundled due to node or wasm modules), is just include them in the assets, and do a "write to tmp, import, delete" flow. It works.

Not saying vfs is bad, just it's not impossible in a few lines of code to set up that. My idea for a simple version of a vfs in node is to use a RAM disk/RAMfs - would that work?

Re: Node.js needs a virtual file system

#214

Earlier quoted context omitted.

I publish a package with zero deps and people still pull in a pile of transitive stuff from their lockfile. "pg" has 13 dependencies and nobody even blinks. One gets compromised and suddenly every Node backend using Postgres is in scope. Bun shipping native drivers feels like the right call, fewer moving parts.

I understand the general point you're making, but the pg package isn’t a good example. It has 6 deps, not 13, and 5 of those are internal packages from the same monorepo without additional dependencies. There’s only a single external dependency, and that one brings in just one additional package. In my opinion, the pg repo and packages are an example of how OSS stuff should be maintained. Clean repo, clean code, well…

You still need to pull 13 extra deps that could be compromised.

Re: Node.js needs a virtual file system

#215
Little bit saddened the sqlite provider doesn't use the SQLite archive format under the hood. Seems like it'd be a good fit for what they're trying to achieve + give you an easy way to create/extract the files out of the virtual file system.

The sqlar schema is missing some of the info thats being stored atm, but there's nothing stopping you from adding your own fields/tables on top of the format, if anything the docs encourage it. It is just a sqlite database at the end of the day.

https://www.sqlite.org/sqlar.html

Re: Node.js needs a virtual file system

#216

Earlier quoted context omitted.

node -e "new Function('console.log(\"hi\")')()" or more to the point node -e "fetch('https://unpkg.com/cowsay/build/cowsay.umd.js').then((r) => r.text()).then(c => new Function(c + 'console.log(exports.say({ text: \"like this\"}))')())" that one is particularly bad, because umd messes with the global object - so this works node -e "fetch('https://unpkg.com/cowsay/build/cowsay.umd.js').then((r) => r.text()).then(c =>…

Well there you have it. I had to laugh, because the post you're replying to STRONGLY reminds me of this story, https://news.ycombinator.com/item?id=31778490 , in which some people on the GNOME project objected to thumbnails in the file-open dialog box because it might be a "Security issue" (even though thumbnails were available in the normal file browser, something those commenters probably should have known about, b…

I can totally believe that, but at the same time I checked that link and didn't see anything about security mentioned.

Re: Node.js needs a virtual file system

#217

Earlier quoted context omitted.

Allowing AI contributions results in lower quality contributions and allows wild things to come in and disrupt it, making it an unreliable dependency. We have seen big tech experience constant outages due to AI contributions as is...

Your comment is why advertisers say that you should repeat your core call to action at least a few times to make it stick. You’ve read people saying the same thing hundreds of times and have somehow taken that as meaning that it’s credible. Neither you nor I nor anyone else here knows what the “effects” are, because this is brand new tech, and it’s constantly changing. Yet you’re speaking with absolute confidence. “B…

My dude, you're making the classic problem of assuming because you don't have any first-hand knowledge of problems, other people are equally ignorant.

Don't slap someone else down because you don't know something.

Re: Node.js needs a virtual file system

#218
post #81

Earlier quoted context omitted.

It would be considered (a) since the author would own the copyright on the code.

Owning copyright of something and writing it are very different things

Not in the US. Copyright exists from the moment the work is created.

Source: https://www.copyright.gov/help/faq/faq-general.html

Re: Node.js needs a virtual file system

#219
post #95

Earlier quoted context omitted.

Large PRs could follow the practices that the Linux kernel dev lists follow. Sometimes large subsystem changes could be carried separately for a while by the submitter for testing and maintenance before being accepted in theory, reviewed, and if ready, then merged. While the large code changes were maintained, they were often split up into a set of semantically meaningful commits for purposes of review and maintenanc…

Nobody wants to review AI-generated code (unless we are paid for doing so). Open source is fun, that's why people do it for free... adding AI to the mix is just insulting to some, and boring to others. Like, why on earth would I spent hours reviewing your PR that you/Claude took 5 minutes to write? I couldn't care less if it improves (best case scenario) my open source codebase, I simply don't enjoy the imbalance.

I hate being paid to review AI slop.

Re: Node.js needs a virtual file system

#220

Earlier quoted context omitted.

Not sure if you are intentionally misrepresenting (a), but here is the full text (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

That seems exclusive of LLMs, as the user didn't create the contribution, the LLM did.

It's exclusive of code where you wrote 0% of it.

"in part" is a trivial bar to clear.

Post reply on HN