Re: BSD Init

[dsavage@peaknet.net]

On Monday July 19, 2004 9:27 a.m. "Drews, Jonathan*" <DrewsJ@cder.fda.gov>
wrote:
>> BSD-style init is an unmaintainable mess.  It's not simpler by *any*
>> stretch of the imagination.  It's actually *ridiculously* complicated
>> compared to SysV init, which simply uses a bunch of symbolic links
>> to determine what gets started/stopped at any given runlevel.
>
>  I don't think it is that bad really.  After all Apple uses FreeBSD as the
> basis for their computers now in the form of OS X. So there must be some
> merit to them. If you think *BSD init is hard wait to till you get
> clobbered
> by Kudzu and ZeroConf. Have fun :).
>  As for the compiling from source argument, Netcraft shows that FreeBSD
> runs
> on 2.5 million sites on 5 million hostnames.
> http://news.netcraft.com/archives/2004/06/07/nearly_25_million_active_sites_
> running_freebsd.html
> Compare that with 1,465,000 sites that run RedHat:
> http://news.netcraft.com/
>  So source compiles can't be that big an impediment. BTW it's possible to
> package fetch on the *BSD's.
>
> BTW way great tutorials here on the NetBSD rc.d system.
> http://www.mewburn.net/luke/bibliography.html

I didn't see the original post, so I'm not sure what act/scene we're in.
As one who was first introduced to UNIX in 1982, the Berkeley versions
were all there were back then. When AT&T introduced System V and their new
multilevel init structure, most of us looked at it with horror. Why all
the complexity? Why do we need to replace one script with a hundred (or
more)?

In time we learned that with complexity comes flexibility and power. With
its SysV Init, Linux gives me the power to alter the behavior of one
function's start or stop script without putting the entire system's Init
in jeopardy. With its well-ordered runlevel schema, I can add / drop /
re-order / modify start & stop scripts with ease _and_ surgical precision.

If I had to go back to a Berkeley style Init system (which I "assume" is
still employed in *BSD), I'd go stark raving mad. To me it would be as
awkward as trying to maintain a 256K CONFIG.SYS file back in DOS. Yeah, I
could do it. Badly. And you can bet the company there'd be a palace coup
simmering in my cubicle.

With respect to source compiles, in any given user population you will
have those who are willing and those who aren't. Tossing numbers about as
though they mean something isn't really much of an argument.

Anyone who's been in this racket longer than a week knows there's a lot
more to computing than setting up systems. If I have a large number of
servers and/or user workstations to maintain in up-to-date good working
order, I'm going to use whatever tool works best. For Red Hat systems,
that's usually -- but not always -- rpm. There may be reasons to do source
compiles.  Two come to mind.

     1. Non-availability of Red Hat binaries. The gftp client is a good
example. It's distributed in .src.rpm and a Debian binary .rpm that
fails a few library dependencies when you try to install it on a Red
Hat or Fedora system. It's no big deal to compile a new binary RPM
from the .src.rpm file and post it to your site's up2date/apt/yum
repository for automatic installation.  Another example of this is
the lt-modem driver for the Lucent winmodem found in many laptops.

     2. Non-availability of rpm packaging at all. Lots of stuff on
sourceforge is available only in tarball format. If you want to use
any of it, you will have to have to know how to extract, compile,
install, etc.

Not everybody is going to want to do this. The vast majority of ordinary
users would much rather spend their time turning on their machines and
using the application(s) of their choice. They have better things to do
with their time than dinkey with the stuff we like to do. For them, and
for us administrators with better things to do with our time, we need a
flexible set of tools to create and automatically distribute binaries
across our enterprises.

For ordinary users they need be no more complex than a dinner fork. Us
geeks will take care of the rest.

--Doc

-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.