this post was submitted on 31 Jan 2026
209 points (98.6% liked)

Linux

11701 readers
460 users here now

A community for everything relating to the GNU/Linux operating system (except the memes!)

Also, check out:

Original icon base courtesy of lewing@isc.tamu.edu and The GIMP

founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] MonkderVierte@lemmy.zip 5 points 2 days ago* (last edited 4 hours ago) (8 children)

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 whole 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.

[–] balsoft@lemmy.ml 0 points 20 hours ago (1 children)

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.

[–] MonkderVierte@lemmy.zip 1 points 20 hours ago* (last edited 4 hours ago) (1 children)

~~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.

[–] balsoft@lemmy.ml 2 points 20 hours ago (2 children)

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.

[–] MonkderVierte@lemmy.zip 1 points 20 hours ago* (last edited 4 hours ago)

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 higher limits, better optimized algorithms, and so on.

load more comments (6 replies)