On Saturday 28 May 2005 00:37, Collins Richey wrote:
> I get a chuckle out of this. You may not have actually said that the
> RedHat enterprise releases are better than other distros, but you have
> vigorously sought to prove RedHat totally blameless when confronted by
> the effects of their release choices (inclusions and omissions). When
> anyone dares to complain, SLA is offered as a panacea for all supposed
> failings.
Bryan has simply tried to balance against Red Hat bashers who seem to think
that Red Hat connot do anything right. Red Hat is not blameless; but neither
is Red Hat a Demon Evil. Red Hat has done a lot of good for the open source
community.
> I find RHEL/CentOS to be a blessing and a curse.
I find computers in general to be a blessing and a curse. A blessing in that
it keeps me employed; a curse in that that employment can be frustrating at
times dealing with the people effects of computers (that is, computers are
made by people; operating systems are written by people; computers are used
by people: and people are not perfect, nor is anything made by people ever
perfect).
> It's certainly
> reliable (my desktop system has encountered no significant problems)
> and the CentOS list is a real gem, but what's going to happen when the
> next round of 2-2-2 6-6-6 hits? Actually, it's already underway. Will
> there be just as many functions dropped that people know and love and
> cannot relinquish without a lot of extra rework, and what new (only
> partially backwards compatible and perhaps still in their infancy)
> functions will be added that cause real grief and more rework for some
> portion of the community?
Track Fedora and make up your own mind; this is the way it works and is the
original reason for the existence of RawHide (now know by the much more
mundane name of Fedora Core Development). Jonathan Kamens, for instance,
tracks RawHide on several machines that he uses on a daily basis, and he
catches all kinds of issues by so doing. Otherwise, you can at least put of
the decision five years until RHEL4 (and by extension) CentOS4 are EOL'ed.
If you don't want to spend the time, effort, and money to track RawHide you
can track the FC releases (don't bother with Fedora Core Test if you're not
willing to track RawHide with it).
If you don't want to spend the time, effort, and money to track FC releases,
then you really must approach things the classical IT way: read the release
notes, and wait on the .1 to deploy at a minimum (in RHEL-speak wait on the
U1 at minimum). And run it on a development server set up identically to
your production server before trying to migrate production. If you can't
afford a development server you really have a problem (one site I work at is
in this shape; it's a school, and in that case I roll out to them what I
already know works, and in fact waited on a rollout for the CentOS4 release
so that I wouldn't be saddled with CentOS3 for the next four years). But you
will get what you pay for, even running a 'free' release; you don't want to
spend the time before hand you WILL spend the same amount or more of time and
a whole lot more grief afterwards if you ignore basic preparations. If
you're still employed, that it. I was serious about the 'in my shop such
could be grounds for dismissal' remark I made earlier; admins should not be
so reckless, and will not be so reckless on my servers.
And you don't blindly cron a yum -y update, either. You stage yum updates on
a dev box, too, or be prepared for breakage if someone upstream made a
mistake (mistakes do and will happen). Things like the MegaRAID driver being
upgraded; in that particular case you really must have an identical
development server to fully mirror your production server, because the
MegaRAID drive can work or not work based on chipset lot number, all other
things being the same.
The flip side of the freedom of open source is the same as the flip side of
any other freedom; with rights come responsibilities. If you want all
decisions made for you run Windows. And even then you run a pair of
identical servers to roll out deployments (as people who have deployed Server
2k3 SP1 have found out the hard way) or you run considerable risks.
Risk-cost-benefit analysis must be done, or you can get burnt, badly. It
boils down to just how critical that server really is.
For example, a JIT-ERP (Just in Time Enterprise Resource Planning) server
being actively used for production line scheduling in a busy factory with a
couple of thousand line workers would be very critical and probably would
still be running RHAS 2.1 even now, since even RHEL3 is not well-tested
enough for that application. Hmm, one might even still be running RHL 6.2EE
on that kind of app, given the flack over gcc 2.96 (at the base of RHAS 2.1).
A misstep in the deployment of an upgrade there could cause the entire IT
department to lose their jobs easily; if done very poorly could cost the
whole business if the production line were taken down for an appreciable
amount of time. And Linux would never be found in that factory again.
This is the market towards which Red Hat Enterprise Linux (R) is striving.
> One thing that would help would be a roadmap. It shouldn't be
> necessary to pore over change logs to get an idea what is coming.
The roadmap exists, and it's called Fedora Core. You can watch it develop in
real time. With as many projects and packages as there are represented in
RHEL it would be impossible to accurately predict any future feature 18
months distant. Instead, you can track what they are trying to do (and you
can track their backsteps!) by simply tracking RawHide. On a development
machine, of course. If you don't have time to do this, hire someone who
does.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu
