The Windows Registry vs Gconf

I often hear people attacking GNOME and Linux because of the claim that they’ve emulated the Windows Registry in Gconf. While this looks to be true at first glance, looking a bit deeper reveals many differences that make the two into completely separate entities. Both GConf and the Registry have their own advantages and drawbacks.

Windows Registry

The Windows Registry was added in Windows 95 to replace .INI files that Windows 3.1 applications would often use. These .INI files would be littered all over the filesystem in whatever location their application decided to put them. .INI files were easy to edit. Requiring only a text editor they could be edited in both DOS and Windows. The Registry was created to keep all the system settings in one place. Before it was released the APIs were made public so that any application could store its data along with all the system data in one common place.

This seemed like a great idea. No longer did you have to go searching to look for the settings for any particular application. Simply open up Registry Editor browse to your applications keys and edit away, unless you accidentally hit some system setting. Because system settings are stored right next to application settings changes to the Windows Registry could render the system unable to boot. This is why you see all those disclaimers on any tutorials involving the Windows Registry.

The Windows Registry is stored in a binary form. This makes it quick to load but limits its flexibility. After a Windows system fails to boot it will ask you if you want to boot with the last known good settings. This basically uses a backup of the Registry made at the last boot-up, where the settings are known to be correct. Not attempt to edit it can be made without a graphical environment and your only option is to roll back to a backup.

GNOME Gconf

On the surface Gconf appears to emulate the Windows Registry. Both gconf-editor and the Windows Registry Editor look very similar, and indeed operate in practically the same way. They’re both a collection of keys and values in a tree form. They also hold some similar settings such as keys to hold the desktop wallpaper location.

Gconf differs significantly to the Windows Registry though. You’ll notice that there are no settings in gconf to configure swapping, tune the filesystems, or configure routing. Gconf doesn’t hold any system settings, it stores only settings related to the desktop environment. You won’t find anything in there to help you configure device drivers or render your system unbootable.

The backing data store for Gconf in XML, which allows editing (though I’ll admit its somewhat difficult) with any text editor, command line or graphical. In the event of you making a change that stops your desktop environment from starting you’ll still be able to boot into a command line mode and attempt to fix the problem. It is also easier to identify when searching for it in a crashed filesystem.

Comparison

Both gconf and windows registry both represent their data in a tree based structure containing keys and values. This is where the similarities end. Gconf does not store system settings, editing it will not destroy your Linux machine. Gconf has a clearly defined scope, and is not meant to encompass every possible setting the computer may need. Gconf is easier to edit and repair, because of its XML format.

I refuse to debate which one is better because they are designed to perform some very different tasks. I do however think that the windows registry would benefit from an XML (or other text backend). Similarly Gconf could benefit from an automatic rollback/checkpointing mechanism.

Edit: Jeff Atwood (one of my favorite blog authors) recently wrote a post about the Windows Registry. Find it at http://www.codinghorror.com/blog/archives/000939.html.

Random Thought: Imagine for a second that transferring zeros over the internet was free and only the ones cost money. Now think of a compression algorithm (or an inflation mechanism rather) that increases the ratio of zeros to ones and makes data cheaper to transfer. Now imagine how you would perform error correction/detection with this protocol.