[Beowulf] SuSE 9.3

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.