deleted by creator

deleted by creator

What, if the US with their genocidial history can play world police…

deleted by creator

deleted by creator

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

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.

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.

While i agree that a standard is useful, i think the FHS is out of date: it has lot’s of fragmentation where it is not needed anymore, instead of keeping it simple. And also lots of reinterpretations, which makes it even more confusing.
Which results in some people who learned FHS thing (but never why it happened) keeping slave-ish to it and doing nonsense in major distros. Which, again, results in small niche distro being forced to it too, because they lack the manpower to adapt the tooling.

or just want to use some obscure software in general, then yeah, things can get more complicated…

Well thanks, so NixOS is not for me then.

deleted by creator

At this point, FHS feels more like a hindrance to me. Also, it was made in a time with very limited disk capacity and personal computers weren’t much of a thing yet.

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.

Btw, why is there no container format for lightweight markups? So you can carry embedded media with it…

What you see is not what you wanted.

Archaic shit.

deleted by creator

Basically a lightweight markup (instead of xml) in a container to carry media and styles with it?

but the gaming performance is a bit low now with all of the spectre mitigations

If it’s only gaming, you can disable them. Although i heard rumors, that some things work better now with the mitigations enabled than without.