[Beowulf] Differenz between a Grid and a Cluster???

[Joe Landman]

Robert G. Brown wrote:
> Joe Landman writes:

[...]

> <warning>
>  patented rgb ramble follows, hit d now or waste your day...:-)
> </warning>

"I'm sorry, is this a 5 minute argument, or the full half hour?" 
(quoting Monty Python )

I've been writing (carefully) makefiles that had to work across Crays, 
RISC, Linux,... for quite a while (better part of 16 years), so I am 
unfortunately familar with the pain of cross platform.

<soapbox context="builder of software that has to work the same 
everywhere regardless of the platform">
Note to vendors of differentiated OS/hardware solutions:  They are not. 
  Many are a pain in the neck to port to.    Make it painless to 
transition (ala AMD64), and we might do it if the benefits outweigh the 
costs of typing "make".  Make it painful (pick your favorite declining 
architecture), and we won't.  Really, this isn't rocket science ...
</soapbox>

Right now, one of bits of software works the same across 3 different 
ABIs, three different OSes, each with a few versions.  It has to.  We 
don't have a choice.  It is a royal pain and quite expensive for us to 
deal with surprising issues on some of these platforms.

>> [...]
>>
>>> Some of the gridware packages do exactly this -- you don't distribute
>>> binaries, you distribute tarball (or other) packages and a set of rules
>>> to build and THEN run your application.  I don't think that any of these
>>> use rpms, although they should -- a well designed src rpm is a nearly
>>
>> RPM is not a panacea.  It has lots of problems in general.  The idea 
>> is good, just the implementation ranges from moderately ok to 
>> absolutely horrendous, depending upon what you want to do with it.  If 
>> you view RPM as a fancy container for a package, albiet one that is 
>> slightly brain damaged, you are least likely to be bitten by some of 
>> its more interesting features.  What features?  Go look at the RedHat 
>> kernels circa 2.4 for all the work-arounds they needed to do to deal 
>> with its shortcomings.
>>
>> I keep hearing how terrible tarballs and zip files are for package 
>> distribution.   But you know, unlike RPMs, they work the same, 
>> everywhere.  Sure they don't have versioning and file/package registry 
>> for easy installation/removal.  That is an easily fixable problem IMO. 
>> Sure they don't have scripting of the install.  Again, this is easily 
>> fixable (jar files and the par files are examples that come to mind 
>> for software distribution from java and perl respectively).
> 
> Sure, and when you're done you'll have reinvented an rpm, or close to
> it. 

Hmmm.  What I object to about RPM is not RPM or the philosophy behind 
it.  That is good.  What I object to are the specifications and the 
details of implementation.  Whats really fun is to take a nice simple 
spec file you have been using for the past few years and discover that 
with the new version of RPM in FCx, some simple feature broke that you 
were relying on working, so you have to redo all your spec files ...

What I object to is that rather than a simple and elegant design, it is 
a patch upon a patch upon a patch, several of them incompatible.  It 
does not play well with many tools, requiring some interesting 
acrobatics to get it to work with various software bits.  This is not 
the philosophy thats wrong, I agree completely with the philosophy.  The 
implementation is what is broken.  Horribly.

A long time ago, there was a nice little book I read titled "the unix 
haters guide" or something like that, which detailed what was wrong with 
unix.  It was amusing, but it had one particular valid point.  That 
point was, that if something is broken, and people start writing 
work-arounds for the broken-ness into their codes, then that broken-ness 
which could have been fixed is now part of the specification of the 
system.  I have a sense that this is descriptive of the RPM 
implementations, and specification.

These days I try to keep my RPMs as absolutely simple as possible.  But 
it is important to note that it is effectively impossible to coax some 
software into the full RPM format (.src rpms that wind up as .arch.rpm) 
due to the way they do builds, or allow/suggest you to reconfigure them 
  GAMESS comes to mind as do a few others.  The solution to this is 
*NOT* to exclude software that doesn't fit the confines of RPM, but to 
fix RPM so that enables you to describe any build method, capture any 
software you can build into it, including binaries built after the 
original binary installation (ala GAMESS) so you can track project 
modifications.  Its just not there, and insisting that all software 
adapt to RPM as it is the defacto "standard" package manager simply 
makes life harder on those whose software will not adapt to RPM.

-- 
Joseph Landman, Ph.D
Founder and CEO
Scalable Informatics LLC,
email: landman at scalableinformatics.com
web  : http://www.scalableinformatics.com
phone: +1 734 786 8423
fax  : +1 734 786 8452
cell : +1 734 612 4615