A huge improvement on the previous .ini files and something still unmatched in the Mac or Linux worlds with config in arbitrary locations and formats (which, incidentally, let anyone write anything anywhere in a similar fashion).
You are a little wrong there about Linux. Nearly all configuration files are in one of two places, /etc or dot folders in the root of my home folder. I can't write to the files in /etc as a user, and the config files in my home folder only apply to me. (Incidentally, since most Windows users at home run as administrator, they have access to the system configurations).
Personally, I don't like the registry because it is a binary blob (and having .ini files spread everywhere is much worse). I like human editable configuration files spread out in a folder hierarchy. I can use the same tools to modify configurations as everything else, as (nearly) everything is a file. I modify configurations with a text editor, I copy the configurations as files etc. It also allows me to get a better understanding of the configurations, since I can easily have comments and can literally copy and paste between text editors to migrate partial configurations.
In terms of a networking environment, applying configurations from a central user server is probably easier with windows due to the nature of the registry. However, due to the separation of system and user configuration on Linux, this is not an issue. You have /etc configuration as part of a 'system image', and can update this using tools like puppet. Then you have your user configuration migrate with a users network filesystem.
> (Incidentally, since most Windows users at home run as administrator, they have access to the system configurations).
Most UNIX users at home have sudo permissions - unless someone else is using you're computer there's no difference in typing a password compared to confirming a UAC prompt.
As part of the registry clutter backlash there has been a tendency for Windows applications to store settings in user or system-wide app data directories. I'm still not convinced by the move, but obviously it's the only way to achieve portable installs without using two different storage backends to support it.
I can think of no system services that don't use /etc. As for user programs, the only real things that I can think of breaking this convention are small projects that store their configuration files with the binary; usually small programs that run from their own directory. Would you care to elaborate on where these other programs choose to store their configuration?
Not unusual for third party software to have configuration files elsewhere though. You see this a lot with "Enterprise" java stuff, typically config files in XML scattered around the installation directory.
You are a little wrong there about Linux. Nearly all configuration files are in one of two places, /etc or dot folders in the root of my home folder. I can't write to the files in /etc as a user, and the config files in my home folder only apply to me. (Incidentally, since most Windows users at home run as administrator, they have access to the system configurations).
Personally, I don't like the registry because it is a binary blob (and having .ini files spread everywhere is much worse). I like human editable configuration files spread out in a folder hierarchy. I can use the same tools to modify configurations as everything else, as (nearly) everything is a file. I modify configurations with a text editor, I copy the configurations as files etc. It also allows me to get a better understanding of the configurations, since I can easily have comments and can literally copy and paste between text editors to migrate partial configurations.
In terms of a networking environment, applying configurations from a central user server is probably easier with windows due to the nature of the registry. However, due to the separation of system and user configuration on Linux, this is not an issue. You have /etc configuration as part of a 'system image', and can update this using tools like puppet. Then you have your user configuration migrate with a users network filesystem.