Re: A technical assessment of porting Sugar to Windows.
On Sat, Apr 26, 2008 at 5:18 AM, NoiseEHC [EMAIL PROTECTED] wrote: I have just found this link: http://pages.cs.wisc.edu/~driscoll/fuse-nt.pdf This is a report about a failed IFS-FUSE attempt. They ended with a loopback SMB server what should the Sugar windows port should follow IMHO. Thanks, I've added this link to the olpcfs wiki page. I'll integrate it into the text next time I make substantial revisions to the document. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: A technical assessment of porting Sugar to Windows.
On Thu, Apr 24, 2008 at 8:32 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: 1. Sugar 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. I think that one option that should not be discounted is the stack Sugar/GNU/Windows. In this case you could keep ABI Word (using the Win32 version) and other open source collaboration tools instead of implementing what Nicholas would call bloat-ware (Share point is probably the ugliest CMS you could deploy - a simple wiki would work tons better ;). Ludovic ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: A technical assessment of porting Sugar to Windows.
I have just found this link: http://pages.cs.wisc.edu/~driscoll/fuse-nt.pdf This is a report about a failed IFS-FUSE attempt. They ended with a loopback SMB server what should the Sugar windows port should follow IMHO. ps: The report contains the problems writing windows FSs. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
RE: A technical assessment of porting Sugar to Windows.
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wade Brainerd Sent: Thursday, April 24, 2008 3:11 PM To: C. Scott Ananian Cc: [EMAIL PROTECTED]; 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 [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 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
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wade Brainerd Sent: Thursday, April 24, 2008 3:11 PM To: C. Scott Ananian Cc: [EMAIL PROTECTED]; 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 [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 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
RE: A technical assessment of porting Sugar to Windows.
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. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wade Brainerd Sent: Thursday, April 24, 2008 3:11 PM To: C. Scott Ananian Cc: [EMAIL PROTECTED]; 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 [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 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,
Re: A technical assessment of porting Sugar to Windows.
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 ATT 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
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wade Brainerd Sent: Thursday, April 24, 2008 3:11 PM To: C. Scott Ananian Cc: [EMAIL PROTECTED]; 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 [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 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
Re: A technical assessment of porting Sugar to Windows.
This may be obviosu to everyone, but just a note if it isnt I have a lot of experience *trying* to tlak Win32 into doing things other then its own way from my time in the Sun Java Performance tuning team. Java has a very X inspired window system. Retting that to run reliably on Windows has been a HUGE effort. The single biggest issue is this: Win32 is not a multi-threaded OS. What I mean by that is that, while you can throw off multipel user threads, it is *vital* that everything that actually calls into the windows kernel happen on a single thread-- the message pump thread. Doing anything else is either unstable or outright fails. Keep this in mind when trying to figure out the work involved in making your GUI work on top of it. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: A technical assessment of porting Sugar to Windows.
You mean everything that actually calls into GDI. The kernel is fully thread safe and preemptive on NT. Since as I know GTK is thread affine as well, probably it is not a problem. Jeffrey Kesselman wrote: This may be obviosu to everyone, but just a note if it isnt I have a lot of experience *trying* to tlak Win32 into doing things other then its own way from my time in the Sun Java Performance tuning team. Java has a very X inspired window system. Retting that to run reliably on Windows has been a HUGE effort. The single biggest issue is this: Win32 is not a multi-threaded OS. What I mean by that is that, while you can throw off multipel user threads, it is *vital* that everything that actually calls into the windows kernel happen on a single thread-- the message pump thread. Doing anything else is either unstable or outright fails. Keep this in mind when trying to figure out the work involved in making your GUI work on top of it. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: A technical assessment of porting Sugar to Windows.
On Fri, Apr 25, 2008 at 12:15 PM, Jeffrey Kesselman [EMAIL PROTECTED] wrote: On Fri, Apr 25, 2008 at 12:01 PM, NoiseEHC [EMAIL PROTECTED] wrote: You mean everything that actually calls into GDI. Right, my mis-speak. Given that almost all my interaction with Windows has been through GDI I tend to blur that distinction in my mind. I should add that Ive also done a fair bit with DirectgX, which also has major threading issues. JK ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
RE: A technical assessment of porting Sugar to Windows.
Realistically this is a big project but I do have MAC/PC/Linux platforms to work with so implementing and testing some of Mr. Logan's methodologies is interesting. I'm also working with Sparx Systems's Enterprise Architect which has a roundtrip software engineering feature that supports Python. I'd like to explore the architecture used in the OLPC XO machine also. There's a lot to learn and so little time. 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wade Brainerd Sent: Thursday, April 24, 2008 3:11 PM To: C. Scott Ananian Cc: [EMAIL PROTECTED]; 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 [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
RE: A technical assessment of porting Sugar to Windows.
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:[EMAIL PROTECTED] 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. [EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wade Brainerd Sent: Thursday, April 24, 2008 3:11 PM To: C. Scott Ananian Cc: [EMAIL PROTECTED]; 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
Re: A technical assessment of porting Sugar to Windows.
Thanks for providing this summary! What is not clear to me is whether we are talking about: 1. Windows on XO with Sugar 2. Sugar on Windows on any machine 3. Both Also not clear what advantage could any variation provide to OLPC so probably NN could be a little more concrete about Sugar on Windows. I mean that supporting 1. would be good for marketing since OLPC could tell the potential buyer that the laptop can run M$ word even if it is not too practical or sane, but at least it would result in laptop sales. However porting all the new thing would make the Linux development became a pointless effort (not that it is possible, see later). Also supporting 2. could mean more Sugar developers and more kids getting learning software but would undermine XO sales... 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. That is what I have meant by porting Sugar to Windows. I think that creating a minimal version which can run most of the Python activities should took less than 1 man year (yes, I have read the MMM) so it is not too hard. Of course it would mean fixing some of them, for example the Sugar shell crashes on VirtualPC 2007 since it only implements SoundBlaster so the OLPC kernel does not recognize any sound card (and the Sugar shell assumes one). Also needs fixing activities to handle different resolutions from 1200x900 and alikes. If you ask me this is the path I advice taking. 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
Re: A technical assessment of porting Sugar to Windows.
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. While I have no affections for Windows, I must say that at least that end of things should not be a problem. Csound is completely multiplatform, runs on Linux, Windows, OSX (and even Solaris). So whatever OS is used, we can be there. But I would very much prefer Linux (then OSX and Windows is a very far third place). Speaking of this, didn't Steve Jobs offer OSX for free to OLPC at the beginning, but it was not taken because of the lack of FOSS credentials (even though Darwin is FOSS, is it not?). It seems funny that now OLPC considers going Windows... I sincerely hope this does not come to pass... Victor ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
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 [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 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
Re: A technical assessment of porting Sugar to Windows.
Hi Carol, I believe MS LiveMesh is a higher level concept than the OLPC Mesh. I think it requires a traditional LAN environment first, and adds functionality on top of that. Whereas the XO's mesh feature creates a traditional LAN environment out of thin air. I could be wrong though, I haven't researched it in detail! Regards, Wade ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: A technical assessment of porting Sugar to Windows.
On 24.04.2008 20:32, C. Scott Ananian wrote: 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. I looked at the OLPCFS page and it became very clear that OLPCFS is virtually identical to what Reiser4 was initially designed to be. Almost all of the listed OLPCFS features were present in the first Reiser4 designs and almost all were repeatedly vetoed by the Linux VFS guys (Al Viro and Christoph Hellwig) for design reasons, not code reasons. So if you want OLPCFS, try early Reiser4 snapshots (maybe for Linux 2.6.4 or so) and add one or two features on top of it. Sorry. I wish the idea would fly, but you may be in for some very tough criticism if you intend to have anything with a concept like OLPCFS merged in the Linux kernel. Regards, Carl-Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Organization was Re: A technical assessment of porting Sugar to Windows.)
On Thu, Apr 24, 2008 at 2:21 PM, Mitch Bradley [EMAIL PROTECTED] wrote: A general observation about organizational behavior: Organizations do not act coherently to nearly the same extent as individual humans. Individuals change their minds, act in ways inconsistent with their stated goals, respond to different external pressures at different times, etc. With organizations it is even worse, and the larger the organization, the more complicated it becomes. Organizational leadership changes, goals and external realities change, internal groups vie for influence, compete with one another and work at cross purposes. Different people within the organization make statements that are attributed to the organization. Expecting an individual to behave coherently over time is dodgy at best; expecting it of an organization is almost certain to disappoint. In the OLPC case, the leadership at the very top hasn't changed, but the second tier has changed, and the situation and external pressures have changed drastically. Yes, the middle tier is now supposed to be Kim Quirk (Technology), Robert Fadel (Administration), Charles Kane (Business Development), and whoever replaces Walter in Deployment. Has anybody heard? The failure to announce such things is one of my biggest complaints. Kim and Robert are adamant about not supporting first world deployments, although they sort of allow them. GiveMany is a joke, and the OLPC community isn't permitted to discuss projects like Illinois (100,000 units proposed) with the staff. I haven't talked to Charles. That reminds me. Do we have any idea what the Boards of Director and Advisors think about all of this? http://laptop.org/vision/people/ Does anybody have contact information for them? I have a few e-mail addresses. Well, I'll ask. Dandy, Ed, Joe; Alan, Mako (all bcc) pass it on, please, and read the thread. We think that Nicholas doesn't know what he is talking about with this Sugar on Windows idea and dissing Open Source, that he is and has been dangerously out of touch with staff and volunteers, and that he is now endangering the mission. Problems like this are supposed to be the reason for a Board of Directors to exist in the first place, so we want to hear that Board members are taking the issue seriously, and preferably see evidence that you are listening to what is going on, and understand the issues. Advisors, any assistance you can give will be appreciated. This is the time to advise, if ever there was one. Nicholas's post http://www.olpcnews.com/people/negroponte/nicholas_negroponte_sugar_olpc.html Replies and related posts http://lists.laptop.org/pipermail/devel/2008-April/thread.html#13140 On Sugar (Development) http://lists.laptop.org/pipermail/sugar/2008-April/thread.html#5173 On Sugar (Sugar) http://lists.laptop.org/pipermail/community-news/2008-April/thread.html#112 Where is Walter http://www.olpcnews.com/people/negroponte/open_source_fundamentalists.html http://www.olpcnews.com/people/negroponte/one_laptop_per_child_off_the_track.html http://www.olpcnews.com/people/negroponte/negroponte_is_further_gone.html http://www.olpcnews.com/people/leadership/walter_bender_resigned_from_olpc.html -- 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: A technical assessment of porting Sugar to Windows.
On Apr 24, 2008, at 2:32 PM, C. Scott Ananian wrote: That said, our Journal and datastore are in need of a rewrite.[...] 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. The datastore wasn't ever _supposed_ to be a real filesystem, and so it could do various Unthinkable Things in normal FS land, such as only exposing a HTTP REST API which gets used through whatever frontend is convenient, e.g. FUSE on Unix. If such an implementation existed, you could temporarily half-ass a Windows frontend via, say, WebDAV, which Windows (AFAIK) supports treating like a filesystem OOB. 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. In meetings with Microsoft, they stated unambiguously that they are unprepared to make _any_ changed to the XP kernel, which is a shipped product, to accommodate the XO. Only changes that can be introduced through normal 3rd-party extension mechanisms (such as drivers) are acceptable, which means overreaching power management changes are out of the question entirely. 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. Why do you think this requires source access and can't be handled by regular drivers? -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: A technical assessment of porting Sugar to Windows.
On Apr 24, 2008, at 7:52 PM, Carl-Daniel Hailfinger wrote: On 24.04.2008 20:32, C. Scott Ananian wrote: 11. Bitfrost: initial activation security. ... 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. AFAIK the hardware side of P_THEFT alias theft protection alias activation security/kill functionality has not been implemented, rendering all software efforts moot. In my opinion, shared by other engineers at Quanta, the proposed hardware side of P_THEFT would not have slowed you down much. Dremel-ing off the epoxy wouldn't take long. The effect it WOULD have is to add at least a hour (if not 24) of latency to the manufacturing process, and to decrease the manufacturing yield, both of which would have increased the price. I discussed this with numerous people at Quanta. On the other hand, I was told at lunch today by members of the Peru deployment that software activation is a critical and necessary feature. In previous deployments of computers, Peru saw a high theft rate in the delivery process. The activation process allows them to tell potential thieves and potential purchasers of hot systems that the laptops will be useless bricks. Have we made it impossible to steal and activate a laptop ? NO. Have we made it much harder ? Yes. Unless the manufacturing details have changed since my last inquiry, I can unlock ~4 XO machines per hour WITHOUT having a developer key. The only thing I need are some really affordable tools. If someone else disassembles the machines for me, I think unlocking 10 machines per hour is well within the doable range. Here in the US, the cost of disassembling, switching SPI flash chips, and reassembling approaches $60 - $70 dollars (I asked several small job shops for quotes.) For the record: I will not take orders for mass-unlocking unless ownership is proven. Thanks. wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: A technical assessment of porting Sugar to Windows.
On Fri, Apr 25, 2008 at 12:09 PM, John Watlington [EMAIL PROTECTED] wrote: The activation process allows them to tell potential thieves and potential purchasers of hot systems that the laptops will be useless bricks. That is the key message, and everything we can do to make it clearer, the better for kids and everyone. The Uruguay team has implemented their own activation/deactivation mechanism, sitting pretty high in the stack but with 30 day leases and blacklists. From what they say, it has been very effective as a deterrent. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
