A technical assessment of porting "Sugar" to Windows.

[C. Scott Ananian]

This document will give a technical overview of the challenges facing
any "Sugar on Windows" project.  Mary Lou Jepson of OLPC was proud of
the fact that the XO did "seven new things" when most hardware
projects try to limit themselves to only one "new thing" per product.
I will outline the "new things" which the XO system intends to
accomplish, and discuss the feasibility of each of them if/when
reimplemented on a Windows substrate.

I will start by addressing nomenclature.  What do we mean when we say
"Sugar"?  Is it the activities?  The zooming UI interface?  The
complete system?  What do we mean when we say "Sugar on Windows"?

For this document, I will assume that "Sugar" means the "new things"
which are goals of the XO system.  As we will see, some of these "new
things" as easy to accomplish, regardless of underlying operating
system, while others are extremely difficult or impossible.  Clearly,
what is meant by "Sugar on Windows" is that some subset of the "new
things" will be implemented on a Windows platform.  It is up to those
who argue for "Sugar on Windows" to be clear about which of these "new
things" they intend to accomplish; the costs and benefits of "Sugar on
Windows" critically depend on this definition.

I will present 12 items which comprise the current XO system.  Most of
these are implemented to some degree on the current GNU/Linux-based
stack ("Sugar/GNU/Linux"), although several of them are
works-in-progress.  For each I will attempt a rough measure of the
difficulty of porting or reimplementing this feature on a
Windows-based stack ("Sugar/Windows").


1. Sugar design guidelines.

In this minimal "Sugar on Windows" proposal, the only thing common
between Sugar/GNU/Linux and Sugar/Windows are the design guidelines.
Windows developers would port existing applications (Word, for
example) and provide simplified interfaces matching the Sugar UI
guidelines, but these activities would not share any code or
interoperate in any way with Sugar/GNU/Linux.  The collaboration and
other features itemized below would exist in Sugar/Windows only to the
extent to which the original or newly-written applications supported
them: native Word collaboration via a SharePoint server, for example,
would replace the Abiword-based peer-to-peer collaboration of
Sugar/GNU/Linux.

This course of action is rather difficult, as it requires essentially
a complete reimplementation of the XO software, but it imposes
minimal coordination and other costs on the existing XO developers and
no changes to the Sugar/GNU/Linux software stack.


2. Activities.

The XO comes with a large number of child-oriented "activities"; see
http://wiki.laptop.org/go/Activities.  One interpretation of "Sugar on
Windows" is to merely port the activities to Windows, transforming
OLPC into a pure "educational software" company.  This course is
moderately difficult.  Python and GTK are "cross-platform", of course, but in
practice many platform dependencies are inadvertently added to Python/GTK
code; any developer can tell you that "cross-platform" code which has not
actually been *tested* on another platform is unlikely to "just work"
on it.  So some amount of work is necessary on *each* XO activity.

Further, activities are written to a number of XO-specific APIs,
including APIs for UI elements, collaboration support, and document
storage.  The easiest course is to stub these out with
roughly-equivalent Windows implementations of the APIs.  This would be
sufficient to allow Windows developers to do a significant amount of
"activity development" on a Windows machine, but the version tested on
Windows would not actually have all of the functionality of the same
code running on the existing Sugar/GNU/Linux stack.  OLPC's developer
base would be expanded, but the resulting ports would be
"developer-friendly" Windows versions of the activities, not necessarily
a "kid-friendly" versions one would expect to deploy in schools.

A more aggressive pursuit of "Activities on Windows" would result in
completely- and fully-functioning versions of ported activities, which
were as "kid friendly" as the versions running on Sugar/GNU/Linux.
This would inevitably entail ports of some of the other features of
the XO; we will discuss the difficulty of implementing these other
features in turn below and leave the reader to sum these for
themselves.


3. Window manager: Mesh/Friend/Home view, frame, etc.

This is a more difficult task than merely porting the standalone
activities; this feature entails replacing the existing Windows file
and application chooser mechanisms with ones which mimic that of
Sugar/GNU/Linux.  There are two implementation possibilities: writing
a new Windows application from scratch which mimics this interface, or
porting the existing Python code from Sugar/GNU/Linux.

Writing a new Windows application is cheap in coordination costs, but
entails completely rewriting this part of Sugar from scratch.  This
course would probably also make porting Activities (item #2) slightly
more difficult, as the interfaces to wm elements (cut and paste,
collaboration, activity startup feedback) would likely need to be
altered to work well with a standalone "Activity chooser" Windows
application.  It is possible that, with some cleverness, the required
API changes could be kept small.

The other alternative is porting the existing code, which implies
running X windows, dbus, and much of the rest of the Gnome software
stack on Windows.  Ports of most of these already exist, but they tend
to differ from the versions we are currently using in Sugar/GNU/Linux:
either the Windows versions lag behind the versions we are using, or
some features don't exist/are broken, or the APIs have deliberately
diverged to better support Windows uses.  A significant amount of
integration work would be necessary, but the end result would be a
system which (in theory) would require only minimal additional changes
to activities.  It is not clear that the result will be "elegant": it
may not be well integrated into Windows, it may be less stable than
the GNU/Linux equivalent (since mainline development of the components
takes place on the GNU/Linux versions), and the performance problems
which dog the UI on Sugar/GNU/Linux would probably be, in the end,
faithfully reproduced on Sugar/Windows.


4. Journal and Datastore.

One part of the zooming UI not discussed in item #3 (above) is the
"Journal" view, the XO's replacement for the traditional "files and
folders" metaphor.  Our current implementation is based on Xapian,
which "compiles" on Windows (but perhaps not much more):
http://lists.tartarus.org/pipermail/xapian-devel/2006-March/000311.html

That said, our Journal and datastore are in need of a rewrite.  The
current proposal (http://wiki.laptop.org/go/Olpcfs) is not
incompatible with a Windows implementation, but the implementation
strategies on Windows and GNU/Linux would likely be very different.
The most straightforward course of action would be to have two
completely separate implementations of the same API.  This course requires
skilled Windows developers who are comfortable with NTFS reparse points
and/or filesystem development on Windows.  Developing a single
implementation which is cross-platform is likely more difficult.

It is possible to imagine Sugar/Windows without a fully-functioning
datastore implementation.  It is likely that the Journal in such a
port would be replaced by a Windows Explorer window which
would allow straightforward manipulation of files using the
traditional metaphor.


5. Collaboration.

Note that this feature is distinct from mesh networking (item #6
below).  Collaboration is simply implementing the APIs used by activity
authors to "share" activities, and the corresponding features in the
UI (item #3) which allow users to find friends and shared documents
and publish or join shared activities.

Our current implementation is based on Telepathy, which "compiles" on
Windows:
http://lists.freedesktop.org/archives/telepathy/2007-August/000977.html
and Avahi/mDNS, which has an Apple-authored implementation for
Windows.  Finishing the rough ports and changing our mDNS implemention
would require a significant amount of work.

Like the datastore, the collaboration component is also due for a
rewrite.  It is possible that the revised design may be lighter weight
and easier to port.  Polychronis Ypodimatopoulos' Cerebro software,
for example, once ran on Windows.


6. Mesh networking.

Aside from collaboration, the XO also supports 802.11s mesh
networking.  I have been told that the basic driver support for the
Marvell device we are using has been ported to Windows.  The Marvell
device we are using is also used in the XBox 360, although without the
mesh networking features and with a different firmware interface and
I/O configuration.  On its face, it looks straightforward to enable
mesh networking on Sugar/Windows.

However, in practice Sugar/GNU/Linux has required changes throughout
the software stack to accommodate 802.11s, from the kernel all the way
up to the applications.  We are continually finding areas which
the 802.11s standard is inadequate or buggy, necessitating tweaks to
over-the-air formats and protocols.  Application protocols on top of
the 802.11s implementation have also required modification; standard
DHCP and mDNS on an 802.11s network display pathologies not present in
standard 802.11a/b/g networks, and broadcasts used in our
collaboration stack have interacted poorly with 802.11s networks.

In reality, therefore, getting mesh networking functional and
interoperable with Sugar/GNU/Linux requires a significant amount of
on-going effort, including effort by Windows kernel developers with
access to restricted Windows source code.  Maintaining compatibility
with the networking stacks of two different operating systems would
complicate this task.


7. Power management.

The XO hardware is capable of sub-200ms resume-from-suspend, which
allows suspending between keystrokes or mouse movements to pursue an
aggressive power management policy.  This has proven extremely
difficult to achieve even on Sugar/GNU/Linux, requiring extensive
kernel changes.  For example, the USB reinitialization path on resume
requires refactoring the USB subsystem, and the kernel scheduler
needed to made tickless and able to invoke suspend during scheduling
in order to properly integrate with application-level timers.

This is extremely unlikely to ever work on Sugar/Windows.  The changes
to the XP kernel are too extensive, and the XP product has already
reached its end-of-life point, making the return on investment very
small.


8. Display technology.

The XO contains impressive display technology, with novel
sunlight readability and power management features.  The basic display
support has already been implemented in the Windows XP kernel.
It is not clear whether advanced features of the display -- for
example, the ability to freeze screen contents during suspend, or the
backlight management which automatically switches the screen into a
high-resolution black-and-white mode -- are implemented.  If they are
not, they require contributions from experienced Windows kernel
developers with access to the Windows XP source.


9. Camera/Microphone/Speakers.

We believe that basic sound support for the XO has been implemented in
the existing Windows XP port.  I am not certain of the state of
camera and microphone support.  If not yet implemented, these also
require contributions from experienced Windows kernel developers with
access to the Windows XP source.

Even after camera and microphone device support is added to Windows,
the APIs used in activities to access these functions differ greatly
from the native Windows APIs.  Activities would have to be manually
ported to use the Windows APIs.  Activities which currently use
gstreamer interfaces to the devices could potentially benefit from
using the Windows port of gstreamer; it is not clear whether that
would still require changes to activity source code.

For sound support, the situation is similar.  I believe that a larger
number of basic APIs are used to access sound playback features than
are used to access the camera and microphone, making compatibility
more difficult.  At minimum, we would need to use the windows port of
CSound; it is not clear to me how much work on CSoundXO would be
necessary.


10. Bitfrost: activity isolation.

Sugar/GNU/Linux has an innovative security model called Bitfrost
(http://wiki.laptop.org/go/Bitfrost).  Among other goals described by
the Bitfrost specification are activity isolation and sandboxing,
which render safe the "click everywhere" behavior of child users.

Our implementation of activity sandboxing is tightly tied to the Unix
security model.  Equivalent constructs exist on non-XP versions of the
Windows platform, but it is fair to say that sandboxing on Windows XP
is extremely challenging.  It is not likely that activity sandboxing
will ever be implemented on Sugar/Windows XP.


11. Bitfrost: initial activation security.

Our deployment countries are very concerned with theft of XOs.  This
item and the next address different mechanisms OLPC has designed to
mitigate and manage this risk.

"Initial activation security" means that an XO as delivered from the
factory is a worthless brick.  It cannot be transformed into a
functional machine without the use of an activation key, tied to the
machine's serial number, which is generated by OLPC or the deployment
country.  The goal of this feature is to deter theft-in-transit:
activation keys and the XO hardware follow different paths to the
target school, minimizing the value of the XO until it arrives in the
hands of its child owner.

Initial activation security is likely to be reasonably implementable
on Sugar/Windows.  Mitch Bradley has been working on making Windows
boot under OpenFirmware, and most of initial activation security is
implemented in OpenFirmware's secure boot path.  The initial
activation step currently involves booting a Linux kernel with a
special ramdisk which validates activation leases and writes them to
internal flash; this process could be used with only minor
modifications to perform activation of Sugar/Windows machines.


12. Bitfrost: active and passive kill.

Some countries want more aggressive anti-theft protection.  The terms
of the GPL (as well as our own moral compasses) require us to allow
the user to disable these mechanisms, but schoolkids who wish to keep
them enabled gain some additional anti-theft protection.

The theft-deterrence comes in two forms.  The first, passive kill,
limits the lifetime of the initial activation lease (item #11).  The
activation lease must be renewed periodically, or the machine reverts
to the unactivated state.  A thief is guaranteed that a stolen machine
will not be usable long.

The vulnerability in this scheme is the real-time clock.  The XO
hardware does not contain an hardware-protected clock (although we may
be able to leverage firmware in the embedded controller to provide
this), and so the burden of protecting the passive kill system from
clock-reset attacks falls on the operating system.  It is rather
difficult to secure Sugar/GNU/Linux against these attacks; it is
unlikely that Sugar/Windows will ever be adequately secure.  (If we
move to an EC-based implementation, then Sugar/Windows will require
Windows kernel expertise in order to follow suit.)

Active kill piggybacks on the update management system: when the XO
performs a network transaction to look for an update, it may also be
informed that it has been stolen, and immediately enter the
deactivated state.  The obvious vulnerability is in the networking: an
enterprising thief may conspire to prevent the XO from ever connecting
to the theft-deterrence server.  A secondary vulnerability is in the
daemon which periodically checks the theft-deterrence server:
again, the burden falls on the operating system to protect that
process from interference.  Again, this is difficult enough on
Sugar/GNU/Linux; it is much more so on Sugar/Windows XP.

For completeness, I will note that although passive and active kill
theft-deterrence systems have been implemented on Sugar/GNU/Linux,
only initial activation security has been deployed in the field.
Passive and active kill systems entail large support costs which OLPC
has chosen to date not to incur.


Conclusion
----------

Discussions of Sugar/Windows are made difficult by varying
definitions.  I hope that this itemized list of Sugar/GNU/Linux
features helps clarify discussion of Sugar/Windows proposals,
which have ranged from simple (item #1, "Design Guidelines", or a
minimal form of item #2, "Activities") to infeasible (a Sugar/Windows
indistinguishable from Sugar/GNU/Linux).  By better defining the
features we intend to accomplish in Sugar/Windows, we can more
rationally assess the costs and benefits of such investment.

 --scott

-- 
 ( http://cscott.net/ )