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