Status of gconf -> dconf

Dan Williams dcbw at redhat.com
Tue Feb 24 18:47:18 UTC 2009


On Tue, 2009-02-24 at 12:22 -0600, Callum Lerwick wrote:
> 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.

As has been pointed out a couple of times, it's *not* always efficient
to use the filesystem, because the filesystem usually relies on block
sizes.  Thus you waste lots of space if your file is < 4k.

As has also been pointed out, locking with network filesystems is dicey
in many cases, and locking mechanisms are not usually cross-platform,
which some of the projects we're talking about require.

Furthermore, access control usually takes the form of uids and posix
permissions, which may not be granular enough.  But I suppose you can
use xattrs to fix some of that.

Dan

> 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.
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list




More information about the fedora-devel-list mailing list