As written before, at the moment we've got two pilot schools, fairly close to our office. We, them and the Department of Education are connected to eachother through a simple network. If something goes wrong software- or hardware-wise, or we need to upgrade XO's, it's fairly easy for us to come over and fix stuff on the same day.
But actually that already is a hassle. Whoever goes to the schools looses a day, and putting new activities on 135 XO's, repeating the same mundane commands, is time consuming. In spring we're gonna deploy a couple of thousands XO's to 15 schools around Nepal. We need automation! And not only that; we also need compartimetalization. Actually we are trying to strike a balance between the easiest way to put content on laptops and the most robust way to put content on laptops.
That is to say, in a country like Nepal you can't count on anything. Take power for example. Our office is located in the center of Kathmandu, the capital. For two days running now we hardly had any power (so I'm filling my time writing blogposts on my XO). For one we have scheduled power outages which total 10 hours a day ('loadshedding'). Rumour has it this will go up to 18 hours a day. Our battery-backup system can't handle that many hours. Also our UPS has problems. Something that's gonna happen in the field as well, but then there's no power-engineer present on-site to address the problem.
A related issue is the fickleness of internet connections. Often we at the office don't have internet because of problems at our ISP or with the connection from Nepal to the outside world. And of course no power automatically means no internet. And this can happen on a number of levels. Our schools are connected to the internet through the computer-lab at the Department of Education (DoE). And DoE is equally affected by loadshedding. Last week we discovered that the capacitators there can't handle the power-requirements of the battery-rig we set up in the lab. No power at DoE, no internet for the schools.
And it's not just about internet access. We're gathering more and more content for the kids to use during their classes. Way more than we can put on their XO's. So they need a way to access that information, and we need a way to easily update this information. An ideal scenario would be putting that content on a central server and to let all kids access that content on-demand. An additional benifit is that kids from non-pilot-schools can also benefit from our efforts. But because of network and power issues we can't rely on a central server alone. And this is where things get messy. So software-wise, what we're sort of trying to create a little three-layered system.
At the top there's a central server, capable of upgrading the schoolservers and able to serve all our content to everybody that has access to the web.
The schoolservers have a local copy of all the content, since we can't count on the central server. The schoolservers should be able to upgrade the XO's. Both the system software and the content, which both have different requirements.
The XO's themselves of course.
Upgrading the system-software is the least of our problems. Right now we use olpc-update from local servers who get custom builds, made by Pilgrim, from the central server. Upgrades will be pushed only once in a while. Content is a different problem. Since we can't count on the schoolserver being up all the time we need to have content on the XO's themselves. But since we've got too much content, some should stay on the server.
Our plan is to have the content needed for specific lessons of the current week, the last week, and the next week on the XO. If the kids want or need to access more info, they should be able to get it on demand. And all of this should be transparent and automatic. We're gonna use Moodle to specify the content for all the school-weeks on the schoolservers. We're gonna use google gears to cache three weeks of content on the XO's. If for a specific week the content is not to be found locally, the XO's should go to the schoolserver and get it there.
Most of the stuff cited above is being worked on. We've got a lot of content. We've got a central server for that content. We're putting the last touches on our customized version of the OLPC schoolserver software (0.4 atm). Thanks to XO version 8.2 we can update our own set of activities from our local server. We've got our own Pilgrim XO baking factory. Olpc-update:ing from a local schoolserver works fine.
What doesn't yet works is the whole Google Gears/Moodle setup. Moodle is set up properly but Google Gears hasn't had enough love yet. Our in-house developed content also isn't yet integrated yet, but our individual activities made in both Squeak/Etoys and Flash, can easily be split up and accessed through the web individually.
Also we don't yet have a mechanism in place to update individual schoolservers from a central server. And again we need a separate mechanism for system-software and content. This is the only aspect we haven't worked on at all so far, but we still have a few months till the deadline in mid-April. Should be time enough... we hope...
[...] software infrastructure - a well functioning, customized XO image - a good plan to set up networks for these schools - [...]