[Beowulf] Differenz between a Grid and a Cluster???
landman at scalableinformatics.com
Thu Sep 22 08:46:36 PDT 2005
Robert G. Brown wrote:
> Joe Landman writes:
> patented rgb ramble follows, hit d now or waste your day...:-)
"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 ...
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
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
More information about the Beowulf