On Saturday, November 27, 2010 02:47:12 pm Phillip Gawlowski wrote:
> On Sat, Nov 27, 2010 at 7:50 PM, David Masover <ninja / slaphack.com> wrote:
> > I suppose I expected people to be developing modern Linux apps that just
> > happen to compile on that hardware.
>=20
> Linux is usually not the OS the vendor supports. Keep in mind, a day
> of lost productivity on this kind of systems means losses in the
> millions of dollars area.

In other words, you need someone who will support it, and maybe someone who=
'll=20
accept that kind of risk. None of the Linux vendors are solid enough? Or is=
 it=20
that they don't support mainframes?

> >> And mainframes with vector CPUs are ideal for all sorts of simulations
> >> engineers have to do (like aerodynamics), or weather research.
> >=20
> > When you say "ideal", do you mean they actually beat out the cluster of
> > commodity hardware I could buy for the same price?
>=20
> Sure, if you can shell out for about 14 000 Xeon CPUs and 7 000 Tesla
> GPGPUs (Source: http://en.wikipedia.org/wiki/Tianhe-I ).

=46rom that page:

"Both the original Tianhe-1 and Tianhe-1A use a Linux-based operating=20
system... Each blade is composed of two compute nodes, with each compute no=
de=20
containing two Xeon X5670 6-core processors and one Nvidia M2050 GPU=20
processor."

I'm not really seeing a difference in terms of hardware.

> > All three of which suggest to me that in many cases, an actual greenfie=
ld
> > project would be worth it. IIRC, there was a change to the California
> > minimum wage that would take 6 months to implement and 9 months to
> > revert because it was written in COBOL -- but could the same team really
> > write a new payroll system in 15 months? Maybe, but doubtful.
>=20
> So, you'd bet the corporation

Nope, which is why I said "doubtful."

> just because you *think* it is
> easier to do changes 40 years later in an unproven, unused, upstart
> language?

Sorry, "unproven, unused, upstart"? Which language are you talking about?

> > But it's still absurdly wasteful. A rewrite would pay for itself with
> > only a few minor changes that'd be trivial in a sane system, but major
> > year-long projects with the legacy system.
>=20
> If the rewrite would pay for itself in the short term, then why hasn't
> it been done?

The problem is that it doesn't. What happens is that those "few minor chang=
es"=20
get written off as "too expensive", so they don't happen. Every now and the=
n,=20
it's actually worth the expense to make a "drastic" change anyway, but at t=
hat=20
point, again, 15 months versus a greenfield rewrite -- the 15 months wins.

So it very likely does pay off in the long run -- being flexible makes good=
=20
business sense, and sooner or later, you're going to have to push another o=
f=20
those 15-month changes. But it doesn't pay off in the short run, and it's h=
ard=20
to predict how long it will be until it does pay off. The best you can do i=
s=20
say that it's very likely to pay off someday, but modern CEOs get rewarded =
in=20
the short term, then take their pensions and let the next guy clean up the=
=20
mess, so there isn't nearly enough incentive for long-term thinking.

And I'm not sure I could make a solid case that it'd pay for itself=20
eventually. I certainly couldn't do so without looking at the individual=20
situation. Still wasteful, but maybe not worth fixing.

Also, think about the argument you're using here. Why hasn't it been done? =
I=20
can think of a few reasons, some saner than others, but sometimes the answe=
r=20
to "Why hasn't it been done?" is "Everybody was wrong." Example: "If it was=
=20
possible to give people gigabytes of email storage for free, why hasn't it=
=20
been done?" Then Gmail did, and the question became "Clearly it's possible =
to=20
give people gigabytes of email storage for free. Why isn't Hotmail doing it=
?"