[ On Friday, March 17, 2000 at 21:34:07 (-0800), Greywolf wrote: ]
> Subject: Re: more work in rc.d [was Re: rc, rc.shutdown proposed change]
>
> You just answered your own question!  We, as systems administrators,
> SEE AND FEEL the difference.

Yes but my point was that it still doesn't make any real difference --
it is just an emotional issue.  When it becomes an emotional issue the
supporters of each particular opposing feature will claim superiority
whether one's really better than the other or not.

> When I worked with Autodesk, we were switching over to Solaris.  I hated
> it.  The performance was abysmal, the shells crashed, and everything felt
> suddenly quite alien.  EVERYthing.  From the way ps worked, to the way the
> startup was handled, to where the host config was split across six or
> eight files, to the fact that su didn't work right, to the STUPID GODDAMN
> DEVICE STRINGS (the compat devices didn't work right, for some reason).
> It was a blight on the face of UNIX (either that or BSD was a bit of
> sandpaper on UNIX's face, which is a blessing in itself :-), and it was a
> slap in the face of every sysadmin who'd ever touched a Berkeley or Sun
> system.

I can promise you that if you'd started by learning V7 and 32V, then
suffered under several years of running Xenix and SysIII, and finally
been relieved a bit by the last releases of SysVr3, and on occasion had
suffered with fall backs to SunOS-3 and even SunOS-4, and all the time
working with at least a few systems that had to work reliably in
commercial production environments, you'd have a much different view and
be far more accepting of change in those systems regardless of whether
it's always for the better!  :-)
 
> If you're expected to learn to admin a system, much less use one,
> what's the FIRST thing you're gonna see...?

The manual pages.  *EVERY* "vendor's" system is different.  Trying to
stuff systems into one of two categories is only going to get you into
trouble.  Everyone stole something from everyone else and everyone made
their mark with something new and unique.  Never ever trust that you can
guess where something is or how something works -- always check the
documentation and double check with hands-on tests.

> And I concur with der Mouse:  To be told that the details of administrating
> a system are unimportant is an insult to my career as a systems and network
> administrator.

That's not waht I was saying.  The point is that narrowing your view of
how to do things so that you're only competent in one environment is
limiting.  Criticising differences just because they are different
doesn't help.  Complaining that "the other" way of doing things is
harder without learning it openly and using "it" in the environments it
was designed for doesn't help either.
 
> Define "production quality".  What's _really_ wrong with what we had?
> "Couldn't be automated."  Bull[#@$(].  It could be.  Just takes some
> more thought, is all.

Production quality has to do with things like reliability,
reproducibility, consistency, integrity, and automatability.  An ideal
production system would run itself in a "lights-out" 7x24 environment,
upgrade itself, tune itself, and perform its own disaster recovery.  All
the system administrator would have to do is the initial install, plug
in new hardware when it's required and authorise the addition and
deletion of user accounts, software, etc.  Obviously no system yet meets
all of those goals 100%....

> Production-quality sysadmin tools != dumbing down the tools.

Of course not -- it means making them smarter, more reliable, and more
consistent, and more automated.

> Your first production-quality sysadmin tool had better be your systems
> administrator!

Well, hmm...  from a systems programmer's P.O.V. I would have to
disagree!  :-)

-- 
							Greg A. Woods

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