Back when I worked on digital camera firmware in 2004, our Taiwanese manufacturing partner asked us to make sure our USB interface worked with Windows 95, claiming that a significant number of their mainland customers were still using this ancient OS. Maybe they're still buying floppies too.

I'm not surprised Apple doesn't support Flash on the iPhone and iPad. I can personally testify that Flash is a serious battery-life waster on laptops too. One morning I was using a web site that had an animated banner ad at the top of each and every page, and I got only 2.5 hours out of my unibody 13" MacBook Pro's "9 hour battery." Without Flash running I can get at least six hours. Then I found the BashFlash app, and realized how often Flash takes 30+% of the CPU. Now I regularly use it to kill the Flash plug-in. Too bad Adobe doesn't give you tools to manage irresponsible Flash adds. A second or two of animation would be fine, after that Flash should "dial it down," but no... continuous attention-grabbing is what the advertisers seem to want, at the expense of my hard-earned battery life!

The 4004 family was fabbed using a 10um pMOS process. Single metal, single poly, self-aligned gate. No depletion. Buried contacts were only used in the 4004 due to density requirements. Pretty sure the rest (4001, 4002, and 4003) used the same process as Intel's SRAMs of the day (e.g. the 1101). Not sure how the diff layer was made. I can ask. Bootstrap loads were used for high-side of push-pull inverters needed to drive big loads. Much to my surprise, diff was used instead of poly for interconnect that couldn't be done in metal.

Dear SPARC International, Inc,

If you want lots of current and future tech professionals to hate you, keep hassling small businesses like SparkFun. Your trademark case against them borders on frivolous. It is a battle that you are unlikely to win in court, and that you will certainly lose in the court of public opinion. Stick with your bread and butter mission: championing the SPARC architecture. Leave popular "Davids" alone, unless the goal is to smear your own brand name.

http://blogofbile.com/wp-content/uploads/2009/04/30/a_scary_thing_happened.pdf

In grad school I studied and developed methods to make programming accessible to young children. At the time, the general consensus in the field was that before the ages of 11-14, children don't typically have the cognitive ability to write programs, even simple ones. Even though I am a professional programmer now, when I was introduced to BASIC at age 9, I definitely didn't "get it." When I got to 7th grade I did.

Radia Perlman did some groundbreaking work in the 1970's to develop technology in the hope that 6-years-old could learn programming skills. Years later, Ken Kahn developed a game/programming environment called ToonTalk. From my personal experience and research, I don't think you can expect kids younger than 9 to build and program robots, but they can start playing with the physical and conceptual "building blocks."

I see from LEGO's literature that WeDo is aimed at children 7-11 years old. Their approach is very sensible: Keep things very, very simple: One motor, one motion sensor, and one tilt sensor. RoboSoccer can wait until they are older.

For further information

The link in the article is to David Merrill's talk at TED2009. Here is a link to David's Siftables project page at the MIT Media Lab

Back in the late-60's and early-70's, when the Busicom 141-PF calculator software was written, United States copyright law was very different, you needed to explicitly mark a work with a copyright symbol, and register it with the U.S. Copyright Office. Nowadays everything is automatically protected by copyright law. Back then it was not. There was no copyright on the Busicom binaries, so this code is free-and-clear. The re-created "source code" was written without access to the original Busicom source code. In this sense it was done using techniques similar to a traditional "clean room".