[Beowulf] SuSE 9.3

[Lombard, David N]

From: Mark Hahn on Tuesday, July 12, 2005 5:27 PM
> 
> > Corporate users and ISVs don't want to see the OS revised more than
once
> > a year.
> 
> which is sad, really.  they've been so traumatized by the dominant
> platform that they expect that changing anything will break
everything.
> the very concept of a standard, let alone an interface standard (ABI)
> is foreign to this mentality.

Theory v. practice.  Implementation (i.e., compiler and linker output)
can substantially impact performance and correctness.

As example, the 2.4.6-2.4.18 range of kernels saw a steady rise in
short/small I/O performance at the expense of a steady and significant
loss of large-I/O performance.  In a cluster that we built, we had to
have an I/O monster app run on 2.6.3 nodes and another app run on
2.6.10? nodes so that both apps made their performance targets.

> > On the user side, it takes a lot of effort to install, certify,
> > and then deploy a new OS.  On the ISV side, there is little to no
> 
> certification is bad for users.  instead of an ISV stepping up to the
> plate and saying "our application requires Linux ABI 3.14 and we will
> fix bugs where it doesn't", the ISV just annoints a particular config
> (OS release, firmware revision, disk setup, these magic three patches,
> phase of moon).  certification is really an admission that the app is
> buggy in indeterminate ways, and that the ISV doesn't care.

When I was responsible for such a statement, I had a "batch" app that
was truly only sensitive to kernel and glibc -- and that's EXACTLY the
requirement I enumerated, a minimal set of kernel and glibc
requirements; eventually it needed to become a bounded range.  I also
had a substantial history with the app and a sufficient understanding of
the kernel and glibc to confidently make the claim.

A sister app, a large graphic app was much more sensitive to the
environment, e.g., C++ libs, graphics device drivers, yada, yada, yada.
Despite my best efforts, they stuck with RHL x.y requirements.  They too
had a substantial history with their app that supported their position;
they also thought I was out of my mind--perhaps, but not to this point.

> > revenue associated with certifying an already released app on a new
OS
> > -- it's purely a cost factor unless the ISV is releasing new code.
> 
> managing cost is a good thing.  but doing so does not necessarily mean
> that you also have to screw your customers.  hey, with a little spin
> we can even make certification sound like we're _doing_them_a_favor_!

Many customers DEMAND certification, most accepted policy explanations
and our continued specific performance in lieu of certification.  But,
even so, on a couple of occasions I was ultimately required to provide
distro-release.version-specific certification to specific customers
based solely on their insistence--this I do blame on the lawyers...

-- 
dnl

My comments represent my opinions, not those of Intel Corporation.