Ubuntu 9.10 (Karmic Koala) is out, so I decided to upgrade. The upgrade process itself went fine, but it seems there were some other changes to the system, which affected me.
I'm running on a MacBook Pro Santa Rosa with 4 GB mem, which means that if I use the standard 32 bit kernel, I cannot use all of the memory. That's not really a problem, I just recompile the kernel to support PAE.
However, I also use XMonad (because it's the best window manager available), and previously I launched it from ~/.xsession. However, the new version of GDM doesn't support that anymore, so now you have to drop a file in /usr/share/xsessions/xmonad.desktop - mine contains this:
CODE:
-
[Desktop Entry]
-
Encoding=UTF-8
-
Name=xmonad
-
Comment=xmonad
-
Exec=/pack/haskell/bin/runxmonad.sh
-
Type=Application
Other than that, simply follow this little guide to make the keyboard and touchpad work properly.
I missed the Facebook thing, but it seems that after JAOO, I got sucked somewhat into Twitter. I'm still a little uncertain as to the actual value of it, but it's always nice to have somewhere to let out your incoherent frustrations. One of the first issues that creep up is whether to write on Twitter that I've written a blog post - and should I do it for a post where I write about me using Twitter? I don't know... Anyways, now you all know where to twit me.
Recently, I've been messing around with JXTA - one of the things you might have heard about at some point (like JINI, for example), but never really given any thought to. Probably rightly so, because it's only interesting if you do any kind of P2P. And not just human peers.
Anyways, we're planning on using JXTA to create a distributed version of one of our big monolithic systems. The data model has been modified to support distribution, and we've had a prototype running with hardcoded communication channels. However, JXTA makes everything much more dynamic, and it also introduces the concept of rendezvous and relay nodes so all nodes don't have to be on the same network - they don't even have to connect to each other directly. Pretty sweet stuff.
It turns out, however, that the JXTA documentation really doesn't explain everything, so I have two things I want to share - not that I expect them to be useful to very many people.
The first thing is really just a problem rather than a solution. I develop on a nice Macbook Pro Santa Rosa. I don't particularly like Apple (as in not at all, actually. Developer-wise, they might even be higher on the hate-list than Microsoft), so I've removed OSX entirely and installed Ubuntu instead. Now you might ask why I then use a Macbook at all, but it turns out that they make pretty good hardware, so I go with that. Incidentally, I also have an iMac at home, also running Ubuntu. It turns out that this is a problem in one single regard: When I have the wireless network enabled and start a JXTA application, the kernel will freeze. Every time. And there will be no errors in any log files. Nothing bad happens if I use wired network or a 3G modem - which is my solution until now. Of course, it seems that nobody in the whole world has ever had this problem, so there's not much chance of getting it fixed (and where do you report such a bug?).
The other thing that's been consuming quite a lot of my time is JXTASockets. JXTASockets are basically regular Java sockets running over JXTA. Instead of connecting to a specific host on a specific port, you simply ask JXTA to give you a socket to an abstract host identifier. JXTA will then route the request to the appropriate host, and then you can send and receive data. Except for the connect phase, it works just like a normal socket. Except not entirely. In many cases you would do something like on the server side:
CODE:
-
JXTAServerSocket server = new JXTAServerSocket(...);
-
while (true) {
-
JXTASocket socket = server.accept();
-
InputStream is = socket.getInputStream();
-
OutputStream os = socket.getOutputStream();
-
-
int b = -1;
-
while ((b = is.read())> -1) {
-
// buffer bytes
-
}
-
is.close();
-
-
byte[] res = handleRequest(buffer);
-
os.write(res);
-
os.close();
-
socket.close();
-
}
And on the client side something like this:
CODE:
-
Socket socket = new JXTASocket(...);
-
InputStream is = socket.getInputStream();
-
OutputStream os = socket.getOutputStream();
-
-
os.write(generateRequest());
-
os.close();
-
-
readResponse(is);
-
is.close();
-
socket.close();
Of course, all sorts of error handling, buffering, and other stuff is missing, but the overall procedure should be clear: the client writes to the output stream and closes it. The server reads from the stream until it has been closed. The server then generates a response and writes it back. Add the appropriate resource handling, and this will work using normal sockets, but it will not work with JXTA. And no, it is not obvious why. In fact, I think the plot of "A Serious Man" is more obvious, and if you've seen the movie, you'll probably agree with me that it is, indeed, not obvious at all.
The problem with JXTA turns out to be that both streams must be open all the time. If you, for example, close the output stream on the client side to signal that there is no more data, the server side will simply get a read timeout at some point. This basically means that you cannot use a closed stream to signal the end of the data stream, so instead you have to write the data length to the stream first, and then the data. The receiving side can then read the data length first, and then read the actual data accordingly. Which is not bad, it just sucks when you've spent so many hours debugging that read timeout.
It's been a while, but thanks to a couple of contributions, I finally managed to release the next version of the Hudson plugin for Eclipse, this time version 1.0.8. There are a couple of new features: Non-blocking refreshes, Date and time-information for the builds, support for HTTP Basic Auth, and a couple of bugfixes. Check out the changelog and download at http://code.google.com/p/hudson-eclipse/.
Karmic Koala
RSS feeds available for 
