Friday, June 03, 2005

Fictional systems

In my ongoing campaign to demonstrate that successful computer scientists have interests outside of computer science, I will use this issue of OS Junkie to introduce you to some of my favorite fiction, written mainly by and about... computer scientists. So much for diversity of interests. However, I find that I derive a strange sense of self-worth from reading fiction in which the main characters identify themselves as "programmers-at-arms" and the like. Professional computer-wrangling, while vital to the modern world as we know it, is still an arcane, out-of-the-way occupation whose practitioners are viewed with good-natured incomprehension and pity by society at large.

This fiction about computer scientists, as you may have already inferred, falls under the heading of science fiction. "Ew," you cry, wrinkling your LCD-tanned nose, "Science fiction, that's low art, unfit for serious personages such as myself. In what little time I spare from the pressing my nose to the grindstone of Serious Science, I read real literature, such as Bridget Jones' Diary and the 10th novel in the Wheel of Time series." It is true - as in any genre, science fiction has its share of total crap. However, you, dear reader, have already self-selected yourself as a person very likely to enjoy what I am about to recommend, by the virtue of reading a weblog about... systems papers. (Really, you ought to be ashamed of yourself!)

The first author I recommend is Charles Stross. I heard him speak at a panel on the Singularity at the 2003 World Science Fiction Convention and bought the only publication of his available on on the strength of about 5 minutes declamation. I knew Stross was my kind of writer when I read the following, from "Antibodies" (part of the Toast short story collection):

I was elbow-deep in an eviscerated PC, performing open-heart surgery on a diseased network card, when the news about the traveling salesman theorem came in. Over on the other side of the office John's terminal beeped, notification of incoming mail. A moment later my own workstation bonged.

"Hey, Geoff! Get a load of this!"

I carried on screwing the card back into its chassis. John is not a priority interrupt.

I think this was one of the all-too-rare occasions when I severely irritated my seatmate on the plane by gasping and giggling repeatedly throughout the story. It was like someone plugged into my brain and started beaming dreams directly into my cortex.

It gets better; Stross's best story (in my opinion) is available online: Lobsters. A good quote:

The box rings. Manfred rips the cover open and pulls out the phone, mildly annoyed. "Yes, who is this?"

The voice at the other end has a heavy Russian accent, almost a parody in this decade of cheap online translation services. "Manfred. Am please to meet you; wish to personalize interface, make friends, no? Have much to offer."

"Who are you?" Manfred repeats suspiciously.

"Am organization formerly known as KGB dot RU."

"I think your translator’s broken." He holds the phone to his ear carefully, as if it’s made of smoke-thin aerogel, tenuous as the sanity of the being on the other end of the line.

"Nyet–no, sorry. Am apologize for we not use commercial translation software. Interpreters are ideologically suspect, mostly have capitalist semiotics and pay-per-use APIs. Must implement English more better, yes?"

Perhaps the best part about Charles Stross's fiction is that it makes me want to go out there and create the future. Most fiction is escapist, about retreating into a fantasy world where, paradoxically, your inability to effect change allows you to let go of feelings of responsibility and enjoy the show. Even most science fiction falls into this category. But reading a Stross story hits me like a handful of Benzedrine, leaving me hyped up and ready to go found a start-up. I don't just want to see the future, I want to make it, starting now! Where's a keyboard and the nearest agglomeration of supergeeks?

I recommend starting with the Toast short story collection and moving on from there to The Atrocity Archives. If you find it worthwhile, email me (use Google); if you don't like it, especially email me. I'm curious to see the inside of a head that likes this blog but doesn't like Charles Stross's writing.

My next two recommendations require less introduction. Vernor Vinge, recent winner of innumerable Hugo awards, wrote about a programmer-at-arms (how I do love that title) in A Fire Upon the Deep and A Deepness in the Sky. Attempting to ascertain which of these novels is better leads to an interminable Emacs-vs-vi style argument among the cognescenti; I have concluded that it's a matter of personal taste (for me, A Fire Upon the Deep and Emacs). Neil Stephenson is perhaps already well known enough that I am wasting precious bandwidth and wear-and-tear on my carpal tunnels by even typing this, but perhaps one or two of my readers have not yet read Cryptonomicon, another novel that makes me want to run out and found a start-up.

And now, an open invitation to send me email about your favorite systems papers, leisure time reading, or hot new start-ups. I usually respond to most email; use of three syllable or longer words, traditional punctuation, and succintness will get you a response sooner. Discovery of my email address is left as an exercise for the reader.

Tuesday, April 26, 2005

QEMU and Queen

I attended USENIX General Technical Conference a few weeks ago, which inspires me to write about QEMU, "a generic and open source processor emulator which achieves a good emulation speed by using dynamic translation." Hm, you think, I know what an emulator is - that's like VMWare - and I know what open source is, but whatever do they mean by generic? It can run all programs compiled for x86?

QEMU is generic in the sense that it emulates many different processor architectures - x86, ARM, SPARC, PowerPC as of this writing, with work progressing on x86_64 and SPARC64. Traditionally, writing an emulator involves a lot of painstaking by-hand coding to translate the machine code instruction for the emulated machine into the appropriate instructions on the host machine. What Fabrice Bellard did with QEMU is harness the compiler and linker in order to generate the instructions for the host machine. Each target instruction is implemented by a small piece of C code, which does something like "ADD r1 to r2 and put the result in r3," which is then compiled into object code. At run time, the pieces of object code are then concatenated and massaged (using linker tricks) in order to emulate the full program. It's a beautiful misuse of the compiler and linker to quickly implement an emulator for one CPU on any other machine.

A full paper on QEMU was published as part of the 2005 FREENIX track. It explains in detail a multitude of neat optimizations used to make QEMU go faster. It's my favorite FREENIX paper; I hope you enjoy it as well.

I recently spoke to a women in computing group about what it takes to be a good computer scientist and they were startled to discover that I do things that don't involve computers (or even math!). Most of the truly successful and talented computer scientists I know have serious, time-consuming, and very artistic hobbies. Valerie Bubb does community theater and marathon bike rides, Armando Fox is an excellent classical and jazz pianist as well as interested in dancing and any number of other ostentatiously liberal arts-esque activities. My main hobby these days is SCA, a medieval recreation group, which provides any number of opportunities for odd artsy activities. Recently, my (awesome) boyfriend won the Crown Tournament of the Kingdom of the West (picture), and I will ironically be spending my weekends during the next 4 months as our local kingdom's paragon of Grace and Beauty - the "Queen." This is probably the most stereotypical thing I've done since I was 7 years old and posed for a photo in all pink clothing - pink velvet dress, pink shoes, pink socks, pink belt with big pink plastic heart-shaped buckle. At least I can smile while clenching my teeth.

Friday, March 18, 2005

Failure oblivious computing

As I continue to labor under the delusion that people find what I have to say interesting, I've decided to restart my (shudder) blog, originally titled "Confessions of an Operating Systems Junkie." (Perhaps in a few decades, when blogs are considered as normal as cell phones or small yappy dogs, I'll leave out the "shudder" part.) First, a quick recap of past episodes... In order to avoid the usual fate of blogs - e.g., random complaining about roommates leaving the dishes in the sink - the main theme of my blog is "Cool systems papers I've read lately," leavened with "Cool other things I've read lately" and very occasionally, "Cool things I've written lately."

While I spent the last few months primarily sleeping on planes and controlling the urge to throttle the sales creature on the other end of the phone, I also read a few systems papers. (Do I sound bitter? Heavens.) Today's cool systems paper is the utterly delightful Failure Oblivious Computing from Martin Rinard at MIT. A safe C compiler creates code that dynamically checks for out-of-bounds memory accesses and terminates the program; this converts, e.g., buffer overflow attacks into mere (?) denial-of-service attacks. Martin wondered what would happen if the compiler instead generated code to transparentally mask bad memory accesses - for a bad read, return some made-up data, for a bad write, silently throw it away. In a lot of cases, the answer is that the program behaves almost as if it had no bug at all, and better than either the safe C compiler case (program termination) or the normal C compiler case (successful security exploit).

Sounds crazy? Read the paper, you'll enjoy it even if you don't agree. Here's a little taste to whet your appetite. In failure-oblivious computing, writes are just thrown away, but how do you decide what value an invalid read should return? In his talk at OSDI 2004, Martin gave the sequence of return values as this: 0, 1, 2, 0, 1, 3, 0, 1, 4... This is because (a) eventually it will cycle through all possible values, allowing things like searches for a particular ASCII character to eventually succeed, and (b) 0 and 1 are the most common data values loaded by programs. This got a big laugh from the audience. In fact, Martin won the unofficial Best Talk award as judged by the Val Henson Laugh-O-Meter. The Laugh-O-Meter was inspired by a talk I gave at the Silicon Valley Linux Users Group a few weeks before. Somehow I managed to make the audience laugh about every 3 minutes while talking about... the history of UNIX file systems. Wild. With any luck, I can repeat the performance at the LUGOD this upcoming Monday night. Imagine what I could do if I were talking about an actually interesting topic!

Martin told me that the only reason he could think up failure oblivious computing was because he hadn't written any code for 10 years. Depressingly, I think he's right. On the other hand, I've only written a couple of test programs and a few scripts over the last 6 months, so perhaps I'm on the road to greatness as well.

If you're reading backwards, you've just hit the end of this blog. I have an earlier blog I wrote while I was at Sun:

Confessions of an Operating Systems Junkie

Hopefully they won't notice I've quit and delete it any time soon.