Deja vu at the NYT

After reading today’s piece by the New York Times public editor (i.e. ombudsman) entitled Weapons of Mass Destruction? Or Mass Distraction?, I was moved to reply to him by email:
Congratulations to both you and the present NYT editorial staff on the courage to confront the isssue of the Times’ coverage of the WMD issue.
And yet, and yet…. As I read your description of the dysfunctional system, the coddling of anonymous sources, and the lack of scrutiny about the motives of sources, I could not help but be reminded of Whitewater et al. From things like Jeff Gerth’s notorious front-page piece of March 8, 1992 on “Clintons Joined S&L Operator…” through the Starr inquiry and the impeachment, there is (now) substantial evidence that uncritical New York Times reporters were manipulated by “sources,” and that exculpatory or debunking material was supressed.
Is it not time for the New York Times to examine its role in this matter in the same spirit of honest self-assessment?
Geoff Arnold

I was actually a bit hasty in sending this off. On re-reading it, I should have added something like this: Even a skeptical reading of accounts such as Joe Conason’s “The Hunting of the President” would suggest that the New York Times failed to meet the standards which you and the present editorial staff now champion. (The fact that other newspapers such as the Boston Globe and the Washington Post behaved even more recklessly should be irrelevant.)

Nobody expects the….

When I started this blog, I thought I was safe going with a budget hosting account that was limited to 300MB/month. So far this month I’ve served up 217MB. Time for an upgrade, I guess….

Tim seems to have passed his OS X infection to me…

No sooner does Tim Bray report that his OS X bitrot has been cured by 10.3.4 than I suddenly find it affecting me. Specifically, iChat refuses to launch; it bounces in a desultory fashion a couple of times and then exits. I’ve deleted all of the obvious prefs files, repaired permissions, run the iChatAV update… nothing. And none of the log files [why does OS X have so many of them?] shows anything untoward….
People may tell me that this is an excellent excuse to start using Adium X, but I’d prefer to make the move voluntarily rather than in desperation.
[Update: Adium is working fine for me, but I wish I knew why iChat is broken.)

Java, open source, standards, and conformance

[Revised 5/30/04]
My colleague Simon Phipps has just posted a lengthy piece entitled On Java and Openness. I agree with him pretty much 100%.
A lot depends on whether you approach compatibility and interoperability from a “standards” position or not. The “standards” viewpoint is that there are going to be multiple implementations, that this is a good thing, and that you need to make sure that these implementations can interoperate. This was always the IETF approach: a proposed standard with only one implementation was viewed as problematic, because you couldn’t distinguish between the intention of the standard and the accidents of implementation.
I started at Sun in 1985, and my first job was to do an implementation of NFS for MS-DOS from spec. All of the previous implementations (for various types of Unix as well as VMS) had been based on the source code, so I guess that I made Rusty Sandberg and the other spec-writers pretty nervous. But it worked. Later I worked with folks from FTP, Microsoft, and JSB to develop the Windows Sockets specification, and we recognized from the start that the conformance verification model was going to be key to acceptance.
I’ve always taken an object-oriented approach to standards: I believe that a standard is an object with one method, bool Conform(implementation i). If an implementation, i, conforms to the standard, I can use it. Of course this presupposes that the standard is adequately specified and the Conform() method is trustworthy, but that’s why doing standards is hard work. It also explains why the Reference Implementation (RI) is such an important concept – that if (or rather when) the language of the standard proves inadequate or ambiguous, there is an authoritative answer: the standard is what the RI does. Critically, the RI is not supposed to be the only implementation; it should be optimized for clarity and conformance rather than performance, size, efficiency, etc.
Everything that I’ve seen about the open source movement suggests that it is designed to encourage group participation on a single code base, rather than the creation of multiple independent implementations. Where’s the 100% compatible clone of Perl, or Apache or Sendmail? In that respect (paradoxically?), open source leads to a monoculture, just as much as Windows does. When you actually have multiple implementations, you have to face the question of whether compatibility is important or not. For platform technologies – systems that other people rely on to make their software work – the answer seems to be yes. And despite the absolutists that Simon cites, there is no evidence whatsoever that a free market approach can sustain compatibility, except by preferring one choice and allowing the others to wither. To me, monoculture – even a free monoculture – seems dangerous. Diversity is good.

Posted in 1K

Back home

I got back home to Boston late last night after an 8 day trip to Silicon Valley. This afternoon we [my wife, daughter, son-in-law and I] headed up to the Museum of Fine Arts, since we had tickets for the Gauguin in Tahiti exhibit. As it turned out, none of us thought much of that show (a little Gauguin goes a long way, and his pedophilia is hard to ignore), but two other exhibits more than made up for it.

First, we saw the Japanese Postcards show. This is simply wonderful – see it if you get the chance. It’s drawn from a collection of thousands of Japanese postcards from the first half of the 20th century: New Year’s cards, art cards, humorous cards, cards celebrating the Russian-Japanese war, advertisements, Art Nouveau, Art Deco… just delightful. The one on the right is by Kobayashi Kaichi, entitled Woman Waiting for her Beloved at 2:25. We bought the book for the exhibition, and one of the staff confided that the Japanese Postcards book had been outselling the Gauguin in Tahiti catalogue by a significant margin.
The other delightful surprise was the exhibition by the English couple Tim Noble and Sue Webster. To quote the MFA: The artists integrate satire and punk strategies with the study of modern sculpture and a keen awareness of the self-importance of the London art scene. Responding to the media hype of the British art world, Noble and Webster find inspiration in pop culture and advertising, creating brilliant animated light displays, or illuminations, such as the fountain and dollar sign in this exhibition. By contrast, their �rubbish,� or shadow sculptures, are brought to life when a simple light is projected over a carefully arranged pile of domestic garbage. Tim Noble & Sue Webster explores the team�s mature work, including seven examples of illuminations, shadow sculptures, and their latest neon forms: a boy/girl couple covered with streetwise slang. The piece to the left is Excessive Sensual Indulgence. Exhilarating, and very, very English.
My favourite pieces were “Real Life is Rubbish” and “Fucking Beautiful”, shown below:

Posted in Art

Tribal eyes? Interesting…

Tim Bray mentions in his blog that he attended a meeting of Sun’s Distinguished Engineers this week. As the organizer of that meeting, I was interested in his observations. One of the not-so-subtle reasons that I asked Tim to present was that I’d really like more of the DEs to start blogging: I think that they have a lot of interesting stuff to say. Only a few of us do right now – James, Eduardo, Jim, Dick, myself….
As Tim noted, getting to be a DE involves peer review, and many people assume that this means we’re really some kind of clique or a club. Nothing could be further from the truth. Technically we’re all over the map, from sub-atomic physics to petascale supercomputers, from the mathematics of component failure to the poetry of programming. Some of us have a broad technological or business perspective, others are wholly focussed on our particular area of specialization. Some are interested in talking about process, organizations, and leadership; others want to stick to “hard” engineering. And some are unfailingly courteous, while others are (let’s face it) arrogant SOBs. The two things that unite us are a passion for engineering, and a passion for Sun. It’s an amazing place to be (I joined in 1985) and it’s a privilege to work with such a team – DEs and everyone else.
As you might imagine, putting together a conference program for that crowd is something of a challenge. But we still had a good time, and got a lot done.

Posted in Sun

Ten mistakes on Iraq

There’s a transcript here of a speech by Gen. Anthony Zinni, USMC (Ret.), former commander of CENTCOM at the CDI Board of Directors Dinner on May 12, 2004. The whole thing is worth reading, including the Q&A that followed the talk. Here I’ll simply summarize the ten mistakes that he identified.
The first mistake that will be recorded in history [was] the belief that containment as a policy doesn’t work.
The second mistake … is that the strategy was flawed. […] the road to Baghdad led through Jerusalem. You solve the Middle East peace process, you’d be surprised what kinds of others things will work out.
The third mistake, I think was one we repeated from Vietnam, we had to create a false rationale for going in to get public support.
We failed in number four, to internationalize the effort.
I think the fifth mistake was that we underestimated the task.
The sixth mistake, and maybe the biggest one, was propping up and trusting the exiles
The seventh problem has been the lack of planning.
The eighth problem was the insufficiency of military forces on the ground.
The ninth problem has been the ad hoc organization we threw in there.
And that ad hoc organization has failed, leading to the tenth mistake, and that’s a series of bad decisions on the ground.

Simple, isn't it?

My last few posts have mentioned the importance of simplicity, so having praised IBM I now feel free to tease them.
A few years ago I went to a conference in Sydney, Australia, and I sat in on a session given by a (US-based) IBM marketeer. He was trying to sell the ease of deployment of some middleware product from IBM, and he kept on stressing the importance of “simplistic solutions” and “simplistic user interfaces”. Never “simple”, always “simplistic”. Most people were polite (and some, I’m sure, never recognized the verbal gaffe), but a few of us had red faces and watering eyes as we tried to avoid the hysterical laughter that threatened to overwhelm us….
Afterwards an Australian colleague asked me if “simplistic” had a different meaning in the US. I often wondered if anyone told the unfortunate speaker of his mistake.

Book recommendation: Autonomic Computing

I’ve just posted a review on of Autonomic Computing by Richard Murch. Yes, I know it’s an IBM Press publication, so dial up your “self-serving bullshit” filters – but not too high. Overall this is a really useful book. While it’s targeted at CIOs and their staffs (folks who have read, and bought into, the Autonomic Computing Manifesto), it’s not afraid to dive the details and point at source code to back up the architectural diagrams. It discusses what’s going on in the research community and what competitors (including Sun) are up to. And I like the way the author models “customer maturity”; the readiness and ability of customers to take up some of the things described in the book. I disagree with some of his numbers, but without this kind of model the temptation to believe one’s own propaganda is irresistible.
There are a few goofs (mobile agents? please, no), as well as some yawning gaps (systems modelling and policy languages). And while it’s reasonable to skip the IBM-heavy business stuff at the front on a first reading, don’t put the book away without going back to it. In particular, don’t skip chapter 2, on the costs of complexity. As I noted in an earlier blog entry, simplicity and staying on topic is key.