A technical assessment of porting "Sugar" to Windows.
Raymond F. Hayes Jr.
rayhayes at rhbe.net
Fri Apr 25 12:46:45 EDT 2008
I understand your concerns. This is my work at home though which is far
enough away from what I do during the day to not be in conflict so I hope I
can contribute something useful. The aim of the OLPC organization is getting
more important with each passing day.
Ray
-----Original Message-----
From: Jeffrey Kesselman [mailto:jeffpk at gmail.com]
Sent: Friday, April 25, 2008 9:29 AM
To: Raymond F. Hayes Jr.
Cc: OLPC Devel
Subject: Re: A technical assessment of porting "Sugar" to Windows.
>From my POV, Ray?
Anything you can do that is cross platform and open is a great service
to the open source community.
But, with no disrespect intended, some of us have been in the way of
Micrsoft's muscling before and seen how at least the corporate side of
your company is not shy to try to get total control over a market by
controlling the core APIs. Or to then use that control to muscle out
anything tht doesn't serve Microsoft's financial interests.
I think its this that worries people about a "Windows based" OLPC. If
Microsoft committed to supporting a completely free and open set of
APIs that were controlled by the community, and not by them. And to
live within those community decisions, then I don't personally see
anything wrong with a Windows kernel option for the OLPC.
But I'm not sure I believe its within your employer's corporate
culture to do so.
JK
On Fri, Apr 25, 2008 at 12:21 PM, Raymond F. Hayes Jr.
<rayhayes at rhbe.net> wrote:
> Say though, I did manage to get something working on all three platforms
and
> put it all back out into the open source community. How does that "limit
the
> freedom" of anyone? It would seem to me that every bit of knowledge and
> every bit of code contributed to the open source community increases the
> freedom of everyone.
>
> Ray
>
> (to be completely transparent, I do work as a developer for MS though in
> Group Policy not anything remotely connected to the OS or the kernel or
> OLPC)
>
>
> -----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 8:16 AM
> To: Raymond F. Hayes Jr.
> Cc: 'OLPC Devel'
> Subject: RE: A technical assessment of porting "Sugar" to Windows.
>
>
>
> 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
> >
>
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
--
~~ Microsoft help desk says: reply hazy, ask again later. ~~
More information about the Devel
mailing list