Re: Demonizing generic Linux issues as Fedora Core-only issues -- WAS: Hi, Bryan

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux