Sunday, May 31, 2009

Support Google's plan to save the earth

In case you haven't noticed, I just put a new widget in my blog's sidebar. I call it the Google Day Counter, and I created it to try to motivate Google to proceed with its charitable contest, Project 10 to the 100. For those who don't want to follow the link, Project 10 to the 100 is a contest Google launched to spend ten million dollars toward ideas that are beneficial to the whole human race. Here was Google's plan: solicit big, earth-saving ideas from normal people, pick the best 100 of those ideas, let normal people vote for the best twenty of those ideas, and spend ten million dollars to launch best few of those twenty ideas. It was a good plan, if a bit un-democratic, but the execution has been problematic.

Google's initial goal was to collect entries until October 20 and announce the 100 finalists on January 27. However, due to the incredibly large number of proposals they received (over 150,000), they had to delay the announcement until March 17. Unfortunately, they had miscalculated again, and the announcement was delayed indefinitely.

The delays mattered to me because I submitted an idea to the contest. My idea was simple: design and develop an open source speech augmentation application for people who can't speak. The application would allow mute people to communicate by clicking on icons or typing in a box on the screen. This software is necessary because the de facto speech augmentation software, Say-it! SAM PC, is far too expensive for many mutes. My plan would ensure that nobody is too poor to communicate with their friends and family.

Because of my submitted proposal, I waited in eager anticipation for March 17, Google Day. When the day finally arrived and the final announcement was delayed indefinitely, I started jokingly measuring the date in relation to Google Day. If I was asked for the date on April 18, I would have responded "April 18, Google Day plus 32." Now that the date has passed Google Day +70, I'm worried that Google has placed Project 10 to the 100 on the back burner and that the project selection could take another six months.

Personally, I believe that that ten million dollars toward big-idea innovation would be most beneficial right now, in the middle of the economic crisis. Thanks to recent deflation, ten million dollars would probably accomplish far more now than six months from now. That's why I've decided to create the Google Day Counter widget and release it to the blogosphere. If you use Blogger to display your opinions to the world, you can add one of the widgets below to show your support.

...but if you use any other blogging system, you can simply cut-and-paste the code below into your sidebar div or *shudder* table cell.

<style type="text/css">
#googledaycounterdiv a {
font-size: 2em;
font-family: Arial, sans;
letter-spacing: -1px;
font-weight: bold;
color: rgb(0, 153, 0) !important;
<script type="text/javascript" language="Javascript">
// addEvent by Scott Andrew LePera
function addEvent(elm,evType,fn,useCapture){
   elm.addEventListener(evType, fn, useCapture);
   return true;
 } else if (elm.attachEvent) {
   var r = elm.attachEvent('on' + evType, fn);
   return r;
 } else {
   elm['on' + evType] = fn;
function googleDayCounterInit() {
 var googleDay = new Date('March 17, 2009');
 var today = new Date();
 var elapsed = Math.floor((today.getTime() - googleDay.getTime()) / 86400000);
 var elapsedDiv = document.getElementById('elapsed');
addEvent(window, 'load', googleDayCounterInit, false);
<div id="googledaycounterdiv"><a href="">Google Day +<span id='elapsed'>?</span></a></div>

I hope you'll join me in prodding Google to devote its time and money to finally launching Project 10 to the 100.

Thursday, May 28, 2009

Google Summer of Code application tips

I have been meaning to write about my Google Summer of Code experience since I learned of my rejection, but I've only now found the free time to finally do it. For those who haven't heard about it, the Google Summer of Code is a program in which Google pays students $4500 to work on open source projects over the summer. (More info.) I learned about the Google Summer of Code on March 23, the first day that applications were being accepted. For the 28 days until the winners were announced, I devoted my life to perfecting my proposals, socializing with the mentoring organizations, and fantasizing about the immense heft that "GSoC student" would carry on my application to MIT.

Unfortunately, I simply wasn't good enough. I had only about 1.5 years of programming experience (none with open source projects), I was a freshman at Broward College, and I made several mistakes on my applications.

However, although I couldn't affect my programming experience or my enrolled college, I certainly could've improved my applications. Below, I've compiled a list of tips that I picked up from numerous IRC conversations, mailing list posts, and direct emails to mentoring organizations. Learn from my mistakes and net yourself that $4500 next summer!

Think inside the box

Although most of the Google documentation on the Summer of Code implies that each organization's ideas list is simply a loose guideline, you should write your proposal on a project explicitly listed on your target organization's ideas list. Resist the urge to set yourself apart from the crowd by proposing something new and revolutionary. Mentoring organizations carefully choose only the most useful projects to be listed on their ideas lists; you are unlikely to think up a project more important than the ones they chose.

Use all available tools

On the same day that I learned of my rejection, I stumbled across this invaluable resource page for GSoC applicants. It has a categorized list of mentoring organizations, a search engine for mentoring organizations, and tons more useful info. Even if the information isn't updated for GSoC 2010, it should still give you a good starting point in your search for a mentoring organization.

There's no safety in numbers

No canned applications! Sending out several generalized proposals will only waste the time you could be spending on your serious applications. You should use all your available time writing targeted, high-quality applications to specific organizations; spamming twenty organizations with your resume is simply a waste of your time and theirs.

Be professional

Don't crack any jokes unless you personally know the proposal reviewer at your target organization. When I wrote an application to Sunlight Labs in which I included one irrelevant but humorous fact and several corny lines, the proposal reviewer thought that the entire application was a joke. I promptly assured him that my proposal was in fact serious, but the damage was done.

Do the work

Unless you want a quick rejection, you should comply with all of your target organization's application requirements. If they ask you to fix a bug, you should actually fix one of their bugs, not just make a patch that somebody else suggested. If you can't dive headfirst into the development of your organization's project, you should probably find another organization. Nothing will get you rejected faster than an hole in your proposal.

Choose wisely

Only apply to organizations you know something about. Although the temptation is strong to apply to some of the obscure supercomputing or AI organizations, you can be sure that there's a bored Computer Science grad student ready to put your proposal to shame. If an organization doesn't get enough skilled students for their projects, they will return their slots to Google. However, if you apply to work on a small project you think you can handle, but the organization doesn't have enough slots for you, they might get one of the surplus slots from another organization. You have a much greater chance of success when you shoot for a project at your level.

Start now

From what I've seen, the majority of accepted Google Summer of Code students had participated in their organization before they even knew about the GSoC. The best way to increase the probability of your acceptance is to be involved in the organization before you apply to work with them. Organizations want to give their slots to students who will complete their projects over the summer and stick with them after the money stops. There's no better way to prove your commitment than to be committed, so find a project that interests you and jump in.

Sunday, May 10, 2009

Failed to build these modules: binascii zlib

It's very rare that I encounter a computer problem that I can't solve. I thrive on the challenge of rooting out the cause of an obscure error and finally getting my software to run properly. However, I thought I had been defeated by the error in the title of this post.

The trouble started when I tried to install Django on my Ubuntu Intrepid Ibex partition. I was unaware of the convenient apt-get method of installation, so I was going through Django's long list of dependencies, trying to find the initial critical library on which the entire list depended. I thought I had reached the end of the chain with Flup, a WSGI (Web Server Gateway Interface) library for Python. I tried to install it from its Python egg, but it threw several serious errors that indicated that I didn't have the necessary library to "hatch" the egg.

Of course, I found the required library and downloaded it, only to realize that it, too, was contained within a Python egg. The readme file clearly indicated that I could install the software by running a simple command: python [I forgot the name of the file].egg. Every time I tried, it would tell me that zlib wasn't installed and quit.

Of course, I looked up the "missing zlib" error and found some possible solutions. I tried to install the zlib python module from source and tried to download it from the repositories, but nothing would stop the fatal error.

I gave up.

Because my school work started to pick up, I didn't really have time to think about Ubuntu and my installation woes for about a month. The trouble started again as I was preparing for one of my Google Summer of Code proposals. When I attempted to install PGReloaded, an unstable development branch of the PyGame multimedia library, on my Intrepid Ibex partition, I encountered strange error after strange error, and I was completely unable to install the library. I thought that the problem might be related to my installation-from-source procedure, so I tried to install the standard Pygame library through apt-get and play a game that relied on it. The game couldn't find Pygame, even though I had just installed it.

I then remembered that installing Python 2.6 had given me an installation error: "Failed to build these modules: binascii zlib." I realized all my problems were caused by a faulty Python installation. First, I tried to verify the integrity of my Python installation. I checked md5 sums, ran tests, and reinstalled Python 2.6 from source. All the tests failed due to the absence of binascii and zlib. Looking for a fix, I started googling around, this time for Python installation message.

I found only one other instance of my problem in a post on a mailing list; unfortunately, the poster didn't get an answer. I thought that the gurus on the Python Help mailing list might be able to diagnose my problem and find a solution. Unfortunately, I hit a dead end there, too.

Now, the narrative flies off the tracks. If you want to read the whole convoluted tale and you have a taste for debugging narratives, you can take a look at Jaunty Jackalope released: Vista all over again. To summarize, I had to reinstall Intrepid Ibex and destroy all my files after an ill-advised "upgrade" to Jaunty Jackalope. I had to start from scratch.

Researching an entirely different problem, I stumbled across this Python 2.6 on Intrepid Ibex installation guide. Apparently, all my problems were caused by a conflict between the system default Python installation, 2.5, and the newer version, 2.6. I was thrilled to finally have my answer, but I wasn't looking forward to another lengthy, complex Python installation.

In the end, after a little advice from some python gurus, I decided to skip Python 2.6 entirely and stick with good ol' 2.5. This time, PGReloaded installed easily (for an unstable development library), and I don't expect any problems installing Django. I guess the moral of this story is "If a task becomes incredibly difficult, make sure that it's actually worth your time."

Sunday, May 3, 2009

Jaunty Jackalope released; Vista all over again

That's right, I put the release of Ubuntu's Jaunty Jackalope on the same level as Microsoft's launch of Windows Vista. Although Jaunty's release wasn't announced by a troupe of performance artists like Vista, its fanfare-filled launch ensnared many users who were unaware of its development-release instability and widespread incompatibility.

My awareness and rage toward this issue started with a single click. After my package manager had downloaded several updates, I noticed a button above the list of updates encouraging me to upgrade my system to the newest release of Linux. I obliged, just as any inexperienced user would when greeted by a safe, important-looking button.

The enticing Jaunty upgrade button

The installation took two or three hours, and it threw only a single minor error: the incompatible package libphoto (or something like that) wasn't installed. I shut down my system for the night, admiring the cool gradient loading bar before turning off the monitor.

When I booted up the next morning, I chose the newest kernel from the GRUB menu and expected a smooth startup. Instead, I was greeted by a total startup failure. My flashed between a black screen and a black screen with a red bar at the top several times before finally hanging on the glitchy red bar. Every time I tried to boot linux, I would get the same red bar of death followed by a permanent hang. Even if I attempted to fall back to an older version of the kernel, I would get the same result: total failure.

I decided to figure out what had happened and how to fix it, so I fired up Vista (GRUB still worked fine) and asked for help on the official Ubuntu forum. Instead of an explanation and instructions on how to fix my problem, I received this response from an experienced Ubuntu user:

Sorry to hear about your upgrade problems. 9.04 seems to be producing a lot more than its share of such problems (which is why we generally recommend against doing an upgrade).

As to reverting, sorry (again), there's no simple way to do that because an upgrade not only replaces packages it also removes them.

I was shocked. I had often heard tales of the stability of Linux relative to Windows, but now I realized those tales were just myths. I might expect to encounter this problem and response if I was installing Jaunty on an old, obscure, or esoteric system, but I never thought that my 64-bit Intel quad core PC wouldn't be supported by an Ubuntu distribution release.

I then began to notice all the encouragements for Ubuntu users to upgrade to Jaunty Jackalope: Jaunty has a plug on the Ubuntu forum index page, it is the default Ubuntu version for download on, and it also has that tantalizing upgrade button on the Package Manager. However, inexperienced users are supposed to ignore all that and instead ask the advice of an experienced Ubuntu user.

I find this incident startlingly similar to Microsoft's often-mocked Vista advertising blitz. Although Vista and Jaunty were unstable and had many incompatibilities, they were both released with much fanfare, enticing naive users to "upgrade" now. I understand that Ubuntu follows a strict six-month release schedule, but the trust of their users should be more important to them than an arbitrary schedule. On the other hand, Ubuntu could have officially released Jaunty but delayed the push for users to upgrade until after the OS was as stable as its predecessor.

I eventually had to destroy my Linux partition (along with all my data) and start again with Intrepid Ibex from my Live CD. After this incident, I might skip the Jaunty upgrade entirely and wait for the next long-term support release; I'm not anxious to "upgrade" Ubuntu again anytime soon.