I run a program called logcheck which regularly scans the logfiles looking for interesting things . One of these interesting things (to logcheck, not to me at first) was dbus complaining about mythtv. The logs look something like this:

Nov 17 05:08:18 elmo dbus-daemon[1621]: dbus[1621]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.236" (uid=999 pid=3669 comm="/usr/bin/mythfilldatabase --verbose general --logl") interface="org.freedesktop.NetworkManager" member="GetDevices" error name="(unset)" requested_reply="0" destination="org.freedesktop.NetworkManager" (uid=0 pid=1930 comm="/usr/sbin/NetworkManager ")

What this is is the dbus daemon rejecting a message being sent from mythfilldatabase that wants to go to NetworkManager. Looking at NetworkManager s dbus configuration, its doing all the right things. So it s a simple matter of just fixing up the dbus configuration and you re done. Then I hit the first snag; the dbus documentation is a little sad. I remember seeing a show where they MRI scanned some artifacts to get to the writing and then used a maker-bot to recreate the hidden writing. They then painstakingly translated it using a team of experts to work out the English translation. Working out the dbus configurations is not quite that difficult, but it s close. The easiest way is to copy something and see if it works, which is what I did. I created a file /etc/dbus-1/system.d/mythtv.conf which permitted the myth user access to the GetDevices method. It looks like: Reloaded dbus and all went quiet.

Related articles

• Dbus C API (Part 1) (benzidwael.wordpress.com)

This is part 6 in a series on organizational design and growth.

The change from a business that the owner-entrepreneur can run with helpers to a business that requires management is a sweeping change. [...] One can compare the two kinds of business to two different kinds of organism: the insect, which is held together by a tough, hard skin, and the vertebrate animal, which has a skeleton. Land animals that are supported by a hard skin cannot grow beyond a few inches in size. To be larger, animals must have a skeleton. Yet the skeleton has not evolved out of the hard skin of the insect; for it is a different organ with different antecedents. Similarly, management becomes necessary when an organization reaches a certain size and complexity. But management, while it replaces the hard-skin structure of the owner-entrepreneur, is not its successor. It is, rather, its replacement. Peter Drucker

What it means Management is the art of enabling people to cooperate in achieving shared goals. I ve written elsewhere about what management is not. Management is a multifaceted discipline which is centered on people and the environment in which they work. Why it s important In very small organizations, management can be comparatively easy, and happen somewhat automatically, especially between people who have worked together before. But as organizations grow, management becomes a first-class concern, requiring dedicated practice and a higher degree of skill. Without due attention to management, coordination becomes excessively difficult, working systems are outgrown and become strained, and much of the important work described in this series just won t happen. Management is part of the infrastructure of the organization, and specifically the part which enables it to adapt and change as it grows. Old Status Quo People generally just do stuff , meaning there is little conscious understanding of the system in which people are working. If explicit managers exist, their jobs are poorly understood. Managers themselves may be confused or uncertain about what their purpose is, particularly if they are in such a role for the first time. The organization itself has probably developed more through accretion than deliberate design. New Status Quo People work within systems which help coordinate their work. These systems are consciously designed, explicitly communicated, and changed as often as necessary. Managers guide and coordinate the development and continuous improvement of these systems. The role of managers in the organization is broadly understood, and managers receive the training, support and coaching they need to be successful. Behaviors that help

• It can be helpful to bring more experienced managers into the organization at this stage, especially if there isn t much management experience in house.
• Show everyone in the organization (including managers themselves) what managers do and why it matters.
• Consider very carefully whether someone should become a manager.
• If someone does take on a management role, treat this as a completely new job, which requires handing off their existing responsibilities and learning a new discipline. Don t treat it as just an extension of their work. Write a new job description and discuss it up front.

Obstacles that stand in our way

• Management misbeliefs
• Granting promotions to management roles as rewards for performance
• Many people, when they experience what management work is like, don t enjoy it and aren t motivated by it. It can be hard to predict when this will be the case, and people can feel trapped in a management role that they don t want. Make sure there are mechanisms to gracefully transition out of roles that don t fit for the people holding them.

Review: Anathem, by Neal Stephenson

Publisher:	William Morrow
Copyright:	2008
ISBN:	0-06-147409-6
Format:	Hardcover
Pages:	935

Fraa Erasmas is a little less than twenty years old and is an avout of the decade math of the Concent of Saunt Edhar. As Anathem opens, he's approaching his first apert. All of those words are left for the reader to puzzle out for themselves, unless you cheat and read the glossary (which I would recommend doing only with caution, but more on that in a moment), since Erasmas, the first-person narrator of this story, writes (mostly) as if the reader is familiar with the mathic world and its concepts. Translated into English, it means that Erasmas was brought into something akin to a scientific monastery (the "math") at around the age of nine and has been there for ten years, since his math is a decade math and therefore remains closed to all outside (s cular) ideas and contact for periods of ten years at a time. He is still a student there, not yet declaring allegiance to one of the chapters. That's something that he will be expected to do after the first apert. Every ten years, the decade math opens its doors to the outside world for a period of ten days (apert), and the fraas and suurs can leave the math and travel through the outside world as they wish. The start of Anathem is an exercise in alienation and reorientation. Stephenson has constructed a complex society with a long history and its own specific technical jargon and throws the reader into it with a minimum of orientation. Despite being familiar with SF novels that use this technique, I did read the preface and recommend that other readers do as well unless they particularly love piecing together a world from hints and clues. The timeline, in particular, was invaluable and something I referred to throughout the story. But even with the preface, you should expect to read the first part of Anathem interpolating meanings from context or just letting things slip past until you later come to understand them. A lot of people bounce off of Anathem here, and it's one of the reasons why I'd been postponing reading it (the other being that it's a substantial doorstop and I wanted to give it my undivided attention). But it's really not as bad as I feared. One gets a feel for the terms fairly quickly, and the more difficult ones Stephenson defines as he goes with excerpts from a dictionary of the mathic world. I found it slightly disorienting for a chapter or two, and then it started growing on me. The terminology is sometimes different just for the sake of being different (jeejahs are indistinguishable from smartphones for all practical purposes), but usually the invented words provide either important links to the past of the constructed world of Arbre or are technical terms that add precision and clarity once you know their meanings. It can be a little bit frustrating to remember the mapping of famous theories and theorems to the Orth names, but only mildly. (And Diax's Rake is so useful of a name for something that English doesn't name that I may start using it myself.) This is also why I recommend against reading the glossary. The definitions of terms are linked to important parts of history, which are, in turn, linked to important parts of the plot, and the glossary therefore risks spoilers. I liked having the term introduced by the frequent dictionary excerpts scattered through the chapters, and enjoyed the feeling of the terminology unfolding with the plot. The glossary is there if you really get lost, but I think the experienced SF reader (particularly if you have enough history background to pick up on the obvious parallels and start mapping bits to Greece, Rome, the Catholic Church, etc.) will be able to navigate the language without that much difficulty. I also stopped caring about the terminology because the story is so engrossing that it pulled me right into the book, closed over me, and made Erasmas's world feel real, precious, and fascinating. Whether that's going to be true of other people is a surprisingly difficult question, and one that I'll try to tackle as part of this review. But I will say up-front that I think this is the best book that Stephenson has ever written, even better than Snow Crash, despite some undeniable flab and one extremely irritating choice. Anathem is, at its heart, a novel about the scientific method. I think it's the first book by Stephenson that elegantly mingles his tendencies (and obsessions) as a writer with the interests (and obsessions) of the characters and makes the whole novel feel coherent. All of Stephenson's books are prone to discursive infodumps, but they've usually had to be shoehorned in around the characters. Even with the Baroque Cycle, a series full of natural philosophers, the digressions are jammed in around the plot like the filling of an over-packed box and frequently stick out at odd angles or dribble out on the floor. With Anathem, Stephenson has populated a book full of characters who have completely believable and engrossing reasons to digress into scientific debate and analysis, can put them into dialogue and thereby avoid some of the strain of the infodump, and (most importantly) largely restrains himself from narrative digressions via first-person narration and careful attention to when the characters themselves would follow the same digression. In short, this is a book full of very smart and very well-educated people who figure things out from first principles using agreed-upon theory, thrown into an unknown and dangerous situation that requires a great deal of deep thinking, science, engineering, and philosophy. All of Stephenson's quirks are still here, on prominent display, but rarely have I ever seen a better match of writer, characters, plot, and world background than this book. I would go so far as to say that, if you don't like this book, you're unlikely to like any long Stephenson. I haven't said a lot about the plot. Erasmas's apert is only the first part, and barely touches on any significant plot elements. It's mostly there to set some groundwork, introduce characters, and get the reader oriented. I'm not going to say much more, since the way the novel transitions from routine to unusual to emergency, and the resulting scramble to understand the emergency, is the heart and soul of this book and should not be spoiled. (I spoiled myself slightly by reading some analysis that I shouldn't have and regretted it, although it wasn't too much of a problem.) This is one of Stephenson's best-plotted novels. It develops slowly enough for the reader (and the characters) to think hard about it and make some good and bad guesses, but fast enough to stay engrossing. Most of it is very well-paced provided that you find the background of science and philosophy of science interesting. (If you don't, this is probably not a book you're going to enjoy.) I say "most of it" because, as mentioned earlier, this book is a bit flabby. There are a couple of sections where the theory and analysis are pushed aside by exigent circumstances and more action-oriented plot elements, both of which reminded me that Stephenson is very bad at writing action sequences and both of which I wished were shorter. And there are a couple of sections where Erasmas is getting oriented to a new situation or working up the courage to do something where I wished he'd get on with it already. But for a novel of nearly 1,000 pages, the amount of tension and reader interest Stephenson maintained for me was quite impressive. But as good as the plot is, the best part of this book is its full-bore, no-apologies embrace of understanding things. This is a book about making sense of the world, and about what it means to make sense of the world, and how you go about it, and what preconditions are required to do so. It is not, contrary to so much science fiction, a book about knowing things. The people who are already experts appear in this book, but generally only in the context of figuring out new things they've not previously been exposed to. Rather, it's a book about learning things, the thrill that comes from applying theory to understand something new, and the satisfaction of working through something from first principles or previously-established theory, arriving at testable predictions, and then testing them. It's the first novel I've read that captures some of the joy and delight that I got from reading George Gamow's One Two Three... Infinity as a child. Stephenson novels have always been about showing the reader neat things he learned, but I think previous books relied on the reader to bring their own enthusiasm. Anathem, at least for me, goes a step farther and uses the passion and approach of its characters to create that enthusiasm. It's one of those books that I not only enjoyed but went away from feeling like it made me a better person in some subtle but detectable way. Sadly, this is also where the irritating part comes in. I'm going to be very careful and indirect here, since the details are all extremely significant spoilers. You may want to skip to the last paragraph of this review if you want to avoid any knowledge about the end of Anathem. Stephenson pulls several rabbits out of the hat in this book, but most of them are well-defended and nicely handled bits of misdirection. There are a few where I thought the science or engineering was dubious, but even those are usually backed with enough hand-waving about Arbre technology that I could swallow it enough for the purposes of this book. (The timeline here is very helpful in allowing one to write off a few things as unknown technology.) But he puts, at the core of the plot, one of the most scientifically dubious bits of the whole book, and there's simply no avoiding that by the end of the story. Now, this doesn't mean that he just expects the reader to swallow it. Much of Anathem is a carefully-constructed defense of the bits he uses for the plot, and the defense is not half-bad within his fictional world. There are substantial in-book justifications for believing these techniques will work on Arbre even if they wouldn't in our scientific domain. So it's not so much the plausibility that bothered me; the idea is at least as plausible as some of the FTL drive concepts that I've swallowed without complaint. I do hold Anathem to a higher standard because the book is about science in a way that most science fiction isn't, but even with that, I think Stephenson mostly managed to dance across the thin ice he built. The problem is more subtle but more serious: if taken seriously on its own terms, the approach Stephenson takes to the plot destroys science in his universe. I can't really say more than that, since all of the details are huge spoilers, but the more I thought about it, the more irritated and annoyed I got. Anathem is otherwise a brilliant defense of the scientific method, and it felt like Stephenson injected a poison pill in the center of it, leading necessarily to a world where the scientific method no longer works. This does not happen on camera, or even between the pages of the book; you have to think about the implications for a while before you realize that's what happened. But once you do, it's a bitter pill to swallow, and it's hard to escape the feeling that it fundamentally undermines Stephenson's whole project here. And, to make it worse (although also oddly better in a way), I think it was unnecessary. He would have had to reconstruct the ending, but I can't shake the feeling that there were ways to write the ending, even maintaining the same character strengths, without having to pull that particular rabbit out of the hat. Because I think it's, in the end, unnecessary, I was still able to enjoy the whole book, including the ending, despite this, but while the rest of Anathem is a wholehearted 10, that choice knocked a full point off my impression of the book. It's profoundly irritating precisely because Stephenson did such an excellent job with the rest of it. But, that said, this book is still exceptional. I think it's the book that Stephenson was meant to write. Not only did he get the overall construction nearly perfect, he gets so many of the details right, from the history (which for a while I thought was merely clever, once I started seeing the correspondences that moved it out of the realm of pure invention, but which transitioned back to profound with later revelations in the book) to the language to the way that he excerpted some theoretic digressions into very well-done appendices. If you've ever thought of a theory as beautiful, or like reading about smart people debating the nature of understanding and knowledge, I cannot recommend this book too highly. Despite the highly irritating flaw at its center, and despite a few sections that show Stephenson is not a well-rounded writer, I think it's brilliant. Rating: 9 out of 10

Review: Wanderlust, by Ann Aguirre

Series:	Sirantha Jax #2
Publisher:	Ace
Copyright:	September 2008
ISBN:	0-441-01627-8
Format:	Mass market
Pages:	312

Wanderlust is the second book in the Sirantha Jax series and a direct sequel to Grimspace. There's no point in reading them out of order. The new shape of Sirantha's universe is still coming together after the climactic events of Grimspace, but they seem to involve a new job. In politics, even, but one for which she's uniquely qualified. Before she can even accept it, she finds out that multiple parties are interested in her taking this position, for widely varying reasons. But she starts her new position by taking a detour to visit some old friends (and the planet I liked least in Grimspace's settings), which turns into a war and a comprehensive distraction that lasts the rest of the book. The biggest problem with Wanderlust (and unfortunately there are several) is that it doesn't feel like a complete book. The first few chapters set up what appears to be the next step of Sirantha's adventures, as well as establishing a new villain, and then the rest of the book is an extended detour. She does learn more about the new villain, but almost everything that's set up at the start of this book is still unresolved at the end of it. The detours are moderately entertaining and (at least after an initial decision based on unfinished business from the first book) are at least related to the plot, but this feels like the setup and middle-book distractions of a book twice as long. I came away wondering why all of that was really necessary and why I had to wait to the next book to read the actual plot. The second problem with this book is the whining. And the angst. And the self-esteem issues. And did I mention the whining? Okay, I get that one of the distinguishing elements of this series is that it's space opera with an urban fantasy first-person perspective, and the latter usually comes with extensive angst and insecurity about one's love life. But, really, I am not interested in Sirantha complaining about her appearance yet again, and I am particularly not interested in the obnoxiously tedious "I love you and therefore I must push you away" dance that both she and the male romance lead do through half this book, and only stop doing because they can't any more. I realize that self-destructiveness is a thing, and that people do react this way, but I don't want to read about it, and I particularly don't want to listen to the narrator whine about how hard it all is for much of the book. Some of the appeal of Sirantha is that she's fragile, paranoid, and all sorts of messed up, but she muddles through and manages to do the right thing anyway. However, for me, the key word there is "do." When she's twitchy and angry and sarcastic and scared but doing something (which does also happen in this book), I really enjoy this series. When she's living in her own head and building elaborate plans for how she's going to destroy her life this time, it starts getting tiresome. It doesn't help that I don't see what she sees in her romantic partner (at least most of the time; he has his moments), and therefore I have even less sympathy for her grand self-sacrificing gestures. Thankfully, there are good parts too. Aguirre introduces a few new characters, all of whom I liked. Sirantha is assembling quite the ragtag band of misfits, and they're misfits in all the right sorts of ways. They play off each other well and they're full of plot hooks. We also get an amusing twist on Sirantha's relationship with her personal assistant AI, which, while bizarrely tangential to the plot, looks like it will hold a lot of promise for the future. And I love Vel, who made the end of Grimspace and who continues to be a highlight of these books, partly because he doesn't throw emotional temper tantrums or indulge in bizarre silent treatments. I always love the quietly competent characters in stories like this. This is not up to Grimspace, but hopefully it's an aberration. It's not bad, exactly, but it went off the rails. Thankfully, the next book promises quite a lot of Vel, which will hopefully be an improvement. Followed by Doubleblind. Rating: 6 out of 10

This is an essay form of a talk I have given today at the Cambridge Mini-debconf. The talk was videoed, so will presumably show up in the Debconf video archive eventually. Abstract Debian has a long and illustrious history. However, some of the things we do perhaps no longer make as much sense as they used to do. It's a new millennium, and we might find better ways of doing things. Things that used to be difficult might now be easy, if we dare look at things from a fresh perspective. I have been doing that at work, for the Baserock project, and this talk is a compilation of observations based on what I've learnt, concentrating on things that affect the development workflow of package maintainers. Introduction and background I have been a Debian developer since August, 1996 (modulo a couple of retirements), and have used it a little bit longer. I have done a variety of things for Debian, from maintaining PGP 2 packages to writing piuparts to blathering excessively on the mailing lists. My day job is to develop the Baserock system at Codethink. Baserock is a set of tools and workflows for developing embedded and appliance Linux systems. If you squint, it looks a bit like a source-based Linux distribution. I have worked on Baserock since September, 2011. Some of Baserock's design has been influenced by my experience with Debian. With Baserock I have the chance to fix all the things that are wrong in Debian, and this talk is me giving back to Debian by pointing out some the things I feel should be fixed. I don't have solutions for these problems: this is a bug report, not a patch. It's also perhaps a bit of a rant. I am specifically concentrating here on technical and tooling issues that affect the development process of Debian. I excluding social issues. I am also not trying to get Debian to switch to Baserock. Baserock is targeting embedded and appliance systems, and makes simplifying assumptions based on those targets, which Debian does not get to do. I am pointing out problems, and I am outlining solutions as implemented in Baserock, when I think the concept carries over well to Debian. Build tools should be intelligent, packaging should be dumb In Debian, the fundamental tool for compiling the upstream code and assembling a binary package is dpkg-buildpackage. It uses debian/rules, which is a Makefile with targets with specific names and semantics. By executing the right targets in the right order, dpkg-buildpackage tells the source package to build the binary package. On the one hand, this is a nice design, because it abstracts away the large variety of upstream build systems into one API for dpkg-buildpackage to use. On the other hand, it puts all the intelligence for how packages are built into the packages. Making packaging intelligent, rather than the build tool, means packagers need to do more work, and there's more work to do when, say, the Debian policy changes, or when there are other changes that affect a large number of packages. If packaging is intelligent, then every package needs changes. If the build tool is intelligent, then you change the build tool and re-build everything. In Baserock we put as much intelligence as we can into the Morph tool, which drives the build process. It turns out that today, unlike in 1995, most upstream projects use one of a handful well-known build systems: autotools, cpan, cmake, Python distutils, etc. With just a little extra logic in Morph we avoid having any delta against upstream in Baserock. This doesn't work for quite all upstream projects, of course, but we've spent the 2% (two, not twenty) of effort that solves 80% of the problem. In recent years, the dh approach to packaging has made a lot of packages be able to have only a minimal, 3-line debian/rules file. This is excellent. Wouldn't it be nice if even that wasn't needed? It'd save thousands of files in source packages across the archive, at least. It would be easy to: if the file is missing, have dpkg-buildpackage assume the 3-line version by default. Getting rid of a single file is, of course, not a particularly big win. The big win is the change in mindset: rather than dealing with all new issues in development by adding yet more fields to debian/control and more optional, competing tooling outside the core toolset, if you improve the tools everyone uses, then everyone's packages gets better. The goal should, in my opinion, be that for the large number of packages where upstream uses a well-known, well-behaved build system, and uses it in a reasonably sensible way, the Debian source package should not require anything added to make the package build. There will still be a need to add some stuff, such as the debian/copyright file, to make a good Debian package, but just getting the package to build should require nothing extra. (Side note: wouldn't it be nice if there was a well-known, widely used way to mark up copyright information so that debian/copyright could be constructed and updated automatically?) Configuration file handling on upgrades: add ucf to dpkg already In the 1990s, dpkg had excellent handling of configuration files and merging local changes with changes from the new package version, but it was excellent only because it tried to do that at all, and mostly nothing else did. It hasn't changed much, since, and it's not excellent on any absolute scale. We have the ucf tool, which can do a better job, but requires to be added to each package wanting to use it. Why don't we make dpkg smarter, instead? If ucf is not not good enough to be merged wholesale into dpkg, let's write something better. Making every package maintainer use ucf manually is just wasteful. This is not the kind of thing that should be done for each package separately: the package manager should be smart so that packaging can be stupid. The goal should be that dpkg is smart enough in its configuration file handling that having the package do it is a very rare special case. Clean building shouldn't be hard The basic tool for building a package is dpkg-buildpackage. It is ever so slightly cumbersome to use, so there are some wrappers, most importantly debuild. However, if you're making a build intended to be uploaded to the Debian archive, you should be doing a clean build. This means having to learn, configure, and use yet more tools. A clean build is important: security updates, development, debugging, quality control, porting, and user support become more difficult if we don't know how a package was built, and can't reproduce the build. It gets harder to keep build dependencies correct, making it harder for everyone to build things. Luckily, Debian has solved the clean build problem. Unluckily, it has solved it multiple times, creating the problem of having to choose the clean building approach you want to use. The default way of building is not clean, so then you have to remember to use the non-standard way. You also get to spend time maintaining the clean build environments yourself, since that doesn't seem to be fully automated. None of this is hard, as such, but it's extra friction in the development workflow. The primary approaches for clean building in Debian seem to be pbuilder, cowbuilder, and sbuild. I happen to use pbuilder myself, because it's what's been around the longest, but I make no claim of having made an informed choice. That is part of the problem here: why should I have to spend the effort to become informed to make a choice well? Why is the default way of building not clean? Don't say performance: Morph sets up a clean staging area in seconds, and does not offer you a choice of not doing so. It's a chroot, with everything but the build tree hardlinked from cached, unpacked build dependencies, and protected using read-only bind mounts. What's more, this approach avoids having to maintain the pbuilder base tarballs or sbuild chroots manually. It's all automatic, and up to date, for every build. Furthermore, the staging area contains only the specified build dependencies, and not anything else, meaning a build fails if a build dependency is missing, rather than succeeding because it happens to be in the default set of packages the build tool installs. Mass building shouldn't be hard Suppose you want to try out a large-scale change in Debian. It might be trying out a new version of GCC, or using llvm's clang as the default C compiler, or updating glibc, or doing a large library transition such as a new version of GTK+, or trying a new dpkg version, or even something more exploratory such as changing the default optimisation flags for all packages to see what breaks. All of these will require you to at least rebuild all affected packages. Ideally you'd test the built packages as well, but let's concentrate on the building for now. Here's what you do. You make the changes you want to try out, and build those packages. You create a dedicated APT repository, and upload your packages there. You configure your build environment to favour that APT repository. You make a list of all reverse build dependencies of the packages you changed. You write a script to build all of those, preferably so that if you change A, and rebuild B, then you also rebuild C which build depends on B. Each rebuilt package you also upload to your APT repository. You keep track of the build log, and success or failure, of each build. The people in Debian who do this kind of stuff regularly presumably have tools for doing it. It shouldn't be a rare, special thing, though. If my package has reverse build dependencies, I should at least consider testing building when I'm making changes. Otherwise, it might take years until the reverse build dependencies are rebuilt, and the problem is only found then, making it harder to fix. To be fair, building a lot of packages takes a lot of resources. It's not feasible to rebuild everything in Debian every time there's any change to, say, eglibc. However, it's feasible to do it, for large subsets of the archive, without huge hardware investments. One VCS to rule them all In 1995 there was really only one relevant version control system: CVS. It was not a great tool. In 2000, another contender existed: Subversion. It fixed some problems in CVS, but still wasn't a great tool. In 2005, there was a great upheaval and distributed version control systems started to become mainstream. There were a large handful of them. In 2010, it was becoming pretty clear that git had won. It's ugly, but it's powerful. I'm not going to debate the relative merits of different version control systems. Until recently, I was a Bazaar boy, and all of my personal projects were kept in Bazaar. (I have recently switched everything to git.) There are, however, strong benefits from everyone using the same system. Developers don't need to learn a dozen version control systems. Tools that operate on many repositories are easier to write and maintain. Workflows become simpler if one system can be assumed. Debian has a strong historical tendency to choose every option. This is sometimes a good thing, and sometimes a bad thing. For keeping source packages in version control I believe it is to be a bad thing. The status quo is that a Debian source package may not be in version control at all, or it might be in any version control system. This is acceptable when everyone only ever needs to maintain their own packages. However, in a distribution the size of Debian, that is not the case. NMUs, security support, archive wide transitions, and other situations arise when I might need to change yours, or you might need to change mine. We try to work around this by having a complicated source package format, using quilt to maintain patches to upstream semi-manually in a debian/patches directory. This is an awkward workflow. It's a workflow that trips up those that are not used to it. (I know quilt is a patch management system, not a version control system. I think git does it much better anyway.) It would be oh so much easier if everyone kept their source packages in the same, real version control system. I don't even care what it is, as long as it is powerful enough to handle the use cases we have. Imagine a world where every Debian source package is kept, for argument's sake, git, and everyone also uses the same layout and roughly the same workflow to maintain it. What would this mean? It would mean that if you want to inspect the history of your package, you know how to do that. If you want to merge in some bugfix from upstream code, you know how to do that, without having to figure out which of the several source package formats are in use. It would make feasible the development of more powerful, more higher level tooling. For example, it would allow Debian to have what we call system branches in Baserock. In Debian we have stable, testing, unstable, and experimental. We may get something like Ubuntu's PPAs, or perhaps an improved version of those. These are very poor versions of system branches, just like quilt is a poor way to manage patches and deltas against upstream. For example, you can upload an experimental version of gccto experimental, but then nobody else can upload another experimental version. You can set up your own PPA for this, but you'll still be affected by all the uploads to unstable while you're working. A Baserock system branch is a branch of the entire system, or the entire distribution in the case of Debian. It is isolated from other system branches. In branch in an individual repository is a well-known concept. A system branch is conceptually like branching every repository in the distribution at once. The actual implementation is more efficient, of course. This would be possible to implement without standardising on one version control system, but it would be much harder to implement, and would have to live with the lowest common denominator for features. CVS and Subversion, for example, don't really to merges, where Bazaar, Mercurial, and git do. Possible does not mean feasible. Any work you do in a system branch is isolated. Your work doesn't affect others, and theirs doesn't affect yours, until a merge happens. This is a simple, but very powerful tool. Cheap system branches, and powerful merging, makes it possible to do experiments safely, with little fuss. Combine that with being able to build everything cleanly and quickly, and get into a situation where there's no need to have make technical decisions based on arguments on mailing lists, and instead they can be done by choosing by looking at working code. I don't know how this could be implemented in Debian, but think about it. If Debian could have this, it might many archive-scale changes easier. debian/rules clean: really? One of the silliest things we require of packages is that they have a debian/rules clean rule that cleans up after a build perfectly so that we can do repeated builds in the same source tree. Let's just use git clean -fdx instead. This is a problem that is superbly well suited for automation. There is no point whatsover making packagers do any manual work for this. Large scale semi-mechanical changes require too much effort About a decade ago, we decided to follow a new version of the Filesystem Hierarchy Standard and transition from /usr/doc to /usr/share/doc. This was an almost entirely mechanical change: in many cases, a mere rebuild would fix it, and in almost every other case it was just a minor tweak to the packaging. A one-line change. It took us seven years to do this. Seven years. Think about it. In a recent discussion about building R binary data files from source at package build time it was suggested that we take 2-3 release cycles to get this done. That's four to six years. Think about it. These are not isolated cases. Every time we need to make a change that affects more than a small handful of packages, it becomes a major undertaking. Most of the time all the people involved in this are agreeable to the change, and welcome it. The change takes long because it requires co-ordinating a large number of people. Sometimes people are just busy. Sometimes they've left the project, but haven't properly orphaned their packages. Waiting for a timeout for answers about packages drags the process longer. Mechanical changes, or semi-mechanical ones, which are very easy and very quick to do should not take years. They should take an evening, no more. There's no end of changes we might want to do like this. In 2005 and 2006 I filed a few hundred bugs from failed piuparts runs. They're still being fixed, even when the fix is simple, such as adding a postrm script to remove, when the package is purged, a configuration file created by postinst, or starting the service with invoke-rc.d rather than running an init.d script directly. Mostly one-line changes. There's more mechanical changes that might happen. For example, changing the value of the VCS-Browser field when the Debian version control server changes domain names. It's not just about simple, mechanical changes, either. Transitions of important library packages, for example, which require changes to reverse dependencies due to a changed API are another source of pain. What should be a few evenings of build fixes can drag out to months of co-ordination. This is caused partly by technical issues, and partly due to social issues. The main social issue is that we have quite a strong ownership of packages, and NMUs are to be done carefully, and only in some cases. This is both good and bad, and I won't discuss that aspect now. The technical issues are that our tools are primarily intended for maintaining individual packages, rather than all of them together, making it harder to make even simple changes in large number of packages. In addition to easy mass building and system branches, as outlined above, large-scale changes would require testing tools so that you don't build the new package versions, but also test things automatically. Essentially, CI at the distribution level. Conclusion I've listed above a small variety of problems I see in the Debian development processes and tools. They're not the important part of this talk. The important part is that it we, the Debian developers, should look at our tools, and workflows, critically, and improve them when we can. Even small improvements are very useful, when they affect each of our twenty thousand source packages. The important change I argue for here is one in mindset, rather than any specific problem in any tool. We need a mindset of constant, incremental improvement for our tools.

Review: Blue Remembered Earth, by Alastair Reynolds

Series:	Poseidon's Children #1
Publisher:	Ace
Copyright:	January 2012
Printing:	June 2012
ISBN:	0-441-02071-2
Format:	Hardcover
Pages:	505

Geoffrey Akinya is one heir to the vast Akinya business empire, which straddles the solar system and has created vast riches from exploration and mining. He wants nothing to do with it. His passion is elephants: long and methodical study of wild herds in Africa, including a slow and careful investigation into their thought processes. His obnoxious and superior cousins have a passion for business and finance and can have the running of the company for all he cares. But Geoffrey's grandmother Eunice, the family matriarch and driving force behind much of their business expansion, has died. Her ashes are brought back to Africa from the Winter Palace in orbit around the Moon where she lived out her final days and scattered in a family ceremony. And, shortly thereafter, Geoffrey's cousins convince him to investigate a safe-deposit box left on the Moon by Eunice to ensure that it doesn't contain anything damaging to the family. What it contains is the first step in a puzzle. Despite himself, Geoffrey and his sister Sunday an artist and family black sheep who lives in a region of the Moon that is one of the sole holdouts against the ubiquitous monitoring common in the rest of the inhabited solar system are slowly pulled into unraveling that puzzle. This leads them into an uneasy alliance with one of the major political forces in the solar system and some startling revelations about their grandmother's actual plans. Blue Remembered Earth is another entry in the currently-popular sub-genre of solar system SF. Interstellar travel is still a dream, but a combination of improved technology, suspended animation, and heavy use of robots and robotic factories has let humans slowly expand into more of the solar system. On Earth, powers have risen and fallen, and the leap into the solar system coincided with a surging and powerful Africa. Extensive undersea colonization has established a new international consortium of sea-floor countries, and Earth politics have realigned into a diplomatic and business struggle between surface and oceanic nations. Unusually for this sort of fiction, most characters of significance in this story are African. The United States and Europe have quietly disappeared in the way that all non-US countries tend to in most other SF. Reynolds doesn't do very much with this setup (and the characters don't seem distinctly African to me). It's just there as the unremarked normal. I liked that. I kind of wish more of African culture had come through in the story, but there are enough SF novels with an assumed and unremarked white (and usually US) future that an assumed and unremarked black African culture is a nice change of pace. I picked up this book in part because it was described as a better 2312. That's a fairly accurate summary (although only helpful to those who have read Kim Stanley Robinson's novel). The scope and setting are similar, although Reynolds's future cuts back on the scope of off-world human colonization, relies more heavily on robotics, and keeps the power base on Earth. Both books are structured as a mystery, although in Blue Remembered Earth that mystery is deliberately planted for the characters. Reynolds is nowhere near as good at set pieces as Robinson, sadly. There's nothing here at the level of some of the scenes on Mercury in 2312. But he is much better at plotting and characterization, and Blue Remembered Earth tells a coherent story with increasing tension and a satisfying ending. Reynolds here uses an interesting strategy for spinning a mystery out of pieces of knowledge and discovery: set the discovery process prior to the novel, use protagonists who were unaware of it, and turn the details into a mystery that they have to investigate. This is an interesting way to address the problem that most discovery processes are slow and not particularly dramatic. It is artificial Eunice creates the plot for the novel but that worked for me. By the end of the book, I think I understand her reasons for doing so, and both Geoffrey and Sunday have good reasons to not be aware of any of the details before they start following the clues that Eunice leaves behind. The mystery of course sends Geoffrey and Sunday on a bit of a tour of the solar system as well as a tour of the past of their family business and the politics of the present. Here, Reynolds draws on an old SF idea: a conflict between groups that want to mechanize space exploration and groups that want to adapt humans for space. Long-time SF readers will be familiar with this approach, and I don't think Reynolds does anything startlingly new with it, but I thought it was a well-executed side plot. And, for once, an SF author realizes that Earth's oceans are as compelling of a place for that conflict to play out as outer space. There are, of course, significant mysteries to be uncovered, but it takes much of the book before those revelations start (even if one of them is almost spoiled in the dust jacket summary). The story up until that point is driven by character, particularly Geoffrey's stubborn annoyance at the rest of his family and his complete lack of interest in being the protagonist of a novel. I should probably warn here that many of the Amazon reviews disliked this book because of the characters, particularly Geoffrey. Apparently he comes across to some as whiny, resentful, and annoying. I, however, didn't have this reaction at all, possibly in part because I wholeheartedly share his opinion of both big business and his cousins. I thoroughly enjoyed reading an SF novel whose main characters are not driven either typical capitalist motives or a desire for personal exploration, but instead are pulled into the plot through a sense of loyalty and an inability to get out of the way of the problem. I also liked the way Reynolds manages to broaden and deepen the reader's appreciation for the characters as the story unfolds, and even salvages some characters I thought were unsalvageable. The last third of the book features some excellent plot twists and some very nicely-handled revelations. This is apparently the first book of a trilogy, and I had a suspicion at the end of the book that sequels were coming, but I think it stands on its own quite well. Most of the questions raised by the plot are resolved by the end of the book, and those that remain are of a size that other books have left unanswered intentionally. Despite not reaching the same moments of awe-inspiring beauty, and despite more workman-like descriptions, the stronger plot and more interesting characters do make Blue Remembered Earth a better 2312 for me. Given that 2312 won a Nebula, that's saying something (although I don't agree with that award). It's a bit deliberate in its pacing, and the plot built around a constructed puzzle can feel a bit artificial, but I think it's a solid and satisfying near-space SF novel. Followed by On the Steel Breeze. Rating: 7 out of 10

Review: Water Logic, by Laurie J. Marks

Series:	Elemental Logic #3
Publisher:	Small Beer Press
Copyright:	2007
ISBN:	1-931520-23-2
Format:	Trade paperback
Pages:	332

Water Logic is the third book in the Elemental Logic series, starting with Fire Logic. As with Earth Logic, it's best to read all three books in close temporal proximity, since Water Logic offers little recap of what happened in the previous books and relies on a large cast of characters who are not reintroduced. It's also hard to review without spoilers for the previous books. Earth Logic ended with a monumental shift in Shaftal politics, and half of Water Logic is deeply concerned with the implications of that shift and where Shaftal should go from here. Karis and Zanja are, of course, deeply involved, but much of the political story is told from the perspective of the character introduced in Earth Logic, and from the perspective of another earth blood, Meriseth. Water bloods haven't been seen much so far in the series. Water magic is about repeated patterns and the malleability of time, and the plot of Water Logic eventually entangles Zanja in events far in the past of Shaftal. This proceeds in parallel with more of Marks's excellent analysis of the meaning of war and peace, diplomacy, cooperation, multiculturalism, adaptation, and empathy. The two sides of the book do to some extent reinforce each other, but the connections are tricky and less obvious. Parts of this book are excellent. Wars are complicated and powerful, and don't end easily. The mutual incomprehension and mutual (if intermittant) struggle for understanding between the natives of Shaftal and the Sainnites is beautifully presented. I particularly loved Mariseth's approach throughout the book. Earth bloods are perhaps Marks's best invention, and seeing another (besides Karis) at work, with the same stubborn patience but with different tactics and different levels of power, was a delight. I feel like reading, and thinking about, Seth's decisions makes me a better person. As with the previous books, though, parts of Water Logic are a bit boring, or at least don't seem to coherently move in a conclusive direction. Zanja has long journeys across the landscape as well as several adventures after she's grabbed by water logic that seem only distantly connected to the rest of the story. Marks does pull this mostly together in the end, and I could detect other thematic linkages while mulling the book over after finishing it, but the book feels a bit disjointed while reading it. And there are some elements, such as the cowdogs, that are neat bits of world-building but that seem tossed in just because they're neat and don't feel strongly connected to the plot. The other complaint I have, which would probably have been lessened by reading the books closer together, is that the cast is a bit too large. All of Karis's extended family are, of course, still around, which I found more confusing than helpful. Named and important characters keep popping in and then disappearing, with no introduction and no help for the reader who doesn't remember the exact details of their roles from previous books. It's a bit frustrating, and it makes the book feel a bit cluttered, although it does a great job of showing the dynamics of a large and comfortable family. (Marks shows the dynamics of family webs with multiple adults better than any other fantasy author I know.) Karis is a bit more sidelined in this book, casting her in the role of force of nature, and I think that works well. It took me a bit to warm to Zanja again, but by the end of the book I was greatly enjoying her sections. But the star, for me, is Seth. Even though some of her segments should have been the boring parts of the book, since they were mostly concerned with quitodian issues, they were the parts I wanted to read about. I was very touched by the ending, even if I think a bit too much authorial hand-waving was required. There is material left for a sequel at the end of Water Logic, including a villain who has yet to fully appear, but it's currently not clear whether Air Logic will ever materialize. But, as with Earth Logic, Water Logic provides a satisfying ending and leaves the world in a stable enough place that I didn't feel cheated out of the end of the story. I think Fire Logic remains the strongest book of this series, but Water Logic is very much worth reading if you've read the previous books. Unfortunately, the books apparently didn't sell well, so this book is from a small press instead of Tor. You may have to order it on-line instead of finding it a local bookstore. But the whole series is very much worth reading. It's a refreshingly original take on fantasy and is much more thoughtful about human relationships and politics than most fantasy works. Rating: 7 out of 10

Last week was the OpenStack Design Summit Icehouse in Hong-Kong where we, OpenStack developers, discussed and designed the new OpenStack release (Icehouse) that is coming up. The week has been wonderful. It was my second OpenStack design summit, and I loved it. Bumping into various people I've never met so far and worked with online was a real pleasure. As it was to meet again with fellow OpenStack developers! The event organisation was great, as were the parties. :-) On the last day, I had the chance to present a talk with Eoghan Glynn and Nick Barcet how we built the auto-scaling feature in Heat, implementing the "alarming" feature needed in Ceilometer.

The slides and video of the talk is online on my talks page. Design sessions This time, Ceilometer design sessions were spread on 3 days. Everything we talked about has its Etherpad instance. The discussions were interesting, and the amount of feedback gathered is big and is going to be very useful. There's a lot of people and companies using Ceilometer now, and the project is getting more and more traction in general. There's a lot of different way to use it and to bend it to one's needs. Considering the amount of features and options that is provided, building functionality with a genericized approach it making Ceilometer useful for a lot of different and interesting use-cases. Icehouse roadmap The list of blueprints targeting Icehouse is available, but not yet complete. I expect people to start filling this list in the next days.If you want to propose blueprints, you're free to do so and inform us about it so we can validate it. The same applies if you wish to implement one of them! Thereafter, I try to guess what the roadmap will look like in the upcoming weeks for Ceilometer based on the discussion we had last week during the summit. Events management A lot of work is going to be put into event management. Ceilometer plans to store notifications sent using oslo.messaging by OpenStack projects. Some work already got merge for Havana, but the API part and future improvements and ideas will continue to flow into the Icehouse release. Agents and group management A lot has been discussed around the polling agents and around the alarm evaluator agent. The current state of the ceilometer-central-agent disallows any kind of high-availability and load-balancing, as the polling task are kept and scheduled on only one node. The high-availability part is already covered by a custom mechanism built into ceilometer-alarm-evaluator, but it came clear to us that a more generic approach is needed. A lot of other projects needs this kind of functionality, and a pattern have been pointed out. A blueprint about group membership has been discussed in an Oslo session, and will end into a new Python library written to solve this in Ceilometer and in other projects. TaskFlow will also probably be leveraged to solve the task distribution issue. Documentation Since a few weeks, Ceilometer auto-generates its API reference documentation using sphinxcontrib-docbookrestapi that parses our API code that uses WSME. We also want to start writing a user guide, and we'll do that inside our own repository. That way, I hope that we will be the first project in OpenStack to require documentation to be incorporated into every patch that's being sent to Ceilometer. This is the best way to assure that nothing can be changed nor added without being accompanied with a documentation update. Tempest testing Testing of Ceilometer already has been a subject during the previous design summit about testing. We already put a large effort on Tempest testing in this last cycle, but we encountered a lot of small issues that we had to tackle to achieve something. Some Ceilometer basic tests are already on their way into Tempest, so this is something that is going to be achieved very soon. Ultimately, I would also want Ceilometer moving towards providing its own set of Tempest tests as part of the code base. That way, it'd be as easy for core reviewers to refuse a patch if it doesn't provide functional tests as it is to refuse it if it doesn't provide unit tests. As we'll do for the documentation. API improvements Once again, a few API improvements will probably be implemented, like aggregation or the ability to specify multiple queries with OR and AND operators. Roll-up, archiving of data There seems to be interest in archiving and rolling-up the data stored by Ceilometer, so work in this area is to be expected. Supporting multiple data storage driver in parallel seems to be something that needs to be done for this and other aspects of Ceilometer feature set. Alarming The alarming feature set is already big, and the work that has been accomplished pretty amazing. A few improvements will be made, as retrieving better metrics and building better statistics (exclusion of low quality data points).

While quite old fashioned, SNMP is still an ubiquitous protocol supported by most network equipments. It comes handy to expose various metrics, like network interface counters, to be gathered for the purpose of monitoring. It can also be used to retrieve and modify equipments configuration. Variables exposed by SNMP agents (servers) are organized inside a Management Information Base (MIB) which is a hierarchical database¹. Each entry is identified by an OID. Querying a specific OID allows a manager (client) to get the value of an associated variable. For example, one common MIB-module is IF-MIB defined in RFC 2863. It contains objects used to manage network interfaces. One of them is ifTable whose rows are representing agent s logical network interfaces. Each row will expose the interface name, characteristics and various associated counters.

ifIndex	ifDescr	ifPhysAddress	ifOperStatus	ifOutOctets
1	lo		up	545721741
2	eth0	0:18:f3:3:4e:4	up	78875421
3	eth1	0:18:f3:3:4e:5	down	0

ifTable is indexed by its first column ifIndex. If you want to get the operational status of the second interface, you need to query IF-MIB::ifOperStatus.2 which is translated to OID .1.3.6.1.2.1.2.2.1.8.2 using information provided by the MIB definition.

Scripting SNMP An SNMP agent can deliver a lot of interesting information:

• interface counters with IF-MIB,
• IP addresses with IP-MIB,
• routing tables with IP-FORWARD-MIB,
• inventory with ENTITY-MIB,
• neighbors with LLDP-MIB.

You can gather those information manually with tools like snmpget and snmpwalk:

$ snmpwalk -v 2c -c public localhost IF-MIB::ifDescr      
IF-MIB::ifDescr.1 = STRING: lo
IF-MIB::ifDescr.2 = STRING: eth0
IF-MIB::ifDescr.3 = STRING: eth1

However, building robust scripts with them is quite challenging. For example, if you wanted to get the descriptions of all active interfaces as well as the total number of octets transmitted, you could do something like that:

#!/bin/sh
set -e
host="$ 1:-localhost "
community="$ 2:-public "
args="-v2c -c $community $host"
for idx in $(snmpwalk -Ov -OQ $args IF-MIB::ifIndex); do
    descr=$(snmpget -Ov -OQ $args IF-MIB::ifDescr.$idx)
    oper=$(snmpget -Ov -OQ $args IF-MIB::ifOperStatus.$idx)
    in=$(snmpget -Ov -OQ $args IF-MIB::ifInOctets.$idx)
    out=$(snmpget -Ov -OQ $args IF-MIB::ifOutOctets.$idx)
    [ x"$descr" != x"lo" ]   continue
    [ x"$oper" = x"up" ]   continue
    echo $descr $in $out
done

Hopefully, SNMP bindings in various languages are pretty common. For example, Net-SNMP ships with a Python binding:

import argparse
import netsnmp
parser = argparse.ArgumentParser()
parser.add_argument("host", default="localhost", nargs="?",
                    help="Agent to retrieve variables from")
parser.add_argument("community", default="public", nargs="?",
                    help="Community to query the agent")
options = parser.parse_args()
args =  
    "Version": 2,
    "DestHost": options.host,
    "Community": options.community
 
for idx in netsnmp.snmpwalk(netsnmp.Varbind("IF-MIB::ifIndex"),
                            **args):
    descr, oper, cin, cout = netsnmp.snmpget(
        netsnmp.Varbind("IF-MIB::ifDescr", idx),
        netsnmp.Varbind("IF-MIB::ifOperStatus", idx),
        netsnmp.Varbind("IF-MIB::ifInOctets", idx),
        netsnmp.Varbind("IF-MIB::ifOutOctets", idx),
        **args)
    assert(descr is not None and
           cin is not None and
           cout is not None) #  
    if descr == "lo":
        continue
    if oper != "1": #  
        continue
    print("     ".format(descr, cin, cout))

This binding is quite primitive and has several drawbacks:

1. It exports everything as strings. See .
2. Error handling is just deficient. If you mispell something, like a variable name, you ll get snmp_build: unknown failure on the standard error. No exception. If a variable does not exist, you ll get None instead. See .

This inability to sanely handle failures makes this binding quite dangerous to use in scripts. Imagine making important modifications on the basis of the returned values. If you forget to check against None, your script may cause havoc!

Snimpy Because I didn t find any reliable Python binding for SNMP, I decided to write Snimpy with two goals in mind:

1. Leverage information contained in MIBs to provide a pythonic interface.
2. Any error condition should raise an exception.

Here is how the previous script could be written:

#!/usr/bin/env snimpy
import argparse
parser = argparse.ArgumentParser()
parser.add_argument("host", default="localhost", nargs="?",
                    help="Agent to retrieve variables from")
parser.add_argument("community", default="public", nargs="?",
                    help="Community to query the agent")
options = parser.parse_args()
m = M(options.host, options.community, 2)
load("IF-MIB")
for idx in m.ifDescr:
    if m.ifDescr[idx] == "lo":
        continue
    if m.ifOperStatus[idx] != "up":
        continue
    print("     ".format(m.ifDescr[idx],
                            m.ifInOctets[idx],
                            m.ifOutOctets[idx]))

You can also use a list comprehension:

load("IF-MIB")
print("\n".join([ "     ".format(m.ifDescr[idx],
                                    m.ifInOctets[idx],
                                    m.ifOutOctets[idx])
                  for idx in m.ifDescr
                  if m.ifDescr[idx] != "lo"
                  and m.ifOperStatus[idx] == "up" ]))

Here is another simple example to get the routing database from the agent:

load("IP-FORWARD-MIB")
m=M("localhost", "public", 2)
routes = m.ipCidrRouteNextHop
for x in routes:
    net, netmask, tos, src = x
    print(" :>15s / :<15s  via  :<15s  src  :<15s ".format(
        net, netmask, routes[x], src))

IP-FORWARD-MIB::ipCidrRouteNextHop is a more complex table with a compound index. Despite this, querying the table still seems natural. Have a look at Snimpy s documentation for more information. Behind the hood, SNMP requests are handled by PySNMP and MIB parsing is done with libsmi². Snimpy supports both Python 2, Python 3 and Pypy.

---

1. A MIB is defined using a subset of ASN.1 called SMI. However, it is not uncommon to refer to the definition as a MIB too.
2. Unfortunately, there is currently no robust SMI parser written in pure Python. For example, PySNMP relies on smidump which comes with libsmi. Snimpy uses a custom CFFI wrapper around libsmi.

Recently I decided to set myself a big photography challenge. The three options which I discussed with a couple of people were:

• Photograph the front of every pub in the nearby area city-centre.
• Photograph ever plaque, monument, and statue in the city-centre.
• Photograph every gravestone and memorial bench in the city centre.

Ultimately I decided pubs would be most fun. Not least because you could do it every year or two, to see what changes occurred. To make it more useful I decided to not only take the pictures, but to collect, and share, the meta-data too:

• Lat/Longditude GPS for each pub.
• Contact details for each pub.
• etc.

Today I spent an hour walking up Easter road, and down Leith Walk. I shot the outside of about 20 pubs, and then fiddled with the layout and organization of the images. I'm reasonably happy with the result, but it remains obvious that I'm not a designer.

• http://edinburgh.io/

The data-set use to generate the site - which is perhaps the most interesting/useful part of the whole exercise to other people - is available online too:

• http://edinburgh.io/data

All the data, even the images, is stored on github for collaboration purposes. I'm not sure if folk will join in, but I can probably manage a few of the major thoroughfares every weekend indefinitely it will only take a couple of days to get "city-wide coverage", then the rest is gravy.

here's the list of RC bugs I've worked on during the last week.

• #713582 src:malaga: "malaga: FTBFS: ld: canvas.o: undefined reference to symbol 'ceil@@GLIBC_2.2.5'"
  add patches from Ubuntu / Matthias Klose, upload to DELAYED/2
• #713595 src:goocanvas: "goocanvas: FTBFS: ld: demo.o: undefined reference to symbol 'sincos@@GLIBC_2.2.5'"
  add patch from Ubuntu / Matthias Klose, upload to DELAYED/2
• #713635 src:osm-gps-map: "osm-gps-map: FTBFS: osm-gps-map-widget.c:778:21: error: format '%lld' expects argument of type 'long long int', but argument 4 has type 'goffset' [-Werror=format=]"
  add patch from upstream git, package FTBFS again later
• #713666 src:gnustep-base: "gnustep-base: FTBFS: GSXML.m:983:38: error: dereferencing pointer to incomplete type"
  add patch from Ubuntu / Benjamin Drung, upload to DELAYED/2
• #713700 src:gsnmp: "gsnmp: FTBFS: gsnmp.h:27:18: fatal error: gnet.h: No such file or directory"
  apply patch from Ubuntu / Daniel T Chen, upload to DELAYED/2
• #713701 src:libmatchbox: "libmatchbox: FTBFS: ld: dump-image.o: undefined reference to symbol 'XOpenDisplay'"
  add patches from Ubuntu / Daniel T Chen, upload to DELAYED/2
• #713708 src:gtkgl2: "gtkgl2: FTBFS: ld: zktor.o: undefined reference to symbol 'atan2@@GLIBC_2.2.5'"
  apply patch from Ubuntu / Daniel T Chen, upload to DELAYED/2
• #713727 src:xmlroff: "xmlroff: FTBFS: ld: ../libfo/.libs/libfo-0.6.a(fo-datatype.o): undefined reference to symbol 'floor@@GLIBC_2.2.5'"
  apply patch from Ubuntu / Daniel T Chen, upload to DELAYED/2
• #713728 src:matchbox-panel: "matchbox-panel: FTBFS: ld: mb-applet-menu-launcher.o: undefined reference to symbol 'XInternAtom'"
  update patch to link against more libs, upload to DELAYED/2
• #724080 src:libgraph-perl: "libgraph-perl: FTBFS: make: *** [clean] Error 1"
  fix clean target in debian/rules, upload to DELAYED/2, then moved to 0-day with maintainer's consent
• #724085 src:myspell: "myspell: FTBFS: POD errors"
  prepare a patch
• #724115 src:hunspell: "hunspell: FTBFS: POD error"
  prepare a patch
• #724142 src:xmltv: "xmltv: FTBFS: Tests failed"
  investigate error
• #724750 electrum: "electrum fails to launch from terminal"
  add missing dependency, upload to DELAYED/2
• #726801 biomaj: "biomaj: fails to install with Recommends enabled"
  tag unreproducible, later further analyzed as a java dependency problem by follow DD

(This is a reproduction of the mail sent to -announce for the planet readers) Aloha, hackers, As some of you notice from the slamn default background in wheezy, (BTW;
a round of applause for Adrien Aubourg for creating Joy!) we ask
for contributions to the debian-desktop team in the form of themeing. This is the official call for proposals for the Jessie cycle. Please
look on the wiki (thank you, Valessio Soares de Brito for creating
the page!) So, if you d like (or know someone who d like) to create a desktop look
and feel that will be seen by trillions of people, be sure to send in
your artwork ASAP! Breaking with tradition, I d like to have the re-themed desktop in place
well before freeze, to ensure we have time to properly integrate it. I m picking the arbitrary deadline of Feb 5th (subject to change) for
artwork to be submitted. I know this isn t a lot of time, but we can
iterate as we integrate. The artwork is usually picked based on which theme looks the most:
- Debian (I m not defining this since I think everyone has their own take
of what Debian means to them) - plausible to integrate without patching core software (As much as I love some of the insanely hot looking themes, some
would require heavy GTK+ theming and patching GDM/GNOME.) - clean / well designed (without becoming something that gets annoying to look at a
year down the road - I think Joy does a good job of this)
This year, do keep in mind the Debian logo *is* freely licensed, so feel
free to use it in your theme.

(or, cutting out bloat by using a platform where bloat won't fly)

Let me start off by saying I'm generally a huge fan of my bank, USAA. Their offerings are free of hidden fees, their phone support excellent, and the perks they provide are competitive. They don't have the best savings interest rates, but you can always find a better deal online to park money not actively in your checking account.

However, USAA's website is a behemoth. My account page took about 8 seconds to fully load, downloading 1.4MiB of content.

The "My Accounts" page you're redirected to after logging in.

It is frequently buggy; whenever I log in via Google Chrome on Ubuntu 12.04 I land on a page with a URL beginning with "https://www.usaa.com/inet/gas_bank/AccountBannerAjax" and a bunch of GET parameters like "currentaccountkey" and "accnumber" with values like "encrypted12a1f4dd1[ ]". The server returns a 200 OK, promises a Content-Length of 20, but then actually returns zero bytes. After navigating to the homepage and clicking a button, I end up getting logged in, but I wonder what percentage of their userbase are experiencing this problem?

Review: Fantasy & Science Fiction, July/August 2011

Editor:	Gordon van Gelder
Issue:	Volume 121, No. 1 & 2
ISSN:	1095-8258
Pages:	258

Nothing of particular interest in the book reviews in this issue, although I was entertained to see Charles de Lint review a collection of the Prince Valiant strip. I have memories of that strip being one of the most boring works of art created by mankind. De Lint, of course, quite likes it. Our tastes seem to be very disjoint, although I have to admit that I've not read it collected and it may be more coherent and more interesting in that format. The science column in this issue, by Paul Doherty and Pat Murphy, deserves special mention. It's on roshambo (rock-paper-scissors), human difficulties with randomness, and strategy in roshambo competitions. It's also the first essay I've read that clearly explains how there can be strategy to roshambo, and why that strategy is worth studying. Even though the primary topic of the column is randomness, it's worth reading from the perspective of strategy in competitive human vs. human games. "Bronsky's Dates with Death" by Peter David: Anyone familiar with PAD's body of work will immediately expect a humorous story with some deeper thoughtful bits, and that's exactly what this is. Bronsky, the title character, is a man almost incapable of saying exactly what's on his mind, and what's on his mind is his eventual death. Not that it bothers him that much; he's just thinking a lot about it. But his incessant discussion of it certainly bothers the people around him. This leads to a few entertaining exchanges with his family, and then to more entertaining exchanges with Death. Or Deaths, as there appear to be several different kinds. I found the exact metaphysics a bit confused, but the ending was still touching and a bit funny. (7) "The Way It Works Out and All" by Peter S. Beagle: This is a reprint of a special fund-raising story about Avram Davidson, so a lot of it was lost on me given that I know almost nothing about Davidson and have yet to get to any of his novels I own. But even without that background, it's a diverting story of hidden and parallel worlds and unexpected explorations. There isn't all that much in the way of a plot, but it's a nice bit of characterization set against a fun SF twist. (6) "Less Stately Mansions" by Rob Chilson: This is a story about conservatism in life, about a farmer staying on his farm and resisting change, and about nostalgia, but I liked it much better than I normally like stories with those themes. It's set against a future world in which climate change is making life increasingly untenable. Humans are migrating into space colonies of various types, but Jacob refuses. This frustrates some parts of the family who want a piece of the substantial cash-out he's being offered for his farm, which of course makes Jacob even more stubborn. It's more of an elegy than a story, but I think it captures a particular stubborn mood, and a conscious decision to go with what one knows even if it doesn't have a long future, quite well. (7) "The Ants of Flanders" by Robert Reed: This is the novella of the issue, and, as you might expect from the author, it's thoughtful, meaty, and satisfying. At the start of the book, the planet is visited by an extraterrestrial ship (or ships it's not entirely clear at first). One of the people near one landing is Bloch, a huge teenager who has an odd lack of natural fear. He stays near the center of the story as Reed slowly develops a cosmology and a galactic political background that makes it clear humans may be incidental to everything that's happening. I liked this. It's a touch depressing in spots, and Bloch is a strange protagonist, but the cosmology is not the normal SF background and sparks some thoughts about how a status quo would be maintained by powers that don't care much about individual lives. The interlude with the leopard is nicely done, even if its significance is inobvious at first. (7) "Hair" by Joan Aiken: This is one of those weird Gothic horror stories about creepy families and half-explained supernatural events that some people love and that do nothing for me. (3) "The Witch of Corinth" by Steven Saylor: This is straight historical fantasy, featuring a Roman and his Greek tutor (heroes, apparently, of a series of historical mysteries) visiting the ruins of Corinth and encountering some bloody and dangerous local conflicts. It's slow and atmospheric, carried along by good characterization and description of ruins. It's not that much of a mystery the characters don't figure things out as much as stick around until the answer becomes obvious but it kept me entertained throughout a sizable story. Numerous elements of the story appear to be fantasy and then get other explanations, but there is a fantasy twist to the ending. (6) "Sir Morgravain Speaks of Night Dragons and Other Things" by Richard Bowes: This odd story is set among the knights of King Arthur on Avalon, where they sleep (mostly), awaiting their call to aid Britain again. Most of the story is told as one-sided dialogue from Morgravain, interspersed with some italic narration. Again, not much of a plot; the story, as such, is figuring out what Morgravain is doing and the point of his interactions with the other knights. I thought it was slight and oddly pointless, but I may have just missed the point. (4) "Someone Like You" by Michael Alexander: A time travel story, but one that's less about time travel per se than about examining and speculating about the alternate paths childhood could take and whether those changes produce different people. It takes some time to figure out what's going on, during which Alexander fills in the protagonist's past and the murder mystery that drives the tale. The time travel mechanism is blatantly hand-waved, making this more of a fantasy than an SF story, which matches the emphasis on emotion and psychology. It's not a bad story, and I think I see where the author was going with the slowly-constructed central conflict, but I still found it hard to take the conflict that seriously. One of the problems with time travel is that undermining of causality also undermines finality of decisions and consequences in ways that can rob stories of their punch. (6) "The Ramshead Algorithm" by KJ Kabza: The first-person protagonist is a well-respected and experienced fixer in a world of chaos and dimensional connection, a world with physics and inhabitants very much unlike ours. But the story doesn't spend much time there; his connection to his home earth is threatened, and he returns to try to stabilize it, which leads to the reader discovering that his family considers him a worthless appendage on a wealthy business family whose sole purpose in life is to stay out of their way. And his portal is rooted in a hedge maze that his father intends to demolish. This is one of those stories that gets more interestingly complex the deeper one gets into it. Ramshead's family is badly screwed up along multiple axes, but not without some hope of redemption. He's desperate and ineffective in his home universe, but more confident and capable when it comes to dealing with dimensional portal problems (although he still seems very young and relies on tools given to him by others). And there's always more going on than it first appears, and not as few obvious villains as it first appears. Good stuff, although I would have liked to understand more about Ramshead's world. (7) Rating: 7 out of 10

You keep using that word. I do not think it means what you think it means. -Inigo Montoya

Having worked in full-time management positions for some years now, I am increasingly convinced that management is widely misunderstood as a role, as a discipline and as a field, and that this makes a lot of lives more difficult and stressful than necessary. It is the subject of much speculation and misbelief, and I ve chosen a few of my favorite examples to deconstruct here. Misbelief #1: management is what managers do I ve noticed a trend among a certain class of companies, whose employees will tell anyone who will listen that there is no management in their organization, they never plan to have any, and neither should you. I think these statements are respectively a lie, a na ve belief, and a piece of bad advice. Usually, these companies are just a few years old and relatively small, most of the people in the company have been there for less than a year, and the speaker is trying to persuade us what a unique and innovative company they work for because nobody there is a manager . They invariably have not read The Tyranny of Structurelessness. Management is the practice of enabling people to effectively cooperate. A manager is someone whose job is to do that. It s that simple. It usually involves tasks such as sharing information, agreeing on a course of action, dividing up work, and figuring out what to do when there s a problem. They re things that every team needs to do, whether anyone is designated a manager or not. Teams can function without managers, but they can t function properly without management. Someone (or everyone) has to do the work to make cooperation possible. Modern management is a specialized discipline, which draws on a broad range of skills in communication, psychology, empathy, problem-solving, leadership, and more. These skills aren t unique to managers, but it often makes sense to designate certain people to do more of the management work, on behalf of the team. By devoting more of their time and attention to it, they free other members of the team to focus on other tasks. They can act as a coordinator to help the team stay in sync, and by focusing on this job, they may be able to do a better job of it, and acquire a higher level of skill through practice and study. But it remains an inherently collaborative practice. Misbelief #2: management is about telling people what to do There are many different varieties of management, each of which is oriented toward a particular type of team or organization. Factories are managed differently from design studios, large companies are managed differently from small companies, and every team has its own distinct management style which arises from the unique group of people involved. Some managers are specialists in a particular type of management, while others are more generalists. The telling people what to do style of management is called command and control . It s characterized by authority, hierarchy, and strict adherence to protocol. It s widely employed by military organizations, and by the managers we see in television and film. It has some advantages and disadvantages, which I won t discuss here. My point is that it is just one example, but this example is used to represent the general concept of management. Self-organization, where no one in particular is responsible for group decisions, is another, quite different, style of management. Small, self-organizing teams are capable of amazing feats of productivity. They re less difficult to manage because they re comparatively simple, and so simple tools and techniques work well. Everyone can be fully aware of what everyone else is doing, and new information propagates quickly throughout the team. But as the team or organization grows, it will often outgrow this way of working, and needs to adapt. There is no single management approach which works universally well. Misbelief #3: management is a promotion You know the story. When an employee is successful within their area of expertise, someone will eventually offer them a management role as a reward for their good work. This is utter nonsense. Management is not a promotion: it s a career change. It means starting over as a beginner in a new discipline and learning from the ground up. Domain expertise is important, as a manager needs to understand the work of the other people on their team, but it is no longer paramount. The team, the human system, becomes their focus. When organizations fail to provide career advancement within a discipline, people may turn to management as the only way to get promoted , only to discover that they are completely unprepared for this new field, and often their new job when they realize what they ve gotten into. If someone were promoted from a position as a financial analyst to a new job as a biochemist with no training or expertise, we would probably find this bizarre. But this is analogous to what happens to new managers all the time, and has become almost standard practice in many organizations and industries. So what? Management is misunderstood. So are science, engineering, and many other fields. What does it matter?

People leave managers not companies in the end, turnover is mostly a manager issue, - Marcus Buckingham & Curt Coffman, First, Break All the Rules

This mythology leads to massive organizational dysfunction, making it harder for everyone to do their jobs. It virtually guarantees incompetent management, which is a scourge on anyone who is exposed to it. It ruins days, weeks, jobs and careers. It leads talented people to leave companies, and it drives them out of their chosen professions. I recommend that we stop denigrating and ignoring management, and start doing a better job of it.

Review: Muse of Fire, by John Scalzi

Publisher:	Subterranean
Copyright:	2012
Printing:	2013
ISBN:	1-59606-639-3
Format:	Kindle
Pages:	28

This is another separately-published short work by Scalzi probably a novelette, although I didn't do a word count. Since it's separately published and has its own ISBN, it gets its own separate review page. At present, it's $1 on the Kindle (and probably elsewhere). I've read a variety of these now, and while the quality of Scalzi's short works varies (as with everyone), I've generally enjoyed them. This is the first one I've read that I really didn't like. The premise is promising enough. Ben Patton is a scientist or engineer of some sort (I don't recall if the story is specific) working on plasma physics for a corporation. He has a nervous tic involving playing with a lighter and an obsession with fire, which his co-workers tolerate (and his boss does not tolerate). The reason for that tic is something he keeps secret: he sees a beautiful woman named Hestia in any flames that he's looking at. For him, she's his muse, and his untouchable obsession. He's mangled one hand trying to touch her. But she appears in fire because she's trapped in hell. There are all sorts of great places Scalzi could have gone with this. Musae and inspiration by themselves are fodder for many stories. The woman's name is Hestia, which is immediately recognizable as the Greek goddess of the hearth and who is extremely important to Greek religious life (although she's definitely not a muse, but I'd even let that pass). That raises more story possibilities around the transition of religion and the effect on worshiped gods, including the way Christian missionaries called "pagan" gods and goddesses devils and indeed did claim they were from hell. There are interesting science and magic crossover possibilities between plasma physics and a muse of fire. And there is, of course, the whole rescue from hell angle, which has generated many a story going back to ancient Greek drama. As you might have guessed from this catalog and my disappointment, Scalzi didn't go any of those directions. He provides some good characterization of the passions and discomfort of Ben's life, shows us the practicalities of his relationship with Hestia, and sets up dramatic tension, all well and good. And then takes the most obvious, least interesting, and least satisfying twist possible. I was getting nervous as I got closer and closer to the end of the story and Scalzi had yet to develop any of the interesting possible directions, but even then I didn't expect the train wreck ending. Even a simplistic "happily ever after" ending would have been preferable. He did catch me by surprise, but only because I wouldn't have expected any author to take that easy of a way out of the story. I can't build up a proper rant while avoiding spoilers, but I will say that Scalzi even manages to walk straight into a rather nasty stereotype in the process. I'm not sure what happened here, but it didn't work, and it's far below the normal standards of Scalzi's work. Such a shame, too, since the setting had so much potential. Avoid. Rating: 4 out of 10

The following post is a verbatim copy of my message to the debian-devel list. While botch produces loads of valuable data to help maintainers modifying the right source packages with build profiles and thus make Debian bootstrappable, it has so far failed at producing this data in a format which is:

• human readable (nobody wants to manually go through 12 MB of JSON data)
• generated automatically periodically and published somewhere (nobody wants to run botch on his own machine or update periodically update the TODO wiki page)
• available on a per-source-package-basis (no maintainer wants to know about the 500 source packages he does NOT maintain)

While human readability is probably still lacking (it's hard to write in a manner understandable by everybody about a complicated topic you are very familiar with), the bootstrapping results are now generated automatically (on a daily basis) and published in a per-source-package-basis as well. Thus let me introduce to you: bootstrap.debian.net Paul Wise encouraged me to set this up and also donated the debian.net CNAME to my server. Thanks a lot! The data is generated daily from the midnight packages/sources records of snapshot.debian.org (I hope it's okay to grab the data from there on a daily basis). The resulting data can be viewed in HTML format (with some javascript for to allow table sorting and paging in case you use javascript) per architecture (here for amd64). In addition it also produces HTML pages per source package for all source packages which are involved in a dependency cycle in any architecture (for example src:avahi or src:python2.7). Currently there are 518 source packages involved in a dependency cycle. While this number seems high, remember that estimations by calculating a feedback arc set suggest that only 50-60 of these source packages have to be modified with build profiles to make the whole graph acyclic. For now it is funny to see that the main architectures do not bootstrap (since July, for different reasons) while less popular ones like ia64 and s390x bootstrap right now without problems (at least in theory). According to the logs (also accessible at above link, here for amd64) this is because gcc-4.6 currently fails compiling due to a build-conflict (this has been reported in bug#724865). Once this bug is fixed, all arches should be bootstrappable again. Let me remind you here that the whole analysis is done on the dependency relationships only (not a single source package is actually compiled at any point) and compilation might fail for many other reasons in practice. It has been the idea of Paul Wise to integrate this data into the pts so that maintainers of affected source packages can react to the heuristics suggested by botch. For this purpose, the website also publishes the raw JSON data from which the HTML pages are generated (here for amd64). The bugreport against the bts can be found in bug#728298. I'm sure that a couple of things regarding understandability of the results are not yet sufficiently explained or outright missing. If you see any such instance, please drop me a mail, suggesting what to change in the textual description or presentation of the results. I also created the following two wiki pages to give an overview of the utilized terminology:

• Explaining basic terminology
• Explaining used heuristics

Feel also free to tell me if anything in these pages is unclear. Direct patches against the python code producing the HTML from the raw JSON data are also always welcome.

Review: Asimov's Science Fiction, August 2011

Editor:	Sheila Williams
Issue:	Volume 35, No. 8
ISSN:	1065-2698
Pages:	112

The editorial this issue is about the Dell Magazines Award, so newsy without a lot of content (particularly since we don't get to read the winners). Silverberg's column is much more interesting, focusing on the complex rules of the honor code of the Albanian highlands and pointing out that there's more complexity and strangeness in things we can find on Earth than in a lot of science fiction. Even within the rules of real human cultures. James Patrick Kelly's column this issue is an interesting summary of what graduates of the Clarion writing workshop learned, in their own words. It's a nice barrage of quick writing tips, and an interesting view of what people take away from a writing workshop. The book review column this issue is Peter Heck's normal workman-like job. "The End of the Line" by Robert Silverberg: Someday, I really should read Lord Valentine's Castle. As you might guess from this comment, this is another Majipoor story. This one follows an official who is part of an advance party for the Coronal Lord, the ruler (of sorts). He's decided, as part of those duties, to take the opportunity to learn more about the aboriginal people of Majipoor: the somewhat mysterious metamorphs, or Piurivar. I'm not that familiar with the history of Majipoor, since all I've read is this story and one other, none of the novels. Apparently, knowing that the official in question is named Stiamot will place this story for more familiar readers. For the unfamiliar, such as myself, there's a lot of politics here and what's clearly background for a major event in the world, but as a standalone story it's a bit unsatisfying (and grim). It's not that clear why things had to turn out the way they did, and the characters seem largely without agency. It's well-written, but mostly a story for fans of the series, I think. (6) "Corn Teeth" by Melanie Tem: This is a tight third-person story about a human child raised by alien foster parents, and it's deeply disturbing. Not because of the fostering, which appears wonderful and loving, but because it's a train wreck sort of story: the reader can see the horrible coming and can't do anything about it (and it turns out even worse than one might expect). It's also a story built around failure of communication and failure of empathy, and has a monumentally depressing ending, the kind that leaves scars. I'm sure all of this is entirely intentional; it seems very well-written. But I really didn't want this much horrible misunderstanding and depressing hopelessness in my reading. (2) "Watch Bees" by Philip Brewer: I rather liked this story even if the protagonist is an awful person. The story is set in a future of bioengineered insects and hard economic times, and it features a man who is supposedly working his way from farm to farm to get back home. What he's actually after is more complicated and is closely related to the defense systems that keep intruders off of farms. You might guess some of the rest from the title. It's a story about understanding layered defense systems, and about economic warfare. I didn't care much for any of the characters, but the story is well-plotted and kept me interested in seeing what would happen next. (6) "For I Have Lain Me Down on the Stones of Loneliness and I'll Not Be Back Again" by Michael Swanwick: By Swanwick, so it's a little odd, but I found this story surprisingly moving and ambiguous. It's about an American of Irish descent, a trip to Ireland, and a love affair with a fierce Irish nationalist, all set against an SF background of an Earth conquered by benevolent aliens. It's angry, uncertain, fanatical, and realistic by turns, and left me with profound mixed feelings. I think it does a good job capturing in a brief story the emotional complexities of what it means to give onself to a cause. (7) "We Were Wonder Scouts" by Will Ludwigsen: This is a short and odd story about a variant of the Boy Scouts founded by a man who is a little too obsessed with the paranormal, and an outing in the woods that turns rather creepy. It's a type of story that I'm not very fond of: one that twists the delight of discovery into something dark and mundane. I suppose you could call it horror; it's more horror than fantasy, at least. Anyway, not my thing. (3) "Pairs" by Zachary Jernigan: This story, on the other hand, isn't as dark as it seems like it should be from the setup. Humans have been conquered and enslaved by more powerful alien races, and now human souls are a profitable business. The protagonist is a person who has been embodied in a spaceship, and who works with (and monitors) another largely insane embodied person as they work as couriers, carrying souls to their buyers. But neither of them are as fully under control as they might appear, which is the point of the story. There is no grand tale of redemption, and the price is high, but I found the psychological portrayal oddly satisfying and faintly hopeful, and I was intrigued by the world background. (7) "Paradise is a Walled Garden" by Lisa Goldstein: The cover story, this is by far the best story of the issue. It's steampunk, set in a world where Muslim civilization was not pressed back by Christianity and continues to thrive into the reign of Queen Elizabeth as, among other things, makers of automata. A girl has managed to get herself a job in a British factory by posing as a boy and is the first to sound the alarm when the automata that do most of the work go strangely (and violently) haywire. That leads to her being assigned to the subsequent delegation to Al-Andulus (Muslim Spain, if you're not familiar with that name from history). The protagonist is the best part of this story. She's thoughtful, resourceful, and delights in learning things, something that she's rarely had the opportunity to do. She's also utterly unintimidated. In Al-Andulus, she thrives, despite the contempt of the leader of the expedition and some dangerous intrigues around the source of the anomalous behavior. I won't spoil the ending, but it's a delight, leaving the reader with a lot of hope for her future. I also liked the portrayal of the Muslim world, which is engrossed in its own business and has its own advantages and disadvantages, but is at least open to and focused on learning and technological development. The contrast with the superstitious British delegation is both pointed and historically grounded in Muslim relations with Europe around the point of divergence of Goldstein's world. (8) Rating: 7 out of 10