[Beowulf] General cluster management tools - Re: Southampton engineers a Raspberry Pi Supercomputer

[Lux, Jim (337C)]

On 9/16/12 8:39 PM, "Ellis H. Wilson III" <ellis at cse.psu.edu> wrote:
>
>On 09/16/2012 07:16 PM, Joe Landman wrote:
>>> >  In addition. Could we, a company of 15 people pay for the continued
>>> >  development and support of OpenIndina?
>> Yes, if this is what you wished to use.  Or you could do it yourself.
>
>I think many of your points Joe are well-made, but I think you see
>things in a very different, maybe even slightly idealistic light because
>of the way your business works (as I understand it as an outside
>observer, so pardon any misunderstanding here).  You and (I suspect you
>do your own hiring) your employees make a business out of tuning every
>aspect of your product.  With the gap between CPU improvements and disk
>bandwidth growing annually and the inane (in my honest opinion) layout
>and API of the I/O stack, tuning can go a long way and misconfiguration
>can hurt a great deal.  So for you, having the source available for
>every level of your product is less a risk-adverse choice than a
>near-absolute necessity for building fast storage.  If you couldn't tune
>some buffer size or whatever because it was inconfigurable and
>closed-source you would be in some special kind of creek, probably
>without a boat-driving device.
>
>However...I can imagine many other businesses try not to worry about the
>OS outside of "will it be there and be supported in X years for a
>/REASONABLE/ cost."

This is one possible reason behind a cluster using Windows, although one
doesn't hear about many large clusters using windows in the science
community.  I'm sure they exist, but you don't hear about them. I think in
the science community, you have a lot of people who know *nix in some
form, and the appeal of almost free for the software is significant.  This
would be particularly the case for the first time would-be cluster
builder, who's often doing it on the cheap.  And once you've built one
using Linux, you've climbed that first step on the learning curve, so you
probably tend to follow it the rest of the way for the next clusters you
build.



>The reasonable part is crucial here, and goes back
>to my (so far unremarked upon) argument that FOSS vs. Proprietary risk
>depends heavily on the size of the source you are trying to work with.

I think that has an effect,but perhaps not as big as other factors.  For
the reasons you elucidate below: having source is nice in theory, but
difficult in practice, if you're not in the OS building business.  It
would probably be difficult to find a large number of software developers
on short notice (although, I suppose, you're probably more likely to find
Linux kernel devs than most others).

I've been involved in some deals over the years where the customer and
vendor had a thing where the source code was escrowed, in case the vendor
went under.  I'm not aware of any of the cases where anyone actually
*used* the escrowed source code.

>So in conclusion, while I think Joe's suggestions are on the money, I
>think they only remain on the money when we are considering tractably
>sized projects (small to medium probably).  Once you get to talking
>about large projects like distributions, kernels, shoot even word
>processors, then the risk you are avoiding is far outweighed by the
>costs your incurring to avoid that risk.



There are probably some analysis codes running on HPC which fit the "able
to be modified/maintained by in house capability":  You may not go into
the deal expecting to modify or maintain something like a finite element
code, but eventually, you wind up doing it.  However in this case, odds
are, you have people who are the users of the code and who are also
knowledgeable about the internal design and function, so they *could*, if
needed, dig in.  (NASTRAN, NEC, codes like that)

>
>In short: Risk isn't everything.  Risk sucks, indeed, and we should
>avoid it where we can by using FOSS projects, but totally avoiding it
>has a price too, and it gets much, much more expensive for larger
>projects.  For small projects where there are equal offerings for FOSS
>and commercial, FOSS will dominate.  But for large projects where there
>are equal offerings for FOSS and commercial...well...that really
>depends.  No matter how open that FOSS project might be, if it is too
>sprawling it might end up being just as impossible, for fiscal rather
>than pragmatic reasons, to keep it updated as its closed-source brethren.


There are also FOSS codes that are just source, with no other
documentation, no design information, etc, and which are basically
incomprhensible to any but the original authors.  This is especially true
with things that sort of evolve over many years, where one or two authors
basically has incrementally updated the software to add features, fix
bugs, etc.   These sorts of things are almost worse than closed source,
because at least with closed source, there's no illusion that you could
mitigate risk by fixing it yourself.


>