A False Sense of Security?

Although I am primarily a technical person I have broader interests than just that, including business and marketing. Sometimes these interests intersect in areas that affect a broader cross-section of the population. This is not a technical post.

One of my sources of occasional reading is Seth Godin, author of several books including All Marketers are Liars. He also runs a personal blog, and in the wake of the Thanksgiving rush he wrote this TSA-inspired post about the stupidity of the air transport security rules and the insensitive way in which they are administered. This really rang bells with me.

Godin courageously risks being thought a whiner by ridiculing the rules that allow a full three-ounce container of gel through the screening but disallow a five-ounce container with only one ounce in it. I've spent a lot of time in US airport security lines, and people aren't generally welcoming of critical remarks. Unfortunately many of the "security" activities that we have to go through are what Bruce Schneier calls security theatre.

At the same time as the TSA are forcing even the airline staff to submit to security screenings there are airports where construction staff are allowed airside simply by swiping an identification card. So the terrorists will be targeting the construction workers, not trying to smuggle six ounces of gel through the passenger channels.

Now I know I'm not the only person to suggest that the US government's initial response to the events of 9/11 was off-target. Benjamin Franklin was spot on in saying "Those who sacrifice freedom for security deserve neither". It seems that the majority of American citizens appear to believe that the government has duty to protect them from all risk from the cradle to the grave.

Said citizens, of course, are oblivious to the fact that it is impossible to eliminate risk completely: the aim of security is to raise the cost of a breach to a level that makes the breach uneconomic. But enough is enough. Dulles International has got to the stage where "going through security" can add over an hour to the passenger processing time, and I'm sure others are as bad if not worse. If things go on the way they are, people will stop flying because of the security measures.

What percentage of the American population use the air transport system? How much is being spent every day on airport security theatre, and how many lives is it saving? How much should we be prepared to spend to save a single life? How quickly could we have fresh drinking water available for all of humanity if we spent the money towards that goal instead? How many lives would that save? Which expenditure would make the USA more secure? Isn't it perhaps time for a reassessment of priorities?

Movie Moguls Need Control

In yet another example of movie mogul insanity the MPAA, in the guise of Paramount Pictures, is suing a small business that is ripping DVDs to iPods for customers who buy both at the same time. This highlights exactly why the Digital Millenium Copywrong Act was a bad idea, and it shows American politics up exactly at its worst: as a way for wealthy influence groups to get their own way at the expense of the buying public who have made them rich.

Don't even get me started on software patents.

Corporate governance always makes such a huge fuss about how corporations are really responsible to their stockholders. Who are the stockholders of the MPAA members, and why aren't they telling their managements to start respecting the customers who earn them their living?

Thunderbird QA Not Slipping!

Well, for my sins I have become a Thunderbird 3.0a1 user, and I can't say I'm happy. Several times the program has threatened to update itself, and eventually the promised (threatened?) upgrade arrived. [NOTE: apparently the 3-series builds are intended only for developers].

The error that originally caused me to update to the latest version is even worse in 3.0a1. Message contents are now being mangled on a regular basis. I have no idea whether they can be recovered correctly or not, and I am beginniing to lose confidence in what has until now been a reasonably reliable piece of software. It's ironic that I am suffering this problem even worse than I was because I wanted to help the project by making an accurate bug report.

If many other users are suffering the same problems I am then this issue needs to be addressed before it starts to give open source a bad name.

Thunderbird: Can't Help for Hurting

I've been an enthusiastic Thunderbird user for a fairly long time, and have only noticed odd quirks from time to time. One such quirk is the fact that occasionally a newsgroup article will show completely the wrong content: like the content of some other article altogether. This happened again today, and my first thought was to report the bug.

Now I've reported bugs in the past, and been told that they were duplicates of existing reports. So this time I decided I'd do the right thing and follow the reporting protocol. After all the guys who put Thunderbird together deserve some consideration, and I'm sure many users are cluelessly inconsiderate of the fact they are one amongst milliions and that they haven't paid a cent for some pretty high-quality software. I can't tell whether there is any description of such a bug in Bugzilla -- it might be bug 239665 or it might not.

It turns out that one if the things you are supposed to do is install the latest nightly download in a blank folder with a new profile and see if the same error occurs. This is not a prospect I relish as it will involve a certain amount of setup, but I do the download (nothing much else to do in my hotel room) and start the install. Unfortunately it turns out there's an error in the install, and I see a dialog box showing

Microsoft Visual C++ Runtime Library error R6034: An application has made an attempt to load the C rutime library incorrectly. Please contact the application's support teamfor more information.

Lucky me: I thought I had one problem, but now I have two. I feel duty bound to report this new error under the "Installer" category. Fortunately the installer completes, and I can run the new Thunderbird to confirm the same error occurs (though I stupidlu omit to bring my RSS feeds forward into my new version). So now I can go ahead and add to the bug report for the original problem, since unfortunately it hasn't gone away. My motivation is severely diminished, however, so this may not actually happen. At least I reported the installer problem.

One step forward, at least only one step back.

Stackless Python Continues to Amaze

I recently started tracking the Stackless Python mailing list. I've been interested in Stackless, the brainchild of the fearsomely clever Christian Tismer, for some time now. I recently acquired a client with active interests in that area, so it behooves me to stay up to date.

Stackless allows you to organise your work into tasklets (which as far as I understand it have replaced the original microthreads as the unit for scheduling: this is all pretty new to me, so apologies if it's incorrect). An interesting thing about tasklets is that you can pickle them, pass the pickle to another computer, unpickle them and resume the tasklet in the new environment.

My attention was grabbed by one recent thread in which a user explains that he was trying to perform such interactions across a heterogeneous environment with Power PC, SPARC and Intel-based CPUs and found that it worked between SPARC and PPC, but the Intel architecture appeared to be failing -- presumably due to the different endianness.

After a couple of messages surmising that this was hardly surprising, Christian came into the thread to explain that there was no architecture-dependent code in the pickled thread resumption functionality. Lo and behold, the original poster came back explaining:

I must apologize, it turns out my problem was due to the fact that I was using a different version of stackless on the intel machine. In case anyone is curious, resuming pickled tasklets across architectures is easy. Thank you for your replies!

Let me repeat that, just in case you missed it: resuming pickled tasklets across architectures is easy. As far as I can see this gives Python an amazing capability to produce applications with highly-distributed architectures. It's going to be interesting to see where Stackless goes with this, but it should be shouted from the rooftops. This is an advanced feature that represents a real advantage for (Stackless) Python in a world where everyone is wondering how they can accommodate the new multicore processors.

With Stackless, your CPUs don't even need to have the same architecture, but the feature will work just as well in the homogeneous environment that multi-processor computers provide.