In the last years, many hierarchical configuration systems appeared, and all of them have the same goal: avoid configuration code rewriting, integration between applications, and separation of configuration parameters from their mother software, so then other software can use same configurations.
Here we will compare some of them with Elektra.
The biggest problem with the Windows Registry is that it is Windows-specific and proprietary in design, API, and key naming conventions.
Cross platform applications can't afford to use the winregistry API because there is nothing similar in other systems.
Hopefully, Elektra will change that:
The "G" comes from Gnome, which makes GConf part of the Gnome project. Some GConf characteristics:
GConf is a high level software with many library dependencies, perfect for high level desktop frameworks, but its dependencies are unacceptable for low level early boot stage programs like /sbin/init. GConf's dependencies look like this:
$ ldd /usr/lib/libgconf-2.so libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x0024b000) libORBit-2.so.0 => /usr/lib/libORBit-2.so.0 (0x03dc7000) libm.so.6 => /lib/tls/libm.so.6 (0x00b66000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00dda000) libdl.so.2 => /lib/libdl.so.2 (0x00b8b000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x0099d000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00101000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00c7c000) libc.so.6 => /lib/tls/libc.so.6 (0x00a3a000) libpopt.so.0 => /usr/lib/libpopt.so.0 (0x0077b000) /lib/ld-linux.so.2 (0x00a21000)
This is useless for an early boot stage program (/usr/lib may be still unmounted), and for a very small OS installation that won't require desktop features, like a router, small firewall, or any other appliance. On the other hand, a program that wants to use Elektra will only link to libelektra.so which has a minimum of natural dependencies:
$ ldd /lib/libelektra.so libc.so.6 => /lib/tls/libc.so.6 /lib/ld-linux.so.2 => /lib/ld-linux.so.2
Compared to GConf, Elektra is not a daemon, was designed from the begining for global system usage, is lightweight, is concerned about security and avoids any dependencies.
D-Conf generated a long discussion on FreeDesktop.org's XDG mailling list. Its objective is to standarize configuration across desktop frameworks like Gnome and KDE, so no focus is being devoted to global non-desktop system configurations.
It was very difficult to find the D-Conf website (not found in the end), and seems that all is available is that XDG discussion, and a wiki page containing analisys of what is required, and development directions.
Conclusion: D-Conf is vaporware.
UniConf started as configuration library and daemon to be used in some specific programs. It claims to be very flexible, capable of having backends and frontends, as any configuration library can have.
Its drawbacks are, as in GConf, some dependencies, and a plus (or minus): it was developed in C++ which makes it also dependent on higher level libraries, and require client programs and programmers to be written in C++, unless they get a pure C frontend.
Some UniConf developers started to write a UniConf backend for Elektra, which means that you'll be able to use Elektra's simple API and tools, and UniConf will be responsible for all low level I/O.
Elektra and UniConf can live together in an entirely Elektrified world, leveraging UniConf flexibility as a storage backend.
Looks like this is a dead project, since nobody talks about it for long time. Last website update was in 2004.
Very ambitious, this project claimed they will write many backends, one for each configuration file available, and after that, some can access say Samba's configurations normalized through their API and tools, what they didn't realized is that to write many different config file parsers (compilers) and keep tracking their changes, is way more difficult than to write patches for each software.
This is a dead project. It is a Python library that accesses ini-style configuration files.