The best server option for Red Hat

[bogstad-e+AXbWqSrlAAvxtiuMwx3w at public.gmane.org (Bill Bogstad)]

On Fri, Dec 10, 2010 at 7:48 AM, Edward Ned Harvey <blu-Z8efaSeK1ezqlBn2x/YWAg at public.gmane.org> 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,

Don't assume that just because a stat call is done to a library that
it is some bizarre attempt to check library versions by Dell et.al.  I
quickly compiled a "hello world" C program on my Ubuntu system, ran it
under strace and saw the following:

....
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=127956, ...}) = 0
....
open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000m\1\0004\0\0\0"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1405508, ...}) = 0
....

Those fstat64() calls appear nowhere in my source code (which consists
of a single printf()).  I would guess that this has something to do
with the dynamic library loading code

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

Some years back I was involved in setting up repeatable builds for
development on Linux systems.   One issue we ran into was that our
build environment put timestamps in the object/executable
files.  The result was that two sequential builds on the same system,
checked out from the same repository wouldn't generate identical
executable files.  (I think this had something to do with our source
code control software putting checkout timestamps into the sources
rather then the compiler itself, but I don't remember the details.)
In any case, the point that I'm trying to make is that any non-trivial
development environment can easily generate trivial file differences
in the resulting object/executable files.   If you add the possibility
of slightly different compiler versions/command line options, binaries
are even more likely to be different.

Bill Bogstad