OLPC’s $100 laptop was going to change the world

Any chance you could comment further on this? What in particular made it bad?

The little I played with it, I remember lots of random UI stuff built by different teams put together haphazardly, and a button press would sometimes take seconds to show a result on the screen... basically what you'd expect from an alpha product put together by volunteers on a shoestring budget.

I'm not the parent, but I bought two OLPCs back in the day in the "Give One, Get One" program.

The software + hardware was really poor, even for the time. (Even the original Raspberry Pi is significantly faster -- I know this isn't a fair comparison, but just for reference)

Also a lot of the OLPC functionality didn't work reliably, or didn't work at all. I bought it specifically for the mesh networking, which was cut entirely. The devices did work over WiFi, but would struggle to see other OLPCs over wifi reliably, even when connected to the same AP. I spent a lot of time reading forums online to troubleshoot and download fixed drivers and such. I remember explicitly wondering "how are children in poor areas who depend on mesh networked internet, supposed to be figuring all of this out?".

The screen was hard to use. The e-Paper mode was nice, but the regular mode was blurry/grainy and slow and dim and just difficult to see. In terms of Software + UI + responsiveness, it felt more like a really big Palm Pilot, and less like a laptop.

---

I loved the mission, I loved the ideas, I loved the design. The exterior of the case really was durable and kid-friendly. I loved the idea of the screen. I threw them more money than was reasonable. I was just fairly underwhelmed by the device as it actually shipped. It felt like a prototype of a dev kit, which is fine. But it was sold as something for children to use, and at least at the time I messed with them, it was nowhere near ready for that.

Your review is probably much more honest than mine... The potential was awesome. I forgot about all the promises that were never fulfilled. Remember when they promised that the super wide touchpad would be resistive touch and you would be able to use a stylus and write on it? Would have been cool, but I don't think that ever happened either.

Oh yeah, I remember that too. That one always felt to me like something they couldn't deliver on (just like the hand crank -- which admittedly, that one they did tell everyone would be dropped before they ordered).

But I remember being most disappointed about the mesh networking, since that was supposed to be the thing that made the project feasible. I intentionally bought two of these devices just so they could talk to each other -- and they couldn't reliably do so, even with conventional WiFi at their disposal).

I had one back in the day, and it was the worst computing experience I can remember. The keyboard was like what you'd find on a speak-and-spell, and the system had the performance of a low-end 486 under heavy swap.

I still don't understand why the system performed so poorly, I know a lot of Sugar was written in Python, but there must have been some very fundamental problems with it. Switching to an existing lightweight X window manager was a much better (but still not good) experience.

I think the problem started out the other way, with way too much budget. They bit off more than they could chew. The budget cuts happened later.

If you had volunteers on a shoestring budget, you'd simply create a FVWM theme. It would be pretty normal, but with thick borders to compensate for the crude touchpad. You'd patch the program launcher to prevent running more than one thing at a time, thus dealing with the memory constraint and user confusion. That's it. Ship it.

Instead, they wrote a completely experimental desktop environment in an interpreted language. This is not the sort of project you'd bite off with volunteers on a shoestring budget.

I was a volunteer. I told them that stuff was nuts, but the paid staff were on a mission. Nothing could dissuade them. They wouldn't even dogfood. By that, I mean they didn't actually use the laptops. They used high-end developer workstations because the laptops were unusable. That should have been a hint.

I worked with the OLPC in university (not MIT). I can confirm your findings, and additionally:

• The hardware was not designed in conjunction with the software; it seems to have been built based on a "wishlist" of features drawn up before the software was developed. There were a number of major hardware features which were unused or unsupported by software, including but not limited to the resistive tablet, the low-power-mode ("e-reader mode") for the display, and even several of the hardware buttons (including most of the ones next to the screen, which were mapped confusingly to arrow keys).

• Aside from being confusing, the software was very rudimentary. The two major activities which would be useful to students (the web browser and text editor) were not actually Sugar applications at all, but standard Linux applications (Firefox and Libreoffice, iirc?) wrapped in their interface. There were very few nontrivial native Sugar activities available.

• The Sugar interface, as designed, had some very strange semantics which were not intuitive, and not reflected well in the user interface. Every activity opened by the user was saved in the filesystem -- even ones which were not useful to save, like web browsers or simple memory games. The OS would automatically discard old activities as necessary to keep storage available -- so recording a long video, for instance, would delete older documents created in the text editor.

• Development on the project had a lot of bizarre priorities. For a time, one major development priority was to build a reverse-engineering suite for the OLPC, so that students could reverse-engineer the mesh networking firmware and develop their own under a free license. Fortunately, I don't think this got to the point of actually being developed.

> I still don't understand why the system performed so poorly, I know a lot of Sugar was written in Python, but there must have been some very fundamental problems with it.

Fundamental problem identified. I believe the Inferno port tended to run better.

The software for the initial public release of the OLPC was very rushed. The organization received so many small orders that they took people off of software development in order to process orders. These laptops were shipped (often months late) with beta-quality software. Beta-quality software was a terrible experience on a 400MHz machine with 0.25GB of memory -- there were no resources to spare.

Subsequent OS releases fixed most of the software problems, but the project had lost a lot of steam and goodwill by then. (They also lost a lot of goodwill before the release when Microsoft announced that they'd gotten Windows XP to work on the laptop, and the OLPC project announced that it would be available as an alternative to their own linux-based OS. [0])

As a result of the really, really bad experience with the Give 1 Get 1 campaign, OLPC instituted minimum order quantities of 1000 laptops (or 100 laptops if you ask nicely. The OLPC XO-1.5, a new motherboard for the XO-1 laptop, was also available in minimum quantity 100). The latest version of the laptop, the XO-4, has a gigahertz ARM processor and either 1 or 2 GB of memory. However, there are only 3 ways to get one:

* be in a country or school program that purchased the XO-4

* have a quarter-million dollars to spend on 100 laptops

* convince the OLPC project to give you one so you can develop educational software for it [1]

If you buy (or hear someone talk about buying) an OLPC laptop, it's almost guaranteed to be an XO-1. Unfortunately, most of the software (including the OS) is now developed against the much more powerful XO-4. This means that the XO-1 is now in a similar state now as it was when it was released -- almost everything is slow, and your precious RAM fills up quickly.

Exemplifying the state of the XO-1 laptop is a memory leak [2] in Sugar (the desktop UI). On the 1-2GB XO-4, it is not considered a problem:

> The leak has negligible impact on XO-4, XO-1.75 and XO-1.5. On these laptops we recommend that you restart Sugar at least weekly.

In the XO-1, however, idle memory consumption is easily 150 MB, and you can run out of memory in less than one day. The official fix is:

> On the XO-1 we recommend that you restart Sugar every few hours

I feel bad about the whole situation. The OLPC organization seriously tried to make Alan Kay's Dynabook real, and they produced a really cool piece, well-designed piece of hardware. (Not to mention a very well-documented hardware-software pair. [3][4]) It's a shame that they got in way over their heads by trying to develop the hardware, develop drivers for the hardware, develop a custom desktop environment, develop child-friendly userspace applications, and sell them in single quantity, defend themselves from critics, and also attract sales contracts from foreign bureaucracies.

[0] https://tech.slashdot.org/story/08/05/15/2320243/microsoft-a...

[1] http://wiki.laptop.org/go/Developers_Program

[2] http://wiki.laptop.org/go/Release_notes/13.2.9#Sugar_Memory_...

[3] http://wiki.laptop.org/go/XO-1/Software_specification

[4] http://wiki.laptop.org/go/Hardware_specifications

Sugar wasn't just written in Python. Parts of it were literally coded in the worst way possible. We're talking Daily WTF levels.

For example, the icon for each Sugar "activity" was an SVG file. When you started an activity, its icon would "throb" in the center of the screen, fading in and out. Guess how the throbbing was implemented.

That's right, it would perform string substitution on the SVG file, filling in the actual colors for macros embedded in the SVG, then reparse and redisplay the SVG. For each frame.

Had it been a simple matter of being written in Python, Sugar might've been usable. But it was shitty Python and that's what killed it.

> The hardware was not designed in conjunction with the software

You're definitely right on that. The hardware took long enough to design, but the software wasn't even done when they started shipping.

> the resistive tablet

For people not familiar with the XO-1, it originally included a weird touchpad. The center third was capacitive, and would work with fingers. The Entire pad was resistive, and would work with a stylus (which was never shipped).

The dual resistive/capacitive was unreliable [0], and was eventually replaced [1] with just a capacitive touchpad with the same area as the original touchpad.

> the low-power-mode

This was a real shame to leave out. The OLPC XO-1 includes a specialized display controller [2] which can drive the display even while the CPU is suspended. THe idea is that the CPU would render one ebook page at a time and sleep between page turns. Unfortunately, the software for this was never implemented. All the rest of the hardware is there; it would have been really cool to have a near-zero-power ebook mode!

> several of the hardware buttons (including most of the ones next to the screen, which were mapped confusingly to arrow keys)

I'm not quite sure what you mean here. All of the keys on the keyboard are mapped [3]. The only ones I can think of which aren't used for much are the progressive dots (F5-F8), which are intended for application-specific use [4].

The buttons around the screen are mapped to the arrow keys (on the left side) and Home, End, PgUp, and PgDown (on the right side). I really like this, because when you fold the screen around into tablet mode, you can easily navigate a document. Reading a PDF or tall web page this way is a pleasant experience.

> the web browser and text editor were [...] standard Linux applications (Firefox and Libreoffice) [...] wrapped in their interface

You're right. The web browser is Firefox with a bunch of XUL stuff, and the document/text editor is AbiWord.

> The Sugar interface, as designed, had some very strange semantics

The idea behind an OS that journals everything you do with it [5] is great. All the power of a VCS, applied to everything you do on a computer. Unfortunately, the implementation in the OLPC is crude and severely hardware-restricted.

> development priority was to build a reverse-engineering suite

This is actually kind of funny, but the only mention I could find is in [6], which is a collective braindump page for software that would be cool to have on the OLPC. Do you have links to any discussion on this?

[0] https://wiki.sugarlabs.org/go/0.90/Notes#OLPC_XO-1_touchpad_...

[1] https://web.archive.org/web/20160825191424/http://lists.lapt...

[2] http://wiki.laptop.org/go/DCON

[3] http://wiki.laptop.org/go/Keyboard

[4] https://wiki.sugarlabs.org/go/Human_Interface_Guidelines/The...

[5] http://www.loper-os.org/?p=249

[6] http://wiki.laptop.org/go/Software_ideas#Technology

I think OLPC should have stayed in demo mode for longer, or focused getting an educational environment that could run ontop of existing PCs. They had a good vision, but the execution either fell short. I would no rather see OLPC concepts built into Chromebooks. I still high hopes for self directed constructivism that leverages low cost computing; after using an OLPC for a little bit I lost luster for the concrete implementation. !BUT! OLPC did spawn netbooks (Asus EEEPC) and then Chromebooks which can be had for nearly the targeted OLPC price point. Chromebooks need better offline modes of operation.

How selfish and arrogant. They should have been using the system and testing the system with end users as often as possible with the goal of shipping a totally functional 1.0 by a fixed date. Look at the totally baked systems with long lifetimes (C64, 512k Mac, Apple 2e) in the education space. OLPC was too ambitious with not enough clarity.

> I'm not quite sure what you mean here. All of the keys on the keyboard are mapped.

Well, for some values of "mapped". There are a few buttons on the keyboard that have a defined meaning, but no corresponding software functionality, like the "Bulletin Board" key, as well as the progressive dots that you mentioned.

I think the OLPC software we were using might have been an early version, and hadn't yet started using some of the keys next to the display.

> The idea behind an OS that journals everything you do with it is great.

Sure. But using that as the primary system for data storage was questionable. When I used it, at least, there was very little support for naming and organizing saved activities, or for managing storage. This seems like it'd be a pretty serious obstacle to any sort of serious educational use.

> Do you have links to any discussion on this?

Not offhand. This was ~10 years ago! I think it was on the OLPC wiki somewhere, but it might have been deleted. Or my memory might be faulty. :)

What's probably true in general, though, was that the OLPC/Sugar development team prioritized the development of activities that they thought would be cool or useful, rather than projects which were actually in demand by educators in the target countries.

The keyboard is probably a lot nicer to use if you can fit all of your fingers on it. (I usually use my IBM model M with my XO-1 laptops.) Also, the newer models are available with a chiclet-style keyboard.

As bitwize said, not only is Sugar written in Python, but it's also badly written. In one of my other comments in this thread, I mentioned the memory leak [0] which has been a problem in Sugar since 2013.

Without Sugar, the experience is better. I run dwm in debian, and it works well as long as I don't have any complicated web pages open. 400 MHz i586 and 256 MB of memory is enough to be useful. The keyboard provides ESC and F1-F12. It's just a little, weird-looking laptop with a transflective display.

I worked on making the Read activity usable in book mode (keyboard folded away, but gamepad buttons usable), and I vaguely recall putting in an ioctl to put the CPU to sleep after you turned a page, but I'm not sure if my changes made it in.

http://lists.sugarlabs.org/archive/sugar-devel/2007-May/0024...

http://lists.sugarlabs.org/archive/sugar-devel/2007-May/0025...

One of the positive outcomes of the OLPC project was the "stone soup" effect, in that it inspired many different people and companies to contribute useful ingredients, which could be folded back (or spun out) into other independent projects.

https://en.wikipedia.org/wiki/Stone_Soup

For example, the "tickless kernel" power saving stuff in the Linux kernel that consolidates bunches of non-exact timer wake-ups to all happen at the same time came out of RedHat's work on the OLPC project.

https://access.redhat.com/documentation/en-us/red_hat_enterp...

EA released the original SimCity source code for the OLPC, under GPLv3, so it could be ported to other platforms and further developed (under a different name, Micropolis).

https://arstechnica.com/information-technology/2007/11/origi...

Sugar had a long way to go, and wasn't very well documented. They were trying to do too much from scratch, and choose a technically good but not winning platform. It was trying to be far too revolutionary, but at the same time building on top of layers and layers of legacy stack (X11, GTK, GTK Objects, PyGTK bindings, Python, etc).

Sugar was written in Python and built on top of PyGTK, which necessitated buying into a lot of "stuff". On top of that, it used other Python modules and GTK bindings like Cairo for imaging, Pango for text, etc. All great industrial strength stuff. But then it had its own higher level Hippo canvas and user interface stuff on top of that, which never really went anywhere (for good reason: it was complex because it was written for PyGTK in a misshapen mish-mash of Python and C with the GTK object system, instead of pure simple Python code -- hardly what Alan Kay thinks of as "object oriented programming"). And for browser based stuff there were the Python bindings to xulrunner, which just made you yearn for pure JavaScript without all the layers of adaptive middle-ware between incompatible object systems.

The problem is that Sugar missed the JavaScript/Web Browser boat (by arriving a bit too early, or actually just not having enough situational awareness). Sugar should have been written in JavaScript and run in any browser (or in an Electron-like shell such as xulrunner). Then it would be like a Chromebook, and it would benefit from the enormous amount of energy being put into the JavaScript/HTML platform. Python and GTK just hasn't had that much lovin'.

When I ported the multi player TCL/Tk/X11 version of SimCity to the OLPC, I ripped out the multi player support because it was too low level and required granting full permission to your X server to other players. I intended to eventually reimplement it on top of the Sugar grid networking and multi user activity stuff, but that never materialized, and it would have been a completely different architecture than one X11 client connecting to multiple X11 servers.

Then I made a simple shell script based wrapper around the TCL/Tk application, to start and stop it from the Sugar menus. It wasn't any more integrated with Sugar than that. Of course the long term plan was to rewrite it from the ground up so it was scriptable in Python, and took advantage of all the fancy Sugar stuff.

But since the Sugar stuff wasn't ready yet, I spent my time ripping out TCL/Tk, translating the C code to C++, wrapping it with SWIG and plugging it into Python, then implementing a pure PyGTK/Cairo user interface, without any Sugar stuff, which would at least be a small step in the direction of supporting Sugar, and big step in the direction of supporting any other platform (like the web).

Open Source Micropolis, based on the original SimCity Classic from Maxis, by Will Wright -- PyGTK interface: https://github.com/SimHacker/micropolis/tree/master/Micropol...

Pie Menus on Python/GTK/Cairo for OLPC Sugar, by Don Hopkins. http://www.donhopkins.com/drupal/node/128

None of that work would have been possible without the OLPC project, which inspired EA to give SimCity away for free in a way that made it possible to port it to other platforms.

So I believe some good did come out of the OLPC project, including some interesting discussions about constructionist education, visual programming and teaching kids to program, with Alan Kay, Guido van Rossum and others!

HAR 2009 Lightning Talk Transcript: Constructionist Educational Open Source SimCity, by Don Hopkins. http://micropolisonline.com/static/documentation/HAR2009Tran...

SimCity for OLPC (One Laptop Per Child): Applying Papert's Ideas About Constructionist Education and Teaching Kids to Program: http://www.donhopkins.com/drupal/node/129

Alan Kay on Programming Languages: http://www.donhopkins.com/drupal/node/132

Alan Kay's ideas about SimCity for OLPC: http://www.donhopkins.com/drupal/node/134

Responding to Alan Kay's criticisms of SimCity: http://www.donhopkins.com/drupal/node/135

OLPC Visual Programming Language Discussion with Guido van Rossum and Alan Kay: http://www.donhopkins.com/drupal/node/137

Discussion with Alan Kay about Robot Odyssey: http://www.donhopkins.com/drupal/node/139

Ideas about OLPC SimCity GUI, Turtle Graphics, and Cellular Automata: http://www.donhopkins.com/drupal/node/141

Redesigning the SimCity User Interface for the OLPC: http://www.donhopkins.com/drupal/node/142

OLPC Visual Programming Languages for Education: http://www.donhopkins.com/drupal/node/143

SimCity Rules: http://www.donhopkins.com/drupal/node/145

A related question: in your opinion, what were the successes and failures of the OLPC project, what openings and obstacles contributed to that, and where do we go from here? https://news.ycombinator.com/item?id=11942313

>Even if we didn't achieve those goals for Sugar, we made progress in the right direction that have their own benefits independent of Sugar.

>Choose your lofty goals so that when projected onto what's actually possible, you still make progress!

> the Inferno port tended to run better.

Cool. I hadn't heard about this! It looks like it's being actively maintained on bitbucket, too! [0]

It looks like someone else also got Plan9 booting on the OLPC [1].

[0] https://bitbucket.org/inferno-os/inferno-os/

[1] http://gsoc.cat-v.org/people/ameya/blog/2007/08/19/1_Plan9_K...

> That's right, it would perform string substitution on the SVG file, filling in the actual colors for macros embedded in the SVG, then reparse and redisplay the SVG. For each frame.

That's intriguing!

I can imagine a path to how they got there:

1. PyGTK (or whatever they were using) has methods to load and display an image.

2. A supported image type is svg+xml

3. SVG is vector graphics. Awesome! Let's use that.

4. Animation is needed, so we consider just ramping the opacity attribute, scaling attribute, etc.

5. We don't have any methods for DOM access. Oops.

6. However, we do have our loaded SVG file which is just plain text.

7. Well, we can just s/OPACITY/RAMP_VALUE or whatever and display that for our animation. That at least doesn't require a read from the harddrive for each frame. :)

Speaking of which-- I've seen developers do animation by repeatedly reading a file from the harddrive in the same process/thread as a realtime audio engine.

Edit: clarification

> Unfortunately, the software for [the low-power DCON mode] was never implemented.

For what it's worth, I was the OLPC employee working the most on the software for this, and it worked and shipped. I recall that there were serious hardware bugs that went unfixed until XO-1.5 and XO-1.75, but just those two models add up to millions of deployed laptops in the field that were using this CPU-off-screen-on mode when idle. If you've ever seen the power LED off or flashing on an XO while the screen is on, it was using this DCON mode.

As much as I like Python for data analysis, I do not understand why a very high level language was chosen to write a GUI window manager.

Was Python chosen as the technology stack by someone inexperienced in developing operating systems?

Good explanation. The common phrase is "boiling the ocean", and seems to happen to a lot of organisations populated by bright, but inexperienced people.

I uh...I don't remember for sure, but I can't guarantee that the Sugar code didn't reload the SVG file from disk for each frame.

The whole thing was madness, all the way down. It's a wonder it worked at all.

At 24 FPS that gives you a total of 41.67 milliseconds to fetch the file from the harddrive, parse it, and display it.

The harddrive was flash memory, no? So we're probably talking hundreds of microseconds to read the file into memory. Let's say 670 microseconds for a rough guess.

That still leaves 41 milliseconds to parse and display the file.

Of course the animation is happening at an arbitrary program's load time which is probably particularly CPU heavy. But OLPC apparently had two cores, so the process controlling the SVG animation should have been able to safely hit its deadlines.

I'm going to guess that the animation was smooth when trivial consumer single-process apps were loaded and janky when something like an office application was opened.

Am I right, or was it always janky?

Here are some technical notes I wrote up about the OLPC XO-1 and its unique display and hardware, problems and successes, etc, back around November 2008:

http://donhopkins.com/home/documents/OLPC-Notes.txt

OLPC: One Laptop Per Child (XO-1)

Summary by Don Hopkins (dhopkins@DonHopkins.com).

+ Mission

  + Education. 
    Educational content, games, simulations, learning tools, 
    programming languages.
  + Literacy. 
    eBook, creative writing, journalism.
  + Constructionist learning. 
    Seymour Papert, Alan Kay.

+ Goals of the XO-1 Hardware Design:

  + Minimal power consumption, with a design target of 2-3 W 
    total power consumption.
  + Minimal product cost, with a target of $100 per laptop for  
    production runs of millions of units. 
  + A "cool" look, implying innovative styling in its physical 
    appearance. 
  + E-book functionality with extremely low power consumption. 
  + The software provided with the laptop should be open source 
    and free software. 

+ Display

  + Designed by Mary Lou Jepsen.
  + 1200x900, 200 dpi, 6x4 inch (152.4x101.6 mm), 6 bits (262k colors).
  + Pixel size 0.127 mm, about 1 arc minute. 
  + You can always see 200 dpi grayscale, even in direct sunlight. 
    (reflective layer)
  + You can get color from the LED backlight. 
  + Colors wash out as the sunlight gets brighter.
  + The backlight uses power (though not nearly as much as cold cathode
    fluorescent backlight).
  + You can turn the backlight down or off to conserve power. 
  + Turning off the backlight tells screen to give slightly higher 
    resolution, to make reading comfortable. 

  + Display Design Goals: 
    + Maximize the number hours of ebook reading.
    + Minimize the power consumption.
    + Maximize the resolution and readability.
    + Mesh with how human perception works.
    + Display sharp high quality text, that's easy on the eyes 
      during the day (reflective) and night (backlight).

  + Critical design innovations:
    + Remove the subtractive color filters that absorb 85% of the light.
    + Replace them with plastic diffraction gratings and lenses, 
      stamped like DVDs. 
    + Much brighter display for a given amount of backlight.
    + Can be manufactured with existing technologies and processes. 
    + Uses efficient environmentally friendly LEDs,
      instead of fragile, expensive, high voltage, cold cathode 
      fluorescent lamp backlights.

  + Combination of two separate screens: sharing an LCD glass. 
  + One normal backlit screen.
  + Another normal reflective screen. 
  + LCD is 1200x900 square grid, with 64 gray levels (6 bits).
  + Off pixels transparent, on pixels opaque. 

  + Backlit screen shines through a color filter on the 1200x900 grid. 
  + Filter gives each pixel just one color: red, green, blue. 
  + Individual grayscale pixels behave like sub-pixels of a normal 
    backlit display. 

  + Reflective screen has reflector behind LCD grid. 
  + Room light passes through grayscale LCD and bounces off of back
    reflector. 
  + 1200x900 pixels depending on ambient outside light to display. 
  
  + The light the user sees comes from both sources (reflected outside 
    light plus filtered backlight).
  + Color filters use fresnel prisms to pass most light, instead of 
    color filters that absorb most light, wasting less energy. 

  + The amount of color and perceived resolution depends on backlight
    brightness and outside light level. 
  + The ambient light level of the room changes the perceived 
    resolution of the display.
  + In direct sunlight you see the reflective screen (exactly 1200x900, 
    200 dpi),
  + In a dark room you see the backlit screen (approx. 800x600 
    perceived, 133 dpi), 
  + In between you see both (approx. 1024x768 perceived).
  + The "official story" is "1200x900 mono resolution, 
    693x520 color resolution". 

  + Screen layers:
    + LED backlight.
    + 1200x900 grid of color filters (fresnel prisms).
    + Semi-reflective layer.
    + 1200x900 LCD.
    + Each pixel has a single color behind it.
    + Colors are arranged in a diagonal pattern.
    + Each pixel has:
      + Fixed hue (r, g or b).
      + 6 bits (64 gray levels) of luminance.
      + Chrominance depends on relative strength of room light 
        to backlight.

  + DCON screen driver chip
    + The screen can stay on while the processor is turned off. 
    + Automatically interpolates ("swizzles") lower resolution color 
      pixels, so the unusual screen format is invisible to software. 
    + Looks just like a regular 1200x900 color framebuffer to software. 
    + DCON has different modes:
      + Monochrome.
      + Color swizzled antialiased.
      + Color swizzled not antialiased.
      + Video pass through.

  + Power saving techniques
    + Uses low power LEDs instead of high voltage cold cathode 
      fluorescent backlights. 
    + Turns off processor while leaving the screen and wireless 
      network on. 
    + Uses fresnel prisms to split most white light into primary 
      colors, instead of color filters to throw away most light. 
    + Turn down refresh rate.
    + Dynamically turn off sections of the screen.

+ Green Electronics

  + Order of magnitude less power consumption. 
  + Designed to use as many environmentally friendly components 
    as possible. 
  + Fully compliant with EU's Restriction of Hazardous Substances 
    Directive (RoHS). 
  + One of eight laptops to receive EPEAT's Gold rating for 
    environmental performance.

+ GPS

  + A future version of the OLPC may include a built-in GPS!
  + The OLPC project needs GPS mapping sofware and low resolution 
    maps, which kids can improve, to map out the areas of the world
    where they live.

+ Software

  + OpenFirmware Forth BIOS loader boot ROMs.
  + Pared-down version of Fedora Linux.
  + Custom web browser based on Gecko engine (xulrunner + Cairo) used 
    by Mozilla Firefox. 
  + Word processor based on AbiWord. Paint program.
  + Email via web based services. 
  + Online chat and VoIP programs.
  + Many programming languages:
    + Python, JavaScript, Forth, Csound, eToys (visual, Squeak 
      Smalltalk), Logo (visual), TamTam (visual).
  + Music sequences with digital instruments: Jean Piche's TamTam.
  + Audio and video players. 
  + RSS news reader. Calculator. 
  + Games: SimCity. Tetris. Connect. Others in development. 
  + Educational software and content. Wikipedia. 
    Internet Archive. E-books. Scanned books. PDF files.

  + Python is the primary programming language for the "Sugar" user 
    interface and applications. 

  + Important Python modules and libraries:
    + Sugar graphical user interface, written in Python, with GTK, 
      Cairo and Pango.
    + GTK user interface toolkit for X11.
    + Cairo rendering library (hardware accelerated Porter/Duff imaging
       model, like PostScript).
      + Great for efficiently drawing high quality antialiased maps 
        with high quality scalable graphics and text, with hardware
	acceleration.
    + Pango international text rendering library. 
    + Pygame computer game programming module (graphics, audio, 
      input, etc). 
    + Mozilla xulrunner (Firefox Gecko web browser component).
    + PyXPCOM Python/XPCOM integration module (enables Python and 
      JavaScript to script the browser, share objects and call each 
      other).
    + Many other high quality Python modules.

  + Project Status: October 2008
    + About half a million XO-1 units out in the field.
      Most are in South America.
      + Afghanistan, Brazil, Cambodia, Columbia (65,000 ordered, 700
        pilots), Ethiopia (5,000 shipped), Ghana, Haiti (7,000
        shipped), India, Iraq (200 shipped), Mali, Mexico (50,000
        ordered), Mongolia (10,000 shipped), Nepal, Nicaragua, Nigeria
        (300 shipped), Niue (500 shipped), Oceania (5000 shipped),
        Pakistan, Peru (260,000 ordered, 20,000 shipped), Philippines,
        Rwanda (5,000 shipped), Tanzania, Thailand, USA (Alabama
        (15,000 ordered), Massachusets, New York, Virgin Islands),
        Uraguay (100,000 ordered, 10,000 shipped), Yemen.
    + You can buy an XO-1 on eBay now, for $90-$200.
    + G1G1 program ran last year.
    + G1G1 v2 program in America will be run by Amazon, 
      starts mid November. 
      + A new G1G1 program has been announced for Europe, beginning on
	November 17, the same day as the US program starts.
	+ The price will be around $399, 312 EUR (no VAT will apply,
	  only shipping cost).
	+ The 27 member states of the EU, plus Switzerland, Russia and
	  Turkey are included.
	+ Where to get them: http://www.amazon.com/xo
	+ More info about OLPC Foundation Europe: http://www.olpceu.org
  + Latest Changes
    + The new version of XO-1 has slight revisions to the circuit 
      board, changing a few things, because parts they are using 
      going obsolete. Trying not to change it much. 
    + Making versions of XO-1 with more RAM and more flash memory.
    + Revamped basic sugar interface.
    + Software support for low power consumption is coming along.
      + New software release is going in the can this week. 
      + Suspends when you close the laptop.
      + Turns off WiFi chip while in suspend unless actually on mesh.
      + Will sit in suspend for 2 days, which John timed.
      + User interface for power saving modes.
      + Sugar control panel, extreme power saving mode without WiFi, 
	saves a watt.
      + Advanced power management mode, goes into suspend when machine 
	is idle, leaves machine on, powers off CPU.
      + Still has a bunch of bugs around the edges:
	+ Sharing over the net, presence service screws up sometimes, 
	  but basically works. 
	+ Need to figure out how to decide whether a laptop is there 
	  or not.
	+ Multicast port, machine wakes up when it gets a multicast 
	  it's interested in, but it always wakes up because protocol
	  does too much milticasting, busy protocol, otherwise the 
	  world thinks laptop goes away.

  + The next version: XO-2
    + The X0-2 exists playdough mockup, looks like paperback with 
      2 hires multitouch screen, no keyboard.
    + No working hardware for that stuff.
    + Jim Gettys stopped working on other things, and is now working 
      on full blown multi touch support in X servers.
    + Price target is $75 for the XO-2, but that seems unlikely.

  + Mesh Networking Problems
    + Mesh networking stuff still does not work well.
    + Not using mesh networking in most schools, since it does not 
      scale to more than 10 laptops.
    + 30 laptops in room all on mesh melt down the network talking
      to each other.
    + Can't reliably do TCP on a busy mesh network, because computers
      are too busy doing status updates.
    + The problem is complicated with using multicast, which have to
      get repeated throughout the mesh.
    + The idea of sticking laptops in a room and they see each other
      is a good idea. 
    + School servers should put up standard WiFi access points.
    + Mesh networking still useful if small deployment scattered 
      across whole village.
    + Don't use mesh networking for larger tasks than 10 or 15 laptops.
    + Could improve it with more work.
    + Work should go into getting colaboration protocols (independent
      of mesh networking) out into generic Linux world.
      + AbiWord should be able to share across internet to edit the same
        document.

  + Windows Compatibility
    + OpenFirmware boot ROMs are now compatible with Windows BIOS,
      so it can boot Windows and Linux without reflashing. 
    + OLPC is not doing any work on Windows, not shipping Windows.
    + Putting all work into Linux based stuff, everything they are 
      shipping is free software
    + OLPC will sell laptops to countries that want to run Windows.
    + Countries must worry about it. 
    + You can't buy that version of Windows in developed countries. 
    + $3 version of Windows not for sale in the US or anywhere people 
      pay full price for Windows, just the "third world".

  + High Expectations
    + OLPC had to recover from artificially high expectations created 
      by the fawning press and Nick Negroponte.
    + The high expectations had to come crashing down eventually.
    + The Windows announcement finally casued it to crash down.
    + Only a few hundred in pilot running Windows. 
    + All the rest are running Fedora Linux.
    + The community needs to be reminded that OLPC is still a free 
      software project. 
    + OLPC is the largest deployment of Fedore anywhere.
      + 500,000 units of Fedore, 50,000 more every month.

  + Successes
    + Two good things have happened to the project in the broader sense:

    1) Spawned this whole netbook thing. 
       + Nobody was doing that before.
       + Now 15 different major companies are doing the same thing. 
       + Finally people are exploring the low cost low power end 
         of the laptop spectrum. 
       + OLPC is still unique in that it was ruggedly designed to be
         dropped and survive. 
       + Other companies have not figured that out yet, and are still
         making cheap low quality laptops.

    2) The free software community is widely in favor of the project. 
        The deal with Microsoft got bad press, and most people in the
	free software community mistakenly think the free software part
	is over, and OLPC is now shipping laptops with Windows. 
	But actually they are not.

It was never smooth, I don't think it ever ran at 24 fps. But the throbbing was slow enough you didn't notice.

There were no "office" applications for Sugar. The closest it got were Sugarized versions of Firefox and AbiWord. The animation, as I recall, was somewhat jankier when attempting to load one of these.

I checked out a few youtube videos like this one[1].

Now I'm wondering whether the lack of smoothness was actually jank or just the choice to animate at a low frame rate.

The animation looks bad but generally uniform in its timing. So I'm guessing whoever coded that just assumed their method of animation was so klunky that they went ahead and set the delay interval to a large value.

It might have helped to use a retro-style step animation, like filling up a cup a quarter at a time where each 1/4 cup is a lighter shade of the same color.

[1] https://www.youtube.com/watch?v=cdUSpkghdA4