[Beowulf] hpl size problems

[Robert G. Brown]

Leif Nixon writes:

> "Robert G. Brown" <rgb at phy.duke.edu> writes:
> 
>> On Fri, 30 Sep 2005, Leif Nixon wrote:
>>
>>> So what about us poor souls who need to have several versions of the
>>> same package installed in parallel? Like five gcc versions, two Dalton
>>> versions, two Gaussian (spit!) versions, three Molcas versions, two
>>> Matlab versions...
>>
>> The right solution or the practical solution?  The right solution is to
>> firebomb somebody's house (or possibly begin with delicately veiled
>> threats and a horse's head in their beds) until a company that is
>> selling you software actually bothers to do as decent a job of packaging
>> and keeping up with linux as all the developers in the world do who are
>> doing it for free (or as part of an open source initiative, anyway).
> 
> Sir, you tempt me.
> 
> Did I mention that the latest redhattish OS Gaussian will support on i386
> is Red Hat 9? And that in general they will not support you if you install
> security patches?
> 
> That's right, "the unmodified, unpatched original CD distributions as
> released by the vendor" is the only supported configuration. Install
> any patches, and you're on your own.

No, we have people here who use stuff that is locked into RH 7.1.  RH 9
is downright modern.  And I've heard horror stories on this very list
about RH 6.

This is nothing but a vendor seeking to shirk responsibility for code
maintenance of the sort that every programmer in the world performs as a
standard part of their day.  It is shameful.  Once they write, or port,
an application (getting it to the minimally functional state that will
sell) they view every additional minute spent on taking care of it as a
reduction in their bottom line, and lacking anything like real
competition in these sorts of markets they just stop.

Firebombing is too good for them.  Fire ants and honey.

>> However, since the Evil here is both incredibly, appallingly obvious to
>> us all -- and not your fault, I give you Absolution for any hackery you
>> have to engage in while you're looking for plutonium on the black
>> market.
> 
> Excellent! I'll see you in court. (As a defense witness, that is.)

Down in these parts a viable defense is "He needed killin'".

However, we should really make a list.  Who gets it first?  Cernlib
people?  Gaussian people?  The developer of Pacman, or the appalling
modules package being discussed on this thread (look at this, people
developing code to PROTECT themselves against the consequences of
vendors' refusal to dynamically maintain their code or package it
properly for an operating system).

What this NEEDS is a government edict that money will Not Be Spent on
software that doesn't certify on current versions of the operating
systems on which it is to be run.  Oops.  Three weeks later, Gaussian
would compile and run perfectly on RHEL, FCX, SuSE, Debian....

Seriously, how hard is it to move a code TOWARDS e.g. posix compliance?

Especially a numerical code?  UI code MIGHT need to get twitched this
way or that, but numerical code is sooo boring.  It is actually
difficult to write numerical code that requires significant
instrumentation across systems, and what instrumentation there is is
likely for optimization, not because multiplication or libm suddenly
because radically incompatible.  I don't recall having to change more
than a handful of calls when major glibc revisions occurred in any of my
numerical code.

The other thing that is needed, of course, is completely open source
versions of everything being used, built on top of open source libraries
such as the GSL.  With open source developers/packagers, its going to be
put into RPM format by SOMEBODY, ideally and usually the developers, in
a way that can be at most tweaked to get a build that works across all
major linuces.  RPMs aren't perfectly portable, sure, but MOST linux
packages are routinely built (and rebuild) as needed for all the rpm-ers
and Debian alike.

   rgb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://www.beowulf.org/pipermail/beowulf/attachments/20051001/e426bd8d/attachment.sig>