My new Samsung Galaxy S3 phone takes a micro-SIM (see the Wikipedia page about Subscriber Identity Modules for details [1]). All my other mobile devices take a mini-SIM so I can t just put the SIM from my old phone in my new phone. I ve just made my second application to Virgin Mobile for a new micro-SIM, the first time they sent me a nano-SIM by mistake. Also if my new phone breaks I will have difficulty in getting a micro-SIM to run in a mini-SIM device (it should be possible, but will be difficult at least). I may even have to ask my Telco to send me a new mini-SIM to allow the use of an older phone if my Galaxy S3 breaks. The difference between micro and mini SIMs is 25*15mm vs 15*12mm. For a phone with a 4.8 display this doesn t seem to be a great benefit. It doesn t seem that the phone would be much bigger if they had designed it for a mini-SIM. If they had used a nano-SIM which is 0.09mm thinner that might have allowed them to make the entire phone thinner, I think that such thin phones are a bad idea but the reviewers seem to like thin phones with small batteries. I think that any device which is large enough to have a speaker somewhere near my ear and a microphone somewhere near my mouth will be big enough to fit a 25mm long SIM card. It seems to have been a trend in Australia in the last few years towards only selling unlocked phones on contracts (relying on the contract terms to lock the customer in) and only use locked phones for discount sales for pre-paid use. Also the free phones in Australia are considerably more expensive than buying a phone outright [2]. So I m sure that most people have a collection of older phones which in future can t be easily interchanged with new phones due to SIM card size differences. This is more of a problem due to the fact that modern phones seem to have a low quality of hardware production, the majority of Android phones owned by my relatives have failed in some substantial way well within the two year replacement period. I don t believe that I can rely on my Galaxy S3 working until I want to buy something better, I expect that my old Galaxy S (which has a hardware fault that makes it crash regularly but is mostly usable) will be pressed into service again. In terms of phone purchases, buying a phone that takes a micro-SIM seems like a bad strategy as there is an even smaller nano-SIM available. For all I know Samsung will release a Galaxy S4 or Note3 that uses a nano-SIM and give me the same upgrade problem in a couple of years time. I wish that the people who reviewed phones would pay more attention to the real world use cases than to slightly better specifications. The micro and nano SIMs seem to provide no real benefit for users. Saving a fraction of a gram in device mass or a fraction of a millimeter in one dimension might seem nice when aggregated with other small savings, but for the user it s no real benefit. Being able to interchange a bunch of random phones is a real benefit. It s also a real benefit to be able to buy a phone and expect it to just work immediately. With the current state of the market one can t buy a phone and make any assumptions about the SIM size that it will accept, at best this requires some extra research before buying and at worst this could involve some time without phone service. I think that a major feature for a review of an important device like a modern smart phone should be how quickly and easily it can be deployed for full use. When SIM size issues prevent a new device from being used properly for over a week (as has happened for me) then it seems like a design failure.

• [1] http://en.wikipedia.org/wiki/Subscriber_identity_module
• [2] http://etbe.coker.com.au/2012/09/22/phone-prices-australia/

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

Some people have complained that they can't install Linux on new machines because their firmware won't let them choose a boot device. This is part of Windows 8's fast boot support - the keyboard may not be initialised until after the OS has started. To deal with this, insert the install media and reboot your computer. Wait for Windows 8 to start. While holding down shift, click on the power icon and click on restart. When the menu appears, click "Use a device" and then click your install media. If it's listed more than once, choose the one that says "UEFI" in front of it. Your system will now restart and boot off the install media.

comments

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

This year it turned out that we had to care the first time for ourself about Christmas dinner. So we decided to try a roast goose. Obtaining the goose is a different story and will maybe told later. The second challenge was to select a recipe. We found a great one at Die Rezeptesammlung der Unix-AG

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.

Floating and tiling window managers In the X Window System, the window manager is that piece of software that places your windows and allows you to move them, resize them, hide them, etc. If your windows have titles on top of them, with buttons to close them or reduce them, it is thanks to the window manager. There are two major types of window managers:

Floating window managers

They are the most usual window managers, that allow you to place an size your windows freely on the screen, in a way where they are independent of each other, possibly overlapping, just as you would be able to place sheets of paper on your desk.

Tiling window managers

They are a more elitist type of window manager, that adjust the size and position of the windows so there is no overlapping and no space lost between windows, thus tiling the screen.

The frontier between these two types is not very tight, because some floating window managers have limited tiling features, and almost all the tiling window manager have floating modes for programs that are not adapted to tiling. For what it is worth, here is a report on my experience with three tiling window managers. Perhaps it may help people that are still hesitating to switch to tiling window management?Using tiling window managers Five years ago I switched to tiling window management, feeling that managing windows was the window manager's job (a quote from larswm). At that time, I started using wmii, then switched to awesome, and now I am trying i3. For people in a hurry, here is a comparative table:

	wmii	awesome	i3
Configuration	Shell script	Lua script	config file
Scriptability	any language, 9P-based	Lua, API-based	any language, socket-based
Layout	simple, column-based	automatic layout-based	flexible, manual tiling-based
Multi-monitor	sucks	OK	OK
Modern stuff		XCB, Xft, notification area, dock windows	XCB, Xft, notification area
Special features	tag-based workspace system	XDG convention to locate the config file real framework for customization	powerful status bar

wmii wmii is a rather minimalist window manager which used to be part of the suckless project, but is now hosted at Google Code and seems to have lost all its documentation during the move (why is it that all the software I have seen hosted at Google Code or worst, at Launchpad, have almost not documentation, and never, ever a single screenshot?). It uses a column-based layout: you place windows in a number of columns, and for each column you can choose either vertical split, stacking or full column mode. This system is very simple to control flexible enough for most situations, but it does not allow for arbitrary tiling. It is fully scriptable in any language, in an interesting way: it exposes all its functions on a 9P virtual filesystem. In fact, wmii itself only implements window management functions, and all the user interaction logic takes place in a distinct script which calls that functions using that 9P filesystem. wmii comes with a default script, written in shell, which makes it a bit hard to extend, and slow if you start calling external programs such as grep, sed and co. You can script it in any language you like however, and there are some already made implementations in Ruby and Python IIRC. A special feature of wmii is that its workspaces are in fact tags, and that you can tag a window so that it will appear in several ones. While this is interesting, in practice I did not find much use for that feature. It is explicitly minimalist, and the developers used to impose themselves a limit on its numbers of lines of codes (not sure if this is still true with the switch to Google Code). While I was using it, it had no notification area, no support for Xft fonts and it sucked with multiple monitors, which is the reason I switched to awesome. awesome awesome is a very flexible window manager that provides advanced automatic layouts. It has become quite popular, and it has a very well documented wiki. It is not officially a tiling window manager but a framework window manager, and to emphasize on that it start in floating mode by default. I think most people use it in tiling mode however. It uses automatic layouts, that place your windows according to rules, for instance the fair layout, which tiles in columns and rows so that each window occupies a similar space. Thanks to that automation, this system is very easy to control and to get used to, and although it certainly does not allow arbitrary tiling, you can cycle between several available layouts which are suitable for most situations (most of them are entirely automatic, but some have parameters you can modify, such as the number and width of columns), and if you miss one, I think you can even code your own. It is fully scriptable using the Lua language. In fact, just as wmii, the user interaction logic is defined in the configuration file, which allows efficient customization. The Lua API is fully documented, and there is a series of useful libraries to extend the basic configuration in any way you like, which is why awesome calls itself a framework window manager . It is not designed to be minimalist, and it implements some modern stuff, such as using XCB rather than Xlib, a notification area, and specific support for dock or utility-type windows such as GIMP's tools. i3 i3 is a window manager inspired by wmii, although they do not have much in common in my opinion. for what I have seen, I think it would be closer the defunct Ion. It uses a layout based on manual splitting: as you open windows you can choose to split an existing window either vertically or horizontally, leading to arbitrarily complex layouts. In addition to that you can tab or stack windows in containers instead of splitting them. This system is very flexible but it requires more user intervention. In its standard mode of operation, i3 is simply configured in a regular way, which allows to customize the user interaction but not to script it in an arbitrary way. It offers an IPC system that can be used for that however, by the mean of a Unix socket, so it can actually be scripted in any language too if needed, although this possibility is probably not as popular and easy as with wmii and awesome. It implements modern features such as XCB, a notification area and a powerful status bar that uses the standard output of a dedicated program that is easy to replace by your own if you need.

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

One of the nicest developments in the cloud arena is the increasing adoption of standards, this of course will impact on maturity and market confidence on such technologies. Amazon, as one of the pioneers, made a good choice on their offering design by making their API implementation public. Now, vendors such as Eucalyptus private/hybrid cloud offering and many other providers can leverage and build upon the specs to offer compatible services without the hassle for their customers to learn a new technology/tool. I ve bare-metal servers siting on Connectria s data-center. A couple of months ago I ve learned about their new cloud storage offering. Since I m working a lot on cloud lately I checked the service. It s was nice to learn they are not re-inventing the wheel but instead implementing Amazon s Simple Storage Service (S3) de-facto standard for cloud storage. Currently there are many S3-compatible tools available both FLOSS and freeware/closed source (Connectria provides a nice list of them). I ve been using s3tools, which is already available in the Debian archive, to interact with S3-compatible services. Usage is pretty straightforward. For my use case I intend to store copies of certain files on my provider s S3 service. I ll need to create buckets to be able to store files. For the ones not very familiar with S3 terminology buckets can be seen as containers or folders (in the desktop paradigm). First thing to do is configure your keys and credentials for accessing S3 from your provider. I do recommend you to use the --configure option to create the $HOME/.s3cfg file because it will put all the available options for a standard S3 service, leaving you the work of just tweaking them based on your needs. You can go and create the file all by yourself if you prefer, of course.

$ sudo aptitude install s3cmd
$ s3cmd --configure
Enter new values or accept defaults in brackets with Enter.
Refer to user manual for detailed description of all options.
Access key and Secret key are your identifiers for Amazon S3
Access Key:
...

You ll be required to enter the access key and the secret key. You ll be asked for a encryption password (use only if you plan to use this feature). Finally, the software will test the configuration against Amazon s service. Since this is not our case it will fail. Tell the configuration instead to not retry configuration and say Y to Save configuration. Now, edit the $HOME/.s3cfg file and set the address for your private/third-party S3 provider. This is done here:
host_base = s3.amazonaws.com
host_bucket = %(bucket)s.s3.amazonaws.com
Change s3.amazonaws.com to your provider s address and the host_bucket configuration also. For my case I had to use:
host_base = rs1.connectria.com
host_bucket = %(bucket)s.rs1.connectria.com
Now, save the file and test the service by listing the available buckets (of course there is none yet).

$ s3cmd ls

If you don t get an error then the tool is properly configured. Now you can create buckets, put files, list, etc.

$ s3cmd mb s3://testbucket
Bucket 's3://testbucket/' created
$ s3cmd put testfile.txt s3://testbucket
testfile.txt -> s3://testbucket/testfile.txt [1 of 1]
8331 of 8331 100% in 1s 7.48 kB/s done
$ s3cmd ls s3://testbucket
2012-12-26 22:09 8331 s3://testbucket/testfile.txt

Doing my regular news scan, I stumbled across this: Hacker reveals in Rio how he rigged an election (in Portuguese; you can try the Google-translated version). Why am I reposting this? Because, even after the reported studies by Diego Aranha and the information disclosure exploited by Sergio Freitas, Brazil is still portrayed as the biggest example on how electronic voting can be 100% secure and tamper-proof. Well, in this case, Rangel (his full name ahs not yet been disclosed), a 19 year old hacker, not only demonstrated how elections could be rigged, but admitted on doing so together with a small group, and even pointed at who was benefitted from this. Rangel's attack was done during the transmission phase After ~50% of the electoral results had been sent over the Oi network. And yes, the provider will most likely close the hole that was pointed at, but this basically shows (again!) that no system can be 100% tamperproof, and that the more electronic devices are trusted for fundamental democratic processes, the more we as a society will be open to such attacks. The security-minded among us will not doubt even for a second that, as this attack was crafted, new attacks will continue to be developed. And while up to some years ago the attack surface was quite smaller (i.e. booths didn't have a communications phase, just stored the votes, and communication was done by personal means), earlier booths have been breached as well. And so will future booths be breached. So, the news of this attack are indeed very relevant for the field. The presentation I am quoting was held around two weeks ago And December will surely dillute attention from this topic. Anyway, I will look for further details on the mechanism that was used, as well as to the process that follows in the TSE (Supreme Electoral Tribunal). I hope we have news to talk about soon!

after having used nanoblogger since august 2005, I decided to switch my blog engine. the reason was mainly that nanoblogger gets terribly slow with more than a handful of entries. inspired by nhandler, I took another look at chronicle, which had caught my interest before already. it's simple, produces static html pages from text files that I can keep in git, & it's written in perl :) let's see how many years chronicle will accompany me

Review: Code Name Verity, by Elizabeth Wein

Publisher:	Hyperion
Copyright:	2012
ISBN:	1-4231-5219-0
Format:	Hardcover
Pages:	339

I don't read very much historical fiction, and I mostly avoid historical fiction from the 20th century. I'm particularly uninterested in reading about Nazis after the saturation programming in places like the History Channel and the number of alternative histories that involve them. I've read enough about World War II to last me a lifetime, and I also avoid books about people being tortured. When Code Name Verity showed up in reviews I read, I was therefore rather dubious: a book set during World War II featuring someone being tortured by Nazis seemed unlikely to appeal to me. But after two steller reviews from reviewers who don't give out top marks easily, I bought a copy with some trepidation. That was one of the best decisions that I've ever made. This is the sort of book that is severely hurt by spoilers. In a moment, I'm going to attempt the impossible dance of giving you a feeling for the book and why I love it so much without spoiling anything. But if you trust my taste in books, let me give you a short warning, and then I suggest you stop reading this review and just go read the book. I avoided as much information about it as possible before reading it and never regretted it. The short warning: This is a book that hurts. lightreads describes it as searing. I think that's a very good term. It's not that it's gruesome; there is torture, but most of it happens off-camera and the focus is on emotional reactions rather than physical description. But the story sneaks up on you with sudden flashes of insight, and parts of it are a gut punch. It's the kind of book that had me in tears for a quarter of the book. It's the kind of book that nearly has me in tears remembering it to write this review. So, you may want to save this one until you are in the mood for that kind of book. But, that warning aside, Code Name Verity is unspeakably brilliant. This is one of the best books I have ever read in my life. I will try to explain more, but if your tastes mostly align with mine, just stop here and go read it.

I AM A COWARD.

That's how Code Name Verity starts: the words of a captured female British agent in Nazi-occupied France. The book opens near the end of her interrogation (and torture). The important information has already been discussed, and now she's likely destined to be executed. For the last set of wireless codes, she's bought herself paper and two weeks to write, and is expected to record everything that she remembers about the British war effort. The pages of this book are that writing (quite literally in the frontpiece and part of the cover, which are beautifully designed). The way she chooses to approach that task is to tell a story about the person whose ID she had when she was captured, a story that becomes the recounting of how she ended up where she is. That story is the heart and soul of this book. It's about the war, yes, and about British operations during the war. But it's a story about airplanes, too, and about the Air Transport Auxiliary, and about women finding a place in the war (with just a bit of a fictional push, detailed by the author in an afterword, although not quite as much of one as you might expect). And it's a story of a friendship, an amazing friendship of two women who would have never met each other if it weren't for the war and its leveling and transcending of normal social separations. It's a story about a friendship of opposites, about two people who find ways to support each other, about two people who see the best in each other. This is quite possibly the best novel about a friendship that I've ever read. This story, by itself, is wonderful. The tone starts light and irreverant, with an undertone of complex despair and defiance that's hard to analyze. One wonders where it's going and whether any of this is relevant, and then it slowly draws in the reader and becomes utterly compelling. But that's only the start of what this book has in store. Wein does some amazing structural things here that turn and broaden and transform, things that absolutely should not be spoiled because experiencing them without advance knowledge is a breathtaking reading experience. And all the parts play off against each other with a confidence that lets Wein understate and even hint at deeper emotions and be completely confident that the reader is right where she wants them to be. It's not a one-trick book, nor is it one that's going to lose you in the structure, but it's a book that opens up layers as you read it and tempts you re-read it immediately with new eyes once you finish it. Except it hurts so much that re-reading it immediately might be more than your heart can take. Perhaps the most astonishing part of this book is the way it hits its emotional notes. It is a masterpiece of showing rather than telling. Wein undersells the emotions in exactly the right way to make them stronger and more effective, avoiding, in the process, multiple traps that I've rarely seen avoided. The ending is absolutely note-perfect to everything that's happened before in a way that I thought, five pages from the end, was going to be impossible to pull off, and gets even better the more that one thinks about it. And the whole book is like that. It's been a month and a half since I read this book, in part because I wasn't sure how to write this review, and I did not, in fact, manage to finish writing it without crying. If I didn't have to be on a train in eight hours from when I'm writing this (a few days before I post it), I'd start reading it again right now. I can't talk about most of the things that make it amazing with anyone who hasn't read it, but it really is that good. Rating: 10 out of 10

git-pbuilder is a shell script suitable for use as the builder command in git-buildpackage that simplifies using pbuilder, cowbuilder, or qemubuilder to build packages in a chroot. It's now part of the git-buildpackage Debian package, but I maintain it somewhat separately. This version supports a new environment variable, GIT_PBUILDER_OUTPUT_DIR, that can be set to override the default output location of ".." (the parent directory). It also changes the script to be a bash script and uses arrays to handle the options passed to the builder command so that shell metacharacters in the GIT_PBUILDER_OPTIONS environment variable will hopefully be handled correctly. As part of that change, it also tries to escape any options that will be passed to --debbuildopts to hopefully protect them from the additional layer of shell parsing that they'll be subject to. Thanks to Guido G nther and paul cannon for the patches. I hate having to make the script bash-specific, but trying to get the shell expansion right is otherwise a huge headache. That probably means that it's outlived the usefulness of the original implementation language (which was shell only because this started life as a quick hack). I should probably take the time to rewrite it in either Perl (which I know best) or Python (which is the language the rest of git-buildpackage is written in). But that's for another day. (Here's an excellent case in point for why one shouldn't embed language-specific extensions in the name of an executable that's part of a user interface or configuration interface.) You can get the latest version from my scripts page.

Happy winder holiday of choice to all and sundry! Enough new Kindle books have accumulated that it seems time for another post so that I can remember what I bought. Elizabeth Bear Garret Investigates (sff)
eluki bes shahar Hellflower (sff)
Elizabeth Cleghorn Gaskell Cranford (mainstream)
John Scalzi Subterranean Scalzi Super Bundle (sff) Cranford was free since it was written in the 1800s. I picked it up because of Jo Walton's review on Tor.com. The eluki bes shahar novel is from Daniel Moran's e-book site FS&, an impulse buy from browsing through his catalog while picking up the Long Run bundle for my mother. The Scalzi super-bundle is a collection of five separately-published novellas and chapbooks plus one non-fiction essay, only one of which I already owned (The God Engines), which seemed like a fairly good deal. In a separate note, the problem with watching interesting lectures on YouTube (apart from the fact that it's very easy to lose a day doing so) is that I usually end up wanting to buy the book on the topic and then read that. That happened to me today: I finally got around to watching Philip Ball's lecture on the chemistry of painting, and now Bright Earth is in my non-fiction want list. And there are three more hour-long TVO programs linked off of related material that look interesting. I fear the day may disappear.... Well, I will be rescued at least partly by being called to help decorate Christmas cookies. This is the beginning of by far my favorite two weeks of the year, although not for the reasons that people might suspect. Other than food (yum) my family doesn't do Christmas: no decorations, no huge family get-togethers, and we all give each other the freedom from guilt and stress of having to find presents. But I get two weeks of mandatory vacation from work, as does, importantly, everyone else. Which means there's nothing going on to suck me in from vacation and a very pleasant sense of resting and resetting for the new year. It's quiet, I can sit and read, I can focus on one thing at a time, and I can reorganize and order my life and revisit priorities and to-do lists with a lovely sense of perspective. Any other mandatory or at least widespread holiday would work as well, so it's unrelated to the season. (I find the commercialism somewhat distracting rather than a positive part of the experience.) But this is the one that we get, and it happens to coincide nicely with the meaningless but psychologically significant change of the year number. And it's delightful every year.

Yup, it's been a while since my last blog post, but I'm not dead yet. Most of my spare time goes into sigrok development these days (open-source signal analysis suite for logic analyzers, oscilloscopes, multimeters, and lots more), but I'll try to revive my blog too. I have various microcontroller/embedded topics and devices I want to talk about in a small blog post series in the nearer future. But more on that later. Feel free to subscribe to the sigrok-devel mailing list, join us on IRC in #sigrok (Freenode) where most of the discussions take place, or follow our new sigrok blog (RSS) if you're interested in the ongoing sigrok developments. Anyway, for now just a quick announce: Same as last year, we will be at the Chaos Communication Congress (29c3), this time in Hamburg, Germany. The conference takes place from December 27th to 30th, 2012. We'll have a sigrok "assembly", likely in area 3b of the conference building, where we'll be hanging around, working on new sigrok features, new hardware drivers, new protocol decoders and various other things. We'll have lots of gear with us for demo and development purposes, including logic analyzers, oscilloscopes, MSOs, multimeters, and lots more. Bring your own device if you own models we don't yet support or know about. We'll be happy to have a look! Chat with us, give us your suggestions which features you'd like to see, which devices you want to be supported, which protocol decoders you'd like to have, or even help us write some drivers/decoders! Hope to see you there!

I ve been working on some autotesting features for d-i over the past few weeks, and I ve started lagging behind on my debian-boot@ reading accordingly, by several hundreds of mails. Today s gift to myself: no more unread/unanswered mails in that mailbox! Even if I ve prepared things for a possible d-i wheezy rc1 release around Christmas, several things weren t ready, most notably: grub-installer. Hopefully #696615 will be fixed soonish, probably by asking where to write when /target(/boot) isn t on (hd0). Wanted! Speaking of grub-installer, if anyone can reproduce #681227, I m all ears! Wouter has a workaround for it (only in sid for now), but I d very much like to track down the root cause for that one. It is supposedly reproducible with wheezy beta 4 images and with weekly builds (they use components from testing), all of those are available from the debian-installer website.

Let me start by wishing you all marry Christmas and a happy new year! I hope next year will prove to be a good year. Bitcoin, the digital decentralised "currency" that allow people to transfer bitcoins between each other with minimal overhead, is a very interesting experiment. And as I wrote a few days ago, the bitcoin situation in Debian is about to improve a bit. The new debian source package (version 0.7.2-2) was uploaded yesterday, and is waiting in the NEW queue for one of the ftpmasters to approve the new bitcoin-qt package name. And thanks to the great work of Jonas and the rest of the bitcoin team in Debian, you can easily test the package in Debian Squeeze using the following steps to get a set of working packages:

git clone git://git.debian.org/git/collab-maint/bitcoin
cd bitcoin
DEB_MAINTAINER_MODE=1 DEB_BUILD_OPTIONS=noupnp fakeroot debian/rules clean
DEB_BUILD_OPTIONS=noupnp git-buildpackage --git-ignore-new

You might have to install some build dependencies as well. The list of commands should give you two packages, bitcoind and bitcoin-qt, ready for use in a Squeeze environment. Note that the client will download the complete set of bitcoin "blocks", which need around 5.6 GiB of data on my machine at the moment. Make sure your ~/.bitcoin/ directory have lots of spare room if you want to download all the blocks. The client will warn if the disk is getting full, so there is not really a problem if you got too little room, but you will not be able to get all the features out of the client. As usual, if you use bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

I use UUCP to get my mails. It works fine but lacks support for modern SMTP features like DSN. While it may be possible to bolt support into the the rmail part, both the sendmail interface used to submit mails and the Postfix pipe daemon used to extract mail are not able to do so. So I started a small project to get around this problem. This software uses LMTP to retrieve and SMTP to send all mails. LMTP (a SMTP derivative with support for all extensions) is used to inject mail via a small daemon. The mails are transported using a format similar to batched SMTP to the remote system. It is then injected via SMTP to the local MTA.