27 Months

This content shows Simple View

software

Hacking the OLPC v2

Hacking the OLPC v2There’s been a veritable bevy of blog posts and rebuttals lately debating what went wrong with the OLPC and what sort of device should follow in its wake. Like a lot of other technology devotees, I’ve watched from the start the meteoric rise and much-publicized decline of the project, which once promised so much but has yet to deliver on the scale its architects had hoped for. There’s been enough punditry, religious warring and snarky commentary following the OLPC’s capitulation to XP to fill volumes. I’m more interested in what form the future OLPC might take, and who will build it. These recent discussions have provided fuel for the imagination.

I think the question of which is better, mobile or a laptop/netbook will become moot as these devices continue toward their inevitable convergence, WiFi networks proliferate in lesser-served parts of the world, and manufacturing costs are further reduced toward the elusive $100 mark. The tantalizing next-generation OLPC (dubbed the XO-2) with its dual touchscreens already resembles an oversized iPhone in both form and function. Availability: sometime in 2010. Maybe.

What should fill the gap between now and then? Until African children can get their hands on the XO-2, or an Android- or Symbian-powered device, perhaps with a foldable keyboard, surely something can be leveraged from all the effort that went into the OLPC.

I’ve spent many hours teaching kids in Cameroonian classrooms, both with computers and the old-fashioned way with a blackboard and, occasionally, printed materials. I can say with certainty that what’s needed in terms of hardware is something rugged and capable of dealing with heat, humidity and dust. Long battery life and a method for off-grid recharging is a must. And no one can argue against the value of having a laptop-like device with a full-sized interface for learning versus a handheld mobile device. Different tools for different purposes.

Last week, while cruising the daily RSS feeds, I offhandedly tweeted this:

Later, I got to thinking about it. Was it such a crazy idea? A dead simple, $200 tablet with a focus on cloud computing seemed like just the ticket. Then, just for laughs, I dummied this up in Photoshop (apologies to TechCrunch):

Hacking the OLPC v2

Like the XO Laptop, Sugar has its share of detractors, often citing it as unintuitive, clunky, inappropriate or worse, but I think they’re missing the point. Nicholas Negroponte has some strong words on this subject:

“In fact, one of the saddest but most common conditions in elementary school computer labs (when they exist in the developing world), is the children are being trained to use Word, Excel and PowerPoint. I consider that criminal, because children should be making things, communicating, exploring, sharing, not running office automation tools.”

Mr. Negroponte is dead on here. I did my best to engage kids in Cameroon with something other than Word (my binary numbers and ASCII lessons were unexpected hits), since Microsoft Office is already taught by default in every school lucky enough to have a computer lab. As a platform for learning, the philosophy and design behind Sugar is incredibly compelling. I can only imagine what a classroom full of my kids in Cameroon would do with a couple dozen “CrunchPad OLPC v2” tablet PCs running Linux and Sugar.

Could a homegrown, bottom-up designed CrunchPad-esque tablet PC be coaxed into doing this? The answer is an emphatic: absolutely! The good news is, Sugar Labs, a non-profit foundation whose mission is to produce, distribute, and support the use of the Sugar learning platform under a number of Linux distributions is already on it. Sugar is now a community project available under the open-source GNU General Public License (GPL) and free to anyone who wants to use or extend it.

As Miquel of Maneno noted, Africans are incredibly resourceful. Might it be possible for a geographically dispersed group of devoted hackers, with the support of the open source community, hardware partners and VC pooled from the diaspora, to produce the next OLPC—here in Africa? Heck, others are already eager to jump on the CrunchPad bandwagon. Surely crazier things have happened.



The Virtues of Small Software

Essayist, poet and philosopher Ralph Waldo Emerson had this to say on the subject of beauty:

  • We ascribe beauty to that which is simple;
  • which has no superfluous parts;
  • which exactly answers its end;
  • which stands related to all things;
  • which is the mean of many extremes.

– The Conduct of Life, Chapter VIII, Beauty (via TinyApps blog)

Doug McIlroy, one of the founders of the Unix tradition, may well have drawn inspiration from Emerson when he summarized the Unix philosophy with the following three tenets: “Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.”

This philosophy placed a special emphasis on the use of a large number of software tools—small programs that could be strung together through a command line interpreter using pipes, as opposed to a single monolithic program that includes all of the same functionality.

An approach like this worked well because, in the late 1970’s and early 80’s, programmers had to work within the confines of relatively small and expensive resources. While difficult to conceive of today, 16KB of RAM was common and 64KB was considered expansive (I remember writing my first assembly program on the Commodore 64—I thought I was in heaven). Likewise, storage in the megabyte range was a luxury. Programmers created small software with tiny allocations of storage and RAM that ran on processors that were Lilliputian by today’s standards. Every byte and clock cycle counted, and thus a lot of work was done to make programs fit into available resources.

The rise of bloatware

Nowadays we have thousands of times the processing power, memory and storage yet, from the user’s perspective, software for the desktop, web and mobile seems to run slower than it should, or used to. We’ve been conditioned to accept long load times for applications, Ajax delays in Gmail, adware, automatic updates and the scourge of bundled third-party software.

Nathan Myhrvold, physicist and former CTO of Microsoft, once compared software to the physical properties of a gas for a keynote address in 1997. In a marriage of Moore’s Law and the Ideal Gas Law, he declared that “software always expands to fill whatever container it is stored in,” but its growth is “inevitably limited by the rate of increase in hardware speed.” So what happens when software hits the upper bounds of the hardware it’s contained in? Myhrvold’s response: “People buy new hardware because the software requires it.”

What Myhrvold succeeded in defining with his four Laws of Software, intentionally or not, is a Unified Theory of Bloatware. In one sense, his Third Law kept the PC business thriving by requiring bigger, faster hardware to run increasingly bloated software.

microsoftofficesize
In a challenge to Moore’s Law comparing installed disk usage of Microsoft Office and Open Office (see above), we find that, “at this rate of growth, Microsoft Office Standard 2013 will be 5000MB, and the Microsoft Office Premium Platinum Plus 2013 edition (a larger edition than the Standard edition) will come on a set of Blu-ray discs.” The take-home message: “Microsoft Office Standard edition’s growth is more closely in step with maximum disk capacities.” Myhrvold was right, at least insofar as Microsoft Office is concerned.
One of the best attacks on bloatware ever, Thank you, Adobe Reader 9!, comes from Ben Hoyt, one of a trio of Kiwi brothers behind Brush Technology. His post is acerbic, hilarious and gives Adobe a well-deserved thrashing as a prime example of what’s wrong with contemporary software. Ben posits the question, Can Modern Software Be Snappy? and draws on some examples from coding for embedded devices and graphics programming. Both are great reads on this topic.

Incidentally, if you haven’t yet please do take Ben’s advice and replace Adobe Reader with Foxit’s PDF reader. You’ll not only save yourself disk space and headache, but avoid some rather nasty security vulnerabilities at the same time.

Small is the the next Big Thing
In an ironic twist, with the rising popularity of netbooks and rapid growth of mobile devices as the default computing platform, software is returning to a focus on “do one thing and do it well” within the resource constraints of these small devices. Moreover, as consumers and businesses alike tighten their budgets during the global economic downturn, extending the life of old hardware is becoming a necessity.

The good news for end-users is that alternatives to bloat do exist. If you want to go really small, the single best resource for apps that run will run on nearly any PC hardware has always been at TinyApps.org. Peruse the list, try a few out (none is bigger than 1.44 MB and many are contained in a single executable), link them up with some keyboard shortcuts and you’ll be working smarter and faster than ever. Trust me, it works.

For the engineer, designing small software that can run efficiently with limited resources was, until recently, a dying art. One of the best resources for programmers is the excellent (and free) book Small Memory by Charles Weir and James Noble. You can also listen to the authors interviewed on Software Engineering Radio.

I’m probably preaching to the choir here, but along with this book it’s worth considering some small software maxims for the engineer. Among the best are Eric Raymond’s design rules in The Art of Unix Programming, Mike Gancarz’s The UNIX Philosophy, and Rob Pike’s Notes on Programming in C. They’re summarized nicely here.

Included with the “small is beautiful” software design ethos is an emphasis on performance analysis, code profiling and refactoring. Too often, in my experience, this step is sacrificed under time pressure to deliver a product to market, yet it’s a crucial phase of any project. Bottlenecks often do occur in surprising places and speed hacks seldom work without solid metrics. It also never hurts to run an app through a processor emulator like QEMU to get a feel for how it will perform on older hardware.

Implications for African software
Citing the challenges brought by bad governance, poverty, low bandwidth, and some of the harshest environments and use-cases in the world, Erik Hersman noted that, “If it works in Africa, it will work anywhere.” If “do one thing and do it well” may be said to capture the philosophies of Unix and small software, Hersman’s declaration is the battle cry for a legion of cottage industry African software entrepreneurs.

By adopting the philosophy of small software, the developers crafting solutions on the African continent are in a unique position to reap opportunity from their environment. Witness highly specialized, targeted applications such as FrontlineSMS, MobilePress, Kerawa, Afrigator, Maneno, Zoopy, Ushahidi and countless others—all created by Africans and distributed online, often for free. One of the most interesting recent applications built for the developing world, FrontlineForms, is targeted specifically at low- to mid-level mobile devices.

These applications (and a lot of others I’ve surely overlooked) are at the forefront of what Samuel Dean called a “knock down, drag ‘em out renaissance…involving guerrilla apps, widgets, and many other software offerings that don’t happen to come from Microsoft or other gorilla-sized providers.”

The future of software is small. The implications for Africa, and the developing world at large, are huge.




top