Congratulations to Tim on his new position at Sun.

In an interview he gave about the move, he said something interesting that I’d like to comment on. When asked whether he’d looked into peer-to-peer technologies, he said;

Only trivially. That has some roots of its thinking in the old Linda [parallel programming coordination language] technology that [David] Gelertner did years and years ago, which I thought was wonderful and which I was astounded never changed the world. But I have been working so hard on search and user interface and things like that for the last couple of years that I haven’t had time to go deep on JXTA.

Linda – or something very Linda-like – did change the world; the World Wide Web.

I’d really love to get Tim’s views on Web services. He’s said a handful of things on REST/SOAP, etc.. , almost all of which suggest that he totally gets the value of the Web (unsurprisingly). But he’s also said some things which have me wondering whether he appreciates the extent of the mistakes being made with Web services.

BTW, I wonder what’s going to happen on the TAG now that both Tim and Norm are at Sun, given that the W3C process document doesn’t allow two members from the same company? Either way, it will be a big loss to the TAG. Bumber.

Update; Tim resigns

Jim writes, regarding a diagram by Savas;

It shows that managing virtualised resources across organisations isn’t scalable, whereas composition of services is. Why the difference in terms of scalability? In the service-oriented view, services can manage whatever backend resources they have for themselves, therefore the complexity of the application driving the services increases linearly with the number of services. In the resource-oriented view, the consuming application must deal with each resource directly and so complexity increases as the sum of a multiple (the number of resources) of each service.

Aside; I think Jim’s using the WS-RF notion of “resource”, which is cool, since it jives so closely with the Web’s notion of one (stateful resource, stateless interaction).

I think the scalability claim above is only correct if you ignore a whole class of useful resources; containers which contain other resources. So I could layout a resource centric view of the network in that diagram to look exactly like the service centric view Savas draws. For example, I might define a container called “the aggregate log ‘file’ of all devices in this building”, and this might be dynamically constructed in basically the same way that aggregate RSS feeds are constructed. And, of course, it would be given a http URI so that I could snarf data from it. Each log entry could also provide the URI of the more granular “device” that it came from so that I, or an automata, could visit there to find its current status.

Ah, that’s better.

My poor little P133 Redhat 6.2 box gave up the ghost on Friday, after about 9 years of faithful service. It had been tempermental for a couple of years, but not so much so that I had to consider replacing it. Its original replacement as my desktop machine a few years ago – a smokin’ 128 (count ’em!) megabyte PII-400 – once again performs replacement duties.

I also took the opportunity to switch distributions. I started out with Yggdrasil back in 1994 (IIRC), switched to Redhat in ’97, and now have gone with Debian after a lot of other developer types recommended it.

Except for some really odd behaviour with a bad bash, and some corrupted binaries (a bad /bin/mount makes rebooting kinda hard) which required a re-install, it’s looking nice. apt is sweet, and it makes me wonder why I ever felt the need to fork over money for rhn.