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@lists.laptop.org
http://lists.laptop.org/listinfo/devel
