Re: OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?)

["Michael K. Edwards" <medwards.linux@gmail.com>]

Not quite in the same vein, but perhaps amusing to Silicon Valley veterans:

I worked for several years for a 64-bit processor + workstation vendor
that shall remain nameless.  There was this one guy in the other
building who built the kernels for the 64-bit UNIX variant that
shipped with US models.  He had a SunOS 4 box on his desk that
happened to be the only machine in the world where his magic
32-to-64-bit cross-compiler generated working kernels, for reasons no
one ever fully understood.  The external SCSI died one day, and either
there were no backups or they wouldn't restore cleanly.  I don't think
they ever shipped another kernel update.

I can't swear to the accuracy of that story, though; my mind was on
the million-dollar "high availability" NFS server deployment I was
swept up in.  The vendor never did get the electricals straight on the
shared SCSI bus, possibly because we had shelled out for redundant
power supplies via independent UPSes all the way out to the backup
generator, probably creating a gimongous ground loop.  Kept frying the
third-party SCSI cards that were the key to the whole system, and
scrambled the contents of the terabyte RAID more than once.  I don't
think those backups ever worked, either.  The whole kit got ripped out
after some months of chaos and replaced with in-house gear, which
never worked right either.

Somewhere along the way, I figured out that the whole company (a U.S.
subsidiary of a Japanese multinational) was a clever arbitrage of the
Japanese tax system.  As I understand it, they got tax credits for
foreign direct investment each quarter, then turned around and sent
most of the check back to the parent company to purchase custom DIMMs
at absurd prices, earning yet more tax credits for export in a
critical high-tech product sector.  They made a tidy profit at the
Japanese taxpayers' expense even if we accomplished nothing
whatsoever.

The dedicated chip design and verification team didn't seem to have
cottoned onto this, though, and went through literally dozens of spins
(using the parent's semiconductor manufacturing division, natch).
Their design simulated substantially correctly at the logic level
(nothing you couldn't work around in the compiler) from the beginning,
but actual fabrication exposed problem after problem in the cell
library associated with the parent company's recent process shrink.
(Naturally, the NRE sent back to the parent for each chip spin also
qualified for super-duper tax credits.)

By the time the similar processor division back in Japan went through
the same shrink, the cell library and design rule kinks were all
worked out.  So they got working silicon on the first spin where the
logic was correct (which was not, if I recall correctly, anything
close to the first spin; but they probably weren't charged NRE).
Guess which division took the fall?  Hint: the tax credits expired in
2001, and so did the US subsidiary.  They got another tax credit for
liquidation losses, of course.  Legend at the time had it that the
company had never had a break-even quarter in 11 years of existence,
and had burned more actual cash than any Silicon Valley startup of its
era.  (In retrospect the numbers don't appear to support the latter
claim.)

I got to do some fun stuff while I was there, though, including a
Frankenstein monster of an encrypted CVS transport that slotted SSLeay
into the GSSAPI interface intended for Kerberos.  (Given the choice of
Kerberizing the site or running our own CA for client certs, we picked
the latter.)  Although we had the source to Solaris, UnixWare, and
Windows NT all under one roof, the "secure" version control was not
for any of these.  It was reserved for the real crown-jewels-on-loan:
the source to the OpenBoot PROM.  Go figure.

Cheers,
- Michael