Formatting and Review for Tutorial Handout (Oh, and some paying work...)


Spent the bulk of yesterday on paying work, solid day of billables down at the Caffe. Nothing all that interesting, just some refactoring of a view, scripting a maintenance task, that kind of thing.

Then started working on the tutorial handout (due end of this week). Got about 1/3 through editing when Paul came in. Spent the rest of the afternoon chatting with him (and Dave) about his (their) business model, elevator pitches and value-adds... surprisingly satisfying... I could imagine doing that kind of stuff for a living, helping people think through complex people-side issues for their technology-side businesses.

Back to the tutorial; it's looking good. About 22 pages in handouts including one optional section (the Telepathy networking version of the game). The introduction/slides will need a bit of editing and I need to put together the "current state of the games" section for that.

One thing I'm definitely going to have to change is the power-usage figures. My old decks all still state the planned power consumption of 2W... somehow I never got the memo that we'd overshot by 350% (!!!) on that particular target (I hate that kind of error, it undermines the reliability of all the discussions that were based on the value!). I'd thought the change we'd seen was from an original 1W up to 2W. We're consuming 2W even when fully suspended, let alone in e-book mode (3.5W), our best "useful" mode (which was originally going to be a sub-1W mode IIRC).

That means that the 1:10 ratio for the manual chargers that people were putting forward is dead, it would be maximum 1:6 if a child can put out ~20W (for longer periods than previously thought) and doesn't need a backlight or much processor power. It drops to 1:3 if they need to run indoors (backlight) or use a demanding application.

That makes individual-child-powered manual chargers far less attractive as a power source (treadle-style or bicycle-style could still work nicely, but anything requiring interruption of usage for 1/4 of your time is getting annoying, that's 1.5h of calisthenics for your 6h school day). Solar is apparently producing around 10W of power if I'm recalling correctly, so that should work fine, but wouldn't charge you up all that much for night usage.

I guess it's possible we'll reverse some of the losses with aggressive suspend, but it seems unlikely we'll get much below 3W without some changes e.g. to the policy of always having the mesh repeater powered, or some extremely clever low-level hacks (which may IIUC involve reworking some part of mDNS or something like that).

Which leads to an interesting question I was asked yesterday (I've been asked it a large number of times before, but yesterday was interesting because I've had some time to get more perspective on the project):

"Can they succeed?"

and surprisingly, my answer is still a "yes".

Yes, the power envelope is much larger than originally planned, but the hardware/systems people can likely find a solution that lets 90% of the kids use the machines, whether it be gang chargers at the school, or solar panels, or what have you.

Yes, the porting process is still far too involved, but we will some day get to the point where a standard Linux application can run "normally" in the system to fill a need without needing any particular porting (we're already seeing that start with the hack-the-X-server wrapper for C applications).

Yes, the development story is still lacking, but we have a reasonable IDE in development, OLPCGames is now becoming a viable environment for writing games, the XPCOM+Python story is starting to shape up, and EToys continues to be solid, we're getting documentation collected and generated automatically by the build process so that devs can actually figure out what's going on, and the Developer's Manual seems to be reasonably effective as a starting point.

Yes, there are other manufacturers looking to "eat our lunch", but heck, let them if they can deliver better, our egos aren't important enough to stand in the way if they have a better solution and can address the whole need (not just the richest segment of the poor) and if they can avoid shady tactics and actually focus on educating children.

In short, like all large IT projects under intense time pressure, the project is running into problems and inefficiencies, but there are enough of us world-wide who believe that the only way the world as a whole can survive, physically, socially, politically and morally is to dramatically improve the quality of education of the children of the world, that we can overcome those problems and find ways to eliminate the inefficiencies.

In short, we can succeed.

Or, at least, that's what I think.

Comments

  1. Tom Hoffman

    Tom Hoffman on 02/27/2008 11:54 a.m. #


    I think OLPC can succeed, as long as they can keep XO's in production. The only question is, can the keep making hardware while the software is being worked out?

  2. Charles Merram

    Charles Merram on 02/28/2008 12:17 p.m. #


    To which IDE are you referring?

  3. Mike Fletcher

    Mike Fletcher on 02/28/2008 1:42 p.m. #


    IDE I was referring to is "<a href="http://z3p.jot.com/DevelopActivity">Develop</a>" IDE currently being worked on. There are probably a few others, but it's the one I hear about the most.

Comments are closed.

Pingbacks

Pingbacks are closed.