Application certification (was Re: [Beowulf] hpl size problems)

[Andrew Fant]

Chris Samuel wrote:
> On Thu, 29 Sep 2005 09:18 am, Joe Landman wrote:
> 
> 
>>Worse, when closed source vendors ship product, they qualify against
>>specific OSes, and will not officially support others.  Usually we get a
>>"tell us if it works" perspective.
> 
> 
> This is our experience too. Also in the extreme case we've been told that 
> because we don't run the ISV's web server on the same node as the PBS server 
> then we're in an unsupported configuration.
> 
> Even when I've shown them the bugs in (and supplied patches for) their Perl 
> code.
> 
> 
>>Somehow this seems wrong to me.  I would like there to be a standards
>>body (say LSB?) that says "linux LSB vX.Y is defined thusly", and then
>>have vendors qualify against that, regardless of the distro.
> 
> 
> Agreed, this is what LSB was supposed to do, I believe.  However, nobody uses 
> it, sadly.


Aside from the testing issues mentioned in the recent /. article and cited in
the blogs I cut from this reply, I think that LSB has two major problems, both
related to Red Hat.  The first of which is that the LSB mandates the
availability of RPM as a packaging method.  This isn't so bad, except that the
LSB mandates so few libraries that vendors either need to ship a LOT of static
code, set up their own shared object library trees for what are often commonly
used libraries, or use RPM dependencies to require other packages to be
installed.  The latter option is the path of least resistance, especially if a
suitable RPM can be installed from the Red Hat installation media.  Even if such
an RPM isn't on the media, using dependencies in the RPM makes it hard for users
of Debian, Gentoo, Slackware, and any other non-RPM based distribution to
install and run the software, even if they DO adhere to the other LSB library
versioning requirements, and even if they DO use a ported RPM manager of some
kind because the prerequisite packages will most likely not be installed by RPM
and in RPM's dependency database, but in the native package database of the
distribution in place.

That rant aside, a bigger problem is that there is no such thing as a strictly
LSB compliant distribution.  To pick on my favorite straw man (mainly because I
do belive that RedHat supports LSB not out of altruism but as a market control
measure),  RHAS or RHEL are not strictly LSB compliant distributions, but
supersets of that minimal compliant base, much as DEC FORTRAN and Cray FORTRAN
were supersets of the ANSI FORTRAN 77 standard.  And much as all future FORTRAN
compilers ended up having to support Cray and DEC extensions because everybody
used them, developers end up using features in the core libraries and kernels of
RHEL and RHAS  that are not in the vanilla sources. A RHEL server may ( modulo
the timing problems that are mentioned in Ulrich Drepper's blog) pass the LSB
certification tests, but it ALSO has the features that RedHat has backported
into glibc and the kernel.  (Don't even get me started on trying to compile a
Red Hat kernel on any other distribution).  Since an ISV has to, from a
practical standpoint, use SOME distribution as its development environment, and
since the RedHat distribution is the largest commercial player, the defacto
result is that the majority of applications will be developed, tested, and
compiled for distribution on their products, and only developer discipline and
vigilance will ensure that the temptation to depend on "redhatisms" is avoided.
   In short, we have traded one 800 pound gorilla for an 800 pound walrus.

Andy