Certainly not for me. Registry was one of the worst parts of the Windows experience for me; but I understand it can be subjective.

With separate files, the ability to download and replace them individually is a big win. Also, I can use terminal tools on them which is great for automation.

I've never understood the criticism of the registry. The only times I've ever had an issue with it were when there were RAM or disk problems with the computer. On Windows there's nothing at all stopping developers of standard Windows applications from implementing their own config files and many do.

1. Most of the programs put things all over the place. If you install software and use it for a while, you may find lots of keys in lots of places, all subtly affecting something.

It’s technically the fault of the program, not the registry. But culture and ecosystems matter, and by-and-large, Config in files is usually much more concentrated.

2. Related to (1), it is very hard to just move settings from one machine to another. How do you export your settings related to program X in order to use it on another machine? I keep my Linux config files in a git repository - I can easily track history and clone it to new machines. What’s the registry equivalent?

3. It is incredibly slow. When I still used windows, if I needed to do some registry editing, I would dump it to a text file, edit and then import the edited keys. That took about 1/10 of the time doing the same took in ResEdit.

For your first point, that's often the result of using third party libraries via COM. That COM library is its own thing and it wouldn't make a lot of sense to put all of its settings under your app. Plus, some parts of the registry (thinking of CLSID) are basically directories where the system looks when a program says "give me an instance of ThirdParty.Grid".

I agree to the above in a painful way. I don't think of myself as a power user but I have at times to clean up the registry for stuff that uninstallers missed because the updated application does not want to install. It's a complete mess of having to dig through a tip to find a broken match box so you can destroy it without setting on fire the whole thing.

Meanwhile OS X or Linux don't suffer from this and working with applications is a lot more "streamlined". As I said, this is just a slightly above average skilled end-user perspective.

My experience with GNOME configuration repository, or files scattered around /etc, /opt/etc and /share kind of tells otherwise

it's nicer using PowerShell. `cd hklm:\` and bob's your uncle.

Registry never made much sense on the local system: just use the filesystem. I assume there was once a plan to use it in a networked fashion. But Active Directory replaced it for that purpose.

The filesystem isn't inherently bad, but the lack of a standard config format, location, and APIs is quite terrible. There's no reason a thousand programs should have a thousand different ways to be configured, it's just a legacy of poor design with no standardization.

Actually there is a standard location for user settings: https://specifications.freedesktop.org/basedir-spec/basedir-...

Dconf complements it: https://wiki.gnome.org/Projects/dconf and dconf-editor is even similar to regedit.

For system settings... that is a bit more complicated.

It's not poor design because it wasn't really designed in the first place...because it didn't really need to be designed.

There is a standard and it's minimal:

- config files are text files - # indicates a comment

Why standardize further when the types of programs that require config files run an extremely wide gamut? Types of programs can be as diverse as web servers, graphic editors, kernel modules, networking programs, etc. Each are vastly different. I don't need to wait for, worry about, or try to install an updated registry processor that knows about new object types. Better to build it into the program or rely on a library. Why change the entire system of configuration storage just for one new type of program?

And text files are awesome for another reason: With the ability to comment config files you can understand any format - as well as include notes and conveniently have documentation where you need it.

Also: You can't use git or other versioning to backup your registry keys and rollback to previous versions.

For Windows, it's faster than accessing the file system (thanks to file system filter drivers).

Editing the registry never results in corrupt unreadable intermediate states, unlike writing to config files. A workaround is "atomic save" (where one app writes to a different filename and renames it over the original). This ensures you'll never get torn reads (I think the Windows registry doesn't support transactional/atomic updates of multiple values at once), but you lose permissions and symlinks or something like that.

Of course it did /does, and depending on how badly the registry corruption was, the whole system could be rendered unbootable.

It could and it did, but honestly, I personally have never seen any Win10 endpoint with any registry issues since it came out.

Have you never experienced an unbootable system because of a corrupted registry? It's unfixable. And I'm not saying it happens when manually editing the registry. It might happen when Windows crashes at the wrong time and the system is in the middle of modifying it. It's quite failure-prone and I'm surprised it hasn't been improved much over the past decades.

Somehow I've never gotten a corrupted registry resulting in a broken account or system. Perhaps I'm lucky or too innocent in this regard. Though it does sound concerning if the Windows registry doesn't perform write-ahead logging like SQLite or a client-server database to enable crash recovery.

I should research what key-value database libraries I can use as a cross-platform registry-like storage format that's more resilient to app or system crashes.

You can use terminal tools on the registry fwiw. Powershell provides a native PSProvider that exposes the registry like a file system so you can cd into it and make changes.

Personally I like the Mac plist system the best. It just works, and it works so well that you never hear about it because no one ever complains about it!

There are at least three different formats for plist files, and the tools are differently broken depending on the format. There are some really odd cases like terminal colour settings which are stored in the plist as a pickled object, so you have to use the gui to adjust a colour rather than (say) using css syntax.

No settings format can force a programmer to make good decisions. A Windows developer could put a .Net binary serialized object into a blob registry key.

> many programs have their own idiosyncratic rules around which config paths take precedence over others.

The place where programs put their config in Windows Registry is as if not more idiosyncratic.

AIX has a registry like thing called the ODM. I think it’s an interesting take on centralizing config on UNIX.

Fairly horrific to use, but I always appreciate unorthodox designs in operating systems. They’re exceedingly rare these days.

On the contrary, having configuration in text files allows using different formats depending on the needs of the application.

Also, it allows the use of git to track changes on config files and even replicate them across hosts.

etckeeper for /etc is wonderful.