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

[Ellis H. Wilson III]

Well, this quickly devolved from an interesting exchange on the risk 
considerations for FOSS vs. Proprietary software to mix of mud-slinging 
and idealistic perspectives.

In particular, the subtle attacks on the efficacy in which a poster does 
his or her job started by Greg have no place on this list.  Of course as 
an administrator you should do your research about what software you're 
using in a foundational manner within your business -- it doesn't take a 
genius nor even an idiot to figure that out, and making these level of 
"suggestions" merely stoke a embers because their real purpose is clear. 
  Plus, simply stating one should "choose more carefully" has the 
benefit of 20/20 hindsight.  Anyone can say that about a mistake 
somebody else made.  These variety of comments are wholly pointless on 
this, and really any, email list.  Provided you aren't the boss of one 
of the other posters, we should all make an effort to avoid these comments.

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."  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. 
You suggested in the quoted text above that Andrew's company could 
continue to develop and support OI.  This is, from what I can tell from 
Andrew's comments, NOT what he (or as I claim, most companies) wants to 
do because of the cost and effort involved there.  It would be a MASSIVE 
undertaking to not only patch an OS, but eventually keep it up to speed 
with thousands of perpetually updating packages that you want to 
support.  I don't care if you have 15 or 1500 employees, the up-front 
and recurring costs of being the sole maintainers of your own OS are 
huge.  And you can't /just/ patch an OS as you suggest -- that might 
hold your sinking ship afloat for a year or maybe a tad longer, but 
after that you'll eventually want one of your packages updated and 
dependency hell will jump in to make sure all of your other packages 
need updated too.  You'll either stagnate into irrelevancy or you'll 
move on to another OS.  Providing full, in-house support for an OS (for 
MOST businesses) is just not reasonable.

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.

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.

Best,

ellis