[Beowulf] General cluster management tools - Re: Southampton engineers a Raspberry Pi Supercomputer
Ellis H. Wilson III
ellis at cse.psu.edu
Sun Sep 16 20:39:05 PDT 2012
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.
More information about the Beowulf