So I got my Karma replaced. They were actually stunningly efficient; I called, got an RMA number, sent it to them and had a new one, all in under a week.
Now, naturally, I want to put some songs on it. Previously I'd used the Java app it comes with to do this from OS X, and that worked fine, except that it's slow. On an 11mbps wireless link, it takes about a minute per ~5MB song. It should take at most 6 or 7 seconds; 802.11b (with good signal strength) is faster than 1MB per second (which is still faster than USB 1.1, which is my other alternative).
The funny thing is, I used the Java app on a friend's Windows machine at Christmas, and it was nice and snappy, so I guess Mac OS X's Java VM has super crappy networking or something. So I figure hey, this is Java, right? I'll just run it in Linux; maybe the VM there has better networking. You can actually get a Java VM for Linux/PPC from IBM.. except that when you try to run the Karma transfer program it dumps core. Great. Write once, run anywhere my ass.
So then I see libkarma. Looks promising.. except that it's horribly written, segfaults all over the place and does fun stuff like returning pointers to buffers on the stack. So then I just cut my losses and write a simple app using WvStreams to copy files to the Karma, and guess what? It doesn't take a minute per song!
I don't know why people haven't done more with the Karma. It's got networking for crying out loud! And the protocol is documented! You can definitely do some cool stuff with that, so it's surprising nobody has, especially since people have written gnome-vfs backends and KIOSlaves for the Rio 500. Anyway, my plan is to write a fuse filesystem for it so I can just mount the sucker.
Moral of the story: don't buy a Karma unless you really like tinkering.
Work
Was super busy for a while, but a bit less so now. It looks like I'm going to have to write a bunch of Java code soon-ish, which will be, uh, interesting, since I've not written any Java code in years.
In an effort to re-familiarise myself with Java today, I've been looking at the new generics implementation in Java 5 (apparently that's the correct thing to call it; will Sun ever stop having rediculously stupid version numbers?)
It turns out that to support backwards compatibility, they've used erasure to implement generics in Java. So you can do this:
public String joinStrings(Vector<String> listOfStrings, String delim);
And then if you pass it just a Vector, or a Vector<Integer>, you'll get an error (which is what you want).
But then you can also do this:
public String joinStrings(Vector listOfStrings, String delim);
And pass in Vector<Integer> if you like. I can see that if you want old class files and old code to work on the new VM and with the new compiler, you need this kind of thing, but it makes generics considerably less useful.
Another nice tidbit is that you can never do new T(); inside a generic class, because the type information is gone, so the compiler doesn't know if the type replacing T provides a no-parameter constructor. So what you see is that in the actual JDK, the code written by engineers at Sun, they're doing nasty things like T[] foo = (T[])new Object[size];
The other way around this is to pass in a Class object of the appropriate type:
public class Generic<T>
{
Class<T> tClass;
public Generic(Class<T> tClass)
{
this.tClass = tClass;
}
public void Foo()
{
T myT = tClass.newInstance();
// ... do stuff with myT
}
}
Yeesh. It seems like there are a lot of these kinds of things in Java; things you want that are there, but only in a half-baked, semi-useful way.
Notice that I dissed Java without even touching on the GC or VM. Those are old, old debates and everybody has opinions on them, so whatever.. apparently that stuff is better these days, but I have no idea.