> I was just playing with a svr4 machine (solaris) and really liked the
> idea of /etc/default. Here you can define things like default device
> for dump, without recompiling.

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.


> And while we are at svr4: I think some of the ideas there are worth
> taking a look at. One is the inittab stuff, the other is the nsswitch.

Some people will want to shoot me for saying this, but...

I've spent the last year using a SysV-ish init environment.
previously, i'd had some experience with it, under A/UX...

i'm not sure that i like the notion of 'inittab' -- it seems to be the
wrong way to do things, or at least not more 'right' than the way
things are currently done.  Same with the multiplicity of run levels.
(i actually know of a 'good' reason for multiple run levels like they
do it, but i'm still not sure it's warranted.)


HOWEVER (as i don my flak jacket), the SysV notions of:

	(1) invoking something both when you're going up to and 'coming
	    down from' a given run level, and,

	(2) having multiple files to implement the 'rc' script, and
	    then looking through all of the ones present and running
	    them

are _good_ ideas for a couple of reasons.


the first is nice, because "just a SIGTERM" is not necessarily enough
to shut down complex processes.  one might want to take other actions
to cause a process to shut down, such as cleaning up some files,
running a script, etc.  i would think this would be more important for
things like databases, etc.  It also means that if you _really_ want
to 'clean' your machine's environment, e.g. by unconfiguring network
interfaces when dropping to single-user, you can, and that if you'd
like to havel your file systems cleaned and mounted before you go to
single-user mode, you could arrange it (if done right).

the second is nice a couple of reasons:
	(a) it's nice for users and/or third-party programs to be able
	    to insert things into the boot sequence, without worrying
	    having to hack the currently existing RC scripts.
	(b) it makes multi-machine maintenance a bit simpler; there's
	    little worry about the 'standard' scripts being modified
	    so, they can be upgraded easily, even rdisted.
	    additionally, one could easily add and subtract things on
	    a machine-by-machine basis.


somebody has actually worked on this; they can pipe up about it if
they'd like.  I've not looked too hard at their implementation,
though, because i've been too busy, because i figured a lot of people
would object strongly, and because there is some 'groundwork' to be
set up first...


chris