CPU Frequency Scaling

[Nicolas Mailhot]

Le Lun 4 décembre 2006 21:43, Bill Nottingham a écrit :
> Matthew Miller (mattdm at mattdm.org) 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