gconf brain death (was Re: [linux-elitists] Yet another mozilla atrocity)

Jason Spence jspence@lightconsulting.com
Wed Oct 1 02:40:48 PDT 2003

On Tue, Sep 30, 2003 at 11:51:21PM +0100, Karsten M. Self wrote: 
> on Tue, Sep 30, 2003 at 02:57:04AM +0100, Karsten M. Self (kmself@ix.netcom.com) wrote:
> > ...but only one mode of setting the configuration actually takes (this
> > on 1.2.5).  Specifically, I've had a lot of trouble getting proxy
> > settings to set, or remain set.
> In this specific case, the solution was to use gconf-editor.  A
> reimplementation of the MS Windows Registry for GNU/Linux, with the
> concommitant problems of undocumented settings, cryptic keys, 
> inability to readily comment features or settings, and use of a single,
> specialized application to access the configuration settings.

I've worked with both the windows registry and various unixy
configuration systems extensively for various projects in the past.
You seem to have been misinformed about a few things, although I
wholeheartedly agree with several of your points.

 - Undocumented settings

Many keys are documented on MSDN and in vendor documentation.
However, many keys are not.  This could be solved by an integrated
documentation system, but like you said there isn't one.  I suspect
that including such a thing in the registry databases themselves would
cause performance problems, although it'd be really hard to argue
against creating a separate index loaded when the documentation data
are required.  

Several groups of keys, such as the services database and the network
card configuration system, are partially documented and are expected
to be changed via APIs instead of directly.  This is either a bug or a
feature depending on who you ask and what you think about Microsoft's

 - Cryptic keys

Yes, many keys are cryptic.  This is a result of a design decision to
allow raw binary data in the registry.  Most of us unix people have a
very serious problem with this because of our nature to expect
everything as text, and we're more than willing to deal with
conversion overhead when dealing with textual representations of
binary data.  Win32, on the other hand, was designed by VMS people who
didn't have any such qualms and so they decided to sacrifice ease of
maintenance for a little bit of extra performance.

 - A single, specialized application to access the configuration

Well, most of the windows users learn to do soho system administration
by watching other sysadmins, and professional windows administrators
don't like to show off any of the really useful things available in
windows for job security reasons or increased expectation of
productivity or whatever.  I suspect you're in the camp that hasn't
been exposed to them.

This hasn't been true for several years.  First of all, most of my
systems came with the reg.exe program which I use for doing registry
add/drop/change stuff in scripts.  Example: 

C:\WINDOWS\system32>reg query

That'll give you some information about what Windows update is doing.  

There's also the wmi scripting interface accessible via the javascript
interpreter (the shell in most windows systems supports a superset of
javascript for system administration tasks; google for JScript windows
scripting host) or the ActiveState Win32 Perl extensions, regedt32,
the raw C API
, and some other methods I'm probably forgetting.

> The last is among the more specific faults I have with such system.s  In
> the Winodws world, one of the neater tricks you can play with tools such
> as UWIN and Cygwin (both POSIX-on-Windows toolkits) is to treat the
> registry as a filesystem (similar to /proc, under UWIN) or as a database
> which can be queried and/or modified with specific tools (via a set of
> command-line utilities, under Cygwin).  Showing effectively that there's
> relatively little difference from a representational standpoint between
> a browseable hierarchy (the default Registry access method), a
> filesystem, or a queryable flat database.

I'm not sure that the default registry access method is that of a
browseable hierarchy.  The majority of the interaction I have with my
systems is via a big pile of remote management software I wrote.  It's
concerned with only a few specific keys; it never pokes around the
rest of the registry looking for stuff.  In that sense, it certainly
does treat it as a filesystem.  Most win32 apps are the same way.  I
don't thing it was ever a design intention for the registry to appear
to the user via a single paradigm.

As far as users go, I'm sure that the majority of the access is via

> It's specifically the lack of generic tools to access the Registry, the
> inability to comment it (or comment out keys while trying settings or
> dealing with a contingency), the masking of functionality through
> intentionally obfuscated keys and values, and the fragility of the
> system as a whole to any file damage, which are the primary complaints
> against the Registry.  Best I can tell, gconf is largely bug-for-bug
> compatible on all points, though I admit my aquaintance with it is
> quite casual.

I totally agree that the inability to comment registry keys is a
problem.  As far as the fragility of the system goes, I'd like to
point out that there's a backup of the registry, the SAM (which is
like the /etc/{passwd,shadow} file pair) and other critical system
files on (at least) 2k+ in %systemroot%\repair while pretty much every
unix system I've dealt with doesn't come by default with any
redundancy for e.g. the password file, critical system binaries, the
rc script, etc.  And last time I checked, there wasn't any redundancy
for the gconf XML database...

It's possible to reconstruct the registry by hand.  The majority of
stuff in a virgin installation is COM goop and other file association
type stuff.  If that gets corrupted you can reconstruct it from the
known default settings if you know the binary format of the registry.
If other keys get corrupted, you have a backup registry file you can
use.  If both copies get corrupted, modern Win32 systems have system
restore, and you can restore from a snapshot.  If THAT gets corrupted
or you're so low on disk that you can't use system restore, you
probably should have backed the system up.  If you didn't, then your
site has bigger problems than worrying about unexpected block level
corruption of your files in spite of all the on-disk per-sector ECC
correction and the 3 different independent checksums you get on any
modern IP network :)

> Is anyone familiar with a curses or command-line gconf editor?  Yes, the
> XML storage means you can tweak by hand, if you know the DTD by heart (I
> don't).  An emacs mode would be an acceptable answer.  Debian doesn't
> seem to be aware of anything.

Lately I've been using OpenOffice, xmlwebgui, and a few commercial
tools to do XML editing.  I've also found that the Java XML stuff has
gotten a lot better recently for what I need to do with it, and
whipping out java classes for simple programmatic things like ripping
tags out of a document is faster for me to do than to set up a simple
sax parser using libxml2 (because you have to make a makefile, write
portability stuff, etc).

For REALLY quick and dirty stuff, I'm still using Perl's XML::Simple
module.  Note that the readme says it's especially nice for modifying
config files.

 - Jason                            Currently at: Somewhere on the Internet ()

The end of the human race will be that it will eventually die of
		-- Ralph Waldo Emerson

More information about the linux-elitists mailing list