3 ms·

Ignores the obvious benefit of the classical filesystem, which is that all data inherits an enormous amount of generic functionality from it: organization, inte

Ignores the obvious benefit of the classical filesystem, which is that all data inherits an enormous amount of generic functionality from it: organization, interop, sharing, backup, versioning, etc. File systems don't need to die, they need to grow up and provide the things that apps always have to implement over top of them: - user-centric interface that shows data in a way that makes sense to them: documents, apps, messages, contacts, etc. - non-hiearchal structure, views based on search, filter, sort - database-like performance and semantics e.g. indexes, transactions - structured data that is trivial to load/save from any programming language I believe that all this can be had while preserving the benefits of flat files, but it's an enormously ambitious undertaking and the only sort-of-attempt that I'm aware of (WinFS) never even shipped, let alone caught on.

fragmede 17y ago
The original Palm Pilot had no file system. There were databases, which you could open and read/write records to/from. I feel it worked pretty well, but soon newer devices came out with so much more ram that it devolved into unusably long lists of databases. Current filesystems and their hierarchical folder structures give an easy-to-understand layer of abstraction without a whole lot of complications. For improvements on the hierarchical part, the expansive list of filesystems using FUSE (http://sourceforge.net/apps/mediawiki/fuse/index.php?title=FileSystems http://sourceforge.net/apps/mediawiki/fuse/index.php?title=F...) has some interesting filesystems. Maybe the author can find some likable ideas there?
- extension 17y ago
  The hierarchical filesystem was invented back when UI and API were the same thing and it hasn't moved past that. You wouldn't tolerate a UI that was full of dangerous "system buttons" labeled with user-hostile jargon. You wouldn't use a user-entered mutable title field as an indexed unique key in a data schema. FUSE is great but it abstracts the back end, not the interface. That's a seperate issue. Platforms like J2ME with object persistence solve half the problem. Fast access to structured data is a breeze, but the user has no control. All data is meaningful to the user at some level, even if it's as shallow as "Settings for the Blah app" or "The entire Blah app". If an object persistence platform forced all data to be wrapped in a user-meaningful container, which the user could manipulate atomically but not look inside, that would give you the best of both worlds. It would probably also encourage more modular and interoperable data design.

fragmede 17y ago

The original Palm Pilot had no file system. There were databases, which you could open and read/write records to/from. I feel it worked pretty well, but soon newer devices came out with so much more ram that it devolved into unusably long lists of databases. Current filesystems and their hierarchical folder structures give an easy-to-understand layer of abstraction without a whole lot of complications. For improvements on the hierarchical part, the expansive list of filesystems using FUSE (http://sourceforge.net/apps/mediawiki/fuse/index.php?title=FileSystems http://sourceforge.net/apps/mediawiki/fuse/index.php?title=F...) has some interesting filesystems. Maybe the author can find some likable ideas there?

extension 17y ago
The hierarchical filesystem was invented back when UI and API were the same thing and it hasn't moved past that. You wouldn't tolerate a UI that was full of dangerous "system buttons" labeled with user-hostile jargon. You wouldn't use a user-entered mutable title field as an indexed unique key in a data schema. FUSE is great but it abstracts the back end, not the interface. That's a seperate issue. Platforms like J2ME with object persistence solve half the problem. Fast access to structured data is a breeze, but the user has no control. All data is meaningful to the user at some level, even if it's as shallow as "Settings for the Blah app" or "The entire Blah app". If an object persistence platform forced all data to be wrapped in a user-meaningful container, which the user could manipulate atomically but not look inside, that would give you the best of both worlds. It would probably also encourage more modular and interoperable data design.