CPU Frequency Scaling

[Dan Williams]

On Tue, 2006-12-05 at 13:27 +0100, David Nielsen wrote:
> tir, 05 12 2006 kl. 06:09 -0500, skrev seth vidal:
> > On Tue, 2006-12-05 at 12:44 +0100, David Nielsen wrote:
> > 
> > > Solution, fix gconf rather than complain over davidz and friends at
> > > least suggesting a forward minded solution to the horror that is "human
> > > readable" configuration files.
> > 
> > I've been reading this whole thread and I'm tired of a couple of
> > semantics being used:
> > 
> > 1. the assumption that all new development is 'progressive' or
> > 'visionary'. Forward motion isn't always positive. So let's cut the spin
> > and just call it what it is - a new interface. 
> > 
> > 2. That anyone promoting sticking with the status-quo is somehow
> > backward.
> 
> This also assumes that there are no problems with the current scheme
> though. By moving to a configuration storage scheme like gconf we get
> the option of having all key explanations be translated and having one
> common format and syntax, I think those two factors alone make it worth
> considering seriously.

It's also easier to auto-update GConf with new settings.  The horror
that is autoupdating, say, /etc/pam.conf or httpd.conf.  _Every_
distributor gets killed by trying to issue updates that might have to
automatically change httpd.conf, even if it's just a few lines, (even
Apple!).

Human manipulatable != machine maniuplatable

Many cases are optimum for human manipulation.  I don't think anyone
wants /etc/resolv.conf to be in XML somewhere.  That
said, /etc/resolv.conf will never get split DNS resolution because the
config file format _cannot_ change.  Hence you need a local caching DNS
resolver.  But for complex configurations, often-times
human-manipulatable config files are _not_ the best solution, especially
when you want to auto-update configuration from an RPM, or some other
mechanism that may have to take user/site-specific changes into account.
It's simply a non-starter to attempt to automatically merge
configuration updates into existing config files that that may be
different than expected even in a few places.

Which leads me to the next point.  Most config file formats these days
are pretty dumb.  They don't have all the information that's needed to
(a) verify conf format, (b) change narrowly scoped pieces of
configuration, or (c) be editable in something other than English.  XML
can do all of this, but is much less human-readable in complex form.

Red Hat tried to do a grand unified configuration project years ago,
with GUI config tools that edited things like /etc/passwd,
httpd.conf, /etc/fstab, and many more.  I think everyone would agree
that having GUI config tools makes Linux more accessible to some portion
of the system administration audience, but the horrors uncovered by that
project mean that what we've got today really doesn't work for GUI
config in most cases.

So it's a tradeoff.  Do you want to keep all the configuration human
manipulatable, and therefore inaccessible to those sysadmins who _don't_
want to edit 10 different config files to get something done, each with
their own config file format?  Or do you add _some_ measure of machine
manipulation ability to the configuration format, at the expense of a
slightly harder to understand configuration format for humans?  After
all, machines are our tools no matter whether we SSH into them to edit
the files directly, or whether we deploy updates via RPM or whatever
automatically.

So perhaps GConf isn't the best solution.  But then what?  What provides
better experience for GUI-based config tools and people who don't want
to get that far down and dirty with hand editing files?  How _do_ you
provide a better way to update little pieces of configuration without
the almost-all-or-nothing approach of automatically updating config
files today?  How many .rpmsave or .rpmnew files do you have lying
around?

Dan


> It seems to me that people are not looking at the full picture here,
> there are people in the world for whom this would be godsend, not just
> desktop users but admins - that is aside all the nice things that this
> will enable us to do according to davidz. It will enable us to give the
> users greater understanding of settings and a greater ease in tinkering
> with them, largely thanks to having one uniform interface, with
> comprehensive comments and explanations in their language.
> 
> - David Nielsen
> 
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list