Rust is not fast


But Rust is slow. (And its type system hates you.)

Rust is slow because there is lots of hidden indirection ("smart dereferencing") and other hidden costs (ref counting, etc). In low-level C code I can look at a line of code and know roughly how many (slow) memory accesses are present. Not so in Rust.

Further, Rust's type system leads to extra unnecessary copying, just to get your code to compile without massive refactoring of the standard library. When writing rusty-turtle I found myself having to add ~ or @ pointers to my types (forcing extra layers of dereferencing) just to work around the type system. Further, the APIs have a genericity problem: there are lots of duplicate methods, since &-pointers aren't truely generic/orthogonal. (And you will find yourself duplicating methods in your own APIs as well, in order to be able to pass in parameters with different reference types -- or else just throw up your hands and wrap an extra @ layer around everything.)

The ownership type system also fights against typical APIs like find_and_insert for maps, since you don't know (before you do the find) whether or not you will be giving up ownership of the parameter (in order to do an insert). So you just copy the inserted value, always! Cycles are cheap, right?

Rust is also slow because it is not built to be parallel. The language is concurrent, but this is a word game: in the past few years the terms have been redefined such that "concurrent" is (roughly) non-blocking cooperative multitasking (such is implemented by node.js and GNU Pth), and "parallel" is reserved for actually doing more than one thing simultaneously (whether on separate CPUs or separate cores of a single CPU). Rust's memory model doesn't help: there is no shared memory, and ownership types make fork/join parallelism difficult. All inter-task communication is explicit message passing, with the races that entails. (Perhaps I'm spoiled: the Cilk work-stealing nano/microscheduler is my benchmark for speed.)

Some possible improvements:

  • Get rid of smart dereferencing; make it clear when performance is impacted by memory references.
  • Fix bugs with small objects/ABI limitations to avoid unnecessary parameter wrapping.
  • Make & pointers truely generic (or invent a new pointer which is) and do template expansion/method splitting to generate the proper specialized version of the method automatically (although this will exacerbate existing problems with code caching).
  • Better support fast refcounting/fast gc (update coalescing, generations).
  • Support fork/join parallelism and work-stealing.

This post is written from my experience with Rust in May 2013. Some of these problems are known, and some may eventually be fixed. But it makes me wonder what the language is really supposed to be good at. There are already plenty of slow safe languages.

JavaScript in asm.js (and a little rust)

Over on twitter, Tim Caswell mentioned, "I think high-level scripting language on top of something like rust.zero would make for an amazing OS." and that set me off a bit. Twitter isn't a great place to write a reasoned discussion of programming languages or implementation strategies, so let's take a shot at it here.

As I've written about on this blog, I've been tinkering for years with TurtleScript, a small learnable JavaScript subset in the spirit of Alan Kay. Over in that twitter conversation David Herman mentioned rusty-turtle, my TurtleScript bytecode interpreter written in Rust. The rusty-turtle codebase includes a REPL which runs TurtleScript's tokenizer, parser, bytecode compiler, and standard library (all written in TurtleScript) through the Rust interpreter. It's quite cute, and I implemented much more of the JavaScript semantics than I strictly needed to (with the side-effect that the behaviors in the JavaScript wat talk now appear quite sane and sensible to me).

I wrote rusty-turtle as a personal warm-up: I was considering taking a job with the fine folks at Mozilla (OLPC having run out of money again) and wanted to understand the technology better. I described a number of further research projects I thought would be interesting to pursue in the rusty-turtle README, including cilk-style fork/join parallelism or transactional memory support (the latter being the subject of my thesis), and a JIT backend using rust's llvm library bindings.

But the true turtles-all-the-way-down approach would be to rewrite the backend using asm.js, which can be trivially JIT'ed (using llvm bindings). Then you've have an entire system from (pseudo-)assembly code up, all written in a consistent manner in JavaScript. To that end, I wrote single-pass type-checker/verifier for asm.js in TurtleScript, discovering lots of issues with the spec in the process (sigh). (I justified this as more "Mozilla interview preparation"! Besides, it was fun.)

Tim Caswell, to finally answer your question: I think that this "JavaScript all the way" system would make an amazing OS. The Rust stuff is just a distraction (except as needed to bootstrap).

In the next post I'll rant a bit more about Rust.

ps. In the end I over-prepared (!): Mozilla's feedback was that I seemed to "know too much about Rust to work on Servo" (Mozilla's experimental web layout engine, written in Rust). Mozilla seems to have reached that awkward size where it can not longer hire smart people and find places for them to contribute; new hires need to fit into precise job descriptions a priori. That sort of place is not for me.

Puzzles I worked on (MIT Mystery Hunt 2013)


Puzzles I particularly liked:

  • Time Conundrum (except for final extraction)
  • Too Many Seacrests

Other puzzles i worked on:

  • Square Routes
  • The Maze (helped guide final extraction)
  • Czar Cycle (which we never solved)
  • Road Trip (final extraction, with alexp)
  • Space Monkey Mafia (final extraction, with alexp)
  • Diagramless Crossmusic (knew how it worked, but meh)



The Gashly-Hunt Tinies (MIT Mystery Hunt 2013)
A is for ADPHI, who ran out of Rs, B is for Better Luck assaulted by czars.
C is for Codex who expired half way, D is for Dataviz stumped by “Wordplay”.
E is for Eigenpirates who left for the beach, F is for Fangorn’s chaotic speech.
G is for Grand Unified Theory’s lost love, H is for herrings caught shifting through drugs.
I is for Illegal, Immoral, and awake; J is for Jones who plagued teams with hard snakes.
K is for Keypad which we did without, L is for Left—as an exercise or just out.
M is for Meteor misstressing trochee; N is for Ninjas searching etsy.
O is for Om Nom locked out of the vault; P is for Part blah blah Who is John Galt?
Q is for Quadragesima Magna Victi In Cratera; R is for Raucous collecting old lira.
S is for Setec humming tunes with 8-bits; T is for Too Long spent reading git hub commits.
U is for Unseen who got caught Up Late; V is for Victory after seventy hours straight.
W is for White Magic which we never solved; X is for Xerox: conundrums resolved.
Y is for You Not Going to Space; Z is for Zero hunts matching this pace.

Guide to readersCollapse )

SDR 0.7

Happy Thanksgiving! Here's SDR 0.7 to celebrate the holiday. Version 0.7 incorporates a number of dance engine refactorings completed shortly after the previous release promised them, as well as (more recently) a number of new call and concept definitions (and test cases) inspired by the C4 calls I am currently studying. I also updated Google App Engine and Google Web Toolkit to the latest versions for the web app, although jMonkeyEngine is still stuck at 2.0 — we might get an Android version of SDR if I manage to rebase to jMonkeyEngine 3.0 for the next release.

Breathing the square properly is still a challenge. Other square dance programs only treat starting and ending formations, but SDR has to consider all of the intermediate positions along the dancers' paths. This leads to some very unusual formations being breathed. As mentioned in the notes for the last release, SDR formulates breathing as a solution to a mixed integer linear programming problem—but there are still a few bugs lurking which cause the constraint solver to blow up from time to time (especially from columns, for some reason). Hopefully I'll be able to dig into this for the next release.

Reading Project Talk (and slides)

An unruly tag team of OLPC folks gave a long talk on the Literacy Project today for attendees at this year's OLPC-SF Community Summit. It was streamed live on Ustream: Part 1 (Matt Keller, Richard Smith), Part 2 (Richard Smith, Ed McNierney, C. Scott Ananian, Chris Ball, questions from the audience). We've posted the slides: Matt Keller, Richard Smith, C. Scott Ananian.

You can try out some of the apps mentioned in the talk. Nell's Balloons and Nell's Colors will run in any reasonably-recent Google Chrome or Mozilla Firefox browser. They will also run as a Firefox webapp on Android devices, using the latest Firefox nightly for Android. For deployment we use a slightly-tweaked build of Firefox (adding expanded webapp storage quotas and the ability to use plugins from inside webapps), and a custom plugin to hook up the Funf logging framework. Source code is available on github: nell-balloons; nell-colors. In addition, Chris Ball's "Matching" app for Android is available: apk; source.

The Importance of Sensing Distance

At IDC 2012 in June, Arnan Sipitakiat and Nusarin Nusen discussed how they are using Robo-Blocks—a turtle robot and “tangible Turtle Blocks”—to teach problem solving and debugging skills to 5- through 12-year-olds.

One of the things I learned from their presentation was that children had difficulty reasoning about relative angles. The Robo-Blocks robot does not have any distance feedback on its motors, so “the result of a program will change depending on the roughness of the surface and the battery level of the robot.” They worked around this issue by developing a protractor tool to guide the children's reasoning about the relationship between the (arbitrary) numbers entered and the amount the robot turned, but some kids still had difficulty. The researchers “often had to insist on trying the protractor” and “some children preferred to keep increasing the turn amount even if a small decrease would have fixed the problem” resulting in programs that had the robot making multiple complete rotations before setting off in the correct direction. The kids were also dissatisfied with polygon-drawing tasks (“turtle geometry”) because the inaccuracies of open-loop control of the robot means that the polygons often didn't close completely, and “[t]his small error turned out to be unacceptable to children.”


Some bonus pictures of the speed sensor on the workbench:

  • The robot on the workbench with probes.
    Speed sensor test setup
    Oscilloscope trace
  • Oscilloscope settings
    Oscilloscope settings

XO Turtle Bot drives around

Here's a first look at an XOrduino Turtle bot driving around:



Tags: ,

"Hello, World" from XOrduino/XO Stick


I've uploaded some more pictures to the XOrduino album as well.


BuildXOrduinoXO Stick
This videov6v7




XO Bot joins the XOrduino and XO Stick

Free things first: I've got parts for 20 copies of the "Mk I" XOrduino and XO Stick. I'm mailing them out for free (!) in exchange for your development help. Send me an email at xorduino@gmail.com describing what you'd like to do with the XOrduino/XO Stick, and your full mailing address. Best 20 or so get kits.

XOrduino A1


  • Assemble an XOrduino / XO stick with an 8-12 year old and document the process. What parts were tricky to solder? Where did polarity matter? How much of the function of the different devices did you find worth explaining? Photos or video of children assembling the device would be great for future publicity, with their permission. (We're not crazy: kids can repair XOs and solder.)
  • Test different configurations of the boards. What are the fewest components necessary for a functional XO Stick? What capacitors are really needed? What's the smallest number of components needed to get the arduino IDE to talk to the XOrduino? Then add the components for the Scratch Sensor Board functionality, and test that with this Arduino sketch (some minor porting required). Try out whatever Arduino shields/old Arduino code you have lying around, and see if there are any gotchas there. Document it all, take photos and video, let me know about bugs and pitfalls.
  • Write some killer education apps! These boards are meant specifically for teaching kids—take the Turtle Art with Sensors ideas as examples, and write up some lessons to teach science. Or take inspiration from the old school "fun with electronics" kits from Radio Shack and recreate some of the popular standbys: a burglar alarm for kids' tree fort, a light-sensitive alarm they can hide in their sibling's drawer, etc. Or a document how to program a robot (more on the robot below) with simple emergent behaviors—avoiding walls, turning toward light, fleeing loud sounds, etc. The Cubelets examples may give you ideas. Take photos and video.
  • Arduino support for the XO Stick. There are a number of projects which add support for the ATtiny85 and friends to the Arduino IDE (for example, this one). Ideally we'd like to make the XO Stick as Arduino-compatible as possible, so we can reuse the excellent Arduino IDE, etc. This involves (a) porting an arduino-compatible bootloader (like usbAspLoader-tiny), as well as (b) porting the Arduino libraries to match the pinout/peripherals of the ATtiny85 and ATtiny861 (this page is a good start).
  • Debrick an XO from the XO Stick. The XO Stick can talk to the EC programming bus to recover a bricked XO; it can probably also reprogram OpenFirmware. We need to write a bit of code to make it pain-free and document the process. This would make the XO Stick a useful repair accessory for XO deployments.
  • Scratch/Turtle Blocks support for the XOrduino and/or XO turtle bot (see below).

Here's the exciting part two: I'm already working on the XOrduino and XO Stick "Mk II". The latest schematics/boards are in github (xostick, xorduino). The kits I'll be sending out this week correspond to the "A1" tag in those repositories; the "Mk II" revision is on the master branch.


The XOrduino gets a more exciting feature (hinted at above) -- enough peripherals to become the XO Turtle Bot! This is a very low-cost turtle robot based on a Tamiya motor assembly. All of the extra robot components are optional—you can populate just the parts you want—but a classroom can now make their XOrduinos (or XO Stick + XOrduino base) into standalone turtle robots, controlled by Scratch, Turtle Art, or Arduino code. The XO Turtle Bot revision adds a motor driver, two bump switches, a simple 3-cell power supply, and rotation sensors for the motors to the XOrduino. (Arnan Sipitakiat and Nussarin Nusen in their Robo-Blocks presentation for IDC 2012 explained that children find "turn for two seconds" hard to understand; we include motor sensors so that we can "turn 90 degrees" instead.) And of course because the robot is based on XOrduino, you can add whatever other sensors you like and write arduino/Scratch/Turtle Blocks code for it.

XOrduino A1 board on top of Tamiya Twin Motor Gearbox.   XOrduino A1 plugged into USB port; prototype XO Turtle Bot in the background.


Nell's Tinkrbook in Omo

This week I will be at the 2012 Interaction Design and Children conference in Bremen, Germany. I will be presenting the Growing Up With Nell paper as well as discussing the OLPC Foundation's literacy pilots in Ethiopia.




Smiling boy in Ethiopia Literacy Pilot Two girls in Ethiopia Literacy Pilot

Tags: , ,

Introducting the XOrduino! (and XO Stick)


The first is the XOrduino, a stripped down low-cost Arduino-compatible board that plugs right into the XO's USB ports. But wait, there's more: it's also compatible with the Scratch Sensor Board, so you can use this device to control Scratch (and Turtle Art, once Firmata is ported). It should be compatible with the Arduino IDE and all Arduino Leonardo-compatible shields.



If $5 per student is too much money, there's also the XO Stick, my second board. It's based on the AVR Stick using the ATtiny85 processor and costs only $1/student. It's not quite as user-friendly as the Arduino-compatible board, but it can also be used to teach simple lessons in embedded electronics. For $0.12 more you can populate an ATtiny261A (though a '461 or '861 would be better) and get 13 I/O ports; this variant should be powerful enough to program other XO Sticks and perform XO maintenance tasks (accessing the serial console, debricking a laptop via SPI flash). The XO Stick is even easier for a kid to assemble themself: only 8 required components, all through-hole. (Sadly, my desire to shave every penny off the cost of this design meant that I couldn't use some of the symmetry tricks I invented for a 2012 Mystery Hunt puzzle to make the circuit impossible to assemble incorrectly.)

Same deal as the XOrduino: design files on github (schematic PDF, pcb PDF); I expect to have a few boards available to people who want to help make some software for them. Schematic and layout review is also appreciated!

Growing Up With Nell



Tags: , ,

2012 Mystery Hunt

This year I was a member of Codex, the writing team for the 2012 Mystery Hunt. I'm going to describe some of the puzzles I wrote for "The Producers" hunt, in release order. BEWARE SPOILERS!

  1. One of the early theme proposals for our hunt was "Alice in Wonderland." Casting about for novel meta ideas, I hit upon the idea of a round with purely numeric answers, 1 through 29,394, which would resolve to words via "looking glass numbers"—that is, numbering all the words in "Through the Looking Glass". It occurred to me that you could make your numbering system self-descriptive if you used certain words; for example, if you wanted to make clear that hyphenated words should be counted as one (instead of two), you could include "great" and "half" on either side of "arm-chair". The numbering of "great" (164) and "half" (166) would make it clear that "arm-chair" should be treated as a single number (165).

    This didn't survive as a meta, but it eventually became a puzzle, called 1207 1370 (which translates to "Looking-Glass Words" using its enumeration system). It also served to ensure that teams had a good wordlist by the time they got to the Charles Dodgson meta...

  2. Blinkenlights. A recursive-structured puzzle inspired by (but not reaching the greatness of) Derek Kisman's Maze from Setec's '05 Hunt. If anyone is mourning the lack of Jonathan Coulton-related puzzles from this year's hunt, blame me: I stole the answer PROTECTORS which Andrew Lin had earmarked for a JoCo puzzle. ("Did I say overlords?")

  3. Caterpillars. I like giving physical objects to teams. This was another failed meta—you would have assembled the pieces out of words, then would have to assemble the jigsaw from the word-pieces. The location of the caterpillars' heads in the final assembly would spell out the final meta answer using an overlay. But the puzzle is more fun with tangible pieces, I think.

  4. B.J. Blazkowicz in ‘Wintertime for Hitler’. I was writing the meta for this round and trying to find non-dictionary words. I needed "CAR..." as a prefix to make the chess game work, which suggested CARMACK as an answer, and the puzzle just wrote itself from there. Scott Handelman contributed the title. This puzzle was going to be distributed on 3.5" disks (remember how I said I like giving teams physical objects?), but the last 3.5" floppy disk puzzle was Blue Steel in '06. (Redundant Obsolescence doesn't count, since the 5 1/4" disk was redundant.) The past six years have not been kind to the 3.5" floppy; ultimately we decided we didn't want to deny teams the pleasure of playing the game because they couldn't locate a floppy drive. It's more important that puzzles be fun than hard!

  5. Charles Lutwidge Dodgson meta. I began writing this puzzle immediately after the 2011 hunt, dissatisfied with the mechanism and final clue phrase of that year's Racking Your Brains. I thought I could write a better puzzle using Scrabble Solitaire as a mechanism.

    Slightly later it became part of the "Alice in Wonderland" theme proposal, with Jabberwocky words. Then I spent a couple of months away from the hunt, getting married.

    Upon returning we badly needed critic metas so I dusted off the puzzle, adding an Alice chess frontend yielding the tile string in order to make it a shell meta. The puzzle can still be solved as pure Scrabble Solitaire (ie, without the given "scores after each play") but it's easier for humans to solve with the frequent checkpoints given. For what it's worth, I constructed the chess game with a reasonably-deep alpha-beta search, so all the moves "make sense" as much as is possible given the constraints of the puzzle. And it ends in a clean checkmate, obviously... I have no idea how BENOISY snuck in there.

  6. Ben Bitdiddle meta. The idea of making an electronic circuit which was impossible to assemble incorrectly had been in my "Mystery Hunt ideas" folder for years. A coworker at OLPC mentioned the odd power-pin configuration of the PIC chips one day, which gave me the "flip" mechanism. Brainstorming with Andrew Lin brought it the rest of the way.

    I promise never to abuse an optoisolator in this way again.

    (Of course it turned out when constructing this puzzle that Ben Bitdiddle really needed to use the show answers CARPAL and THESOUTH because of their length in morse code, so I ended up having to rewrite parts of Dodgson to make Bitdiddle work. In the rewrite CARPAL became CARMACK... and B.J. Blazkowitcz was born.)

  7. JFK SHAGS A SAD SLIM LASS. One of my earliest puzzle submissions was, "A puzzle contained only in its title." Again, the fabulous Codex editor team turned this into a real puzzle.

Some puzzles I enjoyed editing:

  1. Revisiting History — I commissioned a Doctor Who-themed puzzle for the answer TORCHWOOD (see the final clue phrase for the reason why) and contributed the "location of the word 'who'" mechanism.

  2. Gibberish and More Gibberish. I liked the idea for this puzzle enough that I shoehorned a suitable answer into the Charles Dodgson meta... and then had to do some heavy lifting to get the puzzle finished and into the hunt.

  3. Sounds Good to Me. It was immediately obvious this was a brilliant idea from Seth Schoen. But the twin barriers of toki pona and hiragana threatened to make it unsolvable. I'd like to think I played a role in making this an accessible and solvable puzzle.

  4. Itinerant People of America. Same deal. Squiggles had bequeathed the world the facial expression described as, "That's my brain leaving out the back door while my face distracts you." My contribution here was solely instilling the fear of God into the authors. Scott Handleman describes how he and Emily Morgan took that advice and constructed a kick-ass puzzle.

And that's it for my puzzles! I also did a heck of a lot of other stuff for the hunt; I hope y'all enjoyed it. (My own favorite part was the wrap-up, since all my responsibilities had been discharged by then. I could just watch Patrick rock my hat and accordion, play along on ukulele, and sing tenor with Francis at the end.)

A collection of Nell demos





Tags: ,

Introducing Nell









Tags: , , ,

Narrative Interfaces






Small systems... and distributed ones






Turtles All The Way Down



EduJam talks

Chris Ball has done an excellent job posting video from all the talks at EduJam in Montevideo. I gave talks on Sugar, Education, and Tablets, The Diamond Age, Internationalization Everywhere, and Sugar on Android and Native Client.

Next Steps for New Technologies


GObject Introspection (Android or NaCl)


GTK (Android or NaCl)


Sugar partitioning.



Miscellanous topics

  1. ChromeOS w/ touch support.


  2. TurtleArt as JavaScript viewer/editor.





Pango/Android -vs- Pango/NaCl


Screenshot of Pango demo on Android


Screenshot of Pango demo on Native Client








Sugar-on-Native Client investigation



On the other hand, there are three main difficulties:



How does the iPad "use the iPhone's GPS"?




Sugar-on-Android, week one


Basic design of Sugar-on-Android


Key Benefits


Open challenges (general)


Current technical issues/bugs


Bottom line


Exploring New Technologies





Taste, user experience, and engineering

A recent article on Nokia's internal culture contained this interesting quote:


This does seem to me to often be a fundamental problem in not only interaction and UI design, but also internal programming APIs and interfaces. Good engineering is a clever balance; as Larry Wall has said: "Easy things should be easy, and hard things should be possible." An engineering mindset often fixates on the hard things (the "interesting part of the problem"!) and tries to make the hard things easy (or easier), at the risk of making the easy things hard. The end result is failure.

Truly elegant engineering involves finding a view of the problem where the hard parts of the problem disappear. We're not always fortunate enough to find that solution. In falling back to a practical/possible solution, we must be careful to ensure that we keep the easy things easy — it's fine if the hard things are difficult, so long as they are possible. Effort spent making the hard things easier is wasted if it makes the easy things harder. The goal is not a uniform mediocrity of design.

Improving Hunt Software/Improving Google Docs

There's been a lot of discussion about publishing and sharing the software that Mystery Hunt teams use to collaborate to solve puzzles. This is mostly misguided, IMO: teams are very different, and they organically grow solutions to fit their unique processes. On the other hand, an increasing number of teams (including my team, Codex), are building their collaboration software on top of Google services, especially Google Docs and Spreadsheets. Rather than trying to collaborate on One True Hunt Team Software, I think it would be far more useful (for all teams) to lobby for improvements to Google's services. These raise the bar for everyone, and indirectly benefit many other people with collaborative processes.

So here's my list of improvements I'd like to see in Google services:

  1. Integrating Docs and Spreadsheet. If we had an initial "sheet" of the spreadsheet with editable formatted text (not spreadsheet cells) we could actually do away with the wiki we use for capturing free form thoughts and links related to a puzzle.
  2. Integrating Spreadsheet chat, Google Talk, and Jabber. We could just use the chat in the spreadsheet if it were open and accessible, instead of creating our own per-puzzle chat rooms.
  3. Making publish and "setAnonymous" access available via APIs that actually work. We need to use Google Doc Script to do the setAnonymousAccess call, which is not exported via the otherwise-more-complete GData APIs, and drive a headless Firefox 2 instance via Selenium to get the publish bits enabled for the spreadsheet. That's ridiculous.
  4. Providing a way for Google Doc Scripts on a spreadsheet to export data more easily. We can use a Google Form to create a spreadsheet for a puzzle, but no easy way to provide a link to that spreadsheet on the page that results after form submission, or redirect from there.
  5. IIRC Google Talk support for multi-user chat is still barely supported. It doesn't use the standard Jabber protocols, for one. If this were a better supported/more standard service, we wouldn't have to run our own Jabber server.
  6. And, of course, the "next generation" of all this would integrate audio and video into the chat as well. Video is probably more useful, as it communicates human emotional cues. Audio isn't easily archived or searchable, and doesn't work well in crowded rooms, so it is less useful to us. But it would be great if we could actually see some/many/most of the particants in ringhunters, maybe little live video icons next to their faces.

Any further suggestions from other teams?

Codex wins!

We won the Mystery Hunt this year! You can read a Boston globe article which mentions us, but mostly talks about Palindrome.

That means we have to—er, "get to"—write the Mystery Hunt for 2012. My free time for the next year has just vanished.

What's Wikileaks up to?

A recent article in the Economist points out that Wikileaks is not unique: modern network tools have made anonymous communication ubiquitous. You can't stop "wikileaks" by attacking Julian Assange alone. The article is incorrect, however, in claiming that anonymity is easy — in some sense anonymous leafleteers in Colonial America were better off. Bradley Manning currently sits in jail. Haystack was fundamentally flawed. There continues to be a role for organizations who desire to facilitate anonymous speech to identify and provide trustworthy and user-friendly tools and procedures.

Aaron Brady achieves a more fundamental insight by examining Julian Assange's aims. Assange's goal is to hobble "conspiracies", that is, the small cliques of power and secrecy embedded in most organizations, and he seeks to do this by causing them to fear information sharing. By this metric, Wikileaks seems to be succeeding. (Read Aaron Brady's essay for the details.)




Then again, over-reaching openness threatens individual privacy — where to draw the line? Must all our personal mistakes be made in public? Must all our national mistakes be made in public?