Advent of Computing - Episode 46 - Hacker Folklore

Episode Date: December 28, 2020

Hacker hasn't always been used to describe dangerous computer experts will ill intent. More accurately it should be sued to describe those enamored with computers, programming, and trying to push machines to do interesting things. The values, ethics, morals, and practices around those people make up what's known as hacker culture. Today we are digging into the Jargon File, a compendium of all things hackish and hackable, to take a look at hacker culture through its folklore.   Huge thanks to some of my fellow podcasters for doing readings for me this episode. In order of appearance they are:   Randall Kindig of the FloppyDays Vintage Computing Podcast(floppydays.com) Charles Edge from The History of Computing(thehistoryofcomputing.libsyn.com) Sebastian Major of Our Fake History(ourfakehistory.com)   Like the show? Then why not head over and support me on Patreon. Perks include early access to future episodes, and bonus content: https://www.patreon.com/adventofcomputing

When it comes to computers, the actual hardware and software only account for part of the full story. Now, don't get me wrong here. Hardware is a really interesting and important part of what I cover. The same thing goes for software. As I always say, hardware is actually pretty useless without some kind of code to run on it. But you can't fully explain the history of computing with just blinking lights and stacks of code. That would turn to a pretty dry story pretty quickly. You need to also look at the messy part.

That's the human element. And for me, this is where problems usually crop up. You see, there's a certain kind of person that's drawn to computers. Enthusiasts, programmers, engineers, and researchers all seem to have at least somewhat similar motivations. Why do they work with computers? Well, computers are just neat. Why else? Solving problems is fun, and finding inventive solutions is rewarding in itself. And while this kind of drive is really great for the discipline at large, it can also make researching the development of technologies a little bit annoying. Why did Ken Thomas and Dennis Ritchie develop Unix?

Why did text-based adventure games start to show up all over the place? Sure, there are really good technical reasons, but partly it was just for the fun of the project. Once mass-produced computers introduce more people into the fold, these kinds of traits and motivations, they kind of become omnipresent, at least to a point. Those working on large shared mainframes quickly turn from simple teams of researchers into groups of friends. And once networking starts to link up computers, these groups of friends form into a larger community. So, we start to see a large grouping of people with shared ideals, practices, beliefs, and

a common cause at their core. Now that sounds an awful lot like a culture. This is usually called hacker culture. And like any other culture, it has its own folklore. Welcome back to Advent of Computing. I'm your host, Sean Haas, and this is episode 46, Hacker Folklore. Now, this is a project that I've actually had in the works for a while, so I'm especially excited to get to share it with you all. Today's episode is going to be a little bit different from my normal fare. I'm not going to be talking about a specific computer, technology, or even really a series

of events. Instead, we're taking a detour through some fun and I think pretty funny territory. We're going to be looking at a section of the jargon file. In the print edition, it's Appendix A, Hacker Folklore. Hopefully you'll excuse me, but you're in for a bit of a long preamble here. I put together a mini-episode on the jargon file way back in the archive, mainly talking about the file's origins and its history. In short, it's a dictionary of terms used by the more computer-savvy folk. The file began in the 1970s at MIT's Artificial Intelligence Lab, and it spread

pretty quickly from there. Versions moved from coast to coast over the ARPANET, and in 1983, the first print edition was published as the Hacker's Dictionary. This isn't really a dry treatise on terms and technical language. The jargon file is a lot closer to humor than anything else. The file is a mixture of some pretty lowbrow jokes, jabs at corporate employees, and actually useful definitions. For its creators, the jargon file was a fun pastime with an actual purpose. It captures a slightly filtered view of the culture around computers in the 70s, 80s, and beyond. The latest version, v4.4.7 up on CatBee.org, was last updated in 2003.

What makes the jargon file so important is that it preserves something that's normally hard to come by. There's been endless amounts of ink spilled over big events in the history of computing. Figures like Bill Gates or Steve Jobs have multiple biographies covering their life stories. Add to that all the actual hardware and software lying around, and it's actually somewhat easy to chronicle all the big events. All these things are centrally preserved, so you don't really have to go hunting for that one scrap of a note that Bill Gates wrote in the mid-80s. Instead, you can just go grab a book that focuses on Microsoft in that era.

When we get below that high level of visibility, we can run into some serious issues with sourcing. Computer science as a field wasn't developed by a handful of people. It took masses. But those masses aren't usually chronicled in the same way as high-profile figures. Most researchers didn't donate their notebooks to university archives. User group minutes were usually just thrown in the recycling bin, and online forums and messages don't really start being relevant until much more recently. This means that trying to put together less well-known stories can get kind of difficult, and a lot of the culture around these stories is either lost or really, really difficult to find information on. That's where the jargon file sweeps in to save the day. Well,

at least somewhat. It gives a picture of the hacker's subculture during a pretty wide span of time. I guess this may be a good time to actually address the terminology here. Hacker didn't originally mean some malicious actor that broke into computers, although breaking and entering was sometimes part of it. The jargon file has a few different definitions for the term. I think the most relevant here is, quote, a person who enjoys exploring the details of programmable systems and how to stretch their capabilities, as opposed to most users who prefer to learn only the minimum necessary. RFC 1392, the internet user's glossary,

usefully amplifies this as a person who delights in having an intimate understanding of the internal workings of a system, computers and computer networks in particular. Hackers as malicious actors is really a more recent connotation, although the file does admit to some malicious hackers. More properly, it's a collective term for folk that have become obsessed with computers and really just want to see what they can get machines to do. Hackers in this sense are also a part of a subculture, with a set of shared ethics and norms. The jargon file chronicles that culture. They're open to new ideas,

they're ready to cause mischief, and always looking to snag some new hardware. To be 100% clear, this isn't the kind of sourcing that's perfect for specifics, but it does add flavor that's hard to come by otherwise. How did hackers feel about IBM? Well, they thought it sucked. otherwise. How did hackers feel about IBM? Well, they thought it sucked. What toppings did hackers at Carnegie Mellon prefer on pizza? Simple, pepperoni and mushrooms. What does a hacker prefer to wear? Anything but a suit. The jargon file also holds a special place for me more personally. In high school, right around the time I was really getting deep into programming, I chanced across a third edition copy of the text. It should come as no surprise that I've always been a bit of a nerd myself,

and the jargon file really resonated with me. It made me realize that programming could be more than just hammering out code. There's a certain aspect of camaraderie and playfulness to it. I still have that dog-eared copy sitting near my desk today. But out of everything that's held within its pages, my favorite part has always been the hacker folklore section. And as I've been working on Advent of Computing more and more, I've realized just how special that appendix really is. When you get down to it, there isn't that much folklore surrounding computers. Partly this is because computers just aren't really that old. If we want to be really generous,

maybe a hundred years or so? What we do have is usually short and pretty spread out in the sources. Often, this kind of stuff comes down to us as either throwaway lines in interviews or later writings. The Hacker Folklore Appendix is one of the few collections of these types of tales, or rather some of the longer ones, and with archived versions of the jargon file, we can start to put these stories in the proper chronological context. Now, all that aside, I just really like these folklore stories. Over the years, I've read them countless times and always wondered how real they actually are, how much is lore, and how much of it is

things that folk actually did. In this episode, I'm going to share a selection of these stories with you and try to find out just how accurate they are. Are these events passed down as folklore based in actual fact, or are they just digital bedtime stories to tell to hopeful hackers? To that end, we will be determining if some crafty hackers really did sneak a computer into a hospital, how a computer mishap may have ended a monkey's life, and just how much magic actually exists in a server room. Let's start off with a quick trip to the emergency room. This story is called TV Typewriters, a tale of hackish ingenuity. Here's a true story about a glass TTY. One day, an MIT hacker was in a motorcycle accident and broke his leg. He had

to stay in the hospital quite a while and got restless because he couldn't hack. Two of his friends therefore took a terminal and a modem for it to the hospital so that he could use the computer by telephone from his hospital bed. Now this happened some years before the spread of home computers and computer terminals were not a familiar sight to the average person. When the two friends got to the hospital, a guard stopped them and asked what they were carrying. They explained that they wanted to take a computer terminal to their friend, who was a patient. The guard got out his list of things that patients were permitted to have in their rooms. TV, radio, electric razor, typewriter, tape player.

No computer terminals. Computer terminals weren't on the list, so the guard wouldn't let it in. Rules are rules, you know. Fair enough, said the two friends, and they left again. They were frustrated, of course, because they knew that the terminal was as harmless as a TV or anything else on the list. Which gave them an idea. The next day, they returned and the same thing happened. A guard stopped them and asked what they were carrying. They said, this is a TV typewriter. The guard was skeptical, so they plugged it in and demonstrated.

See, you just type on the keyboard and what you type shows up on the TV screen. Now the guard didn't stop to think about how utterly useless a typewriter would be that didn't produce any paper copies of what you typed. But this was clearly a TV typewriter, no doubt about it. So he checked his list. A TV's all right. typewriter's alright. Okay, take it on in. This one has all the hallmarks of a classic hack. Some crafty computer nerds pull a fast one on an unsuspecting party, and in the end, no one actually gets hurt and future hackery ensues. With a little digging, I've managed to narrow down the date of this supposed event. You see, a TV typewriter isn't just some prank device that was dreamed up to trick unsuspecting rubes. It's actually a very early personal computer. Plans for the device were published

all the way back in 1973, and the jargon file even has a footnote about it after the story. file even has a footnote about it after the story. If we assume that most people knew about computers by 1979-1980, then the story probably took place in that middle to late part of the 70s. The first terminal the crew tried to sneak in was probably a glass teletype, a terminal with a built in CRT display. So to complete the picture, try to imagine some college kids, probably with spectacles, little scrawny, trying to lug a 50 plus pound box into a hospital without being seen. I'm of the pretty firm opinion that this probably happened. I mean, accidents happen, people get injured, and people are always trying to get cool things into hospitals. You get bored laying around in bed all day. So what about the second terminal, the TV typewriter that made it into the hospital proper?

It turns out that this is just the kind of project a hacker of the era couldn't really resist. The first quote-unquote real personal computer is usually pegged as the Altair 8800. It was announced in 1975. The Altair holds this distinction because it was the first computer a consumer could buy pre-assembled, at least for a reasonable price. You placed an order, waited for a week, probably more, and eventually got a box ready to plug in and use. But there were earlier options for those with the proper skills. Rough designs and kits for small computers have been circulating for a number of years.

The TV typewriter was the earliest of these DIY options. Don Lancaster was the mind behind this computer. Lancaster was an electrical engineer who had worked at a long series of firms, the most high profile among those being Goodyear Aerospace. And he readily admits that he took the job at Goodyear as a way to dodge the draft during the Vietnam War. In that era, aerospace engineers were actually exempt from forced service. And while his work at Goodyear was interesting, that wasn't actually Lancaster's passion. You see, Don was a hacker.

During his off hours, Lancaster tinkered with hardware projects. He had a fascination with electronics from a really young age, and was especially interested in finding ways to get things built on the cheap. In 1963, he hit upon an outlet for this creative drive. His most recent project was a color organ. It's a device that turns sound into a psychedelic light show. Lancaster really liked the results. It was a satisfying project to build, and it showed off some smart handiwork. The problem was, this wasn't really the sort of thing to share around the office. Engineering firms don't usually

care about musical light shows, although maybe that should change. So Lancaster found another way to share his exciting project. He wrote up a formal design and tutorial for his color organ and sent it off to Electronics World magazine. By April, his article hit print and a royalty check showed up in the mail. This was the start of something new. As Lancaster put it, quote, Even forgetting about the incredible ego trip,

there was something utterly magic about getting paid lots of money to do what I thoroughly enjoyed anyhow, and thus began a long career of writing technical stories and papers. End quote. Now, his hobby was suddenly much more. People actually liked what he was building. Even better, he could make a buck sharing his work. Lancaster wouldn't quit his day job, but publishing projects and papers became a larger side gig for him. This put Lancaster's work at the center of a really new and emerging scene. This put Lancaster's work at the center of a really new and emerging scene.

Up until the internet, there were really few ways to get new information about the latest technology. If you were a researcher, a student, or an engineer at a big firm, then you actually had a line for direct updates. But for everyone else, your options were much more meager. You could go to clubs or hobbyist meetings in your area, which often had speakers and workshops. This was a great way to get in on new developments, but you had to be near other hobbyists. As someone who's spent a large amount of his life out in rural-ville, I can tell you that a lot of us aren't near other hobbyists. The other, arguably more accessible option was to pick up an electronics magazine. As computers started to get smaller and cheaper, and as we approached the first real microprocessors, this meetup and magazine pipeline would drip-feed new technology to early adopters.

Lancaster's articles were one piece in this larger picture. This brings us up to 1973 and Don's most influential article. It was simply titled TV Typewriter. This latest project was inspired by his normal job. One of the Goodyear projects was to build up a million-dollar 12-megapixel display system that a hotshot pilot would supposedly thoughtfully scrutinize while in the middle of a dogfight. I asked myself the obvious question, can I trim cost a tad on this by cutting a corner here and there and drop that price to $99? End quote. The answer was, somewhat surprisingly, yes. And while Lancaster's $99 version would be markedly less sophisticated, it ended up being a lot more influential. The TV typewriter is really a strange beast. On its own, all it can do is

display a character on a TV screen. But its guts, and more importantly, how you can expand the machine, that's where the magic is really at. I said earlier that the TV typewriter was one of the earliest home computers, and... well, that's mostly true? It isn't actually a computer. It was designed before Intel released their first microprocessor, and on its own, a TV typewriter can't do any computing. Basically, the TV typewriter works something like this.

It has onboard memory. You can use a few pins to read and write to that memory. There's a dedicated input for a keyboard and a little bit of circuitry to handle that. At regular intervals, the memory is read, converted to a series of characters, and then output as a TV signal. Simplicity itself. But within that simple formula are some really smart cut corners, and room for a lot of changes. The TV typewriter doesn't have a processor, but it also doesn't have normal memory chips. In 1973, a RAM chip was still pretty expensive. To keep the machine cheap, Lancaster came up with a pretty interesting solution. All things considered, the typewriter doesn't actually

need that much memory, only enough for each character to be displayed. So Lancaster rigged up a recirculating memory buffer using cheap shift registers. How this works is actually pretty wild to me. A shift register is a chip that can hold a stack of data. Basically, you put a number in and it'll store that number until you hit a toggle. Then it outputs the stored value. That one element is pretty simple to build, so you can get chips that have a whole lot of these registers chained together. The TV typewriter used one of these chips with a total of 512 chained registers.

It's storage, but it's not random access storage. You can't tell a shift register where you want to store a number. You just give it a new one to add to its list or pop off the end of that list. The trick Lancaster used was to recirculate that data, so under very specific circumstances, it acted kinda like RAM. As each character was being generated for the TV, it was shifted out of the register, then read into a character generator, and finally pushed back into the register. Think of it as a binary Ouroboros, a chip eating its own pins, if you will. Then when

a character needs to be added back into memory, say, when a user hits a key, that signal gets timed out such that it's dropped into the right place in this flow of data. Since the TV signal refresh rate is so high, to the user, this arrangement acts like RAM, but it only costs a few cents. The other trick that made the TV typewriter such a big deal is its expandability. The circuits and ports are designed such that it's easy to add in new components. More memory can just be added if needed. Peripherals can be connected, you can even wire up a tape recorder to store pages of

typed text. Most importantly for us, the TV typewriter could be connected to a modem. This made the device the cheapest terminal money could buy. Or, in the case of our story, the easiest way to sneak a terminal into a hospital ward. Lancaster's 1973 article turned out to be a really big hit in the hobbyist community. Not only does the article describe how to build the TV typewriter, it also describes how the entire thing works, from the recirculating shift register to the TV output board, character generator to data flow. Everything is capped off with a complete parts list and layout to etch your

own circuit boards at home. In the next few years, more literature about the TV typewriter would hit shelves. Improved designs were published and saw wide circulation. In 73, Lancaster wrote the TV Typewriter Cookbook, an almost 400-page tome of projects and upgrades for the humble typewriter. Tucked away in the book were full plans for how to connect up a modem to your TV. Altogether, this made for an irresistible project for hackers. The combination of smart design, extendability, and easy availability was perfect. Plus, it was small enough to get into a hospital, so, you know, ups for that. Notably, Lancaster doesn't provide designs for a case in his article. This was left up as an

exercise for the reader. From what I've seen, most TV typewriters ended up in small wooden boxes with a keyboard mounted on top. To the untrained eye, it would have looked very much like an electric typewriter, just with a TV output instead of a paper feed. As far as our first story goes, I think the tale of the TV typewriter is 100% real, or at least it's realistic. It covers a real device, and most importantly, a machine that hackers would have been enthralled by.

This next story takes a bit of a turn for the dark, and has some pretty strange background. The Dragonfile is very much a living document. It sees updates at somewhat spontaneous intervals. Looking through these different versions, we can see how the lexicon starts to shift, and how hacker culture slowly changes. The folklore appendix is a bit of an exception. It was added in the 1990 version of the text. After a few years of flux, it reached its current state. But the earliest version was vastly different. It had one story, Mabel the monkey. In subsequent versions, that story disappeared, eventually being partly incorporated into one of the definitions in the main lexicon. So you won't see this story

in the appendix to a modern version of the jargon file. And just as a quick note, in this text, PM stands for preventative maintenance, as in trying to fix problems before they arise. Anyway, I give you our second tale of the evening, The Untimely Demise of Mabel the Monkey. Appendix A, The Untimely Demise of Mabel the Monkey, a cautionary tale. The following modulo, a couple of inserted commas and capitalization changes for readability, is the exact text of a famous Usenet message. The reader may wish to review the definitions of PM and Mount in the main text before continuing. before continuing. Date, Wednesday, the 3rd of September, 1986. From Art Evans. Subject,

always mount a scratch monkey. Two, risks at csl.sri.com. My friend Bud used to be the intercept man at a computer vendor for calls when an irate customer called. Seems one day, Bud was sitting at his desk when the phone rang. Bud! Hello! Voice! You killed Mabel! Bud! Excuse me? Voice! You killed Mabel! This went on for a couple of minutes, and Bud was getting nowhere. So he decided to alter his approach to the customer. Bud, how did I kill Mabel? Voice, you PM'd my machine! Well, to avoid making a long story even longer, I will abbreviate what happened. The customer was a biologist at the University of Blah-Buddy-Blah, and he had one of our computers that controlled gas mixtures that

Mabel, the monkey, breathed. Now, Mabel was not your ordinary monkey. The university had spent years teaching Mabel to swim, studying the effects that different gas mixtures had on her physiology. It turns out that the repair folks had just gotten a new calibrated power supply, used to calibrate analog equipment, and at their first opportunity decided to calibrate the DA converters in that computer. This changed some of the gas mixtures, and poor Mabel was asphyxiated. Well, Bud then called the branch manager for the repair folks. Manager. Hello? Bud.

This is Bud. I heard you did a PM at the University of Blabbity Blah. Manager. Yes, we really performed a complete PM. What can I do for you? Bud, can you swim? The moral is, of course, that you should always mount a scratch monkey. There are several morals here related to risks and use of computers. Examples include, if it ain't broke, don't fix it. However, the cautious, philosophical approach, implied by, always mount a scratch monkey,

says a lot that we should keep in mind. Art Evans, Tartan Labs. Horror aside, let's take a second to look at this text. As written, this is a cautionary tale about protecting irreplaceable components. Also about good communication between teams and why we really shouldn't trust computers with anything that can be damaged. Think of it as a modern rendition of a fable. You have a preventable disaster followed by a good moral. But the question is, did this actually happen or is this only a fable?

And really, would this make Mabel the monkey the first victim of a computer malfunction? I'd like to think not, but this is actually a pretty hotly contested story. It has plenty of arguments both for and against it, so there must be at least something going on here. Almost immediately, we actually run into conflicting reports. That masterful reading was one of the earliest sources I can find, a snippet reportedly taken from an old Usenet post by Art Evans. In that telling, Mabel died as a result of a failed air regulation system.

Jump forward in time, and the story is incorporated into the definition for scratch monkey in the jargon file. Later tellings in the file are a little more abridged. But it says that Mabel is also connected to some electrodes to monitor their brain waves. It says that Mabel is also connected to some electrodes to monitor their brainwaves. Supposedly, a test program sent deadly current down the leads and zapped poor Mabel. So that introduces our first confusion into the story. However, the updated version in the jargon file does give us some clues for our own search.

The entry claims that this University of Bloddy Blah was actually the University of Toronto, that the computer in question was a DEC-VAX mainframe, and that it took place in either 1979 or 1980. Supposedly, these details were acquired after an interview with the sysadmin in question, but doing some digging, we run into another strange twist. Tracking back the details of this updated version lead to a series of Usenet posts that reference an earlier post written by ESR, one of the compilers of the jargon file. Supposedly, in 1987, ESR tracked down the party involved in the event. I have the name, but to protect the innocent, let's call them HackerX.

The story ESR was told ended up circulating around Usenet as early as 93, maybe via other mediums at an earlier date, but I don't have archival copies of those handily available. Eventually, it gets adapted into the jargon file and turns into the modern telling. But this account from Hacker X is a lot different from the later entry inside the lexicon. The story isn't about Mabel. Instead, it was reportedly called the Great Dead Monkey Project, which is a touch more ominous. In the late 70s, Hacker X was a programmer working for the University of Toronto's zoology department. There, they had developed a program that allowed researchers to use a mainframe to manage animal experiments.

Some custom hardware was set up to use a series of digital-to-analog converters to handle feeding or releasing chemicals into enclosures. There were also banks of analog-to-digital converters used to take readings and samples. Everything fed back to a PDP-11 mainframe, and eventually data was compiled onto a beefier VAX machine for analysis. So far, no monkeys. The account HackerX gives says that the zoology department mainly worked with bugs and some rodents. The furthest this went were some rats with a few electrodes wired into their brains. The heaviest task here would have been data acquisition, hence having a separate machine just to handle that. The setup was probably similar to

an EEG, which would produce enough data that a mainframe would be a must. Sometime in 1979 or 1980, the medical department got their hands on a new machine, a vax unit that was roughly similar to the one that Hacker X was working on. And this is where monkeys enter the picture. You see, the zoo department didn't have a primate lab, but the medical department most certainly did. As near as I can tell, they performed experiments on primates from the 1970s up until 2012. Crucially, they carried out cognitive research on some of these monkeys, implanting electrodes directly into their brains to collect data. So when they got a new computer, the department was understandably really eager to get it hooked up to their primate lab.

Luckily, there was someone on campus that could help out. The zoo department lent out HackerX to get everything set up. But it sounds like there was a bit of hackery going on with the install. The zoo department actually had multiple mainframes. A PDP-11 handled all data acquisition, which sat in front of the main computer. My best guess here is that they had to do this because they needed some way to multiplex or demultiplex data, so they could have a lot more leads and different inputs coming in that needed to get consolidated and sorted out before anything was worked on.

The medical department just had the one VAX, so they couldn't shuttle data through another machine. Somehow, HackerX realized that they could use a spare disk drive to interface with this array of electrode wires. It sounds like the hookup worked in such a way that reading from the disk drive would actually be reading from some wires hooked into some monkey brains down the hall. For, hopefully, obvious reasons, this is the kind of setup where you only ever want to read data. You do not want to try to perform a write onto a monkey.

That could do something awful. So to finish things up, HackerX threw in an empty disk with the read-only tab taped shut. That way, the computer couldn't try to write out to a pile of monkeys. We're told that this setup worked, at least until the mainframe crashed late one night. A technician, possibly the bud from the initial reading, was called out to see what was wrong. Unknowingly, they had stepped into a very precarious situation. Usually in this circumstance, Hacker X would have been called in, but for whatever reason, the technician was working alone. While troubleshooting, they noticed that they couldn't write to one of the disk drives,

so they found the errant drive, popped out the strange taped-up disk, and re-ran a diagnostic program. As the diagnostic ran, the VACs tried to write to the monkey's disk drive. The outbound signal traveled through the drive, over a series of tried to write to the monkey's disk drive. The outbound signal traveled through the drive, over a series of wires, up to the primate lab, and then it went fatally into the brains of some unsuspecting monkeys. Hacker X claimed that this induced seizures, killing three monkeys and paralyzing a few more. According to a later source, it wasn't long before the Humane Society and the police descended on campus. Once again, we're looking at a really grisly tale. If this

is true, then animals died in an awful way. Some ingenuity and quick thinking worked until it didn't. And when the worst case scenario came, it led to the death of three monkeys. No Mabel, no swimming monkeys, and no gas mixtures. The sourcing on this story also seems reliable. I've been able to confirm that HackerX did program Vax mainframes at the University of Toronto in the right time period, But I have some issues with this story. Actually, I have issues with both tellings of this monkey story. According to HackerX, the University of Toronto had previous run-ins with the local humane society. So, you know, the Great Dead Monkey Project should have been the biggest news story of the year.

Dead Monkey Project should have been the biggest news story of the year. Even the earlier Mabel story would have been a really big debacle. But I haven't been able to find any news clippings about either incident. Maybe I'm looking in the wrong places, but there should be something. Instead, everything just keeps pointing back to a copy and pasted Usenet post. Looking through the University of Toronto's archive also leads to some more questions than answers. You can find every thesis published at U of T, so it should stand to reason that there'd be something about swimming monkeys. There are works from the medical department dealing with primate research, specifically using implanted electrodes to monitor brain activities while monkeys do various things. That lends a little

credence to the Great Dead Monkey Project. However, as I was saying, there's nothing about swimming monkeys, swimming primates, or any similar permutation of those words in the university's archive. So there were some researchers working with electrified monkeys, but probably no Mabel the Swimming Wonder Monkey. And as someone who's been in academics before, it would be really weird if they just had a swimming monkey that they researched and never published about. To me, this all smells like an urban legend. There just aren't any corroborating sources besides copy-posted stories online. Or, if there are corroborating sources, they are very well hidden from me. The spread of these primate stories is also suspicious. Email threads and old Usenet posts are interesting but not always the

most accurate sources. Basically, for something that should be corroborated, it's good to have something that corroborates it, you know? So why did this spread so far and why is it still believed in some circles? I think this is the kind of folklore that confirms cultural beliefs. In this case, it cements part of the hacker mindset. The moral is always written as never forget to mount a scratch monkey, as in, if you're going to do something that might be dangerous on a computer, make sure to hide away anything you can't replace. But I think there's another one here. That is, non-hackers can cause disaster when treading in a hacker's domain.

This becomes especially clear in the Great Dead Monkey version of the story. The ethics of animal experimentation aside, everything was going fine. The mainframe crashed, no monkeys were harmed, and no monkeys would have been harmed. Things would have worked out if the right people were called in, but instead some unnamed technician arrived on the scene. They didn't know the precarious masterpiece that they were dealing with, and that led to disaster. The gruesome sci-fi element of a computer problem leading to accidental death just makes the story all the more enticing. After that,

I think it's time for a bit of a palate cleanser to end things off, and I've left my favorite story for last. This one isn't gruesome, it isn't grisly, it's just plain fun. I give you a story about magic. Some years ago, I, GLS, was snooping around in the cabinets that housed the MIT AI Labs PDP-10 and noticed a little switch glued to the frame of one cabinet. It was obviously a homebrew job added by one of the lab's hardware hackers. No one knows who. You don't touch an unknown switch on a computer without knowing what it does, because you might crash the computer. The switch was labeled in a most unhelpful way.

It had two positions, and scrawled in pencil on the metal switch body were the words MAGIC and MORE MAGIC. The switch was in the more magic position. I called another hacker over to look at it. He had never seen the switch before either. Closer examination revealed that the switch had only one wire running to it. The other end of the wire disappeared into the maze of wires inside the computer. But it's a basic fact of electricity that a switch can't do anything unless there are two wires connected to it. This switch had a wire connected on one side and no wire on its other side. It was clear that this switch was someone's idea of a silly joke. Convinced by our reasoning that the switch was inoperative, we flipped it.

The computer instantly crashed. Imagine our utter astonishment. We wrote it off as coincidence, but nevertheless restored the switch to the more magic position before reviving the computer. A year later, I told this story to yet another hacker, David Moon, as I recall. He clearly doubted my sanity or suspected me of a supernatural belief in the power of this switch, or perhaps thought I was fooling him with a bogus saga. To prove it to him, I showed him the very switch still glued to the cabinet frame, with only one wire connected to it, still in the more magic position. We scrutinized the switch and its lone connection and found that the other end of the

wire, though connected to the computer wiring, was connected to a ground pin. That clearly made the switch doubly useless. Not only was it electrically non-operative, but it was connected to a place that couldn't affect anything anyway. So we flipped the switch. The computer promptly crashed. This time we ran for Richard Greenblatt, a longtime MIT hacker who was close at hand. He had never noticed the switch before either.

He inspected it, concluded it was useless, got some diagonal cutters, and diked it out. We then revived the computer, and it has run fine ever since. We still don't know how the switch crashed the machine. There's a theory that some circuit near the ground pin was marginal, and flipping the switch changed the electrical capacitance enough to upset the circuit as millionth of a second pulses went through it. But we'll never know for sure. All we can really say is that the switch was magic. I still have that switch in my basement. Maybe I'm silly, but I usually keep it set on more magic. One of the reasons that I love this story so much

is that it falls into a particularly fun and, sadly, very relatable category of computing sagas. That is, hackers getting wrecked by their own machines. It's not a story about magical skills or the magic of a well-placed line of code. The magic here is something that a roomful of experts just can't understand. But this should leave you with a question. Why would anyone leave the Switch set to more magic? Computers are supposed to be logical machines. They carry out deterministic tasks. And programmers should be logical people. The story about magic speaks to an apparent contradiction that surrounds computers. You see, if you use a computer long enough, you actually start to become a little superstitious. This is something that I have

plenty of first-hand experience with. Programmers aren't always the most rational, and I have a bit of a pet theory about that. Computers just don't work like people. Machines are supposed to be cold, logical devices. That's true all the way down to their silicon core. But humans don't function like that. We're squishy bags of illogical thought. So programming computers can turn into a bit of an exercise where you're trying to fit a square peg into a round hole. Even with fancy new programming languages, there's still a part of the discipline that feels somewhat supernatural.

So when things go wrong, it's easy to look to supernatural forces. Around my office, we have a certain recurring joke about this. When something breaks or goes horribly wrong, especially if only one person can spot the problem, we tend to blame it on ghosts. Someone can't log into a server? Ghosts blocked your IP address. Database entries disappearing? Well, the ghosts must be learning how to use SQL. We don't really think our computers are haunted, but sometimes it feels like that. Computers are complicated enough that

a single programmer doesn't always know why exactly something is happening. It can seem like a little bit of magic in everyday life. This kind of feeling isn't without precedent. Unexplained errors can crop up for seemingly wild reasons. Perhaps unsurprisingly, this has been going on since the very earliest days of the discipline. Most likely the earliest example is the quote-unquote first bug found in a computer. Grace Hopper often recalled a story from her time working on the Harvard Mark II computer, although it's important to note here that Hopper wasn't the one to actually find the first bug. The Mark II was one of the first computers to fully function.

It was up and running in 1945. One of the weird quirks with this early mainframe was that it wasn't totally electronic. Instead of vacuum tubes, it used electromechanical relays to perform logic operations. This matters here because relays need to actually move to function. When an electrical impulse is sent into a relay, a small magnet will pull down a contact, When an electrical impulse is sent into a relay, a small magnet will pull down a contact, thus completing a circuit. The problem with relays, and the reason they didn't show up in that many computers, is that they're really slow and unreliable.

Since a contact has to move, well, there's a bit of a hard limit on the speed of operation. And since things are moving around pretty often, wear and tear become a factor. But there's another issue with relays, one that researchers at Harvard didn't expect to find. On September 9th, 1947, the team working on the Mark II noticed some strange errors cropping up. Realizing the problem was with the hardware itself and not the software, someone hopped over to the banks of relays to see what exactly was up. After careful examination, the culprit was identified. A moth had gotten stuck in one of the computer's relays. After cleaning out the dead moth, the Mark II returned to normal

operation. Somewhat amused at their discovery, one of the researchers taped the bug into the logbook for the day, labeling it as the, quote, first actual case of a bug being found. As Hopper tells it, this is how bug started entering more common computer parlance. The word had been used to describe problems in other fields, but the discovery of a real bug, well, that really made the term stick for computing. The story of the moth in the relay shares a few common elements with a story about magic. Hopper's earlier tale isn't so much a prank, well, unless the moth was a really dedicated prankster, but it does chronicle an inexplicable issue caused by something random, something that is dare I say magical. It's the kind of error that

no one can account for. There are very practical solutions. Covering relays better or spraying bug poison could help, but those actions also push a little bit into the realm of magical thinking. Imagine explaining that to a new researcher in the lab. Oh, well, why do we spray pesticide around the mark too before an important calculation? Well, let me tell you a story about back in the day, before we knew this one trick. Honestly, when these kinds of bugs pop up, it can be easier to just fix them, have a good laugh, and move along as quickly as possible. In the book The Devouring Fungus, Carla Jennings observed that, quote, humor is one way the programmer learns to cope with the computer's frustrating magic, end quote. And there's a lot of truth to that. Programming is

really rewarding, but it can also be hard and really frustrating work. There's a reason that not everyone is a programmer. Making our trials and tribulations into jokes does help ease the pain a little bit. Sometimes that verges into the magical. Does keeping the switch set to more magic really do anything? Probably not, but hey, it doesn't hurt to indulge yourself a little. The other factor that a story about magic brings to mind, at least for me, is the idea of the personification of computers. A switch that is functionally useless but does function against all logic, well, that sounds like a very human trait. When we run into these kinds of twists of logic inside otherwise logical machines, I think we see a little bit of ourselves.

Bugs and magical switches are a few prominent examples, but this goes deeper than just idle thinking. This feeling of personhood has been folded back into computers themselves. Most superficially, it shows up in how we talk about computers. A PC can get infected with a virus, just like a human. Once things get too far out of whack, a computer can die, just like one of its creators. But this phenomenon is more than just talk. It also shows up in more formalized places. For instance, did you know a computer can panic? Seriously, that's a very real thing. Well, at least for some systems, systems running Unix and Unix-like operating systems.

When a catastrophic failure occurs on one of these computers, Unix raises what's called a kernel panic. The computer grinds to a halt, and an error code is thrown up on screen. This actually has a pretty straightforward origin. Prior to creating Unix, Dennis Ritchie and Ken Thompson were part of a similar project, an operating system called Multics. In the late 60s, the two left the project and ended up pursuing their own work, which eventually led to Unix. The important distinction is that Multics was born from a big government-funded project. Unix was a side project thrown together by two people. Both were working towards the same goal of a practical,

time-sharing operating system for mainframes, just from slightly different angles. And both contended with similar problems, some among those being errors and crashes. The two operating systems weren't strictly competitors, but just similar projects. A lot of the programmers who worked on Unix knew or had even worked with Multics programmers. Van Vliet was one such programmer on the Multics team. When addressing the differences on the two projects, he recalled a conversation he had with Richie that went something like this. Quote, I remarked to Dennis that easily half the code I was writing in Multics

was error recovery code. He said, we left that stuff out. If there's an error, we have this routine called panic. And when it's called, the machine crashes, and you holler down the hallway, hey, reboot it. End quote. This is a bit of a twisty way to get to the punchline, but modern Unix systems still raise kernel panics. As in, when something goes wrong, like really, really wrong in your code, you can call out to panic. The computer will then panic. That goes down the line, and somewhere nearby, a systems administrator will also panic and bring the computer back up. It's a similar course of events as a story about magic, just more well-documented. Different systems have different takes on this kind of error.

At some point, there just isn't anything a program can do, so it has to crash. Panicking is Unix's flavor of disaster. The corollary on Amiga computers was guru meditation. Once again, this is a case of programmers reflecting a little bit of themselves into their creations. While the Amiga was being developed, its programmers ran into the same issues that every programmer faces. Errors appear, crashes happen, small bugs can become bigger bugs, and eventually everything can just go haywire. Around the Amiga offices, though, they didn't panic. Instead, they meditated. You see, one of the previous projects that they built

was a device called a joyboard. It's essentially a joystick in the form of a board, something like the much later WeBalance board. A user would either stand or sit on the joyboard, then control it by tilting around on the board. Outside the company's offices, it was used for computerized skiing, snowboarding, surfing, that kind of thing. Board-based sports. But there was also a program the team wrote up called the Meditation Game. In this game, a user would sit on the board as still as possible for as long as possible. The longer you could practice stillness, the higher your score. The meditation game was actually really popular inside the Amiga team. When stuck on a particularly frustrating problem, programmers would stomp away from their desks, plop down on a joyboard, and engage in some

computer-supervised meditation. The practice was so common in the office during the development of the first Amiga computer that it showed up in error codes. On a crash, the system displays a message saying, Guru Meditation, followed by an error number. Hey, meditation worked for the programmers who made the Amiga, it may just come in handy for a computer's user. So, do I think a story about magic is real? Honestly, I believe it.

It's a small enough thing that there wouldn't be any corroborating sources, but for this one, that doesn't bother me. Sometimes computers can act in inextricable ways, and sometimes it's best to take that in stride. If you ever run into a computer with a strange switch on it, even if it looks out of place, it doesn't hurt to leave it set to more magic. Alright, that does it for this episode. This has been a bit of a departure from my usual fare, so I hope you've enjoyed the change of pace. If not, then don't worry, I'll be back to the usual come next episode. And I actually have a lot of people to thank and cite this time.

First comes Eric S. Raymond over at Catbee.org. That's where the most up-to-date version of the jargon file lives. All the quotes and stories from the file, sans the early Mabel the Monkey reading, came from the jargon file version 4.4.7. You should have also noticed all the not-Sean voices this episode. Those came courtesy of some of my fellow podcasters. The recording of the TV typewriter story was read by Randall Kendig of the Floppy Days Vintage Computing Podcast. You can find his show at floppydays.com or anywhere podcasters are served. The untimely

demise of Mabel the Monkey was read by Charles Edge of the History of Computing podcast. You can listen to more of him anywhere you listen to podcasts or at thehistoryofcomputing.libsyn.com. And finally, A Story About Magic was read by Sebastian Major of Our Fake History.

That podcast is also found anywhere audio is dealt, or over at ourfakehistory.com. And really, I can't thank these three enough for helping me make this episode come to life, so why not head over and give them a listen? Last, but certainly not least, I want to thank all of you listening here. This year has been a bit crazy for all of us, but it's also had some wonderful twists. Advent of Computing has grown more than I ever expected, and I'm constantly blown away by all the support my listeners show for the podcast. You've helped Advent of Computing get bigger and better than it was at the start of the year, and I'm looking forward to making the show even better

in 2021. If you want to come along for more of the ride, then stay tuned to my feed. And if you want more, I've started putting up some exclusive content on Patreon. Right now I have two mini-episodes up, one on the MIL-STD-1701 specification, and another one on OEM builds of Microsoft DOS. I'm planning to add new content on a semi-regular basis come the new year. I've also been slowly adding to my merch shop over on TeePublic. Most recently, I've thrown up my ENIAC episodes cover art for shirts, mugs, or really anything else you would ever want it printed on. You can get links to everything from my website, adventofcomputing.com. I'll be back in

two weeks time with the next installment of Computing's Past. Until then, if you want to get in touch, you can reach me on Twitter. I'm at adventofcomp over there. And as always, have a great rest of your day.