Earlier quoted context omitted.
Awesome writeup! This goes right to the printer :)
Printing it out because it's too long to read on screen? (Maybe I have failed as a writer to be concise)
He's just old.
Tagsistant: semantic filesystem for Linux
51–60 of 71 posts
Re: Tagsistant: semantic filesystem for Linux
#52Re: Tagsistant: semantic filesystem for Linux
#53Build a new website. This one is not working.
Re: Tagsistant: semantic filesystem for Linux
#54Hierarchical file systems lack expressiveness and are awkward in places. In my day-to-day computing this has become more apparent and problematic with each passing year. For example, I dislike that you are forced to give unique names for each file, that you can classify each file in only one way, and that you can't tell how many copies you own of a piece of data. The smallest step up from a hierarchical file system i…
I remember for a while Google Drive worked on a tags metaphor and it was just too much friction for users. The UI for the traditional file tree is just plain cleaner. Trees provide clear delineations of ownership and categorization. They suffer from the limits of hierarchies, but you can break them down and get a nice tree-view of them, for example. Having spent time categorizing my photos, adding a tag layer on top…
As long as the tags themselves can be hierarchical, can't you recover all the benefits of a tree-like file structure?
Re: Tagsistant: semantic filesystem for Linux
#55Humans have to tag the files, though. This is the same problem which kept the "semantic web" from going anywhere.
Humans already have to pick a path and name for the file in a hierarchical filesystem. I don't see how this is any more difficult, and it might even be easier.
One of the problems might be that humans tend to be not very consistent over longer periods of time. So choosing a set of tags which will stay useful for, say, 10 years is hard. Because of this "tag rot" is likely to happen. After a long time, when you're looking for a certain file you might not remember the tagging scheme you applied at the moment you tagged the file you're looking for.
Re: Tagsistant: semantic filesystem for Linux
#56Now we just need a redesign of Unix tools and principles/practice to accommodate these :-S
That's actually a fairly reasonable conclusion. You'd want to have tools which are aware of a semantic filesystem, or new tools which can make use of them. Probably a mix of both. Wrappers around extant tools might be a reasonable migration path toward the former.
There was a concept of "db-fs", whereby rather than files in a hierarchical folder structure, you just had blobs/collections of data you could search via the usual search-queries. I suppose similar structure to the average no-sql/JSON db, but as a file-system.
The problem is, it isn't even compatible with the usual interface for a fs driver (read/write, permissions etc). There is no "search" concept in the fs conceptual model. The model assume, to some extent, a finite-size mount, duplication/multi-reference is only poorly supported/emulated via hard/soft links.
plus, existing tools would, as you mention, have no support for what would now be build into the fs - functionality such as provided by 'find' would be now built in, such that you would need a shell syntax/dsl to utilize.
My best guess would be a 'special' query command that would result in a virtual folder popping up on a special virtual fs mount, e.g:
> mk_qdir *some-search-query*
/proc/srch/023013/
Re: Tagsistant: semantic filesystem for Linux
#57I've never been able to figure out what people mean by "tags" and what the benefits are, perhaps someone can enlighten me? I feel like the only problem with standard hierarchical file systems is that sometimes you want files to show up in multiple places. I think this is only a subset of files, typically "media." A photograph or a song often has multiple categorizations. However, a lot of things, like my tax document…
I think tags only prove beneficial when you have a very well defined purpose. More concrete, I think the number of tags has to be fairly limited and the logic behind the tagging scheme should stay consistent forever.
One example of tags being superior to links is that you can search files with logical queries. For instance, a family member asks you to send them a good portrait of you for whatever reason. You may want to make sure that it is somewhat recent. However, you're willing to take one that is two years old if it looks better. Then you could search for: #portrait & #me & #2017 & #2016 & #2015
Re: Tagsistant: semantic filesystem for Linux
#58Earlier quoted context omitted.
I remember for a while Google Drive worked on a tags metaphor and it was just too much friction for users. The UI for the traditional file tree is just plain cleaner. Trees provide clear delineations of ownership and categorization. They suffer from the limits of hierarchies, but you can break them down and get a nice tree-view of them, for example. Having spent time categorizing my photos, adding a tag layer on top…
As long as the tags themselves can be hierarchical, can't you recover all the benefits of a tree-like file structure?
This. I believe a hierarchy of tags is a great solution.
Re: Tagsistant: semantic filesystem for Linux
#59Earlier quoted context omitted.
That's actually a fairly reasonable conclusion. You'd want to have tools which are aware of a semantic filesystem, or new tools which can make use of them. Probably a mix of both. Wrappers around extant tools might be a reasonable migration path toward the former.
There was a concept of "db-fs", whereby rather than files in a hierarchical folder structure, you just had blobs/collections of data you could search via the usual search-queries. I suppose similar structure to the average no-sql/JSON db, but as a file-system. The problem is, it isn't even compatible with the usual interface for a fs driver (read/write, permissions etc). There is no "search" concept in the fs concept…
Good point on mount counts.
Doesn't that problem already exist to an extent for remote FS mounts (NFS, etc), especially over automount?
Re: Tagsistant: semantic filesystem for Linux
#60Earlier quoted context omitted.
There was a concept of "db-fs", whereby rather than files in a hierarchical folder structure, you just had blobs/collections of data you could search via the usual search-queries. I suppose similar structure to the average no-sql/JSON db, but as a file-system. The problem is, it isn't even compatible with the usual interface for a fs driver (read/write, permissions etc). There is no "search" concept in the fs concept…
Good point on mount counts. Doesn't that problem already exist to an extent for remote FS mounts (NFS, etc), especially over automount?
Yep, if the external mount is large.
However, it's a little different for an fs system that can quickly (w/o network-speed limits) generate recursive fs structures.
for example, what if a created a vfs that created a 'foo' folder, with a 'foo' folder inside, and so on. The system would crawl an infinite descent of /foo/foo/foo/foo... and so on, which would eventually fill some cache or another.