Remarks on the Work of Sugar

[Martin Langhoff]

On Wed, Jul 23, 2008 at 11:49 AM, Michael Stone <michael at laptop.org> 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.

Excellent analysis. +1 on it, and a couple of minor notes...

Aspects of #1 and #6, specifically:

> 1) Sugar could better hold contributors if it (and its web presence)
> were designed to be extended and to highlight external contributions.

  vs

> 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'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.

Modularity and security compartamentalisation go hand in hand, and are
a social aspect of software. If we have more of what you want in #1,
we will see more of #6.


> 3) Sugar is built on technologies which encourage excessive layering.

+10.

> 5) Sugar is built on technologies that incentivize its developers to
> recompute prior results which could be cached across boots.
...
>   Evidence: Also, OLPC's shipping JFFS2 implementation does not support
>   writable mmaps or uncompressed inodes.

Missing writable mmaps is a real problem - lots of applications are
just not possible to accomplish with adequate performance without it.

>   Evidence: Python lacks support for loading data without unmarshalling
>   it from bytestreams.

The way you've written this strikes me as overbroad, but I think
you've answered that elsewhere.

Unmarshalling costs around IPC do seem to be significant for the bits
of code I've looked at. IME, IPC is fantastic to deliver tiny bits of
data that says "hey, here's the real thing" with a file path, shmem
address or similar
.
> 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).

I wouldn't encourage http :-)

cheers,



martin
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff