Chris Ball

Back from Taipei, and appropriately jetlagged, after a successful bringup of the XO-1.5. The bringup team did some interviews for olpc.tv while we were there, including a demo with Fedora 11 running on the new board. There are interviews with John Watlington (hardware), Richard Smith and Mitch Bradley (hardware/firmware), and me (software), which I’ve embedded below.

Thanks to Charbax for recording the interviews! Was also wonderful to see the new Pixel Qi screen — I’m looking forward to seeing it on mainstream laptops in the coming months.

I’m off to Taipei to help with the XO-1.5 bringup. Before I go, here’s a new guitar piece — the milonga is a Uruguayan relative of the tango.

Jorge Cardoso, Milonga (youtube, download)

Some good news from OLPC: we’ve decided to base the new XO-1.5 laptop’s software release on Fedora 11. Unlike previous releases, we plan to use a full Fedora desktop build, booting into Sugar but giving users the option to switch into a standard GNOME install instead. (This will mostly be useful for older kids in high school.)

I’m particularly happy about this plan because it will allow us to catch up with the awesome work present in the Sugar community’s most recent release, Sugar 0.84, as well as merging the latest Fedora work and including GNOME into the mix for the first time. The new machines will have 1GB of RAM and 4GB of flash, so we have enough room for both environments at once.

We think we’ll need to use our own kernel and initrd, but the other base packages we expect to need are present in Fedora already, including Sugar; in fact, we already have an F11+Sugar+GNOME build for the XO-1 using pure Fedora packages. That build will get better as a result of this work (although OLPC’s focus will be on getting the XO-1.5 running) and it will form the basis for the XO-1.5 build.

If you’re interested in contributing, we’d certainly love your help, and you can find us on the fedora-olpc mailing list, and freenode IRC’s #fedora-olpc channel. Our existing F11 build images for the XO-1 are here, and we’ll soon begin publishing images for the XO-1.5 too. XO-1.5 beta machines will start to be manufactured over the next few months, and will be available to contributors as part of our Contributors Program once the hardware’s up and running.

Finally, thanks are due to the volunteer Fedora packagers and testers who helped us get to the point of being able to commit to Fedora 11 for this new build, in particular: Fabian Affolter, Kushal Das, Greg DeKoenigsberg, Martin Dengler, Scott Douglass, Sebastian Dziallas, Mikus Grinbergs, Bryan Kearney, Gary C. Martin, Steven M. Parrish, and Peter Robinson. Thanks!

Fedora 11 Preview running on the XO-1

Madeleine and I took part in the Processing Time code jam yesterday, and won a prize! Processing is a programming language for creating data visualizations, which Mad’s been using to create graphs for papers recently. Our entry was a program that takes a description of a tree (in Newick format) and draws it, allowing you to zoom in to explore large trees.

The example we used, and the motivation for creating the program, was the phylogenetic tree of life. Since creating this comic, Mad’s wanted a way to create a zooming interface to explore the same, but we didn’t get around to it until we were put in the setting of having four hours to code and then present something. It was a lot of fun; I did the boring part of walking a tree recursively, and Mad worked out the geometry for a radial graphing algorithm that splits points along the edge of a semi-circle equally between end leaves of the tree.

For now, the code’s in this Processing sketch archive, but we’re hoping to make an applet out of it soon. Hat tip to the authors of TreeJuxtaposer, whose Newick format parser we used.

Here’s the obligatory screenshot — zoomed in on part of the mammals section — which isn’t very exciting since the whole point is to explore the tree interactively:

Thanks to the organizers and other participants for such a fun day; it’s great to be given motivation to work on something fun, and lovely to be recognized for it too.

I’ve been pushing myself to record and upload more classical guitar pieces lately. Part of my motivation is that it’s been a long time since I saw my parents and brother, and guitar music’s a nice thing to share with them from afar.

Here are three pieces — if you’re sort of person who cares about copyright licenses, you can consider them CC-BY-SA:

Tárrega, Prelude No. 1 (youtube, download)

Remote desktop is a pretty useful technology. It would be more useful if it wasn’t so competitive, though; when someone joins, the sharer has to sit back and watch, or fight over who gets control. Well, now it’s cooperative — here’s a video demo:

Download the video (23M)

About a month ago, Free Software Magazine published an article that looks into the reasons behind the dearth of women joining free software communities, and makes concrete suggestions about what to change to improve the situation. While I think the article was well-intentioned, I also think it was confused, and promotes recommendations that buy into many of the sexist stereotypes that we should be trying to combat. I haven’t noticed any negative responses to the article, so I decided I should write one.

It’s an odd situation for me to challenging another man’s writing as sexist. It can be hard for women to challenge sexism owing to accusations of overreaction, and on the other hand it can be hard for men to do the same owing to a perceived lack of standing in saying what’s offensive to women; I don’t have a defence for this, other than that I showed drafts of this post to a few women in technology and will invite more to leave comments with their own thoughts after I post. Here’s what I found objectionable about the article, going through some of its bullet point list of recommendations:

• Use forums instead of mailing lists

This suggestion doesn’t make sense to me. I agree with the author (and the many people who have said this before him) that women are turned off by an ultra-aggressive alpha geek style of conversation, but the solution isn’t to “use forums”, it’s to stop using and encouraging these destructive behaviors. We might retitle the suggestion to “When considering flaming someone, don’t.” If you need an example of how moving to a web forum doesn’t make the slightest bit of difference to how respectful a conversation is, consider the average comments in a Slashdot thread.

A point the author doesn’t make — but which I find compelling — is that it’s not just women who are turned off by aggressive conversation modes, it’s anyone who doesn’t want to take part in the alpha geek mentality. By making an environment that is more welcoming to women, we make an environment that is more welcoming to everyone except a loud subset that we’re currently optimizing for.

• Avatars create a face-to-face-like feeling that encourages “more human” behavior

Advocating avatars because they’re “more human”? Are we talking about women or children here? Women read more books than men. Women are perfectly capable of and comfortable with engaging in purely written communication, most likely moreso than men. This insinuation of a childish need for needing cartoons to create a “face-to-face-like feeling” seems extremely insulting.

• When possible, wikis instead of version control archives

I’d love it if I could find more solid reasoning behind this than “wikis are friendly and version control is complicated and women like friendly things and don’t know how to do complicated things so we should use a wiki for version control even though that doesn’t make any sense”, but I’m not seeing it in the article. Ugh.

• When possible, high level languages

Ditto. For example, the FLOSSPOLS report contains a study that compares the programming ability of men and women taking college programming courses. It finds that women perceived their programming ability to be far lower than men perceived their ability, yet programming examinations showed ability levels to be equal between men and women at the end of the course. The problem isn’t that women aren’t smart enough for low-level languages, it’s that we boast about how great we are at coding so much that we manage to convince women that they must not be as smart as us.

• Replace pecking-orders with affirmation processes (thank you’s)

“Women are more likely to want to discuss or seek approval for their changes, owing largely to confidence issues” is not a respectful thing to say. Who doesn’t have confidence issues when joining a new group of people and submitting their first proposal or patch? We’d do well to thank our volunteers better regardless of their gender.

Oh, wow, I just noticed the photo of the sewing machine:

“Programming, like sewing, is largely a “tacit” skill, which is best learned by doing and by watching others.”

Yes, because a comparison to sewing, which is apparently something the author thinks women seem to learn how to do really well, is totally appropriate. Good job. Full marks.

I think I just ran out of words. Please don’t listen to the recommendations in this document. It actually uses good sources, even while it draws insulting conclusions from them, and the sources are worth reading. If you had to choose one thing to read about the (very real) reasons behind there being fewer women in free software, I’d recommend the FLOSSPOLS report, which is a large-scale academic study of the reasons women don’t contribute more to free software projects, and is truly enlightening.

So, now that I’ve complained about the recommendations given, what would a replacement set of recommendations be? As well as the formal recommendations given in FLOSSPOLS, Val Henson’s HOWTO Encourage Women in Linux contains a perfectly good set of advice. Note that one of the recommendations is (3.13) “Don’t assume that all women like cooking, sewing, and babies”. Note that this article attempts to make learning how to participate in a free software project more like learning how to sew.

I spent a few nights working on a web site recently — it’s a public OpenSSH keyserver, in the style of the OpenPGP keyservers, and it’s up now. I’d like to attempt to persuade you all to consider uploading your public SSH keys to http://sshkeys.net/, for a few reasons:

• If you publish your public key, it’s going to be easy for people setting up accounts for you in the future to find it, with a simple wget sshkeys.net/you@yourdomain.com.

• If you manage machines, having your potential users upload keys to the site should save your time by making sure they get past problems like uploading the wrong file, since the site will tell them if they try to upload anything other than a public key.

• There should be side benefits of having a large repository of SSH public keys: I think we would have detected the recent Debian/OpenSSL randomness bug sooner if we’d been on the lookout for unexpected duplicate keys, for example.

I used Django for the site and it was shockingly effortless, to the point where I didn’t have to write any SQL or interact with the database manually. I wrote the following model, which says that there are Addresses, Keys, and combinations of Address and Key that have some extra fields like whether they’ve been verified against the supplied e-mail address or not:

class Address (models.Model):
    address = models.CharField(max_length=255)
    def __unicode__(self):
        return self.address

class SSHKey (models.Model):
    owners = models.ManyToManyField(Address, through='AddressKey')
    keytext = models.CharField(max_length=1024)
    def __unicode__(self):
        return self.keytext

class AddressKey:
    address = models.ForeignKey(Address)
    sshkey = models.ForeignKey(SSHKey)
    date_added = models.DateTimeField('date added')
    verified = models.BooleanField(default=False)
    token = models.CharField(max_length=40)
    token_sent = models.DateTimeField()

After that, it all just worked. The gap between having it all working in the Admin interface (time taken: 3 hours) and having it all working with production views was much larger, though. The Admin interface is full of beautiful widgets that are not at all re-usable in your production site.

The full code’s available over at github (under AGPLv3). I’d be very happy to get patches to make it smarter, and let me know if you find any bugs. Thanks!

I’ve been having fun with new purchases recently: a new bike, and a Neo Freerunner phone from Openmoko. The phone is also my first GPS, and it’s doing a fine job as one:

A bike-mounted Freerunner

Software for the Openmoko has come a long way since the previous model, with a pretty large community of developers building up. (I’ve tried to do my part by writing a patch to fix the touchscreen when the screen’s rotated into landscape mode.) I’m particularly pleased with tangoGPS, which uses data from OpenStreetMap and has some great features: you can zoom out to enclose an area and ask it to download all of the map tiles inside that area for offline viewing, up to a specified zoom level (so, I now have map images for most of Massachusetts sitting on my SD card). You can also publish your current location and get a moving map of friends. It’s written by a single developer, and I’d suggest making a donation to the project if you’re using it — think about how much such an app might cost if it were running on the iPhone instead of the Freerunner!

The bike mount in the photo above is an Arkon CM927, which I don’t recommend very highly; I’ve had the phone come off it (without major damage, which is good) twice now while riding over rough road. It should probably be strapped in separately, but that makes the whole thing less convenient. Let me know if you know of any better cell phone mounts.

Okay, on to the bike ride, which happened yesterday. It was a beautiful day, and we rode from Quincy Center to the beaches at Hull and back, with a few extra-fit people riding from Somerville to Quincy at the start. Here’s a photo of the group:

At the base of Hull Wind 1

We’ve taken the ferry back into Boston harbor twice now (once from Salem and this time from Quincy) and the trip and harbor look fantastic around sunset.

Finally, here’s a photo from tangogps:

Leaving Quincy Harbor on the ferry

A few weeks ago my coworker Scott made a post calling for Peruvian folk heroes to help OLPC out with infrastructure for our Peru deployment, and included a list of projects we’d like to work on. The post began like this:

Peru has ordered over 260,000 OLPC XO-1 laptops. These machines will be running Sugar on GNU/Linux. Forty thousand of these are already in warehouses in Peru, with Sugar builds 656 or 703 installed. That means over a quarter of a million kids will use Sugar/GNU/Linux in the next few months – and you can directly influence their lives! Your software, documentation, support expertise, ideas and insights can improve the education of a vast number of kids.

Wanted: Peruvian Folk Heroes. Will you become one?

From my perspective, the post was a big success. Later that day, Wade Brainerd — a game programmer and OLPC supporter — saw that I’d listed a Spanish Wikipedia snapshot on the list of project ideas and sent a mail asking for more details on the project.

The details are that recently Patrick Collison released a project called wikipedia-iphone, which is a GPL’d program that takes a compressed wikipedia dump (in particular, a single XML file compressed with bzip2), builds an index from each article title into the bzip2 block that stores it, and then allows you to retrieve articles by decompressing just the bzip2 block that’s needed to get at the individual article’s text. It’s an awesome idea, and means you can be carrying around the complete text of a language’s Wikipedia without using too much storage (480M compressed for the full text of the Spanish Wikipedia; 3.5G compressed for the full text of English).

480M is still too large to put on the XO, though, and we have deployments in Uruguay, Peru and Mexico that don’t always have good connectivity. If we could get an archive that was under 100MB, I thought, it would probably be small enough for countries to consider preloading it on all of their XOs by default — providing offline access to the most popular Wikipedia articles for kids who have XOs and their families.

Once Wade and I got started, plenty of help followed. Mel Chua wrote up a wiki page with the state of wikipedia-iphone and what would need to be done, while Wade worked on porting the wikipedia-iphone code from Ruby/Mongrel/Inline-C to Python/BaseHTTPServer/SWIG. Once that was done, Wade started trying to find a renderer from wikitext to HTML that would work well for us. (He chose mwlib.)

Madeleine, Ben Schwartz and I looked at which ranking metrics do a decent job of allowing us to store articles that the user is most likely to want to see — we store that likely subset on the XO, and if an article that falls outside our metric is wanted, we can link out to the local school server or the global net for it, if either is available. Three weeks and over 150 GIT commits later, the finished activity is 98M, has around 30,000 articles and 3,000 images, and is available here.

It was a blast to work on this with a group of volunteers, and to get to know them better in the process. Having a community of passionate and immensely competent developers a stone’s throw away if you can clearly articulate what’s needed and why it’s important is a feature of working at OLPC that I love.

Working on this project has been bringing me back to Eben Moglen‘s keynote at the 2006 Plone Conference (video, transcript). Eben describes the history of attempts to ameliorate human social inequality, and how traditional property being rivalrous and zero-sum has often led those attempts to fail due to the friction and violence that stems from trying to redistribute property from people who have it to people who don’t. He argues that we are past that now; that software is non-rivalrous, and so it’s no longer about “wealth redistribution” because we no longer need to take anything away from anyone; that the utopia of being able to share education and knowledge and the power that comes with them has never been so close. Being part of a team working on distributing hundreds of thousands of copies of Wikipedia to poor kids makes me inclined to agree with him about how close we are.

Eben goes on to describe the moral basis for free software — “If you could make as many loaves of bread as it took to feed the world, by baking one loaf and pressing a button, how could you justify charging more for bread than the poorest people could afford to pay?”

If we are indeed solving epic problems, we should be thankful to the people whose shoulders we’re standing on: the Wikipedians for enabling this transfer of knowledge in the first place; the wikipedia-iphone author for choosing to share his code; the mwlib authors who are reimplementing the mediawiki PHP parser in Python; the determined volunteer OLPC developers who rallied around the idea and followed it through, and finally the creators of this cute green machine that allows us to facilitate a conversation for children to figure out how the world works, why, and how they can shape it for the better.