A technical assessment of porting "Sugar" to Windows.
Raymond F. Hayes Jr.
rayhayes at rhbe.net
Fri Apr 25 11:00:21 EDT 2008
I've been reading "Cross-Platform Development" in C++ by Syd Logan. It's a
fun read if you like coding for fun. I've got all the source; just want all
the information before I start playing.
-----Original Message-----
From: scott at sleekfreak.ath.cx [mailto:scott at sleekfreak.ath.cx] On Behalf Of
scott at gnuveau.net
Sent: Friday, April 25, 2008 12:55 AM
To: Raymond F. Hayes Jr.
Cc: 'OLPC Devel'
Subject: RE: A technical assessment of porting "Sugar" to Windows.
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
>
More information about the Devel
mailing list