On Sunday, November 28, 2010 08:00:18 am Phillip Gawlowski wrote:
> On Sun, Nov 28, 2010 at 1:56 AM, David Masover <ninja / slaphack.com> wrote:
> > In other words, you need someone who will support it, and maybe someone
> > who'll accept that kind of risk. None of the Linux vendors are solid
> > enough? Or is it that they don't support mainframes?
> 
> Both, and the Linux variant you use has to be certified by the
> hardware vendor, too. Essentially, a throwback to the UNIX
> workstations of yore: if you run something uncertified, you don't get
> the support you paid for in the first place.

Must be some specific legacy systems, because IBM does seem to be supporting, 
or at least advertising, Linux on System Z.

> > "Both the original Tianhe-1 and Tianhe-1A use a Linux-based operating
> > system... Each blade is composed of two compute nodes, with each compute
> > node containing two Xeon X5670 6-core processors and one Nvidia M2050
> > GPU processor."
> > 
> > I'm not really seeing a difference in terms of hardware.
> 
> We are probably talking on cross purposes here:
> You *can* build a vector CPU cluster out of commodity hardware, but it
> involves a) a lot of hardware and b) a lot of customization work to
> get them to play well with each other (like concurrency, and avoiding
> bottlenecks that leads to a hold up in several nodes of you cluster).

Probably. You originally called this a "Mainframe", and that's what confused 
me -- it definitely seems to be more a cluster than a mainframe, in terms of 
hardware and software.

> > Sorry, "unproven, unused, upstart"? Which language are you talking about?
> 
> Anything that isn't C, ADA or COBOL. Or even older.

Lisp, then?

> This is a very,
> very conservative mindset, where not even Java has a chance.

If age is the only consideration, Java is only older than Ruby by a few 
months, depending how you count.

I'm not having a problem with it being a conservative mindset, but it seems 
irrationally so. Building a mission-critical system which is not allowed to 
fail out of a language like C, where an errant pointer can corrupt data in an 
entirely different part of the program (let alone expose vulnerabilities), 
seems much riskier than the alternatives.

About the strongest argument I can see in favor of something like C over 
something like Lisp for a greenfield project is that it's what everyone knows, 
it's what the schools are teaching, etc. Of course, the entire reason the 
schools are teaching COBOL is that the industry demands it.

> Don't forget the engineering challenge. Doing the Great Rewrite for
> software that's 20 years in use (or even longer), isn't something that
> is done on a whim, or because this new-fangled "agile movement" is
> something the programmers like.

I'm not disputing that.

> Unless there is a very solid business case (something on the level of
> "if we don't do this, we will go bankrupt in 10 days" or similarly
> drastic), there is no incentive to fix what ain't broke (for certain
> values of "ain't broke", anyway).

This is what I'm disputing. This kind of thinking is what allows companies 
like IBM to be completely blindsided by companies like Microsoft.

> Google has a big incentive, and a big benefit going for it:

Which doesn't change my core point. After all:

> a) Google wants your data, so they can sell you more and better ads.

What's Microsoft's incentive for running Hotmail at all? I have to imagine 
it's a similar business model.

> b) The per MB cost of hard drives came down *significantly* in the
> last 10 years.

Yes, but Google was the first to offer this. And while it makes sense in 
hindsight, when it first came out, people were astonished. No one immediately 
said "Oh, this makes business sense." They were too busy rushing to figure out 
how they could use this for their personal backup, since gigabytes of online 
storage for free was unprecedented.

Then, relatively quickly, everyone else did the same thing, because people 
were leaving Hotmail for Gmail for the storage alone, and no one wanted to be 
the "10 mb free" service when everyone else was offering over a hundred times 
as much.

I'm certainly not saying people should do things just because they're cool, or 
because programmers like them. Clearly, there has to be a business reason. But 
the fact that no one's doing it isn't a reason to assume it's a bad idea.