Doesn't that describe disk filesystems too? And Unix file namespace in particular (a single hierarchy unifying several block devices, just like registry is composed of several on-disk files)? What about all that junk in one's $HOME?
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).
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?
Over on one end you have papersize, a file containing a single word with seemingly no relation to any installed software. In httpd.conf we have a sort of SGML that’s mostly line oriented CDATA. aliases and many other mail files are all members of the Berkeley DB lineage of key value stores. default/ feels like it’s also a key value store but one suspects that one could probably put a command in there and something would execute it. rc.d is 99% code but with semantics in the symlinks too (see also Debian’s alternatives.) A very large number of files look like braced C code; named.conf even requires terminal semicolons!
There’s no value in either consistency or diversity of the underlying implementation be it a registry — the registry, or a gconf thing — or a filesystem smorgasbord of config languages. Without the discipline (authoritarianism?) of a social structure — for example a “company” with a hierarchical leadership that can promote/fire you — you will get diversity in any system.
I just reminded myself of the time I used ansible YAML Jinja templates to control EdgeRouter config files that programmatically built config in /etc. Time for a leisurely stroll in a real garden I think, far away from a computer.
Sure. ulimit or cgroups can.
But this thread is getting distracted. That's a separate issue, and the applications in question can still pollute all they want within their container.
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.
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.
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?
"ProgramData" is like /Library.
"Program Files" is like /Applications.
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).
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...
They're multi-user Operating Systems. Each user needs their own.
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.
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?)
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.
The thing I'm not sure about is how you'd implement secure initialization/registration of a new app on first run.
For instance, most EA games from the early 2000's standardized the store of the CD key in ~HKLM:\SOFTWARE\<Game Name>\ergc. This would let one install the game to any drive and still have access to the CD key.
Games also use the registry as a way to point to where the game is installed. In the worst case scenario, it's used as a dumping ground for the game's preferences/settings and save states. With the shift to 64 bit and the introduction of WoW64 and most recently the shift to VirtualStores, I would rather nobody ever stores anything in the registry.
I'm currently working on a compatibility shim geared towards games that will redirect winapi filesystem and registry calls to a custom location. Hopefully it'll result in being able to make more portable installs of games that may require access to the registry.
I believe in Windows there's even $SHARED/.config
If you need to start manipulating configuration files, then you need to deal with all the complexities of that.
The registry is great for exactly this sort of config info. And on Windows, HKLM (HKEY_LOCAL_MACHINE) is for system-wide stuff. If it were per-user config it'd go in HKCU (HKEY_CURRENT_USER).
The real issue is that this is known since Win 95 days , yet some people don't get it.
Some times it is a relaxation of requirements though. Some people might want/need account deletion to also remove all the content related to the account transactionally, etc, and if that's a requirement, everything account related must be in a transactionable system.
If you can be more flexible on that, separating account management from other data is pretty common in my experience.
The equivalent of "separate microservices" is making sure multiple programs don't share registry keys, and that's already the case 99% of the time for this kind of key.