Remarks on the Work of Sugar

[Michael Stone]

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.