After three years, a new version of ocaml-gettext is out. I know that the delay is quite long... Been too busy to do anything regarding this. This new version is mainly a bug fix release:

• UTF-8 is better handled when merging PO/POT
• multi-lines, special and continuation comments of PO file are supported
• camomile implementation is now safer (less chance to fail if something goes wrong)
• improve overall build system

However, the major event of this release is the fact that it is now compatible with OCaml 3.10.0. This is a big news, because string extraction heavily rely on camlp4, which has changed a lot. I have also uploaded a debian package of ocaml-gettext. Plans for next release:

• website has not been updated because generating it is too much complicated, i should switch to something more simple layout and generation scheme
• my home-made build system is not good at all (fail to detect changes and do incremental rebuild...), next release should move to ocamlbuild
• PDF generation has been disabled, because it makes fop produce a lot of errorrs, it should be re-enable
• finish the patch to xgettext to allow OCaml string been extracted

Homepage Download

Next week will be quiet busy. I will travel a lot. Of course, I am talking about OCaml Meeting and FOSDEM. The OCaml Meeting subscription is over and we reach a quiet good number of attendees: 45. This is the approximate number of people who come last year. There is now some details to finish (dinner for the previous day, schedule for talks...) but enough time left. The only thing I hope for the meeting is that it generates the same effect as last year: another impulse in the OCaml community. Many people are working continuously on OCaml but last year event has generated a lot of post-event discussion and many people started different project. Some of these projects are still alive, some are not as vivid as they deserve. I enjoy being at FOSDEM last year, but I only stay 1 day and it was not enough. I will be able to stay during the 2 days and attend more Debian conference than last year. I will visit Brussels and Ghent just after. Belgium is a really nice country and it has been a long time I haven't take a break.

During one of my project I need to interact with Java cryptographic extension. Some data has been encrypted using PBEWithMD5AndDES. I need to access it from OCaml. I take a look at available cryptographic extension in the Debian project for OCaml: cryptgps and cryptokit. I choose cryptokit, because its author is well known: Xavier Leroy. This article was my starting point. Of course, I keep in mind that the reference is there and that there is a good article covering it. Here is the result in OCaml:

 let decrypt passphrase salt ?(iterationCount=41) str =
   let key, iv =
     let rec hash_aux iter str =
       if iter > 0 then
         (* Rehash string *)
         hash_aux
           (iter - 1)
           (hash_string
              (Hash.md5 ())
              str)
       else
         (* Key = first 8 bytes of the MD5 hash *)
         String.sub str 0 8,
         (* IV = last 8 bytes of the MD5 hash *)
         String.sub str 8 8
     in
       (* Hash n times combination of passphrase and salt,
           return key and iv 
         *)
       hash_aux
         iterationCount
         (passphrase ^ salt)
   in
     transform_string
        (Cipher.des
           ~pad:Padding.length
           ~iv:iv
           key
           Cipher.Decrypt)
       str

The only missing information was the pad algorithm to use (Padding.length). For this piece of information, I need to browse the RSA documentation and test a little bit. Rewriting PBEWithMD5andDES is quite straightforward with cryptokit and OCaml. It takes 25 lines with C# and OCaml (only counting LoC, no comment, no empty constructor or declaration in C#). I was thinking that this task will require 2 or 3 days, but it has been done in 4 hours... Many thanks to cryptokit ;-)

Fresh up on arxiv.org is a paper by Kevin Heng, Kristen Menou and Peter Phillipps: Atmospheric circulation of tidally-locked exoplanets: a suite of benchmark tests for dynamical solvers. Kristen Menou was at exoclimes 2010 where one of the background topics was how to compare and validate our various models in exoplanetary climates. Earth-based climate modellers have test cases such as Held-Suarez which are used to compare the models, but to date no equivalents are used for exoplanetary models. This work fills that gap for Tidally-locked atmospheres (similar to Zarmina for example, and some 'Hot Jupiters'. I'm particularly interested in the tidally-locked Earth case; it's relevant for my own PhD work. Incidentally, for a good summary of the different ways we test climate models, see Steve Easterbrook's recent blog entry; he's been doing a tour of major modelling centres, learning how they do things. Worth a look. Tags exoplanets, climate, benchmarks

This summer I got the chance to buy cheap Spykee robots, and since then I have worked on getting Linux software in place to control them. The firmware for the robot is available from the producer, and using that source it was trivial to figure out the protocol specification. I've started on a perl library to control it, and made some demo programs using this perl library to allow one to control the robots. The library is quite functional already, and capable of controlling the driving, fetching video, uploading MP3s and play them. There are a few less important features too. Since a few weeks ago, I ran out of time to spend on this project, but I never got around to releasing the current source. I decided today that it was time to do something about it, and uploaded the source to my Debian package store at people.skolelinux.org. Because it was simpler for me, I made a Debian package and published the source and deb. If you got a spykee robot, grab the source or binary package:

• libspykee-perl_0.0.20101009-1.tar.gz
• libspykee-perl_0.0.20101009-1.dsc
• libspykee-perl_0.0.20101009-1_all.deb

If you are interested in helping out with developing this library, please let me know.

As some of you might know, I'm an OpenStreetMaper. In the last month, during those bits of spare time I had, I wrote a set of python scripts which compute some statistics over an OSM dump. I do this by parsing the whole XML tree, and national dumps are pretty huge (italy.osm is ~4G nowadays, and is not as well-mapped as Germany!), so I needed a way to do this without creating a memory-hungry beast. With Python, I could succesfully do this:

#!/usr/bin/python
# -*- coding: utf-8 -*-
import xml.etree.cElementTree as etree
def parse(filename):
    source = open(filename)
    context = etree.iterparse(source, events=("start", "end"))
    context = iter(context)
    event, root = context.next()
    for event, elem in context:
        if event == "end":
            root.clear()
            continue
        print elem.tag
if __name__ == '__main__':
    import sys
    parse(sys.argv[1])

And here the results:

$ /usr/bin/time ./parsexml.py ~/osmstats/dumps/italy.osm.bz2.20100912.out 1>/dev/null
413.22user 6.15system 8:57.80elapsed 77%CPU (0avgtext+0avgdata 21200maxresident)k
7739552inputs+0outputs (10major+1470minor)pagefaults 0swaps

However, since some time, I wanted to learn Vala, so I tried to do this very same task with it. Here's the code:

using Xml;
class XmlParser  
    public void parse_file(string path)  
        var handler = SAXHandler();
        void* user_data = null;
        handler.startElement = start_element;
        handler.user_parse_file(user_data, path);
     
    public void start_element(string name, string[] attr)  
        stdout.printf("%s\n", name);
     
 
int main(string[] args)  
    Parser.init();
    var parser = new XmlParser();
    parser.parse_file(args[1]);
    Parser.cleanup();
    return 0;
 

You need to compile it with: valac --pkg libxml-2.0 xml.vala And here's the result:

$ /usr/bin/time ./xml ~/osmstats/dumps/italy.osm.bz2.20100912.out 1>/dev/null
122.01user 4.03system 3:14.61elapsed 64%CPU (0avgtext+0avgdata 6352maxresident)k
7738984inputs+0outputs (0major+461minor)pagefaults 0swaps

Both these codes are, however, CPU-hungry. But at least they don't swap Needless to say that I'm planning to switch my scripts to Vala for 2.0.

I should probably have researched the batteries in this old solar-powered house before I installed a charge controller. I had assumed that the 24 6-volt batteries in the house's battery bay were standard lead-acid deep cycle batteries. It wasn't until I stumbled over a receipt from 1997 that I learned that the batteries are really NiCads. Specifically Saft model STM5-180. Thirty of these were purchased in 1997 from TVA in Chatanooga, for $350 total. An amazing price, since a single deep cycle battery is in that ballpark, new. These batteries were used, they had been in a "bus" -- perhaps it was a 1995 Chrysler TEVan, or maybe one of the pilot electric buses running there in the late 90's. They were probably not in this '79 VW TVA Bus. All mentions of these batteries I can find involve electric vehicles -- it's unusual for them to be used to power a house. Being vented NiCads probably accounts for these batteries' long useful life -- surely at least 15 years. Still, with only twenty-four good ones left, they are probably toward the end of their lifespan and need to be taken care of in order to last. Once I realized they were NiCads, I knew the charge controller was charging them wrong. NiCads like to be charged at a higher voltage than the 13 or so volts used for lead acid. I would have liked to charge them at 16 volts, but that would feed back through the house wiring, and could fry 12 volt stuff. Checking ratings, 15 volts seemed the highest voltage I could risk. Coming back a week later, I found the batteries charged up to 13.4 volts. And they are now working great. Through several cloudy days, we had all the power we needed. And when the sun was out fully, I sometimes saw the solar panels charging the batteries at 125 watts -- fully half of the panels' rated capacity, and much better than before. The batteries start each evening at 13.4 volts, and only drop to 13.3 by morning. We started using electric lights more, and then just leaving them on all evening, and the nslu2 online all night, and the batteries remained at the magic 13.3 in the morning. This is because NiCad batteries have a near-constant voltage until they are perhaps 30% discharged. In other words, I had been charging them less than half full before. I have figured out how to combine the two banks the batteries are in into one large bank, and once I get the cables to do that, I hope to have battery capacity to get through up to a week of solid clouds in midwinter.

battery box and solar panel

Web Video and Global Innovation Chris Anderson (the curator of TED) gave an insightful TED talk about Web Video and Global Innovation [1]. Probably most people who have used the Internet seriously have an intuitive knowledge of the basic points of this talk, Chris had the insight to package it together in a clear manner. He describes how the printing press decreased the importance of verbal communication skills and services such as Youtube have caused a resurgence in the popularity and importance of speeches. He has some interesting theories on how this can be leveraged to improve education and society. Lectures for Developers vs Users Now how can we use these principles to advance the development of Free Software? It seems to me that a good lecture about Free Software achieve will achieve some of the following goals:

1. Promoting projects to new developers.
2. Teaching developers some new aspects of software development related to the system.
3. Promoting projects to new users.
4. Teaching users (and prospective users) how to use the software.

The talks aimed at developers need to be given by technical experts, but talks aimed at users don t need to be given by experts on the technology and someone who has less knowledge of the software but better public speaking skills could probably do a better job when speaking to users. Would it do some good to encourage people to join Free Software projects for the purpose of teaching users? It seems that there are already some people doing such work, but there seems little evidence of people being actively recruited for such work which is a stark contrast to the effort that is sometimes put in to recruiting developers. One problem in regard to separating the user-training and developer-training parts of Free Software advocacy and education is that most conferences seem to appeal to developers and the more Geeky users. Talks for such conferences tend to be given by developers but the audience is a mix of developers and users. Would it be better to have streams in conferences for developers and users with different requirements for getting a talk accepted for each stream? Publishing Videos It has become a standard feature of Free Software related conferences to release videos of all the talks so anyone anywhere in the world can watch them, but it seems that this isn t used as much as we would like. The incidence of Free Software developers citing TED talks in blog posts appears to exceed the incidence of them citing lectures by their peers, while TED talks are world leading in terms of presentation quality the talks by peers are more relevant to the typical Free Software developer who blogs. This seems to be an indication that there is a problem in getting the videos of talks to the audience. Would it help this to make it a standard feature to allow comments (and comments that are rated by other readers) on every video? Would having a central repository (or multiple repositories) of links to Free Software related talks help? Would it help to have a service such as Youtube or Blip.tv used as a separate repository for such talks? Instead of having each conference just use it s own servers if multiple conferences uploaded talks to Youtube (or one of it s competitors) then users could search for relevant talks (including conference content and videos made by individuals not associated with conferences). What about video replies ? What if after each conference there was an RSS feed of links to videos that had one video featured per day in a similar manner to the way TED dribbles the talks out. If you publish 40 videos of 45 minute lectures in one week you can be sure that almost no-one will watch them all and very few people will watch even half of them. But if you had an RSS feed that gave a summary of one talk per day for 6 weeks then maybe many people would watch half of them. Defining Success Chris cites as an example of the success of online video the competition by amateur dancers to create videos of their work and the way that this was used in selecting dancers for The LXD (Legion of eXtraordinary Dancers) [2]. I think that we need a similar culture in our community. Apart from people who give lectures at conferences and some of the larger user group meetings there are very few people giving public video talks related to Free Software. There is also a great lack of instructional videos. This is something that anyone could start doing at home, the basic video mixing that you need can be done with ffmpeg (it s not very good for that purpose, but for short videos it s probably adequate) and Istanbul is good for making videos of X sessions. If we had hundreds of Free Software users making videos of what they were doing then I m sure that the quality would increase rapidly. I expect that some people who made such videos would find themselves invited to speak at major conferences even if they hadn t previously considered themself capable of doing so (the major conferences can be a bit intimidating). How do we Start? Publishing videos requires some significant bandwidth, a cheap VPS has a bandwidth quota of 200GB per month, if short videos are used with an average size of 30MB (which seems about typical for Youtube videos) then that allows more than 6000 video views per month which is OK but as my blog averages about 2000 visits per day (according to Webalizer) it seems that 6000 views per month isn t enough for any serious vlogging. Not to mention the fact that videos in higher resolution or a sudden spike in popularity can drive the usage a lot higher. It seems that a site like Youtube or blip.tv is necessary, which one is best? There are lots of things that can be changed along the way, but a hosting service is difficult to change when people link to it. Conclusion I don t claim to have many answers to these questions. I m planning to start vlogging soon so I will probably learn along the way. I would appreciate any suggestions. Also if anyone has a long suggestion then a blog post will be best (I ll link to any posts that reference this one). If anyone has a long suggestion that is worthy of a blog post but they don t have a blog then I would be happy to post it on my blog.

• [1] http://www.ted.com/talks/chris_anderson_how_web_video_powers_global_innovation.html
• [2] http://thelxd.com/

In the last two cases where I created FAI configurations for different systems I needed to install packages which are not part of the Debian repositories.
Unfortunately FAI does not provide a standard way to supply the installation with custom packages so I need to figure out a way on my own.

I have the following requirements in the solution:

• Packages can be configured in package_config files as usual
• Packages will be installed during the normal package installation, no crude hack (like 'dpkg -i' and 'apt-get -f install' after usual package installation)

It would be easy if a repository reachable by the installed system would already exist. Unfortunately it does not. But.. aha! So here is the idea:

1. In the FAI configuration space add a new directory
   'packages'
2. We will use reprepro for the repositiory. You should install it where ever you prepare the configuration space. It would also be an option to install it into the NFSROOT and run it from there, but I decided to pre-prepare it (but this would be a clean solution if one of the FAI developers decided to implement a standard way, I guess).
3. Create a directory packages/conf and therein a file distribution with this content:
   

   Origin: Debian
   Label: Debian-All
   Suite: stable
   Codename: lenny
   Version: 5.0
   Architectures: i386 amd64
   Components: main
   Description: Debian Lenny

   Obviously you should adapt at least the Architectures line to whatever you need. Otherwise adapt what you need.
   
4. Now you can add packages, with reprepro includedeb lenny /path/to/debfile from within that directory, so cd to it, before.
   The result is, that the packages directory becomes a full-fledged Debian APT repository which can be used with apt by creating a line similar to the following:
   

   deb file:/var/lib/fai/config/packages lenny main contrib non-free

6. And thats what we'll do. In order to make this happen before any software gets installed, we create a hook. It needs to be called instsoft.CLASS where CLASS is a class that is used for the fai install we are working on. It basically needs to contain something like (+ the usual shell script stuff):
   
   

   $ROOTCMD ainsl /etc/apt/sources.list "deb file:/var/lib/fai/config/packages lenny main contrib non-free"
   $ROOTCMD apt-get update

   This should add the repository the sources.list in the /target and run apt-get update.
   

Thats it. This should be all to make the repo available to the usual installation. That means if your package_config files contain packages which are only part of the custom repo they will now be able to be installed.

(This might probably not be a copy and paste howto. It just describes the rough steps needed to do and might contain errors. So don't blame me if it doesn't work 100% this way. ;-)

A conffile is a configuration file managed by dpkg, I m sure you remember the introductory article about conffiles. When your package stops providing a conffile, the file stays on disk and it s recorded as obsolete by the package manager. It s only removed during purge. If you want the file to go away, you have to remove it yourself within your package s configuration scripts. You will now learn how to do this right. When is that needed? dpkg errs on the side of safety by not removing the file until purge but in most cases it s best to remove it sooner so as to not confuse the user. In some cases, it s even required because keeping the file could break the software (for example if the file is in a .d configuration directory, and if it contains directives that are either no longer supported by the new version or in conflict with other new configuration files). What s complicated in rm ? So you want to remove the conffile. Adding an rm command in debian/postinst sounds easy. Except it s not the right thing to do. The conffile might contain customizations made by the administrator and you don t want to wipe those. Instead you want to keep the file around so that he can get his changes back and do whatever is required with those. The correct action is thus to move the file away in the prerm, to ensure it doesn t disturb the new version. At the same time, you need to verify whether the conffile has been modified by the administrator and remember it for later. In the postinst, you need to remove the file if it s unmodified, or keep it under a different name that doesn t interfere with the software. In many cases adding a simple .dpkg-bak suffix is enough. For instance, run-parts ignore files that contain a dot, and many other software are configured to only include files with a certain extension say *.conf. In the postrm, you have to remove the obsolete conffiles that were kept due to local changes and you should also restore the original conffile in case the upgrade obsoleting the conffile is aborted. Automating everything with dpkg-maintscript-helper Phewww that s a lot of things to do for a seemingly simple task. Fortunately everything can be automated with dpkg-maintscript-helper. Let s assume you want to remove /etc/foo/conf.d/bar because it s obsolete and you re going to prepare a new version 1.2-1 with the appropriate code to remove the file on upgrade. You just have to put this snippet in the 3 relevant scripts (preinst, postinst, postrm):

if dpkg-maintscript-helper supports rm_conffile 2>/dev/null; then
    dpkg-maintscript-helper rm_conffile /etc/foo/conf.d/bar 1.2-1 -- "$@"
fi

You can avoid the preliminary test if you pre-depend on dpkg (>= 1.15.7.2) or if enough time has passed to assume that everybody has a newer version anyway. You can learn all the details in dpkg-maintscript-helper s manual page. I hope you found this article helpful. You can follow me on Identi.ca, Twitter and Facebook. 5 comments Support my work

I've recently got a mail from one of my faithful reader, asking why not considering notmuch. Actually, I think notmuch already exists in a better way, and that's called IMAP and Sieve. What notmuch does, is tagging your mail with tags (obviously), based on filtering rules you write. The big downside is that you have to tag all your mails on your computer. And if you use several computers, you'll have to tag several times your mails. And you'll have to find a way to maintain your rules to be identical on all your computers. That does not scale. Using Sieve for mail filtering, one can do already that actually, and much more. A notmuch rule like:

notmuch tag +intel from:intel.com and not tag:intel

Can be written as a Sieve rule like:

if address :all :contains "From" "intel.com"  
        addflag "intel";
 

The flags extension for Sieve is explained in RFC5232. The Sieve based solution has the advantage of being treated server side, and therefore not subject to multiple or different MUA usages. It's also fast, if you use a good IMAP server like Dovecot, which has indexing, etc. Furthermore, Sieve can obviously do a lot more than tagging, like splitting into different mailboxes, filtering with regexp usage, vacation, etc. And if you want to fetch your mail locally, you can synchronize the IMAP box entirely with any software able to (like OfflineIMAP). Now, what's probably missing, is a correct support for IMAP flags on various MUA around. But that's not something notmuch helps to solve either. :-)

I am really struggling with all this anti-Obama rhetoric, coming from both the right and the left. From where I sit, while he hasn t been perfect, he s accomplished quite a bit for us since he s been president. Consider:

• Obama got through the most comprehensive healthcare program we ve ever had, which will provide a needed safety net to many, and yet will save the government money.
• The bailout (TARP) happened when Bush was president, and consisted of loans and asset purchases. Current forecasts are that the government will get 90% of that money back.
• The recovery & reinvestment act passed by Obama has exceeded the estimates of 3 million jobs saved or created, as graded by non-partisan groups. Most economists argue it should have been bigger to make a better change in the economy. It s widely credited with having stopped the bleeding.

I don t get it. Liberals are claiming he s not doing enough, but look at what he s got to work with: Republicans filibustering just about everything in the Senate. I don t think that s Obama s fault. And the conservatives, as far as I can tell, are just yelling. I can t figure this out. They want to cut taxes, cut the deficit, and increase defense spending. Good luck with that.

Review: Thinking in Java, by Bruce Eckel

Publisher:	Prentice Hall
Copyright:	2006
Printing:	October 2009
ISBN:	0-13-187248-6
Format:	Trade paperback
Pages:	1461

Thinking in Java has gone through multiple editions. This review is of the 4th edition, which is targetted at Java 5 (with some minor updates for Java 6, released as it was going to press). Prior to reading this book, I'd never written code from scratch in Java and had never learned anything about Java in a structured fashion. My CS degrees come before the era of ubiquitous Java; the most I'd ever done with the language was look over and make some minor fixes to code other people had written, using general programming knowledge. I choose this book as my introduction because I was looking for a ground-up introduction with good reviews and was avoiding books that contained a printed version of the Java library documentation. I can get that myself on-line. I kept a set of notes on my impressions of the Java language itself separately and will not get into that here. This is, instead, a review of Thinking in Java as a book and as a training tool for someone who wants to pick up the language. First off, this is a remarkably well-titled book, much more so than the typical programming language book. Eckel is not just teaching Java as one programming language among many. He tries hard to teach the reader to think in Java, with a lot of attention to idiomatic use of the language and natural ways to use its expressiveness. This is exactly what I was looking for I don't want to just write C or Perl in Java syntax and I was very satisfied with the result. The book is also very heavy on source code examples; this is much of the reason why it's 1,461 pages. Eckel illustrates everything with Java code, generally complete functioning short programs. Even exploratory musings and experiments are implemented as Java code. I don't think there's any significant thought in this book that isn't shown in both text and in explained Java code. Eckel has also clearly put significant effort into choosing good examples and designing his sample programs. I have some past (mild) experience with object-oriented design, and a lot of experience with higher-level system design, and I was satisfied and occasionally intrigued by the object structures and design tips that Eckel provides. He uses design pattern language heavily, but not in a confusing way, and he takes some time to explain typical design patterns and illustrate them repeatedly. This is a solid introduction to good object-oriented program design as well as an introduction to Java. One oddity of this book, though, is that Eckel introduces the language from the ground up, starting with syntax and basic types, and is very careful not to use any concepts before he introduces them. The result is a very thorough introduction to the Java language, but it means that it takes 900 pages (!) before Eckel introduces I/O and the possibility of writing a useful program based on just the information in the book. This is for entirely sound conceptual reasons: I/O in Java relies on lots of concepts, like exceptions and generics, that require extensive introduction and discussion. However, it does mean that through well more than half of a monumental tome the reader is learning the language through rather artificial programs. I have extensive prior programming background and a high tolerance for more abstract examples (I have a master's degree in software theory), so I could deal with this, but even with that background I was starting to feel like my head was getting too full and too crowded with concepts without being able to make them concrete. It probably would have helped to work through some of the exercises, but I dislike exercises that aren't grounded in some problem I personally want to solve. If you're someone who only learns languages through practical application, this approach to teaching the language may drive you nuts, and you may want to look for another book that compromises conceptual progression to get you started faster. Related to this, Thinking in Java is not about the standard library. It's about the language, and the vast majority of this book is focused directly on the language level: inheritance, information hiding, generics, exceptions, introspection, concurrency, annotations, serialization, and so forth. The only parts of the standard library that Eckel covers in depth are the container classes, I/O, and a somewhat odd and misplaced final chapter on Swing. There is nothing about databases, essentially nothing about web applications or containers, no network programming, and very little in the way of practical, applied problems. As you might guess from the combination of that limitation of scope and the length of this book, that means it is extremely comprehensive; I doubt there are many corners of the basic language semantics, including around generics, that Eckel leaves unexplored. This is exactly what I wanted (I know how to read library documentation myself and all language core libraries start looking mostly the same after you've programmed in five or six languages), but it's very different from the typical approach of a programming language book. Don't be surprised. This biggest problem with Thinking in Java from my perspective is that it defers many interesting topics to Eckel's web pages and to free companion books and material that is supposedly found there, to the point of advertising that on the cover. This is a good way to allow the reader to explore extra topics that are of specific interest while skipping others, provided that one actually delivers on that promise. However, Eckel's web site is dire. The first time I looked at it earlier this year I was unable to find most of the supplemental material the book promises is there, and now www.mindview.net doesn't resolve in DNS. I've found copies of some of that material hosted elsewhere in Google searches, but this is a rather frustrating experience if one was relying on that supplemental material to fill in the gaps. And the book is clearly written expecting people to go look at the web materials; Eckel refers to them probably a hundred times over the course of the book. Less of a serious problem, and more of a quirk, is the closing chapter on Swing. This chapter really doesn't fit much with the book. I suppose Eckel felt obligated to put in at least one chapter on some concrete applied topic (I personally would have preferred databases be that topic, but oh well), and it does serve a useful purpose in showing how concurrency, inner classes, inheritance, and introspection all work together in a significant Java library. But it's not presented as just an example, and it fits in oddly with the rest of the book. It also has an inexplicable middle section about Flash programming. I ended up mostly skimming this. But this isn't much of a flaw in the book; if one ignores 100 pages out of 1,450, that's not much of a loss. Eckel comes from a C++ background (he was a founding member of the C++ standardization committee), which shows up most prominantly in the generics chapter. It's a solid, thorough introduction to Java generics, but it also has an extensive exploration of all the problems with the Java erasure model and many, many examples of the things that one would find intuitive from C++ that don't work the same way in Java. If you come from a C++ background, this is quite possibly useful; if, like me, you don't care about C++, it's at best mildly interesting and gets a touch tedious. There are a few other places where Eckel pokes surprisingly sharp sticks at the Java designers, but taken in context I think this is a quirk of the book's conversational style (which is otherwise a feature). Eckel's love of Python is also somewhat entertaining (particularly the long advertisement for Python in the introductory chapters of a book on Java), but has little impact on the book. I think the largest drawback of it is that all the examples in this book are tested using a Python framework, which isn't so much a problem with them as a lost opportunity. They're annotated with metadata used by Eckel's Python test framework, and in a Java book I would have been much more interested in a good Java test framework built on top of something like JUnit. Oh well. Overall, this is a very solid book which, despite being enormous, does not feel pointlessly padded. It's thorough and exhaustive on its topic, but there's a point to nearly everything in here. It was also exactly the Java book I wanted: an introduction to the language, built on a firm foundation of object-oriented program design, with discussion and pointers on how to think idiomatically in the language and use it to its fullest potential, and without mindlessly reproducing the standard library documentation. If that's also what you're looking for in a Java book, I recommend it highly. Just know going in what sort of book you're getting, since its pacing and order of presentation may frustrate some learning styles. Rating: 8 out of 10

Last night, I released xen-tools 4.2 and also uploaded it to Debian Unstable. It also should become part of the upcoming Debian stable release called Squeeze. (Thanks, Mehdi!) For those who are missing xen-tools in Ubuntu 10.04 Lucid Lynx or Ubuntu 10.10 Maverick Meerkat, there s now a xen-tools PPA containing the current stable package for both Ubuntu releases. Major changes since the 4.2 release candidate 1:

• Tons of documentation improvements
• Preliminary support for Ubuntu 11.04 Natty Narwhal and Debian 7.0 Wheezy (Closes #597521)
• More robustness on exotic combinations of command-line options

Major changes since 4.2 beta 1:

• Uses GeoIP for Debian mirrors: Default Debian mirror is now cdn.debian.net
• Uses apt-config to parse Dom0 s apt.conf. (Closes #560011)
• With --verbose, the output of commands called by xen-tools (e.g. debootstrap) is not only logged, but also printed to STDOUT. (Closes #513126)
• Adds btrfs support.

New Team Member I d also like to welcome St phane Jourdois as member of the xen-tools development team who contributed quite a lot of the new code in 4.2. See GitHub s Impact Graph or Ohloh s List of Contributors. Roadmap If there s no need for a bug fix release, the next release will be 5.0 and will be the result of some heavy refactoring. Our aim is:

• less code duplication
• more modularity
• more consistency over all included scripts and hooks

We will probably also use Perl::Critic to improve the code consistency and quality further. (Thanks Ren e for the idea!)

I've just uploaded git-dpm 0.3.0-1 packages to experimental. Apart from many bugfixes (which I will also take a look if I can make an 0.2.1 version targeting squeeze, though the freeze requirements tend to get tighter and tighter, so I may already be too late), the biggest improvement is the newly added git-dpm dch command to spawn dch and then extracts something to be used for the git commit message (I prefer to have more control over debian/changelog, so I prefer this way over the other direction).

I'm in hospital, taking an enforced rest from work and normal life.with much too much time to think. Luckily I have relatively slow 'Net access.

I've just spent about three weeks in a specialist orthopaedic hospital which is also a centre of excellence, a research and teaching hospital. Some lessons for FLOSS:

Research methods matter: open communication matters more

The hospital was apparently doing various research projects, some minor, some major: whether cooling a knee joint in surgery improved recovery and aftercare, whether complete pain relief and comprehensive analgesia stimulated recovery, trying to standardise on a pain score to measure subjective pain - " On a scale of 1-10 how does it feel?"

The knee joint research was being written up and would be shared worldwide - if it proved worthwhile, hundreds of patients could benefit. If it wasn't worthwhile, it would still be written up just as comprehensively with testing methodology, evidence from double-blind trials or whatever as appropriate to save someone else from having to re-invent the wheel.

The analgesia study sounded just like the application of a doctor or nurse's intuitive commn sense and experience - but it was being carried out scientifically and measured. also answering supplementary questions like "If pain is sometimes a helpful indicator of problems, how should you guage reactions when all pain is dulled?" Additionally, the ward had dispensations to use different and more flexible drug regimes to include the use of oral morphine derivatives. Again, everything was being noted, measured and shared.

Many people know Ultimate Debian Database already, and do use of it to create useful QA tools, or other Debian related activities. There is another database which is widely used by all of us, every day, and runs behind the scenes without being noticed. It is called projectb, the huge database of the Debian archive. projectb is the place where dak stores all the information it needs to run the archive (including but not limited to source packages, related binaries, suite definitions and associations, overrides, and so on), and it tells dak to hit you with a REJECT if you try to upload a package twice, or if you do something The Wrong Way. OK OK, it eventually allows your packages to be accepted too, sometimes it also behaves good projectb is hosted on ftp-master.debian.org. Most fellow Debian Developers cannot login over there because access is restricted to FTP and Release people only, but can enjoy its clone on merkel.debian.org ^[1]. Please note that clone is synced on a regular basis, but it could be a little bit not up-to-date with the very latest changes. Just run the following: psql -d projectb -p 5433 Now that you have access to it, you could want look at its structure to start looking at it. I just provide a couple of trivial examples of what you can do with it, your imagination is the limit ^[2] This query displays which dpkg version known suites ship:
SELECT s.source, max(s.version) AS version, su.suite_name AS suite
FROM source s
JOIN src_associations sa ON sa.source = s.id
JOIN suite su ON su.id = sa.suite
WHERE s.source = 'dpkg'
GROUP BY s.source, su.suite_name
ORDER BY version; This query displays changelog entries for debhelper which versions are greater than 8:
SELECT changelog
FROM changelogs
WHERE source = 'debhelper'
AND version > '8'; Working with projectb means working with real Debian archive data, so you are sure to always get solid information. You can also experience a limited (but functional) dak session on merkel. You cannot do much, data is read-only, but this is not a limit for a couple of commands. The most interesting is dak rm, where you can simulate a package removal, and discover reverse dependencies in advance, to save some work to your lovely FTP Team Just run the following:
dak rm -n -R -m "Don't worry, it's a Dry Run" your_behated_package Wait a little bit, and you will be prompted with removal report. Just remember to always use -n and -R flags, though. Want even more? Join FTP Team, and you will given the chance to learn a lot more about Debian! DISCLAIMER: if you plan to write a tool, or perform an activity which relies on current projectb implementation, PLEASE TALK TO FTP TEAM FIRST. Internal structure can change a lot over times, and it is way better let FTP Team to handle exporting/parsing its data for day-by-day tasks. ^[1] This is probably supposed to change, as merkel is going to be decommissioned soon. ^[2] If you need a new feature, just talk to FTP Team.

Proposed timeline of the Release Team

We hope to have sorted out all the details and resolved the remaining blockers by the end of October, with the focus during November being on translation updates, testing and coordination with different teams to prepare the new release.
This means that it s possible to have a release out in time for Christmas, but to do this we need YOUR help. Please, squash bugs, write release notes, squash bugs, support our translators and squash some bugs.

A while ago, I found the nice arcade game Zaz. The goal is to sort rolling marbles by color to make them vanish before they fall down a hole. I enjoyed playing it in turn with my girlfriend, but it was not nice that one of us always had to wait and watch. Also, Zaz is quite hard and my girlfriend (who is better at the game) did not manage to finish all levels. So I thought, that it would be great if we could play the game together! I recently read that the version of the X server on my laptop supports XInput2 and thus multi-pointer-input, so I thought I give it a shot. The main problem with making the change was SDL, a very common library used by Zaz to interact with the system. The SDL code fetches the events from the X server, handles them (e.g. mapping button presses to unicode characters, remembering mouse positions to calculate relative movement). SDL itself does not know anything about multi-pointers, or the events generated by XInput2. So once I started to listen to XInput2 events, no regular events would come through any more and the game stops reacting. The SDL supports passing unknown X events in a SDL_SysWMEvent. This would have helped, but XInput2 passes its data in X s new GenericEvents where additional data needs to be fetched with XGetEventData before the next X event is handled. SDL does not know that and thus, when more than one event is waiting, the event data is lost before SDL passed them to the application. Therefore I completely bypass the SDL event handling and only use XNextEvent myself. This meant re-implementing some logic, especially relative mouse movements and keeping the mouse within the window, guided by the SDL code. I did not worry about text input, so you need to enter the name for the highscore with an unpatched Zaz :-). The game logic site was surprisingly easy to adjust to more than one player. Just replaced the Player object by an array of Player objects, and the game machinery still works. This is a sign of very good design, kudos to Remigiusz Dybka. At first, when the laser pointer bonus was picked up, only the first player would get it. I changed that so both players benefit from the bonus. It would make more sense if only the player who actually killed the bonus ball would get it, but that would be hard to track. In the end, the result is very satisfying. And together, we managed to finish the game at once. Enough words. Here is a demonstration of us two playing the first level, as a HTLM5 video (alternatively watch it on YouTube): If you want to try it yourself, you can either grab the Debian packages (v0.2.9, source package and binary built for amd64), the patch against version 0.2.9 or the patch against version 1.0.0. Then you need to plug in two mouses and use the xinput command line program to create a new master and reattach one of the mouses to the second master, before starting the game. And of course, you need a partner (unless you want to play the game bimanually good luck). PS: Why is my Ogg/Theroa video, created with recordmydesktop, all green when uploaded to YouTube? I hat to locally convert it to MPEG4 first...

When I am writing software sometimes XKCD is accurate!