The article seemed pretty light on details of what MCA Recovery actually does. I found this presentation in PDF format that seems to go into some more useful detail about what this is. It's not just ECC to repair single-bit errors (although that is part of it, apparently). It also includes features to recover from errors that cannot simply be corrected. For example it includes a mechanism to notify the OS of the details of an uncorrectable error, so that it could presumably re-load a page full of program code from disk, or terminate an application if its data has been corrupted, instead of shutting down the whole machine.

Just to clarify, my post was a response to scorp1us, who proposes that red shift isn't caused by relative motion at all, but by a bubble of matter slowing down the incoming light. In which case one would expect it to be all slowed down the same amount regardless of how far it has travelled, which makes it hard to explain the apparent correlation between red shift and distance.

Whereas the conventional theory that red shift is caused by relative velocity, and that objects farther from us have are moving away from us faster, perfectly explains this apparent correlation.

The universe is expanding, so everything is getting farther away from everything else. Thus it does not matter where you observe from, you will see that the rest of the universe is moving away from you. And things which are farthest from you appear to be moving away the fastest. Aliens in another galaxy would see the same thing from their point of view.

The "bubble causing red shift" theory has the major problem that red shift is greater for objects which are farther away (confirmed by other methods of measuring distance besides red shift). How does the bubble know how far the light has gone already, so that it can red shift it by the appropriate amount?

I'll tell one coding "technique" I certainly don't miss at all: the Lotus 1-2-3 macro. My first job after college was to finish development of such a macro, which had been started by the (non-programmer) owner of the consulting company that hired me. This multi-thousand line macro was the production scheduling system for a major transformer manufacturing plant. Back then a macro was simply a recorded collection of keystrokes with some control structures around it to do loops and branches and so on, nothing like the relatively well-structure VB macros of today.

Amazingly, this thing actually worked. When the guy who hired our company to write it got a job with a competing manufacturer, he even hired us again to do the same thing all over again. We were determined to learn from the past and figure out how to write more structured and maintainable code the second time again. Unfortunately we were also determined to do it as a Lotus 1-2-3 macro again. I am so glad I quit that job before having to finish V2.0 of the Mother of all Macros.