A technical assessment of porting "Sugar" to Windows.

Thu Apr 24 18:11:19 EDT 2008

Hey Scott, thanks for this.  It's nice to see a clear, unbiased
analysis of a complex problem.

It shows that there are some clear technical advantages to the
GNU/Linux stack, while correctly stating that there are options for a
Windows port which would not be impossible.

I personally can't imagine that the experience would be any better for
users, or a good use of OLPC's time and energy, and the apparent cost
of community goodwill *should not* be underestimated by management.
But if it means more sales versus the Classmate, a massive donation
from the Gates foundation, and a large team at Microsoft working on
the project, it may ultimately be for the best for the children to
have Windows available as an option on XO (it's an education project,
not a linux project).  It's a calculated risk to be taken by the
project management.

Anyway, I use tons of open source software every day on Windows XP,
and the fact that the operating system is closed source (as is the
processor, motherboard, and video card) doesn't bother me.  It's worth
noting that I can install a complete KDE environment on my XP machine
via Cygwin in about 2 hours.  Major OSS projects like QT, Firefox and
OpenOffice are pushing cross platform development with the aim of
greater adoption, I don't see why that's such a bad idea for Sugar.

Anyway, it's nice to see the OLPC core people are able to keep level
heads and think pragmatically.  Particularly when *you* were the one
implicated by Ars Technica as "extremely unhappy with Negroponte's
statement and argue that his goals are not technically feasible."

Best,
Wade

On Thu, Apr 24, 2008 at 2:32 PM, C. Scott Ananian <cscott at laptop.org> wrote:
> 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/ )
>  _______________________________________________
>  Devel mailing list
>  Devel at lists.laptop.org
>  http://lists.laptop.org/listinfo/devel
>