A technical assessment of porting "Sugar" to Windows.

[scott at gnuveau.net]

why climb aboard a sinking ship, particularly when yours is moving fast...

On Fri, 25 Apr 2008, Raymond F. Hayes Jr. wrote:

> These might be stupid questions since I just joined the newsgroup today so
> my apologies in advance but I wasn't able to find an answer on the site.
>
> When you're talking about running Sugar on Windows XP, are you talking about
> a running the "retail" version of XP or a version of Windows XP Embedded
> with a customized shell as described here:
> http://msdn2.microsoft.com/en-us/library/ms940134.aspx or some special
> version to be decided later on.
>
>
> Ray
>
>
> -----Original Message-----
> From: devel-bounces at lists.laptop.org [mailto:devel-bounces at lists.laptop.org]
> On Behalf Of Wade Brainerd
> Sent: Thursday, April 24, 2008 3:11 PM
> To: C. Scott Ananian
> Cc: segphault at sbcglobal.net; Michail Bletsas; OLPC Devel
> Subject: Re: A technical assessment of porting "Sugar" to Windows.
>
> 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
> >
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>