Congratulations! but Sugar sucks

[Kimberley Quirk]

Ben,
I think many people will agree with much of what you have identified  
in your rant; and we have been working on making the most progress we  
can given the constraints of the 'real' world:

1 - 350,000 laptops in the hands of kids today. This alone takes most  
of the resources away from your identified big issues and forces us to  
focus on the serious bugs that are currently shipping. This is not an  
excuse... just reality. We identified all the items you have written  
down as being 'not good enough' pretty much from the day we shipped.  
But the problems of real world take precedent over the next features.  
At the same time, we have been hiring so we can try to tackle both:  
support what we've shipped AND make progress on the next features.  
Hiring and coming up to speed take many months.

2 - OLPC never had enough resources to deliver all 6 of these new  
technologies with 'developed world' quality from day 1. This has been  
identified well before we even shipped the first laptop... and we  
decided it was still better to have something in the hands of kids  
rather than nothing.

We've heard it from others who have visited schools in Mongolia,  
Rwanda, Haiti, Uruguay, etc. and I will add my voice to that group as  
I just got back from visiting a school in Peru. The students and  
teachers are all learning so quickly with the laptops, and they are  
all excited and appreciative to have this opportunity in their school.  
It really is better to continuing shipping these laptops where they  
can help children, then to stop and 'get it right' for the developed  
world market.

Yes, sometimes progress is slow; and I (for one) appreciate the time  
and thought you put into this list as it DOES represent the areas  
where we want to make progress and can most use help.

Now, maybe we can turn this list into a real request for how people  
can help!

Kim





On Jul 24, 2008, at 2:25 PM, Benjamin M. Schwartz wrote:

> (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.
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel