February 2005 Archives

What Would An Agile Operating System Project Look Like?

| No Comments

Question raised via Tim Bray: If you’re building an Operating System, what’s that first feature that you build, test, and deliver?.

Taken on its face, it's a question without a good answer. No customer is going to pay for part of an operating system when they can get a full version of Windows, OS X, Solaris, Linux, BSD or any of dozens of other off-the-shelf systems. One feature of an OS is worthless in today's world.

Really, the same question could be asked for any large, complex piece of software. Until there is a real customer willing to pay money, someone else (for example a product manager) has to take on the XP customer role. (Even after a product has real customers, their conflicting needs have to be reconciled somehow. That's part of the responsibility assigned to the XP customer role.)

So the answer remains, whatever feature the customer decides has the most business value. There's a whole book about what features to implement first to maximize financial returns (not just ROI).

Source Code as Specification

| No Comments

I was looking into WebCT's automatic sign-on feature. To use this, I needed to build a URL like http://server/webct/public/autosignon?IMS%20id=LONGID&Time%20Stamp=1108683051&URL=/somewhere&MAC=LONGSTR and use a HTTP redirect to send the browser in.

WebCT does provide fairly detailed technical documentation of their API, explaining how to calculate the right values for IMS id and MAC. Unfortunately, it left some details out, such as exactly which values are used in calculating the MAC and in what order.

A search turned up Java example code. Never mind that this is from the attic of its CVS repository (meaning that it was deleted from CVS). At one time, it probably worked. Java source code is unambiguous — there is no doubt about how values are calculated. I didn't need to compile this code. I didn't even want to implement my solution in Java. (It's ColdFusion, if you must know.)

By using this code as a crib, I was able to get the right value for IMS id. So far, so good. Unfortunately, I wasn't getting the right value for the MAC.

autosignon is a CGI program. No source code, but it can be run in isolation. I just needed to set up its inputs and watch what it was trying to do.

Hmmm, where to look up how to set up the inputs? I decided to look through CGI.pm. Easy to look for references to $ENV and see what it wants. Sure enough, by setting the same environment variables I could run autosignon from the shell. Looking at the strace output I noticed it was reading from a file I hadn't expected... It was reading its shared secret from autosignon_secret, not api_secret. That made sense, it just wasn't clear from the technical documentation.

In the end, I needed to get some information in the absence of source code. I was lucky that I was able to run autosignon standalone: had it been embedded in something bigger I would have faced much greater difficulty.

In most cases, a specification need not be acccurate to the nth degree. An API with security implications is a different matter. It's true that the technical documentation could have included more detail. However, source code showing how to calculate the MAC (for example) is not only less ambiguous than English (or tables and diagrams), it's also more compact. It's also relatively easy to verify.

One factor I'm leaving out is that vendors have a conflict of interest. They want to encourage people to use their professional services to do integration and customization work. That would be a reason to publish enough documentation to show that something is possible without giving away every detail. I think that this has the side effect, however, of lowering the customer's FYO point for that software.

Phew, I Don't Need to Worry About the SHA-1 Break

| No Comments

News on the breaking of the SHA-1 hash algorithm is all over the place.

Fortunately, as Bruce Schneier notes parenthetically:

it doesn't affect applications such as HMAC where collisions aren't important

As it happens, MAC is the only application I care about.

How CEOs Can Create Shareholder Value

| No Comments

As seen in the news: Carly Fiorina finally creates some shareholder value by resigning. The value of HP went up by about $5 billion as a result.

Reminds me of this, from September 2003: Motorola CEO Resigns; Five Analysts Issue Upgrades (MOT, 12.06, up 0.97).

After Chris Galvin resigned, Motorola finally spun off its semiconductor division, like Wall St had been demanding for years. MOT subsequently rose to over $20 (albeit mostly because of improvements in the cell phone business).

No matter how unpopular CEOs are among the rank and file, when they go it's because Wall Street doesn't like them.

Brian Behlendorf on Successful Open Source Development

| No Comments

Stephen Walli has put up the slides to a talk Once a talk given by Brian Behlendorf on OSS Development.

I would have liked to have been there. Behlendorf is deadly accurate about the problems of typical corporate development:

  • Slow feedback loops from inception to use.
  • High underlying technology churn.
  • Poorly documented prior systems and requirements.
  • The growing difficulty in estimating work.
  • Demotivated developers.

(For that matter, more than a few unsuccessful open source projects have suffered from these problems too.)

Some of the lessons that Behlendorf takes from open source projects are bound to be more controversial. He recommends that a [p]roject should be digital from day one: start with specs, customer requests, any initial artifacts in a single, consistantly viewed space. What's more, discussions and decision-making should be moved online as much as possible.

I think this is all to increase transparency. However, I'm not sure if it's not making a virtue of necessity. Big open source projects have developers scattered across the globe — there is no feasible alternative to electronic communications. In an ideal world, they would be better off if they could talk face to face every day.

Nevertheless, I have to respect what Behlendorf has to say. After all, the everything-digital approach clearly works with Apache.