Let s start a convention: bare-metal machines have the linguistic male gender ( der Computer , he needs to be rebooted), whereas VMs have the linguistic female gender ( die virtuelle Maschine , she runs better since the last upgrade of Linux-KVM), and neutral linguistic gender is used when you cannot or do not want or need to make such distinction.
This is, of course, entirely unrelated to human gender, but not unrelated to #debian-68k (on OFTC) discussions ;-) ObRant: DO NOT USE xz COMPRESSION LEVELS ABOVE 6! (For -7 we can make exceptions, for example in Debian *-dbg or *-source packages.) You may use -e if you absolutely need the better compression, but please think of the poor sods who have to create the archives. You must not use the highest compression levels -8 or -9 since they have absolutely insane memory requirements on compression and will still hinder machines with less RAM on decompression. (Using -e only affects CPU usage at compression time; decompression is exactly as fast and memory-consuming as without.) Furthermore, DO NOT CHOOSE A COMPRESSION LEVEL WITH A DICTIONARY SIZE MUCH LARGER THAN THE DATA TO COMPRESS, as that makes absolutely no sense and will rather worsen than improve compression. As a reminder, xz uses the following dictionary sizes:

• 256 KiB at -0 (compresses better than gzip(1) and faster than either gzip(1) or bzip2)
• 1 MiB at -1
• 2 MiB at -2 (compresses better than gzip(1) and bzip2 without losing much speed)
• 4 MiB at -3 and -4 (the difference is in the match finder between these two levels)
• 8 MiB at -5 and -6
• 16 MiB at -7 (186 MiB RAM used to compress a file)
• 32 MiB at -8 (370 MiB RAM used to compress a file)
• 64 MiB at -9 (674 MiB RAM used to compress a file)

Decompression uses less than 1 MiB more than the dictionary size, but the dictionary must always be allocated wholly. (You re fine to use custom presets, but mind the RAM usage!) As a general rule, if you have something of up to 20 MiB to compress, -4 is fine, and -5 will only be better if you have similar data spread across the whole of the file instead of close to each other. When I make mksh distfiles, I instead put files close to each other that have related content, which improves compression much more nicely without penalising low-memory systems; for example, you could put documentation, Makefiles, scripts, m4(1) files, and C source code into groups before archiving, instead of doing it alphabetically. Another note on bzip2: its decompression is slow. I see no reason to use it any more, at all. Use gzip(1) if you care for compatibility or have an issue with xz not having a free copyright licence, and xz otherwise.

Review: City of Diamond, by Jane Emerson

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

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

#696699 was already a funny bug number, but #696969 is even better. d-i FTW!

Got your attention? Don t hold your breath, we re not there yet, but we re a step closer: it s now possible to build Firefox from the Iceweasel package, since version 17.0.1-2 in experimental as of writing, 18.0~b6-1 from the iceweasel-beta repository, or 19.0~a2+20121228042015-1 from the iceweasel-aurora repository. Before letting you know how you can get yourself a packaged Firefox based on the Iceweasel source, I ll remind you that redistribution of Firefox packages requires a trademark license from Mozilla, so please keep the packages you build for yourself for now. That being said, now it s clear that such Firefox packages are not official, you can still test them for yourself. First download the Iceweasel source version of your liking, and extract it, then rename all source files from iceweasel_* to firefox_* (rename s/iceweasel/firefox/ iceweasel_* should do it). Edit debian/changelog so that the first line reads:

firefox (x.y.z-r) distribution; urgency=low

instead of:

iceweasel (x.y.z-r) distribution; urgency=low

and run the following command:

$ debian/rules debian/control

Now you re all set. You can build the package the usual way. Note there are a few differences between the xulrunner packages you get from building Iceweasel vs. from building Firefox that need to be addressed, and a few other details to sort out.

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

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

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.

It's been a few years coming, but the day has finally arrived. Contrary to some rumours which I've had to debunk over the years, the m68k port did not go into limbo because it was kicked out of the archive; instead, it did because recent versions of glibc require support for thread-local storage, a feature that wasn't available on m68k, and nobody with the required time, willingness, and skill set could be found to implement it. This changed a few years back, when some people wrote the required support, because they were paid to do so in order to make recent Linux run on ColdFire processors again. Since ColdFire and m68k processors are sufficiently similar, that meant the technical problem was solved. However, by that time we'd fallen so far behind that essentially, we needed to rebootstrap the port all over again. Doing that is nontrivial, and most of the m68k porters team just didn't have the time or willingness anymore to work on this; and for a while, it seemed like the m68k port was well and truly dead. But then, two things happened. The first thing that happened was called "ARAnyM", short for "Atari Running on Any Machine". An atari emulator, it started supporting running Linux at some point, allowing us to work on the port while on the road, using a laptop something not possible beforehand. While there were some bugs in the emulation of early versions of aranym, these were all fairly quickly fixed, and before long we could run Debian/m68k in the emulator. However, that was still the etch-m68k port on debian-ports.org, some time after Debian etch wasn't even supported anymore; this still required work. The second "thing" that happened was called "Thorsten Glaser". A fresh DD and maintainer of the "mksh" shell, he wanted to make sure his shell would work on all Debian architectures, including the ones on debian-ports.org. When he found out that the m68k port was in a pretty bad shape, he did not, like many before him, shrug and move on; instead, he took it upon himself to start compiling things, just so he could compile his shell. How's that for dedication. Anyway, fast-forward two years, and we're now, finally, at a point where I spent most of today getting buildd up and running on arrakis, one of our oldest buildd hosts. There were some issues while trying that, but it looks like everything is in working order now; and the first package to start building on the first functioning buildd host since a long time (the build of which is still ongoing at the time of this writing) is "babl". Of course, with only one buildd, we'll have no hope whatsoever of ever catching up. But that can be remedied easily by using more than one buildd host... Update: It built! Party!

Review: Alpha and Omega, by Patricia Briggs

Series:	Alpha and Omega #1
Publisher:	Berkley
Copyright:	2007
ISBN:	1-101-41379-4
Format:	Kindle
Pages:	112

Alpha and Omega is a novella set in Briggs's Mercy Thompson universe, an urban fantasy world that started with Moon Called. There's a limited edition hardcover version which is, at this point, ridiculously expensive, but it's available relatively inexpensively on the Kindle. (The page count in the sidebar may be high, since that's from the hardcover version; the Kindle version doesn't have page numbers.) It's the prequel novella to the novel Cry Wolf. You don't have to have read any of the Mercy Thompson novels to follow the story; it stands alone fairly well. I actually read Cry Wolf first, but (as I was warned) that proved to be a mistake, so I'm publishing my reviews in the "correct" reading order. Unusually for a niche novella leading into a regular series, Cry Wolf leans heavily on Alpha and Omega and works best if you've read it first. Anna is a werewolf, but not a very happy one. She's been a werewolf for three years, cutting herself off from everything before at the insistance of her pack, and she's at the bottom of the pecking order: abused, mistreated, and ordered about (although some of the abuse has gotten mildly better). That makes it startling that, when she sees a photograph in the paper of a missing teenager that she recognizes, she's willing to call the Marrok, the ruler of all wolves in North America, to report her pack's possible involvement. The Marrok sends his enforcer, Charles, to investigate. As soon as he arrives, he can tell that far more is wrong than anyone had realized. Anna's pack is completely dysfunctional, and Anna herself... well, that's the point of the story. Alpha and Omega has one of the more appealing qualities of novellas: a clear narrative drive that goes from point A to point B without many sidetracks or digressions. It's told in alternating tight third person perspectives, a traditional choice for this sort of story. Very little here will surprise an urban fantasy reader. It's the hurt/comfort story that one expects from the early going, but it's one that moves right along and hits most of the right notes. The biggest drawback for me was that I'm not horribly fond of Briggs's werewolf mythology. There are some parts that I like, such as Anna herself and the role that she discovers, but there's rather a lot of characters wrestling with their instinctive reactions or finding pack hierarchy enforced via means that appear to be magic. Given that the sort of absolute dominance hierarchy portrayed here is now considered dubious or refuted even in wild wolves, and given that I have a knee-jerk dislike of simplified, absolute structures, that part of Briggs's world-building makes my teeth itch. But, if you can get past that, and if you're not looking for any complex plotting (it is just a novella, after all), this isn't a bad way to spend an afternoon. It's comfort reading: things go roughly as you would expect them to go, and you can have the emotional satisfaction of seeing Anna's growth with very little risk. Followed by Cry Wolf. Rating: 7 out of 10

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

Problem #3: How to find out what s going on with debconf? Slightly longer version: As reported in #679327, the grub prompt during the installation process is entitled Configuring man-db , which isn t exactly great. Given man-db is a known dpkg trigger, I suspected this would be the reason for the broken title, and here s how I debugged it. For starters, using d-i basically means asking a lot of questions, which is implemented using the debconf mechanism. One should note that two implementations are available:

1. the historic implementation, in Perl: debconf
2. the C reimplementation: cdebconf

d-i uses cdebconf udebs, but joy begins when packages get installed in /target: debconf is used there. We ll see why that matters. Recipe #3: Set DEBCONF_DEBUG=developer and read logs!

1. Both implementations support the DEBCONF_DEBUG environment variable. The installer supports passing that as a kernel parameter; example from the syslinux prompt: select the Graphical install entry, press Tab , remove -- quiet and put DEBCONF_DEBUG=developer there instead.
2. Let s look at /var/log/syslog; there s a tail -f on it in VT4, but one can run grep and friends on it in VT2 or VT3. There, one can see what happens at the debconf level (the debconf protocol is documented in debconf-devel(7)). Tiny excerpt (timestamps removed for clarity):

   frontend: --> GET preseed/early_command
   frontend: <-- 0
    
   frontend: --> GET debian-installer/framebuffer
   frontend: <-- 0 true
    
   debconf: --> GET debconf/language
   debconf: <-- 0 en
   debconf: --> SET debconf/language en
   debconf: Setting debconf/language to en
   debconf: <-- 0 value set
   debconf: --> GET debconf/priority
   debconf: <-- 0 high
   debconf: --> GET rescue/enable
   debconf: <-- 0 false
   

3. The interesting point was titles, right? So let s look at the last TITLE occurrences:

   debconf: --> SETTITLE debian-installer/main-menu-title
   debconf: --> SETTITLE debian-installer/grub-installer/title
   in-target: debconf (developer): ----> TITLE Configuration de man-db
   debconf: --> TITLE Configuration de man-db
   in-target: debconf (developer): <-- TITLE Configuration de man-db
   in-target: debconf (developer): ----> TITLE Configuration de man-db
   in-target: debconf (developer): ----> TITLE Configuration de grub-pc
   debconf: --> TITLE Configuration de grub-pc
   in-target: debconf (developer): <-- TITLE Configuration de grub-pc
   in-target: debconf (developer): ----> TITLE Configuration de grub-pc
   in-target: debconf (developer): ----> TITLE Configuration de man-db
   debconf: --> TITLE Configuration de man-db
   in-target: debconf (developer): <-- TITLE Configuration de man-db
   in-target: debconf (developer): ----> TITLE Configuration de man-db
   in-target: debconf (developer): ----> TITLE Configuration de grub-pc
   debconf: --> TITLE Configuration de grub-pc
   in-target: debconf (developer): <-- TITLE Configuration de grub-pc
   in-target: debconf (developer): ----> TITLE Configuration de grub-pc
   debconf: --> SETTITLE debian-installer/grub-installer/title
   

   Bad news: the last one is about grub, so the title should be correct, right?
4. At this point, it might be the Gtk frontend behaving strangely. It s shipped in cdebconf-gtk-udeb, built from the cdebconf source. Let s look:
   • src/modules/frontend/gtk/ui.c has cdebconf_gtk_update_frontend_title(), which does what the function name suggests.
   • src/modules/frontend/gtk/di.c has cdebconf_gtk_di_run_dialog(), which calls the first function.
   • src/modules/frontend/gtk/progress.c has cdebconf_gtk_show_progress() (also calls the first function), which comes with the following comments:

     /** Show the progress widgets.
       *
       * This will actually add the widgets to the corresponding containers.
       * The main title saved when starting the PROGRESS operation will be restored
       * from the value saved when START was called.  This is needed when GO is
       * called during a PROGRESS operation.
     

   Now that s something! Even if the last entry is about grub, some previous value could be restored and could be the reason for the bad behaviour (that is easily confirmed by adding some debug_printf() calls on fe->title in cdebconf, thanks to an extra "debug.h" include). Maybe that s what needs fixing!
5. Now it s time to take a step back. A d-i environment is nice, but testing things can easily become a burden. Taking a random wheezy or sid chroot, and installing/removing a tiny package shipping a manpage should be enough to run into the man-db trigger. Exporting DEBCONF_DEBUG=developer there too, let s either install or remove x11-apps (the trigger does the same job, and the debconf trace is the same), here s the output:

   Processing triggers for man-db ...
   debconf (developer): frontend started
   debconf (developer): frontend running, package name is man-db
   debconf (developer): starting /var/lib/dpkg/info/man-db.config configure /usr/share/man
   debconf (developer): <-- VERSION 2.0
   debconf (developer): --> 0 2.0
   debconf (developer): <-- INPUT medium man-db/install-setuid
   debconf (developer): --> 30 question skipped
   debconf (developer): <-- GO
   debconf (developer): --> 0 ok
   debconf (developer): starting /var/lib/dpkg/info/man-db.postinst triggered /usr/share/man
   debconf (developer): <-- VERSION 2.0
   debconf (developer): --> 0 2.0
   debconf (developer): <-- GET man-db/auto-update
   debconf (developer): --> 0 true
   

   Even if one didn t know about the cdebconf/debconf thing, the frontend started bit in the d-i syslog would have been the key: it s only found in debconf, in the frontend script. That one has several ways to determine the package being acted on, and it finally calls:

   debug developer => "frontend running, package name is $package";
   $frontend->default_title($package) if length $package;
   

   Tada, that s likely to be the issue.
6. Tweaking that frontend script, it s easy to make sure that the code path for this use case is:

   elsif ($ARGV[0]=~m!^.*/(.*?)\.(?:postinst postrm prerm)$!)  
           $package=$1;
    
   

   Since $ARGV[1] is the action being passed to the maintainer script, one can intercept the triggered action, and avoid emitting a title update in this case; I ve therefore reassigned #679327 to the debconf package, and proposed a patch implementing that, which Joey Hess seems to find reasonable.

In my message to the bug report I wrote I actually tested it in a d-i environment, and made sure the issue had gone away. How I did that will likely be described in the next d-i hacking recipe.

My current employer as a benefit offers two days of paid volunteer time every calendar year. In September I decided to devote this time for Debian project. It wasn t easy to convince HR and my manager (hi Gloria ) that such activity can be considered as volunteering but I eventually did it! So last Thursday and Friday were days I could spent working on my packages and other stuff related to Debian Let s talk about effects. 5 packages updated, 16 bugs closed, more than 50 lintian warnings/errors solved. Here goes changelogs from updated packages:
calcurse (3.1.2-1) unstable; urgency=low * The Akamai Technologies paid volunteer days release.
* Package made from scratch (this was funny experience):
- uses new quilt source format
- uses new copyright format
- uses debhelper compatibility level 9 w/hardening options
- uses the newest Standards-Version
* New upstream version:
- supports UTF8 (Closes: #558671)
- hopefully fixes problem with accented characters (Closes: #466010) -- Bartosz Fenski <fenio> Thu, 20 Dec 2012 13:51:08 +0100 httpie (0.3.1-1) unstable; urgency=low * The Akamai Technologies paid volunteer days release.
* Includes manual page (Closes: #673067)
Courtesy of Khalid El Fathi <khalid>. Thanks!
* New upstream version. (Closes: #693810)
- handles binary transfers properly (Closes: #689974) -- Bartosz Fenski <fenio> Thu, 20 Dec 2012 14:27:59 +0100 skipfish (2.10b-1) unstable; urgency=low * The Akamai Technologies paid volunteer days release.
* New upstream version.
* Bumped Standards-Version (no changes needed).
* Various path fixes because of upstream changes.
* Added new libpcre3-dev build dependency.
* Totally rewritten copyright file to comply with new copyright standard. -- Bartosz Fenski <fenio> Thu, 20 Dec 2012 14:59:36 +010 ipcalc (0.41-3) unstable; urgency=low * The Akamai Technologies paid volunteer days release.
* ACK previous NMU, thanks Christopher!
* Documents some missing features in the manpage (Closes: #588143)
Thanks Tanguy Ortolo <tanguy>!
* Fixes other minor problems in manpage (Closes: #688148)
* Description now says it's tool IPv4 only (Closes: #628955)
* Fixes lack of </table> tag when printing supernets (Closes: #600251)
* The following changes are courtesy of Jari Aalto <jari.aalto>:
- Remove deprecated dpatch and upgrade to packaging format "3.0 quilt".
- Update to Standards-Version to 3.9.3 and debhelper to 9.
- Add build-arch and build-indep targets; use dh_prep in rules file.
- Patch 03: update with "quilt refresh" to make it apply cleanly.
Thanks to these changes (Closes: #670737) -- Bartosz Fenski <fenio> Fri, 21 Dec 2012 12:30:11 +0100 netw-ib-ox-ag (5.39.0-1) unstable; urgency=low * The Akamai Technologies paid volunteer days release.
* New upstream version.
* Uses Homepage header. (Closes: #615219, #615294, #615321, #615436, #645522)
* Bumped Standards-Version (no changes needed).
* Switch to dpkg-source 3.0 (quilt) format)
* Fixes FTBFS on s390x and sparc64 (Closes: #639493)
* Fixes 29 (sic!) lintian warnings/errors thus many small changes
in packaging scripts. -- Bartosz Fenski <fenio> Fri, 21 Dec 2012 15:38:29 +0200
Despite this I did something else. I sent end of the world joke-mail to debian-mentors mailing list stating (ignore the fact that my own server marked me as spammer; fixed already ;P) that I m going to review and try to upload every package that will be send to me during end-of-the-world day.
That action was quite successful although no package has been uploaded yet. I reviewed 4 of them and two more are yet to come. So it looks that these two days sponsored by Akamai motivated me enough to spent few more days or even months and help other people to contribute to Debian. Thank you Akamai!

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.

Review: Liars and Outliers, by Bruce Schneier

Publisher:	John Wiley
Copyright:	2012
ISBN:	1-118-14330-2
Format:	Hardcover
Pages:	285

One of the perils of buying a book written by a blogger one reads regularly is that the book may be little more than a rehashing of their blog, with insufficient original material to warrant the time investment. Sometimes it's still nice to support them financially, but it may not make sense to read the book. I've been following Schneier's blog for years (as should anyone with an interest in security), including through the entire process of writing Liars and Outliers, and was a bit worried that might be the case here. Thankfully, I can reassure any other worried potential readers that is not the case. This is substantial new material establishing a firm framework for thinking about incentives and controls in any society or organization. Liars and Outliers talks about security mechanisms, but it's not, at its core, a book about security. Rather, it's a book about incentives, order, and how order is established. It's a comprehensive reductionist analysis of how societies create predictability and compliance to allow us to trust other people who we have never met before and will never meet again. It's a unique (at least in my experience) combination of anthropology, sociology, security analysis, and political science. Schneier cuts across fields in an idiosyncratic but illuminating way that reminded me of (on an entirely separate topic) Jane Jacobs. This is not a prescriptive book, nor is a collection of answers, solutions, or even deep analysis of particular problems. Rather, it's an attempt to construct a general framework for analyzing societal dilemmas: conflicts between individual desires and social good, how those conflicts are resolved, and how societies can weigh the scales and influence the statistical outcomes. The closest Schneier comes to telling the reader how to solve problems is a checklist, at the end of the book, for designing effective societal pressures. Its primary contribution is vocabulary and structure. It also passes one of my litmus tests for any book about human behavior: Schneier complicates, broadens, deepens, and expands understanding, and points out complex interactions and complex feedback in effects we're inclined to consider simple, rather than simplifying or eliminating human complexity. One point I found refreshing about this book is that Schneier is scrupulous in refusing to define either society or individuals as good or bad, to the point of carefully defining terminology used in all of the social dilemmas. Following societal rules is called compliance; not following those rules is called defection. In some cases, defection is morally correct (Schneier's most frequent example is in the civil rights struggles of the 1960s in the United States). In all cases, social pressures are tools, which can be used to encourage compliance with moral or immoral systems, and which are deployed by totalitarian dictatorships and utopian communes alike. Schneier explicitly puts out of scope for this book the questions of how societal goals should be determined, how they change, and whether any given societal rule or interest is moral or immoral. He focuses, rather, only on the mechanisms, with a primary goal of informing and deepening debates over how best to encourage behavior that societies want to encourage and discourage behavior societies want to discourage. He also emphasizes discourage, as opposed to eliminate. Early on, Schneier shows some of the results of game theory, as well as basic common sense, that indicate that no healthy society can totally eliminate defection. Not only would that stifle valuable and important reform, such as changes in civil rights, but the degree of pressure required is immense. Defectors are natural and will always exist, and are sometimes valuable and necessary. Rather, the goal of a society is to reduce defectors to a level where most people can ignore their existence most of the time, a state that leads to the level of risk and trust required to have a functioning and healthy society. The word society, similarly, is intentionally broad, and can refer to just about any collection of people, from a circle of friends to a corporation, institution, or country. However, as Schneier points out early in the book, small societies rarely need much in the way of formal pressure and appear almost magically self-governing. That's the first property that he disassembles, resulting in a general classification of societal pressures into four categories: moral, reputational, institutional, and security systems. The last is an odd category that's partly orthagonal to the other three. Moral pressure is internalized conscience: the normal tendency of nearly everyone to follow their own moral code, a code that's at least partly constructed and certainly heavily influenced by the surrounding society. Reputational pressure is, in a sense, externalized morality: it's the informal reactions of others around one to one's past actions. Included in reputational pressure is shunning of every kind, from cutting off a friendship to boycotts against corporations, but it also includes confrontation from another member of one's society, the more subtle effects of our individual desires to be liked and respected, and all the various aspects of "face", honor, and respect within a community. Small communities are frequently self-governing, in Schneier's model, because they're small enough that moral and reputational pressures are sufficient and no other pressures are required. We're so used to applying moral and reputational pressure to other humans almost unconsciously that we sometimes don't even notice its existence, leading to that "magical" self-governing property. But Schneier puts pressures in a sequence: pressures that work extremely well with small groups often don't scale. Moral pressure works best with small groups and reputational pressure with somewhat larger groups, but when societies scale beyond the limits of reputational pressure when, for example, one frequently interacts with people whose reputations are unknown to you and whose subsequent opinion of you will not be relevant institutional pressure is required to force compliance. Institutional pressure is the sort of pressure that we all tend to think of first when we look for ways to enforce rules: laws, policies, contracts, and other codes of behavior that carry with them formal punishments and some enforcement mechanism. But even in societies so large that institutional pressures are frequently required, such as whole countries, moral and reputational pressures still exist and are extremely important. One of Schneier's most interesting points is his analysis of how institutional pressures can paradoxically undermine reputational and moral pressures, resulting in more defection than if the institutional pressure hadn't existed. This is just the basic framework of Schneier's analysis, hopefully giving you a feel for the structure of the book. He goes much deeper into the complicated interactions between the various levels of pressure, and then dives into an extensive look at competing societal dilemmas: cases where there is more than one society in play simultaneously, possibly demanding contradictory actions. Liars and Outliers also includes a wonderful analysis of organizational entities within the same framework, including their much-different reactions to moral, reputational, and institutional pressures. One of the most cogent analyses of the difficulties of regulating both corporations and governmental institutions falls out of that analysis, once one looks at them in light of Schneier's basic framework. Pressures quickly become complex and multi-layered, and human reactions to pressures are frequently counter-intuitive. Schneier draws extensively on game theory to show that some counter-intuitive responses are actually emergent properties of logical analysis of the situation, but that others are more uniquely human and have little or nothing to do with a mathematical cost-benefit analysis. I haven't even mentioned his discussion of security systems, and how they can extend moral, reputational, and institutional pressures, as well as add a new type of pressure (making a defecting action impossible) that scales even better than institutional pressures. Liars and Outliers has all of the supporting infrastructure you would expect in a scholarly book: notes, extensive references, and a good index. I suspect it will end up being used as at least additional reading in college classes. The notes are, unfortunately, end notes, making the full context of the book much harder to read than was necessary, but at least Schneier does separate the notes from the references so that one doesn't chase notes for further explanation and find a simple citation. As with any book like this, one always wishes it could end in a simple prescription to fix everything, but of course it doesn't. But that's also a measure of a good scholarly work. Human and organizational motivations are complex and tricky, and any framework for analyzing them needs to be able to represent that complexity. Schneier here has constructed a very powerful one, one that I started using in discussions before I'd even finished the book. Perhaps the most valuable contribution of Liars and Outliers to public discussion is clear terminology and categories, which can be of great help in finding the core components of a problem. Liars and Outliers can be slow going, particularly early on when Schneier is still defining terms and setting up the background of his analysis. One can get a bit tired of the analysis matrices of societal dilemmas. But stick with it through the groundwork, since the analyses of competing societal dilemmas and of the impact of societal pressures on organizations are exceptional. Highly recommended, particularly for anyone who is designing or implementing societal pressures: managers, political activists, or anyone in a security-related field. Rating: 8 out of 10

Since I've been working on qcontrol I've had need of a way to build packages in an ARM environment. Since all my native ARM hardware is "production" (at least so far as something can be production in a home environment) I prefer to avoid installing development tools on them. When I started looking into this all my ARM systems ran from relatively small flash devices which also ruled out the possibility of a development chroot. After search the web a bit I discovered that it is possible to use qemu-user-static together with [[!binfmt-support ]] to create cross architecture chroots which can be entered mostly transparently. It is also possible to combine this with schroot and sbuild which makes the day to day use pretty much the same as a native or biarch chroot. Since I've now had to rediscover how to do this twice (once for Sid and then again when I realized I also needed a Wheezy environment) I thought I should write it down for the benefit of my future self. First things first lets install the various packages which we need. As well as debootstrap to create the chroot we need qemu-user-static and binfmt-support to allow us to run ARM binaries:

$ sudo apt-get install debootstrap qemu-user-static binfmt-support

I'm using schroot's lvm-snapshot mode so we need an LVM volume, formatted with a filesystem and mounted in a temporary location:

$ sudo lvcreate -L8G -n sbuild-wheezy-armel /dev/VG
$ sudo mkfs.ext3 /dev/VG/sbuild-wheezy-armel
$ sudo mount /dev/VG/sbuild-wheezy-armel /mnt/

Next we need to create the chroot. For this we use debootstrap in foreign mode which does a 2 stage setup, firstly by using the --foreign option:

$ sudo debootstrap --variant=buildd --include=fakeroot,build-essential \
        --arch=armel --foreign \
        wheezy /mnt http://<DEBIAN-MIRROR>/debian/

Now we (temporarily) copy the qemu-arm-static binary into the chroot (at the place where binfmt-support expects it), change into the chroot and run debootstrap's second stage to finish the basic chroot setup:

$ sudo cp /usr/bin/qemu-arm-static /mnt/usr/bin/
$ sudo chroot /mnt
(chroot)# ./debootstrap/debootstrap --second-stage
(chroot)# exit

Now that we have a basic chroot in place it needs a little bit of tailoring. I've found the easiest way to do this is to use sbuild-createchroot and then tweak the result:

$ sudo sbuild-createchroot --arch=armel --foreign --setup-only \
    wheezy /mnt http://<DEBIAN-MIRROR>/debian/

If we were building a native chroot then we could have skipped the debootstrap stuff and let sbuild-createchroot handle things. Unfortunately this doesn't seem to play nicely with --foreign. Now we can remove the qemu-arm-static binary from the chroot. schroot will automatically bind mount the version from the host into the chroot which ensures it remains up to date. We can also unmount the chroot since we will let schroot manage that from here on:

$ sudo rm /mnt/usr/bin/qemu-arm-static
$ sudo umount /mnt

Next we need to tweak the resulting schroot/sbuild configuration since sbuild-createchroot assumes the use of schroot's directory mode. First remove the symlink to /mnt which it created:

$ sudo rm /etc/sbuild/chroot/wheezy-armel-sbuild

Lastly we need to edit /etc/schroot/chroot.d/wheezy-armel-sbuild-<SUFFIX> (where is randomly generated) and reconfigure it to use lvm-snapshot mode, by apply the following changes:

 [wheezy-armel-sbuild]
-type=directory
-directory=/mnt
+type=lvm-snapshot
+device=/dev/VG/sbuild-wheezy-armel
+lvm-snapshot-options=--size 2G
 description=Debian wheezy/armel autobuilder
 groups=root,sbuild
 root-groups=root,sbuild
 profile=sbuild

That's it, we now have a chroot which we can trivially invoke via sbuild to build armel packages:

$ sbuild --arch=armel --dist=wheezy <... other options...>

We can also use sbuild-update to keep the chroot up to date:

$ sudo sbuild-update -udcar wheezy-armel

You can also use schroot to login to the chroot directly, although for that case you'll likely want to create a different chroot using schroot's directory or block-device mode instead lvm-snapshot and drop some of the sbuild specific setup. I expect I'll blog about this configuration in some more detail at some point in the future since I'll want to document it to give a more convenient build environment for Xen on ARM than the build farm which we have at work.

This is the listing for my local cross-build-only repository for perl:

perl   5.14.2-16   unstable   armel, source

perl   5.16.2-1   experimental   armel, source

Prior to this, 5.14.2-15 also cross-built.

I've just pushed the update which fixes 5.16 from current Debian experimental.

This means that I'm ready to push perl-cross-debian into experimental via NEW. Whilst the package is in NEW, I will be approaching perl upstream about the necessary changes for Makefile.SH and updating the existing bug reports #285559 and #633884 with the necessary changes for debian/rules.

In the meantime, the changes for Makefile.SH and debian/rules exist within the perl-cross-debian source code - the patch for 5.14.2 is the same as I used for 5.16.2 and I don't see a need, yet, for this to be any different with current perl upstream. Equally, the patch for debian/rules works equally well for 5.14.2 and 5.16.2. All the version-specific (and architecture-specific) data lives in perl-cross-debian.

So it's time to tag perl-cross-debian 0.0.1 and upload to ftp-master as a native package aimed at experimental.

What's left to do? TESTING!

I've only tested with armel using the Emdebian cross-building toolchains from Squeeze using the old dpkg-cross style cross-dependency installation paths. There is outline code for armhf and arm64 but these need testing. The code also needs testing using the latest MultiArch cross-building toolchains. This should be a simple matter of checking if the dpkg-cross style paths exist and looking for MultiArch if not.

Right now, all of this is "worksforme" grade. It needs others to have a go and file bugs. Until the package is through NEW, feel free to use the issue tracker on the perl-cross-debian github site.

Please read through the documentation in the source code and the manpages in the package (xml in the source code) and tell me if some of it isn't clear.

Review: Peacekeeper, by Laura E. Reeve

Series:	Major Ariane Kedros #1
Publisher:	Roc
Copyright:	December 2008
ISBN:	0-451-46245-9
Format:	Mass market
Pages:	324

Ariane Kedros is a pilot of a second-wave prospecting ship. Second-wave prospectors are the first explorers into new systems after slower-than-light generation ships haul in the beacons that add them to the FTL network. She's also a reserve major in the Consortium military, which is a point of ongoing tension with her business partner and employer. She disappears on missions for the intelligence branch that she can't talk about, and usually ends up drinking herself into a stupor when she returns. In actuality, Kedros is not her real name. It's a fake identity given her after the last war, a war in which humans detonated a temporal distortion warhead for the first time and possibly destroyed an entire solar system. Kedros was part of the team that launched the bomb and is, according to the Terran Expansion League (the other side of the all-human conflict), a war criminal. She's in the equivalent of a witness protection program, as are all the other people involved in the act. But someone has broken their cover and is picking them off, one by one, and her latest secret mission from the Consortium is to protect another member of the group. Peacekeeper is Reeve's first novel, and unfortunately this shows badly at the start of the book. The writing is choppy and awkward, the paragraph breaks are a bit off, and the sentence structure kept making my teeth itch. I'm not a good enough technical critic to put a finger on what's wrong, but the writing doesn't flow. I also found myself anticipating and completing sentences in my head, which is a sign of too many low-level cliches. A few dozen pages into the book, the writing was bothering me, I hadn't warmed to any of the characters, and I wasn't sure I was going to like it. Ariane grew on me, though, particularly once she got into her mission and started balancing a cover assignment and her actual work. She's hurt, suffering from what's probably post-traumatic stress disorder and self-medicating with alcohol, but she's smart and competent and the plot is sufficiently tricky to provide a lot of meat. Not only is someone after her old team, but she and her partner discovered something potentially major on their last trip, an old friend of her partner has been murdered, the Consortium and the Terrans are negotiating a peace treaty, and all this is happening under the watchful eye of a superior alien race. The Minoans are probably Reeve's best creation here (if a little too similar to Vorlons at times). They're absolutely neutral, but they do not want humanity messing with temporal distortion weapons and are trying to nudge (or push) the humans into peace and disarmament. They are sticklers for not imposing their cultural practices on others, attempting to judge humanity solely by its own rules, but they're utterly literal-minded about rules. They expect everyone to follow any stated rules exactly and to the letter, making them excellent but frustrating overseers of disarmament treaties. They also have a fascinating tendency to interact with people in roles rather than as individuals. This is clearly the first book in an ongoing series, and a lot of the setup is not resolved here. We get only glimpses of what Ariane and her partner may have found, and only a few interactions with the Minoans, while Ariane tracks down who is responsible for killing her former team. There's a bit too much torture for my taste, and the subplot of Ariane's struggle with alcoholism wasn't really what I wanted to read about, but the writing seemed to get substantially better and the plot kept me turning the pages. There's a quality to military SF written by people who have actually been in the military that I find hard to describe but that helps a book tremendously. It didn't surprise me at all to learn that Reeve served in the US Air Force, since Peacekeeper has that quality. It's less about technical accuracy and more about a feel, a sense of what it's like to be inside a military routine and interacting with other military personnel. The culture feels coherent, despite not being described in detail. I think it makes for good SF in general, since it conveys to someone like me (who has never been in the military) a semi-alien but completely coherent culture. It certainly improves this book; in general, I thought Reeve's military characters were more interesting and more believable than her non-military characters. With the rocky beginning, the unpolished writing, and a villain who wasn't entirely satisfactory, I can't quite recommend Peacekeeper, but it's not a bad read. I'm not sure if I'll pick up the sequels, but I did leave it curious about the unresolved plot threads and willing to learn more about Reeve's world. Followed by Vigilante. Rating: 6 out of 10