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...:-)

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.

Review: Countdown, by Mira Grant

Publisher:	Orbit
Copyright:	August 2011
ISBN:	0-316-20448-X
Format:	Kindle
Pages:	75

Countdown is a novella that tells the "origin story" of Grant's Newsflesh universe, the setting for Feed and sequels. It's the story of the initial creation of Kellis-Amberlee and the first zombie Rising, mixed with a small bit of backstory for the Mason family. There are two ways to read this novella that work. It's possible to read it prior to reading any of the Newsflesh books as a sort of teaser. It sets up the universe, shows the devastation of society, and raises the question of how society will respond. Alternately, and I think more effectively, it can be read as an appendix to the Newsflesh trilogy that fills in the backstory. Reading it after all three books led to some fun moments of "oh, that's how that happened." It shows the accidents and bad decisions that led to the Rising, and provides a bit of a counterbalance to some of Georgia and Shaun's snarky comments about the government, scientists, and the media. The way to read it that doesn't work is to try to read it as a stand-alone work. Countdown has very little in the way of a story. It's told in the disaster epic style of brief scenes following numerous characters, some who are only seen once. There are small plot arcs following the Kellis virus, the Amberlee virus, and the Masons, but none of them are satisfying when read as a traditional story. Some events, particularly in the Masons' thread, have no real meaning by themselves and only acquire significance as part of Georgia and Shaun's backstory. The reason to read this novella is because you're invested in the universe, either to whet your appetite for more or to fill in some of the background. With that caveat, I think Countdown is more effective as horror than the Newsflesh trilogy itself is. Feed and its sequels are more action novels that become political thrillers, and the confident first-person narration and snark undermines most of the sense of dread or horror in the world. (Please note: not being a horror fan, I consider this a feature.) Countdown doesn't have that strong narrative presence. Instead, it covers events that are both horrific and inevitable and towards which the characters are largely helpless. Some of the scenes towards the end are haunting. Grant still isn't very subtle, but I think she does a good job writing quiet desperation and leaving some of the emotions for the reader to interpolate. Countdown could be read after Feed, if you're interested enough in the world to want more, but I think it works best after Blackout (for reasons that are minor spoilers). It could be read before the whole series, but I recommend reading it as an appendix instead. Don't expect too much of it it's background filler rather than more story but I thought it was effective and enjoyed the additional filling-in of the world. Rating: 7 out of 10

Review: Blackout, by Mira Grant

Series:	Newsflesh #3
Publisher:	Orbit
Copyright:	2012
ISBN:	0-316-20218-5
Format:	Kindle
Pages:	631

Blackout is the third book in the Newsflesh series that started with Feed. As with the second book, Deadline, you do not want to read this book out of order. All the emotional heavy lifting is done in Feed, and the book won't mean as much without that. Also, as with Deadline, be very careful about any information you read bout the sequels if you've not yet read Feed, since it's very easy to spoil that book and most information about subsequent books will do so. I'm going to try to write this review without spoilers. That's going to be a bit tricky due to events in Feed, so bear with me if I'm less specific than normal. This is the grand finale of the series, and it is a firm conclusion. As you might expect, particularly from Deadline, that involves a lot more politics, a few more big revelations, some reunions, escalating scale, and a lot of fighting. Unfortunately, it also involves setup. A lot of setup. I didn't expect that, given that Deadline ended at a run, but it takes about half of Blackout and a whole lot of pages before we get to the events that logically follow from the end of Blackout. And those pages dragged for me. There are some great moments. The banter continues to be strong, there are some deeply affecting scenes with Shaun, and Maggie continues to be wonderful. Grant also introduces some new secondary characters (Monkey and the rest of his household) who are brilliant and feel like they could have come directly from Borderlands. All of Blackout has a bit more of that mad scientist feel, full of slightly deranged people who take the fight to the world in their own ways. But it still drags. One branch of the book has the protagonists going here, there, and everywhere in several roundabout attempts to advance the plot. The other branch is more psychologically tense, but it takes too long to get moving and therefore turns into a repetition of the same emotions and the same complaints. I wanted to get to the key events that happen about halfway through the book in about half as many pages as they took. Thankfully, things do pick up when the two strands of the book come together. Some of the emotional dynamics strengthen as well, which I'd been missing. Grant does a great job here tying the whole series together in a way that shows the differences between Feed and Deadline and digs into their nature a bit more. There is one big reveal that I found disappointing, both because it had been obvious since early in Deadline and yet was treated as a big reveal and because I think it put the book and series onto slightly more conventional territory in a place where it had previously been interestingly distinct. (I'm being vague because of spoilers.) But that didn't bother me too much, and the surrounding character dynamics I think made up for it. The final ending isn't exactly bad, but neither did it entirely work for me. The whole series seems a touch too naive. This worked in Feed (at least for me; some other reviewers disliked it) since the naivete felt like part of the dynamic of the story and the characters, and the stakes were mostly kept small enough that it was believable. The stakes are large enough here that I needed the world to be a touch more complicated and the villains less hissable. (If there's been one consistent flaw throughout this series, it's that Grant's villains are too purely evil.) And, in the end, I didn't quite buy the conflict at the heart of the story; after everything that had happened, I wanted something more complex and nuanced. I'm a bit unsatisfied, but, like Deadline, Blackout is still a good book. Neither of them live up to Feed, but they're both enjoyable, action-filled, and creative looks at a zombie apocalypse. I think Blackout is at its best when it's being Fallout or Borderlands and emphasizing the mad scientist angle of Grant's world, and I would have happily read several more chapters about Monkey. The mix of wacky risk-taking and serious political idealism doesn't quite gel, and the latter never worked for me in Blackout, but I still had a lot of fun with the core character interactions. If you read Deadline, you certainly want to read Blackout. If you stopped at Feed, Blackout is probably not a persuasive argument to continue. Rating: 7 out of 10

The Microsoft Surface is a fairly attractive bit of tablet hardware, and as a result people have shown interest in running Linux on it. The immediate problem is that (like many ARM devices) it has a locked-down firmware that will only run signed binaries - unlike many other ARM devices, this is implemented using an existing standard (UEFI Secure Boot). Microsoft provide a signing service for UEFI binaries, so it's tempting to think that getting around this restriction would be as simple as taking an existing Linux bootloader, signing it and then booting. Unfortunately Microsoft's signing service signs binaries using a different key (the "Microsoft Windows UEFI Driver Publisher" key) to the one used to sign Windows, and the Surface doesn't carry that key. Booting Linux on these devices would involve finding a flaw in the firmware and using that to run arbitrary code.

Could this also be a problem on x86? In theory - Microsoft don't require that vendors carry the driver publisher key, and so a system could be Windows 8 certified and still not carry it. It's unlikely to occur in practice, though, since any third party expansion hardware will then fail on that device. As a result, anything with PCIe or Expresscard slots is effectively certain to have this key. If anyone finds any counterexamples, please let me know.

comments

I recently had a chance to briefly play with the new Samsung Galaxy Camera [1]. The Galaxy Camera is an Android device with a 4.8 display (the same size as the Samsung Galaxy S3) that has a fairly capable camera (IE nothing like a typical phone camera). It runs Android 4.1 (Jelly Bean) and the camera has 21* zoom with a 16 megapixel sensor. Camera Features It seems that professional photographers are often annoyed when they see someone with a DSLR set in auto mode. It s widely regarded that auto mode is a waste of a good camera, although the better lenses used with DSLRs will usually give a better result than any compact camera even when it s in auto mode. The problem is that photography is quite complex, in an earlier post about digital cameras I summarised some of the technical issues related to cameras and even without any great detail it became a complex issue [2]. The Galaxy Camera has a reasonably friendly GUI for changing camera settings which even includes help on some of the terms, I expect that most people who use it will end up using most of the features which could make it a good training camera for someone who is going to move to a DSLR. A DSLR version of the Galaxy Camera could also be an interesting product. The camera also has modes such as Waterfall and Panorama , hopefully the settings for those would be exposed to the user so they could devise their own similar groups of settings. I ve seen the phone criticised for the lack of physical controls as the expert mode in software is inherently slower than manually turning dials on a DSLR. But it seems obvious to me that anyone who knows how to use the controls manually should be using a DSLR or bridge camera and anyone who doesn t already know how to do such things will be better suited by the software controls. It supports 120fps video at 720*480 resolution (with a file format stating that it s 30fps to give 1/4 speed) which could be useful. I used to have a LG Viewty smart-phone that did 120fps video but the resolution was too low to be useful. 720*480 is enough resolution to see some detail and has the potential for some interesting video, one use that I ve heard of is filming athletes to allow them to analyse their performance in slow motion. It also does 60fps video at 720p (1280*720) resolution. One down-side to the device is that the lens cover doesn t seem particularly sturdy. It s quite OK for a device that will be stored in a camera case but not so good for a device that will be used as a tablet. I didn t get to poke at the lens cover (people don t like it if you mess with their Christmas presents) but it s design is a couple of thin flaps that automatically retract when the camera is enabled which looks quite weak. I d like to see something solid which doesn t look like it will slide back if the device is treated as roughly as a phone. I think that the lack of a solid lens cover could be the one factor that prevents it from being used as a replacement for a smart phone. Apart from that a Galaxy Camera and a cheap GSM phone could perform all the functions of a high end phone such as the Galaxy S3 while also producing great pictures. It would probably make sense for retailers to bundle a cheap phone with a Galaxy Camera for this purpose. Tablet Features The device boasts WiFi Direct to allow multiple cameras and phones to talk to each other without a regular WiFi access point [3]. I didn t test this and I don t think it would be particularly useful to me, but it seems like a handy feature for less technical users. It can connect to the Internet via Wifi or 3G, supports automatic upload of pictures (it comes with Dropbox support by default like the Galaxy S3), and has a suite of photo and video editing software. I don t expect that any photo editing software that runs on an Android device would be much good (I think that you really need fine cursor control with a mouse and a high resolution screen), but it would probably be handy for sending out a first draft of photos. Most Android apps should just work, the exceptions being apps that rely on a camera that faces the user or full phone functionality. So the Galaxy Camera can do almost anything that an Android phone or tablet can do. Value The RRP for the Galaxy Camera is $599, that puts it in the same price range as a DSLR with a single lens. While that s not a bad price when compared to smart-phones (it s cheaper than the LTE version of the Galaxy S3 phone) it s still quite expensive for a camera that s not a DSLR. Fortunately Kogan is selling it for $469 and has free shipping at the moment [4]. This still makes it more expensive than some of Bridge Cameras which probably have significantly better optical features, but in terms of what the typical user can do with a camera the Galaxy Camera will probably give a much better result. The sensor in the Galaxy Camera is smaller than that in the Nokia 808 PureView [5] (1/2.3 vs 1/1.2 ) so the Nokia PureView should be able to take better pictures in some situations. Unfortunately the Nokia 808 doesn t run Android, I d probably own one if it did. Some of the reviews are rather harsh, the Verge has a harsh but fair review by Aaron Souppouris which makes a number of negative comparisons to cheaper cameras [6]. I really recommend reading Aaron s review as there s a lot of good information there. But I think that Aaron is missing some things, for example he criticises the inclusion of ebook software by saying that he wouldn t read a book on a camera. But the device is a small tablet computer which also has a compact camera included. I can easily imagine someone reading a book or playing Angry Birds on their camera/tablet while in transit to where they are will photograph something. I can also imagine a Galaxy Camera being a valuable tool for a journalist who wants to be able to write short articles and upload pictures and video when out of the office. Aaron concludes by suggesting that the Galaxy Camera is a $200 camera with $300 of editing features. I think of it as $200 in camera hardware with software that allows less skilled users to take full advantage of the hardware and the ability to do all the software/Internet things that you would do on a $450+ smart-phone. Would I Buy One? No. The Galaxy Camera is among other things a great toy, I d love to have one to play with but I can t spare $469 on one. Part of the reason for this is that my wife just bought a DSLR and is getting lessons from a professional photographer, so I really won t get better pictures from a Galaxy Camera. The DSLR on auto mode will allow me to take pictures that will usually be better than a Galaxy Camera can achieve (sometimes you just can t beat a good lens). For more demanding pictures my wife can tweak the DSLR. The 120fps video is a really nice feature, I don t know if my wife s DSLR can do that, but it s a toy feature not something I really need. I ve just bought a Galaxy S3 which is a great little tablet computer (most of the time it won t be used for phone calls). I don t need another 4.8 tablet so a significant part of the use of the Galaxy Camera doesn t apply to me. I recommend the Galaxy Camera to anyone who wants to take good photos but can t get a DSLR and lessons on how to use it properly. But if you would rather get a 35mm camera with interchangeable lenses that runs Android then it might be worth waiting. I expect that the Galaxy Camera will be a great success in the market (it s something you will love when you see it). That will drive the development of similar products, if Samsung doesn t release a 35mm Android camera soon then someone else will (for example Sony develops both high end cameras and Android phones). If my wife didn t have a DSLR then I d probably have bought a Galaxy Camera already. I will recommend it to my parents and many other people I know who want an OK camera and can benefit from a tablet, but don t know how to use a DSLR properly (or don t want to carry a bulky camera).

• [1] http://en.wikipedia.org/wiki/Galaxy_Camera
• [2] http://etbe.coker.com.au/2011/08/24/digital-cameras/
• [3] http://en.wikipedia.org/wiki/WiFi_Direct
• [4] http://www.kogan.com/au/buy/samsung-galaxy-camera-ek-gc100-white/
• [5] http://en.wikipedia.org/wiki/Nokia_808
• [6] http://www.theverge.com/2012/12/3/3706206/samsung-galaxy-camera-review

I was happy to discover a few days ago that the Skolelinux / Debian Edu project also this year received a Christmas present from Another Agency in Trondheim. NOK 1000,- showed up on our donation account December 24th. I want to express our thanks for this very welcome present. As the Debian Edu / Skolelinux project is very short on funding these days, and thus lack the money to do regular developer gatherings, this donation was most welcome. One developer gathering cost around NOK 15 000,-, so we need quite a lot more to keep the development pace we want. Thus, I hope their example this year is followed by many others. :) The public list of donors can be found on the donation page for the project, which also contain instructions if you want to donate to the project.

Review: Perl Best Practices, by Damian Conway

Publisher:	O'Reilly
Copyright:	July 2005
Printing:	April 2011
ISBN:	0-596-00173-8
Format:	Trade paperback
Pages:	492

I had a rather bad first reaction to this book or, rather, the existence of this book. Some time ago, I started hearing about a new program named perlcritic that served as a lint program for Perl and decided to give it a try. I was taken aback by the flood of diagnostics, but even more taken aback by the fact that most of them were apparently explained only by a reference to a book that I didn't own. It struck me wrong in an open source project and gave me a negative reaction towards the book, which lingered for years. That was exacerbated by discovering that it recommended using use English in some circumstances, something that I consider to be a horrible idea. So, when a coworker recommended it and suggested I really should read it, I was dubious. I'm glad I gave it a chance, since it turns out that nearly all of my objections were based on misunderstandings or false information. (Well, except for the use English part, but more on that in a moment.) Perl Best Practices does provide a lot of advice, explaining that flood of diagnostics, but perlcritic also warns about the same thing repeatedly, inflating a handful of issues into a lot of messages. Most of the recommendations in Perl Best Practices were things I was doing already; most of the rest are entirely sensible. Also, perlcritic does come with complete explanations of its diagnostics once you know where they're hidden (the perldoc of Perl::Critic::Policy modules whose names you can get at by insisting perlcritic divulge them). And, even more delightfully, once I got past my objections, I discovered that Perl Best Practices is one of the best books on coding style that I've read. Coding style is a notoriously difficult subject, since nearly everyone is convinced their personal style is the best (or at least that they don't want to change). Conway acknowledges that up-front, and acknowledges that some things are just arbitrary and consistency with any rule set is better than following some specific rule set. He then spends surprisingly little time on the sorts of things that dominate most coding style discussions (indentation, spacing, commenting, etc.). Instead, this is primarily a book about how to write efficient and transparent Perl code, one that focuses much more on the content and structure of that code than on how it is indented. The best part is that there are no undefended rules here. Perl Best Practices contains 256 separate guidelines, some quite general ("Provide an optimal interface, rather than a minimal one") and some quite specific ("Pass constructor arguments as labeled values, using a hash reference"), but every one of them has a supporting argument and specific reasons behind it. Conway backs up every recommendation with code samples and practical scenarios showing the pluses and minuses of different approaches. This is a book unconcerned with being an authority; rather, it reads like optional advice from a good mentor, complete with insightful discussions on each point raised. You may come away from it disagreeing with Conway's specific recommendation (and I did, in several places), but you'll almost certainly be better-informed about the problem for having read it. Plus, this book is just fun to read. Admittedly, I love this sort of thing; I spend lots of time thinking about coding style in any language, and a lot more time refactoring coding style when working on my own projects to try to achieve clarity and simplicity. But even without sharing my love of the material, I think this book will be a delight for any practicing Perl programmer who hasn't yet read it. Conway clearly has a wealth of experience and years in the trenches of working with other people's Perl code. The examples he draws on are brief, comprehensible, and illuminating. He also gave me a tour of a variety of helper modules and libraries that I didn't know existed. List::Util is the most prominant example; this incredibly helpful supply of list manipulation functions that I've always half-known I wanted but never bothered to write is now part of Perl core (as of 5.7.3), so there's no reason to avoid it. You too can stop using grep when you actually mean first, or rewriting max in ad hoc ways. That does raise two of the rare flaws in this book, though. One is that I disagree (partially) with Conway's willingness to recommend non-core modules. He is a particular champion of the Readonly module over either normal file global variables or use constant, for very good reasons. But making Readonly a prerequisite for all other Perl code that one releases seems a bit annoying (speaking as someone who used to maintain local Perl installations). Maybe this isn't as big of a deal in these days of ubiquitous Linux distributions and willingness to use the CPAN shell, but I still dislike releasing code that depends on a half-dozen (or more) other CPAN modules for reasons of coding convenience and minor readability rather than core functionality. (His advocacy of Sub::Install raised similar objections.) The second flaw is not something Conway could have done anything about: this book is from 2005, and it's now 2012. Now, the Perl ecosystem is now quite mature, so that hampers the book much less than it would a corresponding book about Ruby or even Python. I also aim for compatibility with the oldest thing out there I know someone is still running, so I'm still hesitant to require anything newer than Perl 5.8. But still, this book was written seven years ago, and Perl is now at 5.14. In the meantime, we've seen core language features like given/when added, the addition of state variables, the need for substantial reworking of how Unicode I/O is handled, the addition of the new // operator, and the new package syntax, among many other things. The Perl taught here is a bit dated, and I would love to hear Conway's opinion about when (or if) to use say. Maybe someday we'll get a second edition. There are two other points that I do have to argue with. One is that Conway does advocate, in a limited way, use English. I could almost go along with his recommendation to use it only for those variables that one has to look up, except that in nearly every case there are other options and one can take the much better approach of simply not using those variables at all. But he then writes the remaining examples in the book using $EVAL_ERROR rather than $@, and I'm sorry, but no. One could not construct a more frustrating annoyance for an experienced Perl programmer than sending them on a futile hunt for where the global variable $EVAL_ERROR is defined. One can debate the merits of Larry Wall's original decision to use variables like $_, @_, $?, $!, and $?, but for better or ill this is Perl, and marginal readability gains for inexperienced programmers do not warrant confusing experienced programmers. This is particularly true when the use English variables are completely indistinguishable from normal global variables, and not infrequently look like a global variable that a programmer might choose. The second is more of an amusement that a real disagreement. Conway rightfully points out that Perl OO, and particularly the way that Perl stores object instance data, is awkward, and none of the commonly-used techniques are particularly satisfying. He then introduces a completely new way of doing instance data that, while having some advantages, has a very strange syntax and is utterly unlike how any OO code one finds in the wild is written. While the discussion of the problem that he's trying to solve is still interesting, I think the solutions he proposes will be more of a curiosity than a style that most programmers will adopt. But, those disagreements aside, I thoroughly enjoyed this book. I found it so engrossing that I kept reading it straight through a long train ride rather than switching to fiction halfway, like I do with most programming books. I've since recommended it to several other coworkers, and we're in the process of revising our internal Perl coding style based heavily on it. It's the sort of book that I expect to re-read several times to refresh my memory of Conway's analysis. If you've been avoiding this one due to misconceptions like I had, or because you think it might be too dry, or even just because you're afraid it's outdated, I strongly recommend it. If you're worried about the price of a printed (or electronic) book on this topic and you do Perl programming as part of your job, see if your employer will buy you a copy as training. It's worth it. I've been writing Perl professionally for more than fifteen years, and I learned a ton from this book. (And if it inspires you to change your coding style, take a look at perlcritic. It requires some configuration, and getting started is quite frustrating, but it reliably detects a surprisingly high percentage of the issues discussed here and can help a great deal in making the coding style shift stick until you can build new habits.) Rating: 9 out of 10

It's after Christmas, and some number of people doubtless ended up with Windows 8 PCs and may want to install Linux on them. If you'd like to do that without fiddling with firmware settings, here are your options.

• Ubuntu 12.10
  The 64-bit version of Ubuntu 12.10 ships with an older version of Shim that's been signed by Microsoft. It should boot out of the box on most systems, but it doesn't have some of the most recent EFI patches that improve compatibility on some machines. Grab it here.
  
• Fedora 18
  Fedora 18 isn't quite released yet, but the latest 64-bit test builds include a Microsoft signed copy of the current version of Shim, including the MOK functionality described here. Fedora 18 has some additional EFI support patches that have just been merged into mainline, which should improve compatibility on some machines - especially ones with Radeon graphics. It also has improved support for booting on Macs. You can get it here, but do bear in mind that it's a test release.
  
• Sabayon
  According to the wiki, Sabayon now supports UEFI Secure Boot out of the box. I don't know if the current CD images do, though. My understanding is that it's based on the Microsoft signed Shim I discussed here, and you'll have to manually install the key once you've booted the install media. Straightforward enough.
  
• Other distributions
  Suse will be using a version of Shim signed by Microsoft, but I don't think it's in any pre-release versions yet. Debian have just merged UEFI support into their installer, but don't have any UEFI Secure Boot support at the moment. I'm not sure what other distributions are planning on doing, but let me know and I'll update the list.
  
• The Linux Foundation loader
  The Linux Foundation have still to obtain a signed copy of their bootloader. There's no especially compelling reason to use it - the use case it supports is where you have users who can follow instructions sufficiently to press "y" but not to choose to enrol a key. The most interesting feature it has is the ability to use the MOK database via the usual UEFI LoadImage and StartImage calls, which means bootloaders like gummiboot work. Unfortunately it implements this by hooking into low-level functionality that's not actually required to be present, so relying on this may be somewhat dubious.
  

comments

I'm thankfully in a place where I can afford to give money to charity, and I've slowly built up a set of charities that I give money to. But I've never been that systematic about it. I've had a vague target for how much I want to give, I add new charities when they seem neat, I'll rarely drop a charity when it doesn't seem to be effective, and I probably spread my money out too much. Recently, I followed a chain of blog references and discovered GiveWell, a site that's devoted to doing more in-depth analysis of charities than the basic financial analysis done by sites like Charity Navigator. In particular, they do literature surveys to try to dig into the effectiveness of particular interventions and take a closer look at how effectively a charity can use new donations. After reading quite a bit on their site and some related sites, I sat down yesterday and did a comprehensive review of my goals and principles and then put together a new plan. Some of that may be interesting to other people, so I'll write up that process here. This will be somewhat US-centric, since charities vary a lot by tax regime, but I think some of the general principles will still apply elsewhere. (But most of my specific examples will be US charities.) First, a few basic principles about charitable giving:

1. Charity goals cannot be evaluated uniformly. Different types of organizations need different criteria. I've found that charities divide generally into ones that are trying to accomplish a specific task and ones that are trying to create political change. For the former, small and quiet organizations are often the best. For the latter, the charity has to get to a certain size before it's part of the conversation, and that involves a different set of tradeoffs.
2. When you care about efficiency (number of lives saved or quality of life improvement per dollar spent), don't give money to organizations you've heard about via means other than word of mouth or third-party evaluations. This is for a simple reason: if the charity has successfully made you aware of it, that means they're advertising themselves to you. Advertising generally costs quite a bit of money. That's money they're not spending on whatever they're trying to accomplish. Excellent examples are many of the health research and education charities, such as the American Heart Association and the American Lung Association, or the massive disaster relief organizations like the American Red Cross. These are not efficient organizations. If you're trying to get the most impact for your dollar, this isn't a good place to spend it. As a special case of this, please don't ever give money to any organization that produces TV commercials showing starving children in Africa. If the commercial makes you want to give money, that's great; just don't give it to the organization on TV. TV commercials are extremely expensive, and those organizations are notorious for being some of the least efficient charities in existence (in some cases bordering on scams). You'll be lucky if 50% of your money actually goes to Africa, and the money that is spent probably isn't spent wisely.
3. If your donation gets you a membership that comes with a glossy magazine, remember that means that the organization is spending your money producing that magazine. This is counted as program funding, not administrative costs, in sites like Charity Navigator because the charity probably counts the magazine as part of their educational mission. If you want to subscribe to the magazine and enjoy it, there's not necessarily anything wrong with this. But if you were giving them money to do something else, be aware that money is being used to produce the magazine (and the Christmas cards and the mailing labels and the tote bag) instead of doing things that you might consider program funding. For example, I stopped giving money to the Audubon Foundation because I want my environmental giving to go directly to protecting the environment, not towards printing calendars and making a glossy magazine full of bird pictures. As a counter-example, I consider the Southern Poverty Law Center to be one of the most effective US political charities, despite the fact that they produce a glossy magazine. That's because a large part of their mission is investigative reporting and research, and that magazine is how they publish that research. In this case, I both want to read the magazine and consider the magazine something that I'm happy to fund.
4. Efficiency isn't everything. For some types of charities, the charity has to be huge in order to be effective. This is particularly true of political charities. For example, the ACLU is not a particularly efficient charity and has several fund-raising practices that I dislike. However, what the ACLU does requires that they have extensive media access and respect from legislators and the judicial system. It cannot be done effectively by a smaller and more efficient organization. Similar principles apply to a lot of political and environmental charities, and to some international aid charities such as Doctors without Borders (M decins Sans Fronti res).

If you're looking to increase the efficiency and effectiveness of your giving according to objective measures, I highly recommend reading through GiveWell's site. They recommend charities that avoid all the pitfalls above. You've probably never heard of them because they don't spend their money on advertising and marketing. However, keep in mind that efficiency isn't everything. With those principles in mind, and after doing a lot of reading on GiveWell, I redid my charity plan by dividing my giving up into five categories with different goals. Services. There are some things that I use that I think should be paid for by tax dollars but aren't, and are instead funded by charitable donations. I don't consider this charity in the same sense as the rest of this list. Rather, I'm paying for what I use plus some extra so that other people who can't afford it can use the service for free. Efficiency doesn't matter as much because there's usually only one organization supporting the thing that I personally use. Examples include my local PBS (public broadcasting) station, the non-profit that works with city government to support the local library system, and the trust that helps maintain the state parks where I go on vacation. Education. This is a special category for me since I regularly give money to the community college I attended. I know the region and the college and have some idea of what they need and what matters to the students there, so I can make specific choices. I give all the money in this category to the same place. Free software. Here, I know that my donations won't be used as efficiently in terms of quality of life as they could be if sent somewhere else, but this is my community and I want to support it because it's my community. Here, as with education, I have a lot more data and can pick and choose places that I think can use my money. Examples here are the Ada Initiative and the Free Software Foundation. Politics. This is the hardest area for efficiency, since it's so difficult to measure effectiveness in any organization where much of the goal of the organization is to persuade politicians or the general public. I try to measure effectiveness by how many concrete actions the organization takes (rather than press releases), which is easiest for organizations like the ACLU or the EFF that file lawsuits or legal documents and requests. As mentioned above, I think the standout in this area is the Southern Poverty Law Center, but political charities are so targeted that I give to multiple charities to cover my range of interests. I've found environmental charities particularly difficult to evaluate, but the one that appears the most effective to me so far is the Environmental Defense Fund, so that's where I concentrate my environmental money. I used to give to small political charities but have given up on that as basically useless, at least for national politics. I think the charity has to be of a minimum size to get anyone in government to listen to them. Poverty and Health. This is where efficiency matters much more than size. GiveWell's analysis is very interesting here, and sadly shows that most interventions either don't work or at least can't be proven to work. Here, I abandoned nearly all of my traditional large charities and have gone almost entirely with GiveWell's recommendations, with two exceptions. I still cycle money through Kiva (a microfinance support charity) because I have a bit of an emotional attachment to it, although microfinance is looking increasingly suspect as an effective charity method and I may yet drop them. And I still give money to Doctors without Borders because, despite being less efficient, I think their size and history has won them an international credibility that lets them get into areas that smaller, more efficient charities wouldn't be able to help. One of GiveWell's recommendations is my new favorite charity: GiveDirectly. All aid charities run a serious risk of having a colonialist bent, where rich countries come into poor countries and build things or tell them how to do things following the priorities of the rich countries. (This is one of the reasons why I prefer medical charities, since they're less susceptible to this.) GiveDirectly identifies the poorest people in a region (using a very transparent process) and transfers money to them directly using the M-Pesa cell system to spend however they choose, with no strings attached other than some due diligence to protect against fraud. This is refreshingly non-paternalistic and makes me far more comfortable than typical aid projects. Originally, I was going to assign money into those buckets and then break the buckets down further, but I ended up not quite doing that. The services bucket is more driven by the services I use than by an even allocation. Of the rest, it goes approximately three shares to poverty and health, two to politics, and one each to education and free software. I think I've managed to eliminate most of the places where I'm giving money to multiple organizations that do the same thing, but I'm still spreading my money rather widely and could stand to focus it more. That's hard, though; there are a lot of different things that I care about, and political charities in particular aren't very interchangeable. I'm currently not giving locally very much, which might be worth changing. The easiest way to do so would be to find a good local food bank and start donating to them (giving cash, not food). For a more comprehensive list of charities I support, see my charities link page.

The vp8 video codec and webm container format (which are alternates for theora/ogg and h264/flv) are getting lots of attention, especially as more web browsers are supporting html5 - which includes a new video tag that plays video directly in a web page, rather than requiring a plugin. With Google fully behind these new formats (and converting YouTube videos) and even skype using vp8, it seems as though it could supplant h264/flash as the default video codec and container. After years under the boot of the proprietary flash video, this change could usher in a lot of exciting developments. While the shift in formats is also significant for on-demand video, I'm focusing on live streaming in this blog. There are a lot of tools needed to successfully stream a live video. Enough of them support vp8 and webm to create a live video stream, however, not all of the right versions of these tools have landed in Debian. Without any patches or changes, if you try to send a live video stream to icecast using vp8 encoding and webm, you'll get something like this:

0 jamie@animal:~$ gst-launch v4l2src ! video/x-raw,width=320,height=240 ! vp8enc ! webmmux ! shout2send ip=icecast.server port=8000 password=secret mount=/test.webm
WARNING: erroneous pipeline: could not link webmmux0 to shout2send0
1 jamie@animal:~$

I've documented the steps for patching/upgrading gstreamer and icecast2 so you can get a live video stream using vp8 encoding and the webmc container that originates on a Debian wheezy machine using gstreamer and streams to a Debian squeeze server running icecast2. On the workstation, you'll need libshout3 version 2.3.0 or higher, which is at the moment available in experimental and installable without bringing in any dependencies. In addition, you will need to bring in gstreamer1.0 from sid and you will need to rebuild gstreamer1.0-plugins-good after libshout-dev has been installed from experimental. So, begin by adding experimental and sid to your sources list by creating the files /etc/apt/sources.list.d/experimental.list and /etc/apt/sources/lists.d/sid.list with the respective contents:

deb http://mirror.cc.columbia.edu/debian experimental main

and

deb http://mirror.cc.columbia.edu/debian sid main 
deb-src http://mirror.cc.columbia.edu/debian sid main

In order to avoid upgrading your entire machine to sid (experimental packages won't upgrade by default), you'll also need to add the file /etc/apt/preferences.d/sid:

Package: *
Pin: release n=sid
Pin-Priority: 200

Then update and install:

apt-get update
apt-get install -t experimental libshout3
apt-get install gir1.2-clutter-gst-1.0 gir1.2-gst-plugins-base-1.0 gir1.2-gstreamer-1.0 gstreamer0.10-ffmpeg  gstreamer1.0-libav:amd64 gstreamer1.0-plugins-bad:amd64 gstreamer1.0-plugins-base:amd64 gstreamer1.0-plugins-base-apps gstreamer1.0-plugins-good:amd64 gstreamer1.0-pulseaudio:amd64 gstreamer1.0-tools gstreamer1.0-x:amd64 libclutter-gst-1.0-0:amd64 libgstreamer-plugins-bad1.0-0:amd64 libgstreamer-plugins-base1.0-0:amd64 libgstreamer-plugins-base1.0 libgstreamer1.0-0:amd64 libgstreamer1.0

Fortunately, the version of gstreamer1.0-plugins-good in sid includes a fix for a bug patched on November 31, 2012 that allows the use of the webm container. However, for it to work properly gstreamer1.0-plugins-good has to be built against libshout version 2.3.0 or higher (which is in experimental, not sid). Therefore, you have install libshout-dev from experimental and then rebuild gstreamer1.0-plugins-good.

sudo apt-get build-dep gstreamer1.0-plugins-good
sudo apt-get -t experimental install libshout-dev
apt-get source gstreamer1.0-plugins-good
cd gst-plugins-good1.0-1.0.4
dch -v 1.0.4-1+webmmux
fakeroot debian/rules binary
sudo dpkg -i ../gstreamer1.0-plugins-good_1.0.4-1+webmmux_amd64.deb

Now if you try the command, things should work on the client side. When streaming to an icecast2 server running squeeze, I don't get any errors, however, when opening the streaming page via the icecast URL, there is a play button, which can be clicked, but no picture is shown. That's because the version of Icecast2 in squeeze doesn't support either vp8 or webm. On the server side, you will need icecast2 version 2.4beta or higher. This version hasn't landed anywhere in Debian as of this writing. However, you can build it from source by following these steps (the patches I'm removing have all been applied to the new upstream version).

apt-get source icecast2
wget http://downloads.xiph.org/releases/icecast/icecast-2.4-beta.tar.gz
tar -xzvf icecast-2.4-beta.tar.gz
cp -r icecast2-2.3.2/debian icecast-2.3.99.0/
cd icecast-2.3.99.0/
rm debian/patches/ 1001_autotools_avoid_debian-subdir.patch,1002_add_missing_xspf_file,1003_fix_memory_leak.patch,series 
dch -v 2.3.99.0-1
fakeroot debian/rules binary

When you install it, be sure to replace the icecast2.xml configuration file and update it with your server-specific customizations. Hopefully this version of icecast2 will make it to experimental soon. And now... you can successfully stream via:

gst-launch-1.0 v4l2src ! video/x-raw,width=320,height=240 ! vp8enc ! webmmux !  shout2send ip=icecast.server port=8000 password=secret mount=/test.webm

If you want full audio and video, here's a more complete pipeline: gst-launch-1.0 v4l2src ! queue ! video/x-raw,width=320,height=240 ! tee name=tscreen ! queue ! autovideosink tscreen. ! queue ! videorate ! video/x-raw,framerate=25/2 ! queue ! vp8enc ! queue ! webmmux name=mux pulsesrc ! queue ! audioconvert ! vorbisenc ! queue ! queue ! mux. mux. ! queue ! shout2send ip=hobo port=8000 mount=jamie.webm password=secret Unfortunately, since I'm not sure how to deal with the python2.7 vs python3 dependecies, my elegant mobi python script that creates this pipeline for you using python-gtk as been reduced to a crude bash script. Another item on the todo list is opus audio encoding. gstreamer doesn't seem able to use opus in the webm container (although it seems to work with ogg). In the course of this research I found directions for getting gstreamer-1.0 installed on debian independent of packages installed on the system. If you follow the directions above, these steps should not be necessary. I'm including in case you need the latest sources for another reason. Extra steps I needed were:

• Edit gst-rebuild, comment out gst-plugins-ugly from plugins var (line 14) and sources arg (line 14) - these caused errors for me.
• manually install the following packages from experimental (apt-get build-dep gets confused about how to find them):
  • apt-get install -t experimental libavcodec-dev=6:9~beta3-1
  • apt-get install -t experimental libavformat-dev=6:9~beta3-1
  • apt-get install -t experimental libswscale-dev=6:9~beta3-1 libswscale2=6:9~beta3-1
• Then follow directions as advertised

Review: Science Fiction: The 101 Best Novels: 1985 2010, by Damien Broderick & Paul Di Filippo

Publisher:	Nonstop
Copyright:	2012
ISBN:	1-933065-39-7
Format:	Trade paperback
Pages:	288

I like book reviews and lists of best novels, as a follower of my reviews probably noticed, so I couldn't resist when this collection made my radar. A follow-up to the earlier Science Fiction: The 101 Best Novels: 1949 1985 by David Pringle (which I have not read), it is a collection of short (two to three pages, generally) reviews of 101 recent SF novels. The date spread is fairly balanced: at least two novels from each year under consideration are featured, and no year gets more than seven or eight. The authors also clearly tried to cover the range of what falls under the science fiction genre, from alternate history through space opera and including novels normally marketed as mainstream, so the result should contain something to everyone's taste. With those characteristics, you may suspect that the "best" part of the title is a bit questionable, and you would be right. "101 of the better novels" would be a more accurate description. While most Hugo and Nebula winners are included here, the section is at times eclectic. But it's eclectic in the spirit of broad inclusiveness: Jumper, Temeraire, or The Hunger Games would normally not be included on this sort of list because they're too popular or "light," but they're here alongside more obscure books (at least for SF readers) like Galatea 2.2, Distance Haze, or My Dirty Little Book of Stolen Time. I doubt anyone will seriously argue that this selection should have replaced the Hugo or Nebula short lists, but one doesn't read review collections like this only to hear about books one already knows about. Those books one has either already read or already chosen not to read. The wide-ranging selection makes it likely that something here will be new to most readers. The authors, Damien Broderick and Paul Di Filippo, are known reviewers in the SF world, and I've read reviews from both of them before. I bought this book largely on the strength of Broderick's name, since I've usually enjoyed his contributions to The New York Review of Science Fiction. Paul Di Filippo was more of a gamble; he's one of the regular reviewers for Asimov's Science Fiction and not one of my favorites. But what I usually disliked about his columns was their focus on obscure small-press titles, graphic novels, and slipstream, so I was hoping that an SF review collection aiming towards the genre mainstream would be more to my taste. The result is mixed. There are things about this selection, and about the reviews, that I enjoyed, and there are other things I found quite annoying. First, the selection. I could (and will in a moment) talk about good and bad selections, but I also have a good statistical metric for at least the alignment of the authors' taste with mine. Of the 107 novels reviewed here (in several case, duologies and trilogies are given single entries), I've read 39, or a little over a third. (Note that I've read every Nebula or Hugo winner in that time period and most of the Hugo nominees, so that will give you a good feel for how broad-ranging this selection is, and how far afield of the normal award slates it goes.) My average rating for those 39 books was 7.49 (including four perfect 10s). By comparison, my average rating for Hugo winners is 6.68 and for Nebula winners is 7.10. There was one 4 (The White Queen) and one 5 (Red Mars), and in both cases I can see why they're here. Of the rest of the books I read I rated them all at least at 6 out of 10. At least among the books I've read, this seems to be a solid selection. Sometimes the details of those selections are odd, though. For example, the authors make an effort to limit the number of selections for each author, a wise choice since they're clearly going by diversity. But if one is operating within that limitation, choosing Ammonite over Slow River for Nicola Griffith, or particularly Ventus over Lady of Mazes or even Permanence for Karl Schroeder, is baffling. There were several similar places where I thought the selection for an author was obscure, minor, or just missed obvious alternatives. Perhaps this was to fill in one of the other breadth criteria, such as balancing number of novels per year or attempting to cover each subgenre. Also, if one is going to divide science fiction and fantasy and try to cover only the science fiction (a division that I think is quite difficult, which is why I don't do it, but it does have the merit of narrowing the field), including The Falling Woman is quite strange. It's a solid book, to be sure, and a Nebula winner. It is also quite straightforward contemporary fantasy involving ghosts and Mayan mythology, without a hint of science-fictional content. Making the protagonists archeologists and scientists doesn't make the book science fiction. The authors try to defend this (unpersuasively to me), but it wasn't the only instance here where I thought their line between science fiction and fantasy was a bit off. That said, there are a lot of great selections here, including books that I love but that aren't frequently picked for this sort of list (The Fortunate Fall, The Time Traveler's Wife, or China Mountain Zhang, for example). It's great to see underappreciated authors like Linda Nagata, Joan Slonczewski, and Karl Schroeder featured. But, of course, one doesn't buy this sort of book just for the list, if for no other reason than that lists aren't copyrightable and one can easily find the complete list of reviewed novels on the Internet (just one example that turned up in a search). Rather, one reads this sort of book for the reviews. And that's where this book moves onto more questionable ground. First, while I realize that everyone has different thresholds for what they consider spoilers and most professional reviewers are more cavalier about them than I am, Broderick and Di Filippo cross any line that I consider reasonable. Most of the reviews are okay, if skirting the limits, but in several places they give away key reveals of books or discuss plot twists right up to, or even including, the ending. The combined review of The Sparrow and Children of God is particularly egregious, containing unambiguous, book-destroying spoilers for The Sparrow. Giving away the ending of Ammonite is only slightly less bad. And those are just two examples I remember. This is not okay. The whole point of this sort of collection is to expose the reader to books they've not yet read but may want to. Proceeding to spoil the book for them in the course of the review is perverse. This alone would make me hesitant to recommend this collection. Second, quite a few of the reviews in this book are, for lack of a better term, emotionally overreaching. Here's an excerpt of a review picked at random (As She Climbed Across the Table by Jonathan Lethem) that will hopefully illustrate:

Lethem's beautifully balanced, metaphorically rich prose propels this blackly jolly fable to a surprising yet satisfying conclusion. By book's end, a sense that the author had accomplished his takeoff taxiing and was now fully in flight for more cosmopolitan cities pervades the pages.

What's "beautifully balanced prose"? Could you recognize it? Does that phrase communicate anything to you other than that the authors liked the book? The whole review collection is written with adjectives and metaphors like this, and after a while it all seems a bit much. It felt like the authors were straining for ways to describe how important or significant the books are and, in the process, lost sight of the basic goal of conveying information about the book. It feels overwrought rather than informative. Even if one is reviewing the books that one considers the pinnacle of achievement in science fiction, a conversational tone with concrete examples and specifics communicates more than impressive but slippery terms like "metaphorically rich." Lest I sound entirely negative, one thing that I did appreciate is that the reviews go to some effort (particularly for their short length) to put the work in the broader context of the field and within the author's oeuvre. Often there's some discussion of previous and subsequent work or related books, and the reviews that feature books from larger series provide good explanations for why those particular books were singled out. Sometimes the number of dangling references was frustrating; authors of these sorts of collections need to remember that most readers will not be as widely read, and reviewing books largely by comparison to other books runs the risk of missing the reader's knowledge entirely. But the reviews convey a real sense of SF as a broad conversation and provide a sense of the breadth and variety of themes and subgenres available. This is one of the fun explorations that this sort of catalog lets the authors and reader do together. Another, more minor, touch that I appreciated was the cover art. Each review leads with an image of the reviewed book's cover (alas, only in black and white for obvious printing reasons). But rather than taking the obvious approach of using the covers of the first releases, or the covers from a particular country, they're chosen from all of the world-wide editions in all their delightful variety. Typical artistic styles for book covers vary drastically between countries, and getting to see a sample of artwork from different markets is a treat. I want to recommend this book. It casts a much broader net than most collections of its kind and provides some needed attention to smaller corners of the genre. I was impressed by the book list before I bought it, and (with the inevitable quibbles) am even more impressed now that I've read it. Broderick and Di Filippo go out of their way to broaden the reader's horizon and open up new avenues for reading, which is one of the best things a review collection can do. But when reviewers don't avoid spoilers, I just can't recommend their work. For me, this is a cardinal sin. Combine that with a writing style that was occasionally overblown and overwritten and the merits don't quite overcome the flaws. I'm glad I read it; it got me excited about reading many books I've already purchased but not gotten to, and I got from it another slew of books to add to my to-purchase list. But I had to read it uncomfortably and lightly, constantly prepared to jump past a review that was too revealing. Rating: 6 out of 10

Review: Cry Wolf, by Patricia Briggs

Series:	Alpha and Omega #2
Publisher:	Ace
Copyright:	August 2008
ISBN:	0-441-01615-4
Format:	Mass market
Pages:	310

Cry Wolf is a sequel to the novella Alpha and Omega. This was originally included in the anthology On the Prowl, which I had no particular interest in, but it's now available as a standalone novella if you have an ebook reader. I recommend reading it first if you have any interest in this series; it's not particularly expensive, and piecing together what happened in it while reading the beginning of Cry Wolf is not particularly enjoyable. There are some mild spoilers for Alpha and Omega here, so if you're planning on reading the novella first, you may want to do that before reading on. Anna is an Omega, an extremely rare form of werewolf who does not fall into the normal pack hierarchy. With normal werewolves, either the wolf is dominant or is submissive, and the most dominant wolf leads the pack and can force their will on the other pack members. Omegas are strange. Normal pack dominance doesn't really work on them, but neither are they dominant themselves. At the start of Cry Wolf, Anna has very little idea what any of this means. She's been rescued from a horribly abusive situation and is being brought to Montana by Charles, the enforcer and son of the leader of all North American werewolves. And, apparently, her mate, according to both of their wolf natures, but she's not entirely sure what that means either. She doesn't have a lot of time to find out, since the local pack is immediately threatened by a rogue werewolf and she's pulled into both pack politics and that hunt. Cry Wolf, despite being the first full book of the Alpha and Omega series, is set in the same world as Briggs's Mercy Thompson series. (At a guess, somewhere around Iron Kissed.) This is not just a vague link within the universe, unfortunately. The characters here refer frequently to Mercy and previous events in her series in that way that implies the reader should have read them, without explaining fully what happened. If, like me, you're more interested in this series than the Mercy Thompson series (I preferred it because there are no vampires and I'm sick of vampires), be aware that starting here will feel like starting in the middle of a series. This will be even worse if you don't read Alpha and Omega first, making the first section of the book feel like constant namedropping when you don't know any of the references. The story, otherwise, is basically hurt/comfort with a side of coming of age. Whether you will enjoy this will depend on whether you're in the mood for a fairly predictable story that hits those buttons. Anna is a mess, thrown into survival mode after years of abuse and hating what she's become. (She is, actually, somewhat less of a mess than I think she should be given what happened to her, although Briggs has both her Omega nature and her wolf as outs there.) Charles wants to comfort her and isn't sure how. She misreads things, he misreads things, there's lots of missed communication... you've probably read this story before and have a pretty good idea how it will go. They are somewhat less stupid about their communication problems than the typical novel of this type, but they still don't use words very well. The rest of the plot felt like mostly an excuse to throw Anna and Charles together doing something external to their relationship and to give Anna a chance to use her unique talents. It takes a bit to get going, since most of the early book is introductions and setting up all the connections to the Mercy Thompson stories, but there is some meat to it, including fleshing out the mythology of werewolves in Briggs's world. (And some passable descriptions of Montana wilds.) I'm not a big fan of how power struggles and combat seem binary and very hierarchical, but that seems to be the way that Briggs differentiates her werewolves, and it does form a sharp contrast with Anna's ability. I think Omegas could have been even more subtle than they are here, but the interplay between the conflict-driven approach of everyone else and Anna's inherent calm can be fun. The biggest problem I had with Cry Wolf, apart from the general predictability of the story and relationships, is that the hurt/comfort angle never felt adequately resolved. Hurting a character very badly and then having others offer comfort is a very common story technique that brings with it some reader expectations in terms of emotional payoff. The point at which the comfort finally works can be very empowering and very affecting. I don't think Briggs hit the payoff as well as she could have. Anna recovers, but she does so rather more easily than felt correct, and without the emotional punch that I was waiting for. It seems odd to complain about this sort of urban fantasy novel having too little angst, and maybe I was just hoping for a story other than the one I was reading, but I wanted a story that dug a bit deeper into Anna's psyche. I think the best word for Cry Wolf is okay. If this is the story you're in the mood for, it delivers that story. Briggs's werewolves are mildly interesting, and the Omega concept is a good one, although not as thoroughly or convincingly explored as I would have liked. I would have preferred more intensity in the hurt/comfort plot and a more difficult healing, but I still enjoyed the book. Followed by Hunting Ground. Rating: 6 out of 10

Jacob (and Oliver too, somewhat) has taken quite the interest in Christmas music this year. Perhaps it s singing in the choir at school, or perhaps it s just him getting older, but in any case, Christmas music fascinates him. And no song more than Jingle Bells. I have recordings of it by several artists in different styles, and he has his favorites and often wants to hear them again and again. The other night at supper, he said, Dad, can you sing Jingle Bells in German? Kind of a random question. I normally try to keep books and devices of all sorts away from the table, but my son had just asked me to sing. In German. I don t believe that had ever happened before, so I wasn t going to say no! I got my tablet, pulled up Google, and found some German lyrics. Not exactly a translation, but it fit the tune, so that s what counts. So I started singing, and when I got to the chorus, and sang Oh, Glockenklang, Glockenklang both boys bust up laughing. They thought Glockenklang was a hilarious word, and loved to hear it. Oliver requests I sing Glockenklang every so often now. He has this eager anticipation when he does it, as if he knows I m going to be hilarious so much so that he almost starts laughing before I even say a word. Then yesterday at breakfast, Jacob requested more German songs. I finally got a couple of hymn books (one of which, Gesangbuch mit Noten, really is a German songbook). I sang some songs in German for the boys, while they enjoyed their blueberry crepes. Sadly Stille Nacht and O du fr hliche did not prove as hilarious as Glockenklang, but they got impatient as I looked through the idnex between each song, saying Dad, just sing more German! Don t look at those pages! So I guess it was a hit. I m not sure where this sudden fascination with German music came from, but it appears to be leaving me hungry. While driving around, Oliver requested I sing Glockenklang in the car. I said yes, despite not remembering even one German word to that song except for, well, Glockenklang. So I just filled in with some random German words I do know. Fortunately, they didn t seem to have memorized the rest of it either. The other day, we went to the annual Christmas concert at the local high school. It was perfect for the boys various styles of music, an interesting old auditorium, nobody was going to care if they weren t perfectly quiet, and the price was right, too. The band played first, and both boys sat there, paying great attention, soaking it all in. They loved the cymbal crashes and Jacob seemed to dream of playing the chimes and bells. At one point, I whispered to Jacob that I could feel the timpani on the wood floor in the auditorium, and he tried it, and made his Hmm, I just learned something interesting! reaction. As is tradition, the concert concluded with singing the Hallelujah Chorus and anyone in the audience that wants to sing is invited on stage to join the choir. I remember being in high school for that concert, and after practicing it in school, the great fun of being joined by many powerful voices from the community all around me on the risers. So this time, while my parents stayed with the boys, I was one of the many that went up to join the choir. It was no less thrilling all these years later. Ending with Forever and ever, Hallelujah, Hallelujah. Hallelujah! , and feeling it, right then, put a huge smile on my face.

As you may know, Debian 7.0 (codename 'wheezy') includes Linux 3.2. I'm maintaining the 3.2.y stable series at kernel.org which will collect bug fixes and some new hardware support as nominated by kernel developers and distributors, following the usual stable kernel rules. The Debian package has some additional features not present in mainline Linux 3.2. Union filesystem Debian Live needs a union filesystem to allow writing files on top of the read-only live system image. To support this, we include Aufs developed by Junjiro R. Okajima. I hope that Linux will gain union mount or union filesystem support in time for the next release, but currently it doesn't take much work on our part to integrate. Security hardening

• Magic SysRq functions are restricted by default. This can be changed through sysctl kernel.sysrq.
• Network protocols AF_IEEE802154, AF_RDS and AF_DECnet must be explicitly loaded; they cannot be loaded just by creating a socket.
• The default permissions on the debugfs root are 700, i.e. accessible only to root. (This change has also been made in Linux 3.7.)
• The symlink and hard link restrictions from Linux 3.6 (and previously grsecurity, Openwall and Ubuntu) are included and enabled by default. This can be changed through sysctls fs.protected_symlinks and fs.protected_hardlinks.
• The procfs hidepid/hidegid feature from Linux 3.4 is included, though not enabled by default. When enabled, this prevents users from reading the state of each others' processes through procfs, which can in some cases be security-sensitive.

Bufferbloat I backported two big pieces of the solution to bufferbloat:

• Byte Queue Limits (BQL) allows network drivers to reduce unnecessary buffering in their hardware transmit queues. This has been implemented in the bnx2, bnx2x, e1000e, forcedeth, igb, ixgbe, sfc, skge and tg3 drivers in Linux 3.3 onwards. Documentation is in the commit that added it, but you're unlikely to need it.
• The CoDel queue management algorithm can reduce unnecessary buffering in software transmit queues. FQ CoDel adds an element of 'fairness' between multiple network flows. These were implemented as the queue disciplines codel and fq_codel in Linux 3.5. They can be selected using the tc command, e.g.:
  tc qdisc replace dev eth0 root fq_codel

Kurt Elling is back in Chicago for two gigs at the Green Mill (where I last saw him in a wonderful big-band setting), along with his long-time collaborator Laurence Hobgood on piano, Clark Sommers on bass, Chicago's own John McLean on guitar, and the new kid Bryan Carter on drums. And they were, of course, awesome. Great mix of standards as well as new stuff from the Grammy-nominated new recording. If you can see Kurt Elling live, go. Now. They return for another gig tonight and I will have to see if I can swing that.

It has been a while since I wrote about bitcoin, the decentralised peer-to-peer based crypto-currency, and the reason is simply that I have been busy elsewhere. But two days ago, I started looking at the state of bitcoin in Debian again to try to recover my old bitcoin wallet. The package is now maintained by a team of people, and the grunt work had already been done by this team. We owe a huge thank you to all these team members. :) But I was sad to discover that the bitcoin client is missing in Wheezy. It is only available in Sid (and an outdated client from backports). The client had several RC bugs registered in BTS blocking it from entering testing. To try to help the team and improve the situation, I spent some time providing patches and triaging the bug reports. I also had a look at the bitcoin package available from Matt Corallo in a PPA for Ubuntu, and moved the useful pieces from that version into the Debian package. After checking with the main package maintainer Jonas Smedegaard on IRC, I pushed several patches into the collab-maint git repository to improve the package. It now contains fixes for the RC issues (not from me, but fixed by Scott Howard), build rules for a Qt GUI client package, konqueror support for the bitcoin: URI and bash completion setup. As I work on Debian Squeeze, I also created a patch to backport the latest version. Jonas is going to look at it and try to integrate it into the git repository before uploading a new version to unstable. I would very much like bitcoin to succeed, to get rid of the centralized control currently exercised in the monetary system. I find it completely unacceptable that the USA government is collecting transaction data for almost all international money transfers (most are done in USD and transaction logs shipped to the spooks), and that the major credit card companies can block legal money transactions to Wikileaks. But for bitcoin to succeed, more people need to use bitcoins, and more people need to accept bitcoins when they sell products and services. Improving the bitcoin support in Debian is a small step in the right direction, but not enough. Unfortunately the user experience when browsing the web and wanting to pay with bitcoin is still not very good. The bitcoin: URI is a step in the right direction, but need to work in most or every browser in use. Also the bitcoin-qt client is too heavy to fire up to do a quick transaction. I believe there are other clients available, but have not tested them. My experiment with bitcoins showed that at least some of my readers use bitcoin. I received 20.15 BTC so far on the address I provided in my blog two years ago, as can be seen on the blockexplorer service. Thank you everyone for your donation. The blockexplorer service demonstrates quite well that bitcoin is not quite anonymous and untracked. :) I wonder if the number of users have gone up since then. If you use bitcoin and want to show your support of my activity, please send Bitcoin donations to the same address as last time, 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

Relase 0.10.2 of Rcpp provides the second update to the 0.10.* series, and has arrived on CRAN and in Debian. It brings another great set of enhancements and extensions, building on the recent 0.10.0 and 0.10.1 releases. The new Rcpp attributes were rewritten to not require Rcpp modules (as we encountered on issue with exceptions on Windows when built this way), code was reorganized to significantly accelerate compilation and a couple of new things such as more Rcpp sugar goodies, a new timer class, and a new string class were added. See below for full details. We also tested this fairly rigorously by checking about two thirds of the over 90 CRAN packages depending on Rcpp (and the remainder required even more package installs which we did not do as this was already taking about 12 total cpu hours to test). We are quite confident that no changes are required (besides one in our own RcppClassic package which we will update. The complete NEWS entry for 0.10.2 is below; more details are in the ChangeLog file in the package and on the Rcpp Changelog page.

Changes in Rcpp version 0.10.2 (2012-12-21)

• Changes in Rcpp API:
  • Source and header files were reorganized and consolidated so that compile time are now significantly lower
  • Added additional check in Rstreambuf deletetion
  • Added support for clang++ when using libc++, and for anc icpc in std=c++11 mode, thanks to a patch by Yan Zhou
  • New class Rcpp::String to facilitate working with a single element of a character vector
  • New utility class sugar::IndexHash inspired from Simon Urbanek's fastmatch package
  • Implementation of the equality operator between two Rcomplex
  • RNGScope now has an internal counter that enables it to be safely used multiple times in the same stack frame.
  • New class Rcpp::Timer for benchmarking
• Changes in Rcpp sugar:
  • More efficient version of match based on IndexHash
  • More efficient version of unique base on IndexHash
  • More efficient version of in base on IndexHash
  • More efficient version of duplicated base on IndexHash
  • More efficient version of self_match base on IndexHash
  • New function collapse that implements paste(., collapse= "" )
• Changes in Rcpp attributes:
  • Use code generation rather than modules to implement sourceCpp and compileAttributes (eliminates problem with exceptions not being able to cross shared library boundaries on Windows)
  • Exported functions now automatically establish an RNGScope
  • Functions exported by sourceCpp now directly reference the external function pointer rather than rely on dynlib lookup
  • On Windows, Rtools is automatically added to the PATH during sourceCpp compilations
  • Diagnostics are printed to the console if sourceCpp fails and C++ development tools are not installed
  • A warning is printed if when compileAttributes detects Rcpp::depends attributes in source files that are not matched by Depends/LinkingTo entries in the package DESCRIPTION

Thanks to CRANberries, you can also look at a diff to the previous release 0.10.1. As always, even fuller details are on the Rcpp Changelog page and the Rcpp page which also leads to the downloads, the browseable doxygen docs and zip files of doxygen output for the standard formats. A local directory has source and documentation too. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page

This post is a bit late, but still interesting: Last weekend, I held a Bug Squashing Party at my company's offices in Mechlin, Belgium. This is the first time I've attended, let alone hosted, such an event; so I'm not that experienced in figuring out what I can and cannot do with other people's packages yet. As a result, our success rate was a bit lower than I'd hoped for. Still we closed two bugs, figured out that one more bug required just some binNMUs, that one should probably be tagged wheezy-ignore (as it was tagged squeeze-ignore too, and hasn't seen updates since then), and touched three more bugs. Having said that, I did have a bit of a hidden agenda, in that I've been wanting to build a stronger Debian community in Belgium; we are ranked fairly highly on the Debian Developer per capita list, but us Belgian DDs never meet up, in contrast to DDs from three of the four countries that surround Belgium. In that, I did have some success, too; some local people showed up who'd never (directly) contributed to Debian before. While I'm not silly enough to think that just showing up to a BSP once makes you suddenly an active member of a community, it's still a good first step. Unfortunately, however, I did not manage to get any other active Belgian DDs to show up. Apart from myself, only Dutch DD Joost Van Baal and DD Emeritus Joost Damad were present. If I can't find a way to improve on that, I'm not sure this BSPing will have a long life in Mechelen. At any rate, though, I did have a lot of fun doing this. Surely that, if nothing else, counts as "success".