Summary

  • OLPC's 2007 connection guide separated hotspot Wi-Fi, a school-server mesh and a simple mesh for direct XO-to-XO collaboration. The last mode let children reach one another; an Internet route required a gateway and an upstream connection.
  • OLPC's July 2009 deployment guide assigned shared services and the Internet portal to a school server. Its planning tables added a PC, access points, storage and maintenance as the deployment grew. The attractive word “connected” carried two different bills.

The radio could find a classmate

The appeal of the XO's mesh was easy to see from a school with no convenient hotspot. Each laptop had a wireless card. A child could find another XO, join a shared activity and send traffic across nearby machines. OLPC's connection instructions, captured in December 2007, gave users three choices in the Neighborhood view: an ordinary Wi-Fi access point, a mesh with a school server, or a “simple” mesh. The guide describes the simple mesh as a way to collaborate directly with other XOs. That small sentence is the hinge of the story. Local conversation and access to the wider Internet were different achievements, even when both began with the same radio icon.

The OLPC networking page described a wireless chip capable of relaying traffic while the laptop's main processor slept. It also discussed an active antenna that could attach a server or another computer to the mesh, or simply repeat packets when powered. The design made the XO more than an endpoint: it could help carry its neighbor's traffic. A classroom with several machines gained a path among children without first putting a cable at every desk.

That path had a limit. The same OLPC networking page expected schools to obtain Internet access and a school server. It assigned the server a gateway and proxy role for web traffic, email and network time, and called it a beacon for sharing Internet connectivity. Its deployment section warned that some capabilities remained work in progress and that hop count, latency and bandwidth needed field testing. The mesh could distribute reach inside the group. It could not manufacture the upstream circuit at the far end.

This is where a generous metaphor can become a budget trick. Saying that a child holds a “connected laptop” might mean the machine can see a neighboring machine. It might mean it can reach a local library. It might mean it can fetch a page from the open Internet. Each meaning requires another piece of infrastructure. The radio is in the child's hand; the Internet contract is somewhere else.

The second computer enters the classroom

OLPC's school-server description is refreshingly direct. The XO is self-sufficient for many learning activities. Other activities and services depend on additional infrastructure. The XS school server was designed to provide connectivity, shared resources, storage and processing on a generic low-end Linux machine. In practical terms, the project that put an individual computer in every child's hands also needed a shared computer whose failure or absence would be felt by many children at once.

The July 2009 deployment guide made that dependence concrete. It described the school server as a local library and a mesh portal to the Internet. It could bring together as many as three separate mesh channels. It could host teaching material, backups, software updates, presence and management services. A local collection matters even when the uplink is slow or absent; it also needs someone to choose, copy and maintain the material. The server did real work beyond waving packets out to a carrier.

The guide's planning table kept the exception visible. For fewer than 20 laptops, it said no server was needed, although server functions would be useful. Larger configurations called for a server and rising numbers of access points. The guide warned that the numbers were in flux and required experimentation. That is a deployment recommendation, not a guarantee that 40 or 120 children would receive a stated performance level. The more precise historical fact is the architecture OLPC told operators to budget for: group size changed the number of shared machines and radios needed around the individual laptops.

OLPC also wanted a laptop to act as the school server for small schools. In July 2009, the guide said the goal had not yet been reached and instructed schools to use a basic PC. Here the brand's most elegant picture met a mundane procurement line. A low-power laptop in every bag did not eliminate the rack, the power socket, the disk, or the person responsible for the shared service.

The OLPCorps XO-1 technical guide moved from architecture to setup. An Internet-connected school server needed two network interfaces: one toward the Internet and one toward the local wireless network. Access points paired with it were told to leave DHCP and NAT to the server. The guide asked who would install and maintain that server. Those questions were not glamorous. They determined whether a classroom's packet could leave the classroom, whether addresses were assigned coherently, and who would fix the system after the visiting deployment team went home.

A mesh is not a backhaul contract

The 2007 Ethiopian OLPC planning documents show the distinction before it reached a school timetable. The concept paper imagined children talking across a mesh and roughly 500 sharing one satellite backhaul point. The number described a design assumption, not a measured result. The implementation handbook then called the link to the national Internet backbone critical. It proposed investigating a telecom partner and existing networks, while placing an address-managing school server at the mesh boundary. The plan had two negotiations: how the children would reach one another, and who would supply and pay for the path out.

That separation also changed who could make decisions. Local mesh routing let neighboring laptops participate in carrying traffic. The gateway operator decided how the group met the outside world: which upstream was available, how traffic was shared, where content was cached, how machines were updated and who administered addresses. A school could have lively local collaboration while its Internet link was congested, missing or out of service. Another could have a working uplink but weak local coverage. “Connectivity” was a bundle of independent operating conditions, not a checkbox printed on a product box.

The project's own documents are enough to reject the miracle version of the XO story. They do not offer a census of every deployment's uptime or a verdict on the educational result. They show the decision OLPC itself put in front of operators: a mesh can reduce the need for wired connections among students, while access beyond the school still has to be purchased, powered, configured and maintained. One laptop per child was an arresting distribution rule. One functioning Internet path per school was a different job.