[PLUG] RHEL, CentOS, SL

Keith Lofstrom keithl at kl-ic.com
Fri May 13 22:45:48 UTC 2011


On Fri, May 13, 2011 at 01:07:59PM -0700, Paul Heinlein wrote:
> Second, for CentOS developers, 100% binary compatibility is required 
> for a release. That means that every library and executable will have 
> exactly the same linking and dependencies as RHEL. Running ldd against 
> a library on CentOS will show the exact same dependencies as the same 
> library on RHEL. SL aims for a bit broader target, and the 
> dependencies aren't tracked as exactly.

As always, Paul makes excellent points.  As an example of the
way SL deviates:  about a month ago a security mod to glibc,
propagated through the RHEL5 update process. The update broke
gnome-panel.  The Fermilabs support team for SL released a
partial patch a few days later, and a full patch about a week
later, pushing the patch back upstream to RedHat.  I welcome
that kind of response, but it doesn't conform to 100% binary
compatability to The Upstream Vendor.

I run some $$$$ proprietary chip design software targeted
for RHEL5, but use SL instead.  I also use EL5 and CentOS5
repositories for upgrades, and have not had any problems, so
"less than 100% compatability" has never been an issue for me. 

My biggest problems are with the bleeding edge developers
attracted to projects like OpenOffice and Firefox, who insist
on very recent versions of libraries.  Since I've written an
enormous collection of small one-off programs for Real
Scientific Computing ("Horrors! Using a computer for computing?
HERESY!!!") over the years, the biggest problem with the
upgrade treadmill for me is breakage (excuse me, upgrades)
of the libraries these older programs depend on.  That kind
of breakage affects the chip design programs I use, too.

The Scientific Linux support team is sensitive to this, and
occasionally will release SL security updates of Firefox and
other tools that don't need new libraries.  Most scientific
computer users are in the same boat I'm in.  Some of them
run multi-month compute jobs on kilo-processor parallel
machines, and don't take kindly to security upgrades which
break the programs they are using.

Legacy code doesn't work for everyone.  Some people do
best with the latest and greatest code (and ride 20 year
old bicycles).  But when developers are too clueless to
realize that the world that feeds and clothes and houses
them is strongly dependent on legacy code, they should not
be in charge of the upgrade process.  Fortunately, there
are clueful support teams who understand legacy code.

In any case, I'm glad the CentOS folks are still doing good
work.  I hope they get back on track for a timely 6.1 release.

Keith

-- 
Keith Lofstrom          keithl at keithl.com         Voice (503)-520-1993
KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon"
Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs



More information about the PLUG mailing list