Hacker News Reader

Comment by duped | Hacker News Reader

A central key-value store that can be programmatically accessed to persist state across users, processes, and boots, that is also strictly typed and hierarchical is quite useful.

I think it would actually be quite useful to have an /etc/conf virtual file system that could be programmatically accessed by user space processes and used as a "dumping ground" just like /etc already is.

View on HN

I think the "central" part is where you lose me with this argument. What advantages does the registry have over application-specific KV stores... besides the potential to interfere with other applications and the OS itself?

Where do you store where the application-specific KV stores are located? Are you just going to hard-code it so the application cannot be moved or installed elsewhere or on external drives? Where does the OS store its own settings?

There are a lot of problems with software "shotgunning" their junk across the system. This isn't exclusive to the Registry or even a specific OS unfortunately. Just go look at what configuration files are located between applications on Linux for example, it is not consistent at all.

Linux is about as consistent as Windows these days. /etc isn’t really a “dumping ground” for everything and is quite static now. Just diffed a snapshot of /etc on my workstation from a month ago and there aren’t really any changes I didn’t put there myself. It’s reasonable to make /etc immutable on a lot of systems; something impossible with the registry.

Home is a bit more chaotic but most applications follow the XDG specs. Mostly. Less so with cache and state files (vscode, for example, dumps tons of cache/state files in .config instead of .cache and .local/state). And weird things like Flatpak shoving everything in .var.

I’d say things generally behave about as well as windows apps which often treat documents as a dumping ground for all kinds of files. I always have to go to pcgamingwiki to find game data locations without having to check half a dozen places.

For administration I really like the /usr and /etc divide. Vendor files go on /usr, and overrides for the running system in /etc. It’s useful to be able to peek in /usr to see defaults.You don’t really get that ability with the registry. With some more modern setups /etc is bootstrapped from /usr (for example, with systemd-tmpfiles) and you can “factory reset” a system by clearing out /etc (with some asterisks around restoring state for a few of the legacy state files still kept in /etc if the system is has manually created users/groups).

>Where do you store where the application-specific KV stores are located? Are you just going to hard-code it so the application cannot be moved or installed elsewhere or on external drives?

I would put that in the same directory as the executable so I can have more than one executable of the same program or the path is simply passed as a command line parameter in the systems unit file.

Compare that to hardcoding the registry key path in the executable...

> I would put that in the same directory as the executable

They're multi-user Operating Systems. Each user needs their own.

Which is how it works in Windows, if you follow Microsoft's own (admittedly confusing) guidelines. Every user has directories for both private and user-visible data, as well as for some half-thought-out feature called "roaming" that I've personally never seen an actual requirement for.

Storing .INI files in the .EXE's directory has been a no-no for many years, and nobody should be arguing for that. But the central registry concept makes even less sense. Use .INIs in your format of choice, and store them in the appropriate user-specific application data folder. Additionally, they should be created when the executable finds them missing, not by the installer.

The latter practice alone solves a multitude of problems, ranging from multiuser support ("Whaddya mean, install for everybody who uses the computer or just me? WTF?" -- your users) to the issue of requiring admin rights at installation time that are not really needed by the program itself.

macOS has a folder called Library where this stuff is supposed to go. It's not enforced by decree, with many apps doing their own horrible thing. Ultimately, its macOS' culture that mostly makes apps puts their settings and other resident details in Library.

I'm not knowledgeable enough to know why a culturally enforced folder is far worse than the database that Windows has. Care to enlighten me?

Linux has ~/.local, ~/.config, and ~/.cache for user-specific program files. Sadly many programs don't respect these and pollute your home directory instead.

Even better are the programs which will stick cache files inside something like ~/.config/appx/mycache . Like a little middle finger from the developer to waste space in my backups.

macOS also has NSUserDefaults which is a similar application (but sometimes developer team?) scoped KV system which is actually just a plist file shoved into ~/Library/Preferences. It's the most similar thing to the Windows Registry in both its intended purpose (small amounts of configuration data) and the ways people abuse it due to its simple interface (storing absolutely everything in it).

I pressume "Program Files" or "AppData" folders are Windows analogy to Library

"AppData" is like $HOME/Library.

"ProgramData" is like /Library.

"Program Files" is like /Applications.

Those are terrible names!

How do you find it? How do you install it? Do you need root/admin permissions to create it? How do you provide access control for it?

There's a lot of value to having something like this "built in" where the plumbing isn't something you worry about. You don't have to worry about the state of your users' file systems (User deleted 'My Documents', User doesn't have a $HOME folder, you don't have write permissions for %AppData%, etc...).

I think if someone went off and redesigned a global KV store for an OS they'd probably require authentication tokens for mutations, so your app would only be able to communicate with the subtrees of the store that it has permissions to (but also, kind of like a file system?)

> I think if someone went off and redesigned a global KV store for an OS they'd probably require authentication tokens for mutations, so your app would only be able to communicate with the subtrees of the store that it has permissions to (but also, kind of like a file system?)

If I had to design an OS from scratch, this is basically what I would do. I'd provide an API for a prefix-tree based KV store with specific data types (eg bytes, utf-8 string, bool, int, float, datetime...) with some mechanism for namespaces and path access controls or the like. Processes would always have their own space to use ad-lib, and would have controlled access to system-wide or cross-process spaces.

This sort of implementation lets you optimize access patterns so that basically each process gets its own KV/db (if it wishes) which should be roughly as performant as rolling its own kv running on the filesystem. Vs all processes all competing for the same data structure, all the time.

I agree with this. Although I would probably make it a pseudo file system and allow normal file reading (you want to dump as JSON? Read /etc/conf/app.json. TOML? /etc/conf/app.toml) as well as something like sysfs (/etc/conf/app/thing). The raw data itself can live at /mnt/conf.

The thing I'm not sure about is how you'd implement secure initialization/registration of a new app on first run.

Interestingly enough, the only thing that's missing from this design from the modern Windows Registry is the generation and usage of user principals. The registry already supports a rich, granular permission system, and enforced sandboxing for access. In a greenfield design, yeah, I could see your design being quite useful, but adapting and enforcing a usage pattern on current day Windows isn't that far off.

Reply on news.ycombinator.com