Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

The best server option for Red Hat

On Fri, Dec 10, 2010 at 7:48 AM, Edward Ned Harvey <blu-Z8efaSeK1ezqlBn2x/YWAg at> wrote:
>> From: jabr-iwcNaMm7aMIiq3RsQ1AnAw at [mailto:jabr-iwcNaMm7aMIiq3RsQ1AnAw at] 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/ 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  I
quickly compiled a "hello world" C program on my Ubuntu system, ran it
under strace and saw the following:

open("/etc/", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=127956, ...}) = 0
open("/lib/tls/i686/cmov/", 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

BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!

Boston Linux & Unix /