Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Node.js needs a virtual file system

blog.platformatic.dev

Post reply on HN
Print view View original

131–140 of 275 posts

Re: Node.js needs a virtual file system

#131

Post by Dylan16807 »

indutny wrote: post #42
athorax wrote: post #37

Earlier quoted context omitted.

How exactly does it violate the Developer's Certificate of Origin clause?

The submitted code must adhere to either of (a), (b), (c), and separately a (d) clause of: https://github.com/nodejs/node/blob/main/CONTRIBUTING.md#dev... If submitter picks (a) they assert that they wrote the code themselves and have right to submit it under project's license. If (b) the code was taken from another place with clear license terms compatible with the project's license. If (c) contribution was written…

If there's a "the original" the LLM is copying then there's a problem.

If there isn't, then (b) works fine, the code is taken from the LLM with no preexisting license. And it would be very strange if a mix of (a) and (b) is a problem; almost any (b) code will need some (a) code to adapt it.

Re: Node.js needs a virtual file system

#133

Post by pie_flavor »

zadikian wrote: post #48
PaulHoule wrote: post #5

Would be nice if node packages could be packed up in ZIP files so to avoid the security/metadata tax for small file access on Windows.

Would accessing deps directly from a zip really be faster? I'd be a little surprised but not terribly, given that it's readonly on an fs designed for RW. If not, maybe just tar?

You just cat the exe with the zip file, then it is all loaded into memory at the same time on process init. This is how e.g. LÖVE does game code packaging. (It can't be tar, because this trick only works because the PKZIP descriptor is at the end of the file.)

Re: Node.js needs a virtual file system

#134

Post by kruffalon »

epolanski wrote: post #103
exe34 wrote: post #96

Earlier quoted context omitted.

> if it's your job, it's a bit different and you may have to do so Oh I'd use an llm to generate large amounts of feedback and request changes!

Imagine if every profession reasoned liked that when doing something they don't enjoy.

What a wonderful world we would have, or possibly at least better than the current shit show :)

Re: Node.js needs a virtual file system

#136

Post by giancarlostoro »

> 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.

This is the biggest takeaway for me for AI. It's not even that nobody wants to do these things, its that by the time you finish your tasks, you have no time to do these things, because your manage / scrum master / powers that be want you to work on the next task.

Re: Node.js needs a virtual file system

#137

Post by giancarlostoro »

everlier wrote: post #89
mixologic wrote: post #74

Earlier quoted context omitted.

Worth noting that mcollina is a member of the Node.js Technical Steering Committee

We call it a slip slop at work, it's ok to slip some slop if it's "our" slop :-)

> 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.

Re: Node.js needs a virtual file system

#138

Post by skydhash »

mohsen1 wrote: post #59
Normal_gaussian wrote: post #52

Earlier quoted context omitted.

The way to do this today is to do it outside of node. Using an overlay fs with the overlay being a ramfs. You can even chroot into it if you can't scope the paths you need to be just downstream from some directory. Or, just use docker.

making that work cross platform is pure pain

What are the other OS? There's a bunch of solutions described on Wikipedia

https://en.wikipedia.org/wiki/List_of_RAM_drive_software

Re: Node.js needs a virtual file system

#140

Post by SAI_Peregrinus »

ryandrake wrote: post #111
torginus wrote: post #109

Why do people keep reinventing OS features? There's Docker, OverlayFS, FUSE, ZFS or Btrfs snapshots? Do you not trust your OS to do this correctly, or do you think you can do better? A lot of this stuff existed 5, 10, 15 years ago... Somehow there's been a trend for every effing program to grow and absorb the features and responsibilities of every other program. Actually, I have a brilliant idea, what if we used node…

One of the worst is media players that all insist on grafting their own "library" on top of my already-working OS filesystem. So I can't just run the media player and play files. No, that would be too simple. I have to first "import" my media into a "library" abstraction and then store that library somewhere else on my filesystem. Terrible!

There's a legitimate problem they're trying to solve there: there are several ways to sort media that don't match up well with a hierarchical filesystem¹. They solve it badly. Good players maintain a database for efficient queries of media metadata, and periodically rescan the folders to update it. Shitty media players try to manage the files themselves, and still end up needing to maintain a database. The worst of these use the database to manage the contents of their storage files (or store the files themselves in the database), if something isn't in the database they delete the files. Adobe Lightroom Classic does this, if your database gets corrupted it deletes all your RAW files!

¹E.g. if you've got music, and it's sorted `artist/album/track.extension`, and two artists collaborate on an album, which one gets the album in their folder? What if you want to sort all songs in the display by publication date? Even if they use the files on your filesystem without moving them, some sort of metadata database will be needed for efficient display & search.

Post reply on HN