Eagle's Path

Passion and dispassion. Choose two.

Larry Wall

2018-03-17: DocKnot 1.03

This is the software that I use to generate documentation for my software. Currently, it just handles README, README.md, and the top-level web page for the package.

This release adds a new metadata file, support/extra, which includes information that should be added to the middle of the normal SUPPORT section of README and README.md files. It also adds an explanatory paragraph about SPDX to the default templates, and adds SPDX license identifiers to the package itself.

I've spent quite some time looking at good ways of maintaining accurate license metadata for my packages (and for Debian packages I maintain), including writing a truly ugly Perl script that generates a Debian copyright-format 1.0 file from a source tree. (There are multiple versions of this; mine is pickier than any other that I'm aware of.) Rather than trying to solve the free-form comment parsing problem, some form of structured metadata that's broadly adopted feels like the correct engineering solution (putting aside the fact that it will be hard to get everyone adopt it). The SPDX project is trying to solve this, and although it seems very bureaucratic and the spec is almost unreadable, it does seem to be catching on to a degree.

I'm therefore adopting it in my packages at least to the extent of adding SPDX-License-Identifier headers to my source files and using the SPDX-standard identifiers (which annoyingly differ from the Debian copyright-format identifiers). I added a test to check that all the files have these headers and will start adding that to all my packages as I release them.

I'm still generating the LICENSE file with my messed-up Perl script. I want to switch from that to a better script that supports SPDX and I don't have to maintain, and will take a look at both the SPDX tooling and cme when I have a chance.

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

2018-03-08: My friend Stirge

Eric Sturgeon, one of my oldest and dearest friends, died this week of complications from what I'm fairly certain was non-alcoholic fatty liver disease.

It was not entirely unexpected. He'd been getting progressively worse over the past six months. But at the same time there's no way to expect this sort of hole in my life.

I've known Stirge for twenty-five years, more than half of my life. We were both in college when we first met on Usenet in 1993 in the rec.arts.comics.* hierarchy, where Stirge was the one with the insane pull list and the canonical knowledge of the Marvel Universe. We have been friends ever since: part of on-line fiction groups, IRC channels, and free-form role-playing groups. He's been my friend through school and graduation, through every step of my career, through four generations of console systems, through two moves for me and maybe a dozen for him, through a difficult job change... through my entire adult life.

For more than fifteen years, he's been spending a day or a week or two, several times a year, sitting on my couch and playing video games. Usually he played and I navigated, researching FAQs and walkthroughs. Twitch was immediately obvious to me the moment I discovered it existed; it's the experience I'd had with Stirge for years before that. I don't know what video games are without his thoughts on them.

Stirge rarely was able to put his ideas into stories he could share with other people. He admired other people's art deeply, but wasn't an artist himself. But he loved fictional worlds, loved their depth and complexity and lore, and was deeply and passionately creative. He knew the stories he played and read and watched, and he knew the characters he played, particularly in World of Warcraft and Star Wars: The Old Republic. His characters had depth and emotions, histories, independent viewpoints, and stories that I got to hear. Stirge wrote stories the way that I do: in our heads, shared with a small number of people if anyone, not crafted for external consumption, not polished, not always coherent, but deeply important to our thoughts and our emotions and our lives. He's one of the very few people in the world I was able to share that with, who understood what that was like.

He was the friend who I could not see for six months, a year, and then pick up a conversation with as if we'd seen each other yesterday.

After my dad had a heart attack and emergency surgery to embed a pacemaker while we were on vacation in Oregon, I was worrying about how we would manage to get him back home. Stirge immediately volunteered to drive down from Seattle to drive us. He had a crappy job with no vacation, and if he'd done that he almost certainly would have gotten fired, and I knew with absolute certainty that he would have done it anyway.

I didn't take him up on the offer (probably to his vast relief). When I told him years later how much it meant to me, he didn't feel like it should have counted, since he didn't do anything. But he did. In one of the worst moments of my life, he said exactly the right thing to make me feel like I wasn't alone, that I wasn't bearing the burden of figuring everything out by myself, that I could call on help if I needed it. To this day I start crying every time I think about it. It's one of the best things that anyone has ever done for me.

Stirge confided in me, the last time he visited me, that he didn't think he was the sort of person anyone thought about when he wasn't around. That people might enjoy him well enough when he was there, but that he'd quickly fade from memory, with perhaps a vague wonder about what happened to that guy. But it wasn't true, not for me, not ever. I tried to convince him of that while he was alive, and I'm so very glad that I did.

The last time I talked to him, he explained the Marvel Cinematic Universe to me in detail, and gave me a rundown of the relative strength of every movie, the ones to watch and the ones that weren't as good, and then did the same thing for the DC movies. He got to see Star Wars before he died. He would have loved Black Panther.

There were so many games we never finished, and so many games we never started.

I will miss you, my friend. More than I think you would ever have believed.

2018-03-04: Free software log (February 2018)

Last month, I did a single software release: a new version of pgpcontrol, the collection of tools to check signed Usenet control messages. This is a pure maintenance release to keep it alive using GnuPG 1.0. The package is kind of a mess and needs a clean rewrite that I haven't had time to do yet (which is why I don't even have a software page for it).

Other than that, I didn't finish anything sufficiently to generate a new release, but I'm close on a bunch of fronts. Most of the user-visible (eventually) work went into podlators, the conversion tools from POD (Perl's documentation format) to text and man pages. Based on an excellent series of bug reports from eponymous alias, I fixed a bunch of long-standing bugs in Pod::Text, Pod::Text::Color, and Pod::Text::Termcap, and continued the slow process of reworking the package test suite to be cleaner and easier to maintain.

In C TAP Harness, I took an idea from the Rust assert macros and changed the arguments for all the TAP functions from wanted and seen to left and right. This way, one doesn't have to care about the order in which to pass arguments (which I can never remember). It will make it easier to update the INN test suite to the current TAP library interface, since I had used the opposite order for all of the original INN tests I wrote.

I spent a bunch of time adding SPDX identifiers to my utility functions that are intended for copying into other packages, and laid the groundwork for using SPDX identifiers in all of my projects. I picked up the habit of being careful about license notices from Debian work, and SPDX (if a bit weird in places, such as its utterly opaque file specification) is the first comprehensive and unambiguous labeling system. I have a horrible Perl script that does a lot of guesswork to generate a license file for my packages now, and am hoping to replace that with something (largely) based on SPDX.

Finally, I updated my Debian packaging with Git notes, and wrote new notes on using sbuild.

2018-02-28: Review: Coding Freedom

Review: Coding Freedom, by E. Gabriella Coleman

Publisher Princeton University Press
Copyright 2013
ISBN 0-691-14461-3
Format Trade paperback
Pages 223

Subtitled The Ethics and Aesthetics of Hacking, Coding Freedom is a rare beast in my personal reading: an academic anthropological study of a fairly new virtual community. It's possible that many books of this type are being written, but they're not within my normal reading focus. It's also a bit of an awkward review, since the community discussed here is (one of) mine. I'm going to have an insider's nitpicks and "well, but" reactions to the anthropology, which is a valid reaction but not necessarily the intended audience.

I'm also coming to this book about four years after everyone finished talking about it, and even longer after Coleman's field work in support of the book. I think Coding Freedom suffers from that lack of currency. If this book were written today, I suspect its focus would change, at least in part. More on that in a moment.

Coding Freedom's title is more subtle and layered than it may first appear. It is about the freedom to write code, and about free software as a movement, but not only that. It's also about how concepts of freedom are encoded in the culture and language of hacking communities, and about the concept of code as speech (specifically free speech in the liberal tradition). And the title also captures the idea of code switching, where a speaker switches between languages even in the middle of sentences. The free software community does something akin to code switching between the domains of technical software problems, legal problems, and political beliefs and ideologies. Coleman covers all of that ground in this book.

Apart from an introduction and conclusion, the book is divided into five chapters in three parts. The opening part talks about the typical life story and community involvement of a free software hacker and briefly sketches the legal history of free software licenses. The second part talks about the experience of hacking, with a particular focus on playful expression and the tension between collaboration, competitiveness, and proving one's membership in the group. The final part dives into software as speech, legal and political struggles against the DMCA and other attempts to restrict code through copyright law, and the free software challenge to the liberal regime of capitalism and private property, grounded in the also-liberal value of free speech.

There's a lot here to discuss, but it's also worth noting what's not here, and what I think would have been here if the same field work were done today. There's nothing about gender or inclusion, which have surpassed DMCA issues to become the political flash point de jour. (Coleman notes early in the book that she intentionally omitted that topic as one that deserves its own separate treatment.) The presentation of social norms and behaviors also felt strongly centered in an early 2000s attitude towards social testing, with low tolerance of people who haven't proven their competence. Coleman uses the term meritocracy with very few caveats and complications. I don't think one would do that in work starting today; the flaws, unwritten borders, and gatekeeping for who can participate in that supposed meritocracy are now more frequently discussed.

Those omissions left me somewhat uncomfortable throughout. Coleman follows the community self-image from a decade or more ago (which makes sense, given that's when most of her field research and the majority of examples she draws on in the book are from): valuing technical acumen and skilled play, devoted to free speech, and welcoming and valuing anyone with similar technical abilities. While this self-image is not entirely wrong, it hides a world of unspoken rules and vicious gatekeeping to control who gets to have free speech within the community, what types of people are valued, and who is allowed to not do emotional labor. And who isn't.

These are rather glaring gaps, and for me they limit the usefulness of Coding Freedom as an accurate analysis of the community.

That said, I do want to acknowledge that this wasn't Coleman's project. Her focus, instead, is on the way free software communities noticed and pushed into the open some hidden conflicts in the tradition of liberalism. Free political speech and democratic politics have gone hand-in-hand with capitalism and an overwhelming emphasis on private property, extended into purely virtual objects such as computer software. Free software questions that alliance, pokes at it, and at times even rips it apart.

The free software movement is deeply embedded in liberalism. Although it has members from anarchist, communist, and other political traditions, the general community is not very radical in its understanding of speech, labor, or politics. It has a long tradition of trying to avoid disruptive politics, apart from issues that touch directly on free software, to maximize its political alliances and avoid alienating any members. Free software is largely not a critique of liberalism from the outside; it's a movement that expresses a conflict inside the liberal tradition. It asks whether self-expression is consistent with, and more important than, private property, a question that liberalism otherwise attempts to ignore.

This is the part of the book I found fascinating: looking at my community from the outside, putting emergent political positions in that community into a broader context, and showing the complex and skillful ways that the community discusses, analyzes, and reaches consensus on those positions while retaining a broad base of support and growing membership. Coleman provides a sense of being part of something larger in the best and most complicated way: not a revolution, not an ideology, but a community with complex boundaries, rituals that are both scoffed at and followed, and gatekeeping behavior that exist in part because any human community will create and enforce boundaries.

When one is deeply inside a culture, it's easy to get lost in the ethical debates over whether a particular community behavior is good or bad. It takes an anthropologist to recast all those behaviors, good and bad, as humans being human, and to ask curious questions about what social functions those behaviors serve. Coding Freedom gave me a renewed appreciation of the insight that can come from the disinterested observer. If nothing else, it might help me choose my battles more strategically, and have more understanding and empathy.

This is a very academic work, at least compared to what I normally read. I never lost the thread of Coleman's argument, but I found it hard going and heavy on jargon in a few places. If, like me, you're not familiar with current work in anthropology, you'll probably feel like part of the discussion is going over your head, and that some terms you're reading with their normal English meaning are actually terms of art with more narrow and specific definitions. This is a book rather than an academic paper, and it does try to be approachable, but it's more research than popularization.

I wish Coding Freedom were more engaged with the problems of free software today, instead of the problems of free software in 2002, the era of United States v. Elcom Ltd. and Free Dmitry. I wish that Coleman had been far more critical of the concept of a meritocracy, and had dug deeper into the gatekeeping and boundaries around who is allowed to participate and who is discouraged or excluded. And while I'm not going to complain about academic rigor, I wish the prose were a bit lighter and a bit more approachable, and that it hadn't taken me months to read this book.

But, that said, I'm not sorry to have finally read it. The perspective from the anthropological view of one's own community is quite valuable. The distance provides an opportunity for less judgmental analysis, and a reminder that human social structures are robust and complex attempts to balance contradictory goals.

Coleman made me feel more connected, not to an overarching ideology or political goal, but to a tangled, flawed, dynamic, and responsive community, whose primary shared purpose is to support that human complexity. Sometimes it's easy to miss that forest for the day-to-day trees.

If you want to get more of a feel for Coleman's work, her keynote on Anonymous at DebConf14 in Portland in 2014 is very interesting and consistent in tone and approach with this book (albeit on a somewhat more controversial topic).

Rating: 6 out of 10

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

Last spun 2018-03-18 from thread modified 2008-08-13