On Sep 6,  4:27am, Jay Maynard wrote:
} On Sun, Apr 16, 2000 at 06:35:20AM -0700, John Nemeth wrote:
} > The point of this, is that when I talk
} > about what works (for me), it's not on a whim, it's based on a lot of
} > real world experience in a variety of settings doing a variety of jobs
} > with a variety of OS'es.
} 
} Me too. My list is the same as yours, except that I don't have SunOS 4.1.3
} and do have AIX 3.2, IRIX 5.3, 6.2, and 6.5, and OSF/1^H^H^H^H^HDigital
} Unix^A^A^T^TTru64 Unix 1.3, 3.2, and 4.0.

     I did Irix 4.0.5F at one point, and I've assisted people with AIX
and OSF/1.  I also played on A/UX at one point.  I also have an AT&T
3B2/200 kicking around which has genuine SVR2 loaded on it.  There
aren't very many unix varients that I haven't at least used at some
point.

} >      Given my experience, I would order the above systems for ease of
} > administration, from easiest to hardest as follows:  NetBSD, SunOS
} > 4.1.3, SunOS 5.5, HP-UX 10.20, SCO UNIX, and lastly RedHat Linux.
} 
} I think this is a matter of what you learned first. I learned SysV first,

     Possibly.  The first UNIX system I used was a Pyramid running OSx
(the dual domain OS).  From there I went to real 4.2BSD on a VAX 11/780
and SunOS 3.x on a 3/280.  Around that time, I also poked at Apollo's
DomainOS.  The first UNIX system I "administered" was Minix and that
was fairly early in my UNIX career.  Minix was basically a teaching
system that could run on a PC XT, so it was very minimal.  From a
usage/admin viewpoint, it was probably very much like V7.  It was
basically an adjunct to Andrew Tannebaum's Operating Systems textbook.
>From there, I jumped to SunOS 4.x and Ultrix 3.x, which were both
production systems.  Although, I'm reasonably comfortable using and
admining both BSD and SysV derived systems, I much prefer to use and
admin BSD based systems.  Given that I started in the BSD world, that
may be a factor.  Although, from a usage viewpoint I found BSD systems
to be more featureful and easier to use (note that SVR4 has caught up
on most aspects).  From an admin viewpoint, I find BSD to be simpler
and more logical.

} and so am used to how it goes about doing things; a quick grep finds the
} exact file I need to modify, no matter which system I'm sitting down in
} front of this time. (Ironically enough, the quick grep method needs a
} modification on Solaris - only - because of two named pipes they stuck in
} /etc. Argh!) BSD systems still drive me occasionally nuts.

    Hmm, that is annoying.

} > The SysV based systems come next because they spread out
} > configuration all over the place, meaning I have to go hunt for what I
} > need to change, but are otherwise relatively easy to maintain.
} 
} If you're not finding what you need to change in a matter of seconds, you're
} not searching well. Use the available tools. At some point, if you maintain

     The point is that I shouldn't have to hunt at all, it should all be
in one place.

} >      This is where contractors come into play.  And, the easier it is
} > to maintain a system, the less its administration will cost you (of
} > course, the reliability of the system also plays a factor here).
} 
} Exactly - and the ease of maintainability and reliability of the system

     Perhaps, but I would say they are correlated.  The easier it is to
maintain a system, the less likely screwups will occur in the first place
which would make the system more reliable.

} aren't always the same, especially in the face of admin screwups - which
} WILL happen, unless you're claiming to be perfect.

     Nope.  However, in the ten years I've been doing system
administration professionally, I can count on one hand the number of
times I've clobbered a system so badly that I needed to be at the
console to fix it.  And, of those, only a couple were really serious
and they were done at the beginning of my career.

} >      How often do you make changes to system startup?  I rarely "fiddle
} > that file" after initial system configuration.
} 
} That argument cuts both ways: if you don't change the configuration often,
} what's the problem in costing an extra grep if you can't remember where the
} setting is?

     If something is rarely done, then the easier it is, the more
likely it will be done right.  If somebody performs a complex procedure
everyday they are more like to get it right, then a complex procedure
that is only performed once in a blue moon.  Therefore, it is better
for rarely performed procedures to be simple.

}-- End of excerpt from Jay Maynard