[qwertox]

I can't agree with this. I like it that I can have all these tools which work with files and are tools which are not db-oriented, and the fact that there are different filesystems for different scenarios, that I can sandwich LVM between a FS and the block device. That /proc/ can pretend to be a FS because else we'd possibly end up with something like the Windows Registry for these operations, only managed through a database.

Would you store all your ~/ in something like SQLite database?

[90s_dev]

> Would you store all your ~/ in something like SQLite database?

Actually yeah that sounds pretty good.

For Desktop/Finder/Explorer you'd just need a nice UI.

Searching Documents/projects/etc would be the same just maybe faster?

All the arbitrary stuff like ~/.npm/**/* would stop cluttering up my ls -la in ~ and could be stored in their own tables whose names I genuinely don't care about. (This was the dream of ~/Library, no?)

[edit] Ooooh, I get it now. This doesn't solve namespacing or traversal.

[fc417fc802]

> This doesn't solve namespacing or traversal.

That's "just" API. FS is "just" a KV store with a weird crufty API and a few extra tricks (bind mounts or whatever).

I think the primary issue is the difference in performance between different strategies. It would be interesting to have a FS with different types of folders similar to how (for example) btrfs is generally CoW but you can turn that off via an attribute.

[hdevalence]

Yes, I would