John Mashey is a well-known and well-respected greybeard in the computer business. It was a treat to read his many articles on comp.arch. He has forgotten more than I will ever know. But such flattery needs to be tempered by his forays into the global warming debate.
He has posted many comments to http://www.realclimate.org/, generally making fun of the people outside the IPCC clique – those who dare question the work.
Some year and a half ago, he opined, verbosely but wrongly, that releasing all the data and the code used to produced publications by James Hansen’s group at NASA is somehow inappropriate or wasteful. Here’s one, responding to this comment. He seemed to assume that no software + climate expert promised to review the entire code base of whatever widget the NASA people were running. Therefore, he argued, no one else should feel entitled to review anything at all.
Bollocks. That is a ridiculous standard. Nonspecialists routinely contribute meaningfully in open-source projects. Nothing even close is done in the esteemed peer review process that is supposed to give such authority to the published mainstream papers.
His most recent entry is just as obtuse. Here, he’s defending the typical practice of climate researchers to NOT release the snapshots of the data they used in particular published papers, even though many of the data sources (historical temperature tables) are frequently – and retroactively — updated. How warm was it at historical sensor X last year? Well, that depends on when and whom you ask… scary!
Anyway, here is a guy who knows all about software (and hardware). He even comments about how software version control solves many problems. He still seems to be so invested in the position that the mainstream climate people should not have to stoop to fully disclosing their methods that he goes back thirty years in some company history to find a time when some researchers couldn’t be bothered to do version control. And that was swell then, so it must be swell now.
Bollocks and shame. It should be obvious to any software practitioner that simple source control of the changing data sets would make it trivial to both track history and propagate changes. And he should know full well that simple version control is now trivially cheap. (There exist many free public web services to do it if one can’t even host a repository oneself.) There is no excuse for not saving data except negligence … and encouraging enablement by folks such as Mr. Mashey.
It is a cliche in space movies to show the controllers’ “go”/“no go” roll call around launch time. Presumably, each station can veto a flight upon adverse conditions.
It’s not so easy for an ambitious amateur pilot to make the analogous decision. Sure, when the skies are blue and the birds are nowhere to be seen, its easy to “go”. When the weather is poor, or potential technical complications might arise, it is hard, hard, hard to choose.
Take my wife, please trip a few days ago. I was to go to the Boston area to talk with some company customers about some piece of software or other. Thursday 11:30 start time. I live about 590 miles away – 2.5 hours’ flight or 10 hours’ drive. Commercial flights were considered, but not committed to early, and were too expensive at the last minute. Trains for some reason didn’t occur to me. That left flying myself in C-GXRP or driving.
The night before the trip, the weather forecasts were getting worse and worse. Even the civilian forecasts warned of blizzards, ice, and strong ground-level winds. Aviation forecasts were more quantitative but ambiguous. For the morning, 12 hours away, the numbers indicated a bearable if turbulent flight. For the return trip, it looked like a toss-up between good/safe enough, vs. having to stay over another night in Boston.
Waiting a few hours – until midnight or early morning Thursday – would make the aviation forecasts more accurate & reliable. But if those new forecasts were to indicate unflyable conditions, I’d have to drive. If I decided too late, there would not be time to drive and make it to the meetings in time.
After several hours of staring at the numbers and maps, I decided to drive on Wednesday night. I left at 19:30. It was a lousy trip, in total darkness mixed with snow and fog. Three snack and one nap stop punctuated the long slog. I was relieved at the destination a few hours early. Despite the fatigue, meetings started and ended, much mirth was mandated, etc.
I stole some time to look at the weather again, to retroactively second-guess myself. Should I have flown in the morning? Number-wise, the ground winds were less bad than forecast and ceilings/visibilities were higher. But the en-route conditions, a few thousand feet up, told a different story. Winds were ferociously turbulent with big planes reporting moderate/severe turbulence and/or icing down on my hypothetical route/altitude. As the day wore on, it was getting worse, especially over upper New York state. I was soon reassured that driving was after all the right thing to do.
Of course, now I had to get back. Departing Boston at 4:00 in the afternoon was unkindly abrupt to my local colleagues, but a necessary evil to get home soon. The first few hours were fine. I especially enjoyed a chicken & potatoes snack at a toll highway service station. The ground-level wind started to howl, and snow started to pour, Crossing over the Appalachian mountain region from western MA to mid-NY were about the worst driving conditions I’ve experienced, since … well, since the last time I made the same drive two years earlier.
It was the same night, same area, same weather, just a few hours after that Dash-8 plane crashed in Buffalo. I was glad not to be in the air that night, but I was just as unglad to be on the road. Sometimes, when it’s not good enough to fly, it’s not good enough to drive either.