Collapse

What happened to New Orleans is terrible. But as James Robertson points out, it was not unanticipated.

The situation reminds me of our increasing understanding of earthquakes where I live in the Pacific Northwest. A similar hell could break out at any time here.

Jared Diamond's book "Collapse" addresses this recurring theme. A societal collapse is often triggered by an environmental collapse. These days the signs of a coming disaster are well known if not widely acknowledged, let alone acted upon effectively.

What Google Gets

Steve Gillmor has a great characterization of where Google could be going. Rather than trying to build the platform for everybody, Google seems to want everybody to build the platform for them or rather, with them. Google could be engineering something at the scale of the Internet, not just producing a suite of somewhat related products. If others continue to join in, the competition could be dizzying. Steve called it "iterative competitive development", "overlapping interoperability" rather than "lock-in" or "lock-out".

Anyone not taking this kind of approach probably is locking themselves out.

Threading Eras

James Robertson points out the difference between "native" OS threads and threads implemented in the language runtime. Some people (as quoted) see mapping language-level threads to OS threads as a good thing.

In part this may come from Java's first implementation of threads (aka "green" threads, a term Jim also applies to VW Smalltalk's threads). These had their share of implementation problems early on and so before long the Java community seemed to gravitate toward an anti-green-thread attitude at the conceptual level. Only now for example is BEA's JRocket JVM *experimenting* with a high-performance non-native thread implementation they call "thin threads" (wisely avoiding the "green" label).

As VW Smalltalk, Gambit and PLT Scheme, Erlang, and the Oz language demonstrate, highly concurrent programming requires much lighter-weight mechanisms than OS threads. (For the typical OS.)

Apparently most Common Lisp systems have heavy thread implementations and so the ErLisp implementation may not scale up as well as these other systems either.

A File System For (or To) the Rest of Us

Update 2: comments on WinFS capabilities...

Across the network you could still use it as a WinFS if you have WinFS installed. If you don't, it's just a file system, so you're not locked to it. It might be better just to use a common, standard, protocol; the idea that it's appropriate to degenerate to file system behavior is just retro

Update 1: Michael Lucas-Smith has another useful take on WinFS. I am not as thrilled by the synchronizing capabilities in these local pseudo-databases as he seems to be. I have a different interpretation of the Network being the Computer. Michael suggests a Topic Maps-like capability on top of databases or files or whatever might be more useful than WinFS. I agree with this, and I agree having to rewrite apps is a problem. Those seem like two different issues though that each need to be addressed.

I do agree with one vision of WinFS... I think we need easier structuring as well as semi-structuring mechanisms. A relational database is a structuring mechanism. A topic map is a "semi-structuring" mechanism. Big old-fashioned databases are good at structuring, it's just they suck at ease of use and ease of operations.

Michael points out some capabilities of SQL Server (and Oracle). For example they *can* act as file systems. But who uses them as file systems? Which goes more to the point: These more mature databases are too cumbersome. However file systems are too limited. WinFS is trying to hit somewhere in between. I think they are aiming at the wrong target.

Hopefully Microsoft is heading toward better support for unstructured data. But if WinFS is the best they can do for *structured* data... they should try again. A "local" filesystem/database with some proprietary synchronization capabilities is just not what I think we need. If we're going to rewrite systems for the formal aspects of structuring data then we can do better than a system which appears to be something less than a Lotus Notes database at best.

The bottom line for me is: whatever WinFS *is*, well, it should be *that* for the network. WinFS should not be something for me if it happens to be running on my specific box, something else for you if it happens to be running on some other specific box.

End Update 1

A telling quote in the Channel 9 piece on WinFS...

"WinFS -- to the rest of the world it's important that it looks like a file system"

A better philosophy would be this:

To the rest of the world it is important that it looks like WinFS.

But apparently the WinFS team has not entered the age of the network is the computer. I think that is what is important to "the rest of the world." Why degrade capabilities over the network?

The WinFS team continues to be stuck in outdated thinking.

Piracy

A graph showing the inverse relationship between global temperature and pirates. Actually I think there may be as many pirates as ever. So this *could* very well turn out to be bad science.

Trusted Computing and Digital Rights Management

Someone once said, "Follow the money." The aphorism is broadly applicable.

Note that the opinions expressed here are my own. In the interest of full disclosure, I currently am paid by Intel Corporation to do something akin to real work and I own Intel stock, but my work for them has nothing to do with Trusted Computing, nor do I have any privileged insights into that technology.

So here's my thought: I find irony that the Internet continues to be victimized through its own orifices, especially those on the common endpoints, while an appropriate solution, Trusted Computing, is getting a bad rap because some media companies want to use it to prop up their derelict business model (see Digital Rights Management (DRM)).

The digital rights problem seems to me to be a social problem in the market, not a technology problem. I think by associating Trusted Computing too closely with DRM. Tim Bray writes...

OK, if there’s ever a place where DRM is appropriate, it had better be open and non-monopolistic and all that.

And this is exactly right... the technology can be used broadly to support capability-based security down to the hardware. All software can be made more secure if this problem can be addressed effectively. The media companies are just a mountain in the road toward safer computing generally. We need market solutions to solve that problem, but the technology should be considered as a potential solution to the fact that insecure office and back office software are still exposing our orifices on the net to whomever wishes to pay an unwanted visit.

Trusted computing *and* greasemonkey might make a terrific combination. (With a fair bit of reengingeering unfortunately.)

Cairo looks cool

A little reminder to myself to try cairo (lower case) 1.0, cross-platform structured 2d graphics.