Review: Lockstep, by Karl Schroeder

Publisher:	Tor
Copyright:	March 2014
ISBN:	0-7653-3726-6
Format:	Hardcover
Pages:	351

Toby McGonigal's family fled an Earth dominated by trillionaires and vicious class conflict, and attempt, instead, a very risky and precarious settlement on a trans-Neptunian object. It's the last unclaimed but marginally habitable space left in the solar system, and securing their claim requires constant bureaucratic hoop-jumping. That's what sent Toby on a solo mission to a distant moon of their home to claim it and solidify their title. But, while in cold sleep, his craft hits a small chunk of rock, and he wakes up near another world: cold, silent, dead... but apparently with lifeless cities. Another trip through suspended animation in a desperate attempt to conserve resources against the distant hope of rescue has him awakening in a society both utterly foreign and yet strangely familiar. Schroeder is one of the better big idea writers in science fiction, but I found Lockstep to be a mixed bag. He does a surprisingly good job with the core conceit of the novel (more on that in a moment), even though it's a tricky one to make believable. Surrounding that, though, are a lot of less convincing bits that I kept having to not think about too hard, such as Toby crossing the path of another trans-Neptunian object after the accident (space is really, really big and really, really empty), or the implications of later revelations about the time scales involved in parts of the plot. Some parts of the world building, even if scientifically plausible, struck me as sloppy; for example, a religion plays a prominent role in the plot, but the nature of that religion was not particularly believable, nor was its interaction with the plot climax. I won't go into details about the religion, since it's a major plot point, but the short version is that religions tend to mature from the concrete to the abstract, not the other way around. That said, the core conceit is both surprising and considerably better-defended in the book than I thought it could be. The world into which Toby awakes is the world of the locksteps: a society that uses suspended animation in a universal and coordinated way to build a functional society on the far outskirts of the solar system. Humans emerge for some short period of time, like a month, and build, trade, interact, and consume. They welcome ships traveling from other trans-Neptunian worlds and prepare for their own journeys. And then they go into suspended animation for an extended period 15 years and 30 years are common choices while robots slowly gather more resources and energy, and repair and replace what's consumed in the month of active life. Ships travel with passengers in suspended animation, allowing the vast distances between these cold worlds to be reached during the sleep period. And, since all members of the lockstep sleep and wake on the same schedule, there is no wrenching desynchronization with the surrounding society during travel. One may spend thirty years in transit, but no time passes for anyone else in the lockstep while you're traveling either. A world can effectively trade with all other worlds within a thirty year travel radius without noticing the elapsed time. This is a technological system that at first doesn't sound like it would work, but Schroeder does a great job defending it and chasing down implications. The lockstep civilization serves as a sort of anchor and time capsule separate from the more frantic pace of the so-called fast worlds. The trans-Neptunian lockstep worlds are remote enough and poor enough to not attract too much unwanted attention, and are thus tolerated by fast societies that may have more available resources. (Although, to be sure, automated robot defenses have to carry a lot of weight here given how helpless the locksteps are during a sleep cycle.) I'm not sure I completely bought the sociology, but it works well enough to carry the weight of the story, and I've never seen a science fiction construction that uses the common technology of suspended animation in quite this way before. Schroeder sets up some nice stabilizing tensions between resources and time, adds some believable political reasons for this fragile society to survive, and uses some of its obvious political vulnerabilities as story drivers. The plot, unfortunately, isn't as good as the big idea, and particularly suffers at the start of the book. Toby is a teenager without much experience (Lockstep is marketed as young adult), and is immediately thrown into a strange and quickly hostile environment. This means that he spends the first half of the book reacting to a blizzard of new information, and the plot tends to revert to a tour of Schroeder's constructed world. Toby is also a bit of a cipher and a bit of an everyman, without many feelings or opinions beyond the obvious feelings that any teenage boy would go through in this situation. That makes the sense of a world tour even stronger. This flaw does not persist through the whole book. Toby does eventually start making decisions and doing things, some of the supporting characters add additional depth, and I found the unwinding of the plot surprisingly satisfying. The nature of time in this world lets Schroeder have both epic sweep and personal connection at the same time, which lets him pull off some neat contrasts between the personal and the political. I also liked Toby's gradual piecing together of what actually happened while he was asleep, both in the construction of society as a whole and in the personal conflicts between people he knew well. Some of the ease of grand manipulation seemed dubious to me, but, in Schroeder's defense, people do develop a reverence for and stories about things that have lasted a very long time, and Schroeder's setup gives him quite a lot to work with in that department. So, a mixed bag. The core concept is thought-provoking and up to Schroeder's usual standards. The surrounding world-building isn't as much, and I think Schroeder reaches for some too-easy explanations and still underplays just how many disruptive things can happen over the span of time that this book covers. The characterization I found weak and unsatisfying for much of the book, but it gets moderately better in the end. There's a bit too much tour, and a bit too much world exploration instead of plot, but it's a fascinating world and I still enjoyed the tour. With stronger characters and a few fewer dubious supporting pillars in the world background, I think this would have been an excellent book. As is, it's an enjoyable novel set firmly in the big idea and deep future end of science fiction, and I'm always happy to see more stories like that. It's not the best that Schroeder has done, but I still recommend it. Rating: 7 out of 10

We currently use completely different methods and tools of building test beds and running tests for Debian vs. Click packages, for normal uploads vs. CI airline landings vs. upstream project merge proposal testing, and keep lots of knowledge about Click package test metadata external and not easily accessible/discoverable. Today I released autopkgtest 3.0 (and 3.0.1 with a few minor updates) which is a major milestone in unifying how we run package tests both locally and in production CI. The goals of this are:

• Keep all test metadata, such as test dependencies, commands to run the test etc., in the project/package source itself instead of external. We have had that for a long time for Debian packages with DEP-8 and debian/tests/control, but not yet for Ubuntu s Click packages.
• Use the same tools for Debian and Click packages to simplify what developers have to know about and to reduce the amount of test infrastructure code to maintain.
• Use the exact same testbeds and test runners in production CI than what developers use locally, so that you can reproduce and investigate failures.
• Re-use the existing autopkgtest capabilities for using various kinds of testbeds, and conversely, making all new testbed types immediately available to all package formats.
• Stop putting tests into the Ubuntu archive as packages (such as mediaplayer-app-autopilot). This just adds packaging and archive space overhead and also makes updating tests a lot harder and taking longer than it should.

So, let s dive into the new features! New runner: adt-virt-ssh We want to run tests on real hardware such as a laptop of a particular brand with a particular graphics card, or an Ubuntu phone. We also want to restructure our current CI machinery to run tests on a real OpenStack cloud and gradually get rid of our hand-maintained QA lab with its test machines. While these use cases seem rather different, they both have in common that there is an already existing machine which is pretty much only accessible with ssh. Once you have an ssh connection, they look pretty much the same, you just need different initial setup (like fiddling with adb, calling nova boot, etc.) to prepare them. So the new adt-virt-ssh runner factorizes all the common bits such as communicating with adt-run, auto-detecting sudo availability, doing SSH connection sharing etc., and delegates the target specific bits to a setup script . E. g. we could specify --setup-script ssh-setup-nova or --setup-script ssh-setup-adb which would then get called with open at the appropriate time by adt-run; it calls the nova commands to create a VM, or run a few adb commands to install/start ssh and install the public key. Then autopkgtest does its thing, and eventually calls the script with cleanup again. The actual protocol is a bit more involved (see manpage), but that s the general idea. autopkgtest now ships readymade scripts for these two use cases. So you could e. g. run the libpng tests in a temporary cloud VM:

# if you don't have one, create it with "nova keypair-create"
$ nova keypair-list
[...]
  pitti   9f:31:cf:78:50:4f:42:04:7a:87:d7:2a:75:5e:46:56  
# find a suitable image
$ nova image-list 
[...]
  ca2e362c-62c9-4c0d-82a6-5d6a37fcb251   Ubuntu Server 14.04 LTS (amd64 20140607.1) - Partner Image                           ACTIVE    
$ nova flavor-list 
[...]
  100   standard.xsmall    1024        10     10                 1       1.0           N/A        
# now run the tests: please be patient, this takes a few mins!
$ adt-run libpng --setup-commands="apt-get update" --- ssh -s /usr/share/autopkgtest/ssh-setup/nova -- \
   -f standard.xsmall -i ca2e362c-62c9-4c0d-82a6-5d6a37fcb251 -k pitti
[...]
adt-run [16:23:16]: test build:  - - - - - - - - - - results - - - - - - - - - -
build                PASS
adt-run: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ tests done.

Please see man adt-virt-ssh for details how to use it and how to write setup scripts. There is also a commented /usr/share/autopkgtest/ssh-setup/SKELETON template for writing your own for your use cases. You can also not use any setup script and just specify user and host name as options, but please remember that the ssh runner cannot clean up after itself, so never use this on important machines which you can t reset/reinstall! Test dependency installation without apt/root Ubuntu phones with system images have a read-only file system where you can t install test dependencies with apt. A similar case is using the null runner without root. When apt-get install is not available, autopkgtest now has a reduced fallback mode: it downloads the required test dependencies, unpacks them into a temporary directory, and runs the tests with $PATH, $PYTHONPATH, $GI_TYPELIB_PATH, etc. pointing to the unpacked temp dir. Of course this only works for packages which are relocatable in that way, i. e. libraries, Python modules, or command line tools; it will totally fail for things which look for config files, plugins etc. in hardcoded directory paths. But it s good enough for the purposes of Click package testing such as installing autopilot, libautopilot-qt etc. Click package support autopkgtest now recognizes click source directories and *.click package arguments, and introduces a new test metadata specification syntax in a click package manifest. This is similar in spirit and capabilities to DEP-8 debian/tests/control, except that it s using JSON:

    "x-test":  
        "unit": "tests/unittests",
        "smoke":  
            "path": "tests/smoketest",
            "depends": ["shunit2", "moreutils"],
            "restrictions": ["allow-stderr"]
         ,
        "another":  
            "command": "echo hello > /tmp/world.txt"
         
     

For convenience, there is also some magic to make running autopilot tests particularly simple. E. g. our existing click packages usually specify something like

    "x-test":  
        "autopilot": "ubuntu_calculator_app"
     

which is enough to do what I mean , i. e. implicitly add the autopilot test depends and run autopilot with the specified test module name. You can specify your own dependencies and/or commands, and restrictions etc., of course. So with this, and the previous support for non-apt test dependencies and the ssh runner, we can put all this together to run the tests for e. g. the Ubuntu calculator app on the phone:

$ bzr branch lp:ubuntu-calculator-app
# built straight from that branch; TODO: where is the official" download URL?
$ wget http://people.canonical.com/~pitti/tmp/com.ubuntu.calculator_1.3.283_all.click
$ adt-run ubuntu-calculator-app/ com.ubuntu.calculator_1.3.283_all.click --- \
      ssh -s /usr/share/autopkgtest/ssh-setup/adb
[..]
Traceback (most recent call last):
  File "/tmp/adt-run.KfY5bG/tree/tests/autopilot/ubuntu_calculator_app/tests/test_simple_page.py", line 93, in test_divide_with_infinity_length_result_number
    self._assert_result("0.33333333")
  File "/tmp/adt-run.KfY5bG/tree/tests/autopilot/ubuntu_calculator_app/tests/test_simple_page.py", line 63, in _assert_result
    self.main_view.get_result, Eventually(Equals(expected_result)))
  File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 406, in assertThat
    raise mismatch_error
testtools.matchers._impl.MismatchError: After 10.0 seconds test failed: '0.33333333' != '0.3'
Ran 33 tests in 295.586s
FAILED (failures=1)

Note that the current adb ssh setup script deals with some things like applying the autopilot click AppArmor hooks and disabling screen dimming, but it does not do the first-time setup (connecting to network, doing the gesture intro) and unlocking the screen. These are still on the TODO list, but I need to find out how to do these properly. Help appreciated! Click app tests in schroot/containers But, that s not the only thing you can do! autopkgtest has all these other runners, so why not try and run them in a schroot or container? To emulate the environment of an Ubuntu Touch session I wrote a --setup-commands script:

adt-run --setup-commands /usr/share/autopkgtest/setup-commands/ubuntu-touch-session \
    ubuntu-calculator-app/ com.ubuntu.calculator_1.3.283_all.click --- schroot utopic

This will actually work in the sense of running (and succeeding) the autopilot tests, but it will fail due to a lot of libust[11345/11358]: Error: Error opening shm /lttng-ust-wait... warnings on stderr. I don t know what these mean, just that I also see them on the phone itself occasionally. I also wrote another setup-commands script which emulates read-only apt , so that you can test the unpack only fallback. So you could prepare a container with click and the App framework preinstalled (so that it doesn t always take ages to install them), starting from a standard adt-build-lxc container:

$ sudo lxc-clone -o adt-utopic -n click
$ sudo lxc-start -n click
  # run "sudo apt-get install click ubuntu-sdk-libs ubuntu-app-launch-tools" there
  # then "sudo powerdown"
# current apparmor profile doesn't allow remounting something read-only
$ echo "lxc.aa_profile = unconfined"   sudo tee -a /var/lib/lxc/click/config

Now that container has enough stuff preinstalled to be reasonably fast to set up, and the remaining test dependencies (mostly autopilot) work fine with the unpack/$*_PATH fallback:

$ adt-run --setup-commands /usr/share/autopkgtest/setup-commands/ubuntu-touch-session \
          --setup-commands /usr/share/autopkgtest/setup-commands/ro-apt \
          ubuntu-calculator-app/ com.ubuntu.calculator_1.3.283_all.click \
          --- lxc -es click

This will successfully run all the tests, and provided you have apt-cacher-ng installed, it only takes a few seconds to set up. This might be a nice thing to do on merge proposals, if you don t have an actual phone at hand, or don t want to clutter it up. autopkgtest 3.0.1 will be available in Utopic tomorrow (through autosyncs). If you can t wait to try it out, download it from my people.c.c page . Feedback appreciated!

Suppose you had spawned a process in TCL and knew its PID and wanted to kill it? Sounds simple enough thing to do, right? This problem has plagued me for many months because some things you can assume on a normal system do not hold true on strange environments, such as build deaemons. Seems simple enough, I started off with: Except.. not every environment has the kill binary, and with that piece of code exec has to be a binary and not a shell builtin. The funny thing is that /bin/kill is in the procps package, which is the package having the buildd problems. So next idea was to use command -v to check for the existence of kill and skip those tests that needed kill if not found. Good idea except, so I found out later, it also finds built-ins. That means we are back to problem #1. There is a kill command in tcl, but it requires tclx. That seems excessive for just one little simple command. How can I run a shell out of TCL that runs the kill builtin? On the command line, something like below would do it. I was closer, but then hit TCL quoting hell. No matter what I (initially) did I d either get the shell to complain or my variable to not be evaluated. In the end, I had to write it to a separate variable for the command line then apply that to the exec. Not perfect but at least it works now. The resulting code (found in testsuite/config/unix.exp) looks like: Perhaps there is a more elegant way, I m certainly no star TCL programmer, but of all the combinations I saw this was the only that worked.

Review: Ancillary Justice, by Ann Leckie

Series:	Imperial Radch #1
Publisher:	Orbit
Copyright:	2013
ISBN:	0-316-24662-X
Format:	Trade paperback
Pages:	416

As Ancillary Justice opens, Breq is on an icy planet trying to track down a person who has gone rather thoroughly to ground. As her search continues, the reader slowly learns the context of that search, which is only the latest step of a long and quixotic exercise in private determination. She was set on her path by events twenty years previous, told in interleaved flashbacks, that have left her greatly diminished and thrust outside of any of the context of her over thousand years of life. Breq was Justice of Toren, a starship and AI that possessed thousands of ancillaries, human bodies slaved to her mind. Now only this one remains, and nothing exists of her former life other than this goal. It's always hard to write a review of a book that I loved this much. I want to find some way to grab the reader and shake them and say "you have to read this!" without giving away any of the delicious details. That's particularly difficult with Ancillary Justice, since one of the delights of this book is the slow unfolding of not only the plot but the background and motivations behind the plot. There is so much beneath the surface of Breq's methodical intent, and discovering all the nuances is utterly delightful. This is also a book that is very deeply concerned with identity, and which does one of the best jobs I've seen in science fiction of showing a non-human first-person protagonist: close enough to human to permit identification and comprehension, but far enough away for delightful sparks of unexpected insight or thought-provoking difference. Breq is a ship, and AIs are central to this story, so the comparison that comes immediately to mind is with Iain M. Banks. Leckie's role for ship AIs is much different than the structure of Banks's Culture, but I think this is still an apt comparison. Like Banks, Leckie is writing large-scale space opera dominated by a meddling empire that follows some familiar human patterns but not others. Banks's Culture takes a less direct approach with its meddling; the Radch has a more Roman attitude towards preventative conquest and citizenship. But both deal with large-scale issues of politics, culture, and conquest. Both also write excellent AIs, but I think Leckie is more successful than Banks at giving her AIs inhuman properties and creating a sense of eerie alienness that sometimes fades almost entirely and sometimes comes sharply to the surface. The first-person perspective helps considerably there. But where Ancillary Justice truly shined for me is in the interpersonal relationships, and in the insight they provided into character and motive. At the start of the book, Breq finds a drug addict dying in the cold and rescues her, bringing her along on her search for lack of a better option. Breq's relationship with Seivarden is complex, difficult for both of them, badly asymmetric at the start, and develops into something brilliant. At the start of the book, Seivarden is easy to dislike, and Breq's tone is refreshingly bracing and forthright. But through the course of the book Seivarden grows into something much more, in a way that I found both believable and incredibly compelling. And Leckie does this without falling into any of the typical relationship patterns, without introducing artificial romance (or, indeed, any romance at all, which is an excellent choice here), and without compromising the personalities of either character. It's masterfully done. One of the most amazing things about this book to me is that it's a first novel. I never would have guessed that from reading it. It's beautifully paced, the characterization is deep and compelling, and Leckie avoids any sign of the typical first-novel problem of stuffing the book with too much Stuff. Ancillary Justice is a capable and confident novel that builds a compelling world and even more compelling characters. I liked it more than I like most of the Culture novels, which is saying quite a lot, but Leckie offers much of the same scope with deeper and more personal characterization and a tighter plot. I haven't yet remarked on one aspect of this book that every other review seems to remark on: its treatment of gender. The Radch do not recognize or care about gender distinctions, and therefore Breq struggles throughout the book with proper gender labeling in much the same way that a native English speaker tends to struggle with grammatical gender when learning a Romance language, except with more social consequences. Leckie has chosen to represent this in the novel by having Breq refer to everyone uniformly as "she." This has its pluses and minuses: it still supports a binary gender concept where a gender-neutral pronoun might not, but given all the negative reaction this book got just for using "she," a gender-neutral pronoun might be a bridge too far for a lot of readers. I thought it created a nice bit of alienation, a way of forcing the reader to look at gender markers from the outside and a way to point out how arbitrary many of them are. It was also interesting to see how surprised I was at various points in the book when it became obvious that some person Breq had been calling "she" in the first-person narration turned out, from story context, to probably be male. That said, I think this part of the book is overblown in reviews. It's often the first thing people mention, but while it was a nice side bit of world-building, I don't think it's that central to the story. I'm particularly baffled by the handful of people who complained about it, since it's not intrusive and it quickly fades into the background apart from occasional necessary shifts of mental image. (It does create the impression of a world containing only women, but I found that a nice change from the more common impression in space opera of a world containing only men.) Ancillary Justice has already won the Nebula and Arthur C. Clarke awards and tied for the BSFA award for best novel, and I'm happy to report that it deserves all of those. I haven't yet read all of the other Hugo nominees, but it's hard to imagine a world in which it won't top my ballot. This is a fantastic novel, by far the best thing I've read so far this year. I'm delighted that it's the first book of a trilogy, since I'm not done with either the world or the characters yet, but it stands well on its own and reaches a satisfying conclusion. I recommend it to everyone, but particularly to anyone who likes Banks, intelligent ships, or who is looking for thoughtful and complex space opera. Followed by Ancillary Sword. Rating: 10 out of 10

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/

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

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

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

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

So, I have a SEN account (it's part of the PSN), I have 2 videos with SEN, I have a broken PS3 so I can no deactivate video (you can only do that from the console itself, yes, really)... and the response from SEN has been abysmal, specifically:

As we take the security of SEN accounts very seriously, we are unable to provide support on this matter by e-mail as we will need you to answer some security questions before we can investigate this further. We need you to phone us in order to verify your account details because we're not allowed to verify details via e-mail.

I mean, seriously, they're going to verify my details over the phone better than over e-mail how exactly? All the contact details are tied to my e-mail account, I have logged in to their control panel and renamed the broken PS3 to "Broken PS3", I have given them the serial number of the PS3, and yet they insist that I need to call them, because apparently they're fucking stupid. I'm damned glad that I only ever got 2 videos from SEN, both of which I own on DVD now anyways, this kind of idiotic tie in to a system is badly wrong. So, you phone the number... and now you get stuck with hold music for ever... oh, yeah, great customer service here guys. I mean, seriously, WTF. OK - 10 minutes on the phone, and still being told "One of our advisors will be with you shortly". I get the feeling that I'll just be writing off the 2 videos that I no longer have access to. I'm damned glad that I didn't decide to buy more content from that - at least you can reset the games entitlement once every six months without jumping through all these hoops (you have to reactivate each console that you still want to use, but hey).

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

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

Review: A People's History of the Supreme Court, by Peter Irons

Publisher:	Penguin
Copyright:	1999, 2006
Printing:	2006
ISBN:	0-14-303738-2
Format:	Trade paperback
Pages:	553

I first encountered Peter Irons via his Teaching Company course, The History of the Supreme Court. I listened to that and enjoyed it, and would recommend it as an excellent overview. When I later ran across this book, I was excited: I usually prefer books to lectures on topics that can benefit from greater depth, and A People's History of the United States is one of my favorite history books. A book that talked about the Supreme Court from a similar bottom-up approach was appealing. Unfortunately, I think the title oversells this book. It is a history of the Supreme Court, and, as with Zinn's book, it carries its bias openly (if not as forcefully or compellingly as Zinn). It is a legal history concerned with individual rights, and Irons openly expresses his opinions of the merits of certain decisions. But it's not the full-throated cry for justice and for the voice of the general population that Zinn's book was, nor did I think it entirely delivered on the introductory promise to look at the people and situations underlying the case. It does provide more background and biographical sketch of the litigants in famous cases than some other histories, but those sketches are generally brief and focused on the background and relevant facts for the case. This is, in short, a history of the Supreme Court, with some attention paid to the people involved and open comfort with an authorial viewpoint, but without the eye-opening and convention-defying freshness of Zinn's refusal to point the camera at the usual suspects. It also largely duplicates Irons's course for the Teaching Company. That's only really a problem for those, like me, who listened to that course already and came to this book looking for additional material. If you haven't listened to the course, this is a reasonable medium in which to provide the same content, although you do miss the audio recordings of actual Supreme Court argument in some of the most famous cases. But after having listened or read both, I think I prefer the course. It felt a bit more focused; the book is not padded, but the additional material is also not horribly memorable. That said, as a history, I found this a solid book. Irons opens with a surprisingly detailed look at the constitutional convention and the debates over the wording of the US Constitution, focusing on those sections that will become the heart of later controversy. Some of them were known to be controversial at the time and were discussed and argued at great length, such as anything related to slavery and the role of a bill of rights. But others, including many sections at the heart of modern controversies, were barely considered. Despite being a bit off-topic for the book, I found this section very interesting and am now wanting to seek out a good, full history of the convention. Irons's history from there is primarily chronological, although he does shift the order slightly to group some major cases into themes. He doesn't quite provide the biographies of each Supreme Court justice that he discussed in the introduction, but he comes close, along with discussion of the surrounding politics of the nomination and the political climate in which they were sitting. There's a bit of an overview of the types of cases each court saw, although not as much as I would have liked. Most of the history is, as one might expect, focused on more detailed histories of the major cases. Here, I was sometimes left satisfied and sometimes left a bit annoyed. The discussion of the Japanese internment cases is excellent, as you might expect given Irons's personal role in getting them overturned. The discussion of the segregation cases is also excellent; in general, I found Section V the strongest part of this book. Irons also does a good job throughout in showing how clearly political the court was and has always been, and the degree to which many major decisions were pre-decided by politics rather than reasoned legal judgment. Where I think he fails, however, is that much of this book has little sense of narrative arc. This is admittedly difficult in a history of a body that takes on widely varying and almost random cases, but there are some clear narratives that run through judicial thinking, and I don't think Irons does a good enough job telling those stories for the readers. For example, I remembered the evolution of interpretation of the 14th Amendment from freedom of contract to the keystone of application of the Bill of Rights to the states as a compelling and coherent story from his course, and here it felt scattered and less clear. In general, I liked the earlier sections of this book better than the later, with Section V on the Warren court as the best and last strong section. Beyond that point in the history, it felt like Irons was running out of steam, and it was harder and harder to see an underlying structure to the book. He would describe a few cases, in a factual but somewhat dry manner, make a few comments on the merits of the decision that felt more superficial than earlier sections of the book, and then move on to another case that might be largely unrelated. Recent judicial history is fascinating, but I don't think this is the book for that. Irons is much stronger in the 19th and first half of the 20th centuries; beyond that, I prefer Jeffrey Toobin's The Nine, which also has far deeper and more interesting biographies of recent justices. This is not a bad history of the Supreme Court. If you're looking for one, I can recommend it. But if you're flexible about format, I recommend Irons's course more. I think it's less dry, better presented, and flows better, and I don't feel like you'll miss much in the transformation of this book into an 18 hour course. It's also remarkable to hear the actual voices of the lawyers and justices in some of the landmark cases of the middle of the 20th century. But if you specifically want a book, this does the job. Do also read The Nine, though. It's a good complement to Irons's straight history, showing much more of the inner workings, political maneuverings, and day-to-day struggles of the justices. Rating: 7 out of 10

AltOS 1.4.1 Fix ups for 1.4 Bdale and I are pleased to announce the release of AltOS version 1.4.1. AltOS is the core of the software for all of the Altus Metrum products. It consists of firmware for our cc1111, STM32L151, LPC11U14 and ATtiny85 based electronics and Java-based ground station software. This is a minor release of AltOS, incorporating a small handful of build and install issues. No new features have been added, and the only firmware change was to make sure that updated TeleMetrum v2.0 firmware is included in this release. AltOS TeleMetrum v2.0 firmware included AltOS version 1.4 shipped without updated firmware for TeleMetrum v2.0. There are a couple of useful new features and bug fixes in that version, so if you have a TeleMetrum v2.0 board with older firmware, you should download this release and update it. AltosUI and TeleGPS Signed Windows Drivers, faster maps downloading We finally figured out how to get our Windows drivers signed making it easier for Windows 7 and 8 users to install our software and use our devices. Also for Windows users, we ve fixed the Java version detection so that if you have Java 8 already installed, AltOS and TeleGPS won t try to download Java 7 and install that. We also fixed the Java download path so that if you have no Java installed, we ll download a working version of Java 6 instead of using an invalid Java 7 download URL. Finally, for everyone, we fixed maps downloading to use the authorized Google API key method for getting map tiles. This makes map downloading faster and more reliable. Thanks for flying with Altus Metrum!