How reliable will the system be? All the sensors keep working, every parking spot, all the time, five nines? No damage from cutting into the pavement for utility work? Salt will never find its way through cracks and short them out? The maintenance crews will be just as diligent in the low-income parts of town as they are in the high-income parts?

How reliable does it need to be? How does it degrade? At any given moment it seems like maybe 2%-3% of all streetlights are out of commission, let's say the failure rate for sensors is about the same; what happens? What is the failure mode like?

How will drivers react if the system directs them to drive a long way for a parking space that turns out to buried in snow? Or occupied by a motorcycle that didn't trip the sensor?

Is this thing robust, or is it just a fantasy that makes a good demo but becomes useless the first year there isn't enough money for perfect maintenance?

The important atomic bomb secret was that it could be done.

The important secret here is that "university-based scientists in the Netherlands and Wisconsin created a version of the so-called H5N1 influenza virus that is highly lethal and easily transmissible between ferrets."

Assume that there are terrorists out there who wish to develop a virological weapon, and have the smarts and the wherewithal to do so. They now know that the H5N1 virus is a good place to start and that there's a winning combination to be found. Holding back the precise blueprint isn't going to delay things much. You have to assume the terrorists are capable of doing research-quality work. It sounds rather as if researchers in the Netherlands and Wisconsin both found answers indepedently. It's quite possible that the terrorists, working on their own, will find something original and better than either of them.

What suppressing the research might do is make it difficult for other researchers to experiment with protective measures against them.

The Manifold Clock not just a clock with a pretty face. It's a paradigm shift. A quantum leap. It's revolutionary, disruptive technology. This is bigger than than flush toilets and the atomic bomb. It's going to blow syzygies out of the water and catalyze our synaesthesia of space and time. It's going to change the world. It's the biggest thing since Microsoft Bob.

The article says "A swallowed pill is essentially at the mercy of the movements of the GI tract. Not so with the microswimmer." Another Googled article informs me that the colon undergoes "Segmentation contractions which chop and mix the ingesta; antiperistaltic contractions propagate toward the ileum, and giant migrating contractions... a very intense and prolonged peristaltic contraction which strips an area of large intestine clear of contents." So among other things this little gadget is swimming downstream when the colon is trying to push things upstream. What does it feel like? Tickling? Gas pains?

When you have a colonoscopy, they give you a sedative (often Midazolam), a pain-killer (often Fentanyl), and sometimes general anesthesia. Of course that's a lot more invasive, but it probably doesn't take as long because the colon is a lot shorter than your whole GI tract. Sometimes the doctor has a little trouble getting a colonscope around a tight corner. Does this thing ever get stuck and how do they deal with it?

I was one of the original G1G1 participants, and I'm sorry to say that the gap between what was promised and what was delivered would never have been forgiven in any commercial enterprise. The "20 hour" battery life turned out to be 3-4 hours, and despite much talk about improvements to the power management software, nothing ever came of it.

The biggest disappointment for me was that the much-heralded "show source" button, didn't. I never quite worked out the tortuous explanations/excuses, but one of the original premises was that all of the machine's source would be available for inspection and modification--to kids, if sufficiently bright. In reality, all the enthusiastic video demonstrations of the "show source" feature were just showing ordinary browser HTML source, and as nearly as I could tell, the "show source" button never did anything more than that.

"Sugar," which I'd hoped would educate me in a brand new model for computer interaction, was, at the time, a bad joke with poor usability. The only way to locate journal entries was by remember to enter text tags for each one when complete, and doing text searches on the tags. It was explained that "fortunately kids like to describe everything they're doing." All usability objections were answered with the retort that I was not part of the machine's intended user base--true enough, and I have never verified for myself whether eight-year-old kids using the OLPC laptop really do type in text tags to enable them to locate their documents.

The one practical use I meant to put it to, as an eBook reader for PDF documents, didn't work because the PDF reader program was buggy, crashprone, and--even when it didn't crash--didn't save your place in the document (and didn't have any bookmarking mechanism). If you stopped reading at page 56, when you reopened the document, you'd be at page 1 and would have to remember what page you were on and scroll to it.

Hopefully all of these problems have long since been dealt with, but it left me with a bad taste in my mouth.

It's from an O. Henry story. Or, at least, O. Henry wrote a story about just such a scam, involving a painting. What WAS the title? Google, click, click. Nothing. Where's my dead-tree copy? Aha. "Babes in the Jungle."

Used to be REALBasic. It is or used to be Mac-centric, though, and I can't speak to how good it is on Windows.

It's sort of what Visual Basic used to be. Or what HyperCard used to be.

Tighter integration between the drawing tools and the code. Less awareness of all the moving parts and the build procedure. You can get to the equivalent of "Hello, world" as easily as you'd hope. Open a blank project, drag a BevelButton and a TextField into the window. Double-click the BevelButton. Type in

textfield1.text = "hello world"

as the code for the "Action" method.

Then you can start typing in fancy things like textfield1.text = str(sin(0.5)) and build up incrementally from there.

Big library of built-in functions and stuff. Not terribly expensive. Pretty good built-in help system. Pretty good customer support. Pretty good community.

There have been many calendar-reform systems proposed, and "leap-weeks" are a common solution. Wikipedia has an article on leap week calendars and lists five advantages and three disadvantages. It, in turn, points to a web page about leap week calendars that details nine of them.

Henry's own web page doesn't mention the existence of other leap week calendars. It merely says the Hanke-Henry Permanent Calendar is better than the Gregorian calendar, not why it is better than the nine other leap week calendars. And it doesn't seem to present any particular plan for getting it adopted, beyond saying "It CAN be done, folks, and the decision is YOURS, not mine. Each of you," and the proof that it's feasible is that his mother has adapted to quoting Celsius temperatures. But what's needed is not a better calendar, but a better plan than anyone has heretofore come up with for getting it adopted.

"When I told you 'thirty days hath September,' I didn't HEX!"

In the first place, this has been known since the time of the ancient Greeks, in the form of the memorization technique known as the "method of loci." Rhetoricians memorized their speeches by associating each part of the speech with a room in their house, and as they gave the speech would mentally walk through the house. This is in fact the source of our expressions "in the first place," "in the second place," etc.

In the second place... uh... I forgot what I was going to say.