A technical assessment of porting "Sugar" to Windows.

Thu Apr 24 18:00:27 EDT 2008

Thanks, Scott, for taking us away from the direction of flamage to
many of the real issues. I have nothing to add about the difficulty of
the actual technical issues that you discuss, but I have some comments
on the significance of the technical issues for corporate strategy and
marketing.

The first point here is that the Windows kernel and API work can only
be done by Microsoft itself (details in Scott's message snipped). I
would argue that OLPC should leave all of the Sugar on Windows work to
Microsoft (except for GPL audits), unless we get the kind of financial
commitment from Microsoft that Red Hat and others have made. In that
case, we could discuss it, but I still wouldn't automatically agree to
it. I would also consider, as an example, trading a seat on OLPC's
board for seats on the boards of both Microsoft and The Gates
Foundation. If the proposed contract is published in advance and
passes public scrutiny. Maybe.

But consider the effects of GPL auditing of Microsoft Windows kernel
software, or rather the implications of Microsoft using any GPLed
software in its kernel. I don't see any chance of it, which means that
Microsoft will have to reimplement everything. And we would still want
to do the audits to make sure that nobody cheats. Given Microsoft's
ferocious opposition even to escrowing Windows source code that nobody
should ever need to look at, I don't see an audit happening. In which
case I don't see Sugar on Windows happening, and especially not Sugar
on XP/XO.

It's funny. Before the IBM PC and PC/MS DOS, Microsoft took out ads
saying, "Microsoft is pleased to announce that there will be no 16-bit
software crisis." That was about their original AT&T Unix license,
which they later spun off to The Santa Cruz Operation (not in any way
the current SCO). But now we are actually having a 64-bit software
crisis and an XO software crisis. Welcome to the future.

On Thu, Apr 24, 2008 at 11:32 AM, 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"

Understood.

>  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.

Augmenting, I think you mean, rather than replacing? But we know what
you are talking about.

>  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.

Some people love the journal, and some hate it. I assume that they
would evaluate this possibility differently. I like the Journal in
principle, but it needs a lot more work. Basically, it doesn't scale
to a year's work or more yet. If the children like it, then not having
it can be a deal-breaker. I know lots of people who hate hierarchical
file systems because they don't know where to put things or how to
find them again.

>  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.

Right. All of this works over ordinary Internet and local networks, so
it does not affect decision-making for us or Microsoft. Unless they
decide to go for obfuscation of these distinctions in their marketing.

>  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.

I am a firm believer in requiring reference implementations for
software and combined software/hardware standards. But that doesn't
affect the discussion with Microsoft, as far as I can see.

>  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.

This is a serious obstacle for the whole concept. Not having mesh
would limit Sugar on Windows to fully connected regions in developing
nations, mainly in cities. Well, maybe Microsoft can steal from the
rich and we can give to the poor. %-]

>  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.

I wouldn't count on that. XP on the desktop has a little more life in
it as long as Vista won't let people play content that they own, lacks
many drivers, and continues to have other deal-breaker gotchas. Also,
XP/XO, with a potential market of hundreds of millions of units, would
amply justify the engineering effort if Microsoft could pull off both
that and the marketing. I include the network effect of potentially
locking in those hundreds of millions of users to Windows for life,
which is by no means a sure thing for Microsoft. (I think it quite
unlikely.)

>  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.

An essential part of the discovery model of education. Children will
discover the function of every button and icon if left to it on their
own. Not having that safety means that schools have to take up class
time teaching them what they are allowed to do and what not.

>  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.

Though not for lack of trying on Microsoft's part, I expect.

>  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.

I think you make a strong case that it would take Microsoft several
years to implement Sugar on Windows fully, and that OLPC should have
nothing to do with it. Certainly it isn't the express bypass that
Nicholas has been looking for.

>   --scott
>
>  --
>   ( http://cscott.net/ )
>  _______________________________________________
>  Devel mailing list
>  Devel at lists.laptop.org
>  http://lists.laptop.org/listinfo/devel
>

-- 
Edward Cherlin
End Poverty at a Profit by teaching children business
http://www.EarthTreasury.org/
"The best way to predict the future is to invent it."--Alan Kay