This case study is an abbreviated version of my second master thesis in interaction design, Computation as Strange Material: Excursions into Critical Accidents. It investigates the notion that a computational artifact is a product of technical conditions and the social structures by which they get produced and, crucially, re-produced. It frames computation as a recursive relationship between the two, entangled in weird ways to form a strange material.
I explore these themes through computational prototypes situated in social-technical intersections. This essay is a case study about one of these prototypes, a kind of terminal that traces program execution through the Linux Kernel Mailing List. The thesis goes into greater detail about the concept, but this text is self-contained. The source code of the experiment can be found on GitHub.
Why is the source code and not commit messages considered the canonical representation of the software? What if you could debug through GitHub tickets or chart execution using email threads? This case study outlines a prototype I made that answer the latter, providing an interface that connects dense Linux stack traces to the corpus of the Linux kernel mailing list. It outlines the design process, reflects on its use and traces possible continuations.
The oral history of stack traces
Like so many things, the project started with a bit of, almost accidental, media archaeology. I was developing another prototype when it crashed to a stack trace, like so many times before. Stack traces document the computational process of a running program and dumps them into a dense, slightly frightening blob of text. To get a scale of how large these can get, loading a web page in Safari executed at least 385 different subroutines and system calls, resulting in a stack trace that, when printed, would span 62 A4 pages of 10pt Times New Roman. This is fascinating by its sheer scale; however, I was interested in seeing what the stack trace could tell us about the social production of software. As such, I hacked together a small, barely-graphical user interface that used sample to grab the execution stack of a running program.
The screenshot shows a view of the aforementioned Safari stack trace. Anyone who has worked on macOS internals knows that they originate in the NeXTStep operating system, as signified by the NS prefix found in the name of types and functions, i.e., NSString or NSDictionary. Nowhere in any documentation, promotional material or user-facing text does macOS acknowledge this heritage, yet, pop the hood open, and it proudly stares back at you. A similar thing happens if you get deep into the Java programming language and its runtime.
Today, software giant Oracle owns and maintains Java, a relationship through acquisition. The language originated at Unix darlings Sun, a similar chapter of economic history that forever haunts our computational systems in the levels of Java code, where one often comes across namespaces featuring the com.sun prefix. Thus, the stack trace of a program forms a kind of oral history of itself, a constant, recursive reenactment of software history. It is one of the few instances where the socioeconomic structures produced software directly seep through the bitmasked cracks of the otherwise notoriously closed corporate world. It also raises the question of where one might find similar, strange intersections, a search that leads us to the most extensive email list in the history of the world.
Grokking the LKML
The Linux kernel is arguably the most critical piece of software in the world, forming the basis of multiple operating systems, most notably Android. It is notable not only for its technological ubiquity but also for its mode of production. Linux is free and open-source software, continuously maintained by a decentralized network of volunteers that provide their labor as part of their work or as a way to show care to other users, often both.
The development of Linux takes place on the public Linux kernel mailing list (LKML). Today multiple lists where Linux kernel development happens through debate, discussion and the inevitable submission of patches — changes to the source code. Participation in the LKML is open to anyone, as is the offer of patches. The LKML is a testament to the fact that the Linux kernel is not “just” a technical project but a planetary-scale social experiment into decentralized (re-)production. The LKML is continuously archived and available for anyone (with the know-how) to scrutinize.
The LKML is archived using git, the today ubiquitous version control software originally written by Linus Torvalds to support kernel development. Lists archival follows the public-inbox “standard,” an “archives first approach the mailing lists” that, as far as I can tell by a short search, is used exclusively in the kernel world. Working with the archive, perhaps the largest git repository created, requires the use of grokmirror, after which you have to get acquainted with the concept of a “bare” repository.
Working with the LKML is arcane and requires an in-depth understanding of git, email and piecing together disparate man-pages. At first, it was infuriating, but once you get your head around it, it is a lovely example of situated software. The LKML archives do a single, non-trivial thing and manage to do so using solely tools known to a large portion of the intended audience. For example, the entire script I wrote to parse a public-inbox repository and put it into an SQLite database is just about 100 lines of parallelizable Clojure code. With the lists in hand, one can be probing the social structure of the kernel.
Tracing social structure
The untitled prototype, its name only known to the stack traces as org.motform.strange-material.lkml, juxtaposes the execution of Linux system calls with a list of email discussions, their implementation, debugging and use. A system call is how a program communicates with the operating system, often requesting resources like input devices or memory. This move intends to re-frame the dense, technical stack trace through the softer, sometimes surprisingly caring email conversations that lead to their creation.
The prototype underwent a few different iterations during its two weeks of development. The initial version featured the pre-analyzed syscalls from ls, where selecting a call in the list filters the email view to relevant messages.
The second version removes the dependence on the pre-analyzed call and enables interactive use. The application was paradoxically developed on macOS, requiring the use of a Linux virtual machine run through Vagrant to provide a Linux environment. In addition, it adds a richer interface, including a command line, tabbed command, and views that include stdout and the stack trace itself.
The final version cleans up the interface in favor of something my thesis examiner and later college Clint Heyer dubbed “strangely wireframe-like”, a critique which I partially blame on the fact that the application uses using cljfx, an excellent interface to the horrible UI toolkit JavaFX. This iteration is like a simple terminal, perhaps the world's first tracing teletype.
“Final” is a bit of a misnomer in this context as there is a lot of room for improvement in fidelity and function. However, it fills its purpose perfectly as a vehicle for inquisitive research.
Exploring social computation
I took the prototype for a spin during a very open-ended workshop with a few designers. After briefly introducing the history of the Linux kernel in general and the LKML in particular, we shifted gears into exploration.
Most of the emails are technical; as such, the participants were surprised to discover that the LKML is often a labor of care. In a 2008 email, Pavel Machek submits a bug report about how a recent kernel update broke “Columns,” a “very popular game of year about 1993”, sarcastically noting how the update also crashed “my boot, but who cares about boot when the game is broken?” The intention behind the email, which (participants were quick to note) was sent to the entire LKML, was never ridiculed; instead, it triggered a joint debugging session that ended in a patch submission fixing the root problem, making Columns playable once more. One participant likened this dialectic between the accident and adapting to the fervorous choreography of an ant colony — a seemly chaotic yet, masterfully orchestrated interplay between creation and maintenance through collective care for each other.
Once the participants had gotten familiar with the prototype, the work took an analytical turn. Discussions moved away from the situated scenes of the interface towards the larger scales of the LKML. The sheer size of the corpus incited speculation about whether one could train an artificial neural network to re-enact and then automatically maintain a parallel copy of the LKML. Indeed a strange thought, the idea then evolved into a meditation on what might happen if one splices the LKML at arbitrary points and resume development from there. The schism could be enacted by humans or a purposely trained machine learning system, regardless of constituting a counterfactual development of the Linux kernel and, by extension, the foundation of our computational reality. This idea transformed the LKML into more than an archive, a strange attractor for each email, the possible convergence of a new chronology.
The excursion ended, not with the exhaustion of the initial stack trace experiment but with a teeming excitement. Instead, the participants began to brainstorm other interfaces for the LKML, such as an interactive quilt inspired by Daniella Rosner’s project Making Core Memory, before concluding how the journey had “opened the black box.”
This workshop was a small session with a few designers, but it speaks to the point that even such a simple juxtaposition can open doors to previously unthinkable discussions. It also points to the many possibilities for other, more elaborate versions of the same concept. For example, could it be a debugging tool if it had a more advanced email view that mapped commit-SHA to messages? How should you visualize the interconnections between a syscall and a snarky comment? Could you execute the email list itself?
I don’t have the answers to these questions, which is incredibly exciting. Getting stuck in the limited horizons set by the current visions of computation is easy, so we should make sure to listen.
Special thanks to my thesis advisor Linda Hilfling Ritasdatter, for always seeing through my bluffs and pushing the project into new, far more exciting places. If you found this essay interesting, you would love her fascinating Ph.D. on COBOL and its entangled manifestations of execution, crisis, and maintenance.