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

[Andrew Fant]

At the risk of further decreasing the signal to noise ratio and raising 
suspicions that I have nothing better to do than to argue on the list on a 
Friday night, I feel like I ought to further respond

Mark Hahn wrote:
>>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
> 
> 
> I don't see what the problem is - RPM is expressive enough, probably.
> look at Yum - probably one of the best package tools, and not apparently
> crippled by RPM.

The problem is that yum still uses RPM under the hood.  Why should my prefered 
Linux distribution be a second-class citizen because it has its own mechanism 
for resolving dependencies that Red Hat hasn't blessed?


>>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
> 
> 
> really?  I haven't looked at a lot of binary/closed apps, but what do 
> they depend on?  LSB covers all the normal system interfaces, including X.

Lets start with toolkits on top of X, such as motif, gtk, or qt.  Or, to use a 
  library close to RGB's heart, libxml2. For that matter, any of the standard 
numerical libraries that many of us live by, such as blas or lapack.

> 
>>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
> 
> 
> but isn't that fair?

No, it isn't fair.  Depending on the Red Hat RPMs means that it isn't running 
on Linux, it is running on one particular (very commericalized) version of 
Linux.

> 
> 
>>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.
> 
> 
> hmm, I use Yum, which appears to be exactly the sort of non-RPM tool that 
> LSB explicitly permits.  it seems to do OK with non-Redhat RPMs.

But it still expects you to be storing all your package dependencies in a RPM 
formated DB. And you still are using RPMs for your package management.  Some 
of us do use distributions that aren't RPM based.

> 
>>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
> 
> 
> but how is this bad?  if the users really do think the extensions are great,
> the next version of the standard should include them.

Standards take years to be updated.  Witness the FORTRAN 8x standard where x 
had to be expressed in Hexidecimal.  And don't market your standard to ISVs as 
"the one way" to ensure cross-distribution compatability when it includes 
requirements that exclude some distributions from full participation.

> 
>>Red Hat kernel on any other distribution).  Since an ISV has to, from a
>>practical standpoint, use SOME distribution as its development environment, and
> 
> 
> but it doesn't have to be so slovenly in coding that it has RH-isms.

It doesn't have to be, but it often is.

> 
>>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.
> 
> 
> so why don't app-developers strive for this minimal-seeming level of competence?

Some do.  Most of my software suppliers actually DON'T ship their software in 
RPM format, thank goodness.  They still come up with reasons not to provide 
support if you aren't running their pet distribution ( and for someone who 
supports an enterprise cluster with enough different applications that there 
IS no one distribution that officially runs all of the applications in 
question, this is a giant PITA), but at least I can get it all installed and 
then start worrying about munging versions of shared libraries and 
configuration file contents to get it all running.

> 
>>   In short, we have traded one 800 pound gorilla for an 800 pound walrus.
> 
> 
> I think you're saying that RH is the new MSFT, which seems pretty funny...

Actually, I see it as rather sad.  As it was pointed out in a parallel thread, 
Gaussian will refuse to support your installation if you are using anything 
more recent than RedHat 9 and even them, you aren't supposed to put security 
patches on.  To too many ISVs Linux := some version of RedHat.  I will admit 
that I am somewhat of a Gentoo partisian, and that makes me suspect.  But why 
should I be expected to mirror my dependency trees into an alien db format and 
jump through hoops to compile a backporting nightmare of a kernel just to 
support "standard" code?   Red Hat does not own Linux, even though 9 out of 10 
CIOs would be hard pressed to name another distribution.  The whole point of 
Open-Source software is  supposedly about being able to get your hands dirty 
with the code and have meaningful standards for interoperability that one can 
reproduce without being at the mercy of ANY commercial vendor.

-- 
Andrew Fant    | And when the night is cloudy    | This space to let
Molecular Geek | There is still a light          |----------------------
fant at pobox.com | That shines on me               | Disclaimer:  I don't
Boston, MA     | Shine until tomorrow, Let it be | even speak for myself