> The registry is a single point of failure. That's why every single registry editing tip you'll ever find starts with a big fat screaming disclaimer about how

> The registry is a single point of failure. That's why every single registry editing tip you'll ever find starts with a big fat screaming disclaimer about how you can break your computer with regedit. Back in the INI days you could prevent Windows 3.x from starting, too. > The registry is opaque and binary. As much as I dislike the angle bracket tax, at least XML config files are reasonably human-readable, and they allow as many comments as you see fit. XML/INI/JSON config files will be slower than registry access. > The registry has to be in sync with the filesystem. Delete an application without "uninstalling" it and you're left with stale registry cruft. Leaving stuff behind is a fair point, but there's no impact to the system. It just appears to be visibly messy to the user (and why are you spending that much time in regedit?). With that said, the author fails to rectify how that would work on the file system. Uninstallers typically ignore user-specific data -- and may need to. What if two users used a globally installed application, and the installer DID have an option to remove user data. If one user uninstalls the application yet does not have permission to the other user's userdata folder, it's going to leave files behind. > The registry is monolithic. Let's say you wanted to move an application to a different path on your machine, or even to a different machine altogether. You can create a System State backup and restore it to the same or another machine to restore the hive. You can further that with a full system backup which will restore user profiles and programs. No, not as easy as zipping files up and dropping them elsewhere. But the registry can export keys, and that's fairly easy for someone familiar with regedit. > What's depressing about all of this is how prescient the UNIX conventions are in retrospect. This fails to see that the UNIX conventions are also not good. Config files littering god-knows-what directory (trace your Apache conf files!). An end user wouldn't understand this, as much as they wouldn't understand the registry. I think what this boils down to is that the form of how settings are stored does not matter (except the registry will be that much faster thanks to being a JET Blue database and in-memory at all times). An end user with limited knowledge won't know how to backup all settings and restore them elsewhere. An IT admin will, but then the settings storage doesn't matter.