CPU Frequency Scaling

[seth vidal]

On Tue, 2006-12-05 at 07:28 -0500, Dan Williams wrote:
> 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?
> 

You don't. You work around that problem and, fortunately, we already
know how to do that. As opposed to the gconf-mechanism where we will
have to learn a whole new way to do it, unless of course, there is no
option to learn b/c it just isn't possible to automatically correct it.

Try fixing evolution settings that used to be in gconf using gconftool.

Not a fun option.

That's the point - we keep trotting out new mechanisms that claim to
make sysadmin life easier/better/something but seem to have few ACTUAL
sysadmins who would back up that claim.

Seriously, who are you deriving these claims about sysadmins from?
Clearly not actual linux sysadmins.

-sv