Status of gconf -> dconf

Callum Lerwick seg at haxxed.com
Tue Feb 24 18:22:28 UTC 2009


On Tue, 2009-02-24 at 12:30 -0500, Colin Walters wrote:
> 2009/2/23 Callum Lerwick <seg at haxxed.com>:
> >
> > Yes, constantly re-inventing the filesystem, inside a file, is a much
> > better idea.
> 
> It's not reinventing the filesystem, any more than the various systems
> in current /etc are.

I'm not talking about /etc, I'm talking about non-plaintext storage of
configuration.

Dude I'm going to blow your mind: The filesystem is a database. Locking,
atomic transactions and crash recovery (journaling), access control,
efficient storage and retrieval of data. Same set of issues.

Once you're talking about "optimized" binary formats, with hashed
lookups, transactions and locking, you're talking about a database. So
use a database. There's one already built in to your kernel.

> >> 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,
> 
> I don't think so.  It's actually a quite hard problem.

Did I say it wasn't a hard problem? It's a hard problem that's already
been solved. Several times over.

> > 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.
> 
> Nothing prevents one from writing a FUSE layer to expose an actually
> efficient configuration store for the developer/sysadmin experience
> without imposing overhead for the normal case.

Yeah, that's sure keeping it simple. This is the essence of the problem.
All those pushing this "One True Configuration System" thing Just Don't
Get It, "it" being:

http://en.wikipedia.org/wiki/Unix_philosophy

"It's not efficient to do it that way!" and thus "It can't be
plaintext!" are flagrant violations of unix engineering philosophy. Yet
they expect every single piece of unix software in existence to come
running to use it? Good luck with that.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090224/7a8e1d88/attachment.sig>


More information about the fedora-devel-list mailing list