News for hackers. Stuff that matters.
Re:Show HN: Reimagine the File System by eyelidlessness on Monday November 30, 2020 @05:10PM (#25259686)
It’s a great design for certain use cases and fundamentally incompatible with/needs adaptation for others.

It’ll work well for:

- Aggregate workflows (i.e. composing heterogeneous collections)

- Library curation (i.e. individual or mass categorization)

- Content discovery/rediscovery (i.e. find things based on metadata rather than location)

It’ll either poorly serve or need additional consideration for:

- Contained dependencies (i.e. any kind of encapsulated package that has internal references)

- Structural authorization (i.e. a given user may or may not be permitted access to some or all functions based on the branch/leaf they’re trying to access)

- Structural layout (i.e. the user has a hierarchy in mind which they wish to reify)

Re:Show HN: Reimagine the File System by eyelidlessness on Monday November 30, 2020 @05:16PM (#25259741)
I’ll leave the above comment intact from here but I already edited once and still regret the word choice “fundamentally incompatible”. As with any data structure, you can make adaptations and accommodations to support use cases that seem to conflict. There’s always a memory/performance/impedance mismatch/experience cost for any abstraction, but there’s no reason a set/tree hybrid couldn’t provide for both families of use cases, given those costs.