3 ms·

Purely tag based filesystems are not better than hierarchical filesystems because hierarchy is meaningful. The 'pritam' in `/home/pritam` has a different meanin

Purely tag based filesystems are not better than hierarchical filesystems because hierarchy is meaningful. The 'pritam' in `/home/pritam` has a different meaning than the one in `~/Documents/taxes/pritam`. > Yeah, the filesystem wouldn't work so great if you have thousands of tiny files... but I'd probably argue that you shouldn't have thousands of tiny files in the first place. If your program needs tens of thousands of tiny files then it should probably use something other than the filesystem That's dismissing a core feature of many production file systems today, some of which are used precisely because they support this feature.

geokon 9y ago
That's a valid counterexample! :) The first implies ownership and the other just designates folders with information about 'pritam'. `~/Documents/taxes/pritam` could be a folder on your accountant's computer and then it'd have a different meaning than on your machine. You're not wrong, but I think that that situation is rather rare and rather harmless. In the vast majority of cases the context doesn't change the meaning of the name much. The converse situation, where you have many folders with the same meaning, is a lot more common. You probably have dozens of 'src' 'include' 'build' folders on your machine; and you could have dozens of folders called "June" "August" "September" - all which carry the same exact meaning in their respective contexts. But we've been forced to recreate these redundant folders b/c the system forces us into use a tree structure for concepts that don't necessarily conform to it.
- acoard 9y ago
  >In the vast majority of cases the context doesn't change the meaning of the name much. It absolutely does, and in a vast number of cases I have duplicate folder names. I probably have a hundred different folders on my computer called "src". Knowing that it's ~/dev/projectName/src/ helps me know which src folder it is. For a non-software example, I always organize my client folders somewhat like: ~/clients/A/contracts, or ~/clients/A/designs, ~/clients/A/notes

geokon 9y ago

That's a valid counterexample! :) The first implies ownership and the other just designates folders with information about 'pritam'. `~/Documents/taxes/pritam` could be a folder on your accountant's computer and then it'd have a different meaning than on your machine. You're not wrong, but I think that that situation is rather rare and rather harmless. In the vast majority of cases the context doesn't change the meaning of the name much. The converse situation, where you have many folders with the same meaning, is a lot more common. You probably have dozens of 'src' 'include' 'build' folders on your machine; and you could have dozens of folders called "June" "August" "September" - all which carry the same exact meaning in their respective contexts. But we've been forced to recreate these redundant folders b/c the system forces us into use a tree structure for concepts that don't necessarily conform to it.

acoard 9y ago
>In the vast majority of cases the context doesn't change the meaning of the name much. It absolutely does, and in a vast number of cases I have duplicate folder names. I probably have a hundred different folders on my computer called "src". Knowing that it's ~/dev/projectName/src/ helps me know which src folder it is. For a non-software example, I always organize my client folders somewhat like: ~/clients/A/contracts, or ~/clients/A/designs, ~/clients/A/notes