Le Lun 4 décembre 2006 21:43, Bill Nottingham a écrit : > Matthew Miller (mattdm@xxxxxxxxxx) said: >> I'm just not convinced that not being able to ssh in to a server and >> edit >> some config files but rather have to figure out how to tweak the >> policy-daemon-of-the-month is the user experience a large segment of >> "we" >> wants at all. Human-editable config files are a huge strength. Using a >> policy daemon may be part of the answer, but it should be able to get >> its >> configuration from something that can be fixed with vi. > > So, the entire thing boils down to "I don't like the g-conf storage > format?" (I'm honestly asking here.) What admin likes the g-conf storage format ? What admin likes the fact that unless you're careful gconfd will happily overwrite manual modifications because you've done them in vim and not (insert name of neutered GUI gconf tool there) I like XML but I'll take an old GNOME .ini conf file over a gconf one any day. Instead of being admin-friendly the gconf storage backend is over-optimized for developpers. Admins want/need stable schemas, sane file organization, stable formatting, pretty indenting, XML schemas registered in places vim and emacs can find them, safety of editing with whatever tool the admin likes best, no magic binary cookies use, explicit documentation Developpers want a system that can re-read conf files at blazing speed (so their app can read 20 times the same setting without impacting performance), with low change impedance (so they can stuff last-minute settings there or even change the format from version to version), and no hard documentation requirements (yay for burying configuration access in gconf-editor). They don't care if settings are not accessible without writing dedicated tools/scripts because writing code is what they do for a living. I wonder that anyone is surprised by the admin anguish over making a core infrastructure element depend on gconf. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
