John Scalzi wrote an insightful post about the utility of blog comments with the way the Internet works nowadays [1]. He starts out focusing on hate comments that could reasonably be described as terrorism (death threats with the aim of preventing people writing about politics meet any reasonable definition of terrorism ). Terrorists on the Internet are a significant problem but it s one that doesn t get much attention as it generally only affects people who aren t straight-acting white men. Blogging About Technology One corner case that John doesn t seem to consider is that of writing about technology. Issues related to programming often aren t related to politics and are often testable so comments will be based on things that have been shown to work rather than stuff people invent or want to believe. I ve received many useful and educational comments on my technical posts with little hostility. Even getting a snarky comment is rare when writing a strictly technical blog post. The comments problem for technology blogging is spam. I ve been using the WordPress plugin Block Spam by Math [2] (which is obsolete but still works) for years. Initially it stopped almost all spam, but now I m getting at least 20 spam comments a day. Extremely Popular Blogs The comments section of a blog is sometimes described as a conversation . When a blog post gets comments from less than 10 people it is possible for them to have something that resembles a conversation with the author that is of benefit to other readers and doesn t take excessive amounts of time for the author. When a blog is very popular and every post gets comments from 50+ people it s not really possible. So a traditional blog comment section seems to work best when the blog is primarily read by a small well connected group of people who sometimes comment and some casual readers who never comment (but sometimes find value in the comments of others). Discussions of blog comment systems usually include a reference to a post written by someone who disabled comments on their blog and found it to be a good thing, it always seems that the person who writes such a post has a large and varied audience who s comments would take a lot of time to moderate. John followed the usual form in this regard by linking to a reasonably popular SF author who would presumably have a lot of fans with good net access. I m not going to criticise anyone for disabling comments when their blog becomes really popular, but any advice that they have to offer about such things won t apply to the vast majority of blogs. Due to the long-tail effect the small blogs would probably comprise the majority of all comments so in terms of the way the blog environment works I don t think it makes much difference when the small minority of very popular blogs disable comments. The vast majority of blogs that I regularly read only have a small number of comments. One thing that should be noted is that getting a lot of readers shouldn t be the only factor for writing a successful blog. For example some of my blog posts about SE Linux are aimed at a small audience of Linux programmers and have an even smaller number of people who are qualified to comment. When I write a post that can only receive comments other than please explain more because I don t understand from a few dozen people that doesn t make it any less important. Sometimes the few dozen people who know a topic well need to work together to educate the few thousand who can implement the ideas for the benefit of millions of users of the software. Disabling Comments on Contentious Posts One interesting method John uses is to disable comments early when posting about contentious issues. It s a general practice when running a blog to disable comments on posts after a certain period of time (3 months to 1 year seem to be common time limits for comments). This means that the moderators can concentrate on recent posts and not be bothered with spam bots hitting ancient posts as the interest in writing legitimate comments on an old post is vanishingly small. John has a practice of disabling comments after a couple of days when the comments start to lose quality. No matter how contentious the issue is I m not likely to get the 400+ comments that John gets. But the idea of closing comments quickly still has some merit for my blog and other blogs with less traffic. Not Accepting Comments While Asleep John has a practice of closing comments while he s asleep to avoid allowing a troll to get 8 hours of viewing for a nasty comment. The most immediate down-side to that is that it inconveniences people who don t want to wait 8 hours to comment and prioritises comments from people in the same time zone, this makes me think of Cory Doctorow s novel Eastern Standard Tribe (which is available for free download and I highly recommend reading it) [3]. It seems that a better solution to that problem would be to have a team of moderators to watch things 24*7 which is what a lot of popular blogs that allow comments do. The WordPress capabilities model doesn t support granting a user no special privileges other than moderating comments [4], as WordPress is the most popular self-hosted blog software this limits the possibilities for people moderating comments on other people s blogs. No variation of this would work for me. I have lots of things that require my ongoing attention and don t want to add my blog to the list. If I have other things to work on for a few days I want to just not bother with my blog. This means that my blog needs to be able to run on autopilot for days at a time however I do monitor my blog closely after publishing a post that is likely to attract nasty comments. One extra problem that I have is that the Android client for WordPress has problems in synchronising comments. Using a Forum for Comments Popular Planet installations such as Planet Debian and Planet Linux Australia syndicate more than a few blogs that have comments disabled. A forum installation for such a Planet would be useful to allow people to comment on all posts and also support bloggers who are thinking of disabling comments. While the use of a forum for blog comments has been proven to work well for Boing Boing forums have their own issues of spam and anti-social behavior. Debian already has a forum [5], if a section of that was devoted to discussing blog posts from Planet Debian then it shouldn t make much of an increase to the work of the forum administrators while providing a benefit to the community. Also if the Debian forum had such a section it would probably attract use from more Debian Developers, I would use that forum if it was a place to comment on blogs that don t have a comment section and I might also comment on other forum discussions. It would be good if there was a forum for discussing Linux in Australia. I m not volunteering to run it but I would help out if someone else wants to be the main sysadmin and I can offer free hosting.

• [1] http://whatever.scalzi.com/2013/08/28/various-thoughts-on-online-comments/
• [2] http://wordpress.org/plugins/block-spam-by-math/
• [3] http://craphound.com/est/?page_id=1574
• [4] http://codex.wordpress.org/Roles_and_Capabilities
• [5] http://forums.debian.net/

The Debian FTP masters have for quite a while a line in their reject FAQ about the PHP license. Despite that, quite a lot of PHP extensions were uploaded to the archive and accepted. Some are being managed/developed in PHP.net s PECL website, and are done under the umbrella of the PHP Group, which is the group the PHP license is refers to. Over time, we started to see many more extension being developed outside of the PHP group (both technically with sites like github and copyright wise). This is true to certain degree with the PHP.net s PEAR website which has software written in PHP. The issue has been raised again in October 2013 with php-gearman using the PHP license while having different copyright holders (bug #728196). After discussions (ftp masters, release team & Ond ej), it was agreed that the current interpretation is still relevant, and almost all extensions and applications should be either removed or re-licensed by its upstream. This makes the todo list 41 packages long (full list based on Ond ej Sur s bug reports). Any help with contacting upstream projects, explaining the situation and requesting a license change would be welcomed. We also need to monitor new release based on fulfilling these requests. Until such a change happen, with automatic removal of packages from testing, we re going to see packages disappear after mid July. This has a little wider affect due to package dependencies, but for the moment only on testing (Jessie).
Filed under: Debian GNU/Linux, PHP

Russ Albery wrote an insightful blog post about trust, computer security, and training programmers [1]. He makes a good case that social problems in our community decrease the availability of skilled people to write and audit security code. The Lawfare blog has an insightful article by Dan Geer about Heartbleed as a Metaphor [2]. He makes some good points about security and design, ways of potentially solving some flaws and problems with the various solutions. Eben Moglen wrote an insightful article for The Guardian about the way that the NSA spying is a direct threat to democracy [3] The TED blog has an interesting interview with Kitra Cahana about her work living with and photographing nomads in the US [4]. I was surprised to learn that there s an active nomad community in the US based on the culture that started in the Great Depression. Apparently people are using Youtube to learn about nomad culture before joining. Dave Johnson wrote an interesting Salon article about why CEOs make 300* as much money as workers [5]. Note that actually contributing to the financial success of the company is not one of the reasons. Maia Szalavitz wrote an interesting Slate article about Autism and Anorexia [6]. Apparently some people on the Autism Spectrum are mis-diagnosed with Anorexia due to food intolerance. Groups of four professors have applied for the job of president and vice-chancellor of the University of Alberta [7]. While it was a joke to apply in that way, 1/4 of the university president s salary is greater than the salary of a professor and the university would get a team of 4 people to do the job so it would really make sense to hire them. Of course the university could just pay a more reasonable salary for the president and hire an extra 3 professors. But the same argument applies for lots of highly paid jobs. Is a CEO who gets paid $10M per annim really going to do a better job than a team of 100 people who are paid $100K? Joel on Software wrote an insightful article explaining why hiring 1/200 applicants doesn t mean you hire the top 0.5% of workers [8]. He suggests that the best employees almost never apply through regular channels so an intern program is the only way to get a chance of hiring the best people. Chaotic Idealism has an interesting article on some of the bogus claims about autism and violence [9]. Salon has an interesting articleby Lindsay Abrams about the way the food industry in the US lobbies for laws to prevent employees from reporting animal cruelty or contamination of the food supply and how drones will now be used for investigative journalism [10]. Jacobin Mag has an interesting article by Geoff Shullenberger about the Voluntariat , the people who volunteer their time to help commercial organisations [11]. I don t object to people voluntarily helping companies, but when they are exploited or when the company also requires voluntary help from the government it becomes a problem. We need some legislation about this. Laura Hudson wrote an insightful article about how Riot Games solved their online abuse problem [12]. There are ideas in this that can apply to all online communities. Matt LeMay wrote an interesting article for Medium titled What (Else) Can Men Do? Grow The Fuck Up [13]. It s a general commentary on the treatment of women in geek communities (and most other places). Foz Meadows wrote an insightful analysis of the attempts of bigots to influence science-fiction [14]. If I had more spare time I d read some of the books by bigoted authors on the Sad Puppy Slate (from a library of course) and see if they lack talent in the same way that Orson Scott Card does. Racialicious has an interesting article by Phenderson Djeli Clark about the horrible racism and bigotry of H.P. Lovecraft [15]. I have only read two HP Lovecraft stories, one was mediocre and the other (The Horroe at Red Hook) was quite poor largely due to his inability to write about non-white people. Grace Wyler wrote an insightful article for Vice magazine about the right-wing terrorists in the US killing cops [16]. Paul Rosenberg wrote an interesting and amusing (for people outside the US) article about the gun crazies in the US [17]. Maybe the gun crazies should have a loaded assault rifles and tequila party to follow up on their gun appreciation day . A US TV show made a 4 minute clip of some of the stupid things that Tony Abbott has done [18]. Tony is almost as stupid as Dubya.

• [1] http://www.eyrie.org/~eagle/journal/2014-04/003.html
• [2] http://www.lawfareblog.com/2014/04/heartbleed-as-metaphor/
• [3] http://tinyurl.com/kcocf7o
• [4] http://tinyurl.com/kysyz77
• [5] http://tinyurl.com/qyt9qf8
• [6] http://tinyurl.com/m95dv8q
• [7] http://tinyurl.com/ka27qyg
• [8] http://www.joelonsoftware.com/items/2005/01/27.html
• [9] http://chaoticidealism.livejournal.com/134561.html
• [10] http://tinyurl.com/nv3ygzm
• [11] https://www.jacobinmag.com/2014/05/the-rise-of-the-voluntariat/
• [12] http://www.wired.com/2014/05/fighting-online-harassment/
• [13] http://tinyurl.com/phrq937
• [14] http://tinyurl.com/kye63mw
• [15] http://tinyurl.com/me2aj5a
• [16] http://www.vice.com/read/whats-behind-all-the-right-wing-cop-shootings
• [17] http://tinyurl.com/pynqmls
• [18] http://tinyurl.com/khkav88

Vangelis' soundtrack for the movie Blade Runner is one of my favourite film soundtracks. Its troubled history is reasonably well documented on Wikipedia . At the time of writing, that article doesn't mention the recent 2013 reissue which was remastered and released on Vinyl, and possibly SACD too. Last year I spotted this record and bought it for a friend's birthday. In the year since I've eventually gave into temptation and bought another copy for myself. This was a little unfortunate in terms of timing as my record player has been packed away for two months pending a house move. I did manage to test it out on a Numark PT-01 but it really needs a proper setup to do it justice. In the mean time, one can watch a video of someone else's copy playing: In related news, I've recently enjoyed the BBC's adaptation of Do Androids Dream of Electric Sheep?, as part of their "Dangerous Visions" series. Much like the film, the play elides a lot of material from the book; including Deckard's wife and (more sadly) the entire Buster Friendly / Mercer side-story. However it retains the second police station, which (to me) was the key, classic Dick "What-the..." moment in the novel.

Review: The Knowledge, by Lewis Dartnell

Publisher:	Penguin
Copyright:	2014
ISBN:	0-698-15165-8
Format:	Kindle
Pages:	328

The cover pitch for The Knowledge is that technological civilization has collapsed. A war, an asteroid, a pandemic, or some other catastrophic event has ended life as we know it. Survivors have recovered enough to stabilize the population, but all the industry and infrastructure that supports the modern world has been crippled and the knowledge lost. What do they need to know to rebuild the world? (The subtitle, How to Rebuild Our World from Scratch, is deceptive. Dartnell spends a lot of time talking about what could be scavenged from the ruins after an event like a pandemic that leaves buildings and tools intact.) This brief description may bring several incorrect ideas to mind, so a few clarifications are in order. First, this is not a book about how to survive an apocalypse, or how to stabilize society afterwards. Dartnell skips over anything related to basic survival or politics, and this book would only be of limited interest to preppers. Rather, it is focused on the key concepts and key processes that underlie much of what makes up our civilization, and how those processes can be bootstrapped and recreated, hopefully much more quickly than the thousands of years they took to develop the first time around. Second, as much as I think Dartnell would have liked it to be, The Knowledge is not an instruction manual. There's just too much involved in modern machinery, metallurgy, chemistry, and other necessary science and engineering. What it is instead is a tour of the most important ideas, basic processes, and approaches that can lead to creation of an industrial economy. This means it's also a tour of the most critical technology and discoveries that we rely on for day-to-day living. Each idea presented here is a bare sketch, and would require extensive research and experimentation to put into practice. The Knowledge is not a scientific encyclopedia. Rather, it's a collection of signposts and suggested directions along with some suggestions about sequencing, with special emphasis on the ideas that were unintuitive or surprising, or which took humans much longer to stumble across than would have been necessary. I will say up front that I am quite dubious about the stated goal of this book. I'm not sure if it would be of significant assistance to people who found themselves in the circumstances that Dartnell postulates, and I'm also not sure it would be as difficult as Dartnell supposes to reconstruct these details from a good library, although the point is well-taken that most modern industrial techniques would be unavailable to a civilization starting from scratch and many historic techniques are no longer practiced and therefore not well-documented. But this book does not have to succeed at its stated goal to be worth reading. The Knowledge provides a fascinating insight into the way our current capabilities developed, other paths that development could have followed, and what building blocks are vital for the industry that we rely on. If you are like me, the first thing The Knowledge will remind you of is Minecraft, particularly with some of the mods (such as TerraFirmaCraft) that add more realistic detail to the technological bootstrapping. It's a treasure trove for anyone who might be working on that sort of mod or game. Dartnell tries to cover as much of the spectrum of technology as possible, from farming through medicine, from basic materials to industrial chemistry, and from electrical power through transportation. Each chapter necessarily covers only the highlights, the most vital technologies and the early priorities, and many of those are relatively vague pointers. But that's enough for a fascinating orientation. It's also full of memorable trivia: the huge variety of uses to which wood can be put, the difficulty in re-establishing production of industrial acids, the shelf life of gasoline, the global seed vault within the Arctic Circle, and the importance of a long-threaded screw for a lathe, just to name a few examples. In short, The Knowledge may or may not be a practical aid in rebuilding the world, but it's a lot of fun to read and full of tidbits that are fun to think about or pass on to others. It's also a great orientation in applied technology. The Knowledge is particularly fascinating if you have any interest in the simplified recreation of technological and industrial processes, such as in Minecraft and similar games. For authors of Minecraft mods who are aiming for realism, it might even be required reading. I'd love to see more mods based heavily on the approaches described in this book. The Knowledge also conveys, better than any book or course I've seen, an intuitive feel for the amazing complexity and ingenuity underlying industrial technology. I pre-ordered a copy of this book as soon as I heard about it, and I was not disappointed. Despite my certainty that I would be one of the early casualties in any general social collapse, I thoroughly enjoyed reading it, and would like to read it again at some point. Recommended, albeit with the caveat that I do not have the background required to verify any of the facts in this book, and am assuming that Dartnell has done his research properly. Rating: 9 out of 10

As previously mentioned I've been working on git-based DNS hosting for a while now. The site was launched for real last Sunday, and since that time I've received enough paying customers to cover all the costs, which is nice. Today the site was "relaunched", by which I mean almost nothing has changed, except the site looks completely different - since the templates/pages/content is all wrapped up in Bootstrap now, rather than my ropy home-made table-based layout. This week coming I'll be slowly making some of the implementation available as free-software, having made a start by publishing CGI::Application::Plugin::AB - a module designed for very simple A/B testing. I don't think there will be too much interest in most of the code, but one piece I'm reasonably happy with is my webhook-receiver. Webhooks are at the core of how my service is implemented:

• You create a repository to host your DNS records.
• You configure a webhook to be invoked when pushing to that repository.
• The webhook will then receive updates, and magically update your DNS.

Because the webhook must respond quickly, otherwise github/bitbucket/whatever will believe you've timed out and report an error, you can't do much work on the back-end. Instead I've written a component that listens for incoming HTTP POSTS, parses the body to determine which repository that came from, and then enqueues the data for later processing. A different process will be constantly polling the job-queue (which in my case is Redis, but could be beanstalkd, or similar. Hell even use MySQL if you're a masochist) and actually do the necessary magic. Most of the webhook processor is trivial, but handling different services (github, bitbucket, etc) while pretending they're all the same is hard. So my little toy-service will be released next week and might be useful to others. ObRandom: New pricing unveiled for users of a single zone - which is a case I never imagined I'd need to cover. Yay for A/B testing :)

Jim has been busy as part of the procps-ng team that looks after top. Basically all the changes you find in top from around 2.7 or so are by him. Not satisfied enough with fixing top, making it faster and showing more fields, he has given us CPU and memory graphs. He also thinks I don t have enough colours (or as he would put it colors) on my top output so I ve posted what the new top looks like for me so you can see the graphs and he can see my colours. I think it is both colourful and useful addition. The colours have been available for a while now and the graphs will appear in the next upstream release of procps-ng.

AddThis:

Categories:

• Debian-Blog

Keywords:

• fcoe

As I care to have all the Lintian output and warnings, I have this in my ~/.lintianrc:

info=yes
display-info=yes
display-experimental=yes
pedantic=yes
show-overrides=yes
color=auto

So, by default, my Lintian setup displays all pedantic warnings. However, it s been annoying me with the debian-watch-may-check-gpg-signature, which I don t really care about since 1/ there s never such a PGP stuff upstream, and 2/ I mostly use Git tags from upstream, in which I do check signatures whenever possible (and mostly, if I have upstream s key in my keyring after a key signing party, which happened a few times). The solution? Well, very easy:

sudo sed -i 's/Disable-Tags:/Disable-Tags: debian-watch-may-check-gpg-signature,/' /usr/share/lintian/profiles/debian/main.profile

There s nothing more to it! Of course, you can also create your own profile, with the added benefit that your changes wont be overwritten on next upgrade. But that s overkill if you re alone in the system, and anyway it s damned easy to do the changes again, plus I often reinstall this computer from scratch. With the above, you can of course disable the display of any tag you wish.

DNSSEC is one of those things that have been on the I should poke at that sometime list, but today I decided to actually get in and play around with it. Turns out it s pretty trivially easy to setup, but I got bitten by a few gotchas during testing, that I thought worthwhile to document. Since I like to explain things, a lot of this article isn t how to so much as how does .

Configuring The Resolver First off, you need a resolver¹ that you can trust, and which implements DNSSEC validation. In theory, you could use your ISP s resolvers (if they re DNSSEC-enabled), or even Google s public resolvers (8.8.8.8 and 8.8.4.4), but it s really not recommended how much do you trust those, really? More importantly, how much do you trust the network path between them and you? Frankly, running a local on-host caching resolver is trivial, consumes next-to-no resources, and is highly recommended. It s what I did. I used unbound, finally casting free the venerable dnscache, which has served me well for many years. I chose unbound because it fits the do one small thing, and do it well philosophy that I cherish (unlike BIND), and because it s what all the cool kids appear to be using these days. Installing it was as simple as apt-get install unbound it s available in pretty much every distro, I believe. Out of the box, unbound in Debian wheezy comes configured for DNSSEC validation. Other methods of installation might not be so amenable, so just make sure your unbound.conf liiks like this, so that DNSSEC is enabled:

server:
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    val-log-level: 2

The val-log-level line isn t strictly required, but I found it useful to have unbound log info on validation failures to syslog. Season to taste. You also have to configure your system to actually use your new, shiny local resolver. Editing /etc/resolv.conf would, in an ideal world, work Just Fine, but between Magical Unhelpful Pixies (I m looking at you, NetworkManager) and DHCP, it often isn t that easy. Ultimately, though, you should configure your system so that the only resolver in /etc/resolv.conf is always 127.0.0.1. Anything else is a security hole waiting to happen. If you re using DHCP and a recent version of ISC dhclient, adding supersede domain-name-servers 127.0.0.1; to dhclient.conf should do the needful.

Weighing the (Trust) Anchor Whatever local resolver you choose, you need to tell it about trust anchors . This is a key (or keys) which are trusted to sign all the other data that the resolver will find. Like the rest of the DNS, DNSSEC is hierarchical, and you need to know who to start with before you can start. To resolve a name using DNS, you ask the root servers for the answer to a question (say, what is the address of www.example.com? ). The root server doesn t know the answer, but it knows who to ask, and it tells you where to go (typically, go ask the DNS servers for .com, which are X, Y, and Z ). Then you ask those servers, and they probably don t know, but they know who to ask, and they tell you to go ask those servers. This continues until you finally get a server which says, oh, yes, I know the answer to that! and hands over the information you re after. In DNSSEC, you get digital signatures that prove that the answers you get from each DNS server you ask are legit, and not forged. So when you ask the root servers, what is the address of www.example.com? , they answer, I don t know, but go ask DNS servers at addresses X, Y, and Z and by the way, you can trust this answer is legit because here s this signature you can check . To verify a signature is legit, you need to know that the key used to make the signature is trustworthy, and it wasn t just any ol key that made it similar to how an ink scribble on a page doesn t mean anything unless you know what the signature you re looking at should look like. DNSSEC has two ways to make sure you know who to trust. Firstly, those trust anchors I mentioned three paragraphs ago. These are the keys that the root servers use to sign the responses they send out. You tell unbound (or your local DNSSEC-enabled resolver of choice), if you see a signature provided by this trust anchor key, you can trust it to be legit . The second way to trust is key is to have someone you already trust say, oh, you can trust this key, too . This is done by providing more data in the answer that you get from the root servers. So the full answer you get from the root servers when you ask, what is the address of www.example.com? looks like this:

I don t know, but you should ask the DNS servers at addresses X, Y, and Z. You can trust their answers because they ll sign their responses with key K. Finally, you can trust that I m legit because of this signature I m providing you, generated from key T.

Assuming that T is the trust-anchor key you ve already told unbound to trust, it can then trust all of the information it got from that first question. When it then goes to DNS server X and asks, Hey, do you know the address of www.example.com? , that server can send back its own response saying:

Gee, shucks, I don t know, but DNS servers at P and Q can help you. You can trust them because they ll sign responses with key S. And just to show you I m on the level, check out this nifty signature I made, signed with key K.

Since a server we trust told us to trust key K, and then we got a response signed by key K that told us to trust key S, when we then go and ask server P and get a response signed by S, we re still demonstrably secure. Neat setup, right? Anyway, now you know all about trust anchors. How do you set it up? For unbound, it s capable of priming the trust anchor itself. It does this by retrieving a copy of the trust anchor from [a well-known HTTPS URL]((https://data.iana.org/root-anchors/root-anchors.xml), which provides a reasonable measure of security the trust anchor file should be safe as long as that HTTPS server is trustworthy. For the properly paranoid, you should determine an alternate means of verifying that you have the correct root key (a web search for DNSSEC root key attestation would probably be a good start).

Testing It s always handy to know that something s working as you expect. For something that s important for security, that goes double. So, how do you test that your DNSSEC-capable resolver is, indeed, working as designed? Well, firstly, you can test that the resolver, by itself, is working. This is simple: do a query for a zone known to have broken DNSSEC. Thankfully, some nice people (Comcast, specifically) have already set this up. You can test a resolver for DNSSEC-correctness with this command:

dig @127.0.0.1 www.dnssec-failed.org

If dig gives you back an IP address, something is broken. The correct, my DNSSEC works! response should be a status: SERVFAIL response. That s all well and good, but having a resolver that works isn t much good if nothing s actually using it. Your system configuration has probably got some other resolvers configured into it (such as those provided by a DHCP server), and you ll want to make sure those aren t getting used². The trivial test is to visit http://www.dnssec-failed.org in your browser. If that comes back with a page, then something s still wrong. A more user-friendly test of your DNSSEC configuration is provided by http://dnssectest.sidnlabs.nl/test.php, which will display a page either way, and give you a tick or a cross depending on whether you re DNSSEC-enabled or not. One thing to be wary of when you re doing browser tests is caching. I spent far too long trying to work out why unbound wasn t working , when in actual fact it was working fine, it s just that both my browser and local caching proxy (squid) were caching DNS requests³. So, even after I d correctly setup unbound, visiting the test sites was providing me with erroneous results. Fixing up the browser was simple enough. In Chromium, visiting chrome://net-internals#dns will show you what s being cached, what resolv.conf settings are being used, and allow you to clear the browser s resolver cache. Squid was similarly simple, although it took me a while to figure out that it was causing me grief (software that just works , being so rare, tends to slip your mind, and so I often forget that squid is actually doing me good). Restarting squid has the appropriate result (clears the DNS cache), but in the end I decided that having another layer of caching wasn t going to help significantly when I ve got an on-host DNS cache already, in unbound. So, I just turned the knobs for DNS caching in squid right down:

negative_dns_ttl 1 second
positive_dns_ttl 1 second

And voila! All was well.

In summary DNSSEC is cool. It s easy to get going with, and over time it will provide more and more practical benefits (I am a DANE fanboi). Get started with it now, and you ll be ahead of the curve.

---

1. A resolver is a program which takes a name, does all the DNS queries required to get the data associated with that name, and return it to whoever wanted to know. This can be a library which links to a client application, or it can be a separate program which receives DNS requests itself. There are usually both types of resolvers in use for a typical Linux system to resolve names. On every machine, in every program, there is the so-called stub resolver , which is part of libc, and does nothing except create DNS requests and send them to the addresses listed in resolv.conf. Also present, although not always running on every machine (typically your ISP or network admin has some running for everyone to share) are one or more recursive resolvers , which are separate programs which take DNS requests, do all of the queries themselves, and return the result to the stub resolver for presentation to the client program which made the request in the first place. You will see this material again.
2. You can configure dhclient to use your local resolver instead of the DHCP-provided ones by simply setting:

   supersede domain-name-servers 127.0.0.1;
   

   in your dhclient.conf file.
3. It also didn t help that I hadn t correctly knobbled dhclient the first time around, and so even when I thought I was only resolving against my local unbound server, it was still actually using the DHCP-provided resolvers

One which ends in tears, I m afraid. A week or so ago, I got an MacBook Air 13 (MacBook Air 6-2), to take with me when I head out to local hack sessions, and when I travel out of state for short lengths of time. My current Thinkpad T520i is an amazing machine, and will remain my daily driver for a while to come. After getting it, I unboxed the machine, and put in a Debian install USB key. I wiped OSX (without even booting into it) and put Debian on the drive. To my dismay, it didn t boot up after install. Using the recovery mode of the disk, I chrooted in and attempted an upgrade (to ensure I had an up-to-date GRUB). I couldn t dist-upgrade, the terminal went white. After C-c ing the terminal, I saw something about systemd s sysvinit shim, so I manually did a purge of sysvinit and install of systemd. I hear this has been resolved now. Thanks :) My machine still wasn t booting, so I checked around. Turns out I needed to copy over the GRUB EFI blob to a different location to allow it to boot. After doing that, I could boot Debian whilst holding Alt. After booting, things went great! Until I shut my lid. After that point, my screen was either 0% bright (absolutely dark) or 100% (facemeltingly bright). I saw mba6x_bl, which claims to fix it, and has many happy users. If you re in a similar suggestion, I highly suggest looking at it. Unfortunately, this caused my machine to black out on boot and I couldn t see the screen at all anymore. A rescue disk later, and I was back. Annoyingly, the bootup noise s volume is stored in NVRAM, which gets written out by OSX when it shuts down. After consulting the inimitableMatthew Garrett, I was told the NVRAM can be hacked about with by mounting efivarfs on /sys/firmware/efi/efivars type efivarfs. Win! After hitting enter, I got a kernel panic and some notes about hardware assertions failing. That s when I returned my MacBook and got a Dell XPS 13.
This is a problem, folks. If I can t figure out how to make this work, how can we expect our users? Such a shame the most hardware on the planet gets no support, locking it s users into even less freedom.

Review: The Wilding, by C.S. Friedman

Series:	In Conquest Born #2
Publisher:	DAW
Copyright:	2004
Printing:	July 2005
ISBN:	0-7564-0202-6
Format:	Mass market
Pages:	551

In Conquest Born is a rather odd space opera, featuring an interstellar war between two great empires that culminates in an intensely personal struggle between leaders of the two sides. It has one of the most intensely misogynistic societies in science fiction (the villains, yes, but weirdly ambiguous villains), genetic breeding programs for telepaths, and a host of unlikable but oddly fascinating characters. I thought it was weaker on re-read than I remembered it being originally, but it's still singular enough in memory that I wanted to read the sequel. The Wilding picks up in the same universe a century and a half later. I expected more of a direct connection to the plot of In Conquest Born, but I think this book could be read on its own. (This is good, given how the plot of In Conquest Born tends to slip out of my memory, despite how unique the book is.) The Azeans and the Braxins are, of course, still at war, an on-again, off-again affair that neither side seems likely to ever win. But the Azeans have forbidden psychic powers and driven all psychics underground, if they still exist at all. They are supposedly too unstable to be allowed in the carefully constructed Azean society. Tathas is Braxin, but not from the ruling Braxan tribe. He is caught practicing old rituals of his native tribe and escapes sentence of death by going on the Wilding, an ancient practice of leaving Braxin culture to find new genetic material and bring it back to strengthen their species. Or, put in less euphemistic terms, to find and rape a woman and bring back the resulting child, although apparently retrieving a genetic sample would also work. Did I mention the misogynistic society part? Still there. Zara, the other primary protagonist, is an Azean mediator who, as the book is opening, starts developing psychic powers. This is a rather serious problem that gets her suspended from her job. Her check of her own genetic records (the old-school SF obsession with eugenics is also still there) leads to the discovery that she's an identical twin, whose sister was kidnapped as an infant under mysterious circumstances and apparently by underground psychics. Zara decides to go in search of her. As with In Conquest Born, this book is full of deeply unpleasant societies and world views. Also as with In Conquest Born, I don't think Friedman intends any of them to be held up as examples of correct politics or behavior. What makes both of these books unusual is that neither she nor the characters seem to be making any attempt to construct a third alternative that would be better. The secret society of psychics has a different appeal, but it's not clear the characters would want to be part of it either, and it's quite possible that they're still responsible for a lot of the crap that's going on in the galaxy. The book feels like it ought to be political, as these societies are clearly broken and deeply abusive (the Braxins more obviously than the Azeans, but they're both creepy), but it mostly isn't. Instead, The Wilding is focused on individual people trying to make their way in this world. Those people come from varying strata of these societies. Zara and Tathas are there throughout; other characters crop up briefly with their own viewpoints and then often go away again or are killed. I think Friedman is going for a story of raw emotion and a tight focus on individual actions, with little in the way of clean morality or broader morals. And yet... the final act of the protagonists in the book is a political act that seems aimed at making the universe a better place. In a way, this is a very cynical book: there is a tremendous amount of manipulation and political maneuvering, and it's hard to see any cause here that one can fully support. This is all rather similar to In Conquest Born, but what held the previous book together was its backbone of obsessive vengeance and the spectacle of two intelligent people from utterly different societies locked in all-out emotional and physical combat. The Wilding doesn't have that. It has characters with strong motives and strong emotions, but none of them are the sort of epic, transcendent emotions that propel mythic heroes at each other. This is a more prosaic and personal book, which means the drama isn't strong and sweeping enough to make the reader forget the deep unpleasantness that's going on around them. The Wilding feels less like a clash of titans and more like personal quests for identity against a universe full of awful people and worse systems. It also retains, in the Braxin, aggressive male-dominant sexuality just this side of a Gor novel, but here that feels seedier and even more squirm-inducing than it did in In Conquest Born. The Wilding is even more ambiguous about the ethics of that sexual and misogynistic abusiveness; Tathas partly gives it up, but this is presented more as an accommodation to another culture than as a real engagement with the inherent abusiveness of Braxin society. I still have no idea whether and to whom I would recommend In Conquest Born. I'm less torn about The Wilding: don't bother. It's a lesser work in all respects, it shares some of the problems with too many characters and an occasionally incoherent plot, and I had even more trouble with the horrible societies Friedman creates than I did in the previous book. And it doesn't have the same counterbalance of epic, uncontrolled emotions and characters who seem to transcend the story they're in. Instead, it feels more like a story of damaged people in an awful universe who are meddling through as best they can while being manipulated by the people with real power. It got more depressing the more I thought about it, and the ending doesn't salvage the story. Rating: 4 out of 10

When I took over maintenance of the nbd userland utilities, I decided not to do a full rewrite, even though that might have been a good idea. I've managed to keep things running, but the code isn't very pretty. Unfortunately I've also made a few mistakes. Yes, I know. No, I can't say it won't happen again. Still, the "design", for lack of a better word, of the nbd-server code was problematic, to the extent that some needed performance improvements could not be done, or would require so much work that it would be better to just throw everything out and start over. The unfortunate result of this has been that those who did want to try to do something new with NBD did just that, rather than contributing back to the reference implementation. Over the years, I've sometimes tried to come up with ways to improve the way in which things work. Most of these efforts haven't gone very far, either because they turned out to be dead ends, or because I just didn't have the time to finish it, and that by the time I could finally work on the branch again, the main branch had diverged so much that the branch was so outdated that I would almost have to start over if I was ever going to make it useful again. The most recent of those efforts is the io_transaction branch. This branch has two main goals:

1. Make nbd-server somewhat more modular, so that it would be possible to a different backend per export, if necessary
2. Improve upon the way we handle select() and friends, so that the server can deal with requests more efficiently.

Today, I've reached the (fairly significant) milestone with that branch that on my machine, it seems to pass the "read" part of the test suite. What's more, the second part of the above two means it actually did so at a much higher speed than it does, on average, on the main branch. Of course, reading is only half of the story, and no, write doesn't seem to work yet. After that, there's also a lot of work still to be done if I want to get this branch "on par" with the main branch, feature-wise. But there's a light at the end of the tunnel. Finally.

Review: The Emergency Sasquatch Ordinance, by Kevin Underhill

Publisher:	American Bar Association
Copyright:	2013
ISBN:	1-62722-269-3
Format:	Trade paperback
Pages:	334

First, if you have not read Lowering the Bar, you should do so. There aren't many blogs where I will start reading, end up reading numerous posts out loud to anyone in the vicinity, and then find myself systematically reading the entire backlog (which, in this case, is substantial). Kevin Underhill is a lawyer with civil libertarian leanings, a wicked sense of humor, and a knack for finding the most absurd legal stories. He varies between weary incredulity and caustic sarcasm, almost always manages to make me smile, and often makes me laugh out loud. The Emergency Sasquatch Ordinance, and Other Real Laws that Human Beings Have Actually Dreamed Up, Enacted, and Sometimes Even Enforced is, as one might expect, more of the same sort of thing that one gets from Lowering the Bar. However, unlike a lot of books released by long-standing bloggers, it is not a collection of previously published material. This is an entirely new collection of legal absurdities, drawing on history, US federal, state, and local law, and some non-US laws, and complete with Underhill's trademark commentary. Long-time readers of Lowering the Bar have seen several posts about this sort of thing before, which also means there's a great sample up on the web. See posts tagged "Law (Dumb)" for a preview of the sort of thing you'll get, although as mentioned the material in the book is original. My one complaint about the book version of this post type is that I think the blog posts tend to be longer and contain a bit more analysis. Underhill gets in about one punch line per law in the book, and I frequently wished for a somewhat longer analysis. The blog posts tend to get funnier and more biting once he works up a head of steam on a topic. The book is, alas, a bit uniform in its style. It's composed of a large number of "chapters," each of which is usually a page or two and covers a single law. Those are divided into ancient, pre-modern, US federal, US state, US city, and non-US laws, but with considerably funnier section headings than those. Each chapter has a title that's usually a brief summary of the law (often funny), an introduction, a quote (or several), and a punch line. There's not much variation, which makes it good bathroom reading you can pick it up anywhere, read a few pages, and put it back down without fear of losing context but lacks variety when read in large gulps. I find Lowering the Bar itself funnier than this book. I think that's because the blog posts are longer, more varied, and mix weird laws with caustic political commentary and entertaining stories of the extremely ill-advised things people do around, within, and against the law. The odd laws are entertaining; the stories of defendants, the accounts of weird legal proceedings, and Underhill's exasperated sarcasm about legal and political stupidities are even funnier. If you had to choose between the book and the blog, I'd go with the blog. That said, you don't have to choose, and if you've been reading the blog for a while, more material is always welcome. A book also has the substantial advantage of being a way to throw some money at a blogger as a reward for hours of entertainment, with a bonus of getting an enjoyable physical object in return. I certainly don't regret the purchase, and I've already had an opportunity to mention Millard Fillmore's State of the Union address on guano. I'm not sure if that means the book made me smarter, but I do believe it made me more entertaining. TL,DR version: Read Lowering the Bar. If you like that, there's this book. I think you can figure out the rest from there. Rating: 7 out of 10

I stared at Noodles' Emptiness, where I found a short rant on the currently most used forms of communication. No, into the most socially-useful forms of communication. No, into what works best for him. And, as each person's experience is unique, I won't try to correct him Noodles knows himself much, much, much, much better than I do. But some people have wondered recently (i.e. at conferences I have been at) why I give such an atypical use to social networks (...a term which I still hold to be grossly misused, but that's a topic for a different rant...One that's been had too many times). So, although my blog is syndicated at Planet Debian, and I know a good deal of readers come from there, this post is targetted at the rest of the world population: Those that don't understand why many among us prefer other ways of communication. Noodles mentions seven forms of communication he uses, arguably sorted by their nowadayness, low to high: Phone call, text (SMS) message, email, IRC, Skype, Google Hangouts and Facebook messenger. Among those, I strongly dislike two: Phone call and Skype (or any voice-based service, FWIW). I do most of my communication while multitasking, usually at work. I enjoy the quasi-real-timeliness of IRC and the instant messengers, but much more, I like the ability to delay an answer for seconds or minutes without it breaking the rules of engagement. Second, if the ordering is based on what I found, the reason for my little rant should become obvious: We had kept a great job so far building interoperable technology.1 Up until now, you could say drop me a mail , and no matter if you had your mail with GMail and I insisted on self-hosting my gwolf.org, as long as our communications adhered to simple and basic standards, we would be perfectly able to communicate. Skype is a bit of a special case here: They did build a great solution, ~ten years ago, when decent-quality VoIP was nowhere to be found. They have kept their algorithm and mechanisms propietary, and deliberately don't operate with others. And, all in all, there is a case for them remaining closed. But Google Hangouts and Facebook Messenger do piss me off. More the first than the second. Both arrived to the instant messenger scene long after the experimentation and early stages, so they both took Jabber / XMPP, a well tried and tested protocol made with interoperability and federability in mind. And... They closed it, so they can control their whole walled garden. So, yes, I do use them both Because in both there are many people which I value, and which I want to be in touch with. And no, I won't try to change the ways of everybody so they can talk with me on IRC. I'm an asshole, but everything has its limits! :) Of course, I can (still?) use them from my trusty old multiprotocol chat manager, Pidgin. And it's so much better to have one small program gobbling up moderate heaps of memory than to be connected to the Facebook site, spending much more memory and CPU cycles via Javascript in a Web browser. Bah. PS- Interestingly, he left out the face-to-face communication.I am quite an anchorite in my daily life, but I still think it's worth at least a mention ;-) So, Noodles: Thanks for the excuse to let me vent a rant ;-)

• 1. Interestingly, a counterexample came up on me. One I do not remember, but I have seen printed information that make me believe it: Back in the 1940s/1950s, Mexico (Mexico City only perhaps?) had two parallel phone networks. If I'm not mistaken, one was Ericsson and the other was AT&T. Businesses often gave you both of their numbers in their ads, because you could not call one network from the other. And now that seems so backwards and unbelievable!

I've been working on my backup strategy for the notebook recently. The idea is to have full backups every now month and then incremental backups in between as fine-grained as possible. As it's a mobile device there's no point in time where it is guaranteed to be up, connected and within reach of the backup server. As I'm running Debian GNU/kFreeBSD on it, using ZFS and specifically zfs send comes quite naturally. I'm now generating a new file system snapshot every day (if the notebook happens to be online during that day) using cron.

@daily zfs snapshot base/root@ date -I 
@daily zfs snapshot base/home@ date -I 
@reboot zfs snapshot base/root@ date -I 
@reboot zfs snapshot base/home@ date -I 

When connected to the home network I'm synchronizing off all incrementals that are not yet on the backup server. This is using zfs send together with gpg to encrypt the data and then put it off to some sftp storage. For the first snapshot every month a full backup is created. As there doesn't seem to be a way to merge zfs send streams without importing everything in a zfs pool I create additional incremental streams to the first snapshot of last month so I'm able to delete older full backups and daily snapshots and still keep coarse-gained backups for a longer period of time.

#!/usr/bin/python
# -*- coding: utf-8 -*-
####################
# Config
SFTP_HOST = 'botero.siccegge.de'
SFTP_DIR  = '/srv/backup/mitoraj'
SFTP_USER = 'root'
ZPOOL     = 'base'
GPGUSER   = '9FED5C6CE206B70A585770CA965522B9D49AE731'
#
####################
import subprocess
import os.path
import sys
import paramiko
term =  
    'green':  "\033[0;32m",
    'red':    "\033[0;31m",
    'yellow': "\033[0;33m",
    'purple': "\033[0;35m",
    'none':   "\033[0m",
     
sftp = None
def print_colored(data, color):
    sys.stdout.write(term[color])
    sys.stdout.write(data)
    sys.stdout.write(term['none'])
    sys.stdout.write('\n')
    sys.stdout.flush()
def postprocess_datasets(datasets):
    devices = set([entry.split('@')[0] for entry in datasets])
    result = dict()
    for device in devices:
        result[device] = sorted([ entry.split('@')[1] for entry in datasets
                                    if entry.startswith(device) ])
    return result
def sftp_connect():
    global sftp
    host_keys = paramiko.util.load_host_keys(os.path.expanduser('~/.ssh/known_hosts'))
    hostkeytype = host_keys[SFTP_HOST].keys()[0]
    hostkey = host_keys[SFTP_HOST][hostkeytype]
    agent = paramiko.Agent()
    transport = paramiko.Transport((SFTP_HOST, 22))
    transport.connect(hostkey=hostkey)
    for key in agent.get_keys():
        try:
            transport.auth_publickey(SFTP_USER, key)
            break
        except paramiko.SSHException:
            continue
    sftp = paramiko.SFTPClient.from_transport(transport)
    sftp.chdir(SFTP_DIR)
def sftp_send(dataset, reference=None):
    zfscommand = ['sudo', 'zfs', 'send', '%s/%s' % (ZPOOL, dataset)]
    if reference is not None:
        zfscommand = zfscommand + ['-i', reference]
    zfs = subprocess.Popen(zfscommand, stdout=subprocess.PIPE)
    gpgcommand = [ 'gpg', '--batch', '--compress-algo', 'ZLIB',
                   '--sign', '--encrypt', '--recipient', GPGUSER ]
    gpg = subprocess.Popen(gpgcommand, stdout=subprocess.PIPE,
                                       stdin=zfs.stdout,
                                       stderr=subprocess.PIPE)
    gpg.poll()
    if gpg.returncode not in [None, 0]:
        print_colored("Error:\n\n" + gpg.stderr, 'red')
        return
    if reference is None:
        filename = '%s.full.zfs.gpg' % dataset
    else:
        filename = '%s.from.%s.zfs.gpg' % (dataset, reference)
    with sftp.open(filename, 'w') as remotefile:
        sys.stdout.write(term['purple'])
        while True:
            junk = gpg.stdout.read(1024*1024)
            if len(junk) == 0:
                break
            sys.stdout.write('#')
            sys.stdout.flush()
            remotefile.write(junk)
        print_colored(" DONE", 'green')
def syncronize(local_datasets, remote_datasets):
    for device in local_datasets.keys():
        current = ""
        for dataset in local_datasets[device]:
            last = current
            current = dataset
            if device in remote_datasets:
                if dataset in remote_datasets[device]:
                    print_colored("%s@%s -- found on remote server" % (device, dataset), 'yellow')
                    continue
            if last == '':
                print_colored("Initial syncronization for device %s" % device, 'green')
                sftp_send("%s@%s" % (device, dataset))
                lastmonth = dataset
                continue
            if last[:7] == dataset[:7]:
                print_colored("%s@%s -- incremental backup (reference: %s)" %
                              (device, dataset, last), 'green')
                sftp_send("%s@%s" % (device, dataset), last)
            else:
                print_colored("%s@%s -- full backup" % (device, dataset), 'green')
                sftp_send("%s@%s" % (device, dataset))
                print_colored("%s@%s -- doing incremental backup" % (device, dataset), 'green')
                sftp_send("%s@%s" % (device, dataset), lastmonth)
                lastmonth = dataset
def get_remote_datasets():
    datasets = sftp.listdir()
    datasets = filter(lambda x: '@' in x, datasets)
    datasets = [ entry.split('.')[0] for entry in datasets ]
    return postprocess_datasets(datasets)
def get_local_datasets():
    datasets = subprocess.check_output(['sudo', 'zfs', 'list', '-t', 'snapshot', '-H', '-o', 'name'])
    datasets = datasets.strip().split('\n')
    datasets = [ entry[5:] for entry in datasets ]
    return postprocess_datasets(datasets)
def main():
    sftp_connect()
    syncronize(get_local_datasets(), get_remote_datasets())
if __name__ == '__main__':
    main()

Rumors have it, btrfs has gained similar functionality to zfs send so maybe I'll be able to extend that code and use it on my linux nodes some future day (after migrating to btrfs there for a start).

I've written a small dmenu-based script which allows to select passwords from one's pass password manager and have it xdotool typed in. This should completely bypass the clipboard (which is distrusted by people for a reason). As I've been asked about the script a few times in the past here it is. Feel free to copy and any suggestions welcome.

#!/bin/bash
shopt -s nullglob globstar
list_passwords()  
	basedir=~/.password-store/
	passwords=( ~/.password-store/**/*.gpg )
	for password in "$ passwords[@] "
	do
		filename="$ password#$basedir "
		filename="$ filename%.gpg "
		echo $filename
	done
 
xdotool_command()  
	echo -n "type "
	pass "$1"
 
selected_password="$(list_passwords 2>/dev/null  dmenu)"
echo $selected_password
if [ -n "$selected_password" ]
then
	xdotool_command "$selected_password"   xdotool -
fi

While cooperatives fortnight is mostly a celebration of how well cooperatives are doing in the UK, this year is tinged with sadness for me because it sees Downham Food Coop stop trading. This Friday and Saturday will be their last market stall, 9til 1 on the Town Square, aka Clock or Pump square. As you can see, the downturn has hit the market hard and I guess being the last stall left outside the market square (see picture: it used to have neighbouring stalls!) was just too much. The coop cites shortage of volunteers and trading downturn as reasons for closure. But if you re near Downham today or tomorrow morning, please take advantage of this last chance to buy some great products in West Norfolk!

Review: Due Diligence, by David Roodman

Publisher:	Center for Global Development
Copyright:	2012
ISBN:	1-933286-48-2
Format:	Trade paperback
Pages:	335

Due Diligence: An Impertinent Inquiry into Microfinance is a detailed analysis of the effects, philosophy, approaches, and merits of microfinance as an institution and as, increasingly, a charitable focus of the developed world. The author, David Roodman, was a senior fellow at the Center for Global Development at the time of writing this book, and is an expert in microfinance and economic development. This book starts as an overview and a history of the spectrum of microfinance institutions (something I found very valuable, since I knew very little about microfinance prior to Kiva's popularity), and then attempts a critical, data-driven analysis of whether, to what extent, and by which measures microfinance is successful. The most common aspect of microfinance, made popular and prominent by Kiva among others, is microcredit: small loans to people in developing countries. The underlying theory of microcredit is that lack of financial services handicaps prospective entrepreneurs and business owners in the third world, preventing them from growing businesses, funding expansion, and moving out of poverty. By extending relatively small amounts of credit to these people, or so the theory goes, they can better smooth out the uncertainties of day-to-day life and get the necessary capital to expand small local business. Microcredit is not the only type of microfinance, though, and Roodman's careful discussion of that point was one of the most informative parts of this book for me. It can also come in the form of microsavings tiny bank accounts or small-scale savings plans or microinsurance. Roodman makes a very interesting argument that these three forms of microfinance form two opposing continuums. Microcredit is the easiest to provide and microinsurance is the hardest, for many reasons he discusses including some that were surprising to me, but microinsurance is arguably the most helpful and beneficial to the individual poor and microcredit is the least. The opening history and survey does an excellent job showing the range of techniques and approaches used in microfinance, and showing the challenges of providing it. I had some vague understanding of the logistical challenges in serving areas far away from traditional infrastructure. I had much less understanding of the fascinating array of techniques in use, both inside and outside what's become the microfinance industry. Some of these techniques are brilliant examples of human economic creativity and skill at balancing incentives with risk protection. There are a much wider variety of approaches and instruments available than the individual or group loans that one typically sees on a site like Kiva, all with different trade-offs in group size, flexibility, rigidity, risk, and complexity. This book is well worth reading just to get a feel for the huge array of financial arrangements possible outside of the traditional banking structures that most readers of this review are used to. Another question Roodman answers thoroughly is why microfinance is so focused on microcredit. My vague unease with that was strengthened by reading David Graeber's Debt, which among many other things makes clear some of the social perils and power imbalances in lending. Due Diligence both crystallized that discomfort and explained why alternatives are difficult. Both microsavings and microinsurance necessarily involve considerably more regulation (which has both advantages and complexity), since they involve taking and safeguarding people's money and promising service in the future. Lenders require less trust; lenders instead extend trust and assume that risk themselves, and are in a position to do so. Microinsurance is also harder to explain and harder to target, although it is potentially the most helpful financial instrument when well-targeted. And microcredit can absorb huge influxes of capital from the outside, lending it out in a region, while both microsavings and microinsurance are necessarily built on the money already in the local economy and are inherently more resistant to external involvement. (I'm of the opinion this is a significant feature, but it makes it far harder for them to catch on as a charitable trend.) The heart of the book is a hard look at whether microfinance, and particularly microcredit, works. Roodman attempts this analysis for three different definitions of working: lifting people out of poverty (the most commonly claimed success), giving people more freedom and control over their lives even if their poverty level does not change in absolute terms, and developing the local economy. Sadly for charities like Kiva, microcredit does surprisingly poorly on the first two metrics. There is still little clear data, and the degree to which data from one region is applicable to a different region is highly debatable, but what evidence we have does not support the theory that microcredit lifts people out of poverty. In fact, the more intense the microcredit, the more likely it appears to be that credit pathologies common in the developed world, such as taking out loans from one organization to pay off loans from another, spirals of debt that is unlikely to ever be repaid, and aggressive debt collection methods, turn up in microcredit as well. The vision of the entrepreneur who succeeds through new-found access to capital is largely a myth. Indeed, the current packaging and presentation of loans to distant charities in developed countries means that even the supposed purpose of the loans is dubious. Loans are almost always presented as being for some sort of business activity, since that's what external charities want to fund, but money is fungible and the funds are more often used for all the things people normally need to use funds for: weddings, funerals, food for the family in hard times, paying off other loans to relatives, and other daily expenses. On the empowerment front, microcredit fairs little better, and here I particularly appreciated Roodman's clear-eyed and honest portrayal of common microcredit practices and their benefits for the creditors. For example, microcredit makes much of loaning to women, and presents this as a story of female empowerment. Roodman argues that there is some reality behind that, but it's also clear that microcredit organizations loan to women because women are more likely to repay not due to any inherent gender trait, but because women are easier to intimidate and shame into repaying. Similarly, the much-vaunted group loans, usually presented as a way for the community to support each other and teach each other financial skills, are most common in the poorest regions because they represent an outsourcing of costs. The main risk to the lender is that poor people have no such thing as credit histories, and detailed investigations of someone's trustworthiness is expensive. Groups are jointly liable and therefore will police themselves and check each other's reliability at no cost to the lender. Groups will also use intimidation tactics and even violence against members who don't or can't repay their share, without the lender having to get involved or have any responsibility for those tactics. Roodman takes a philosophical tone on this topic, noting several times that services for the very poor are generally of low quality and finance is no exception. I'm less inclined to be philosophical; after reading this book, I find it very hard to support group loans. This leaves economic development as the most compelling argument left for microcredit. This is weak tea for people like myself who wanted to believe in the transformative power of microcredit, but Roodman does a solid job explaining why it's still important. There is a great deal to be said for the perspective that only industrialization actually lifts people out of poverty on any substantial scale, and therefore the most useful type of aid is aid that somehow contributes towards industrialization. Building a native financial industry could arguably be such a step. And there seems to be some real merit and lasting effect to having a richer and more capable set of local financial institutions. However, here, it's not at all clear that external money helps. In fact, there's quite a bit of evidence that external money hurts, since it pushes microfinance institutions to find ways of using that money and pleasing external donors instead of building their infrastructure and capabilities as financial institutions. The earlier institutions, such as the Grameen Bank, seem to have done a better job at being local institutions woven into the local economy than have the later organizations that are largely supported by western donors. Roodman makes a good case for the usefulness of microfinance as a part of economic development, but it comes with a strong argument against too much external funding, and particularly against the practice of developed world donors funding specific loans. I came away from this book feeling like I had a much better understanding of the core problems and techniques of financial services for the poor, and with a strong desire to see more microsavings than microcredit. The two are closer in nature than I had expected, and Roodman's analysis of the similarities was fascinating, but microsavings seems less vulnerable to some of the credit pathologies. There is also some statistical evidence that microsavings does provide some modest reductions in poverty, while the evidence for microcredit is much less compelling. Sadly, from the perspective of a resident of the developed world such as myself who would very much like to help, neither microsavings nor effective microcredit seems likely to benefit from my contributions, and particularly not in the form of a site like Kiva. The end of this book is a long appendix that reprints multiple blog posts on related topics, including additional discussion of the problems with the Kiva model. Effectively, Kiva is a way for people like myself to subsidize microcredit organizations. It's not at all clear that subsidies are needed, and there's some reason to believe that they encourage negative and destructive behavior. The way they are marketed involves a certain amount of lying, or at least distortion, on the part of multiple actors in the microcredit picture. And they're a distraction from microsavings, and from microcredit based on loaning out savings from within the same local economy, both of which seem to have considerably more positive properties. Due Diligence is a book with a somewhat narrow target audience. It will appeal primarily to people with an interest in economics, particularly development economics, or who are evaluating microfinance charities or analyzing their support of groups like Kiva. But within that context, this is an excellent book, and I recommend it to your attention. Roodman is clear, thorough, and fair within my ability to measure that, and while no one book can be the final word on a topic, he adds considerable data and thoughtful analysis. If you are a supporter of Kiva, like I was, I fear you'll find this book rather discouraging. But it's better to have the information than not, and I found it a good reminder of the inherent drawbacks of loans and debt. There is, sadly, nothing magical about microcredit that removes those problems. Rating: 9 out of 10

I am struck by the fragmentation in communication mechanisms. Let's look at how I have communicated with my friends in the past few days:

• Phone call
  Tried and tested, though I tend to avoid them. I've made some deliberate calls to sort out immediate plans, and at least one accidental call caused by user error which resulted in talking to someone it was good to hear from.
• Text message
  Again, reasonably tried and tested. I miss the inability to use Google Voice when I'm in the UK; I'd much rather read and compose text messages from my web browser when I'm near a computer than type them on my phone, even if it does have a keyboard.
• Email
  One of my favourite methods of communication. Suitable for quick messages or longer screeds. I can throw links in and expect you to be able to click them. I can put lots of detail so that everything is covered easily. I can confuse you by quoting correctly. I guess while I do read email on my phone I'm less likely to reply there as I'm always a bit embarrassed how the clients cope with replies.
• IRC
  Like, I suspect, many readers of my blog posts, I'm still a daily user of IRC. There are friends I keep in touch with mostly via this method. It's great. It's like Twitter for old people and much better in many ways.
• Skype
  This started out as a work thing. It was the way in which the Belfast office communicated with the US, it become the way the Belfast office communicated with each other and when I moved on it was the way in which I kept in contact with a group of people I consider good friends. It's great for calls (I feel bad saying that, but it's an idea executed well across multiple platforms and any other VOIP stuff I've played with has been much more of a hassle), but the one to one and group chat functionality is pretty spot on as well. Also has the advantage that I can turn it off and mostly not end up with work queries.
• Google Hangouts
  I actually quite like these. They work on my phone, I can poke them from a web browser, I can dump more than just text into them. IRC is better in some ways, but I do like the additional flexibility I get from a Hangout. It doesn't play well with people who haven't drunk the Google koolaid, which is the main reason I haven't managed to convince the Skype group chat group to move it over here.
• Facebook messenger
  I hate this. On the face of it there's not a lot of difference between it and Hangouts, but the app wants more and more privileges, I'm less likely to be logged into Facebook (e.g. I avoid it at work, whereas there are good reasons I'd be logged into my Google account there, though less so since the demise of Reader) and I don't think it's as nicely implemented. However there are a few people who it's easiest to get hold of via this method. And there's a certain amount of mesmerisation by the floaty wee faces it invokes on my phone.

While some of these work better for me than others really what I'd like is to use fewer of them, and I can't see that happening any time soon. I don't want to have to run a handful of different messaging apps on my phone. I also don't want to be limited to only using my laptop or my phone for something - I'd much prefer to be able to pickup the phone, laptop or tablet depending on what I'm up to and have my full range of communication available. Some of these things can be aggregated together, but that will then lose some of the advantages. And I'm sure that even if I got rid of one or two of the above there'd be something to fill the gap along shortly (I have, for example, so far completely avoided WhatsApp).