The best server option for Red Hat

[jarod-ajLrJawYSntWk0Htik3J/w at public.gmane.org (Jarod Wilson)]

On Dec 10, 2010, at 7:48 AM, Edward Ned Harvey wrote:

>> From: jabr-iwcNaMm7aMIiq3RsQ1AnAw at public.gmane.org [mailto:jabr-iwcNaMm7aMIiq3RsQ1AnAw at public.gmane.org] On Behalf Of John
>> Abreau
>> 
>> You've shown that Dell software behaves differently on CentOS vs RHEL.
>> You have *NOT* shown any evidence that Red Hat did any proprietary
>> development for Dell.
> 
> Correct.  This is a discussion for the sake of information, not an argument
> for the sake of proving I'm right and someone else is wrong.
> 
> For what it's worth:  I have also shown that closed-source binaries released
> by dell have hard-coded rhel specifics, more specific than just the
> redhat-release, into them.  It appears they are "stat"ing standard
> libraries, such as /lib/libdl.so.2 which is a supposed binary-compatible,
> centos not-modified, standard system library.  But in rhel it's 15048 bytes,
> and in centos it's 16748.  And many other such libraries etc.

Unless CentOS compiled their libdl in *exactly* the same build environment
as Red Hat, then they're not the same thing. A bug in a compiler, some
different version of a build dependency, CFLAGS that don't match, a CPU
bug, etc., and the resulting binaries will be different, potentially in
very significant ways that cause different behavior of either the binary
itself, or something linking against the binary.

A third party, such as Dell, builds their binaries against the libraries
shipped by Red Hat. You've already shown that there is a measurable
difference between libdl's, so any expectation of 100% compatibility
goes right out the door. Red Hat has absolutely nothing to do with the
inability of CentOS to reproduce the build, other than perhaps not
spelling out the exact recipe for the build environment and making the
same build host and binary Red Hat packages available for CentOS to
use to build their package. Which would of course, be insane for Red
Hat to do (we have shareholders).

This is exactly why certification on Red Hat != certification on its
many rebuilds. As close as the rebuilds are, they're not bit for bit
identical. In my eyes, you haven't definitively shown that Dell have
hard-coded RHEL specifics beyond redhat-release, though I'll grant
you that its possible they came up with some way to distinguish
between libraries build on RHEL and libraries not build on RHEL, and
wrote their code to behave differently on non-RHEL. What you *have*
shown definitively is that CentOS is not 100% binary compatible with
RHEL, which I think is a point I've been trying to make understood
from the very beginning. :)

However, I'd also like to address what I believe are the reasons you
are seeing fewer problems with CentOS 5. It all goes back to the
build environment. With RHEL5, Red Hat has always had mock at the
center of the build environment. When using mock to build packages,
they're all built in a freshly populated chroot that contains only
the minimum build requirements. This same build environment is used
for Fedora, and so far as I know, for CentOS as well now. I'm not
sure on exact timeline, but I'm reasonably sure mock didn't exist
when RHEL4 first shipped, and to this day, there's still no yum in
the RHEL4 package collection, and mock relies upon yum to do its
buildroot population. So its less surprising that the environment
used to build CentOS 4 might not be as close to that of RHEL4 as
CentOS 5 might be to RHEL5.

Again, honest, Red Hat isn't doing anything nefarious. This is just
reality here: a rebuild isn't 100% the same thing, so expecting it
to be 100% compatible is fool-hardy, as is getting mad at Red Hat
when reality bites.

-- 
Jarod Wilson
jarod-ajLrJawYSntWk0Htik3J/w at public.gmane.org