4 ms·
I'm starting to think that the reason we keep building tree-like data structures is because that's how our minds work. We can intuitively grasp hierarchies of
by spin 13y ago
I'm starting to think that the reason we keep building tree-like data structures is because that's how our minds work. We can intuitively grasp hierarchies of categories (a tree structure), with the occasional exception (a symlink to another location).
Because we intuitively see the world in this way, we are good at building and maintaining systems that work in this way.
Anything more sophisticated than that (algebra, relational databases) requires a lot of study and practice to get good at.
- loup-vaillant 13y ago> [Maybe] the reason we keep building tree-like data structures is because that's how our minds work. No. That's how physical space works. When you're a library, and you need your user to be able to find the books, you don't have a choice: any given book must be in one shelf, in one alley, in one room. And bam, you have a tree hierarchy that is three levels deep. But our minds are better at dealing with tags. Just see how popular they are in blogs. I bet that a tag based file system would be vastly better at storing personal data than a hierarchical one.
- spin 13y agoWe could just put all the books in one, big room, just aisles and aisle of shelves, everything numbered sequentially. We could even build a library as one long hallway -- one single line of books. But we choose to divide our buildings up into rooms. We choose to create that hierarchy. Edit: I suppose, though, that our minds evolved to operate in physical space. Go hunt some zebra, go climb a tree... things like that...
- andrewflnr 13y agoEven if you put the books on a single long shelf, chances are you're going to make the numbering system based on the content of the books, like say, the Dewey Decimal system. That's a hierarchy of at least two layers, right there. If you assign random identifiers, you'll probably end up creating that same hierarchy in the index instead, unless you do something more tag-based which is actually likely to be better.
- maxerickson 13y agoBoth is better. There is no reason for the navigation system to ignore groups and hierarchies, it just should also be able to deal with arbitrary tags. Having watched people struggle with what is essentially a configurable search pane (specifically, the excellent thumbnail viewer in Windows Live Photo Viewer), there does need to be a simple default, probably one that looks just like a hierarchical file system. It just shouldn't be the only way to use the system.
- im3w1l 13y agoI spent sometime yesterday thinking about what queries I would like a filesystem (layout) to be able to answer. -installed programs -files installed (except configuration) by a program -files installed (including configuration) by a program -libraries -a users personal files (including configuration). -all files except bare bones install -all files -files on a specific hard drive My conclusion was that my preferred layout would be /os/ - bare bones install /home/ - users files /home/im3w1l/.conf/firefox - my configuration for firefox /programs/ - installed program and libraries /programs/libfuse/.conf - configuration for libfuse /programs/firefox/.conf/im3w1l - my configuration for firefox C:/programs - installed programs on specific hard drive And that if a file is deleted from one place it is deleted from all. So rm /home/im3w1l/.conf/firefox -rf would be the same as rm /programs/firefox/.conf/im3w1l -rf But I think a general tagged system has some problems, most notable filename collisions. Adding a tag to a file could create a collision for instance.
- loup-vaillant 13y agoFor me a basic tag based file system needs several things: A unique ID for files (a strong cryptographic hash of the contents is probably best), a name for each file, and a list of tags for each files. And of course, a number of logical volumes on which the files are "located". Where a directory structure is actually needed, files could have special names, like "/os/glad/file_42" (that's a name, not a path). A variation on this theme would be to do away with explicit names altogether, and only use tags. The "name" of the file would just need to be reasonably unique. That one is probably best. Now, when you search for a file, you just query for tags. Can also be done through the shell: it's just that those two commands would have the exact same effect: cd /foo/bar cd /bar/foo As for the volume, you need them to transfer files between your USB key and your computer. Oh, thinking of using cryptographic hashes to name files… When you modify the file, the ID changes as well… that's a new file! By default, the old version should still be around. Imagine that: Git for the masses.