Status of gconf -> dconf

Jack Neely jjneely at ncsu.edu
Mon Feb 23 22:24:16 UTC 2009


On Mon, Feb 23, 2009 at 05:20:51PM -0500, seth vidal wrote:
> 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.
> > 
> > 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.
> 
> To be fair - a lot of the new mechanisms for storing config data don't
> work with the filesystems commonly in use. NFSv3, AFS, cifs are 3 that
> come to mind as NOT playing well with sqlite, in particular.
> 
> I think we need to be very careful in designing future config formats to
> realize that the world is:
> 1. not a single user on a laptop/desktop
> 2. very commonly using shared filespaces - especially for homedirs
> 
> -sv
> 

I can't agree strongly enough here.

Jack

-- 
Jack Neely <jjneely at ncsu.edu>
Linux Czar, OIT Campus Linux Services
Office of Information Technology, NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4  EA6B 213B 765F 3B6A 5B89




More information about the fedora-devel-list mailing list