Clark’s Three Laws and Other Great Quotes

Oh So Random, Tech and Security No Comments

I recently ran across a few quotes that I feel worth mentioning here. The first 3 relate to technology, and are noteworthy. The remaining ones deal with stupidity. They may seen overly negative to some, but they are intended to be read with an bit of humor.

Arthur C. Clark’s three “laws” of prediction:

  1. When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
  2. The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
  3. Any sufficiently advanced technology is indistinguishable from magic.

The 3rd law was rephrased by NASA’s J. Porter Clark into one of my favorite quotes:

“Sufficiently advanced incompetence is indistinguishable from malice.”

A corollary to this is called Hanlon’s razor:

“Never attribute to malice that which can be adequately explained by stupidity.”

And while I’m on the subject, here’s a great quote from Albert Einstein:

“Only two things are infinite, the universe and human stupidity, and I’m not sure about the universe.”

Finally, German General Kurt von Hammerstein-Equord (what a name) shared these observations about the risks of human stupidity:

“I divide my officers into four classes; the clever, the lazy, the industrious, and the stupid. Each officer possesses at least two of these qualities. Those who are clever and industrious are fitted for the highest staff appointments. Use can be made of those who are stupid and lazy. The man who is clever and lazy however is for the very highest command; he has the temperament and nerves to deal with all situations. But whoever is stupid and industrious is a menace and must be removed immediately!”

Interview with Mastercard’s Rob Reeg

Tech and Security No Comments

Mastercard LogoCIO has a good interview with Rob Reeg, president of Mastercard’s Global Technology and Operations. He discusses their infrastructure and processing architecture. Definitely worth looking at if you’re interested in how credit card transactions are processed.

Interviewer: How big of an infrastructure do you have to support and maintain? It must be huge.

Reeg: Actually from a pure server footprint standpoint… we probably have fewer actual footprint servers because of techniques like virtualization that help us leverage one box to do multiple things.

Where it gets interesting is philosophically: We try to put [transaction] processing as close to our customers, the banks, as possible. When we talk about the global network, we have small servers that sit with the bank customers that connect to our network. What it does is it gives us intelligence there at the end of the network. So as a transaction comes through, we can take a look at that transaction and decide how do we best process that transaction for the benefit of all those four parties in the model.

As to processing, the majority of transactions we’re looking at relate to how do we process them as fast as possible in the most accurate way. The way to do that is by peer to peer: If you’re using your card in Europe, in London, say, and you swipe your card as you check out of hotel, we can route that transaction to the hotel’s acquiring bank in London directly to your issuing bank and get that message back for approval without ever going through St. Louis or some big data center in the middle of all that.

You can read the full article HERE.

San Francisco city officials locked out of computer network

Tech and Security No Comments

San Francisco: LockedUpdate 7/22/2008: The issue may be more complex than it first looks (of course, the media always over-simplifies things). Click HERE to read an insider’s account of the situation.

Okay, THIS is funny because of the glaring security mistakes made by San Francisco’s Department of Technology (or Department of Ignorance, after this one). From the New York Times:

A disgruntled city computer engineer has virtually commandeered San Francisco’s new multimillion-dollar computer network, altering it to deny access to top administrators even as he sits in jail…

Prosecutors say Childs, who works in the Department of Technology… tampered with the city’s new FiberWAN (Wide Area Network), where records such as officials’ e-mails, city payroll files, confidential law enforcement documents and jail inmates’ bookings are stored.

Officials also said they feared that although Childs is in jail, he may have enabled a third party to access the system by telephone or other electronic device and order the destruction of hundreds of thousands of sensitive documents.

This is like security 101… you never give this much power to any single person. On critical systems like this, you always have check-and-balances, outside security code reviews, and strict audits. The S.F. DoT was basically driving around without insurance and got in an accident… I don’t feel sorry for them. It’s really sad how ignorant the world is about security (sigh).

Inside the Software of the Mars Phoenix Lander

Code Monkey No Comments

Mars Phoenix LanderO’Reilly has a great interview up with NASA’s Peter Gluck, project software engineer for the Mars Phoenix Lander. I always find the design and implementation of mission-critical systems interesting. In short, they’re running a radiation-hardened system (the RAD 6000 board) with a 33MHz CPU, 128 megabytes of RAM, and a PCI peripheral interface… pretty advanced stuff for space. This usually surprises people when they first hear about these systems, but the circumstances require proven technology that is hardened against the perils of outer space (for example, the Hubble Space Telescope was recently upgraded to an Intel 486 processor… the Space Shuttle still runs on hardened PDP-11s).

The software is written in C and running on the VxWorks real-time OS… Lockheed Martin (who wrote the control systems) switched from ADA to C a few years back. There are plenty more interesting details in the article. Here are a few teasers:

The RAD 6000 has built in error detection and corrections. So the hardware does RAM scrubbing. There is a RAM scrubbing that occurs on a continuous basis. And beyond that, we have internal fault protection that monitors the health and safety of the software. And if a software task, for example, fails to respond to a ping, we have pings in the system, then the fault protection task will declare that a fault has occurred and will safe the spacecraft. And what that means, by “safeing”, we mean that the spacecraft will enter into a power and communications safe mode where it will just sit and wait for the ground to respond. It’ll basically phone home and say, I’ve got a problem; somebody tell me what to do.

So if it were to completely lock-up, the hardware has to be stroked every 64 seconds. There’s a watch-stop timer. And so if that 64 second period expires, then the hardware resets and the software is rebooted, and hopefully that clears whatever error occurred. Now in the event that that doesn’t work, we have a whole second set of avionics onboard. So the hardware will try to boot to the same side, and if the same side doesn’t come up and start stroking the watch-stop timer, then it will swap to the other side and boot the first side.

Interviewer: Am I right in assuming that there’s very little process separation in the older RAD 6000 boards?

Peter: Exactly… We have strict coding guidelines that we use. We don’t allow dynamic memory allocation, for example.

These are true fail-safe systems… not the stuff we mortal engineers play with. Click HERE to read the rest of the interview.