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.

Review: A Paradise Built in Hell, by Rebecca Solnit

Publisher:	Penguin
Copyright:	2009
Printing:	2010
ISBN:	0-14-311807-2
Format:	Trade paperback
Pages:	319

A Paradise Built in Hell is a book with an agenda. Solnit's goal is to convince the reader that nearly everything we're shown in movies and popular culture about human behavior during disasters is wrong. Not only is destructive mass panic unusual verging on nonexistent, spontaneous cooperation and acts of startling courage and resourcefulness are commonplace. The heroes that we hear about afterwards are more the norm than the exception. Disasters are far more likely to bring out the best in people than the worst. They break down barriers and form spontaneous human communities that survivors remember for a lifetime. Rather than natural disasters leading inevitably to an exacerbating human crisis in the absence of strong authority, Solnit argues that they are an amazing human opportunity, and that the most negative and destructive human behavior during crises is not from untrained victims but from the panic of the elites who are supposedly responsible for protecting the public. I think her analysis and presentation is both deeply appealing and deeply flawed. The flaws involve extrapolation and generalization beyond the applicability of her research, and I'll say more about that in a moment. But the appeal is still surprising and satisfying, and I think there's a lot of truth in this book despite its one-sided presentation. I like to tell people, half-jokingly, that I'm an anarchosyndicalist. It's my political alliegance of the heart: the political structure that I know would never work, but that matches the world I want to live in. (I suspect much of the belief in libertarianism is of this form.) Now I have a book to point people at when they ask what the appeal of anarchosyndicalism is. The sense of spontaneous community, of bonding, of reaching out to other people to do something necessary, together, that Solnit describes here in the aftermath of a disaster matches that vision of a world without imposed economic authority, where people spontaneously collaborate to solve problems. A Paradise Built in Hell is structured by disaster, providing a tour of major disasters and their aftermath interspersed with extended musings on what the human reactions mean and how disaster communities functioned. The major disasters discussed are the 1906 San Francisco earthquake, the Halifax explosion, the 1985 Mexico City earthquake, 9/11, and Hurricane Katrina. Solnit moves through them in chronological order, closing the book with Katrina, which had (at least for me) the most infuriating and uplifting mixes of community bonding and elite panic. But both of those factors are present from the beginning in the 1906 earthquake: spontaneous human organization that (from multiple first-hand accounts) transformed people's lives mixed with a military reaction and elite panic that possibly did more damage to the city than the earthquake did. Elite panic is the dark side of Solnit's celebration of human altruism and spontaneous community organization. The primary picture she paints is of ordinary people responding with great courage and creativity and finding, in their reaction, a transformative experience and a sense of purpose that often becomes the most powerful and positive experience of their life. But this is at odds with a deeply-entrenched elite belief in mass panic, in the necessity of keeping information from the public to suppress their reaction, and in the need to re-establish "order." And with that, Solnit is absolutely scathing, and with some justification. Along with detailed accounts of these major disasters, Solnit also gives the reader a tour of the research literature on disasters, research that has shown that the panic and chaos that is at the center of practically every disaster movie ever made is essentially a myth. Mass panic in disasters is not only rare, it's close to non-existent. As you might expect, the handling of Katrina by both the government and by neighboring white communities is the subject of the harshest attacks. The material on Katrina presented here is enough to make anyone want to throw out the current playbook on how we react to disasters (and lest one think Solnit is unfair, her research matches very closely with other research and journalism on Katrina that I've seen from a wide variety of sources). But Solnit shows that this is a pattern: the combination of our media-driven belief in how people will react to disasters combined with the elite need to re-establish control plays out in many major disasters, and almost always negatively. Even in 9/11, the official response in some cases hampered and undermined an already-effective unofficial response. This is very interesting and has concrete implications for public policy around disasters. But where Solnit moves onto thinner anarchosyndicalist ice is the story that she tells about disasters as dramatic upheavals of the established social order that could point to a revolution in how we interact with each other. Solnit is deeply inspired by human altruism during disasters, and her enthusiasm is somewhat contageous, but it was useful to read this book shortly after Bruce Schneier's Liars and Outliers. I think Solnit, in her understandable eagerness to find a way to extend disaster behavior to general life, does not understand the relationships between what Schneier terms moral, reputational, and institutional pressures. And that's the core of why we need to both enable spontaneous human response in disasters and have organized first responders and supporting infrastructure, and why disaster communities will break down when extended beyond the disaster. When I first mentioned A Paradise Built in Hell to my mother, her first reaction was dubiousness due to her memory of the 1977 New York City blackout. There was a disaster that resulted in widespread looting and destruction, rather than the positive reaction Solnit describes. Solnit does have a cogent argument for why looting is poorly analyzed (we don't, for example, distinguish between breaking into stores to get desperately needed supplies and doing so for personal gain) and should not be a priority in a life-threatening disaster. But it's not completely convincing; in some disasters, particularly ones like the 1977 power outage that were not particularly life-threatening, the looting has been the most destructive part of the disaster. Schneier provides what I think is the missing piece, both to this and to why the wonderful behavior during disasters doesn't last into everyday life. During a life-threatening disaster, moral pressures are massively increased. Nearly all of us have self-images and moral beliefs that provide very strong incentives to help others and collaborate in the face of life-threatening emergencies, incentives that override other motives and lead to the sort of behavior that Solnit celebrates. But moral pressures have inherent limitations. That moral reaction applies most strongly to small groups (such as bands of survivors), and will start to break down as larger society re-establishes itself. And disasters, like a power outage, that are not immediately life-threatening will not provoke the same intensification of moral pressures: we don't have strong moral beliefs and internal stories about staying quietly at home during power outages the way that we do for saving people from burning buildings or pulling them out of rubble. Once larger communities have reformed and that short-term emergency reaction has dissipated, the need for institutional pressures (police, law, and formal authority structures) will return. I wish Solnit had been able to read Schneier's book before writing hers. I think his analysis structure provides a healthy dose of realism and perspective to her desire for a self-organizing communal world, and might have blunted her enthusiastic but somewhat unrealistic hopes for finding some key to a revolution in human organization in the heart of disasters. But if A Paradise Built in Hell is unlikely to lead to a radical change in how we organize societies, it should at least provoke a radical rethinking of some of our unnecessary pessimism about our fellow humans. The evidence is substantial and compelling: crisis brings out the best in people, not the worst, and the ordinary people who happen to be around are capable of becoming some of the most amazing disaster response teams that we can imagine. This has numerous mundane implications for social policy. We should consider simple training for the general public, for example, to strengthen that reaction, should allow for it in legal structures and training of first responders (around looting, for instance), and should do everything we can to kill the destructive myth that people cannot be trusted in disasters or that mass panic will be as much of a threat as the disaster. But the best part of this book is that it provides a concrete, well-documented, and well-defended reason to let go of some of our cynicism and to extend a bit of trust to our fellow humans. There sadly aren't earth-shaking implications for everyday society, but there is a wealth of evidence that shows that we're better people in the crunch than we believe we are, or that we expect of others. And the more that we can embrace the dissolution of boundaries and social hierarchies in the middle of disasters, the more we are likely to be surprised by deep human connection and a sense of shared, focused purpose. Solnit is a bit long-winded with her agenda, but that bright hope has stuck with me. Recommended. Rating: 8 out of 10

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!

In order to start the year in a good mood, what's the best than squashing some bugs on OpenStack? Therefore, the Ceilometer team is pleased to announce that it organizes a bug squashing day on the Friday 4th January 2013. We wrote an extensive page about how you can contribute to Ceilometer, from updating the documentation, to fixing bugs. There's a lot you can do. We've good support for Ceilometer built into Devstack, so installing a development platform is really easy. The main goal on this bug day will be put Ceilometer in the best possible shape before the grizzly-2 milestone arrives (10th January 2013). This version of Ceilometer will aim to keep compatibility with Folsom, so early deployers can enjoy some of our new features before upgrading to Grizzly. After that date, we'll start merging more extensive changes. We'll be hanging out on the #openstack-metering IRC channel on Freenode, as usual, so feel free to come by and join us!

Review: Cry Wolf, by Patricia Briggs

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

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

I just realized it's sunday again, so here goes my list of RC bugs I've worked on during the last week:

• #603428 snort-pgsql,snort-mysql: "snort: prompting due to modified conffiles which where not modified by the user"
  investigate with piuparts, later tagged/fixed by Salvatore Bonaccorso and Ivo De Decker
• #667995 python-cups: "cupsd configuration: "cupsdAuthorize: Empty Basic password!""
  backport fix from Fedora git, after Vagrant's test upload it to DELAYED/2
• #684732 release.debian.org: "unblock: nut/2.6.4-2.2"
  sponsor NMU prepared by Ivo De Decker, upload to DELAYED/1
• #694890 liblemonldap-ng-handler-perl: "liblemonldap-ng-handler-perl: fails to install: cp: cannot create regular file '/var/lib/lemonldap-ng/handler/MyHandler.pm': No such file or directory"
  upload package prepared by xguimard (pkg-perl)
• #696329 lemonldap-ng: "lemonldap-ng: CVE-2012-6426: SAML messages signatures are not verified"
  upload package prepared by xguimard (pkg-perl)

I just realized it's sunday again, so here goes my list of RC bugs I've worked on during the last week:

• #603428 snort-pgsql,snort-mysql: "snort: prompting due to modified conffiles which where not modified by the user"
  investigate with piuparts, later tagged/fixed by Salvatore Bonaccorso and Ivo De Decker
• #667995 python-cups: "cupsd configuration: "cupsdAuthorize: Empty Basic password!""
  backport fix from Fedora git, after Vagrant's test upload it to DELAYED/2
• #684732 release.debian.org: "unblock: nut/2.6.4-2.2"
  sponsor NMU prepared by Ivo De Decker, upload to DELAYED/1
• #694890 liblemonldap-ng-handler-perl: "liblemonldap-ng-handler-perl: fails to install: cp: cannot create regular file '/var/lib/lemonldap-ng/handler/MyHandler.pm': No such file or directory"
  upload package prepared by xguimard (pkg-perl)
• #696329 lemonldap-ng: "lemonldap-ng: CVE-2012-6426: SAML messages signatures are not verified"
  upload package prepared by xguimard (pkg-perl)

This post was written with Andr s Monroy-Hern ndez for the Follow the Crowd Research Blog. The post is a summary of a paper forthcoming in Computer-Supported Cooperative Work 2013. You read also read the full paper: The Cost of Collaboration for Code and Art: Evidence from Remixing. It is part of a series of papers I have written with Monroy-Hern ndez using data from Scratch. You can find the others on my academic website.

Does collaboration result in higher quality creative works than individuals working alone? Is working in groups better for functional works like code than for creative works like art? Although these questions lie at the heart of conversations about collaborative production on the Internet and peer production, it can be hard to find research settings where you can compare across both individual and group work and across both code and art. We set out to tackle these questions in the context of a very large remixing community. Remixing platforms provide an ideal setting to answer these questions. Most support the sharing, and collaborative rating, of both individually and collaboratively authored creative works. They also frequently combine code with artistic media like sound and graphics. We know that that increased collaboration often leads to higher quality products. For example, studies of Wikipedia have suggested that vandalism is detected and removed within minutes, and that high quality articles in Wikipedia, by several measures, tend to be produced by more collaboration. That said, we also know that collaborative work is not always better for example, that brainstorming results in less good ideas when done in groups. We attempt to answer this broad question, asked many times before, in the context of remixing: Which is the better description, the wisdom of crowds or too many cooks spoil the broth ? That, fundamentally, forms our paper s first research question: Are remixes, on average, higher quality than single-authored works? A number of critics of peer production, and some fans, have suggested that mass collaboration on the Internet might work much better for certain kinds of works. The argument is that free software and Wikipedia can be built by a crowd because they are functional. But more creative works like music, a novel, or a drawing might benefit less, or even be hurt by, participation by a crowd. Our second research question tries to get at this possibility: Are code-intensive remixes, higher quality than media-intensive remixes? We try to answers to these questions using a detailed dataset from Scratch a large online remixing community where young people build, share, and collaborate on interactive animations and video games. The community was built to support users of the Scratch programming environment: a desktop application with functionality similar to Flash created by the Lifelong Kindergarten Group at the MIT Media Lab. Scratch is designed to allow users to build projects by integrating images, music, sound and other media with programming code. Scratch is used by more than a million, mostly young, users. Measuring quality is tricky and we acknowledge that there are many ways to do it. In the paper, we rely most heavily a measure of peer ratings in Scratch called loveits very similar to likes on Facebook. We find similar results with several other metrics and we control for the number of views a project receives. In answering our first research question, we find that remixes are, on average, rated as being of lower quality than works of single authorship. This finding was surprising to us but holds up across a number of alternative tests and robustness checks. In answering our second question, we find rough support for the common wisdom that remixing tends to be more effective for functional works than for artistic media. The more code-intensive a project is, on average, the closer the gap is between a remix and a work of single authorship. But the more media-intensive a project is, the bigger the gap. You can see the relationships that our model predicts in the graph below. Both of us are supporters and advocates of remixing. As a result, we were initially a little troubled by our result in this paper. We think the finding suggests an important limit to the broadest claims of the benefit of collaboration in remixing and peer production. That said, we also reject the blind repetition of the mantra that collaboration is always better for every definition of better, and for every type of work. We think it s crucial to learn and understand the limitations and challenges associated with remixing and we re optimistic that this work can influence the design of social media and collaboration systems to help remixing and peer production thrive. For more, see our full paper, The Cost of Collaboration for Code and Art: Evidence from Remixing.

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

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

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

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

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

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

A member of SAGE-AU [1] found two ATM skimmers [2] and gave me permission to publish his description and analysis of the situation. I ve lightly edited this from a mailing list post to a blog format with permission from the author. This Courier-Mail article refers to the skimmers in question [3]. People were wondering what gave the skimmers away so here goes, NB this is only about the 2 I discovered.

1. The actual atms in question were the free standing type (but even this doesn t matter in the scheme of things because they can be on those in a bank of the things).
2. I d actually conducted transaction and was waiting for my card to come out of the machine these things looked that good. The colours matched especially in the 3/4 or less light that you typically have on the fascia s of such machine. The backing plate grey matched atm fascia as did the green bubble where the card goes.
3. WHAT REALLY CAUSED SUSPICION my card was having difficulty coming out of the atm at end of transaction i.e. card coming out extra slow then only the end couple of mm, I had to physically grab my card with fingertips to get it out and there was barely perceptible movement of skimmer due to my fingers using the green bubble as purchase point, THAT was what made me suspect. I then really had close look and found that I could move the bubble with its backing plate I pulled it off the machine and then looked at the atm next to it and found it to look exactly the same. These things are held on by double sided tape.
4. Grabbed the cleaning lady wandering past showed her the device and asked her to get security. Security and centre operations manager subsequently showed up, while waiting for them I had to stop people from using either machine (everyone amazed at how good these things looked). Centre ops guy went and checked other machines in the centre, I left my details and they called the cops I went straight to my credit union and reported what had happened and they cancelled my card and ordered a new one on the spot for me.
5. Coincidently (or not) the centre ops and security lady told me that the machines had been serviced (refilled) not too much earlier that day i.e. I wondered if the bad guys did the service or were tracking armaguard servicing types.

Quick side notes:

1. 3 more skimmers have been found since then.
2. Subsequently, I found out these were the type that needed to be picked up for the bad guys to retrieve the data i.e. these weren t the type that transmitted to some-one sitting near by via Bluetooth/wireless i.e. in this instance I need not have cancelled my card and gotten a new one from my credit union.
   HOWEVER, it is best practice if you discover one and you ve used that machine to immediately have your financial institution cancel your card and issue you a new one though getting the new one can take up to a week.
3. As I understand it, These 2 devices (i.e. others could be different) have 2 usb ports one for the reader and the other to a pinhole camera (commercially available type removed from it s original housing). The magnetic stripe data is held on the audio track associated with the video and there was an 8GB storage card to hold it all i.e. it makes things easier for the bad guys to match PINs to card details.
4. If you do find a skimmer DO NOT touch the insides (non public facing parts) of it this is where the cops can really try lift dna and prints from; gathering prints from externally is far more fraught as everyone and their dog has probably touched the exterior of the skimmer.
5. In the lead up to Xmas these things or similar are highly likely to become more prevalent as we all go about parting with dosh while gift shopping SO BE AWARE AND CAREFUL.

• [1] http://www.sage-au.org.au/
• [2] http://en.wikipedia.org/wiki/Skimming_(credit_card_fraud)#Skimming
• [3] http://tinyurl.com/aqu9yb6

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.

Yesterday's release of Rcpp 0.10.2 required a small change to RcppClassic, the package supporting the deprecated older classic Rcpp API defined in the earlier 2005 to 2006 releases. So version 0.9.3 of RcppClassic is now on CRAN. There is no new user-facing code. Courtesy of CRANberries, there is the set of changes relative to the previous release 0.9.2. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

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

Forgot to blog about this (though I posted on Google+ about it), but we went to a neat little concert in the neighborhood on October 6. Chicago's own Patricia Barber came to the wonderful Unity Temple by Frank Lloyd Wright (more on the temple at Wikipedia and the foundation). This closed the 2012 series of the Unity Temple concerts and the setting was a little, well, weird. Look like mostly concert subscribers, with the commensurate age brackets, and not too many jazz folks. Not sure how many Patricia Barber, along with Larry Kohut on bass, won over, but I enjoyed it. I had secured front row (!!) seats in what is already an wonderfully intimate setting for such a duet concert. See the Google+ link for a YouTube recording by her.

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!

Care2 has an interesting article about people being offended by a picture of a poor Afro-American boy using an iPad [1]. It seems that people object to poor people having what is in many ways the greatest educational tool available because it can also be seen as a status symbol. I wonder if one of the cheaper Android tablets (at 1/3 the price of an iPad or less) would get the same response. Dvice has an inspiring article by Evan Ackerman about an experiment where a large quantity of Motorolla Xoom tablets were delivered to Ethiopian kids who couldn t read and didn t know English [2]. The kids learned printed English and learned to hack the devices to enable all the hardware features! I don t expect that kids in first-world countries would get the same benefits as kids in countries such as the US and Australia are distracted by TV, games consoles, and other forms of entertainment that aren t readily available in Ethiopian villages. But the potential benefits for widespread deployment of tablets in the poorer parts of first-world countries seems significant. I think that the government of every first-world country should give a voucher to every resident who is more than two years old for a $100 discount off the list price of a tablet. If someone is happy with a cheap Android tablet then $100 will cover the prices. If they want something better then they can pay more. I m happy for wealthy people to get a $100 discount on the price of one of the more expensive tablets, it seems that means testing such government subsidies just causes political issues without saving much money. Apart from the obvious educational benefits for people who own tablets (which means adults as well as children) there are also benefits in having everyone own a tablet. If everyone owned a tablet then the resale price of a low-end tablet would approach zero and the resale price of even more desirable tablets such as the iPad would drop a lot. This would reduce the incentive to steal tablets and allow people to use them in situations where there is less safety. If most people felt safe to use a tablet computer on public transport and started doing educational things instead of reading newspapers then it would improve the overall education of the population. Newspapers generally aren t educational and in the case of News Corp publications and other tabloids you can become less well informed by reading them I believe that on average newspapers have a negative educational value in Australia. The cost of giving a $100 tablet voucher to every resident of Australia would be about $2,200,000,000 (plus administrative costs) which seems like a lot of money. But when compared to the costs of building infrastructure it s not significant. I ve just read some government announcements regarding transport budget which includes items such as $6,500,000 to determine the best route for a new rail line. So if we were to get 350 new rail lines (and we need more than this) then merely determining the routes would cost as much as getting a tablet for everyone in the country!

• [1] http://www.care2.com/causes/why-is-the-us-so-insulted-by-welfare-queens.html
• [2] http://dvice.com/archives/2012/10/ethiopian-kids.php