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

[Mark Hahn]

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

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

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

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

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

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

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

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