Subject: Re: The new rc.d stuff...
To: None <email@example.com, firstname.lastname@example.org>
From: John Nemeth <email@example.com>
Date: 05/24/2000 23:36:56
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
} > 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