Eagle's Path

Passion and dispassion. Choose two.

Larry Wall

2018-02-11: February Haul

Most of this is the current StoryBundle: Black Narratives, in honor of Black History Month in the United States. But there's also a random selection of other things that I couldn't resist.

(I'm still reading this year too! Just a touch behind on reviews at the moment.)

Alicia Wright Brewster — Echo (sff)
T. Thorne Coyle — To Raise a Clenched Fist to the Sky (sff)
T. Thorne Coyle — To Wrest Our Bodies from the Fire (sff)
Julie E. Czerneda — Riders of the Storm (sff)
Julie E. Czerneda — Rift in the Sky (sff)
Terah Edun — Blades of Magic (sff)
Terah Edun — Blades of Illusion (sff)
L.L. Farmer — Black Borne (sff)
Jim C. Hines — Goblin Quest (sff)
Jim C. Hines — The Stepsister Scheme (sff)
Nalo Hopkinson — The Salt Roads (sff)
S.L. Huang — Root of Unity (sff)
Ursula K. Le Guin — Steering the Craft (nonfiction)
Nnedi Okorafor — Kabu-Kabu (sff collection)
Karen Lord — Redemption in Indigo (sff)
L. Penelope — Angelborn (sff)
Elizabeth Wein — The Pearl Thief (mainstream)

I'm slowly reading through the Czerneda that I missed, since I liked the Species Imperative series so much. Most of it isn't that good, and Czerneda has a few predictable themes, but it's fun and entertaining.

The Wein is a prequel to Code Name Verity, so, uh, yes please.

2018-02-11: pgpcontrol 2.6

This is the legacy bundle of Usenet control message signing and verification tools, distributed primarily via ftp.isc.org (which hasn't updated yet as I write this). You can see the files for the current release at archives.eyrie.org.

This release adds support for using gpg for signature verification, provided by Thomas Hochstein, since gpgv may no longer support insecure digest algorithms.

Honestly, all the Perl Usenet control message code I maintain is a mess and needs some serious investment in effort, along with a major migration for the Big Eight signing key (and probably the signing key for various other archives). A lot of this stuff hasn't changed substantially in something like 20 years now, still supports software that no one has used in eons (like the PGP 2.6.3i release), doesn't use modern coding idioms, doesn't have a working test suite any longer, and is full of duplicate code to mess about with temporary files to generate signatures.

The formal protocol specification is also a pretty old and scanty description from the original project, and really should be a proper RFC.

I keep wanting to work on this, and keep not clearing the time to start properly and do a decent job of it, since it's a relatively large effort. But this could all be so much better, and I could then unify about four different software distributions I currently maintain, or at least layer them properly, and have something that would have a modern test suite and could be packaged properly. And then I could start a migration for the Big Eight signing key, which has been needed for quite some time.

Not sure when I'm going to do this, though, since it's several days of work to really get started. Maybe my next vacation?

(Alternately, I could just switch everything over to Julien's Python code. But I have a bunch of software already written in Perl of which the control message processing is just a component, so it would be easier to have a good Perl implementation.)

2018-02-04: Debian packaging with Git notes

I finally found the time today to update my notes on how I package for Debian using Git. They're rather long (even after dropping my beginner Git tutorial, which seemed pointless given how many good ones there are now), so I'm not including the full text here. Take a look if you're curious.

The major differences from the previous version (last revised in 2012, and originally written in 2008) are:

On my current development machine, I'm experimenting with using btrfs as the root file system, including using sbuild instead of pbuilder to build packages since it can use btrfs snapshots. So far, I'm extremely happy with that configuration. It was hard to find good documentation for the process, so I wrote up how I configure sbuild with btrfs in case it's of interest to anyone else. It's noticably faster than using pbuilder, and once I got used to it I think it feels a bit cleaner.

2018-02-04: Free software log (January 2018)

The only sofware releases I got out this month were both for work: versions 0.4.0 and 0.4.1 of groupy, the client library for Merou, the authorization management system we use. We're not doing formal releases of the latter yet, just building from Git, and probably need to settle on a final public project name before we do.

At some point I'll build proper software release pages for both of these, since I seem to be doing most of the release management for groupy.

The 0.4.0 release was in support of the new service account model. The 0.4.1 release was an attempt to reduce the number of Python modules that had to be installed to configure the build, since too much setup_requires was causing various issues and version conflicts in our internal build system. Python has a slightly odd (at least to me) way of allowing modules to inject more commands into setup.py that are only useful in specific situations, and it's hard to find the right place in the dependency metadata to put those modules. I'm still not totally happy with the compromise we arrived at.

I also did a bit of work on control-archive, but didn't finish making a new release. I think the only thing left is to rewrite the documentation to use DocKnot. Hopefully this month.

On the INN front, I tracked down a few test failures and fixed them upstream in rra-c-util, and also expanded the documentation links for INN on my web site.

Finally, I uploaded new versions of a couple of Debian packages: libnews-article-perl (just a packaging refresh), and libnet-duo-perl (now donated to the Perl packaging team). I may end up orphaning Net::Duo, since I'm not currently actively using it, although I'm still hanging on to it since I'm considering using it for some personal stuff.

Overall, I would have liked to get a few more full software releases out, but I'm pretty happy for this month for a January, a return-to-work month, and a month during which I was on-call for a week. Definitely better than the months of "I didn't do much" towards the end of last year!

2018-01-30: Review: My Grandmother Asked Me to Tell You She's Sorry

Review: My Grandmother Asked Me to Tell You She's Sorry, by Fredrik Backman

Series Britt-Marie #1
Translator Henning Koch
Publisher Washington Square
Copyright 2014
Printing April 2016
ISBN 1-5011-1507-3
Format Trade paperback
Pages 372

Elsa is seven, going on eight. She's not very good at it; she knows she's different and annoying, which is why she gets chased and bullied constantly at school and why her only friend is her grandmother. But Granny is a superhero, who's also very bad at being old. Her superpowers are lifesaving and driving people nuts. She made a career of being a doctor in crisis zones; now she makes a second career of, well, this sort of thing:

Or that time she made a snowman in Britt-Marie and Kent's garden right under their balcony and dressed it up in grown-up clothes so it looked as if a person had fallen from the roof. Or that time those prim men wearing spectacles started ringing all the doorbells and wanted to talk about God and Jesus and heaven, and Granny stood on her balcony with her dressing gown flapping open, shooting at them with her paintball gun

The other thing Granny is good at is telling fairy tales. She's been telling Elsa fairy tales since she was small and her mom and dad had just gotten divorced and Elsa was having trouble sleeping. The fairy tales are all about Miamas and the other kingdoms of the Land-of-Almost-Awake, where the fearsome War-Without-End was fought against the shadows. Miamas is the land from which all fairy tales come, and Granny has endless stories from there, featuring princesses and knights, sorrows and victories, and kingdoms like Miploris where all the sorrows are stored.

Granny and Miamas and the Land-of-Almost-Awake make Elsa's life not too bad, even though she has no other friends and she's chased at school. But then Granny dies, right after giving Elsa one final quest, her greatest quest. It starts with a letter and a key, addressed to the Monster who lives downstairs. (Elsa calls him that because he's a huge man who only seems to come out at night.) And Granny's words:

"Promise you won't hate me when you find out who I've been. And promise me you'll protect the castle. Protect your friends."

My Grandmother Asked Me to Tell You She's Sorry is written in third person, but it's close third person focused on Elsa and her perspective on the world. She's a precocious seven-year-old who I thought was nearly perfect (rare praise for me for children in books), which probably means some folks will think she's a little too precocious. But she has a wonderful voice, a combination of creative imagination, thoughtfulness, and good taste in literature (particularly Harry Potter and Marvel Comics). The book is all about what it's like to be seven, going on eight, with a complicated family situation and an awful time at school, but enough strong emotional support from her family that she's still full of stubbornness, curiosity, and fire.

Her grandmother's quest gets her to meet the other residents of the apartment building she lives in, turning them into more than the backdrop of her life. That, in turn, adds new depth to the fairy tales her Granny told her. Their events turn out to not be pure fabrication. They were about people, the many people in her Granny's life, reshaped by Granny's wild imagination and seen through the lens of a child. They leave Elsa surprisingly well-equipped to navigate and start to untangle the complicated relationships surrounding her.

This is where Backman pulls off the triumph of this book. Elsa's discoveries that her childhood fairy tales are about the people around her, people with a long history with her grandmother, could have been disillusioning. This could be the story of magic fading into reality and thereby losing its luster. And at first Elsa is quite angry that other people have this deep connection to things she thought were hers, shared with her favorite person. But Backman perfectly walks that line, letting Elsa keep her imaginative view of the world while intelligently mapping her new discoveries onto it. The Miamas framework withstands serious weight in this story because Elsa is flexible, thoughtful, and knows how to hold on to the pieces of her story that carry deeper truth. She sees the people around her more clearly than anyone else because she has a deep grasp of her grandmother's highly perceptive, if chaotic, wisdom, baked into all the stories she grew up with.

This book starts out extremely funny, turns heartwarming and touching, and develops real suspense by the end. It starts out as Elsa nearly alone against the world and ends with a complicated matrix of friends and family, some of whom were always supporting each other beneath Elsa's notice and some of whom are re-learning the knack. It's a beautiful story, and for the second half of the book I could barely put it down.

I am, as a side note, once again struck by the subtle difference in stories from cultures with a functional safety net. I caught my American brain puzzling through ways that some of the people in this book could still be alive and living in this apartment building since they don't seem capable of holding down jobs, before realizing this story is not set in a brutal Hobbesian jungle of all against all like the United States. The existence of this safety net plays no significant role in this book apart from putting a floor under how far people can fall, and yet it makes all the difference in the world and in some ways makes Backman's plot possible. Perhaps publishers should market Swedish literary novels as utopian science fiction in the US.

This is great stuff. The back and forth between fairy tales and Elsa's resilient and slightly sarcastic life can take a bit to get used to, but stick with it. All the details of the fairy tales matter, and are tied back together wonderfully by the end of the book. Highly recommended. In its own way, this is fully as good as A Man Called Ove.

There is a subsequent book, Britt-Marie Was Here, that follows one of the supporting characters of this novel, but My Grandmother Asked Me to Tell You She's Sorry stands alone and reaches a very satisfying conclusion (including for that character).

Rating: 10 out of 10

2018-01-29: Review: Reap the Wild Wind

Review: Reap the Wild Wind, by Julie E. Czerneda

Series Stratification #1
Publisher DAW
Copyright 2007
Printing September 2008
ISBN 0-7564-0487-8
Format Mass market
Pages 459

Reap the Wild Wind is the first book in the Stratification series. This is set in the same universe as the Trade Pact series (which starts with A Thousand Words for Stranger), but goes back in time, telling the story of the Om'ray before they left Cersi to become the Clan. You may have more interest in this series if you read and enjoyed the Trade Pact trilogy, but it's not a prerequisite. It's been over ten years since I read that series, I've forgotten nearly everything about it except the weird gender roles, and I didn't have any trouble following the story.

Aryl Sarc is member of the Yena Clan, who live a precarious existence in the trees above a vast swamp filled with swarms of carnivorous creatures. They are one of several isolated clans of Om'ray on the planet Cersi. Everything about the clans is tightly constrained by an agreement between the Om'ray, the Tiktik, and the Oud to maintain a wary peace. The agreement calls for nothing about the nature of the world or its three species to ever change.

Reap the Wild Wind opens with the annual dresel harvest: every fall, a great, dry wind called the M'hir flows down the mountains and across the forest in which the Yena live, blowing free the ripe dresel for collection at the treetops. Dresel is so deeply a part of Aryl's world that the book never explains it, but the reader can intuit that it contains some essential nutrient without which all the Yena would die. But disaster strikes while Aryl is watching the dresel harvest, disaster in the form of a strange flying vehicle no one has seen before and an explosion that kills many of the Yena and ruins the harvest essential to life.

The early part of the book is the emotional and political fallout of this disaster. Aryl discovers an unknown new talent, saving the man she's in love with (although they're too young to psychically join in the way of the Om'ray) at the cost of her brother. There's a lot of angst, a lot of cliched descriptions of internal psychic chaos (the M'hir that will be familiar to readers of the Trade Pact books), and a lot of her mother being nasty and abusive in ways that Aryl doesn't recognize as abuse. I struggled to get into the story; Aryl was an aimless mess, and none of the other characters were appealing. The saving grace for me in the early going were the interludes with Enris, an Om'ray from a far different clan, a metalworker whose primary dealings are with the Oud instead of the Tiktik.

This stage of the story thankfully doesn't last. Aryl eventually ends up among the Tiktik, struggling to understand their far different perspective on the world, and then meets the visitors who caused the disaster. They're not only from outside of Aryl's limited experience; they shouldn't even exist by the rules of Aryl's world. As Aryl slowly tries to understand what they're doing, the scope of the story expands, with hints that Aryl's world is far more complicated than she realized.

Czerneda sticks with a tight viewpoint focus on Aryl and Enris. That's frustrating when Aryl is uninterested in, or cannot understand, key pieces of the larger picture that the reader wants to know. But it creates a sense of slow discovery from an alien viewpoint that occasionally reminded me of Rosemary Kirstein's Steerswoman series. Steerswoman is much better, but it's much better than almost everything, and Aryl's growing understanding of her world is still fun. I particularly liked how Aryl's psychic species defines the world by the sensed locations of the Om'ray clans, making it extremely hard for her to understand geography in the traditional sense.

I was also happy to see Czerneda undermine the strict sexual dimorphism of Clan society a tiny bit with an Om'ray who doesn't want to participate in the pair-bonding of Choosing. She painted herself into a corner with the extreme gender roles in the Trade Pact series and there's still a lot of that here, but at least a few questions raised about that structure.

Reap the Wild Wind is all setup with little payoff. By the end of the book, we still just have hints of the history of Cersi, the goals of the Oud or Tiktik, or the true shape of what the visitors are investigating. But it had grabbed my interest, mostly because of Aryl's consistent, thoughtful curiosity. I wish this first book had gotten into the interesting meat of the story faster and had gotten farther, but this is good enough that I'll probably keep reading.

Followed by Riders of the Storm.

Rating: 7 out of 10

2018-01-28: Review: Roads and Bridges

Review: Roads and Bridges, by Nadia Eghbal

Publisher Ford Foundation
Copyright July 2016
Format Epub
Pages 143

Subtitled The Unseen Labor Behind Our Digital Infrastructure, Roads and Bridges isn't a book. It's a long report for the Ford Foundation, available for free from their web site. But I read it like a book, so you get a review anyway.

If, like me, you've spent years in the free software community, you'll know much of this already. Eghbal starts with a survey of the history of free software and open source (skewed towards the practical and economic open source analysis, and essentially silent on ethics), and then a survey of how projects are currently organized. The emphasis, consistent with the rest of the report, is on how these free software building blocks underlie nearly all the consumer software and services used today. Eghbal singles out OpenSSL as her example of lack of infrastructure support due to Heartbleed and the subsequent discussion of how vital OpenSSL is but how little funding it received.

Eghbal hit her stride for me at the end of the third section, which tries to understand why people contribute to open source without being paid. I'm a bit dubious that many people contribute to build their personal reputation, since that's not a commonly stated reason in my areas of the free software community, but Eghbal's analysis of the risk of this motive from the infrastructure perspective seemed on point if this is becoming common. Better was her second motive: "the project became unexpectedly popular, and the maintainer feels obligated to support it." Yes. There is so much of this in free software, and it's a real threat to the sustainability of projects because it's a description of the trajectory of burnout. It's also a place where a volunteer culture and the unfairness of unpaid labor come into uncomfortable tension. Eghbal very correctly portrays her third reason, "a labor of love," as not that obviously distinct from that feeling of obligation.

The following discussion of challenges rightfully focuses on the projects that are larger than a weekend hobby but smaller than Linux:

However, many projects are trapped somewhere in the middle: large enough to require significant maintenance, but not quite so large that corporations are clamoring to offer support. These are the stories that go unnoticed and untold. From both sides, these maintainers are told they are the problem: Small project maintainers think mid-sized maintainers should just learn to cope, and large project maintainers think if the project were "good enough," institutional support would have already come to them.

Eghbal includes a thoughtful analysis of the problems posed by the vast increase in the number of programmers and the new economic focus on software development. This should be a good thing for free software, and in some ways it is, but the nature of software and human psychology tends towards fragmentation. It's more fun to write a new thing than do hard maintenance work on an old code base. The money is also almost entirely in building new things while spending as little time as possible on existing components. Industry perception is that open source accelerates new business models by allowing someone to build their new work on top of a solid foundation, but this use is mostly parasitic in practice, and the solid foundation doesn't stay solid if no one contributes to it.

Eghbal closes with a survey of current funding models for open source software, from corporate sponsorship to crowdfunding to foundations, and some tentative suggestions for principles of successful funding. This is primarily a problem report, though; don't expect much in the way of solutions. Putting together an effective funding model is difficult, community-specific, and requires thoughtful understanding of what resources are most needed and who can answer that need. It's also socially fraught. A lot of people work on these projects because they're not part of the capitalist system of money-seeking, and don't want to deal with the conflicts and overhead that funding brings.

I was hoping Eghbal would propose more solutions than she did, but I'm not surprised. I've been through several of these funding conversations in various communities. The problem is very hard, on both economic and social levels. But despite the lack of solutions, the whole report was more interesting than I was expecting given how familiar I already am with this problem. Eghbal's background is in venture capital, so she looks at infrastructure primarily through the company-building lens, but she's not blind to the infrastructure gaps those companies leave behind or even make worse. It's a different and clarifying angle on the problem than mine.

I realized, reading this, that while I think of myself as working on infrastructure, nearly all of my contributions have been in the small project. Only INN (back in the heyday of Usenet), OpenAFS (which I'm no longer involved in), and Debian rise to the level of significant infrastructure projects that might benefit from funding. Debian is large enough that, while it has resource challenges, it's partly transitioned into the lower echelons of institutional support. And INN is back in weekend project territory, since Usenet isn't what it was.

This report made me want to get involved in some more significant infrastructure project in need of this kind of support, but simultaneously made it clear how difficult it is to do this on a hobby basis. And it's remarkably hard to find corporate sponsorship for this sort of work that doesn't involve so much complexity and uncertainty that it's hard to justify leaving a stable and well-understood job. Which, of course, is much of Eghbal's point.

Eghbal also surfaces the significant tension between the volunteer, interest-based allocation of resources native to free software, and the money-based allocation of resources of a surrounding capitalist society. Projects are usually the healthiest and the happiest when they function as volunteer communities: they spontaneously develop governance structures that work for people as volunteers, they tend towards governance where investment of effort translates into influence (not without its problems, but generally better than other models), and each contributor has a volunteer's freedom to stop doing things they aren't enjoying (although one shouldn't underestimate the obligation factor of working on a project used by other people). But since nearly everyone has to spend the majority of their time on paying work, it's very difficult to find sustained and significant resources for volunteer projects. You need funding, so that people can be paid, but once people are paid they're no longer volunteers, and that fundamentally alters the social structure of the project. Those changes are rarely for the better, since the motives of those paying are both external to the project (not part of the collaborative decision-making process) and potentially overriding given how vital they are to the project.

It's a hard problem. I avoided it for years by living in the academic world, which is much better at reconciling these elements than for-profit companies, but the academic world doesn't have enough total resources, or the right incentives, to maintain this type of infrastructure.

The largest oversight I saw in this report was the lack of discussion of the international nature of open source development coupled with the huge discrepancy in cost of living in different parts of the world. This poses strange and significant fairness issues for project funding that I'm quite surprised Eghbal didn't notice: for the same money required to support full-time work by a current maintainer who lives in New York or San Francisco, one could fund two or three (or even more) developers in, say, some eastern European or southeast Asian countries with much lower costs of living and average incomes. Eghbal doesn't say a word about the social challenges this creates.

Other than that, though, this is a thoughtful and well-written survey of the resource problems facing the foundations of nearly all of our digital world. Free software developers will be annoyed but unsurprised by the near-total disregard of ethical considerations, but here the economic and ethical case arrive at roughly the same conclusion: nearly all the resources are going to companies and projects that are parasitical on a free software foundation, that foundation is nowhere near as healthy as people think it is, and the charity-based funding and occasional corporate sponsorship is inadequate and concentrated on the most visible large projects. For every Linux, with full-time paid developers, heavy corporate sponsorship, and sustained development with a wide variety of funding models, there are dozens of key libraries or programs developed by a single person in their scant free time, and dozens of core frameworks that are barely maintained and draw more vitriol than useful assistance.

Worth a read if you have an interest in free software governance or funding models, particularly since it's free.

Rating: 7 out of 10

2018-01-20: New year haul

Some new acquired books. This is a pretty wide variety of impulse purchases, filled with the optimism of a new year with more reading time.

Libba Bray — Beauty Queens (sff)
Sarah Gailey — River of Teeth (sff)
Seanan McGuire — Down Among the Sticks and Bones (sff)
Alexandra Pierce & Mimi Mondal (ed.) — Luminescent Threads (nonfiction anthology)
Karen Marie Moning — Darkfever (sff)
Nnedi Okorafor — Binti (sff)
Malka Older — Infomocracy (sff)
Brett Slatkin — Effective Python (nonfiction)
Zeynep Tufekci — Twitter and Tear Gas (nonfiction)
Martha Wells — All Systems Red (sff)
Helen S. Wright — A Matter of Oaths (sff)
J.Y. Yang — Waiting on a Bright Moon (sff)

Several of these are novellas that were on sale over the holidays; the rest came from a combination of reviews and random on-line book discussions.

The year hasn't been great for reading time so far, but I do have a couple of things ready to review and a third that I'm nearly done with, which is not a horrible start.

2018-01-07: Free software log (December 2017)

I finally have enough activity to report that I need to think about how to format these updates. It's a good problem to have.

In upstream work, I updated rra-c-util with an evaluation of the new warning flags for GCC 7, enabling as many warnings as possible. I also finished the work to build with Clang with warnings enabled, which required investigating a lot of conversions between variables of different sizes. Part of that investigation surfaced that the SA_LEN macro was no longer useful, so I removed that from INN and rra-c-util.

I'm still of two minds about whether adding the casts and code to correctly build with -Wsign-conversion is worth it. I started a patch to rra-c-util (currently sitting in a branch), but wasn't very happy about the resulting code quality. I think doing this properly requires some thoughtfulness about macros and a systematic approach.


In Debian Policy, I wrote and merged a patch for one bug, merged patches for two other bugs, and merged a bunch of wording improvements to the copyright-format document. I also updated the license-count script to work with current Debian infrastructure and ran it again for various ongoing discussions of what licenses to include in common-licenses.

Debian package uploads:

There are a few more orphaning uploads and uploads giving Perl packages to the Perl packaging team coming, and then I should be down to the set of packages I'm in a position to actively maintain and I can figure out where I want to focus going forward.

2018-01-01: 2017 Book Reading in Review

So much of my reading energy this year went into endlessly reloading political web sites and reading essays and poll analysis. This was not a very good use of that energy, but I did it anyway, and I'm not sure I could have stopped. It was a very 2017 problem, and I know I'm not alone — it was an anxious, anger-inducing year for a lot of us. I think that's also why I read shorter books (although more of them) than in 2016. Most of the year's reading happened in a couple of bursts during vacations.

My reading goal for last year was to get back to reading award nominees and previous award winners. The overall quality of my reading rose towards the end of the year, and I think several books I read in 2017 are likely to be award nominees or winners in 2018, but I still fell short of that goal. I'm carrying it over to 2018, coupling it with a goal to read more non-fiction, and calling that a goal to make time and energy for deeper, more demanding, and more rewarding reading. I want to sustain that over the year, rather than concentrating all my reading energy in vacations.

There were no 10 out of 10 books this year, but there were 6 books with a 9 rating. On the fiction side, two of them were the second and third books of Julie E. Czerneda's Species Imperative series: Migration and Regeneration. I recommend the entire series, starting with Survival, as excellent SF focusing on practicing scientists and on biology and ecology rather than physics. Czerneda has a slightly cartoony style that can take a bit to get used to, and I found the romance subplot unfortunate, but the protagonist was a delight and the last two books of the series were excellent.

The other fiction books with 9 out of 10 ratings were Becky Chambers's A Closed and Common Orbit, a sequel to The Long Way to a Small, Angry Planet that I thought was even better than the original, and Melina Marchetta's The Piper's Son. Many thanks to Light for the recommendation of the latter; it's the sort of mainstream literary fiction that I wouldn't have found without recommendations. It's a satisfying story about untangling past emotional mistakes and finding ways to move forward, but all the subtle work done by friendship networks was what made it special to me.

The two non-fiction books I gave 9 out of 10 ratings this year were Algorithms to Live By by Brian Christian and Tom Griffiths, and Why We Sleep by Matthew Walker. The first was a well-structured look at how we apply computer science algorithms to everyday life: short on actionable insight, but long on thoughtful analogies (email and social media as buffer bloat!) and new ways to view everyday decisions. The second is a passionate attempt to convince everyone to get more sleep. Like many projects dear to the author's heart, it should be taken with a grain of salt, but I found the summary of current sleep research fascinating.

The last book that I think deserves special mention is The Tiger's Daughter by K. Arsenault Rivera. It lacks the polish of some of the other books I read, and at times could be a sprawling mess, but of all the books I read this year, it's the one that most reliably puts a smile on my face when I remember it. It is completely unabashed about its emotions and completely in love with its characters and dares the world to do something about it, and I needed a book like that in 2017.

The full analysis includes some additional personal reading statistics, probably only of interest to me.

2017-12-31: Review: Barbary Station

Review: Barbary Station, by R.E. Stearns

Series Barbary Station #1
Publisher Saga
Copyright October 2017
ISBN 1-4814-7688-2
Format Kindle
Pages 448

Adda and Iridian are newly-graduated engineers who, as the book opens, are hijacking a colony ship to deliver it to a notorious group of pirates. Adda is the computer expert: dyed hair, neural implants, and the sort of high-tech gear required to subsume computer systems. Iridian is a former soldier, a Shieldrunner to be specific. They graduated into an awful economy following a secessionist war between Earth and the outer system and have spent much of their adult lives trying to keep their heads above water financially. This is Adda's scheme to get them enough money to live comfortably and, more importantly, together: hijack a colony ship, eject the passengers, and deliver the rest to the most successful pirate gang in the system.

This plan goes surprisingly well right up to the point where they arrive at Barbary Station. There, they discover that the pirates everyone believes are living in luxury in a former ship-breaking station are, instead, prisoners in a cobbled-together emergency shelter attached to the side of a station they can't safely enter. The pirates don't control Barbary Station. A malicious AI does, and it's trying very hard to kill them.

You can tell that this book was written in 2017 by the fact that a college education in engineering is only financially useful as a stepping point to piracy and crime. I can't imagine an author more than 20 or 30 years ago writing about economically desperate STEM college graduates, and yet it now seems depressingly plausible.

James Nicoll's appreciation for this story was derailed early by the total lack of attention the main characters give to the hapless passengers of the colony ship who get abandoned in deep space. I'm forced to admit that I barely noticed that, probably because the story seemed to barely notice it. Adda and Iridian do show some care for ordinary civilians stuck in the line of fire later in the book, but they primarily see the world in terms of allies and opportunities rather than solidarity among the victims. To be fair to them, their future is a grim, corporate-controlled oligarchy that is entirely uninterested in teaching such luxuries as empathy.

Despite some interesting examination of AI systems and the interaction of logic between security and environmental controls, Barbary Station is not really about its world-building or science-fiction background. If you try to read it as that sort of book, you will probably be frustrated by unanswered, and even unasked, questions. The plot is more thriller than idea exploration: can the heroines make allies, subvert a malicious AI, figure out what really happened on the station, and stay alive long enough for any of the answers to matter? There are a lot of bloody fights, an escalating series of terrifying ways in which an AI can try to kill unwanted parasites, and the constant danger that their erstwhile allies will suddenly decide they've outlived their usefulness.

As long as what you want is a thriller, though, this is an enjoyable one, although not exceptional. It has the occasional writing problem that I'll attribute to first novel: I got very tired of the phrase "the cold and the dark," for example, and the set pieces in the crumbling decks of a badly damaged space station were less epic than I would have wished because I struggled to visualize them. But the tension builds satisfyingly, the sides and factions on the station are entertainingly complex, and the resolution of the AI plot was appropriately creepy and inhuman. This AI felt like a computer with complex programming, not like a human, and that's hard to pull off.

This is also a book in which one of the protagonists is a computer hacker, and I was never tempted to throw it at a wall. The computers acted basically like computers within the conceit of neural implants that force metaphorical mental models instead of code. For me, that's a high bar to meet.

What Barbary Station does best is show a mixed working partnership. On the surface, Adda and Iridian fall into the brains and brawn stereotypes, but Stearns takes their relationship much deeper than that. Adda is nervous, distant, skittish, and needs her time alone to concentrate. She's comfortable in her own space with her thoughts. Iridian may be the muscle, but she's also the gregarious and outgoing one who inspires trust and loves being around people. While Adda works out the parameters of the pirates' AI problem, Iridian is making friends, identifying grudges and suspicions, and figuring out how to cross faction boundaries. And Adda and Iridian know each other well, understand each other's strengths and weaknesses, and fill in each other's gaps with unconscious ease. Books with this type of partnership protagonist told in alternating viewpoints aren't unheard of, but they aren't common, and I think Stearns did it very well. (I did find myself wishing the chapters would advertise the protagonist of that chapter, though, particularly when picking this book up after a reading break.)

Barbary Station felt like what military SF could be if it were willing to consider more varied human motivations than duty and honor, allow lesbian partners as protagonists, and use suspicious criminals instead of military units as the organizational structure. It has a similar focus on the technical hardware, immediate survival problems, the dangers of space, physical feats of heroism, and navigating factions in violent, hierarchical organizations. Characterization gets deeper and more satisfying as the book goes on, and there are a few moments of human connection that I found surprisingly moving. It's not entirely the book I wanted, it takes a while to get going, and I don't think the world background quite hung together, but by the end of the book I was having a hard time putting it down.

If you're in the mood for a desperate fight against malicious automation in an abandoned deep space structure, and can tolerate some world-building gaps, repetitive wording, and some odd failures of empathy, you could definitely do worse.

This is a mostly self-contained story, but there were enough hooks for a sequel that I was unsurprised to see that it will be followed by Mutiny at Vesta.

Rating: 6 out of 10

2017-12-31: DocKnot 1.02

DocKnot is my current personal automation project: try to find some way to keep all the various documentation for my software projects in sync while reusing boilerplate that applies to multiple projects. I'm still figuring out how I want it to work, so I haven't written the sort of comprehensive documentation that would let someone else more easily use it. The current tentative plan is to do that for the 2.00 release, around the time I've switched all my active project documentation and all my software web pages over to it.

This release has all the incremental improvements I needed to handle the pam-krb5 documentation:

I'll probably redo how the license is named in the future, since right now I'm abusing copyright-format 1.0 syntax in a way that wasn't intended. (I use that format for the upstream license files of all of my software.)

Right now, this is all very, very specific to my software page styles and how I like to document software, and doesn't aspire to be more than that. That's why I've not uploaded it to Debian, although it is available on CPAN (as App::DockNot) if anyone wants.

You can get the latest version from the DocKnot distribution page.

2017-12-30: pam-krb5 4.8

This is the default Kerberos PAM module for Debian and Ubuntu systems, and supports both MIT Kerberos and Heimdal. I'm not sure how many people still use straight Kerberos PAM modules these days, with sssd taking off, but I'm still maintaining it.

This release fixes a somewhat obscure bug: if you configure the module to do expired password changes properly, it checks to see that the expired credentials can still get kadmin/changepw credentials to do the password change. However, it was setting credential options improperly on that call, which could cause it to spuriously fail if, say, krb5.conf is configured to request proxiable credentials but kadmin/changepw doesn't support proxiable credentials. Thanks to Florian Best for the excellent bug report.

The test suite in this version also works properly with Heimdal 7.0.1 and later, which changed a bunch of the messages (at the cost of skipping tests with earlier versions of Heimdal), and reports richer error messages on PKINIT failures with Heimdal. It also includes documentation fixes and lots of warning fixes, and now builds properly with tons of warnings enabled with GCC 7, Clang, and the Clang static analyzer.

You can get the latest version from the pam-krb5 distribution page.

2017-12-30: rra-c-util 7.0

This is my collection of utility libraries and support code for (mostly) C software.

The major version bump is due a backwards-incompatible change: dropping the SA_LEN macro from portable/socket.h, including all the Autoconf machinery to probe for it. This macro came from INN's old portability code when porting to IPv6, but INN turned out to not really need it and it's never caught on. It was causing some warnings with GCC 7 that would otherwise have been hard to fix, so it was time for it to go.

There are a couple of other changes to function signatures that shouldn't matter for backward compatibility: network_sockaddr_sprint now takes a socklen_t for better type compatibility with other networking functions, and bail_krb5 and diag_krb5 in the TAP add-ons take a long as the error code argument so that they can take either a krb5_error_code or a kadm5_ret_t.

The remaining changes are all about enabling more warnings. rra-c-util now builds with intensive warnings enabled in both GCC 7 and Clang, and the warning options have been refreshed against GCC 7. It also reports clean from the Clang static analyzer, which included changing reallocarray and the vector implementations to always allocate memory of at least the minimum size.

You can get the latest version from the rra-c-util distribution page.

2017-12-30: C TAP Harness 4.2

The functional change in this release of my test framework for C programs is the addition of a new is_blob test function. This is equivalent to ok(memcmp(...)) but it reports where the two memory regions differ as a diagnostic. This was contributed by Daniel Collins.

Otherwise, the changes are warning fixes and machinery to more easily test with warnings. C TAP Harness now supports being built with warnings with either GCC or Clang.

You can get the latest version from the C TAP Harness distribution page.

Last spun 2018-02-12 from thread modified 2008-08-13