A technical assessment of porting "Sugar" to Windows.

[NoiseEHC]

Thanks for providing this summary!

What is not clear to me is whether we are talking about:
1. Windows on XO with Sugar
2. Sugar on Windows on any machine
3. Both
Also not clear what advantage could any variation provide to OLPC so 
probably NN could be a little more concrete about Sugar on Windows. I 
mean that supporting 1. would be good for marketing since OLPC could 
tell the potential buyer that the laptop can run M$ word even if it is 
not too practical or sane, but at least it would result in laptop sales. 
However porting all the "new" thing would make the Linux development 
became a pointless effort (not that it is possible, see later). Also 
supporting 2. could mean more Sugar developers and more kids getting 
learning software but would undermine XO sales...

> 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.
>   
That is what I have meant by porting Sugar to Windows. I think that 
creating a minimal version which can run most of the Python activities 
should took less than 1 man year (yes, I have read the MMM) so it is not 
too hard. Of course it would mean fixing some of them, for example the 
Sugar shell crashes on VirtualPC 2007 since it only implements 
SoundBlaster so the OLPC kernel does not recognize any sound card (and 
the Sugar shell assumes one). Also needs fixing activities to handle 
different resolutions from 1200x900 and alikes. If you ask me this is 
the path I advice taking.
> 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.
>   
I do not see what would be the purpose of replacing the standard Windows 
shell with the Frame/Zoom interface. It would result in user retraining 
(which would result in ministries not choosing the XO+Sugar variant) and 
compatibility issues (most of the win apps assume the explorer shell). 
Porting the whole X<->Sugar stack would result in totally crappy looking 
applications nobody wanna use (in case of normal Windows machines) or 
crappy dog slow apps on a Windows XO. So in my opinion this is a path 
which require a lot of resources and gives back almost no rewards.

> 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.
>
>   
Now that is a real problem. A user space datastore would be easily 
portable to Windows but an Olpcfs thing is not. There is a saying on the 
OSR mailing lists (this is the company MS outsources the IFS DDK 
support), that no matter how many developers you have, creating an FS 
takes at least one year. I have heard (never have seen) that there are 
several FUSE like things for Windows but all are closed source 
commercial ones. Of course if MS or OSR would allocate some people for 
this task (the latter requires a lot of money) then it would finish in 
less than 1 year, for example Olpcfs is roughly the same as ExchangeFS 
(what is finished). If we want to go in the filter driver direction 
(which is much much much much easier) then the problem is that we do not 
even know if the XO Windows port even uses NTFS to use reparse points. 
However if we are talking about Sugar on a simple Windows machine then I 
do not know if requiring an FS installation is what we want to ask from 
the user... This is one of the hardest solvable problem in the port.
> 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.
>
>   
It is "just" a recompile. :)
> 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.
>
>   
I do not know what too much about 802.11s but most likely if MS does not 
do it then it will not happen (on the XO). If we are talking about 
simple Windows then it is not required.
> 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.
>
>   
The same as the mesh, if MS does not do it then it will not happen.
> 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.
>
>   
It simply needs a monolithic kernel driver for the display/DCON hardware 
or two communicating drivers but it needs just the DDK. Since MS is 
maintaining the drivers for the XO, I do not see a reason why should we 
care.
> 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.
>
>   
Now it is just a straightforward porting effort (and somebody wrote that 
CSound does not need porting at all), not too difficult. The problem is 
that if we wanna support simple Windows machines then the activities 
should be fixed not to assume a specific camera resolution or similar 
things. Effectively it is the fixing which will be required when the 
XO-2 will be released with a different hardware.
> 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.
>
>   
I think if MS does implement something like 10-12 it will be supported, 
otherwise do not even think about it. Some ways the WindowsXO will be 
always inferior to the Linux one so there is no point thinking too much 
on reaching feature parity. It is frightening enough that millions of 
children could get Windows without access for IT people but if that is 
the price of reaching the economies of scale then be it.

ps:
Note that I started to write this message yesterday and was a little bit 
slow process since I am not a native English speaker. So it is not too 
surprising that the later comments are shorter... :)