On Tue, 2009-02-24 at 08:12 -0500, seth vidal wrote: > On Tue, 2009-02-24 at 10:43 +0000, Bastien Nocera wrote: > > > For GConf, we were human editable and readable through gconf-editor, and > > greppable/diffable through gconftool-2. > > > > Either you're fueling a flamefest, or you don't understand what's > > required for a modern configuration system. > > I'm not trying to fuel a flamefest, but it does seem apparent that you > do not understand the requirements of a modern network and shared > resource system. > > If you want to know what things are common problems with a linux desktop > infrastructure in a shared resource environment ask on the list. There > are a good number of folks here who have to maintain resources for > hundreds of users, not just single users on a desktop/laptop. Seth, the fact that sqlite or other db-style files have problems on some networked filesystem either indicate a bug in the db or in such filesystems. NFS(v2/3) is known to be a bad file system, sure it "mostly" works for users, but has so many problems I do not even care to think anymore (riduculous locking, stateless, no decent client caching ...). NFSv4 and CIFS should be much better, is sqlite breaks on these filesystems there are perhaps bugs in their client kernel components. It would be better to fix the FSs rather then just ditch the problem completely. That said, given home directories must stay on a trusted server anyway, building a central daemon that the networked desktops can use instead of trying to open databases over networked filesystems (performance sucks when opened from multiple clients) is also a good idea. As for files Callum, they are fine for manually managed machines, where you have a tiny number of daemons that rarely change their configuration, and when it happens usually are restarted. For any application that have frequent automated configuration changes (ie through an internal API), that need to share configuration options with multiple applications, or that store complex data, a file is not only *not* useful, it is really an impediment. The only files that are well structured enough to not be an impediment are XML files, and most people that claim text files are the solution of all problems also claim XML is not a format to use. And XML files are still not really good for the desktop, they lack the features a daemon with a database/directory like backend can much more easily offer, like notification of changes, not to think of ACLs per attribute, etc... Quite static applications are ok with text file (to a degree, some ). But dynamic applications like those running on a desktop have a much harder life trying to use text files. I understand that some people had traumatic experiences with windows and registry files, but a single bad implementation shouldn't be used as an example to banish everything good there is in a registry/directory like approach. As for editing/grepping/etc.. unless you want also to impose the restriction that you have to use "vim file" then most decent system have CLI tools that allow you to edit/search within the store, so your litmus test of being readable by humans and searchable is certainly not a problem. Simo. -- Simo Sorce * Red Hat, Inc * New York -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
