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?
I've studied the Sugar design and source code, and programmed Sugar apps and widgets, including wrapping the X11/TCL/Tk version of SimCity [1] in a thin Sugar python script wrapper to make it into an activity, working on reducing the power consumption of the eBook reader, and developing pie menu widgets for Sugar in Python/GTK/Cairo/Pango [2].
My take on the OLPC project is that they were tackling so many interdependent problems at once, both software and hardware, that it was impossible to succeed at its original lofty goals. But it was also impossible to achieve those goals without tackling all of those problems at once. However, a lot of good came out of trying.
It was like the "Stone Soup" folk story [3], that brought together brilliant people from many different fields.
A great example of that effect was that we were able to convince Electronic Arts to relicense SimCity under GPLv3 so it could be used on the OLPC. [4]
One of the many big goals was reducing power consumption, which cross-cut through all parts of the system, requiring coordination of both hardware, software, and the firmware in-between.
Some of the designs were brilliant and far ahead of their time, especially Mary Lou Jepsen's hybrid display, and Mitch Bradley's Open Firmware Forth system.
RedHat modified Linux to support a tickless kernel, consolidating periodic interrupts together to run at the same time so they didn't each wake the CPU at many different times. [5]
Many of the solutions to problem the OLPC project was working on have benefitted other more successful platforms.
John Gilmore credits the OLPC in lighting a fire under laptop vendors to make competing low power low cost laptops like the Chromebook a reality.
Some of the ideas were ridiculous, like the silly crank to charge it.
Sugar had too many dependencies on all the other stuff already being in place and working flawlessly. And its was far too ambitious and revolutionary, while still being layered on tons of old legacy cruft like X11, Python, GTK, etc.
I love Python, but the OLPC came at a time when it would have been a better to implement the entire user interface in JavaScript/HTML.
Sugar app developers realized they needed the services of a deeply integrated web browser (not to mention the ability to run in any desktop or mobile web browser outside of the Sugar ecosystem), but the overhead of plugging xulrunner into Python and integrating JavaScript and Python via XP/COM and GTK Objects was just too astronomically complex, not to mention horribly wasteful of power and memory and simplicity.
You have to navigate the trade-offs of building on top of old stuff, and building new stuff. And I think Sugar chose the wrong old stuff to build on top of, for that point in time. Python and Cairo are wonderful, but JavaScript won, and Cairo migrated down the stack into the web browser rendering layer, HTML Canvas component, etc.
Also there was no 3D acceleration (or OpenGL/WebGL), which was a big disappointment to game developers, but at the time it was necessary to keep power usage low.
I'll try to specifically address your question about Sugar's appropriateness for the task and what's good and bad about it. I'll quote some stuff I wrote about it when I was porting SimCity to Sugar (prefixed by ">), and then make some retrospective comments (no prefix): [5]
>Sugar is based on Python, and uses the GTK toolkit, Cairo rendering library, Pango international text layout library, and Hippo drawing canvas, and many others useful modules. Once SimCity is integrated with Python, it will be great fun to create a kid-friendly multi-player user interface that's totally integrated with the OLPC's unique hardware design (like the hires mono/color LCD screen, which flips over into book mode with a game controller pad) and Sugar's advanced features, like scalable graphics, journaling, mesh networking, messaging, collaboration, and (most importantly) applying Seymour Papert's philosophy of "Constructionist Education" to SimCity.
Sugar was trying to reinvent far too many wheels at once.
Python was a great choice of languages, but it was in the process of being eclipsed by JavaScript. Python is strong at integrating native code (its API is easy to use, then there's SWIG, Boost, and many other ways to wrap libraries), and meta-integrating other code (GTK Objects, COM, XP/COM, etc).
But there's an overhead to that, especially when you mix-and-match different integration layers, like for example if you embedded a web browser in a Sugar interface, registered event handlers and made calls on DOM objects, etc.
On top of Cairo for graphics and Pango for text, which are two wonderful solid well tested widely supported libraries used by many other application, Sugar had its own half-baked object oriented graphics drawing canvas, "Hippo", which was written in a mish-mash of Python and GTK Objects. Nobody should have to learn how to wrangle GTK Objects just to draw a circle on the screen.
And there's this thing about universal object oriented graphics representation APIs, which is why the OLPC didn't support PEX, X11 PHIGS Extension (Programmer's Hierarchical Interactive Graphics System), and why we're not all using GKS (Graphical Kernel System) terminals instead of web browsers.
As a Sugar programmer at the time, all parts of the system were in flux, and it was hard to know what to depend on. For the Sugar pie menus, I stuck to the solid Python/Cairo/Pango APIs, with a thin layer of GTK Objects and event handlers.
As for all that stuff about journaling, mesh networking, messaging, collaboration: great ideas, hard problems, fresh snow, thin ice. As Dave Emory says: "It's food for thought and grounds for further research."
Sugar activities are implemented in Python.
What I had to do with SimCity to integrate it into Sugar was to take an existing X11/TCL/Tk application, and wrap it in Sugar activity that just launched it as a separate process, then send a few administrative messages back and forth.
That was also the way Scratch/eToys and other monolithic existing applications were integrated into Sugar.
The idealistic long term plan was to refactor SimCity to make it independent of the user interface, and plug it into Sugar via Python, then finally re-implement the user interface with Sugar.
As progress towards that goal, which was independent of Sugar, I stripped out the UI, refactored and reformatted the code as C++ independent of any scripting language or UI platform, and then plugged it into Python (and potentially other languages) with SWIG. I then implemented a pure GTK/Cairo user interface on top of that in Python (without any Sugar dependencies), and developed some interfaces so you could script your own agents and zones in Python. (As an example, I made a plug-in giant PacMan agent who followed the roads around, turning at corners in the direction of the most traffic, eating cars thus reducing traffic [7], and a plug-in Church of PacMania whose worshippers generate lots of traffic, to attract the PacMan to its neighborhood, and sacrifice themselves to their god [8]!)
As it turned out, the SimCity kernel plugged into Python was also useful for implementing a SimCity web server with a Flash web client interface, which is a much better architecture for an online multi player game than the half-baked, untested collaboration APIs that Sugar was developing.
At the high level, there were a lot of great ideas behind Sugar, but they should have been implementing on top of existing systems, instead of developed from scratch.
>The goals of deeply integrating SimCity with Sugar are to focus on education and accessibility for younger kids, as well as motivating and enabling older kids to learn programming, in the spirit of Seymour Papert's work with Logo. It should be easy to extend and re-program SimCity in many interesting ways. For example: kids should be able to create new disasters and agents (like the monster, tornado, helicopter and train), and program them like Logo's turtle graphics or Robot Odyssey's visual robot programming language!
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!
[1] http://wiki.laptop.org/go/SimCity
[2] http://www.donhopkins.com/drupal/node/128
[3] https://en.wikipedia.org/wiki/Stone_Soup
[4] http://micropolisonline.com/static/documentation/HAR2009Tran...
[5] https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...
[6]
http://www.donhopkins.com/drupal/node/129
[7] https://github.com/SimHacker/micropolis/blob/master/Micropol...
[8] https://github.com/SimHacker/micropolis/blob/master/Micropol...