Personally, i dream of a stateless, tag/attribute-based, tree-less operating system. “directories” would not be neccessary but a tag could be displayed as one in file managers. Want to load a library? type:library, name:xyz it is.
Stuff is there on the disk anyway, you just have to identify it.
But that would require the kernel, a file system and the tooling made for this.
But maybe we get there; since the young generation isn’t used to file trees anymore.
I think what you’re looking for is simply an indexer + UI that sorts your filesystem by tags rather than by directory structure. Not sure if that’s as beneficial as you imagine it to be, but IIRC KDE allows you to do something like that in Dolphin.
No, they always have to keep a index uptodate. And no synch (or even compatibility) with other such tooling. Only thing that comes close currently is xattributes some fs support. But they are wholly a undefined blank slate.
Dolphin (well, whatever the KDE’s indexer is called) uses xattrs under the hood for tagging, so it will be compatible with other software (including {get,set}fattr).
The index has to be up-to-date, but then that would be true with any tag-based filesystem, it’s just happening on a different layer (and arguably a layer which is more suitable for this - not sure it’d be a good idea to enforce synchronous indexing during xattr writes).
The most significant user-facing obstacle is lack of software which supports this system, but I guess that shows that there’s not much desire for it in reality.
Right, i remembered KDE using xattr just after writing the answer. But still, only a KDE convention how the data is stored, not a fs convention.
But my point was, we could entirely get rid of file trees. How many times did i wish, find slowly traversing the fs tree, that you could define a bit more details than the name and roughly if it is a file, a directory or a symlink. Working on a small trashdir shell script currently, there is a .trashinfo file with the date deleted and the last used path; that’s a hack, not a solution. The fs index could contain things like mime type, intended use (library, executable, plaintext), advanced security context, deleted/visibility, without storing a tree the tooling has to hang on to. Finding stuff on the whole disk could be instantaneous.
And yeah, of course this would be incompatible to everything *nix and Windows currently. Which is why i think it would need to be a whole new OS (with compatibility tooling to *nix). Current *nix kernels have a lot of Server-centric assumptions the distro tooling has to work around for desktop use anyway. The file systems also, they were made for server-centric use in times of MB, not TB. ext3/4 are just iterations over the old thing, with better optimized algorithms and so on.
But even in NixOS there are issues with non-FHS paths. And the kernel expects some paths too, also the whole bootstrapping thing. Sure, they could just be adapted.
Personally, i dream of a stateless, tag/attribute-based, tree-less operating system. “directories” would not be neccessary but a tag could be displayed as one in file managers. Want to load a library? type:library, name:xyz it is.
Stuff is there on the disk anyway, you just have to identify it.
But that would require
the kernel, a file system and the tooling made for this.But maybe we get there; since the young generation isn’t used to file trees anymore.
Edit: ok, scratch the kernel, it could work.
I think what you’re looking for is simply an indexer + UI that sorts your filesystem by tags rather than by directory structure. Not sure if that’s as beneficial as you imagine it to be, but IIRC KDE allows you to do something like that in Dolphin.
No, they always have to keep a index uptodate. And no synch (or even compatibility) with other such tooling. Only thing that comes close currently is xattributes some fs support. But they are wholly a undefined blank slate.
About advantages, no broken paths would be one.
Dolphin (well, whatever the KDE’s indexer is called) uses xattrs under the hood for tagging, so it will be compatible with other software (including {get,set}fattr).
The index has to be up-to-date, but then that would be true with any tag-based filesystem, it’s just happening on a different layer (and arguably a layer which is more suitable for this - not sure it’d be a good idea to enforce synchronous indexing during xattr writes).
The most significant user-facing obstacle is lack of software which supports this system, but I guess that shows that there’s not much desire for it in reality.
deleted by creator
Right, i remembered KDE using xattr just after writing the answer. But still, only a KDE convention how the data is stored, not a fs convention.
But my point was, we could entirely get rid of file trees. How many times did i wish,
findslowly traversing the fs tree, that you could define a bit more details than the name and roughly if it is a file, a directory or a symlink. Working on a small trashdir shell script currently, there is a .trashinfo file with the date deleted and the last used path; that’s a hack, not a solution. The fs index could contain things like mime type, intended use (library, executable, plaintext), advanced security context, deleted/visibility, without storing a tree the tooling has to hang on to. Finding stuff on the whole disk could be instantaneous.And yeah, of course this would be incompatible to everything *nix and Windows currently. Which is why i think it would need to be a whole new OS (with compatibility tooling to *nix). Current *nix kernels have a lot of Server-centric assumptions the distro tooling has to work around for desktop use anyway. The file systems also, they were made for server-centric use in times of MB, not TB. ext3/4 are just iterations over the old thing, with better optimized algorithms and so on.
You described a file system. You can make that system easily and put in any os. You don’t have to make and os for one feature.
But even in NixOS there are issues with non-FHS paths. And the kernel expects some paths too, also the whole bootstrapping thing. Sure, they could just be adapted.
Wouldn’t it just require a kernel module rather than a whole kernel?