SCIENTIFIC-LINUX-USERS Archives

July 2008

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
John Summerfield <[log in to unmask]>
Reply To:
John Summerfield <[log in to unmask]>
Date:
Thu, 31 Jul 2008 09:34:53 +0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (104 lines)
Michael Mansour wrote:

> 
> I remember when first looking at all this after Fedora became unmanageable for
> me in the enterprise. I originally looked at Whitebox Linux (yes early days
> I'm talking), Tao, Scientific Linux and CentOS. 

I personally have/maintain one WBEL4, several CentOS{4.5} and SL5 systems.

> 
> The reason I chose Scientific Linux was simple, stability. My highest priority
> was to have an OS which was rock solid and didn't require me to spend the
> large part of my life fixing it, maintaining it, patching it and upgrading it.
> 
> Why didn't I choose CentOS? a couple of reasons:
> 
> * CentOS would immediately re-package and release updates straight after Red
> Hat, bugs and all. SL would perform further tests meaning I had something more
> stable and tested than what Red Hat and CentOS would release. Saving me heart
> ache, stress and time.

If one does not fix a bug, it continues to be a bug in one's system. 
Whenever one makes a change, there is some possibility of introducing a 
new problem (and I've just been bitten by this on a CentOS4 system). 
However, if one installs bug fixes as they become available then one has 
fewer bugs than otherwise.

This is fixed in C5, not in SL5:
https://bugzilla.redhat.com/show_bug.cgi?id=455271


> 
> * at the time CentOS forced upgrades to the latest released Red Hat Updates
> kits. This meant that when I ran, say, CentOS 4.1, and CentOS 4.2 was out,
> CentOS would no longer package and release the errata for 4.1. SL would
> closely follow the same support regime as Red Hat, which supports releases for
> 8 years (although SL committed to 3, which is still ok), no matter what update
> kit/release you're running. I don't want to be forced to do anything
> especially in enterprise production environments where things cannot go wrong.

Unless Connie and Troy roll their own fixes, the only source of fixes is 
Red Hat. Their only choices are to release fixes sourced from RH ASAP, 
or to delay them.

I note that SL5 has the same version of firefox as C5.2 has (3.0) - C5.1 
has firefox 1.5.

Whether the latest SL5 calls itself 5.0 (its release file here syas 5.0) 
or 5.2, there are good reasons to have the same versions of software as 
the latest RHEL5:
Upstreams are only interested in supporting its latest stable versions, 
supporting five-year-old software isn't their concern, it's the concern 
of whomever ships it: RH, CentOS, SL. If RH doesn't care to devote 
resources to supporting old software, SL and CentOS certainly can't. 
Besides, doing so breaks compatibility with RH, and at least for CentOS 
that's critical.

Mozilla in particular is picky about what constitutes "firefox," 
"thunderbird" etc. If they haven't approved code changes, it's not 
"firefox" or "thunderbird." For this reason, Debian doesn't ship 
packages called "firefox" or "thunderbird." (Debian is very picky about 
getting security fixes out the door promptly).

If you have a new system on which you want to install SL4 or SL3, likely 
you will need new drivers.

Now, if there's a problem in CentOS4.0, there will be a fix: it's unfair 
to say otherwise. It might mean you cherry-pick the latest integrated 
update and updates thereto, or you might just let "yum upgrade" do its 
thing. Your choice.


> 
> Since making the decision to go SL over CentOS I've never looked back. I use
> repo's from Dag/Dries, ATrpms, EPEL and even CentOS extras/plus and
> utterramblings (when I really need them for clients). But the point is, the
> approaches's were different for both CentOS and SL when I was looking at this
> years ago, and I needed/preferred the SL approach over the CentOS approach.

Of course, by using all those additional sources of software, one 
forfeits what you see as stability. Especially as those don't all play 
nice together (I recall seeing complaints that the latest, EPEL, didn't 
play nice with the others, after the others had made efforts to be 
compatible and (maybe) integrate at rpmforge.)

If someone packages postgresql 8.3 for RHEL4 you could well get it 
accidentally (something of that kind did happen to me).



-- 

Cheers
John

-- spambait
[log in to unmask]  [log in to unmask]
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)

ATOM RSS1 RSS2