Evolution Overview

Introduction

Even when Commercial Of The Shelf (COTS) technology becomes available deployment will depend on a spiral evolution with parallel extension of area of coverage, density of adoption and intensity (volume) of use in parallel with growth of available postal and telecommunications facilities, battery power, and resources and capabilities available from senders and receivers of information.

Initial deployment is likely to be further complicated by staged rollout of a system with limited capabilities while development of additional capabilities proceeds.

In particular it is likely that a "podcasting" approach with a small number of channels for essentially a single producer and subscriber (but large numbers of end users) may have immediate application justifying deployment of end user devices (Cardpods) and relay systems (XO laptops).

Subsequent upgrades could proceed through an evolutionary process of:

More Channels and Subscribers

This requires management of storage space and channel capacity with costs shared among multiple subscriber institutions. Some material will be "cross posted" to multiple channels and should be "hard-linked" so it is only stored and transmitted once with costs shared properly among multiple sponsors.

More Control by End Users

This requires registration of changes in subscription parameters for each end user (eg channels of interest and share of space for each) and configuration of relays to implement those parameters (deleting old messages to make room for new ones when flash cards are updated).

Feedback

This requires compression and routing of recordings made on end user devices (Cardpods) back up towards the original publishers.

Voicemail

Full two-way communications can be conceived as an extension of "podcasting" with communications in each direction between a particular pair of parties treated as a pair of channels. Nevertheless it requires significantly more sophisticated systems including directory, registration and billing systems. This is more like Teleco systems than OLPC but is the only plausible source of revenue as opposed to "mere" social benefits.

OLPT

Use of school XOs as more than a relay appliance including One Laptop Per Teacher requires additional development although still less complex than for OLPC.

ICT Kiosks

Provision of public access to messaging, information queries, phone calls etc through school and teacher computers raises serious problems of remote systems administration and payment systems.

Software Updates

Reliable software updates for both XOs and embedded end user devices (Cardpods) will clearly be essential even after a fully developed COTS technology is available. The XO software from OLPC is still not mature and a crisis in funding for both OLPC and Sugar Labs makes it likely that problems will persist at least until the end of 2009. This does not change the fact that the XO is the only plausible solution for deployment in areas with no electricity grid and that the hardware will continue to be available for that purpose. But it does imply that software updates will be more frequent and more important than might have been assumed.

Simultaneous development and deployment implies that this update capability has to be there from the start. There is simply no way to do large numbers of manual updates to tens of thousands of remote systems that don't even have network connectivity.

Thus fully automated reliable remote updates via physical media have to be implemented before initial deployment. This overlaps with some of the requirements for later stages, but can be thought of as a (postal) podcast channel carrying (signed) software updates that get applied automatically on reception.

Significant system administration skills will be required at the central site for this as well as extensive testing and careful management of signed releases. Any faulty release could disable thousands of XOs in remote locations. Such skills can be acquired by a motivated team with some minimal linux experience supported by mentoring, perhaps including (expensive) commercial support like that supplied by companies like Red Hat for large scale commercial linux deployments (and also OLPC XO deployments). Mentoring via the internet is a normal way for system administrators to acquire their skills and should be much cheaper than expatriate staff. In view of the importance of experience in acquiring such skills, and the long lead time involved in acquiring experience, it may be important to establish such a team as early as possible and assign it other responsibilities for feasability study, development, procurement and support for other linux deployments in the meantime.

Previous methods for customizing the XO image using Pilgrim or Puritan were unacceptably complex and put a major strain on limited sysadmin resources and will probably be obsoleted by changes resulting from the OLPC funding crisis and merge into Fedora.

Well managed international and national repositories mirroring upstream distributions and projects and something closer to tools used for Fedora remixing spins like Revisor should conceal the complexities of other tools like Pungi and Anaconda  kickstart examples and be integrated with build and test procedures that require final approval by more than one reviewer before a signed release can be created but do not need additional work beyond the selection and testing of new and updated packages. Creation of such repositories should start early, using tools like mrepo and existing repositories for particular upstream packages and distributions like those maintained by OLPC, Fedora and  Red Hat Enterprise Linux derivatives such as Centos or Scientific Linux. These are also potential sources for mentoring or commercial support. Local selections would be made and tested from the main distributions and supplementary software from repositories like rpmfusion plus any project specific packages.

Some relevant tools include:

image-digestor - enables use of secure signed reflash.

rpmxo - rpm-based small system images for the OLPC XO-1 based on rinse and debootstrap.

 Fedora Appliance Tools.

It is expected that the next OLPC XO software release (previously called 9.1) will be included in Fedora 11 or 12 and include a general capability to simply install additional Fedora application packages using yum. That should greatly simplify these issues but implies little can be expected before the end of 2009.

In addition future releases will directly support simplified image customization and image signing key delegation and also provide GUI for local software updates.

Fedora 10 itself already supports a live usb creator Sugar spin and can be placed on an SD card to boot on an XO, as described in the How To Create and Use Live USB (based on similar for Live CD) or using the -xo flag with the Live USB Creator GUI. The fedora OLPC Special Interest Group and former staff of OLPC intend to include the 9.1 release no longer feasible due to OLPC funding crisis as software merged within mainstream Fedora 11 or 12 (December 2009) for future development as part of Fedora. The work that has to be done for that both illustrates the necessity of having a local distribution remix capability and will make it feasible to do so.

If required, the anti-theft security features planned for OLPC will also require a local security server operated by the local sysadmin team as there is little likelihood of OLPC being able to operate that service.

The lighter weight Xfce desktop is recommended instead of Gnome for use on XO.

The JHbuild tool is used for maintaining complex collections of source code packages, like Sugar and Gnome that may need to be patched locally while waiting for local changes to be included upstream. It can be used with all the relevant advanced distributed revision control software used in typical FOSS development for maintaining local copies and contributing upstream.

A team with the system administration skills necessary for these functions is useful for supporting all kinds of ICT activities in any developing country. The proposed FOSS college at Nepal's IT park at Kavre could be a suitable location for such a team to be established early and benefit from ongoing mentoring by email and chat from contacts with participants in international FOSS conferences held there. There would be work for them immediately on RHEL derived deployments (in less difficult environments with power and telecommunications) for many different government, NGO and commercial purposes, in the course of which they would gain sysadmin experience.

Details on creating a variant distribution (Fedora spin) using kickstart files can be found in this example of online mentoring via internet chat.