[unilynx]

This was basically the idea behind the Windows registry - a single configuration store. With mostly the same tree structure on Machine and User level, so your local prefs could override machine-level prefs. The 'user' part was portable between machines on a domain. And you have a single API to access or change settings

Opinions may differ on how well it was executed in practice. I'm not sure /etc/ with its hundreds of different file formats and Ansible or Chefs as an 'API' is that much better

[derefr]

> This was basically the idea behind the Windows registry.

Was it? I got the impression that the original (Windows 3.1) registry was a Windows-internal thing—a store of Windows settings, and a set of APIs to read and modify those Windows settings, e.g. COM/OLE class registrations. (See https://devblogs.microsoft.com/oldnewthing/20080117-00/?p=23...)

But then, third-party ISVs found the registry, and exploited it to store their own settings. And Microsoft being Microsoft, they accepted that unilateral design change and continued on with it.

[bboreham]

Prior to the registry most settings were in files like WIN.INI, and ISVs put settings there. The registry took this idea, added more structure and an API so simultaneous writes don’t screw up.

With the registry, each vendor puts its stuff under a path like HKEY_LOCAL_MACHINE\Software\VendorName, even Microsoft.

[samstave]

Yep. The INI files were the original ways to store config info...

The registry was the next step. What would be great is an online serve for such - a machine gets booted and it asks for your config unam UUID etc - and then just slurps your snapshot down.

[bboreham]

When I first heard about Active Directory (1998?) I thought it would work a bit like this - a distributed Registry.