In KSP Interstellar, thermal and electric rockets run on power–but producing power with a fission reactor (at least, with the technology accessible early in the tech tree) is frustrated by the high mass of the reactor and electric generator. We can beam power via microwaves, but early experiments revealed that moderately sized orbital fission reactors were not capable of producing sufficient power. We needed more. Lots more.
Solar panels collect energy from the sun; they’re lightweight and inexhaustible, but produce very little power compared to a full-size reactor. Moreover, their power falls off with the inverse square of distance to the sun, making them less effective for outer-planetary exploration.
In February of 2014, I discovered KSP Interstellar, which adds a broad array of hypothetical technologies to Kerbal Space Program. For instance, you can attach a small nuclear reactor to a thermal nozzle, and fly a small plane for several years continuously, using only air for fuel.
Kerbal Space Program is a game that, at its best, conveys the grandeur and majesty of space exploration. I suggest you put on an appropriate soundtrack and imagine the long, slow descent to the surface of the moon, in a craft surrounded by millions of miles of vacuum. Having traveled for days, shedding propellant and stages along your journey, until finally, your final stage hovers, whispering to a halt on jets of burning breath from your ancestral homeland–
Somewhere around January of 2014, I discovered Kerbal Space Program.
Prey is an perfectly serviceable AAA-class, science-fiction survival thriller game. It’s a first-person shooter, a stealth adventure, and a surprisingly enjoyable platformer. The plot is all right. The art is iconoclastic and gorgeous. As is traditional for the genre, much of the storytelling transpires through the environment: emails, voice logs, and diorama. There are some lovely ethical questions, both abstract and reified. For some reason, these are the things that people talk about when they talk about Prey.
After all, Prey is a videogame, and gameplay, art direction, and story are how we read videogames as texts. But I’d like to step back for a moment and talk about Prey’s symbolic and thematic choices, which are absolutely fucking fascinating. Spoilers ahead.
Previously: Hexing the technical interview.
In the formless days, long before the rise of the Church, all spells were woven of pure causality, all actions were permitted, and death was common. Many witches were disfigured by their magicks, found crumpled at the center of a circle of twisted, glass-eaten trees, and stones which burned unceasing in the pooling water; some disappeared entirely, or wandered along the ridgetops: feet never touching earth, breath never warming air.
Previously: Reversing the technical interview.
Long ago, on Svalbard, when you were a young witch of forty-three, your mother took your unscarred wrists in her hands, and spoke:
If you want to get a job as a software witch, you’re going to have to pass a whiteboard interview. We all do them, as engineers–often as a part of our morning ritual, along with arranging a beautiful grid of xterms across the astral plane, and compulsively running ls in every nearby directory–just in case things have shifted during the night–the incorporeal equivalent of rummaging through that drawer in the back of the kitchen where we stash odd flanges, screwdrivers, and the strangely specific plastic bits: the accessories, those long-estranged black sheep of the families of our household appliances, their original purpose now forgotten, perhaps never known, but which we are bound to care for nonetheless. I’d like to walk you through a common interview question: reversing a linked list.
First, we need a linked list. Clear your workspace of unwanted xterms, sprinkle salt into the protective form of two parentheses, and recurse. Summon a list from the void.
Last fall, I worked with CockroachDB to review and extend their Jepsen test suite. We found new bugs leading to serializability violations, improved documentation, and demonstrated documented behavior around nonlinearizable multi-key transactions. You can read the full analysis on jepsen.io.
This fall, I worked with MongoDB to design a new Jepsen test for MongoDB. We discovered design flaws in the v0 replication protocol, plus implementation bugs in the v1 protocol, both of which allowed for the loss of majority-committed updates. While the v0 protocol remains broken, patches for v1 are available in MongoDB 3.2.12 and 3.4.0, and now pass the expanded Jepsen test suite.
You can read the full analysis at jepsen.io.
In Herlihy and Wing’s seminal paper introducing linearizability, they mention an important advantage of this consistency model:
Unlike alternative correctness conditions such as sequential consistency  or serializability , linearizability is a local property: a system is linearizable if each individual object is linearizable.
Locality is important because it allows concurrent systems to be designed and constructed in a modular fashion; linearizable objects can be implemented, verified, and executed independently. A concurrent system based on a nonlocal correctness property must either rely on a centralized scheduler for all objects, or else satisfy additional constraints placed on objects to ensure that they follow compatible scheduling protocols.