The best server option for Red Hat

[blu-Z8efaSeK1ezqlBn2x/YWAg at public.gmane.org (Edward Ned Harvey)]

> 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.

Why would they do that?  I have no answer, except to point out that we don't
know who wrote those binaries.  They are released by dell, but they could
have been developed by dell, redhat, or anybody else that dell hired.


> Jarod works at Red Hat and is in a postion to be aware of any proprietary
> development at Red Hat, if any existed. He has repeatedly asserted that
> no such development exists.

I will agree that redhat does not release proprietary code in rhel.  But
redhat is also a company for hire, who can and will develop proprietary code
for your company directly, if you hire them to do such development.

But as alluded to above, it is immaterial WHO wrote dell's proprietary code.
The only thing that matters is (a) such proprietary code actually exists,
and (b) there are reasonable workarounds so you don't have to worry about it
too much.