> Why do you think init.d is the right choice for the default for "large
> installation" users?

because proper use of 'init.d' scripts involves no editing of any
pre-existing configuration files, for one.

> If third-party software comes packaged as a tarfile which wants to be
> extracted from the root of the filesystem so that it can drop a file
> in /etc/init.d/foobar and a symlink in /etc/rc.d/95foobar, then this
> makes life harder for me if I want to install the software on a file
> server instead of on a single machine.

straw man.  Don't blame startup scripts for bad packaging of binaries.

If you're using /etc/rc there IS _NO_ easy drop-in solution you can
safely use, ever, to add stuff to the startup sequence.

Looked at another way, if you want to install the software on the file
server, the instructions you have to give to the people installing the
software is "edit your RC scripts," rather than "make a symlink from
your rcN.d directory to this script."

The latter is much easier, and much more robust, for both the server
manager _and_ any local admins, be they users or otherwise.


> From the perspective of standardizing machine configuration, my
> experience at MIT is that although it's a much harder to do for
> systems using /etc/init.d than it is on systems using the simpler
> /etc/rc system, because of the added complexity of the /etc/rc system.
> (I do not think /etc/rc is a "good" system; I just think that of the
> two standard evils, /etc/rc is preferrable to /etc/init.d because of
> its simplicity.  Not that /etc/init.d is particularly standard; every
> vendor seems to do it differently.)

"standardizing configuration" between two OSes?  that's not our
concern.

standardizing two machines, with the same OSes?  that's easy: diff and
ls will do it for you.  You can tell (1) which init files have been
added or removed, and (2) which have been changed, all easily.

if you have /etc/rc, you must diff it and understand the context of
any changes...  i'd call it a wash.


> A brief statement on why alphabetized symlinks in a directory is evil:
> a good configuration file (or "means of storing configuration
> information," if you prefer) should have the following properties:
> 
> 	1. It should be easy to read and edit by a human who has not
> 	   read any documentation.

i would argue that init.d scripts _are_ easily to read and edit by
humans, who have not read any documentation.

Certainly, adding and removing scripts and features is _very_ easy.

> 	2. It should have a syntax for comments (relevant to (1)).

They're written in 'sh' -- that means you can have comments.

> 	3. It should be verifiable by an automatic procedure.

what does this mean?  (you can't do this with /etc/rc _or_ init.d
scripts...)

> 	4. It should be editable by an automatic procedure.

automated management of init.d scripts and/or symlinks is much easier
than management of features in /etc/rc.  you want to remove a feature,
you remove the script and/or link.  easy.  can be done by a program.

/etc/rc modification can't safely be done by programs, in my opinion.

In any case, you shouldn't _need_ an "automatic procedure" or a
program, etc., to generate your startup scripts.  you _should_ be able
to modify them by hand, with no new tools.

> 	5. If possible, single errors should not invalidate the entire
> 	   configuration file.
> 
> A shell script has property 2 and, to some degree 1, but automatically
> flunks 3, 4, and 5 because it's Turing-complete.  Symlinks in a
> directory have property 3, 4, and 5, but they do not and never will
> have property 1 and 2.
> 
> Symlinks in a directory have the main advantage that they allow you to
> do ordering with the "ls" command.  I think this is a sorry reason to
> use it over a configuration file.

That's "simplicity."  Simplicity _is_ a good argument for something,
especially if you think people are going to want to muck with it.

It seems to me that your "desires" actually indicate that init.d-style
scripts and symlinks are better than /etc/rc...


cgd