-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1,SHA512
I am transitioning GPG keys from an old 1024-bit DSA key to a new
4096-bit RSA key.  The old key will continue to be valid for some
time, but I prefer all new correspondance to be encrypted to the new
key, and will be making all signatures going forward with the new key.
This transition document is signed with both keys to validate the
transition.
If you have signed my old key, I would appreciate signatures on my new
key as well, provided that your signing policy permits that without
re-authenticating me.
The old key, which I am transitioning away from, is:
  pub   1024D/DFCA34A3 2007-10-07 [expires: 2013-10-24]
    Key fingerprint = FE23 BE62 DF18 72FB C58D  D637 FFAE 0427 DFCA 34A3
The new key, to which I am transitioning, is:
  pub   4096R/95206DD3 2013-01-02 [expires: 2016-01-02]
    Key fingerprint = DF0B FDFF 4A4D DA01 7944  1B8F 6906 4B01 9520 6DD3
To fetch the full new key from a public key server using GnuPG, run:
  gpg --keyserver keys.gnupg.net --recv-key 95206DD3
If you have already validated my old key, you can then validate that
the new key is signed by my old key:
  gpg --check-sigs 95206DD3
If you then want to sign my new key, a simple and safe way to do that
is by using caff (shipped in Debian as part of the "signing-party"
package) as follows:
  caff 95206DD3
Please contact me via e-mail at <richih.mailinglist@gmail.com>
if you have any questions about this document or this transition.
    Richard Hartmann
    richih.mailinglist@gmail.com
    2013-01-03
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAlDk27gACgkQ/64EJ9/KNKMGDgCeLyQy6yhEu3OB8UarJ6LYOfVY
ihgAnRSbYMrVxK+28souMHiLx4y0rSQ+iQIcBAEBCgAGBQJQ5Nu4AAoJEGkGSwGV
IG3TcbYP/je8mu+MCIiNNY8w/gN+/9S8gEGWd2p9LeN71xpCuSpBVSevAxxStV9R
2XRTfI8tf/nk27y+4073IscUTPaBkb2IhvIfCnFmOtZjP9slS2JMHOylqH3KLulQ
Cm/IbpKCAwTmQtRMzFxKoRjNPJDCVzZYpoD9r7TmIrs+iKtDQ/w/zQmtwEFWncYK
2JJqVEd+qN9REpWlKDDifcUDPGiugsICelAaUF8VMvp2ouVxQTGbz53IdAgvrX9G
vM+BAfel3W73nfF3L+08vgad0BGGMnEWcfcZ6r+DKu2WXgC8AXT0Y32sD8TiGJSd
JrWMqwec1iOd6lfOpFDdhSCFyMl5r1NiOLw5iNsETHYjysW2N1wZCicmF/8ukm/y
EpIXf3z8vtLrofGLN1jTC34Jugts8C5NNRil195Hkim36t2F97OJswNLhxt7nQ41
vhyXaBK3kwOZ1nVp6xM/yMnQzi5eVO1W/BE8Wr27O6pe3KqEx0Lv8zBzQjj4ly64
shyNRY3gzxs/KZ3p/3nrSn1AYOXIuCM3nILh89qQ/ynotrqYmpFkUorUSSOvraoQ
LN5IPH0wh8F2eDUCui2fGDEmnQ5S5mlHnIZmL3gkPVGLhNaoFQh0R8UwUO6HIxMQ
cTxv5TGL1YWtIvl0bvlEXK6MA4g0ZBXk15JZkWUD84zycr5cb79d
=DFzt
-----END PGP SIGNATURE-----

In 2011, I wrote about how small files could consume a lot of space. I meant to do a follow-up on the savings but I forgot about it until now. In 2.5.7, we started compressing some of the collected data files. Some of these are ridiculously compressable (#664794). Even better, compressing them is sometimes faster than writing them directly to the disk, so in some cases it is a pure win/win. For lintian.d.o, we also see a vast size reduction in overall size of the laboratory. I have taken a few samples occasionally. The samples were done with du(1):
$ du -csh [--apparent-size] laboratory/*


Version/date	du -csh	apparent-size
N/A around 20 Mar 2012 (#664794)	16G	13G
2.5.6 (Fri Apr 27 2012)	14GB	N/A
2.5.6 (Mon Jun 04 2012))	N/A	12G
2.5.10.2 (Fri Sep 21 2012)	12G	8.3G
2.5.11 (Wed Jan 2 2013)	10G	6.1G

And the most awesome part of this? The comparison is quite biased against the 2.5.11 entry, which is the only entry to also process experimental (approx. 10% extra packages). Some of the early entries (2.5.6 and older ) might also have suffered from the too many links issue[1]. I only wish I had been better at collecting data points, so I could have made a proper graph of it. It sounds almost too good to be true, but if you look at the size of one of the linux-image packages[1], the space usage dropped from 27M to 15M between 2.5.5 to 2.5.9. Currently it is squeezed down to 14M (tested with head of the git master branch). [1] I believe is about 5-10% less binary packages processed for those runs. [2] linux-image-3.2.0-2-amd64_3.2.20-1_amd64.deb

podlators is the package that contains Pod::Man and Pod::Text and the pod2man and pod2text driver scripts, which convert Perl's POD documentation format into text and *roff (for man pages) output. This release is a "clearing the decks" release that rolls up various smallish feature requests and bug fixes that have been pending for a while. I want to do the same reworking to podlators that I did to Term::ANSIColor, but it's going to take longer since it's quite a bit more code. (And Term::ANSIColor took me about two days.) I didn't want to block the various pending issues on that work, so this tries to clean up all the open bugs I was aware of other than sorting out the defaults for Unicode output. (That's a much larger problem and will probably be fixed in a major release.) The primary change is that pod2man and pod2text now die by default if the POD contains syntax errors. This will hopefully flush out numerous POD documents around the world that have been carrying POD ERRORS sections around forever. I considered just warning by default but not failing, since this will also cause CPAN builds to fail, and I may fall back to that if there are too many complaints. But usually fixing the POD syntax is straightforward, and normally parsing programs will fail on syntax errors. Note that the defaults for the modules, Pod::Man and Pod::Text, continue to be to add a POD ERRORS section, since aborting inside a module isn't very friendly to the caller. There is a new option for both the modules and the driver scripts to set the error handling behavior, which can be set to die, report to standard error but continue, add a POD ERRORS section, or ignore errors entirely. Also in this release is a new nourls option that suppresses the URLs in text and *roff output for L<> codes that have anchor text, which can declutter some POD texts, and fixes for X<> formatting codes containing whitespace and small-caps handling of paragraphs consisting entirely of all-caps text. You can get the latest release from the podlators distribution page.

During Christmas, I have worked a bit on the Debian support for LEGO Mindstorm NXT. My son and I have played a bit with my NXT set, and I discovered I had to build all the tools myself because none were already in Debian Squeeze. If Debian support for LEGO is something you care about, please join me on the IRC channel #debian-lego (server irc.debian.org). There is a lot that could be done to improve the Debian support for LEGO designers. For example both CAD software and Mindstorm compilers are missing. :) Update 2012-01-03: A project page including links to Lego related packages is now available.

I just uploaded wit-2.10a to Debian experimental (it has to pass the NEW queue first, though). WIT (Wiimms ISO Tools) is a set of command-line tools to manipulate Wii and GameCube ISO images and WBFS containers. It is useful (for me) to store backups of my Wii games on a USB hard disk drive. This saves me the optical disc juggling, doesn t wear off the discs as fast and gives faster load times. Here is an example session where I format one partition of the USB hard disk with WBFS and then copy my old WBFS image over to it:

$ wwt format -v --force /dev/sde3
wwt: Wiimms WBFS Tool v2.10a r0 x86_64 - Dirk Clemens - 2013-01-02
FORMAT BLOCK DEVICE /dev/sde3 [172 GiB, hss=512]
** 1 file formatted.
$ wwt add --part /dev/sde3 /media/sde1/wbfs/The\ Legend\ of\ Zelda\ Skyward\ Sword\ \[SOUP01\]/*.wbfs
*****  wwt: Wiimms WBFS Tool v2.10a r0 x86_64 - Dirk Clemens - 2013-01-02  *****
WBFSv1 #1/1 opened: /dev/sde3
 - ADD 1/1 [SOUP01] WBFS:/media/sde1/wbfs/The Legend of Zelda Skyward Sword [SOUP01]/SOUP01.wbfs/#0
* WBFS #1: 1 disc added.
wwt add --part /dev/sde3   0,02s user 7,66s system 2% cpu 5:02,68 total
$ wwt list
ID6     1/500 discs (4 GiB)
---------------------------------------------------------------------
SOUP01  The Legend of Zelda Skyward Sword
---------------------------------------------------------------------
Total: 1/500 discs, 4176 MiB ~ 4 GiB used, 171444 MiB ~ 167 GiB free.

Yesterday was a busy Debian day for me with the release of not one but two packages. procps procps version 3.3.6 was released both as an upstream and a Debian package. While there were many bug fixes in this release, the main new feature for it was the top inspect feature. The top inspect feature allows you to run top in the normal way then you can inspect a specific process you have selected within top for more information. Examples of this include fuser or lsof type output to see what files or libraries are open but really the limit is how clever the operator is and how often you would need this information. Even scripts can be run off this feature if you have some customised or cooked output you need to see. Once the output is there, you can search for text. There will be a small hold-up with the Debian packages as the section for the library has been moved to libs, where it should be. At least I think that s why there is a delay. procps infrastructure procps currently has only an email list and a gitorious git repository. While this works most of the time, there are two main problems with this setup. The first is that the only two ways you can report bugs is send an email to the list or create a git merge request. The email has the problem with tracking and gathering history while the git sets the bar pretty high for reporting something has gone wrong. Second problem is there is no tarball file repository. gitorious does have the feature of downloading tarballs of the tag checkpoints, but this is the raw repository. When you make a tarball with make dist there are some generated files included in the tarball that don t appear in the gitorious ones, which means its not a simple for some as you expect. So I ll be creating a project for these two features soon. Not sure where they will be but I use sourceforge for both these for a few other projects so that might be where they end up. Mudlet Mudlet, the multi-user dungeon or MUD client, has finally made it to version 2.0! It looks a lot more stable and polished at least from the scripting side than the previous RC versions but has all the features that we ve come to expect with it. The most important thing is that the developers have finally put a line in the sand and said this is version 2.0 . The Debian package was uploaded yesterday and should be on its way to your local mirror soon.

For the year of 2012, I finished and reviewed 60 books, the same number as 2011. Given how stressful and chaotic much of the year was, I count this a major triumph. The hardest part was not the reading but the review writing; the end of the year required a significant push to finish writing reviews of all the books I'd read that year, and at one point I was reviewing things I'd read more than two months earlier. But I can enter 2013 entirely caught-up. This continues to feel like about the right pace, striking a balance between reading enough that I can pursue multiple reading goals at the same time, while leaving enough time for other projects and video games. I gave three novels a 10 out of 10 this year, but the stand-out even among that group was Elizabeth Wein's Code Name Verity. Not only was it my favorite book of the year, but it was one of the best books I've ever read. The other two 10-rated books are also highly recommended, of course: Matt Ruff's fascinating novel of multiple personalities, Set This House in Order; and C.J. Cherryh's SF classic, Cyteen. The latter was a re-read in advance of reading the sequel, Regenesis, which I also recommend if you've read and liked the last third of Cyteen. Other fiction highlights of the year were China Mi ville's Embassytown and Suzanne Collins's The Hunger Games triology, particularly the third book, Mockingjay. Embassytown continues the trend from Mi ville's The City & The City of tighter, faster-moving novels while moving into space opera and first contact territory. It keeps Mi ville in the top rank of current SFF writers, despite having some suspension of disbelief problems. Collins's world-building in The Hunger Games also has suspension of disbelief problems, but I understood why the series was so popular. I was caught by surprise by its look at violence and its after-effects and was particularly impressed by Mockingjay and Collins's chosen ending. I think this is a popular series that lives up to the hype. There were no 10 ratings in non-fiction this year, but several books nonetheless stood out. John Kenneth Galbraith's The Affluent Society is a thought-provoking book that questions the foundation of a consumer-oriented economy while perceptively pointing out how it distorts choices away from public goods. Susan Cain's Quiet is a passionate defense of introversion in an extroverted world. And, finally, Joshua Bloch's Effective Java and Damian Conway's Perl Best Practices are both insightful looks at the good and bad of their respective languages and taught me a great deal as a practicing programmer. One final highlight to mention: Eclipse Phase by Posthuman Studios is an excellent RPG sourcebook, at least from the perspective of interesting world-building. I haven't played it, but I thoroughly enjoyed reading it (and have acquired nearly all of the supplements). The full analysis includes some additional personal reading statistics, probably only of interest to me.

Choices, options, selections if you rather. These are what set us all apart from our fellow man, perhaps it is only the appearance of free will and individuality but our world is full of choice.

In software it might be argued programming is nothing more than making thousands perhaps millions of choices which result in a list of instructions for a machine incapable of making decisions of its own.

On a more mundane level sometimes a programmer cannot make a choice suitable for all expected use cases and a user option is created. These options have become something of a cause for arguments within certain sections of the open source software community especially amongst the groups that influence the graphical user experience.

The discussion should be nuanced and varied (perhaps that is my age, or maybe I am more diplomatic than I thought?) but there seems to be little compromise on this discussion which (from an outsiders point of view) splits into two viewpoints:

• On one side of the argument, which I shall label reductionist, is that all options should be removed with the software just doing the correct thing
• On the other, whom I shall refer to as maximalist, is that users should be presented with options to customise everything.

The reductionist group is currently winning the argument in the popular graphical environments and seem to be removing functionality which requires user choice wherever they can find it. This results in the absurd "joke" that the UI will become a single button, which they are trying to remove.

Personally my view is that an option should be present only when an option cannot be satisfactorily selected by the computer and even then a default suitable for as many users as possible should be picked.

You may ask why I have raised this topic at all? well over the last few days I have been trying to fix the preferences selection for the GTK port of NetSurf. The NetSurf project follows my view on this subject pretty closely but being a browser its very difficult to do the right thing for everyone

NetSurf has numerous frontends for the core browser, I use the term frontend because in some places the toolkit and OS are conflated (windows, cocoa) and not in others (gtk). For each frontend NetSurf is a native application, this is an important distinction, the windows and widgets a user interfaces with are produced by that platforms toolkit.

Old NetSurf Preferences Dialog

This is a deliberate choice unlike other browsers which render their UI themselves as web content, this is a beguiling solution when the authors wish there to be a single browsing "experience" with a common look and feel. However NetSurf looks and feels like a native browser for each frontend, which is what the project decided it wanted to achieve.

Given this the gtk frontend (is it a Gnome application? not sure of the distinction TBH) has had no dedicated maintainer for some time it has suffered from a bad case of bitrot from both GTK library changes and general neglect.

I have slowly been improving this situation, the browser can now be compiled with GTK version 2 (2.12 onwards) or 3, the menus and other UI elements have been translated for the supported languages and now the turn has come for the options dialog.

Oh, right, its "Preferences" not options, fair enough a common semantic throughout all applications does give a degree of homogeneousness but the word choice does seem to indicate the users control has been reduced. At this point I gained an education in just how unfriendly GTK and its tools have become towards the casual programmer.

The dialog I wanted to construct was a pretty standard tabbed layout which reflected the current options and allowed the user to change them in an obvious way. Given that I have constructed and equivalent interface in idiomatic manner for cocoa and windows I thought this would be straightforward, I was very wrong.

The interface construction tool is called glade which used to be the name of the UI "resource" file and interfaces. However the tool is still called glade but the interface is now GtkBuilder which has a different (but similar) XML based file format. Then we discover that despite it being an extensible file format the UI files are specifically versioned against the GTK library. Also why on earth can these resources not be compiled into my program? OK make them over-ridable perhaps. Generally it is yet another file to distribute and update in step with the executable.

New NetSurf Preferences

So because I want to support back to version 2.12 of GTK I do not get to use any of the features from 2.16 in my UI unless I load a different UI builder file...oh and GTK3? requires a completely different version of glade and the UI files which are incompatible with gtk 2. Once this was worked round with having multiple UI files I then moved on to the next issue.

The GTK model uses function callbacks on events, these are known as signals. Perfectly reasonable but because the ui files are loaded at runtime and not compiled in there must be a way for the GTKBuilder to map the textural signal names to function pointers.

The way the GTK developers have chosen to do this is to search the global function table which means any signal handler function symbol has also to be global which means unnecessary overhead for the ELF loader increasing load times.

This lookup should have been confined to a single object or even placed in an alternative section to avoid these issues, this would not have seemed especially challenging to implement as all callback handlers have to use a preprocessor to define already (G_MODULE_EXPORT).

Another thing that makes developing GTK applications worse is the documentation, this seems to be a continuous complaint about may open source projects, which is taciturn or simply missing in many cases. GTK seems to suffer dreadfully from having multiple API versions all subtly different resulting in a lot of work on the developers part to simply find what they want.

A specific example of this is the signals and under what circumstance they occur I wanted to update all the widgets with the current configuration state whenever the options window is shown (using gtk_widget_show()) so I figured that would be the "show" signal...right? nope, never did find the right one to use, ended up with "realize" which occurs once when the dialog is created, not what I wanted, but is at least consistent and works.

NetSurf with Preferences Dialog

Overall my impression of developing just one small dialog (60 widgets total exclusing labels and containers) for a GTK program is that the toolkit and its tooling is missing the facilities to make developers life easier when doing the drudge work that a good proportion of graphical program development.

It is not the case that one cannot do things, just that everything has to be done manually instead of having the tools do the work, and because of the documentation that tedium is magnified.

I did eventually reach the stage that the thought of writing the boilerplate to add another check button to enable "do not track" had me thinking "do they really need this or can I avoid the work?" perhaps that is why they are all reductionist?

Yet another yearly summary of my running activities. It seems, indeed, that running has now slightly taken precedence over free software activities in my life and priorities for my free time. To my fellow free software friends: don't worry, I'm not on my way to stop investing my time in Debian. It's quite clear that I'm reducing my involvement, mostly because days only have 24 hours...not because I'm bored or tired by free software development. But, certainly, it became an important thing that running currently has a small priority over Debian nowadays, for me. So, what happened on that front in 2012 for running bubulle? I finally managed to run 2900 km during the year, which is over 400km more than 2011. This is mostly due to the increasing part of running in my daily commute : a typical work week can now be something like this:

• Monday morning, leave home with a big bag and clothes for up to 4 work days (including those I'm wearing) plus running clothes (and shoes).
• Monday evening: come back by running. Either 4km, then 30 minutes train ride, then 3km more....or "the long version": 10km, then 20 minutes train ride, then 3km more.
• Tuesday: go to work by run+train+run, shower, change clothes, work, come back by run+train+run
• Wednesday: ditto
• Thursday: let's have a break. I usually work in another facility where it's less convenient to go by running
• Friday morning: go to work by run+train+run
• Friday evening: come back home with a big bag of dirty clothes

With such an organization, I can end up with weeks where I run up to 50-60 kilometers in 5 days, with peaks that may include 26km in one *work* day. I also end up having room in trains between the runs, I wonder why..:-) And, of course, during week-ends, I spend some parts of my time running too..:-). Indeed, just like for many drugs, I feel sad during days where I haven't run at all and it's usually hard for me to spend more than 2 days without. Indeed, the longest time period without running, this year, has been 9 days, just after the Caen marathon, in June. Mostly because, at that time, I reached a moment where training (and believe me, very boring and hard training) consumed all my motivation. But these moments are indeed very rare and training is mostly *never* boring for me. Mostly because I like running in the nature, in forests, woods, fields, country. Never wearing an MP3 player or any kind of such device toplay music, but just enjoying the outside, whether it's raining, winding, sunny hot. Running (particularly my daily commute) is also the moment where I *think* about my work, my technical activities, my own life, whatever. I think I even sometimes translated some software, mentally, while running..:) Indeed, there have been 205 days in this year where I ran at least once. Last year was 181 so....drug addiction is increasing. So, 2900 kilometers. That's about the distance from my place to Moscow in Russia. 282 hours (11 days18 hours.....9d21h last year). Average speed: 10,3km/h (10,5km/h last year). Cumulated height difference: 33,400 meters (27700m last year). More distance, more time, a bit slower: this is an obvious consequence of more trail running (which includes more difficulties, such as running on volcanoes!). Most active month: November with 331km. Less active month: June with 141km. This year was also a year of records:

• personal best broken in September by....14 seconds....on half-marathon with 1h37'28" after failing a first time by 20 seconds in March
• personal best broken twice in the two marathons I ran. first in June, in Caen, after a very hard 8-week training and in difficult conditions (rain, wind, hard race profile) with 3h38'45". Then, I managed to run a stunning 3h33'35" in October in Val du Rueil (a small town in the Seine river valley). That one will be hard to break now.
• longest distance run, with the "80km" Paris Ecotrail run in March, in 11 hours
• great progress in my other "ultra" race (70km in November) which I ran in 8h22 instead of 9h15 last year

I ran 10 official races during the year : two "ultra" races (70km Le Puy-Firminy in November, by night and 80km Paris Ecotrail in March), two marathons (Caen and Val de Rueil), four half-marathons and two "short" (less than 30km) trail races. How about next^W this year? Well, my goals are currently being secured:

• more trail races than roads races
• Paris 80km Ecotrail again in March. Goal: beat last year's 11 hours
• Le Puy-Firminy 70km again in November. A very nice "small" race (small by number of participants....but the effort is not small!).
• Mont-Blanc "marathon" in late June. Indeed a 42km trail race in Chamonix, starting at 1000m, finishing at 1600m, with a peak at 2300m and 2500m positive vertical gain (1490m negative).
• Another "long" trail race (40-60km) somewhere in April/May
• A "classic" marathon in October/November. Probably somewhere in France. Maybe La Rochelle. That might be the only classic marathon I run this year...unless I decide for another challenge like running two marathons in two consecutive Sundays..:-)
• Do once again my own personal marathon which is just "come back from work by foot".....which nearly equals the distance of a marathon. Something I achieved for the first time in September, in about 5 hours
• Maybe try a 6 or 12 hour race (running for 6 or 12 hours...or more...on a small 1-2km loop). These ones are very friendly ones and the only races where lame runners like me can run along with the best ones, not only for the first 100 meters.

All this of course is assuming that no injury comes up (my ankles are sometimes yelling outbut I'm fortunate enough to not have articulation problems that many runners have, particularly in knees). We'll see on January 1st 2014...:-)

Review: City of Diamond, by Jane Emerson

Publisher:	DAW
Copyright:	March 1996
ISBN:	0-88677-704-6
Format:	Mass market
Pages:	624

The setting is deep into the star-faring future of humanity. Humans have settled many other worlds, thanks largely to technology from a race named the Curosa. There is a thriving network of settlement based around a sort of warp conduit network. But, standing apart from most human settlements, are three huge ships: the City of Opal, the City of Pearl, and the City of Diamond. Their inhabitants are devout members of the Redemptionist faith, a merging of Christian (primarily Catholic) belief and Curosa religion. Their ships are gifts from the now-departed Curosa, featuring drives unknown to the rest of humanity that allows them to ignore the normal transport network. They are meant to witness and spread their religion, but now, six centuries later, they primarily trade. Much of this is not apparent at the start. City of Diamond opens with Adrian Mercati, chosen heir of the current dying Protector, dodging people in what seems to be an oddly-organized city. Impudent, occasionally flippant, utterly charming, and in love with danger, he inherits the position of Protector shortly after we meet him. Emerson slowly reveals more of the nature of the ship while Adrian is shocking (and charming) the nobility and the church, and consorting with demons. Or, at least, one demon: Tal, an entirely human-appearing creature except for his eyes, who the Redemptionists claim is born without a soul. Slowly, it becomes clear that he's actually the offspring of an alien and a human, a mating of species whose children cannot socialize as human and behave in ways that seem like human sociopaths. Tal is no exception, but his interests align with Adrian's for the time. To those two viewpoint characters, Emerson adds four more: a low-rank administrator named Spider who works for Tal after Tal saved him from death by recycling, Adrian's politically-arranged bride-to-be from the rival (and even more religious) ship City of Opal, a guard from a French-descended slum on City of Opal, and a dangerously honorable and literal mercenary from an off-shoot culture of humanity that's now only a legend. This is a book that tends to sprawl. There's quite a lot going on, starting with the negotiations between City of Diamond and City of Opal to put to rest the remnants of a civil war and leading to the search for a legendary Curosa artifact on the planet they're both visiting. All of the characters have their own agendas, their own history, and their own goals, and are pursuing them in parallel and occasionally in opposition. Emerson takes the time to let all of this build. Despite that, there is very little in this book that drags or bores, and that's due primarily to the strength of the characters. Every one of the viewpoint characters is unique, bringing a different perspective to the story, and every one of them changes and grow over the course of the story. They also play off of each other in delightful ways. This is a book that makes full use of the fact that three characters make seven character interactions. For example, Tal by himself is logical but just slightly askew, Tal seen by Spider is uncomfortable and worrisome, Tal and Adrian is a dance of mutual amusement and respect, and Tal and Keylinn finding points of commonality is just delightful. I did wish that there was a bit more Keylinn and Tal and a bit less of Spider, but once Emerson built her world, introduced her characters, and got the story moving, there aren't many weak pieces. Part of the fun is figuring out the world background. There are almost no infodumps here; Emerson just starts telling stories of characters in the surroundings in which they find themselves, and the reader is left to piece things together from background description, the occasional explanation from one character to another, and parallels with long-standing SF tropes. It's not a puzzle book, but it is a book of where the reader is dropped as an alien into a fully-developed culture. In both that way and in the use of nobility, religion, and formal hierarchy against a starfaring backdrop, City of Diamond reminds me of the sort of classic space opera that led up to Star Wars but isn't seen as much these days. It's also funny. I was unsurprised to discover that Emerson is a pseudonym for Doris Egan, who (in addition to writing some other SF) is an occasional writer and producer for House. The humor isn't entirely obvious at the start, although Adrian frequently provokes a grin from the start of the book, but Tal's perceptive but obliviously blunt comments become more and more fun as the book progresses, and both Iolanthe (Adrian's bride) and Keylinn (the mercenary, sort of) are a delight. I want to see more of both of them, but sadly the book ends just as they (particularly Iolanthe) are hitting their strides. And that's the biggest problem with City of Diamond: it's a failed (or at least postponed) trilogy. As with Walter Jon Williams's Metropolitan and City on Fire, there were supposed to be more books, but apparently either the publisher lost interest or other projects took precedence. The story does come to something of a conclusion, but most of the major story arcs aren't resolved. Emerson is still bringing more guns onto the set late in the book. None of the villains truly get their just desserts, nor do most of the character arcs fully resolve, although friendships and more have formed satisfyingly by the end of the book. There is obviously far more to both these characters and this universe, including an entire ship that was never visited and an alien whose presence should prove startling. This is a great book: warm, funny, full of interesting characters, and with a nicely complex background universe. If it were complete in itself, or if the sequels had materialized, I would recommend it unreservedly. As is, you will have to weigh your dislike of unfinished stories against its stand-alone merits. But I enjoyed it a great deal. Rating: 7 out of 10

One things I never quite got around to during 2012 was to blog about the awesome relay we ran in early June. This was the race formerly known as MC200 (for Madiston, WI, to Chicago, IL, by way of Milwaukee, WI, for about 200 miles) and is now part of the Ragnar Relay series: Ragnar Chicago. We ran as a so-called ultra team of six runners, as opposed to a regular ream of twelve. The course is cut into 36 segments; on regular teams you get 3, we each had twice that. My first leg was a combined 17 miles in what turned out to be pretty blistering heat in mid-to-late afternoon. My fellow team members were awesome in getting me lots of water an ice, and I managed to hold onto a pace of just over 8 min/miles. One of the harder runs I've had. Next was a wonderful run pretty much exactly at midnight under starry skies---about seven or so miles followed by ten more miles the next morning. We ended up coming third (yay!) beating the next time by about six or seven seconds (!!) over a total time of 25 or 26 hours. It was hard. It was fun. It was exhilirating. It may also have broken me as I haven't really run much since. So good intentions for 2013: get back into the groove.

It was too much to hope for that all that testing would catch everything in a 4.00 release, but it's ironic that the main bug was a bug in one of the test cases! BlueT - Matthew Lien - found that one of the tests malfunctioned when Test::Warn was not installed. Since I was cutting a new release anyway, I also improved the README somewhat and added POD documentation to the example script. You can get the latest version from the Term::ANSIColor distribution page.

I finally published a short essay I wrote about a year ago: Freedom for Users, Not for Software. Anybody who has hung around the free software community for a while will be familiar with the confusion created by the ambiguity between "free as in price" versus "free as freedom." In the essay I argue that there is a less appreciated semantic ambiguity that arises when we begin to think that what matters is that software is free. Software doesn't need freedom, of course; Users of software need freedom. My essay looks at how the focus on free software, as opposed to on free users, has created challenges and divisions in the free software movement. The essay was recently published in Wealth of the Commons: A World Beyond Market and State, a book edited by David Bollier and Silke Helfrich and published by Levellers Press. The book includes essays by 73 authors that include some other folks from the free software and free culture communities along with a ton of people working on very different types of commons. My essay is short and has two parts: The first is basically a short introduction to free software movement. The second lays out what I see as major challenges for free software. I will point out that these are some of the areas that I am working most closely with the FSF who are having their annual fundraiser at the moment to support and build advocacy programs around.

January Started cycling again. By the end of the year I had done 2,300 miles. (Strava profile) February Private concert at the British Museum of Haydn baryton trios for the annual winding of the Thomas Tompion Mostyn clock. March Zadok Baroque premiere concert, East Sheen. (review) April Belsize Baroque concert, Bloomsbury. May Lute concert, Greenwich. June Left Playfire. July/August YCombinator, California. September Renaissance viol weekend, West Sussex. October Moved house. November Battersea Park 5K. Ran 200 miles this year. December Beethoven Triple concerto, Cambridge. (more)

This year, I've gradually realized that I no longer identify as a perl programmer. For a decade and a half, perl was the language I reached for to solve any problem that didn't have a good reason to be solved in some other language. Now I only reach for it in the occasional one-liner -- and even then I'm more likely to find myself in ghci and end up with a small haskell program. I still maintain plenty of perl code, but even when I do, I'm not thinking in perl, but traslating from some internal lambda calculus. There's quite a few new-ish perl features that I have not bothered to learn, and I can feel some of the trivia that perl encourages be kept in mind slipping gradually away. Although the evil gotchas remain fresh in my mind! More importantly, my brain's own evaluation of code has changed; it doesn't evaluate it imperatively (unless forced to by an appropriate monad), but sees the gesalt, sees the data flow, and operates lazily and sometimes, I think in parallel. The closest I can come to explaining the feeling is how you might feel when thinking about a shell pipeline, rather than a for loop. Revisiting some of my older haskell code, I could see the perl thinking that led to it. And rewriting it into pure, type-driven, code that took advantage of laziness for automatic memoization, I saw, conclusively that the way I think about code has changed. (See the difference for yourself: before after ) I hear of many people who enjoy learning lots of programming languages, one after the other. A new one every month, or year. I suspect this is a fairly shallow learning. I like to dive deep. It took me probably 6 years to fully explore every depth of perl. And I never saw a reason to do the same with python or ruby or their ilk; they're too similar to perl for it to seem worth the bother. Though they have less arcania in their learning curves and are probably better, there's not enough value to redo that process. I'm glad haskell came along as a language that is significantly different enough that it was worth learning. The deep dive for haskell goes deep indeed. I'm already 5 years in, and have more to learn now than I ever did before. I'm glad I didn't get stuck on perl. But I may be stuck on haskell now instead, for the foreseeable future. I'd sort of like to get really fluent in javascript, but only as a means to an end -- and haskell to javascript compilers are getting sufficiently good that I may avoid it. Other than that, I sense adga and coq beckoning with their promises of proof. Perhaps one of these years. Of course if Bradley Kuhn is right and perl is the new cobol, I know what I'll be doing come the unix rollover in 2038. ;)

Review: Wasted Heart, by Lynn Galli

Publisher:	Penikila
Copyright:	2010
ISBN:	1-935611-32-1
Format:	Kindle
Pages:	252

Austy is a lawyer working for the US District Attorney's office in Seattle. Six months ago, she moved there from Virginia, in large part because she fell in love with her best friend. Her married best friend. Now, she's trying (mostly unsuccessfully) to deal with the Seattle lesbian scene while becoming (successfully) the go-to lawyer for prosecuting cases with a substantial technology component. Two things are about to complicate that life: meeting and working with FBI special agent Elise Bridie, and working on a case that involves her best friend's company. Yes, that best friend. This is, as you might have guessed, a lesbian romance novel, so with that should come my "reading out of genre disclaimer": it's rather easy, when reading a genre one normally doesn't read, to find books fresh and interesting when they're unoriginal to regular genre readers, or to miss genre conventions or reactions because one has not read the previous work. You should therefore take my opinions with a grain of salt, particularly if you read more romance novels than I do (which wouldn't be hard). I grabbed this book for a few reasons: I felt like reading a warm-hearted story focused on human relationships, I wanted a reasonably fast read (since I'm obsessed with meaningless numeric milestones, like how many books I read in a year), and I wanted something with an upbeat ending. Romance generally delivers on those fronts. Lesbian romance has the added bonus of avoiding a whole bunch of gender essentialism and heterosexual romance tropes that tend to give me hives. Landing was excellent, so I thought I'd see if I could find more of that. Wasted Heart does indeed deliver, although it's not quite as good as Landing. There's a bit too much physical attraction and love based on appearance for my taste, but Galli leavens that with quite a lot of interesting psychology. Both Austy and Elise are private and cautious people, and for me that makes the romance feel more realistic. It also draws out the initial phase of getting to know the other person, which is the part of the romance that I often find the most interesting. Elise in particular is a great character maybe a little too ideal in a few places, but smart and observant in a way that's very fun to read about. Like a lot of romances, there is some annoying miscommunication and misunderstanding (predictably right around the height of the tension), but it's not quite as stupid as those problems usually are, and Galli doesn't drag it out until one starts wanting to hit the characters with blunt objects. As good or better is the community that surrounds the main characters. Galli has a full cast of believable and interesting characters, most notably including Austy's old gang from Virginia. The tensions between having a group of friends one cares about deeply, wanting to build a new life after making a major break and major decision but having difficulty sustaining that under the onslaught of those friends, and being easily tossed about by expressive and outgoing people when one is private and a bit quiet all play out here. And, refreshingly, without a lot of angst, and with quite a bit of intelligent introspection. Both Austy and her friends are smarter and more considerate than most of the characters I've seen in this sort of situation. Another good bit is the little pieces of legal drama. Galli doesn't neglect Austy's work life, and while this is certainly not a legal thriller or procedural, we do get some nice scenes of Austy doing her job. I love courtroom scenes, particularly ones (like these) that are more on the realistic side, so that was a nice bonus. Austy and Elise's jobs also lead to a somewhat predictable bit of drama, and I was a bit less enamored of that; the more I thought about it, the less well it hung together for me. But I did like that it stayed firmly on the realistic side, including a look at psychological aftereffects for real people rather than thriller protagonists. This is not the sort of book that I would tell someone to rush out and buy, but it met my criteria nicely and delivered just the sort of entertainment I was looking for. (And it's not particularly expensive on Kindle, at least in the US.) There was a bit too much focus on physical appearance and physical infatuation, and Elise might be just a little too perfect, but I enjoyed it. Note that I read the special edition, which includes a (much appreciated) epilogue that closes out the story. That seems to be the default edition for sale everywhere I look, but in case you see the older version, I recommend the special edition. Rating: 7 out of 10

hey, this week the list of RC bugs I touched is even shorter than in the last weeks:

• #692979 libimager-qrcode-perl: "libimager-qrcode-perl: expects older version of Imager than dependencies supply"
  manual close after successful binNUMs
• #696329 lemonldap-ng: "lemonldap-ng: CVE-2012-6426: SAML messages signatures are not verified"
  upload package prepared by xguimard to testing-proposed-update (pkg-perl)

A while ago I wrote a blog post debunking the idea that swap should be twice as large as RAM [1]. The issue of swap size has come up for discussion in a mailing list so it seems that it s worth another blog post. Swap Size In my previous post I suggested making swap space equal to RAM size for systems with less than 1G of RAM and half RAM size for systems with 2-4G of RAM with a maximum of 2G for any system. Generally it s better to have the kernel Oom handler kill a memory hungry process than to have the entire system go so slow that a hardware reset is needed. I wrote memlockd to lock the important system programs and the shared objects and data files they use into RAM to make it easier to recover from some bad paging situations [2], but even that won t always make it possible to login to a thrashing system in a reasonable amount of time. But it s not always good to reduce swap size. Sometimes if you don t have enough swap then performance sucks in situations where it would be OK if there was more swap. One factor in this regard is that pages mapped read-only from files are discarded when there is great memory pressure and no swap space to page-out the read-write pages. This can mean that you get thrashing among memory for executables and shared objects while there s lots of unused data pages in RAM that can t be paged out. One noteworthy corner case in this regard is Chromium which seems to take a lot of RAM if you have many tabs open for a long time. Another factor is that there is a reasonable amount of memory allocated which will almost never get used (EG all the X based workstations which have 6 gettys running on virtual consoles which will almost never be used). So a system which has a large amount of RAM relative to it s use (EG a single-user workstation with 8G of RAM) can still benefit from having a small amount of swap to allow larger caches. One workstation I run has 8G of RAM for a single user and typically has about 200M of the 1G swap space in use. It doesn t have enough swap to make much difference if really memory hungry programs are run, but having 4G of memory for cache instead of 3.8G might make a difference to system performance. So even systems which can run without using any swap can still be expected to give better performance if there is some swap space for programs that are very inactive. I have some systems with as much 4G of swap, but they are for corner cases where swap is allocated but there isn t a lot of paging going on. For example I have a workstation with 3G of RAM and 4G of swap for the benefit of Chromium. Hardware Developments Disk IO performance hasn t increased much when compared to increases in RAM size over the last ~15 years. A low-end 1988 era hard drive could sustain 512KB/s contiguous transfer rates and had random access times of about 28ms. A modern SATA disk will have contiguous transfer rates getting close to 200MB/s and random access times less than 4ms. So we are looking at about 400* the contiguous performance and about 10* the random access since 1988. In 1988 2MB was a lot of RAM for a PC, now no-one would buy a new PC with less than 4G so we are looking at something like 2000* the RAM size in the same period. When comparing with 1993 (when I first ran a Linux server 24*7) it was 4M of RAM, maybe 15ms random access, and maybe 1MB/s contiguous IO approximately double everything I had in 1988. But I ll use the numbers from 1988 because I m more certain of them even though I never ran an OS capable of proper memory management on the 1988 PC. In the most unrealistically ideal situation paging IO will be a factor of 5* more expensive now relatively than it was in 1988 (RAM size increase by a factor of 2000 divided by contiguous IO performance increase by a factor of 400). But in a more realistic situation (random IO) it will be 200* more expensive relatively than it was. In the early 90s a Linux system with swap use equal or greater than RAM could perform well (my recollection is that a system with 4M of RAM and 4M of active swap performed well and the same system with 8M of active swap was usable). But nowadays there s no chance of a system that has 4G of RAM and 4G of swap in active use being usable in any way unless you have some corner case of an application allocating RAM and not using it much. Note that 4G of RAM doesn t make a big system by today s standards, so it might be reasonable to compare 2M in 1988 to 8G or 16G today. But I think that assuming 4G of RAM for the purpose of comparison makes my point. Using Lots of Swap It is probably possible to have some background Chromium tabs using 4G of paged out RAM with good system performance. I ve had a system use 2G of swap for Chromium and perform well overall. There are surely many other ways that a user can launch processes that use a lot of memory and not use them actively. But this will probably require that the user know how the system works and alter their usage patterns. If you have a lot of swap in use and one application starts to run slowly you really don t want to flip to another application which would only make things worse. If you use tmpfs for /tmp then you need enough swap to store everything that is written to /tmp. There is no real upper limit to how much data that could be apart from the fact that applications and users generally don t want to write big data files that disappear on reboot. I generally only use a tmpfs for /tmp on servers. Programs that run on servers tend not to store a large amount of data in /tmp and that data is usually very temporary, unlike workstation users who store large video files in /tmp and leave them there until the next reboot. Are there any other common corner cases that allow using a lot of swap space without serious performance problems? My Swap Space Allocation When I setup Linux workstations for other people I generally use 1G of swap. For a system that often has multiple users (via the user-switch feature) I use 2G of swap if it only has 3G of RAM (I run many systems which are limited to 3G of RAM by their chipset). For systems that I personally use I generally allocate 4G of swap, this is to cater to excessive RAM use by Chromium and also because I test out random memory hungry programs and can t easily predict how much swap space will be needed a typical end-user desktop system is a lot more predictable than a workstation used for software development. For servers I generally allocate 512M of swap space. That s enough to page out things that aren t used and make space for cache memory. If that turns out to be inadequate then it s probably best to just let the watchdog daemon reboot the system.

• [1] http://etbe.coker.com.au/2007/09/28/swap-space/
• [2] http://doc.coker.com.au/projects/memlockd/

For some time, I have been concerned about the amount of data I store on Google. This post aims to show alternatives to the service. This is primarily for two reasons. The first is simple. I would like to avoid a single point of failure, and the risk that I could be suspended for a number of months with no recourse. The second if more political. I'm worried about the way that certain governments can subpoena information which they may not be able to collect directly. Now, don't get me wrong. Google is good at transparency. They also provide a very useful service that works incredibly well. In fact, the quality of the integration and services provided is the primary reason I have not changed previously. Calendaring is something that I naturally feel shouldn't be hard, but somehow is. Google Calendaring service is rather good, and far outstrips anything open source I've found so far. However, I've managed to migrate to Zoho which offers a very similar level of functionality. It's also very easy to extract your entire calendar from Google, which makes the transition easier. Reader is a service provided to subscribe and read RSS feeds. In the past, I've used Gregarius as a self hosted solution, but this seems to have disappeared recently. I briefly flirted with NetVibes, which works well once you turn off the frustrating 'widget' mode, but has completely failed to address the need to have native tablet apps. In the end, I settled for NewsBlur which also has the clever use of hotkeys for navigation which I found essential in Google's products. Picasa has stood me well for hosting photos for some time. And photo hosting is something I have quite a large amount of professional experience with :) Despite having previously been in competition with them, I can heartily recommend Flickr, even with it's dogmatic reliance to creating a Yahoo! email address for each account. Search still has some way to go to find a viable replacement. I've tried DuckDuckGo, but found it lacking. Much like the mistake that Apple seem to have made with the launch of Apple Maps, there seems to be a misunderstanding that search is actually HARD.
There are two camps when it comes to searching. You can be dumb, or you can be smart. By being dumb, the user can provide enough information to help narrow the results down to a single (or at least manageable) result set. This works fine, and is a traditional model. The opposite is to be smart. Simply get the results right, using a variety of metrics to work out what the user wanted in the first place. This is obviously more difficult, but infinitely more valuable, and is something that Google excels at. The problem lies when you fall in between these stalls. Unfortunately, it seems that there is no viable alternative to the big G at the moment.

Installing an operating system When you want to install a new operating system, the first thing to do is to get an installer medium, which usually involves two steps: downloading an image, and writing it to a medium. There are two major types of media usable for that purpose: optical discs and USB sticks. There used to be a third one, floppy disks, but it is no longer used, and it was conceptually very similar to USB sticks.Power-user If you are a power-user, you probably use USB stick, to be able to reuse them and because they are easier to carry. For you, writing an optical disc or an USB drive is almost the same:

$ wodim image.iso
$ dd if=image.img of=/dev/sdc

Regular user But what would you suggest to a normal user? USB stick? You should not: while it is technically much easier to write an USB stick (just copy blocks from the image to the peripheral file, without any need to use any specific function), desktop file manager make it much harder. Indeed, for a desktop user, burning an ISO image to an optical disk is quite simple: right-click on the image file and choose the burn option. But writing an image to an USB stick? There is no similar option, so that will involve calling a power-user friend, which will tell you to open a terminal and type dd if= . Moral

Power-users

Continue using USB sticks as installation media, but tell regular users to use optical discs until desktop file managers adapt.

Regular users

Use optical discs. If your computer does not have an optical reader, either invite a power user friend, or buy an USB optical reader.

Desktop developers

Please, fix that! Writing an image to an USB stick should not be harder than burning it to an optical disc! People are using more and more computers without an optical reader, and that situation is certainly not new, as it is only similar to that of the time when we were using floppy disks.