Development issues

Software Development Issues

The OLPC system is an open platform and we expect that many organizations may make software for this system. We will do the best we can at making the information available for people interested in porting to our hardware.

That being said, OLPC is concentrating on free and open source software that meets the Debian Free Software Guidelines using Linux distributions.

Generic Issues

Consequences of Cost Constraints

The machine will have different performance characteristics than you are used to. We plan to use the JFFS2 journalling flash file system on the flash, so you can presume a read/write non-volitile file system, which also may perform data compression (previous experience for uncompressed data shows about a factor of 2 savings on this file system). Flash has quite different performance characteristics than disk: no seek time for reads, write is slow, and erase is very slow. Flash must be erased before new data is written. The file system tries to hide the erase latency from you by erasing freed blocks as soon as it can, but if there are no erased free blocks, writes can become painfully slow even if blocks have been recently freed.

This means that paging is pretty untenable, and we will not be able to tolerate software that is sloppy about memory usage.

The handhelds.org community has quite a bit of experience in using somewhat similar machines (though with less RAM, and much less flash).

Open Source Developers

What does this mean to you, an open source developer?

With luck, a huge new audience for your software all over the world; maybe of order 100,000,000 in ‘07, if everything goes really well (there are about 1 billion school-age kids on the planet, and others want the same kind of hardware for more commercial use). Governments want to buy these by the shiploads. Their motivation is obvious: distributing conventional books is expensive, and all you get is a book. A computer at the $100 price point, if it can last 4-5 years, can be justified on that ground alone, much less the other uses of computers, such as the web, VOIP, email, IM, etc.

Commercial Software Developers

We'd like to see commercial software available for the OLPC machine just as it is for more conventional Linux and proprietary operating systems; but it is problematic to understand how OLPC could possibly redistribute such software. Please understand that education is fundamentally a local issue, and as such, local decisions will often be made on what software is available in a particular area.

Screen

The screen should be usable in two modes: 1110×830 resolution b&w (grayscale), sunlight readable, which is essential as many schools are out of doors and conventional LCD’s generally don’t work well in strong light, and a back-lit color mode, at lower resolution, using an LED.

Note that in many locations in the world, the backlight will be the first artificial illumination many families will have (besides a fire). How people will use these systems will facinate us all.

The later Geode chips have rotated blits and alpha blending hardware support, but not 3D, so most OpenGL applications won’t have decent performance, but other X Window System performance, including Composite, should work quite well indeed (when we have the driver done right, anyway). I’d like to see either a kdrive or EXA X implementation that takes advantage of these features.

Check Hardware specification for detailed information about hardware.

Note that many developers have never tested their applications on a grayscale display.

General Recommendations

• Take internationalization seriously. And make it easy to localize your applications as well by using commonly used frameworks (e.g. gettext).
• Memory usage matters, and leaks are deadly. On modern CPU’s, your code will probably also run faster if it uses less RAM, as RAM is often/usually one of the major performance bottlenecks (along with stupid algorithms, of course).
• It is often better to recompute something from data than to keep large caches of computed results.
• Cache locality: the trend in computing is clear. To give you a clue: if you take a full cache miss on an iPAQ handheld, you use 200 times the power of a cache hit (due to capacitive loading). I’m sure initially on this machine the penalty will be much lower than this, but the general trend in computing architectures is in this direction.
• Stupid memory use on desktops can already cause your machine to page, causing unpredictable interactive feel (even worse, some one else’s application can do this to your app.). But paging at all on a flash system, even if possible, is the kiss of death for performance, as write times to flash can be so slow.
• Remember, your applications may also be using pixmap memory in the X server, and can leak pixmaps. There are some tools these days for looking at which applications are using memory in the X server.
• Think about taking session management seriously: when memory is low, I’d like to be able for a window manager to tell the application you have buried to save itself, and go away entirely, only to be transparently restarted if the user again references that buried/iconified application they haven’t touched recently, and recover to the exact state when stopped.
• If you are sloppy in performance or memory usage or waste file system space, we’ll probably choose other software; what matters are the educational applications to us, and the content which will educate the children.
• Don’t waste screen real-estate. Test with small windows and/or X servers configured for small screens. We hope to get better instructions on how to set up a good test environment soon. The Xephr X server that Mathew Allum developed may be very useful for such testing and understanding memory usage of your application.
• Use GUI editors (e.g. Glade/libglade) so that your application can be tuned well for smaller displays (and, if appropriate, provide more than one GUI definition); this is also true for the Nokia 770, iPAQ, and Sharp devices, with even smaller screens. Bother to do such tuning your self, or you may not like other people’s tuning, or even better, get some help from someone who can actually design decent GUI’s in the first place (most programmers are pretty bad at this art, even those who think they are good at it).
• You have an even higher premium on writing easy to use and learn software; your audience may be younger than you.
• Doing stupid things in your programs can make it hard to put the processor to sleep or use more power than need be. In the case of this machine, this translates to real work to do (think cranking).
• There is some fun system work for kernel hackers to give user space the facility to choose who to kill (or better, checkpoint) when RAM runs low. Window managers have a ton better idea what you are doing than the kernel ever will. The OOM killer is worse than nothing; it often chooses a key component to kill.

Software Environment

This section will be fleshed out as we have better information.

• You can presume Linux 2.6.x and the basic libraries you would expect to find, along with the X Window System and basic X libraries used by modern desktop environments. You can also expect not to find some of the antique X applications and libraries.
• Remember, even if you might expect JFFS2 to get us a factor of two in space, educational content must also be resident on flash, so we expect some hard decisions to be necessary. At this date it looks unlikely there will be flash and RAM space to provide both Gnome and KDE environments. And some parts of those environments are pigs, and need replacement (or serious rewrite) in any case, so we may choose other more suitable components (e.g. window managers, panels, session managers, etc.). At this point, OLPC looks most favorably on the GTK+/Pango/ATK toolkit combination to give us the best internationalization and accessibility properties. This does not mean that it will be impossible to run software from both common free desktops on the machine simultaneously, just that it may come with a very high penalty due to the constraints of the machine.
• Space (in RAM or flash) will often also constrain loading other software with large footprints. We expect and hope that many open source projects will rise to the challenge, and fix both memory usage problems and their flash footprint (sometimes by things as simple as better packaging, and sometimes by more serious rewrite).
• You can expect a normal Linux development environment to be available for the most common languages, though not necessarily on systems with content loaded.
• We expect to have an interesting set of educational software, including some that has not before seen wide deployment, such as scratch as well as other open source educational software you may already be familiar with.

Open Formats

Open data formats is essential to the free redistribution of content, and we have no licensing mechanism nor could we afford to pay a revenue stream for closed format, patent enumbered data formats such as MP3. Therefore we encourage the use of formats such as ODF, Ogg Vorbis, and Ogg Theora, rather than proprietary data formats. Using such formats for educational content will greatly restrict their usefulness world-wide.

Licensing

Content

We would like to call your attention to the good work of the Creative Commons project, which has been developing a family of licenses for the redistribution of creative materials. Many of these licenses will be suitable for general free redistribution of educational content; some, however, will not.

Software

A general guideline for what software licenses might be useful for redistribution in this project is best stated by the Debian Free Software Guidelines (or the similar OSI guidelines).

Jim Gettys, December 19, 2005