I don't use GNOME, but...

> Key-level access controls, which can be done with text files only by
> having only one key/value per file (which has its own disadvantages)

I've never, ever come across a situation where I wished I could make one half of a configuration file editable by one user and another half by another.

In the situations where it might be even of theoretical interest, the software designers always split the configuration into multiple files, or provide #include-like functionality.

> All the atomicity, transactioning, and other consistency advantages that a
> database & dbms give you.

Atomicity is a solved problem. Just create the new config file as a separate file, then use rename() to get either the old or new file. Every filesystem that I know of has this semantic with rename (yes, I know it's not strictly in POSIX.) Every major UNIX text editor (vi, emacs, etc.) uses the rename() trick by default.

Transactioning is a solved problem because... you do make backups of /etc, right? Or you use btrfs with snapshotting.

It might be interesting to have a registry that had something like a foreign key constraint in SQL. (If X is set, then Y can't be set, etc.) The problem with schemes like this is that they tend to assume close cooperation between the maintainers of different projects. One config file per-daemon or service puts the responsibility squarely on the package maintainer's shoulders. With foreign-key constraints that could span packages, who has the final responsibility for fixing things?

Also, if the constraint is violated, what do you do? Silently modify the user's configuration according to your own whims? shutdown -h? Or just add to the syslog spew?

> Strongly-typed data

This is probably the strongest argument in favor of a registry. Being forced to use getter and setter functions prevents you from writing your own parser, which you'll probably screw up.

The rebuttal is that good programmers never write their own parsers from scratch. They use tools like lex and yacc to generate parsers which are type-safe and correct. Or they use a canned format like XML or the Python ConfigParser format.

The more detailed rebuttal is that true type-safety would require the ability to extend the registry with arbitrary datatypes. Sure you have string and uint32, but will you allow me to store my FtpUser object? If you won't, I'm still going to be doing something that smells a lot like parsing.

> Changes are done through a standardised API, which makes makes a lot of
> stuff, such as centralised administration, easier

There are tools like "Chef" that provide centralized management for unix config files. On the other hand, there are no such tools that I'm aware of for the Windows registry, unless you want to call "regedit" such a tool. I'm not aware of any for the gnome registry except for it's own registry editor dialog, and... Gnome itself. The reality is that one program cannot understand another program's configuration, no matter how it's stored or parsed, without someone putting work into integrating the two projects. Centralization and integration have nothing to do with technology, and everything to do with politics and management.

Since I'm being a completionist, let me point out another thing. You forgot to mention another argument against text file configuration: configuration file size. A set of (binary) registry entries can be parsed more quickly than a large text file.

This actually became a real issue in the samba program. Some users had extremely large configurations that were taking a long time to parse when the daemon was started. The samba team solved it by providing a (non-mandatory) facility to compile the config file into a binary representation.