[sugar] Remarks on the Work of Sugar

Wed Jul 23 00:56:39 EDT 2008

Michael's report resonates with me perfectly. I 'm trying to contribute 
to a rather core part of Sugar, its collaboration system, but I can't 
because the time required to master and use the various layers I need to 
work with has been prohibitive. On the other hand, circumventing the 
layers altogether has not been an option either as it would brake 
"backwards compatibility" with existing activities (Sugar is a two-year 
old experimental project and already has legacy?). I have been working 
with the XO ever since the A-Test boards and I am not familiar with any 
significant contribution to the collaboration system by volunteers so far.

On the other side, Ben's and Eben's points are completely valid: the 
time frames vs. resources available between releases have been 
ridiculously disproportional.

On another note, should we look into Google's protobufs 
(http://code.google.com/p/protobuf/) to be used as structures to be 
passed in inter-process calls? These are essentially "compiled data 
structures", but I'm not sure if the trade-off for (de)serializing data 
is worth it, even if native code is used to perform the action.

As an alternative to Michael's suggestion for IPC mechanisms, I think 
the problem is not the mechanism itself, but rather the data we are 
passing using the mechanism. Like Martin said, Dbus works great for 
small messages, but passing whole objects renders the whole mechanism 
counter-intuitive. What happened to good-old JSON? JSON maps exactly 
onto Python dictionaries (un)marshaling data is as simple as str() and 
dict().

Pol

Michael Stone wrote:
> After mild provocation, Marco and Tomeu asked me to publish some of my
> reactions to sugar's architecture, design, and implementation. Here are
> a few initial comments.
>
> 1) Sugar could better hold contributors if it (and its web presence)
> were designed to be extended and to highlight external contributions. 
>
>    Evidence: Trac and xmonad both have thriving communities of
>    contributors based around their plugin architectures and community
>    sites like trac-hacks.org.
>    
>    Evidence: Sugar has already attracted new contributors by creating
>    three different extension points:
>    
>      Activities themselves
>      Device entries on the Frame
>      Control Panel Entries
>
>    Evidence: Non-extensible aspects of Sugar like activity launching,
>    home view layout, frame contents, and the presence service have
>    stagnated.
>
> 2) Sugar would run more smoothly on-XO if jhbuild were retired. By
> running at non-XO speeds, jhbuild permits Sugar developers to retain
> faulty assumptions about the environment in which their code will run.
>
>    Evidence: Sugar uses algorithms which casual inspection reveals to be
>    horribly slow and Sugar has, in the past, suffered from
>    easily-revealed memory leaks which went unfixed for long periods of
>    time in part because developers had little personal motivation to fix
>    the issues.
>   
> 3) Sugar is built on technologies which encourage excessive layering.
> Excessive layering makes it hard to approach code (high cognitive
> burden) and harms performance (by causing unnecessary data copying and
> by causing data to be stored in the heap rather than the stack or in
> pageable regions of memory.
>
>    Evidence: the "convenience" layers of Python wrappers around
>    dbus-python stubs around dbus objects around two layers of python
>    bindings for an information retrieval system built on a filesystem in
>    merely to create and save files with a dict of attached metadata.
>
>    Evidence: The "convenience" layers of Python wrappers around gobject
>    properties around dbus-python stubs around dbus objects around a
>    hardcoded network manager around the underlying CLI tools and the
>    kernel's netlink sockets.
>
>    Evidence: The SVG python icon objects in a three-layer Sugar icon
>    cache spanning gobject properties and cairo surfaces atop gtk and gdk
>    windows atop X windows and pixmaps atop...
>
> 4) Sugar's underlying technologies bias it toward computing results more
> eagerly than is appropriate.
>
>    Evidence: Python and C are eager languages without well-documented
>    support for lazy computation.
>
>    Evidence: Sugar performance has been shown to improve by making
>    some computations lazy, e.g. palette creation.
>    
> 5) Sugar is built on technologies that incentivize its developers to
> recompute prior results which could be cached across boots. 
>    
>    Evidence: Sugar is developed by people running on hardware that is
>    fast enough to recompute results at little cost to interactivity (see
>    §2). 
>    
>    Evidence: Also, OLPC's shipping JFFS2 implementation does not support
>    writable mmaps or uncompressed inodes.
>
>    Evidence: Python lacks support for loading data without unmarshalling
>    it from bytestreams.
>
> 6) Sugar was not built with compartmentalization in mind. All its
> functionality runs with the full privilege of the human operator and it
> has very coarse process-level memory protection.
>
>    Evidence: Sugar packs great functionality into a small number of
>    processes and occupies only one uid.
>
>    Evidence: Sugar's process-level boundaries (e.g. "shell", "DS", "PS",
>    "telepathy CMs", "rainbow", "activities") seem to me to be strongly
>    correlated with the existence of cliques of the developers who built
>    them. 
>
> 7) Sugar prefers IPC techniques with inferior human interfaces (DBus, X)
> to IPC techniques with superior human interfaces (HTTP, 9P, environment
> variables, well-known files, process arguments + status codes + man
> pages).
>
> Regards,
>
> Michael
>
> P.S. - Let me know if you'd like to see more such remarks in the future
> (perhaps on other subsystems?) or if you'd like to see more detailed
> exploration of any of the items noted above.
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>   

-- 
Polychronis Ypodimatopoulos
Graduate student
Viral Communications
MIT Media Lab
Tel: +1 (617) 459-6058
http://www.mit.edu/~ypod/