December 2006 Archives

Found this on Simon's blog : http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt

Favorite part :

Executive Executive Summary
---------------------------
The Vista Content Protection specification could very well constitute the
longest suicide note in history.

Read it and pass it on...

I think that YouOS runs YouNicks on their backend servers...

(I have to admit I was a little disappointed that I couldn't run the YouOS demo in "WereWolf", the web browser for the YouOS desktop in the YouOS demo...)

I know I'll sound like a luddite, but I was late getting a TiVo (2004) and it wasn't until today that I had any real interest in getting content off of it. When TiVo announced TivoToGo, I took a look, but with no OS X support, I didn't really care. When I travel, I spend most of my time working, so having TV shows with me wasn't so interesting.

For whatever reason, I changed my mind - maybe it was getting the Big Thick Disk for the TiVo. Doesn't matter. There are cool tools out there that I'm playing with now :

• tivodecode - takes a TiVo formatted file and converts to MPEG-2 (I think)
• Galleon - Home media server that works with TiVo, I'm using it to fetch content from the TiVo (better than using a web browser...)
• TiVo Decode Manager really slick front end for tivodecode - lets you fetch and convert. Problem is that for some reason, it has trouble downloading, and simply quits. Maybe I can help fix it.
• VideoLan - viewer for the MPEG-2's created by tivoconvert. For some reason, QuickTime can't grok them.

It's really not clear to me what I'm going to do with this (again, I really don't have time to watch TV...) but we'll see. Right now it's fun to fool around, something the Christmas break is good for...)

Hasn't this joker heard of drag and drop? If you want to move a folder, you need to select it, then hit the "Move..." button, and then select the target folder in a dialog box, and then hit "OK". Its like something out of Lotus Notes...

Update : Oh, I see - you can drag around in the right pane, but not the left. I wonder why?

Right now, I'm setting an undocumented property :

prop.setProperty("mail.pop3.socketFactory.class", "javax.net.ssl.SSLSocketFactory");

and it just feels wrong...

Last friday, I ordered a TiVo upgrade kit from weaKnees and asked for overnight shipping + saturday service - I thought it would be a nice present for the family. I'd get it sometime Saturday, install then or Sunday. They shipped it via UPS, so needless to say, it showed up on Tuesday.

So after it arrived, I pinged weaKnees via email. An hour later, they'd refunded the full shipping charges. No argument, no attempt to compromise on a ground rate - just a refund. Needless to say, I'll buy from them again.

I just saw this post by Tim Bray on email clients on OS X. I thought the timing interesting because I've just switched back to Mail.app from Thunderbird (on OS X). I switched to IMAP a while ago (and have never looked back), and for some reason thought that TBird was a better IMAP client. But a few days ago, I needed to import an mbox, and I have to admit I just couldn't figure it out in TBird. I started Mail.app, sat back while it synched to the server and did it's digestion (redline that core duo!), imported the mbox. I also read some mail.

Problem was, when I went back to TBird an hour later, I thought the same thing that Tim did - it does feel slower, and wasn't as visually appealing, etc. So I'm back on Mail.app for a while. It doesn't seem to have identities (which I think is a big flaw, but I can work around it), but otherwise I'm happy.

This is a validation of at least one reason why I chose IMAP - freedom from client. When I tried (and failed) to switch from Mac to Windows last year (because I was tired of carrying around multiple laptops...), I realized that Mail.app had it's own mbox format, and I vowed never to be beholden to one mail client again. IMAP lets me do this - I can use the best mail client for the platform, or even switch now and then to keep things fresh. Change is good.

Lately, I've been thinking a lot about the question "Is it Java^TM?", from the perspective of open source and free software implementations. I'm quite smitten with Apache Harmony (obviously), and there are lots of other implementations of piece-parts (GNU Classpath, Kaffe, GCJ, etc) as well as the 800-lb gorilla that has just started to show up, Sun's OpenJDK project.

So we have lots of code out that that claim to be implementations of the Java SE specification, but what actually makes those implementations "Java^TM", or as a Sun branding pedant would have it, "Java^TM compatible"? I'm actually a True Believer in the compatibility promise of Java - I think that it's very important - as a software developer, knowing that my runtime platform is Java (or "Java compatible") means that, in the memorable words of Rob Gingell, "my bytecodes won't be lied to". While this explicitly means that my programs will run as I expect them to, the implicit benefit is that I'm free of vendor lock-in. I can take my program and move it to another Java implementation, on another hardware platform, on another operating system. My choice, my freedom.

Traditionally, the way you know you have Java (or an implementation of one of the many JSRs that augment the base platforms) is if the implementation passes the "TCK" - the Technology Compatibility Kit - a test suite that any implementor can obtain from the spec lead to demonstrate that their implementation is compatible with whatever spec they've implemented. When you pass the TCK, you can claim compatibility with the spec and as a side benefit, you get all the "necessary IP" held by any members of the Expert Group that created the spec, a mechanism that keeps any member of the Expert Group - including the Spec Lead - from acting like a patent troll, being able to commercially control usage of the spec through patents. Java is an "open" ecosystem, right? ;).

So how is this related to the blossoming of open and Free implementations of Java? I was reading this recent blog post by Chris Adamson of OnJava. He asks if the DLJ - the Distribution License for Java - matters anymore, based on the premise that the linux distros will be doing their own packaging :

"Of course, with the GPL release of Java, the need for the DLJ would seemingly go away"

Does it? What exactly is the result when the distros compile and package the OpenJDK source? I'll argue it's by definition not "Java^TM" (or "Java compatible") because it hasn't passed the TCK. I'm sure that it's reasonably good software - after all, it's based on the same source code that Sun ships as tested binaries under their proprietary licenses. If a distro, especially a commercial distro that is feeding commercial enterprises, wants to deliver commercial-grade (whatever that means) infrastructure, I'm betting their customers will demand "Java^TM compatible", not "something based on the code that goes into Sun's implementation of Java".

One of the "success drivers" of open source is the notion of "good enough" - people are very happy to use solutions that are good enough to get the job done. They aren't necessarily the fastest, or the most stable, or full-featured, or pedigreed, but are fast enough, stable enough, functional enough, or "pedigreed enough". So whatever you get when you compile OpenJDK may be "good enough", but it won't be "Java^TM" or "Java^TM compatible". Now, I'll risk being accused of spreading FUD here, but I really wonder - is there an implicit "fork" coming in Java, with users choosing between "Java^TM compatible" runtimes and ubiquitous "Good enough" runtimes? (Maybe that's why I get winks and giggles from my Free Software friends when I ask them questions like this....) Last week, I spent some time traveling around Belgium and the Netherlands. Trains are two-class - first class means you probably get a seat, second class is good enough, but both tend to get the job done. (To really screw up this metaphor, I suppose I can conflate .NET/Mono and Amtrak as examples of the bad things that happen when you have a single supplier...)

I'm really not interested in seeing this. I've spent a lot of time in the last few years helping create compatible implementations of Java specifications in open source, including helping drive awareness of the value and utility in the Java compatibility promise. I'm hoping I'm wrong here - that this is a hypothetical, and that a solution will emerge where the Linux distros are shipping tested binaries. If I put on my tinfoil hat, I can see that this fits with my Walled Garden Theory about Sun's open source Java strategy, but the long term consequences are so disastrous, I can't believe it (even with the tinfoil hat...). Two obvious solutions - 1) OpenJDK releases binaries under the GPL, so that the distros that are happy re-packaging binaries from others can do so, and 2) those that need to build from source simply get the TCK from Sun and test what they ship. I suspect that the latter will be the way it will have to happen, given the need for the distros to build from source (and it will be fun to watch), but it leads to the outcome best for the ecosystem - preservation of the Java compatibility promise, and the long-term health of the platform.

Yay! (JavaSE5)++ It's also fast - "out of the box" anyway. I wish he mentioned the SPECjbb2005 value for Sun's Java SE 6 OOB so we could compare to other results that have been posted on the SPEC site.

Isn't having competition in the Java SE platform space (Sun, IBM, BEA, Apache Harmony, Kaffe...) grand!

Update - 2006-12-22 : David updated his weblog with actual numbers (probably required by SPEC). First thing to note - Sun needs to stop shipping AMD and start shipping Intel because, um, that Dell 2950 is simply hammering the tar out of the Sun Fire X4200 (FD - I work for Intel). Second, these are good numbers but if you go look at the latest posted SPEC JBB2005 results, nothing beats a good set of configuration parameters for your VM if you are interested in performance. Which makes me wonder - will we ever be able to get our VMs to self-tune optimally for the workload? I bet we will...

I found the following link on Simon's Blog, and think that the way CBR presented the material is extremely misleading.

The article in question talks about a response from Steve Harris of Oracle regarding Sun's OpenJDK project, and also references an earlier response by Rod Smith of IBM. In summary, they thought that contributing the code to an existing open source Java community under a different license would have been better than forming a new community. (I also think it would have been tremendously constructive for Sun to offer the code under a permissive license like the Apache License to the Apache Harmony project, but I also understand Sun's desire to retain full control.)

What bothered me is the position of the following quote from my friend Simon Phipps from earlier in the month (IOW, it doesn't appear that the quote was in response to either Steve or Rod) :

Speaking to Computer Business Review earlier this month Sun's chief open source officer, Simon Phipps, explained that using the GPL would overcome fears about license compatibility with Linux. "We've been working on the Java platform for a considerable time and we've got to the point where we're considering 'how do we grow the market'," he said. "The most important thing is that that the Java platform is not included in many GNU Linux distributions." Choosing the GPL, which is already used for Linux, avoids that issue, he explained. "Java now becomes the development platform of choice for enterprise GNU Linux users."

My complaint is that as presented, it makes it appear to the reader that Simon is saying there's a problem regarding license compatibility between the Apache License and Linux. He isn't (I checked) and there is none. Ever see a Linux distribution without the Apache HTTPD Web Server? It's under the Apache License, and runs 70% of the website in the world. (Answer : no). Money quote on this - when we first started Apache Harmony, one of the GNU Classpath people told me - "That's why we like the GNU Classpath exception to our license - we want to use Apache Tomcat". The problem was that Sun's licensing was neither open source or compatible with re-distribution requirements of the Linux community. They solved nicely - this should result in quick uptake of complete Java in Linux (the Novell - Microsoft pact will help too) - but lets be clear... there's no problem running Apache Licensed programs on Linux.

Congratulations to my friend Bruno Souza, who has re-joined Sun Microsystems, working on NetBeans. Maybe he can help me get C/C++ support for OS X. It works on Eclipse ;)

I have to admit I don't quite follow the logic Terrance uses here.

"Sun has every interest in encouraging innovation in the Java ME application space. The reason we have chosen not to add the classpath exception to Java ME is simply because Java ME applications are typically not shipped in a bundle together with the platform implementation and therefore an explicit classpath exception is not needed."

So... why not add the Classpath exception and prove your theory? As you are interested in encouraging innovation, you can't lose! If it's not needed, then no one will use it. If someone does take advantage of it, it's by definition an innovation.

As Bill Joy likes to say "the smartest people don't always work for you", and "innovation happens elsewhere". Let go. Let it happen.

Heh. Thanks Cam

(And these are not only some of the nicest people I know, but also some of the smartest - "wicked smaaht", actually, being in the Boston area - so if you have problems dealing with large amounts of transactional data in a cluster or grid, give them a call. They will fix it, and you will be happy.)