3 ms·

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 di

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?

hdevalence 1y ago
Yes, I would
90s_dev 1y ago
> 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 1y ago
  > 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.