9.1.0 requirements

Release 9.1.0 Overview

This is a time based release per the process at:
Release Process Home

The process is not final. It is a set of rough guidelines still being worked out and subject to change.

The goal (not confirmed) is to make this release public sometime between December, 2008 and June, 2009.

Technical Strategy

Faster, more robust, better integration of activities, more collaboration...

See requirement definition at Requirements

Sales - Deployment Strategy

See customers below.

Pedagogical Strategy

....

Target Deployments

See: User talk:Gregorio#Shipment Quantities and Languages

Uruguay

Spanish 100K x XOs?

Peru

Spanish 100K x XOs?

Mexico

Spanish
50K x XOs

Mongolia

Mongolian?
20K x XOs

Rwanda

French 10K x XOs

Haiti

Kreyol
13K x XOs

Ethiopia

Amharic
5k x XOs

Cambodia

Khmer
1000 XOs

Afghanistan

Dari
3000 x XOs

Thailand

Thai
500 x XOs

India

Devanagari
500

Brazil

Portuguese
200 x XOs

Arabic

Sabra and Shatila (Lebanon)
500 x XOs

Oceania

Enlish?
500 x XOs

Italy

Italian
600 x XOs

Turkey

Turkish?
15k x XOs

Senegal

French
1000 x XOs

Panama

Spanish

Birmingham

English

South Carolina

English

New York City

English

Priorities from Deployments

Should list what, who and why on each item. Should link to detailed requirements and use cases eventually.

See User talk:Gregorio#Priorities from Carla

Longer Battery Life

Requirement Definition

Requirements#Power Management Requirements

Who requested

Kim

Touchpad

Who requested

Improved in 8.2.0
Priority request from Carla

Collaboration

Requirement Definition

Allow for intuitive mesh connection and activity-sharing.
Must support first two use cases defined at: Use Cases#Collaboration Examples

Requirements#Mesh / Connectivity_Requirements

Requirements#AbiWord Sharing Requirements

Who requested

Priority request from Carla and David.
Also several thread on OLPC-Sur.
Peru technical leaders

Inter-school communication

What I see as most missing and most necessary is a safe space for collaboration between students at different schools, even in different countries.
http://lists.laptop.org/pipermail/localization/2008-July/001249.html

Performance and Reliability

Faster activity launching
6472

- File/activity open

- File save

- Task switching

- Activity or main GUI responsivesness to cursor

- Hardware

Security Activation and Deployability

School server push of XO images

Requirement: The XO should be able to get the latest build from the school server

• The administrator makes the desired build available in the designated

directory. When ready, the administrator requests to 'push' the build to all laptops as they come on line. Both of these activities should be an easy-to-use UI at the school server.

• A test requirement is the ability to create a white list of serial numbers

that should be upgraded with the push.

Source: Peru

Activation lease security feature

Requirement - if the laptop is stolen, and doesn't contact its local school server within some period time (activation lease time); then it will tell the user that it will not activate on next boot and provide date and time.

Requirement - it is not possible to set the date on the laptop to keep it within the lease period or to force it to outside the lease management. This might mean you cannot change the date or there is no root access, or it might mean an alternate time source is used... (not trying to solve the problem, just want to note this requirement).

Source: Peru

XO Monitoring

Requirement: Provide XS database and an API so that countries can create reports and monitoring for various aspects of XOs:

• Version of code
• Which laptops are being seen each day
• Total number of laptops being seen per day
• Number of laptops accessing the internet
• List of URLs being accessed
• List of URLs per laptop
• Which activities are being used per laptop
• Number of minutes in each activity per laptop; can we determine (and subtract) idle time?
• Number of minutes in each activity within and outside of school hours (perhaps this means we capture the 'start' time of each activity and allow the reporting to decide if this is during or outside of school hours).

Background and implementation ideas:
I think there might be some work in the XO to make the information available; and a database and API spec from the school server. This is not as high priority for their deployment as the passive lease management, but I believe this feature will be important for any deployment. We should try to get feedback from other deployments as to the information we want to collect.

Source: Peru

Activation lease security feature

Must allow changing startup picture by copying an image to the XO. This should not require any OLPC developer intervention and should not need a new or special build.

http://lists.laptop.org/pipermail/devel/2008-July/017299.html

Source: Colombia and Mexico before.

Network Manager Connections

G1G1 encryption.

802.11i (AKA 802.1x) Uruguay

Unadorned and unedited user feedback

6th grade kids feedback on build 656:
http://sextosdela37.blogspot.com/2008/04/analizando-el-uso-de-las-laptop-en-el.html

Priorities from Carla: User talk:Gregorio#Priorities from Carla

Comments from technical user in Ecuador:
http://lists.laptop.org/pipermail/olpc-sur/2008-July/000408.html

GUI and Usability

Request from Uruguay for HW alerts:
http://lists.laptop.org/pipermail/sugar/2008-July/007086.html

Designs ideas from Scott and Eben in thread. e.g. I hope our alert system will use the freedesktop.org standard: http://www.galago-project.org/specs/notification/index.php

Priorities from Engineering

• #4662 needed for better activity capabilities.
• #2447 caps lock
• #1997 flashing in write
• NAND full crashes system
• I think analyzing performance of non-JFFS2 file systems and picking a replacement should be a high-priority item for 9.1 update.
• from: http://lists.laptop.org/pipermail/devel/2008-July/016994.html

Fedora 10 rebase?

Localization

Spell checking in as part of l10n. (Sayamindu)

Allow adding a language after the build is created and without OLPC intervention

e-mail from Ben S

http://lists.laptop.org/pipermail/sugar/2008-July/007390.html

1. The datastore
Sugar's design calls for a centralized rich data storage system, the datastore. The datastore provides secure, limited file access to Activities, manages file metadata, maintains a differentially compressed history of all work, ensures reliable backups to a trusted server, and mediates the connection to removable media. Every one of these features is crucial to Sugar's functioning, and almost none are really working at this time. We cannot afford another release based on the present datastore, as it fails to implement the features we require, and is unreliable even in the features it supposedly implements.

Solution:
There have, at this point, been at least five distinct proposals for a next-generation datastore design, all differing in underlying implementation and user-facing functionality. We need to have a Once And For All datastore summit, draw up a compromise datastore design, and implement it. We can do this by 9.1.0, if we are willing to make it a priority.

Additional Links:

• The current datastore
• Olpcfs
• Sugar Datastore Summit in January (item 10).
• SDS (stands for Simple Data Store or possibly something else)
• Git-based datastore design

2. OS Updates
We now have hundreds of thousands of laptops deployed in the field, running a variety of OS versions. OLPC cannot afford to support a multitude of decrepit versions, and children cannot afford to suffer defects that have long since been fixed. We need a reliable, fast, update system that does not rely on the network, so that children everywhere can move to the latest version of Sugar without losing their data. The update system must support tremendously invasive upgrades, like repartitioning the NAND and replacing JFFS2, because we expect to do this in short order.

Solution:
A secure usb autoreinstallation stick is required. It is not technically challenging to implement, but it must be made a priority, and then be made widely available and idiot-proof.

3. File Sharing
Students and teachers have no good way to distribute files directly from one person's Journal to another. If all Activities that open a file do not implement Collaboration, then there is simply no way to transfer that file over the network. This is the most basic possible network functionality --- FTP was standardized in 1971 --- but it is completely missing from our system.

Solution:
A number of technical proof-of-concept programs have been written for distributing files, using methods like HTTP over stream tubes and Cerebro's Teleport. There is an excellent set of [[Specifications/Object_Transfers|UI mockups for this] functionality. All that is left is to Get It Done.

Additional Links:

• Read
• Distribute
• A Summer of Code application

4. Activity Modification
A keystone of the Sugar design has always been the user's ability to edit any Activity, and to cement this a "View Source" key was designed right into the hardware. This functionality is simply missing, and that prevents us from making our principal claim regarding an emphasis on user modification.

Solution:
"Develop" must be polished, finished, and included by default. This will require modifications to the core system, in order to support an endless variety of slightly modified Activities. It will also require work on the Develop program itself. If volunteer efforts are not moving fast enough, OLPC must ensure that someone is working on the problem as a professional.

Additional links:

• Develop
• Previous, stalled attempt at Develop
• Current status of "view source"
• OLPC_Human_Interface_Guidelines/The_Laptop_Experience/View_Source
• EAG_The_Laptop_Experience:_View_Source

5. Bitfrost
Sugar, as it currently stands, is among the least secure operating systems ever, far less secure than any modern Linux or Windows OS. I can easily write an Activity that, when run by the user, escalates to root privileges and does anything I like with the system. Given Sugar's competitive status against Windows XO, this failing threatens the very existence of the project. The Sugar designs have long stated that safely running untrusted code from a classmate is a key goal for learning, but the current software accomplishes precisely the opposite.

Solution:
NO ONE IS WORKING ON BITFROST. That's right. Everyone who was working on Sugar security (after activation) has either left OLPC or moved into another role. Someone must be assigned to continue the security work, or it will certainly never make progress. Anyone who _does_ take on this challenge will start from a much better position than previously, because many of the Vserver features have moved into the mainline kernel over the last few versions. The kernel now contains a number of new, powerful isolation and control primitives.

6. Power management
Power management is the raison d'etre of the XO hardware. It is the reason that the hardware took four times as long to develop as a standard laptop, the reason that we suffer from the closed Marvell operating system, the reason that OLPC's best engineers flew around the globe fighting with details of voltage and capacitance. In an increasingly crowded low cost laptop market, it is one of OLPC's few remaining distinctions. As of 8.2.0, aggressive suspend is available, but its functionality is still far from the target.

Solution:
Enabling aggressive power management is a major challenge, perhaps more difficult than anything else on this list. We know what is required for a first step: ensure that we can reliably wake up from a hardware timer.

This single feature would be enough to enable a basic sleepy approach that is truly transparent to software. Other work includes removing USB from the critical path on resume. Aggressive suspend may not be ready for 9.1.0, but if no one is working on it it will never be ready.