On Mon, 24 Apr 2000, Greg A. Woods wrote:

# > I think this would be best done using a different model for starting
# > daemons/subsystems, more akin to an inetd/init model (where a
# > management daemon remains as a parent to the managed services) as
# > opposed to an rc "fire and forget" model.
# 
# Exactly.  This is why SysV had run levels and used them to implement a
# state machine!  ;-)

I will go on record here as saying that I vehemently disagree with this
approach.  If the daemon is crashing now and then, why are we ignoring it
instead of _*>>>FIXING<<<*_ it?

# Especially in this day and age when getty processes on real terminal
# ports are much less common and important...

...in your opinion.  I do most of my work on a command line.

# ...it seems to me that 'init' is
# the natural place to integrate a daemon and subsystem monitoring and
# control feature.

I think that's giving init entirely too much credit/responsibility for its
ability.

I'm going to say this yet again:  "BSD != SysV.  If you want SysV,
you can go get it.  There is an outdated Amiga version, there is Solaris,
and I'm sure you can scare up a version for the 88k or 68k processors.
Getting System V for i386 can be had from SCO."

That said, there were some things sysV did right.  And we've already
integrated those:  echo, touch, and date, and their /bin/sh.  There
are a plenitude of things done wrong -- init, their tty drivers (note
that SVR4 uses the Berkeley tty drivers, albeit the user interface
to the tty settings is POSIX (which AT&T put a lot of money into
when they built SVR4)), ttymon, and dare we forget their printing
monster? -- and we're better off leaving those things out of *BSD.

rc.d still isn't my first choice, but it does modularise a bit, which
I can see as a boon (especially lately, seeing as ndc start takes
significantly longer than 'named' to run, and ndc stop is more effective
than 'kill -1 $named_pid'. sh named stop; sh named start -- or sh named
restart -- would be preferable).

But SysV is not the best implementation of UNIX(-like) in the world.
I still give that honor to BSD in general.  Having worked extensively
with both, and especially having seen the design and the innards of
both, I will not retract my statement.  BSD may be the "bastard child"
of the UNIX family tree -- but it's more worthy of wielding the UNIX
Excalibur than any other operating system.  It's "knowledgable user-
friendly", while I've found SysV to be outright user-hostile, and
the more you knew, the more SysV tries to tell you you DON'T.  There
are too many black boxes there where there shouldn't be (ttymon,
saf, portmon, lp...).  I'll take getty, accton, and lpr any day
of the blasted week.

And SysV can *keep* it's damned init and inittab, and all that implies.

				--*greywolf;
--
If anyone requests a reason as to why Windows NT is inferior to UNIX,
refer them to the process scheduler, for starters.  Of course, users
don't care, and programmers try not to, even though they both should.
If that fails, reiterate that remote administration and control of a
node is a *good* thing, especially if network security is concerned.