Chapter 10

Full Stack DH: Building a Virtual Research Environment on a Raspberry Pi

James Smithies

Ian Hodder (2014) recently pointed to a “return to things” in the humanities and social sciences — a mode of analysis that explores the relationships between people and the objects we use to construct and make sense of the world (19). In digital humanities (DH), we see this turn in Matthew Kirschenbaum’s (2007) forensic analysis of computer hard disks; platform studies that investigate the relationship between computing culture, consoles, and other hardware (Monfort and Bogost 2009); and maker cultures that explore the humanities through practical experimentation (Dieter and Lovink 2014). A return to things suggests a desire to pay attention to and interact with the material world, rather than retreat to a purely digital one. Some commentators go beyond this position. They propose that entanglement with material objects represents a ground of being for humans and their societies — a postphenomenological “dialectic of dependence and dependency between humans and things” worthy of deep contemplation (Hodder 19). We rely on the things we have created to such a degree that our identity has become inseparable from them. In Donald Ihde’s (2009) original conception, such reliance amounts to a “recognition that ‘consciousness’ is an abstraction, that experience in its deeper and broader sense entails its embeddedness in both the physical or material world and its cultural-social dimensions” (19). As literary historian Bill Brown (2001, 2003) suggests, knowledge, art, religion, and science are entangled, in turn, with books, oil paint, churches, and laboratories: “thing theory” grounds epistemology in the myriad interactions between the physical and non-physical world (Preda 347–66).

My “Full Stack DH” project explored these ideas by engaging in a practical experiment: migrating my personal website — jamessmithies.org — from Wordpress.org (a free, fully hosted service) to a home server running on a Raspberry Pi minimal computer. In doing so, it extended the site from a limited blog to a Virtual Research Environment (VRE) capable of further development, and it also challenged me to consider the myriad connections between my scholarly identity, technical ability, and wider technological culture. The intention was not necessarily to create a monolithic product, but to take control of all aspects of the computing architecture to gain a better understanding of my scholarly infrastructure needs, from hardware and maintenance of the Internet domain name to the content management system and firewalls that secure it. Unexpectedly, the project also confronted me with ethical decisions about corporate information technology (IT) and the security challenges posed by bots. My colleagues can be forgiven for finding the purpose of the project opaque. It does not use archival sources or critique a text. It does not describe a historical event or argue a philosophical position. I do not recommend it as a model for widespread adoption. Rather, the project functions as a prototype, performance, and experiment: it asks to be read as scholarly objet d’art, instantiated in hardware and code.

In using a minimal computer, the project adopts an oppositional stance toward large-scale infrastructure, but it is intended as more than a statement in critical theory and by no means rejects large-scale infrastructure out of hand. Quite the opposite: it embraces digital infrastructure as an exciting new site for humanistic inquiry and calls for experimentation to “integrate theory and practice,” as Tara McPherson (2014) puts it, and take into account the “full stack” of our computational tools, from circuitry to software (177–88).

It does so by reporting on the development of a personal VRE. VREs come in a range of different configurations and are notoriously difficult to define, but they represent a central trope in the discourse of cyber-infrastructure. Although they sound like concrete things (and therefore present likely candidates for funding), in many ways they are undertheorized and misunderstood (e.g., “vaporware,” a software product that sounds like something everyone needs but is never delivered). To their detractors, VREs symbolize retrograde policy positions that assume humanists should use tools that will increase our productivity, legitimize our work in relation to the STEM disciplines, and give us fingertip access to everything the digital world promises. This project takes those concerns seriously. It uses prototyping to reconsider what a VRE might mean in a humanities context free of the issues large-scale VRE projects involve. The goal is to use a minimal computer and free software to create a prototype environment that is under my control, without the constraints and expectations of a large project, and (crucially) capable of ongoing extension and elaboration by a lone scholar.

Design and development of humanities VREs are made difficult by the plethora of tools, websites, resources, and methods available to researchers as well as the range of techniques used across the different humanities disciplines. A VRE to enable prosopographical research like the Lands of the Normans project about elite medieval landholders (Mackenzie et al. 127–42) will have quite different requirements than one designed to enable research into late-twentieth-century New Zealand poetry. Because of these differences, many countries are putting resources into aggregation and discovery projects (e.g., HuNI in Australia, DigitalNZ in New Zealand, and the DPLA in the United States) that form large distributed databases capable (in theory) of enabling computationally intensive research. These services offer public search interfaces but also Application Programming Interfaces (API) that can be used to provide source documents for a new generation of research tools; they represent an essential step toward the development of future VREs. Australian historian Tim Sherratt’s QueryPic website, which provides a search interface for the national libraries of Australia and New Zealand’s digitized newspaper collections, is an example of grassroots use of cultural heritage sector APIs. At the Digital Humanities 2014 conference in Lausanne, Adam Farquhar and James Baker from the British Library suggested a similarly flexible approach to the development of VREs based on five principles: keep it simple, lower the bar, bring your own tools, be creative, and enable users to start small and grow big (Farquhar and Baker).

We are clearly at a stage where small-scale tinkering needs to occur in parallel to large-scale data integration. This attitude is valuable when approaching the problem of humanities cyber-infrastructure. Why should we assume, after all, that humanists will need the kind of high performance computing (HPC) environments used in the hard sciences, or (more accurately) that investment in digital humanities should be directed toward such projects before other options that privilege education and services over physical systems? Similarly, how can we develop strong arguments that we need to invest in different kinds of tools and methods if we do not have examples of what we do need? In a simpler sense, how can we contribute to conversations involving the allocation of cyber-infrastructure funding if we do not understand the practical difference between megabytes and petaflops? I am involved in large-scale infrastructure projects, including the CEISMIC Canterbury Earthquakes Digital Archive and, more recently, Digital Research Infrastructure for the Arts and Humanities (DARIAH), but I recognize that we have a responsibility to attend to the small as well as the large.

Having said that, and although minimal computers offer a way to explore potential designs for VREs without the overhead that comes with large cyber-infrastructure projects, they cannot offer a canvas free of cultural or political bias. We should be wary of the culture surrounding them as much as we are of national and transnational cyber-infrastructure efforts.

Minimal or physical computing uses extremely small, low-powered, and cheap computers (often embedded on a single circuit board) to create anything from interactive art installations to mini weather stations and electronic sensors. The movement began in the art and design community as a way to integrate contemporary technologies into their practices. It moved into schools, libraries, art galleries, and museums when people decided that hacking (cobbling together working prototypes using cheap and easily available components) might offer a way to engage students with the material affordances of contemporary technology (Przybylla and Romeike 241–54). Many engineering and computer science teachers feel that students have lost an understanding of hardware that came naturally to earlier generations who had to struggle to get the most out of limited devices. These practices exist in the context of a broader “maker culture,” which extends Do-It-Yourself (DIY) principles from traditional arts and craft practices (e.g., needlework, stained glass making, etc.) to all manner of technology (e.g., minimal computing, 3-D printing, amateur robotics, etc.). They can be easily aligned to some areas of humanities theory, in a superficial sense at least. If we concentrate on the contents of our screens rather than investigating hardware and circuitry, for example, then we succumb to what Matthew Kirschenbaum calls a “medial ideology” (36): the mistaken belief that digital reality is “infinitely fungible” and unconstrained by physical limitations. Experimenting with physical hardware reminds us that the digital world is grounded in physical reality.

This is well and good, and more effort should go into exploring the intersections between maker culture and humanities theory, but it is equally important to avoid hitching the humanities to questionable trends in technology. In 1991 Mark Weiser, a computer scientist at the famed PARC research center, predicted that computers would “disappear” in the twenty-first century as production processes allowed them to be made ever smaller (94–104). This notion of ubiquitous computing (Greenfield), pervasive computing, or ambient computing (McCullough, Digital Ground; Ambient Commons) — each term holds a slightly different meaning — is viewed by many commentators as the inevitable next step in technological development. Large multinational corporations, including IBM, Google, and Microsoft, are making significant investments in the field. Rather than being mere toys, minimal computers such as the Raspberry Pi used in this project are now used in a wide variety of settings, including factory automation and systems monitoring, and they are central to the developing rhetoric of “ubicomp” (Dourish and Bell 23). The goal is to leverage miniaturization and falling costs of production to produce computers so small that they become “wearables,” embedded in walls, and eventually implanted in human bodies.

The aim is to connect billions of these devices over an Internet of Things, enabling radically useful new software tools. The business community is enthralled by the possibilities:

The vision of a future filled with smart and interacting everyday objects offers a whole range of fascinating possibilities. For example, parents will no longer lose track of their children, even in the busiest of crowds, when location sensors and communications modules are sewn into their clothes. Similar devices attached to timetables and signposts could guide blind people in unknown environments by “talking” to them via a wireless headset. Tiny communicating computers could also play a valuable role in protecting the environment; for example, sensors the size of dust particles that detect the dispersion of oil spills or forest fires. Another interesting possibility is that of linking any sort of information to everyday objects, allowing future washing machines to query our dirty clothes for washing instructions. (Raisinghani)

Needless to say, such a vision has worryingly Orwellian echoes to humanities researchers sensitive to issues of online privacy, surveillance, and a “digital panopticon” (Terras 257–69).

Rita Raley (2014) argues that an awareness of contemporary technology requires “more critical reflection upon, and ironic self-awareness about, the embedded place of digital humanities in the contemporary knowledge economy” (“Digital Humanities for the Next Five Minutes” 35). According to Raley, the way to achieve this awareness is to use technology to circumvent sociocultural systems oriented toward instrumentalist modes of reason or operational efficiency; “reverse engineering, hacktivism, denial-of-service attacks, the digital hijack, contestational robotics, collaborative software, and open-access technology labs” are all cited as potential vectors to critique digital culture from within, instead of merely criticizing from without (Tactical Media 6). In other words, it is not so much a case of the tools you use, but the philosophical perspectives and level of critical awareness you evince in their deployment. The claim is that (rather than attempting to regain an antediluvian, pre-digital past) digital technology should be hijacked for creative, ethical, and critically informed goals, in an effort to construct new forms of subjectivity that can support less compromised forms of political engagement. This kind of “tactical” activity asks to be understood in terms of “performance” as much as the postphenomenological entanglement that inspired jamessmithies.org (9). It privileges the artistic act over instrumentalism and seeks to prompt thought and further exploration rather than (necessarily) resulting in outcomes that can be measured or operationalized.

Michael Deiter and Geert Lovink suggest similar approaches in their “Theses on Making in the Digital Age.” They propose that humanists develop prototypes designed to function as a “model” or “ideal type” at the interface “between the workshop and the factory.” So-called “critical making” can improve our understanding of technology in academic contexts and broaden its potential for teaching and research. Despite traditional resistance to manual, laboratory-like activity in the core humanities disciplines, resources are becoming available to support maker culture and minimal computing within them (Fuller 78). These resources range from this volume of essays to advice offered at major institutions such as the Smithsonian Institution[1] to university-based laboratories and centers dedicated to experimenting with emerging tools and methods. Theoretical approaches to critical making “are intended to bridge the gap between creative physical and conceptual exploration” (Ratto 252–60) and guide researchers interested in exploring the relationship between technology and sociocultural life. Frameworks such as design thinking are being used to guide the design process (Plattner, Meinel, and Leifer).

As Matt Ratto (2011) points out, “devices themselves are not the ultimate goal” of critical making (253). Rather, the idea is to produce prototypes and basic models in the service of wider intellectual goals, blending “practice-based engagement with pragmatic and theoretical issues” (253). He suggests that the approach can be particularly useful in the context of so-called “wicked problems” (253), defined by architectural scholar Horst Rittel in the 1960s and 1970s (Rittel and Webber 160). This class of problem is characterized by the existence of “many clients and decision makers with conflicting values, and where the ramifications in the whole system are thoroughly confusing” (Churchman B141). Rittel was interested in problems associated with large-scale planning projects. Significantly, he claimed there is a moral element to such problems, in that it is immoral to solve only one component of a wicked problem when such an approach will leave the larger issue unresolved. Prototyping and critical making can thus be positioned not as inadequate tinkering but as a mode of activity well-suited to the resolution of very complex problems. In this way we come to an intersection of tactical media, critical making, cyber-infrastructure, and the humanities.

My website, jamessmithies.org, is hosted on a Raspberry Pi 2 Model B, a minimal computer built in the United Kingdom at Sony’s manufacturing plant in Pencoed in South Wales and supported by a registered charity, the Raspberry Pi Foundation. The computer measures 85.60 mm by 56 mm by 21 mm (or roughly 3.37” by 2.21” by 0.83”), has 1 GB of Random Access Memory (RAM), and is powered by a 900-MHz quad-core ARM Cortex-A7 Central Processing Unit (CPU). ARM processors were developed by a British company, ARM Holdings, and are designed for low-power mobile devices. According to Wikipedia, the Pi is the fastest selling British personal computer in history, with over five million units sold as of February 2015. The computer uses “system on a chip” architecture, meaning the RAM, CPU, and video capabilities are all embedded on a single integrated circuit. Long-term storage is provided by a removable mini SD card, which can be bought in sizes from 8 GB to 128 GB.

The Pi can be connected to a keyboard, mouse, and monitor as well as the Internet (via an ethernet connection or wifi). It has four USB ports, an audio jack, and a High-Definition Multimedia Interface (HDMI) video/audio port. Power is supplied using a micro connection, the kind of power pack used to charge mobile phones. Minimal computers like the Pi often run “headless” without keyboard and monitor. In that case, as with this project, maintenance of the Pi is undertaken remotely using another computer connected to the Internet or a local network. This approach allows all available resources to be directed to specific goals (such as running a web server) instead of running processes required for a monitor and other peripheral devices. Lack of computational power is a feature, not a design flaw, of the Raspberry Pi. Aside from keeping unit costs down, it forces people to think carefully about use and performance.

This thinking increases computational literacy by forcing people to interact with the computer as a thing-in-itself: merely an engineered device with affordances and constraints. The question of over-engineering and its relationship to economics arises, too. Computer manufacturers and software developers make money by selling new devices to consumers in a marketing cycle that transfers personal and organizational funds into the accounts of multinational corporations. While new features are exciting and often useful, most modern computers have significantly more functionality than their users need. This excess is not a problem if someone simply wants to experience the added benefits of the latest iPhone or Galaxy S, but it is a problem if investments are being made in computing devices at the expense of, say, books and faculty. Most humanists only ever use word processors, web browsers, and e-mail applications, but are supplied with computers that far exceed those requirements. While a 1-GB minimal computer is too low-powered for everyday professional use, it is closer to the minimum requirements than its NZD $65 price tag might suggest.

Like most minimal computing devices, Raspberry Pi runs versions of the open-source Linux operating system (OS) (Raymond). Linux was heavily influenced by Unix operating systems developed at AT&T’s Bell Laboratories in the 1970s, so it has deep connections to computing history (Toomey 74–82). Although not widely used for desktop PCs, Linux and Unix-like operating systems are used for over 67 percent of the world’s web servers,[2] along with a wide variety of mundane devices from televisions to traffic lights. Although the community’s culture is not without its problems (its initiator and figurehead, Linus Torvalds, is recognized as a “benign dictator for life,” and there are periodic claims of bullying and overly aggressive behavior), over twelve thousand programmers have contributed to the Linux project since 2005. Yochai Benkler (2002) describes it as a system of peer production and “sociological phenomenon” that changed software development norms and raised questions about the dominant paradigms underlying economists’ definition of productivity (373). Linux is licensed so freely that over six hundred different “distributions” or “distros” of its kernel have been created by people and organizations in need of bespoke operating systems, including systems for minimal computers such as the Raspberry Pi. At the time of writing, at least ten Linux operating systems, from “Debian Wheezy” (suitable for general users and recommended for school projects) to “Pidora” (based on Fedora, a popular operating system for web servers and the OS chosen for this project), were available to install on Raspberry Pi. The vast majority are free to download and use and also offered under the GNU General Public License (GPLv2) that allows modification and redistribution.

The Raspberry Pi computer and Linux operating system thus provide the foundations of jamessmithies.org: a credit-card-sized computer stored inside a cheap plastic box, plugged into a standard home modem, and nestled under a desk in a home office. The Pi and OS can perhaps be viewed as the filing cabinet and folders of the VRE, accessible only to their owner and configured according to their personal requirements. The application architecture that sits on top of this device enables the core functions and creates the opportunity for further development (see Figure 10.1).

I built the VRE application using Django, a Python-based web framework designed for newspaper websites but now deployed in a wide variety of scenarios. Social media service Pinterest is one of the largest services to use Django, with over forty-six million unique visitors between 2011 and 2015 (Statista). The framework is highly adaptable and could be used to develop almost any functionality a humanities researcher might need. Jamessmithies.org is served by the Gunicorn application server and lightweight Nginx web server. The latter was developed by Russian programmer Igor Sysoev in 2002 but is now maintained in San Francisco; it is used by NASA and dozens of other high-profile sites. Content is saved in Postgres, one of the more advanced database systems available. All of these products are available free through the open-source community. They require a reasonable level of technical proficiency to install and configure, but many tutorials are available online and their user communities openly share knowledge. Although a massive gap exists between jamessmithies.org and well-funded cyber-infrastructure projects, the nature of the open-source software movement means only a small gap (if any) exists in terms of scalability and potential functionality.

One of the most powerful things about the project — in both technical and tactical terms — is the level of control conferred by the architecture of the “stack.” Not only is the Pi itself accessible and configurable, but its operating system can also be changed, and Gunicorn and Nginx can be configured at both an administrative level and through their core code base. Django can be programmed to support an extremely wide range of functionality. To extend the metaphor of control toward the incomprehensibly large infrastructures used by multinational digital corporations (and to escape criticism that the Pi is a fundamentally limited device, or a mere toy), static files like Cascading Style Sheets (CSS) and images are hosted in the Amazon Web Services (AWS) cloud, too, integrating the Pi with a truly enormous global data infrastructure. These files could have been hosted on the Pi, but developer communities consider it best practice to deliver files separately for Django projects. Essentially, much of the heavy lifting is outsourced to a high-performance computer, allowing almost limitless options for expansion of the site.

The fact that Amazon is a multinational giant responsible for changes in publishing and the wider culture industry that challenges the humanities is both ironic and somewhat perverse, of course. Resisting Amazon’s low-cost services and massive economy of scale is difficult, even when starting with a little computer that is relatively free of the more negative associations of corporate IT. Let there be no doubt: any facade of purity (technological or intellectual) is compromised and perhaps entirely lost despite radical gains in functionality. The services offered include, remarkably enough, easy development of a Content Delivery Network (CDN) like those used by corporate giants to spread site content across multiple edge servers around the world in cases of extraordinarily high demand, reducing the latency that results when bits are forced to flow across vast distances. Storage for these files costs less than NZD $1 per month, despite the fact that they share the same infrastructure as commercial sites such as Netflix and Reddit. I also used AWS to connect the VRE to the Internet. Instead of third-party services that hide details of Internet Protocol (IP) redirection, I used accessible hosting tables and the AWS Route 53 service to route the domain name jamessmithies.org to the Pi’s public IP address. Similarly, I configured the firewall on the home router that directs http requests to the VRE, and another installed on the Pi itself, and can maintain them along with the rest of the system.

The limited processing power of the Pi will continue to constrain the project in important ways, but its integration into AWS speaks to its larger meaning as a full stack project. It offers a model cyber-infrastructure that unites theory and practice in addition to hands-on control of the means of production by the scholar-author without sacrificing power and reach. It represents a macrocosm of big data, big enterprise, and big Internet, miniaturized to a level where individual scholarly agency is regained, if only to a degree. This agency is perhaps most apparent in the inclusion of a Virtual Machines section to the VRE, which migrated content from another of my projects, Academic AMI (academicami.org). This migration more than merely consolidated my technical work and reduced the fragmentation of my scholarly identity across multiple online services. Academic AMI was produced in 2011, in response to a lack of easy-to-access “sandpit” servers. Any time I wanted to experiment with a new tool, test a new plug-in, or demonstrate how a web application could be used in teaching or research, I needed to configure multiple local environments (for each participant) or use an online service to set up a public-facing server. Amazon Machines Images (AMIs) allow me to package up complete operating systems, replete with their own web server and web application, and run them online in less than five minutes. A workshop with 40 participants can thus learn how to use Omeka or Open Journal Systems in the cloud with very little technical overhead.

This approach allowed me to self-provision a minor but functional analogue to Australia’s Nectar Cloud, to which New Zealand had no parallel at the time. (It is of some significance that academicami.org actually predated the Nectar Cloud and several similar services around the world.) jamessmithies.org is now more than a mere blog; it is beginning to assume some characteristics of a full-fledged VRE, including “cloud infrastructure on demand” and a downloadable virtual machine that can be either run on a local computer or distributed to groups in need of a standardized operating system and digital humanities toolset. More work is planned to fulfill some of my other needs as a researcher and teacher: integration of my zotero.org library so my intellectual interests are more transparent to visitors; aggregated search across datasets I use on a regular basis; and experiments with visualization and machine learning. Unlike many digital humanists who will either choose or be forced to spread that kind of activity across multiple platforms, at the end of my career I hope to have a single project that consolidates and presents a lifetime of digital scholarship. This aim is perhaps the larger challenge posed by jamessmithies.org. For people with the requisite skills, does a minimal computer + open source web framework + cloud service integration amount to the ultimate VRE?

The need for ongoing maintenance suggests not. Conceived as a decades-long personal project, jamessmithies.org is likely to stay live for some time as a by-product of intellectual and technical engagement, but it is far from a model for general use. This chapter is intended as a project report, not a “how to” guide. The Pi needs to remain plugged in for the site to remain live, the tools used to build it are relatively advanced technologies and need to be updated on a regular basis, improvements in functionality are constrained by my limited programming skills, and depending on Amazon is problematic. The project’s intellectual grounding in postphenomenology provides an intriguing perspective on this situation. When all is said and done, it offers an object lesson in human-thing entanglement. The Pi and the VRE that sits atop it are entwined with its author in intellectual, cultural, technical, and epistemological terms. Its affordances can only be enjoyed with ongoing care and attention, perhaps not unlike a farmer’s tools; the natural rhythms of human interaction with (and dependence on) technology is returned as a consequence of experimentation. Conceived in this way, the knowledge created from the system and presented using it become almost indistinguishable from the system itself. It presents a stark reminder about the relationship between the modern self and digital technology (Verbeek 9).

The value of the project as a digital humanities experiment is further illustrated in the unexpected insight the Pi/VRE offers about bots and the algorithmic nature of an online, digital world. Bots (short for “robots”) take many forms, but are essentially automated software programs that perform tasks on the Internet for their designers. Those tasks range from performing indexing for search services such as Google and Bing to writing cyber-fiction and publishing it on Twitter (Meyer 2013). Digital humanists have started exploring the potential of bots to create new forms of knowledge by surfacing random snippets from the Trove newspaper archive (Sherratt 2013) and building politically oriented “protest bots” (Sample 2014). Other bots are more malicious and scan the Internet for vulnerable web servers to integrate into massive “botnets,” which can then be used to send spam or flood other websites with requests in denial-of-service attacks. In a worst-case scenario even the lowliest Raspberry Pi could be enlisted in an attack on the cyber-infrastructure of a nation-state.

Every website on the Internet is subjected to ongoing probing by these bots to find weaknesses, but owners remain unaware because attempted attacks are only recorded in server logs accessible by system administrators. Online services such as Wordpress, Blogger, and Medium keep those logs far from end users, making it impossible to see which bots are casing your website. This distance is inconsequential in many ways and merely illustrates the good sense of using supported services to ensure your online security, but it hides an important feature of the digital world: the vast, algorithmic swarms of bots that go about their business behind the scenes. jamessmithies.org is regularly visited by Googlebot (indexing for Google), Baidu Spider (indexing for the Chinese Baidu search engine), and other friendly enough bots. But it is also subject to attack by Morfeus Fucking Scanner, The Beast, and others that scan for vulnerabilities they can exploit to gain access. The Pi thus unexpectedly acts as a honeypot for research into the algorithmic world beneath the surface of the web, problematizing my understanding of the Internet as a human-centered domain and driving home the potential unsustainability of the project as a whole. While projecting intentionality onto bots would be foolish, jamessmithies.org illustrates an empirical research finding that arose due to the full stack design of its VRE: an unforeseen affordance unlikely to be a feature request in a formal requirements definition workshop. Such machine-inspired serendipity justifies ongoing engagement with a lowly Pi.

Notes

Bibliography