[sugar] Sugar Digest, Vol 25, Issue 94

[Greg Smith]

Hi Ben,

Thanks for the input.

I'm glad you sent this before the launch of 8.2.0 as it would be very 
discouraging to launch a new release then have one of the lead engineers 
say "this sucks" ;-)

That said, I don't think we can address many (any?) of these things in 
8.2.0 due to the constraints that Kim mentioned.

I pasted this e-mail in to the 9.1.0 privatization page, engineering 
requests section: 
http://wiki.laptop.org/go/9.1.0#Priorities_from_Engineering

Can you send and/or paste in to the 9.1.0 wiki links to further 
documentation or history on your points?

These four in particular, but any other details also appreciated:
- bug ids for the "amazing variety of terrible bugs"
- Links to specifications on the 5 datastore design proposals
- Links to file sharing proof of concept programs
- Links to "develop" specs and documentation on how it works now

This may be old news for others, but I don't have the details in my 
browser favorites or linked from my wiki pages yet.

Brief comments on your top 6 items:
1 - Datastore
Are you saying the current datastore has the functionality but its 
buggy, or that new core functionality is needed? Either way, I hear 
there is consensus that a major redesign is needed and its holding up 
other work (e.g. journal improvements).

2 - Updates
I agree. Not sure when we'll freeze the OS variables require us to wipe 
user data on upgrade (e.g. see 1 above). Aside from USB, this problem 
can benefit from system level work (e.g. XS -> XO or XO <-> XO updating).

BTW - 75% of deployed Xos are on 656 and 25% (Peru) are on 703. That 
will change as new countries come online. See: 
http://wiki.laptop.org/go/User_talk:Gregorio#Shipment_Quantities_and_Languages 
I will be adding build #s to that data as soon as I can.

3 - File sharing
I completely agree!

4 - Activity modification
I want to hear more demand from the users, but its clearly part of our 
core mission. We need scoping to prioritize this re: 9.1.0

5 - Bitfrost
Not sure about the long term design but it sounds like we need to fix 
that one hole ASAP. If we could be as secure as Linux + Gnome that would 
be a good start.

6 - Power
Should be much better in 8.2.0. I'd like to see a design proposal and 
scoping for your additional suggestions. That should include real use 
cases (e.g. XO only chirping on wireless, XO not networking and user 
away for long time, XO not networking and user away for short time, etc.).

BTW lots of architectural challenges were raised on the list lately. Its 
a great discussion but I hope it doesn't distract too much from the 
focus of improving "stability" in 8.2.0. We're in the home stretch on 
that and we need it working in the field ASAP.

I hope we can manage two subjects in parallel:
- deliver highest possible quality in 8.2.0
- design/discuss 9.1.0

Thanks for your comments and significant contribution to the project!

Thanks,

Greg S

> Date: Thu, 24 Jul 2008 14:25:37 -0400
> From: "Benjamin M. Schwartz" <bmschwar at fas.harvard.edu>
> Subject: [sugar] Congratulations! but Sugar sucks
> To: "OLPC Developer's List" <devel at lists.laptop.org>,	Sugar Mailing
> 	List <sugar at lists.laptop.org>
> Message-ID: <4888C921.7020402 at fas.harvard.edu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> (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.
> 
>