5 ms·

Why do you think so? I am trying to do a use case and it seems that the usage would not differ that much. The sets are still seen as folders, and have subfolder

by dejan 17y ago

Why do you think so? I am trying to do a use case and it seems that the usage would not differ that much. The sets are still seen as folders, and have subfolders. The only thing is that the subfolder also owns the parent, but that is not noticeable due to the unique direction. What I want to say is that Documents -> University or University -> Documents is the same, thus it makes sense. In real life the order doesn't matter. Thus it opens a path for better HCI: computer, give me all documents from the university (all university documents).. I am curios in what perspective you see this failing?

silentbicycle 17y ago
They could be partitioned by department, so (for example) searching through math research wouldn't have to search the biology department's archives as well.
- dejan 17y ago
  This would allow for defining the context of the search, so that would be a benefit, wouldn't it? Although I am focusing on personal computing, distributed fits too?
  - silentbicycle 17y ago
    Naturally. You might be interested in the filesystem research associated with plan9. :)
malkia 17y ago
Contrived but possible: src/share/test.cpp share/src/test.cpp Also certain implicit build systems, rely on the hierarchy to know what is parent, and what is child. You lose that with sets. I still think it's cool idea, but not for all of your documents... Besides how would you deal with sharing, inheriting security attributes, etc? If I have share/test/something.cpp and share is shared to everyone, would test/share/something-else.cpp got shared too the same way as the first one?
- dejan 17y ago
  Good points. but that form of structuring has been imposed by the nature of directories/files. I am not sure what the right solution would be for that case, perhaps internal tags for a set, but that would make things complicated. In the nature of sets, maybe this could be done: "Source Code", "Shared With XYZ", "Application1" Sharing could be defined on the set, "Shared With XYZ" is a tag that when defined could have the permissions etc. When a file is "placed in it", it is automatically shared. We need to get detached from hierarchical thinking to see the possibilities, which is difficult as it is all present.
- rleisti 17y ago
  Maybe some sort of namespacing on tags would fix that; ie. so that your 'conf' tag for a software project doesn't conflict with the system 'conf' tag, which may have a different set of permissions.
  - silentbicycle 17y ago
    In practice, you would probably have different filesystem tables, so that system:conf+share/filename would be distinct from projects:conf+share/filename. The meaning of the same tag may be different in different contexts.
deleted 17y ago
[deleted]
m0th87 17y ago
I've heard of this concept of 'set-based' filesystems (although with different terminology), and I think it's brilliant. And not just for documents either. Generally speaking, websites have moved away from storing data in a hierarchical matter (e.g. old-school Internet directories), and on to flat, tag-oriented categorization (e.g. delicious) because of the abundance of information to categorize. Hierarchies do not scale and are difficult to change, whereas free-form categorization do not suffer from this. Personal systems have more files on them than ever before, and fitting them to hierarchies that were invented decades ago can be tricky. These issues have been abated for now with things like OS X's Spotlight and Win7's Libraries, but my suspicion is that set-based filesystems would be far simpler than the current paradigm. A good example off the top of my head is resolving what command-line executables are available. In most operating systems, this is done by setting a PATH variable with a list of directories that contain the executables. While this is trivial for the type of people on HN, it is far from for your average user. Instead, command-line executables could be given a specific tag, and the command-line would be able to execute any application that has that tag. Now, whether set-based filesystems could replace hierarchical ones is a different question. Such a filesystem would diverge so greatly from current assumptions that people might be too aversive to change. It wouldn't be the first time; I think Plan 9 was light years ahead in so many respects, but it never took off because it was such a radical departure.
- dejan 17y ago
  That's what I'm thinking too. However, those are assumptions (which I share). I am thinking maybe it would be interesting to see this simulated in the web environment and get feedback on that - web file system. I started playing with tags on Aleveo for that reason, maybe I should take it further on a separate test project. It makes a big difference using it and thinking how it would be used. Also, I am not sure what would be best for executables but how are those currently seen - as having an "+x". Having an executable tag is not much different. That also means, tags are a bit "smarter" than the regular ones seen on the web. I am mostly thrilled by the ability to see the relations of files and folders to others. Those are not folders anymore as "storage units" but "meanings". Also currently a file can exists only in one place. Having symlinks is cruft in my opinion, compensating for the need of multiple context presence of data. Symlink is a separate file, a pointer different than the original. Windows is excluded completely :) I think file can be in several places depending on the need. After all this is not the physical world.

by dejan 17y ago

silentbicycle 17y ago

They could be partitioned by department, so (for example) searching through math research wouldn't have to search the biology department's archives as well.

dejan 17y ago
This would allow for defining the context of the search, so that would be a benefit, wouldn't it? Although I am focusing on personal computing, distributed fits too?
- silentbicycle 17y ago
  Naturally. You might be interested in the filesystem research associated with plan9. :)

malkia 17y ago

Contrived but possible: src/share/test.cpp share/src/test.cpp Also certain implicit build systems, rely on the hierarchy to know what is parent, and what is child. You lose that with sets. I still think it's cool idea, but not for all of your documents... Besides how would you deal with sharing, inheriting security attributes, etc? If I have share/test/something.cpp and share is shared to everyone, would test/share/something-else.cpp got shared too the same way as the first one?

dejan 17y ago
Good points. but that form of structuring has been imposed by the nature of directories/files. I am not sure what the right solution would be for that case, perhaps internal tags for a set, but that would make things complicated. In the nature of sets, maybe this could be done: "Source Code", "Shared With XYZ", "Application1" Sharing could be defined on the set, "Shared With XYZ" is a tag that when defined could have the permissions etc. When a file is "placed in it", it is automatically shared. We need to get detached from hierarchical thinking to see the possibilities, which is difficult as it is all present.
rleisti 17y ago
Maybe some sort of namespacing on tags would fix that; ie. so that your 'conf' tag for a software project doesn't conflict with the system 'conf' tag, which may have a different set of permissions.
- silentbicycle 17y ago
  In practice, you would probably have different filesystem tables, so that system:conf+share/filename would be distinct from projects:conf+share/filename. The meaning of the same tag may be different in different contexts.

deleted 17y ago

[deleted]

m0th87 17y ago

I've heard of this concept of 'set-based' filesystems (although with different terminology), and I think it's brilliant. And not just for documents either. Generally speaking, websites have moved away from storing data in a hierarchical matter (e.g. old-school Internet directories), and on to flat, tag-oriented categorization (e.g. delicious) because of the abundance of information to categorize. Hierarchies do not scale and are difficult to change, whereas free-form categorization do not suffer from this. Personal systems have more files on them than ever before, and fitting them to hierarchies that were invented decades ago can be tricky. These issues have been abated for now with things like OS X's Spotlight and Win7's Libraries, but my suspicion is that set-based filesystems would be far simpler than the current paradigm. A good example off the top of my head is resolving what command-line executables are available. In most operating systems, this is done by setting a PATH variable with a list of directories that contain the executables. While this is trivial for the type of people on HN, it is far from for your average user. Instead, command-line executables could be given a specific tag, and the command-line would be able to execute any application that has that tag. Now, whether set-based filesystems could replace hierarchical ones is a different question. Such a filesystem would diverge so greatly from current assumptions that people might be too aversive to change. It wouldn't be the first time; I think Plan 9 was light years ahead in so many respects, but it never took off because it was such a radical departure.

dejan 17y ago
That's what I'm thinking too. However, those are assumptions (which I share). I am thinking maybe it would be interesting to see this simulated in the web environment and get feedback on that - web file system. I started playing with tags on Aleveo for that reason, maybe I should take it further on a separate test project. It makes a big difference using it and thinking how it would be used. Also, I am not sure what would be best for executables but how are those currently seen - as having an "+x". Having an executable tag is not much different. That also means, tags are a bit "smarter" than the regular ones seen on the web. I am mostly thrilled by the ability to see the relations of files and folders to others. Those are not folders anymore as "storage units" but "meanings". Also currently a file can exists only in one place. Having symlinks is cruft in my opinion, compensating for the need of multiple context presence of data. Symlink is a separate file, a pointer different than the original. Windows is excluded completely :) I think file can be in several places depending on the need. After all this is not the physical world.