Next up: there was a guy with a video camera at his “Open Source as Liberal Art” talk. I really must track down a recording of it, because it was even better.

GigaPan, as described to me by Jason Campbell, is a method for very cheaply taking very high-resolution panoramic images. The basic idea is to have a commodity digital camera in a computerized servo-mount on a tripod. The servo-mount pans the camera over the desired areas, taking pictures at appropriate intervals as it goes. The gigapan web service then stitches the entire set of images together and provides a convenient interface for viewing.

Bonus nifty #1: no special interface is needed to the camera. It just uses another servo and a stick to manually depress the shutter switch!

Bonus nifty #2: Because the entire panorama isn’t taken at once, but over the course of several minutes (for potentially large values of several) as the camera pans over the scene, it doesn’t capture a point in time but a distribution. This occasionally creates strange artifacts when images are stitched together, but potentially has some very cool implications. Imagine if you had enough storage to keep one of these running throughout the course of an entire event of some kind, or even a significant span of time. Would it be possible to present an interface to the resulting time-distributed panorama that reflects the wealth of information gathered?

Martin Wattenberg is just plain awesome. I’d seen Name Voyager before (it’s great fun to play with), but his presentation on Many Eyes was really cool. It’s apparently being used extensively by a lot of linguistics and literary researchers, including Bible scholars. One of the more interesting observations from his talk: the key to Many Eyes was “stop words”, garbage connecting words that most software types would be inclined to throw away. However, the presence and usage of these words can offer more information about a piece of text than “significant” words!

And Evil Mad Scientist still has the best company name ever.

Lessig provides an excellent explanation in Code 2.0 of why this is a horrible idea. Ignoring government and forging boldly forwards on your own doesn’t create an system that cannot be regulated by government. Instead, it cedes the government space to the authoritarians, allowing them to operate and expand its influence uncontested. We’re seeing the end result of that in politics now. Across pretty much all of the western world, the notion that “government is inherently harmful” or “government can do no good” or dozens of different variations on the theme have taken hold. As a result, those that would support a progressive agenda have largely abandoned government, and authoritarianism has grown unchecked.

Further, the history of privatization in the 20th century has been an unchecked series of disasters. Private entities are motivated wholly by profit, and thus incredibly susceptible to authoritarian influence. They make more money from it, after all. Public entities are, at least theoretically, answerable primarily to the public good which, in a democratic system, is determined in a distributed manner.

I believe that government can be made to understand the Benefits of Free and work in a distributed, free model. In fact, I believe it is inherent to a properly functioning democratic system. But we won’t have a properly functioning democratic system unless we believe that government can do good; that free and public are complementary, not opposed; and that “being political” is something desirable, rather than something repugnant.

I’m not going to talk about the talk itself except in the most general terms above (as per FOO Camp policy, I shall only be blogging about publicly-available stuff) but I will talk about my reaction to it, since the whole thing hit very close to home for me.

I’m hasty. I tend to jump into things without thinking or looking. I make rushed decisions, I jump into things, and I tend to constantly strive for better without appreciating what’s there. This is most obvious in my thesis, when I decided not to use NS2 and wrote my own network simulator instead. I learned a hell of a lot, and it honestly probably didn’t take longer, but… Was it the right decision? I’m not sure. I thought at the time that I’d considered all my options carefully, but in retrospect, I think I might’ve jumped at the opportunity to demonstrate my ego. Honestly, I think a lot of software folks are this way – it’s why we’re so bad at code re-use.

The Art and Adventure of Beekeeping is all about the value of observation, contemplation and patience. I’ve been suggesting for a while that our culture needs to learn the value of being slow again – for example, we need to realize that not being able to travel halfway around the world in less than twelve hours is not necessarily bad. But listening to Fitz talk (and joining in the discussion), I realized that I need to learn that I don’t need to do everything at 100% speed. There’s a lot of value to sitting and watching beehives, listening to the bees and learning their behaviors. Before you jump in and start clearing out honey and replacing bits of the hive, you’ve got to learn the feel of what’s already there and what that feel means.

Another interesting thought was that cleanliness isn’t necessarily the highest virtue – things that are messy can still have value. Cleaning them up without pausing to observe them and consider them from different perspectives can inadvertently destroy that value. Yes, working with them in the interim can be annoying, but it’s better than wading in and wrecking things before you grasp the full picture.

I could probably write a small book about the stuff in that session, but I think I’m going to stick to two more little bits. First off, unless you’re writing an RFC, don’t say “should”. Should usually means that you’re coming to a situation with a pre-conceived notion of how it “should” be, making snap value judgments without actually taking the time to observe.

Secondly, “failure scales.” It may sound like a quip, but it’s surprisingly accurate. It’s hard to replicate success, it’s much easier to replicate failures or borderline marginal.

Mark Dominus demonstrates one example of this while examining the whole “Design Patterns” mess. The “Design Pattern” movement seems to be unconsciously based on this ignorance of history, through an assumption that modern programming languages are the be-all and end-all of programming languages, and always have been. As Dominus puts it:

If these problems recurred in every language, we might conclude that they were endemic to programming itself. We might not, but it’s hard to say, since if there are any such problems, they have not yet been brought to my attention. Every pattern discovered so far seems to be specific to only a small subset of the world’s languages.

Some awareness of the history of programming languages might produce a slightly greater awareness of the trends Dominus identifies in the history of programming language development. It might help us avoid re-treading the same ground over and over while claiming that we’re exploring new territory. Perhaps we could even focus our attentions on the areas of language development that actually need work?

Another excellent example is this recent article on Internet software patents by Philip Greenspun, who correctly identifies that most modern software “innovation” is rehashing the work of early pioneers. We’re just scaling that work in obvious ways to take advantage of increased system capacity, or making half-cooked implementations of ideas that these pioneers devised in a much more robust form but were unable to follow through with.

Looking back on my computer science degrees, I’m honestly confused about why there wasn’t more history taught. We got a lot of algorithms, mathematics, and mainstream languages (C, C++, Java) thrown at us, but very little history of or context for the things we were learning. Except for Dr. Grundke’s second-year assembly language course and Dr. Cox’s third-year programming languages course, it wasn’t until fourth year courses or graduate work that historical matters were mentioned at all. And even then, no consideration was given to the implications of the history or its influence. It was written off as obsolete, interesting but largely irrelevant. Even in graduate courses, my experience shows a near-exclusive focus on recent history.

Yet Engelbart’s NLS did things that modern computer systems still can’t manage. Modern programming language and environment development seems to put a lot of sweat into developing poor copies of Smalltalk and LISP. Years of time are put into recreating things that our Internet protocols can already do, because the existing programs that implement these protocols don’t. I’m not saying these older solutions didn’t have their flaws, or that there haven’t been original new developments. But the history of these older technologies at least merits study, so we can focus on improving the things they did wrong and take advantage of the things they did right. Unfortunately, many of the students graduating from computer science programs (possibly the vast majority, including many graduate students!) are as completely unaware of this rich history as they are of modern developments.

This is particularly strange to me, because one of the big motivators for my interest in computers was Steven Levy’s Hackers. Levy’s examination of the early days of the computer movement was inspiring and educational. While non-technical, it provided some good examples of what does work (openness) and what doesn’t work (secrecy), which almost certainly shaped my interest in the Free Software movement. Towards the end of the book, he also inadvertently demonstrates the importance of historical awareness by following people who were sure that history was irrelevant. This lack of awareness doomed them to repeat their predecessors’ mistakes, eventually leading to the collapse of their movements, companies, and technology.

I also have to wonder how much influence the proprietary software movement’s had on this mentality. When your ideal model of software development is behind closed doors, you have to pretend that there’s no need for awareness of other technologies, much less awareness of how they work. If you recognize that reading, working with, and building on notable programs and technology written by others  is valuable, the claim that software innovation requires absolute secrecy starts to look a little shaky.

TLDR: what I want to see is a required course – possibly even a full-year course! – on the history of computing. A proper history course, one that critically examines the causes and effects of events, their influence, and forces the students to become aware of these historical pioneers and the technology they developed. Teach them what it did and what it didn’t do. Heck, if it’s feasible, make them use it a little.

The problem appears to be that the power harness used in the Digi 002 is defective. (References: here and here). DigiDesigns will replace the harness for free, but the user has to install it themselves. This isn’t particularly tricky, since they send you complete and easy-to-follow instructions. The tricky part is working out what’s wrong, since there’s no sensible error messages from their software and no clear indication of a hardware error. Even worse, the hardware error is often intermittent, seeming to go away for long periods before returning.

Hardware Symptoms:

• When the IEEE1394 interface cable is connected, the green link light (on the back of the case, right between the IEEE1394 ports) briefly turns on then immediately turns off again.
• The Mute light on the front of the case remains lit. No other lights are on. The device is unresponsive.
• When attempting to establish a connection, the link light blinks on, a click is heard, then the light immediately turns off again. This repeats several times.

Software Symptoms:

• When starting ProTools LE, the following error message is seen: “Unable to locate Digidesign hardware. Make sure your hardware is connected and turned on. Click “Ok” when the hardware is ready.”

Getting a Replacement Part:

The replacement part is user-serviceable. Call the technical support line (free if you’re under warranty, $3/minute up to $75 or so if you’re not) and describe the problem to them. They should e-mail you a waiver of liability for the user-installed parts. Once you read and agree to that, they’ll mail you a replacement part and instructions for installing it. The part should arrive inside of a week.

Hopefully, this post will be useful to anyone else who runs into this problem.

Annoyingly, OS X doesn’t let me bind a key to activate the screensaver. There used to be a couple utilities that enabled this, but they haven’t been updated since 10.3. The screensaver engine itself is an application, but we still need a convenient way to activate it. Enter Quicksilver. Quicksilver’s Triggers let us bind Quicksilver actions (including, conveniently, opening Applications) to keypresses.

So, to create a key to activate your screensaver or lock your system with Quicksilver, follow these simple steps:

1. Create a Quicksilver trigger to open the screensaver engine. The engine is /System/Library/Frameworks/ScreenSaver.framework/
Versions/A/Resources/ScreenSaverEngine.app



2. Bring up the Trigger’s info pane.
3. Set a key shortcut for the trigger. The combination of options I’ve got selected mean that the trigger only goes off if I hold the keys down for three seconds, and Quicksilver brings up a display window to let me know that I’m activating a trigger. Very handy! (Due to what I think is a Quicksilver/Leopard bug, the hotkey field is incomplete. Mine’s set to cmd-alt-ctrl-L)



4. Enjoy!