28 ms·
No, because the filesystem is one layer of abstraction lower than the registry. There's nothing with less bottleneck to the filesystem besides raw device access
by kortex 3y ago
No, because the filesystem is one layer of abstraction lower than the registry. There's nothing with less bottleneck to the filesystem besides raw device access. The registry runs on top of the filesystem. If you wish to use the registry for filesystem-like purposes (eg storing startup config specific to the app or user state), just use filesystem. If you wish to use it like a database for system-wide information, that's a better use-case, but the registry isn't quite a proper database.
Windows programs proliferate $HOME junk, too. And that's an issue in its own right, which should be addressed by platform-specific application dirs (e.g. the platformdirs library for python).
- Joker_vD 3y ago> No, because the filesystem is one layer of abstraction lower than the registry. That doesn't prevent it from becoming a KV dumping ground for every process and their dog to litter with whatever, at all. Not in the least because it's already that, which a cursory look through /tmp and /var supports. > There's nothing with less bottleneck to the filesystem besides raw device access I thought there was considerable effort from the Linux kernel team spend on parallelization of the inode and buffers management but if you say that the main bottleneck is the raw device speed then sure, I'll believe you. It's not like NVMe protocl has design with 64K command queues each 64K command long because the OS simply can't saturate the device's bandwith otherwise, right?