Status of gconf -> dconf

[Callum Lerwick]

On Mon, 2009-02-23 at 17:17 -0500, Colin Walters wrote:
> 2009/2/23 Callum Lerwick <seg at haxxed.com>:
> >
> > What is this, Windows? Everything is a file. Hey, I have a wild idea!
> > Store your config in ~/.fooconfig/keyname, the contents being the value
> > of the key. Wow, now you have hashed key lookups, locking (fcntl),
> > change notification (inotify), permissions and ACLs...
> 
> This is the kind of design that makes kernel developers complain when
> they strace applications and notice how many system calls they take to
> start up.  Also, inotify has kernel limitations that would prevent us
> from using it on that kind of scale.
> 
> "Everything is a file" was a cute mantra for the 1970s, but reality is
> more complex than that.  As painful as it is, in general we've been
> moving more underlying storage in the desktop to mmap()able formats
> because it involves few system calls, doesn't take lots of file
> descriptors (not an unlimited resource), and works well in the
> multi-process architecture that for historical/political and some
> technical reasons we have.

Yes, constantly re-inventing the filesystem, inside a file, is a much
better idea.

> Don't get me wrong - GConf has some very bad design flaws (at least
> should have used something like Protocol Buffers instead of XML), and
> I'm not defending the weird dconf licensing.
> 
> But "let's just use lots of files" is not the answer.

So group your keys if too many files is such a problem. You know, like
we've been doing for decades. Config files are a Solved Problem, the
only problem here is people want to write some overwrought universal
library and make everything use it. While centralizing code is generally
a Good Thing, people seem determined to overthink and overdesign it.
Second system effect at its finest.

Everything not greppable, diffable, human readable and editable, should
be dragged out in to the street and shot. This is /configuration/ we're
talking about.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090223/c924372c/attachment.bin