A technical assessment of porting "Sugar" to Windows.

Fri Apr 25 11:02:35 EDT 2008

Below is exactly my attitude about getting in Bed with Microsoft. They
are not in the business of helping to distribute OPEN Software.

On Thu, 2008-04-24 at 15:00 -0700, Edward Cherlin wrote:
> 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
> >
> 
> 
> 
--
=======================================================================
Work without a vision is slavery, Vision without work is a pipe dream,
But vision with work is the hope of the world.
=======================================================================
Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam at sbcglobal.net