[rescue] Re:EMACS

[Greg A. Woods]

[ On Thursday, June 28, 2001 at 01:06:39 (-0500), Dan Debertin wrote: ]
> Subject: Re: [rescue] Re:EMACS
>
> Most of the folks who say that wouldn't recognize a BSD init if it smacked
> them in the face ;). It is in fact nothing at all like it, it just isn't
> SysV-ish, and sucks more than SysVinit to boot.

Indeed....

> The current NetBSD rc.conf/rc.d layout effectively combines the good
> things about both init styles, with none of the things sysadmins hate
> about SysV. IMO.

Well, as a sysadmin I only ever hated the original *BSD startup stuff.

W.r.t. system configuration and startup/shutdown processes SysV,
especially by the time of SysVr4.0, was a joy, a dream, a pure delight
to manage (compared to most anything unixy that came before it).

Of course that's not to say that there weren't implementation problems
with the SysV startup stuff.

The new NetBSD stuff really does clear up most of the problems and
present a very clean implementation that's also very easy to use and
extend.  Its author claims the same setup has been used quite
successfully on most commercial unices (i.e. with both *BSD and SysV
init programs driving it).

Oddly *BSD people still seem to prefer to have init's states hard-coded
and hidden inside /sbin/init.  I'd prefer to have them open and exposed
to run-time data-driven control (i.e. /etc/inittab), but either way's
more or less fine so long as what they drive is manageable.  (Last time
I mentioned the internal states of *BSD init on one of the NetBSD
mailing lists to my surprise I got quite a number of vitriolic replies
trying to claim that *BSD init is not a state machine!  Having just
added another state to my own version and munged about with shutdown and
reboot, and thus having a full understanding of their internals, I had
great fun taunting them with the reality of their world!  ;-)

(One major advantage of having significant things hard-coded inside
/sbin/init is that it's possible to tie the boot processes to the
console device and thus allow a much higher degree of interactive
control over the boot-up and shutdown processes.)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods at acm.org>     <woods at robohack.ca>
Planix, Inc. <woods at planix.com>;   Secrets of the Weird <woods at weird.com>