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 <[EMAIL PROTECTED]> 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@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: [EMAIL PROTECTED] _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel