Category: Computing

Rob Gingell once observed that “those who do not use Jini are doomed to reinvent it.” Today Warren brings us up to date on the way this reinvention is happening in the WS-splat world:

How deliciously ironic that the WS architects are (badly) re-inventing executable bytecode (BPEL), types (XSD) and interface centric service development (SCA).

I’ll reserve judgment on his “(badly)” evaluation, and simply note that I can remember a conversation with one of the people involved in SCA in which we were lamenting the fact that software engineers are notoriously ignorant about the history of their discipline….

O’Reilly blows its credibility. What a shame. From the O’Reilly Radar, “To protect the brand we’ve established with our two Web 2.0 Conferences, we’re taking steps to register “Web 2.0″ as our service mark, for conferences.” And the blogosphere explodes with a mixture of rage and hilarity….
UPDATE: Illiad nails it beautifully over at User Friendly.

Part of the recent re-org at Sun was a new role for Greg – or rather, a de jure codification of what should have been the de facto all along. As Jonathan blogged:

Now as you may have heard, I gave Greg a new title recently. In addition to being Sun’s CTO, he’s now Executive Vice President of Research and Development. Why’s that important?
[…]
So as a part of this change, the product group CTO’s, the sentinels supporting the line executives who run our businesses, will also report to Greg. In the world of human resources, that’s known as a “dual hard line” reporting structure.

So what exactly do these “sentinels” do? Or, perhaps more important, what should they do? Here’s what I wrote to a colleague a few months ago:

Back in the mid-90s, Hal Jespersen and I were co-CTOs in the Network Software Group under Terry Keeley and then John McFarlane. We found that the job involved both inward and outward facing activities, as you’d imagine. The outward included:

• Customer facing work, both tactical and strategic. Familiar stuff.
• Other business-related stuff: analysts meetings, press, etc.
• M&A [merger & acquisition] up to the point of acquisition (due diligence, selection, etc.).
• Strategic partnering (remember the various strategic alignments attempted with XXX,YYY etc.?).

These are fairly straightforward. They are business-critical, usually interrupt-driven, with no obvious tempo. By contrast, there are a number of inward facing activities for which it is important to develop a predictable process, a cadence:

• Portfolio planning and MRP [Medium Range Planning – Sun’s budget process].
• Technical reviews of projects – regular, in person, with [at least] the tech leads, every 3-6 months.
• Business reviews of programs, supplying an independent voice on the state of the technology.
• M&A from the date of acquisition until effective assimilation
• Setting technical “big rules” if absolutely necessary
• Taking care of the engineering community, from a retention, skills inventory, and development perspective
• Coordination with CTOs in other business units

(In addition, the CTO *may* be responsible for AD [Advanced Development] within the BU [Business Unit], in order to shield the budget for this from being traded off at the project level. Where AD belongs – within each program, at BU CTO level, or in the Labs – is something that needs to be worked out carefully.)
All of these roles are vital, of course. 🙂 The one that should not be skimped on is the regular technical project reviews. VPs and directors in charge of programs will routinely fudge (lie about) the technical state of their projects; that’s just the way things are, no big deal. The CTO has to understand the technical status of the programs, has to be in a position to identify gaps, overlaps, and duplications across the portfolio.

Obviously one person can’t do all of this: you need a strong, outgoing leader with a small staff of experienced engineers and process people. (The “co-CTO” approach that Hal and I used in NSG was a good “in the small” example of this.) Above all, you need someone who is respected and trusted by the BU EVP but relatively independent of him or her. That’s the value of the dual reporting relationship that Jonathan described.
Of course this only works if all of the BUs have CTOs….

From Reuters:

Computer maker Silicon Graphics Inc filed for Chapter 11 bankruptcy protection after a round of restructuring measures failed, according to court papers filed on Monday.

Of course this comes as no surprise; indeed, my initial reaction was, “FINALLY!! And about time too!” But the stated reason is odd. Among the possible interpretations:

• Restructuring measures were implemented, but failed to yield the intended results.
• Restructuring measures were proposed, but failed to win the support of, e.g., the existing creditors.
• Restructuring was started, but could not be completed – “we tried to lay off the marketing department, but they wouldn’t leave”.

Ah, well. A salutary lesson for those who believe that “if you build it, they will come” despite all evidence to the contrary. And as for Itanium… well, at least Intel won’t have to worry about the special version of Montecito to work with SGI’s NUMA.
(And yes, I realize that “Chapter 11” is not the same as “defunct”. But in this case….)

Check out this essay by Paul Graham. Sample:

It’s pretty easy to say what kinds of problems are not interesting: those where instead of solving a few big, clear, problems, you have to solve a lot of nasty little ones. One of the worst kinds of projects is writing an interface to a piece of software that’s full of bugs. Another is when you have to customize something for an individual client’s complex and ill-defined needs. To hackers these kinds of projects are the death of a thousand cuts.
The distinguishing feature of nasty little problems is that you don’t learn anything from them. Writing a compiler is interesting because it teaches you what a compiler is. But writing an interface to a buggy piece of software doesn’t teach you anything, because the bugs are random. So it’s not just fastidiousness that makes good hackers avoid nasty little problems. It’s more a question of self-preservation. Working on nasty little problems makes you stupid. Good hackers avoid it for the same reason models avoid cheeseburgers.

This is strangely reminiscent of the arguments about Microsoft’s EULA, isn’t it?

Britain threatened the United States yesterday that it will cancel its £12 billion order for the new Joint Strike Fighter unless America agrees to give the Armed Forces full access to the warplane’s critical computer codes.
[…]
Without full access to computer software, the next-generation aircraft would effectively remain under the control of the Americans and could be “switched off” without warning.

One nice thing about AppleCare is that you can track the the whole process on the web. My PowerBook with the broken latch was shipped to Texas (why Texas?) on Thursday night, repaired late Friday evening, and shipped back to Chestnut Hill, MA on Saturday. As soon as DHL reported that it had been delivered, I headed over to the Apple store to pick it up. “Did we call you?” the “Genius” asked? “No, DHL IM’d me,” I replied, confusing him mightily.
From the paperwork, it seems that Apple replaced the latch, the bottom casing, and the speakers. And from running last I could see that the technician booted it up at around 11pm on Friday night, logged in to the test account that I’d created, and logged out 3 minutes later.

This lunchtime I visited the Computer History Museum in Mountain View. It’s the first time I’ve visited it since it opened here. The Computer Museum started out in “The Mill” at Digital, then moved to Museum Wharf in Boston, next to the Children’s Museum. Eventually it was absorbed by the Museum of Science in Boston, and most of the significant artifacts were transferred to the Computer History Museum. However I still think of it all as “Computer Museum 1.0” and “Computer Museum 2.0”, and I’m sure I’m not alone.
I’ve posted a set of pictures that I took, mostly of stuff that has some relevance to my 38-odd years in the business.

Kate just drew my attention to a wonderful rant over at Joel on Software

When I started interviewing programmers in 1991, I would generally let them use any language they wanted to solve the coding problems I gave them. 99% of the time, they chose C.

And the problem with this is…?

[W]hat I’d like to claim is that Java is not, generally, a hard enough programming language that it can be used to discriminate between great programmers and mediocre programmers. It may be a fine language to work in, but that’s not today’s topic.

Essential reading, complete with Monty Python references and a picture of a card punch.

As I mentioned, I wanted to check out ZFS now that it’s finally available in the latest Solaris build. My plan was simple: to upgrade my Ferrari to Nevada B27 and then “blow away the Ubuntu partition and create a couple of 10GB partitions” to test ZFS. Well, it wasn’t quite that simple.

On Monday I borrowed a B27 DVD from a colleague and upgraded my Solaris partition. This went just fine, although I did run into a fiddly little xscreensaver bug that meant I had to snarf the B28a version of the Xorg bits. Never mind: I was now ready to repurpose that 20GB Ubuntu partition. But how? Solaris format/fdisk wouldn’t touch it. I booted up a Ubuntu LiveCD and used Linux fdisk: this let me change the type code to 0xbf, which is Solaris2, but Solaris still wouldn’t see it.

It turns out that Solaris only recognizes one primary Solaris partition on a drive; you can’t have more. So on Tuesday I rebooted the Ubuntu LiveCD and used fdisk to delete both the Solaris and Linux partitions (leaving WinXP untouched). I then created a new partition, and reinstalled Solaris from scratch; I sliced up the partition as 20GB root, 1GB swap, two 10GB slices for ZFS, and the rest in /export/home. Of course I now had to customize the system the way I like it, so I downloaded a ton of stuff, went home, and got things working during the commercial breaks while watching House.

Finally this morning I was ready to test ZFS:

zpool create -f test c1d0s5 [the -f flag because the Solaris installation had put a UFS filesystem on the slice]
zfs create test/tfs
cd /test/tfs

and start playing….

Verdict: if you want to experiment with ZFS, it’s a lot easier on a desktop machine where you can simply plug in another disk. You can use a laptop, but the chances that your disk layout will be appropriate are pretty slim; you should be prepared to repartition your disk and reinstall. Once you do, it all just works – kudos to Jeff and the team.

OK, next step is to try mirroring:

zpool create mtest mirror c1d0s5 c1d0s6
zfs create mtest/tfs
cd /mtest/tfs