A technical assessment of porting "Sugar" to Windows.
scott at gnuveau.net
scott at gnuveau.net
Fri Apr 25 11:15:31 EDT 2008
On Fri, 25 Apr 2008, Raymond F. Hayes Jr. wrote:
> 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.
Seems like most everyone involved currently considers this at best a bad
idea, but if limiting the freedom of a large chunk of a generation is your
idea of fun, go ahead and knock yourself out trying.
IMHO involving MS in any way is shooting ourselves in the foot.
>
> -----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
> >
>
>
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
More information about the Devel
mailing list