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

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