On Sat, 18 Mar 2000, Greg A. Woods wrote:

# 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.

Then you have missed the real point.  UI feel is important.  I'm a
sysadmin.  I do it for a living.  UI feel is _real_ important to me.

# 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!  :-)

1.  You're a SysV veteran.  I'm a BSD veteran.  I expect our viewpoints
    to be slightly askew each other's.

2.  I didn't have your experiences:  I was born and raised on four washers
    and a fridge (VAX 11/750, three 80MB drives and a TapeStretch-11),
    migrated to Sun-2 running SunOS 3, to Sun-3 running SunOS 3, to Sun-3
    limping along on SunOS 4, to SPARC box running SunOS 4, to SPARC box
    crawling on Solaris, with a few lurid interludes with SVR0, SVR2 and 3
    (each with NFS, NIS and a Berkeley TCP/IP stack glued on), and A/UX
    (which I did a (n admittedly miniscule) bit of work on all back between
    the Sun3/SunOS3 and Sun3/SunOS4, as well as a few random encounters
    with IRIX, HP-UX and AIX.

# > 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.

<dry>
Wow.  A system that shows you the manual without intervention from the
minute you log in.  Now that's intriguing.
</dry>

# *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.

Ain't THAT the trough.

# 
# > 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.

No, that's what we are being told.  "It's all in the subroutines which
you should never need to look at."

Now, I have a bit more TRUST in NetBSD trying to do that, but it's magic
which is definitely on the darker side of gray.

# The point is that narrowing your view of
# how to do things so that you're only competent in one environment is
# limiting.

I will grant you that.  You've a very valid point.  To my defense,
I am not incompetent -- in fact, I'm reduced to doing even some NT
administration these days! -- but I am a hell of a lot more comfortable
in a BSD environment than not (ps, df, su, and LINES=34 are only a few
of the aggravations I can name).

# 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.

Nor does approaching it with the attitude of "F*ck you.  We're doing it
this way and your opinion as a user doesn't matter.  Deal."

It's a problem.

# > 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.

Agreed with everything but the last one.  Do you *really* trust any
automation to be done right by _every_ script?  Do you really trust
the third parties to have their order in sync with your system?

I am certainly not so foolish.

Now, that aside, I must confess to having installed ssh, gone into
/etc/rc.local, s/pkg/local/g, and rewritten /usr/local/etc/rc.d/ssh
so that it took stop/start args...

# 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%....

Thank you SO much for working so hard to make my job obsolete.

# > Production-quality sysadmin tools != dumbing down the tools.
# 
# Of course not -- it means making them smarter, more reliable, and more
# consistent, and more automated.

"Dumbing down the tools" : I meant just the transformation you described.
Hiring a monkey to do systems administration.  Thankfully, sysadmin is
more than just that.

# > 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!  :-)

Of course.  I'm a systems administrator (and I do my job very well,
thanks).

I'm a systems administrator because, admittedly, I can script and I
can program my own tools as necessary.  I've never been put on a
programming project from start to finish (and I can't do that on
my own, really.).

# 							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>
# 


				--*greywolf;
--
BSD: The Power of Code.