[Beowulf] SuSE 9.3

Mikhail Kuzminsky kus at free.net
Wed Jul 13 08:17:58 PDT 2005

In message from "Lombard, David N" <david.n.lombard at intel.com> (Wed, 
13 Jul 2005 07:23:57 -0700):
>From: Mark Hahn on Tuesday, July 12, 2005 5:27 PM
>> > Corporate users and ISVs don't want to see the OS revised more 
>> > a year.
>> which is sad, really.  they've been so traumatized by the dominant
>> platform that they expect that changing anything will break
>> the very concept of a standard, let alone an interface standard 
>> is foreign to this mentality.
>Theory v. practice.  Implementation (i.e., compiler and linker 
>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 
>loss of large-I/O performance. 
Sorry, does it incorrect for latest 2.4.x, for example 2.4.21 ?
BTW, if you say about ext2fs/ext3fs, and need huge I/O, why not to use 
xfs file system ? 


> 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 
>> plate and saying "our application requires Linux ABI 3.14 and we 
>> fix bugs where it doesn't", the ISV just annoints a particular 
>> (OS release, firmware revision, disk setup, these magic three 
>> phase of moon).  certification is really an admission that the app 
>> 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 
>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 
>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, 
>Despite my best efforts, they stuck with RHL x.y requirements.  They 
>had a substantial history with their app that supported their 
>they also thought I was out of my mind--perhaps, but not to this 
>> > revenue associated with certifying an already released app on a 
>> > -- 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 
>> that you also have to screw your customers.  hey, with a little spin
>> we can even make certification sound like we're 
>Many customers DEMAND certification, most accepted policy 
>and our continued specific performance in lieu of certification. 
> But,
>even so, on a couple of occasions I was ultimately required to 
>distro-release.version-specific certification to specific customers
>based solely on their insistence--this I do blame on the lawyers...
>My comments represent my opinions, not those of Intel Corporation.
>Beowulf mailing list, Beowulf at beowulf.org
>To change your subscription (digest mode or unsubscribe) visit 

More information about the Beowulf mailing list