2 ms·
These concepts look nice, but never take into account the difficulty of working on complex projects with multiple people that hierarchical filesystem actually w
by mmastrac 11y ago
These concepts look nice, but never take into account the difficulty of working on complex projects with multiple people that hierarchical filesystem actually work well on.
There's absolutely no way you could build an app in a big "bucket 'o' files". Sure, you can put together a flyer for a softball game or (maybe) type up a simplistic report for school, but eventually these "loops" are going to become big, unusable buckets of content that isn't easily searchable (do we have good search on music contents yet? better hope the filename is good before it goes into the bucket!).
Perhaps the answer here is a "subloop". That's starting to look like we've come around to nested document folders again, isn't it?
Somewhat amusing: the screenshot of Sublime Text in the mockup is using folders.
- koenigdavidmj 11y agoI would assume that a file would correspond with an 'app project' with appropriately structured content inside. Analogies I'm thinking of include Smalltalk images, or how a compiled .app is a directory right now.
- jimminy 11y agoWhat I find most funny about it is that HFS actually provides the closest model framework for a heirarchial distributed FS, where pretty much no other does (btrfs does have some benefits as well.) Like the author, I worked on a distributed cloud FS, but hierarchy was a core goal. The abstracted reference system of HFS that split meta-data from the data resources is a huge boon to handling various common issues, from rights management to doing "fast" full-tree cloning over a distributed store and several other neat tricks like persistence. The biggest issue with distributed heirarchial file-systems is probably how to handle the full-tree cloning, in a way that isn't crippling, slow, or causes an enforced depth and file limits.