The
concept of the registry is just fine. The implementation had a few small architectural issues, but throwing out the concept because of a single specific implementation is a mistake.
Text files have MORE problems, not less. Your familiarity with them and your unfamiliarity with the registry doesn't make text files better, it makes them more familiar. Similarly, even if you know the Windows Registry well, that's the Windows-specific implementation that dates back to the 1990s!
If the registry concept was re-done today, with all of the lessons learnt across decades of software pattern evolution, it would be done differently.
What you probably don't realise is that Registry provides an awful lot that prevents every developer having to reinvent in a Unique and Special Way that is incompatible with everything else.
It gets "right" the following:
- Hierarchical storage of key/value data.
- A single consistent GUI and API across all application settings.
- Permissions on a per folder path and/or per key basis.
- Integrated audit logging for all access, including both read and write access, down to the individual key level.
- Binary (byte array) data stored natively.
- Strong typing for 32-bit and 64-bit integers.
- Special string types such as "substitute environment variables in this string" vs "just a plain string".
- Layering of settings. E.g.: Machine, User, Default, etc...
- Integration with the Group Policy engine, where there are "policy enforced" and "default preferences" that can be pushed out centrally.
That last one needs expanding, because Linux has NOTHING like it, and alternatives don't even come close. The policy engine is declarative, with a "template" file specifying the keys and allowed values. This has matching multi-lingual files so that administrators that don't speak English can see the names and multi-paragraph descriptions in their native language. The policy settings apply and un-apply in layers automatically. Moving locations can automatically deploy a setting, and then wind it back if you return to your original location. Thousands of settings can be centrally administered by one admin for tens of thousands of machines with a few mouse clicks. Linux config files are a single layer and are effectively write-only. You can't read them with an API or merge/unmerge changes on the fly. There is just no way to solve this problem with general text-files.
If I were to reinvent registry files now, in 2022, I would just fix a few implementation specific annoyances:
- More strong types. E.g.: network addresses, DNS names, GUIDs, etc...
- The "layering" of Group Policy is manually implemented in app code, so most apps outside of the Enterprise space don't have policy integration. I would make the policy settings automatically overlap the same key names so that they're merged by the "registry engine" instead of the app.
- Writing arbitrary values into a single share hive is a mistake. I would create a hive-per-application.
- Requiring kernel transitions for registry key reads is also a mistake. The "user" hives belonging to individual applications ought to be accessed directly by the associated app processes. I've seen hacks that implement this using API rewrites that improve the performance of some business applications by 20-40%!
- Registry hives should have "layers" much like Docker files in the physical sense, not just the logical sense. So for example an application patch would be a new delta layer over the base layer, but then policy would always layer on top of the latest patch, whatever that may be.
- Stronger tooling for developers. Make policy template files trivial to create. The template files should auto-generate matching strongly typed configuration objects in multiple languages, and these should also integrate with CLI command parsers, environment variable overrides, etc...
- Use a more standard base storage format, such as SQLite.
- Make it cross-platform and open-source.
- Similarly, the policy engine shouldn't be so closely tied to a single product (Active Directory), but should be a pluggable module that large-scale enterprise software can also reuse as an internal component. Think Citrix, Anti-Virus products, Backup, etc... anything that needs to manage hundreds of servers from a console with policy, preferences, etc...