I've thought a lot about stuff like this and this is pretty cool but this basically looks like just a tagging system for files, which already exists in many ways. A true graph based file system wouldn't just be an overlay over a directory tree. Would love to see some kinda filesystem dedicated to graph representation, where each file is a node with multiple edges.
I'm always on the lookout for something like this. tmsu is pretty close, but have you found anything better? There's a paupacy of software for Linux in this space, and I don't understand why.
Why stop at a tag-based file manager? Why not a tag-based filesystem?
I was thinking BeOS's BFS since that was the closest I knew off the top of my head, but tmsu looks awesome. I love that simple command line interface around it.
That kind of storage might somewhat work for media files and simple tags if you only view the files in the tag-aware file manager but what about other applications and files?
If the path of a file changes every time you add a tag or remove one that means the path of files is very unstable so you can't e.g. reopen the last used files in other applications easily. I also don't think this scales to the billions of files on a modern system. And of course any files required by an application to be in a specific place will be screwed up completely by this.
Maybe the tag directories should be hard links to the actual files instead?
I don't see how the tag => file path will be workable. As you add and remove tags, your actual file system is going to go strait to hell. Dear god I don't want to think about what that would be like to browse from the terminal
It uses the Python binding for GTK. Yeah, that's a big no for me.
I barely use GUI apps, but beyond that my only strong adverse reaction is to cancerous Electron platform. So: why the hard no specifically on the Python GTK bindings?
Lately, I've started to hate scripted languages. That's all I've got to say. You know, overhead and stuff? And well, much of it is just projection about how I can't land even internships, because I decided to flunk on Golang and Rust. Ruby and Python ruined my early-career.
Been there. But, while I have a preference for statically compiled languages with minimal runtime-linked libraries, when it comes to GUIs, the horses are already out of the barn, right? So I don't sweat it as much for software I'm getting from the distribution's repos.
Take a look at the readme...
😭😭🤧
I've thought a lot about stuff like this and this is pretty cool but this basically looks like just a tagging system for files, which already exists in many ways. A true graph based file system wouldn't just be an overlay over a directory tree. Would love to see some kinda filesystem dedicated to graph representation, where each file is a node with multiple edges.
I'm always on the lookout for something like this. tmsu is pretty close, but have you found anything better? There's a paupacy of software for Linux in this space, and I don't understand why.
Why stop at a tag-based file manager? Why not a tag-based filesystem?
Like tmsu? Or did you have another in mind?
I was thinking BeOS's BFS since that was the closest I knew off the top of my head, but tmsu looks awesome. I love that simple command line interface around it.
That kind of storage might somewhat work for media files and simple tags if you only view the files in the tag-aware file manager but what about other applications and files?
If the path of a file changes every time you add a tag or remove one that means the path of files is very unstable so you can't e.g. reopen the last used files in other applications easily. I also don't think this scales to the billions of files on a modern system. And of course any files required by an application to be in a specific place will be screwed up completely by this.
Maybe the tag directories should be hard links to the actual files instead?
I don't see how the tag => file path will be workable. As you add and remove tags, your actual file system is going to go strait to hell. Dear god I don't want to think about what that would be like to browse from the terminal
It uses the Python binding for GTK. Yeah, that's a big no for me.
I barely use GUI apps, but beyond that my only strong adverse reaction is to cancerous Electron platform. So: why the hard no specifically on the Python GTK bindings?
Lately, I've started to hate scripted languages. That's all I've got to say. You know, overhead and stuff? And well, much of it is just projection about how I can't land even internships, because I decided to flunk on Golang and Rust. Ruby and Python ruined my early-career.
Been there. But, while I have a preference for statically compiled languages with minimal runtime-linked libraries, when it comes to GUIs, the horses are already out of the barn, right? So I don't sweat it as much for software I'm getting from the distribution's repos.