up yours, rude shithead. i forget the ".d" on the end of a directory
name i haven't seen much of in years, and that justifies a clueless git
like you to claim that i don't know what i'm talking about? i don't
think so.
FYI, i use the term "abomination" because it is appropriate in the
context (i.e. description of slackware's rc system)
i used to use slackware for over 2 years before i got sick of it's
"upgrade" procedure. i switched to debian in late '95 (IIRC) and have
never looked back.
admittedly, slackware was a vast improvement over the SLS systems i
used before that but it basically got stuck there. as a selling point,
"better than SLS" was good for 1994, irrelevant in 1995, and meaningless
today.
slackware has an abomination of an rc system. it's useless for anything
but booting the system. stopping and starting daemons in any clean,
precise, and systematic way is not possible. this is a self-evident and
undeniable truth.
> Debian has directories including but not only /etc/rc[0-6].d and they
> (by default) contain nothing but a sylink to a script (mostly the same
> one) in /etc/init.d.
this is called standard system V init. if you had a clue, you would know
this.
> Slackware has none of this involved, non-functional runaround.
so, the ability to cleanly stop and start any daemon at any time without
having to grep through half a dozen rc* files is "non-functional"???
slackware isn't an operating _system_ it's a random bunch of
pre-compiled binaries slapped onto a disk.
> It has the single directory /etc/rc.d containing a number of standard
> scripts. Some are control scripts such as rc.M which are cited in
> /etc/inittab and run by init, and others are secondary scripts such
> are rc.inet1 and rc.cdrom which are only run (e.g. by rc.M) if they
> have been made executable.
yes, i know. this is the abomination i referred to. they fulfil their
function at boot-time, and are not much use any other time (e.g. when an
important daemon has died and you need to start it in a hurry without
affecting any other running processes).
> The Slackware arrangement has the advantage of intelligibility (you
> only have to look in one place), and IMHO a certain elegance. Debian
> probably gives a better foundation for corporate change management in
> the startup files department. It's the kind of way you do things when
> time and cost don't matter but control matters.
it's the kind of way you do things when *fine* control of a system
matters, when smooth operation of your machines matters.
it's the kind of system you use when you think that rebooting is for
kernel upgrades or hardware failures, and *not* for making sure that all
your daemons have started up properly.
it's the kind of system you use when you have several assistant
system admins you can't quite trust to grep through the boot
scripts to figure out how to stop/start services cleanly but can
remember rules like "start daemon foo by running '/etc/init.d/foo
[stop|start|reload|restart]'"
> But Debian probably just did it that way to look like System V, and
hey! 3 cheers for the genius. he figured this out all by himself.
debian (and redhat and, i believe, SUSE and others) use sysvinit (or
variants thereof) in order to conform to existing and well-known
conventions that greatly increase the productivity of systems
administrators.
> you can think of the Slackware files as a creative simplification of
> the System V rigmarole.
i think of it as a clueless abomination, with no elegance or style or
even useful functionality.
craig
-- Craig Sanders Systems Administrator VICNET- Victoria's Network http://www.vicnet.net.au- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/