[Beowulf] What services do you run on your cluster nodes?

[Robert G. Brown]

On Thu, 25 Sep 2008, Greg Lindahl wrote:

> On Thu, Sep 25, 2008 at 06:34:50PM -0400, Robert G. Brown wrote:
>
>> So yeah, XML isn't a magic bullet.  I think half of the anger people
>> seem to feel for it is because they think it somehow should be.
>
> I'm only upset by XML boosters who are so positive about it. You fall
> into this category; when I began picking nits you admitted that XML
> has flaws, but until that point, you were preaching its benefits with
> no mention of its numerous flaws.

One can be enthusiastic about a hammer without thinking all the world is
a nail, Greg.  And in this particular context I AM enthusiastic about
it.  Now ask me if I think that we should rewrite PVM or MPI to send all
data messages encapsulated in XML...

>> That's not the point -- the point is that they are easy
>> to PARSE so one can easily write and debug a PARSER (or encoder)
>
> So that's why XML parsers are so big and expensive, because it's
> "easy".

To make it easy for the programmer, sure, compared to rolling your own
interface for each application, each with whatever ideas you thought of
at the time built into it and different from everybody else's.

> Dude, beauty is in the eye of the beholder, or in this case, in the
> eye of the proud pappa. Your baby is ugly. Your argument of "this is
> prettier than /proc" is a very weak one. If one person designed /proc
> it would probably be prettier than your XML. I'll take Don's beostat
> format sight-unseen over your XML.

Great!  Enjoy parsing the variable value 18 bytes from the beginning of
the address pointer to get a value, and hope that the API never changes
by a byte.  That's perfectly fine as well.  And I'm not being negative,
BTW -- I'm serious, it IS perfectly fine.  It has precisely the
advantages and disadvantages I outlined before.

But -- and this isn't being a proud papa, it is just stating a fact --
you could write a parser for just from the content of my previous email:
without a manual, without a library, without a binary-level data
dictionary, and inside e.g. perl, or C, or java, or php, without
worrying about things like big- or little-endianness.

Ugly vs pretty is irrelevant.  The data is clearly and cleanly
organized, easy to extract and put into structures, capable of dealing
with the natural variability of hardware configuration on the sending
side -- multiple interfaces, CPUs all handled consistently and
automagically, no aggregation or overloading because they suddenly
invented dual or quad CPUs.

    rgb

-- 
Robert G. Brown                            Phone(cell): 1-919-280-8443
Duke University Physics Dept, Box 90305
Durham, N.C. 27708-0305
Web: http://www.phy.duke.edu/~rgb
Book of Lilith Website: http://www.phy.duke.edu/~rgb/Lilith/Lilith.php
Lulu Bookstore: http://stores.lulu.com/store.php?fAcctID=877977