Congratulations! but Sugar sucks

[Benjamin M. Schwartz]

(Foreword: I originally intended to send this e-mail after the release of 
8.2.0,
but I have been convinced to send it earlier in order to prompt discussion)

Dear OLPC developers,

Congratulations on your work so far towards 8.2.0, with its new UI, new
underpinnings, and thousands of individual improvements.  It took years of
effort to get this far, and a tremendous amount has been done to reinvent
the entire notion of a software stack to better serve the educational
needs of children.  This release will be a triumph.

Unfortunately, it is also an abysmal failure.  There is hardly a worse 
operating
environment available than Sugar as it currently stands.  In addition to an
amazing variety of terrible bugs, this failure is due to a handful of 
major missing
features.  I list here six major missing features, and what can be done about
them to ensure a 9.1.0 that moves Sugar from mediocre to outstanding.

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.

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 UI mockups for this
functionality.  All that is left is to Get It Done.

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.

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.