> > so, uh, what reads these files, and sets the 'defaults'?
> > > What is the general view about this? Is it a Good or a Bad thing?
> > if the kernel has to read them, it's a Very Bad Idea.
> Sorry, I wasn't clear about it, I meant defaults for user progs.

While a way of changing defaults for user programs is nice, it would also
be nice if some kernel tunable parameters could be altered without having
to recompile or relink the kernel.  On UNOS, we had a separate configuration
file which contained information like what root device to use (swap was
handled by having the kernel actually open a file named "/dev/swap"), what
program process 1 should exec, how large the buffer pool should be, all
the System V IPC mistunables, and so on; you could have several precanned
configurations in different files, and there was a simple utility for
creating configuration files.

It was quite convenient, and cost fairly little; the boot program already
knows how to find and read files, so opening two files (or three; it also
had to load an I/O Processor executable) was no great mass of code.  The
boot-loader to kernel communication was a little more complicated, but not
much (the boot loader has to pick a place to write the config file (if any),
and passes a pointer rather than a flags word).  (The kernel had a set of
precompiled defaults, so it was possible to boot without a valid config
file.) 

As for application defaults, a lot of applications already have haphazard
schemes for alterable defaults, usually through environment variables.
A "defaults library" could regularize and extend that mechanism; or perhaps
what "/etc/defaults" should really be is a shell script that people can
source in their login profiles (OK, so you'll need a separate file for
each command processor with substantially different syntax).  (That doesn't
as easily help things that invoked by cron or inetd or whatever.)