Re: [IAEP] [Sugar-devel] Planning for the future (Samuel Greenfeld)
On Wed, Feb 25, 2015 at 1:20 PM, Jerry Vonau m...@jvonau.ca wrote: I know this is not a sugar issue directly, more of an OLPC issue but since Fedora F12 the entire i686 platform's userland is being compiled with -mtune=atom[1] which would use sse[2]. -mtune is designed not to break any compatibility. So -mtune=atom means that generated code is optimized for atom but *no compatibility with other CPUs is broken*. So -mtune=atom does not imply that gcc will spit out sse instructions because it feels like it. In fact, it will actively avoid generating sse instructions in order to maintain compatibility. (-march is probably what you are thinking of) This causes problems for some parts of sugar[3] now that java[4] is being used more and the XO-1 lacks sse. The WebKit issue happened because it generates its own machine code at runtime (not using gcc). It's definitely a bug that it dropped sse instructions in there without properly checking if the CPU can do sse, but not a common case that you will see throughout the distro. I assume you mean javascript there, and bug #4785 does not look like a sse-related issue to me. That issue shows a SIGSEGV whereas if code is using sse instructions you would instead expect a SIGILL. Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Question About 13.1.0 on XO-1s
On Fri, May 3, 2013 at 8:06 PM, Caryl Bigenho cbige...@hotmail.com wrote: Hi... Today I was helping some folks reflash the XO-1s they will be using in a small deployment in Los Angeles. After installing 13.1.0 we found that a scrolling display of code or something white on black... went by too fast to read appeared on startup. This was not just on the first startup, but on all startups. Is this necessary? If not, can it be turned off? How? Take a look at the very first messages that appear when you turn the laptop on - those ones (if any) are much easier to read. Most likely it says something like: Not updating firmware now - no external power If so, connect external power, power up again, it will upgrade the firmware then you will be back to normal. Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] gray dots forever: when 12.1.0 13.1.0 never fully boot (XO-1 especially? 11.3.1 too)
Hi, On Sun, Mar 10, 2013 at 2:41 PM, Holt h...@laptop.org wrote: On 3/10/2013 3:39 PM, Nancie Severs wrote: Going to 12 and 13, I am still getting a % of XOs that get stuck at the grey dots when booting after the reflash is complete. Richard Smith figured out that this is a Pretty Boot issue. He had a workaround that worked on an XO 1.5, but I have not been successful had getting that to work on an XO 1.0. I've the same issue with an XO-1 running Release 11.3.1 -- it was previously running March 6th's 13.1.0 Now it freezes at the end of prettyboot (once all grey dots have formed a circle). I think this is the first report we have of this issue. To diagnose further, it would be good if someone could hook up a serial console and log the boot messages. I know it's not trivial to have this available, but I can't think of other debugging approaches. Also, it is always helpful to know at exactly which point the system hangs. In Adam's case this was stated clearly (I interpret: once all the dots in the circle go dark grey after they have 'spun around' for a while) but in Nancie's case it wasn't. The other thing to keep in mind is that first boot takes longer than subsequent boot. So be sure to have a little patience before declaring the system as hung. Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [support-gang] gray dots forever: when 12.1.0 13.1.0 never fully boot (XO-1 especially? 11.3.1 too)
On Mon, Mar 11, 2013 at 10:31 AM, Nancie Severs olpc.dri...@yahoo.com wrote: I had it with a brand new blue high school XO-1.5 (that booted normally before I flashed it to 12.1.0). I took that one to the Boston office Richard Smith watched the boot and figured out the work around. Adam has it for Haiti now. I have XO-1's that do this that I can provide to someone to hook up log as you suggest. And I have a few new 1.5's that we can try and reproduce it on also, if helpful. My point is that the problem is not limited to the XO-1s. Richard, would it be helpful for me to bring some affected XOs down to the office if I can get to Boston later this week? That would be excellent, we'd just have to make sure that Richard and I have time to work through this at the right moment. Would you be leaving XOs there for a day or two, or would you need to take them away with you when you leave a couple of hours later? We won't be able to diagnose anything if we can't reproduce the problem of course, and it sounds like that at least today you are having trouble hitting this. That would complicate things. Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [support-gang] Yama First impressions, OLPC OS 13.1 31018
Hi Yama, Thanks a lot for the feedback - all very useful. Focusing mainly on the items where a quick answer is possible: On Fri, Dec 14, 2012 at 6:35 PM, Yama Ploskonka yamap...@gmail.com wrote: *Sugar GUI* Terminal is hidden again. If someone /deserves/ Terminal privileges, they can learn how to get it, so it's OK Terminal isn't in the favourites view by default - thats indeed correct, but it's been like that for at least 2 years now, probably longer. This is easily overrideable by deployments if they wish. 2) Mayan numbers for the Mesh Network was announced many times, but AFAIK never implemented. Mesh icons are still undistinguishable from each other The mayan numbers are used for the ad-hoc network points used on XO-1.5 and newer. These networks behave differently from the mesh, so the visual difference does make some sense. The XO-1 mesh icons could indeed do with some love. Bottom line, after just a first look, Sugar doesn't seem improved, but Gnome is much, much better than it ever was (even good desktop Gnome OS versions used to have issues with the files I need) Yes, Sugar has not heavily changed for existing laptop users this time around. My first stab at http://wiki.laptop.org/go/Release_notes/13.1.0 gives some indication of where our efforts have been: touchscreen usability and XO-4 hardware. However, old platforms are not forgotten, and hopefully we'll be back to a broader ranging set of improvements for the next release. Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] 13.1 ? and 12 ? Re: Sugar Digest 2012-11-30
On Fri, Nov 30, 2012 at 12:07 PM, Yama Ploskonka yamap...@gmail.com wrote: 2) What is the role of these 31012 builds? are they meant as an official update? are they undergoing further testing? In short, should I point people to those instead of to the 21021? The naming scheme is described here: http://wiki.laptop.org/go/Release_Process#Version_numbering So really what you are asking is: should you point people at 12.1 or 13.1? http://wiki.laptop.org/go/Releases shows you that 12.1 is the latest stable, and 13.1 is in development. So it depends if you are working with users or developers... background: the link Walter offers (thanks!) http://build.laptop.org/13.1.0/os13/ has only XO-4 files... The de...@lists.laptop.org list has build announcements - thats the best place to keep up with whats going on. In this case build 13 was never announced; the build 12 announcement did mention that build 13 would be XO-4 only. Also, if I look for 12.1 files, here: http://build.laptop.org/13.1.0/os12/xo-1/ they are named 31012 Your mistake here would be that you are looking for 12.1 files in a 13.1.0 directory. You can find 12.1 final on http://download.laptop.org or on the link you include below: while http://wiki.laptop.org/go/Release_notes/12.1.0#XO-1 points to 21021 ones That is the 12.1 final release. BTW, the os14 directories /do/ have X0-1 files, but I guess that's trying timetravel :-) http://build.laptop.org/13.1.0/os14/ Thats 13.1.0 build 14, the latest announced 13.1 development build. Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Fwd: [Sugar-devel] SugarCamp in Paris -- save the date: September 9th-10th-11th, 2011
On Fri, Aug 19, 2011 at 12:19 PM, Christoph Derndorfer christoph.derndor...@gmail.com wrote: I spoke to Simon yesterday and he said that both he and Daniel are going to attend from Saturday to Monday evening. :-) Daniel has also added some more accomodation options to http://wiki.sugarlabs.org/go/User:Bzg/SugarCamp. However looking at the options it seems like many of them are already quite full that weekend so we should really make a decision here! Again, having a head-count of who needs accomodation would really help so everyone please add your information to the wiki page. Yep. +CC Raul and Gary - please add info to http://wiki.sugarlabs.org/go/User:Bzg/SugarCamp p.s. just booked my flight - will be there from Saturday afternoon til Monday evening. Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Anyone up for a post Sugar Camp Hack Day? (was: Registration for the Sugar Camp in Paris (sept) are now open)
On Wed, Aug 3, 2011 at 4:07 PM, Christoph Derndorfer christoph.derndor...@gmail.com wrote: Hi all, speaking to Sascha earlier today he mentioned the idea of having a small post Sugar Camp Hack Day or something. I had already bought my flights for September 9 (Friday) to 14 (Wednesday) anyway so I'll definitely be in town. I assume many others of the registered participants (http://fr.amiando.com/olpcfrance-sugarcamp2011.html;jsessionid=57C0354E37E6A4A314890B401B6EEF56.web02?page=571393) are buying their tickets these days as well so it would be good to get a head count of who would be up for such an event:-) I think this is a great idea. I'm looking into the possibility of attending, but that weekend is a bit complicated with some university and moving commitments (Monday OTOH would be fine). I'd like to push PyGI/GTK3 porting as the main activity of such a hack day... http://wiki.sugarlabs.org/go/Features/GTK3 Please keep me informed on accommodation as well. Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [support-gang] [ANNOUNCE] Sugar Labs Licensing Referendum (non-binding) results
On 11 July 2011 03:23, Gary Martin garycmar...@googlemail.com wrote: Hi Luke, I was surprised as I had no recollection at all of the original email (subscribed to way too many Sugar related lists), but after some digging found it had been clobbered as junk email, so not sure who else this may have hit, but thought it worth mentioning. I was not included on the members ballot even though I have voted before. Similarly, I wonder if I'm the only one in this situation. Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] !! in 10.1.3, setting languages property clears all activities
Hi Tim, On 30 January 2011 13:44, Daniel Drake d...@laptop.org wrote: On 28 January 2011 15:36, Timothy Falconer tee...@waveplace.org wrote: sugar-control-panel -s languages Kreyol/Haiti And after restarting, ALL OF THE ACTIVITIES ARE GONE. Can anyone confirm this or give me guidance. How can I set the language in a bash script in 10.1.3? I imagine this is because the language is not included. Sorry, I overlooked something and lead everyone down the wrong path. Kreyol *is* included in 10.1.3 (and in our development builds), just the particular command you are using is broken (a Sugar bug, also present today, http://dev.laptop.org/ticket/10681) The 2 workarounds are: 1. Set the language inside the sugar control panel GUI (the GUI works, the command line interface is broken) 2. Adjust your script so that instead of calling sugar-control-panel, it just writes a file at /home/olpc/.i18n with these contents: LANG=ht_HT.utf8 LANGUAGE=ht_HT.utf8 In script terms this is: cat EOF /home/olpc/.i18n LANG=ht_HT.utf8 LANGUAGE=ht_HT.utf8 EOF Apologies hope this helps! Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] !! in 10.1.3, setting languages property clears all activities
Hi Tim, On 28 January 2011 15:36, Timothy Falconer tee...@waveplace.org wrote: sugar-control-panel -s languages Kreyol/Haiti And after restarting, ALL OF THE ACTIVITIES ARE GONE. Can anyone confirm this or give me guidance. How can I set the language in a bash script in 10.1.3? I imagine this is because the language is not included. What version of the software did you last successfully run this on? The languages included in 10.1.x are: en_US,es,ar,pt,pt_BR,fr,ht,mn,mr_IN,am_ET,km_KH,ne_NP,ur_PK,rw,ps,fa_AF,si,zh_CN Reconstructing the image with another language added is as easy as having good bandwith and a Fedora 11 machine available (which is probably very difficult if you are in Haiti). The target XOs must all be unlocked (security disabled). I'd be happy to guide you through the build process if this is an option for you. Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] !! in 10.1.3, setting languages property clears all activities
On 30 January 2011 14:10, Yamandu Ploskonka yamap...@gmail.com wrote: Daniel, wouldn't it be simpler that someone who knows how to do it does build that image, uploads it somewhere so Kreyol people can just download the image in one go? Yes, thanks for volunteering ;) However, It still depends on unlocked laptops and enough bandwidth in Haiti to download the end result, so I'm not sure how much this helps Tim. Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] !! in 10.1.3, setting languages property clears all activities
On 30 January 2011 14:57, Paul Fox p...@laptop.org wrote: daniel wrote: Hi Tim, On 28 January 2011 15:36, Timothy Falconer tee...@waveplace.org wrote: sugar-control-panel -s languages Kreyol/Haiti And after restarting, ALL OF THE ACTIVITIES ARE GONE. Can anyone confirm this or give me guidance. How can I set the language in a bash script in 10.1.3? I imagine this is because the language is not included. What version why would this make the activities disappear? We have a ticket, which I can't find right now, which shows a case of Python blowing up when the environment selects a locale that doesn't exist on the system. Thats my guess. Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] stepping down as maintainer
On 24 October 2010 05:42, David Farning dfarn...@ubuntu.com wrote: Sugar Labs lost its lead developer. It is unfortunate that no-one has done a public review of the reasons and implications of Tomeu quiting. Tomeu's leaving is significant enough that Sugar Labs should take a hard look at what is working, what is not working, and how to fix the pieces that are not working. I think a lot of contributors forgot to be nice to the maintainer. If I were in Tomeu's position I think I would have stepped down a while ago (I've been put in what I think are similar positions in other projects I've been involved in). Too much emails and not enough code, simple maintainers wishes being ignored, nobody stepping up to help the maintainer with the increasing workload, etc. A key part of contributing to an open source is keeping the maintainer engaged and motivated. Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [RELEASE] Etoys 4.1.2384
On 30 August 2010 03:50, Bert Freudenberg b...@freudenbergs.de wrote: This is the first beta release of Etoys 4.1. The biggest change is that stopping the Etoys activity will no longer save to the Journal. To save, you will have to press the keep button. The octagonal stop button is replaced by a circular exit button to indicate the new behavior. It puts up a warning before actually quitting. I'm worried that this is further going to contribute to the keep confusion that exists all over the world. Can I suggest that you start a [DESIGN] thread and seek some input from the design experts? (regarding how to present this new you must save technicality, not the well-justified decision to not save on stop like other activities) Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Redesigning: Library, Read, Get-Books, and Content bundles
On 20 July 2010 12:33, Reuben K. Caron reu...@laptop.org wrote: So what if we created a Library Activity The activity would: -Open a book from within the activity -Highlight and annotate books -List all of the books you have downloaded -Allow you to search and download additional books from Feed Books, Internet Archive, the XS, etc.. -List the resources in /home/olpc/Library (so this can be removed from Browse) -Allow one to synchronously or asynchronously share a book to their Neighborhood so anyone can download and read it. I'd argue that some of this is duplication of functionality that belongs (or already is) in the Journal and the Read activity, having such a design might kill some UI complications but add others. Parts of your concerns could be addressed with some ideas I wrote here: http://wiki.sugarlabs.org/go/Features/Content_support#Accessing_content_from_home_screen I agree that this definitely merits further design/discussion. Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Sugar Digest 2010-06-10
On 10 June 2010 16:13, Christoph Derndorfer e0425...@student.tuwien.ac.at wrote: I hate to play devil's advocate here (naaa, not really;-) but one might argue that based on what little we know about OLPC in Peru, arguably the 2nd largest OLPC / Sugar project at the moment, this (simply passing out XOs and getting out of children’s way.) is pretty much exactly what seems to be happening. While the deployment info is less public (and less publicized?) than most, and while like any deployment it faces a fair share of challenges and difficulties, it's not like this. Daniel, in Peru ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] Really cool developments with SoaS v3
There have been some nice little changes in various parts of SugarLabs recently which make me happy to see that core contributors are really thinking about sugar sustainability and sugar in the field, but I think we've all just been blown out of the water with 4 really great things about the new SoaS release that I'd like to highlight: 1. Scaling to appropriate resources - given that the community isn't that big, they've cut back to something that's maintainable and sustainable, with clear processes, and ideas on how to grow as more resources become available. 2. Piggybacking from other communities - by making sure that everything is sparkly clean and by positioning themselves within the bounds of Fedora's organization, rules and guidelines, they've won support and assistance of Fedora and its community, to the point where SoaS is a download from Fedora itself, and is prominently featured in the Fedora 13 release notes (extremely cool!): http://fedoraproject.org/wiki/F13_one_page_release_notes?F13an 3. Local requirements - I see a change in model with the v3 release, from a model that I never thought would work well (1 version of SoaS for the whole world) to the simple distribution of a reference platform with a clean process for making customizations, which is realistically something that the vast majority of significant soas deployers would want to do. 4. Build/customization documentation - in addition to actually adjusting the process to make customization clean and possible, they've written *good documentation* on how to do it, even ready for the release date and not done as an afterthought: http://download.sugarlabs.org/soas/docs/customization-guide/ Thanks to the SoaS contributors, great work! Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] ANNOUNCE: F11 for the XO-1 build 140py released
On 16 April 2010 19:52, Bernie Innocenti ber...@codewiz.org wrote: Regardless of whether you use the updates bit or not, you'll want to reinstate that server configuration so that the laptops can receive lease updates before expiration (Raul told me that they have switched this feature on a while back when school holidays were approaching). I'd say this is still working fine, because laptops perform activation from wifi just after being flashed with the new OS. Is there anything else I should check for? I have very little understanding of the internals of OATS. This is the fetching of leases from the school server once they have expired (or for the cases when there is no activation at all, e.g. right after reflash). Thats the first way that laptops can receive leases. This codepath does not execute at other times. And it only works when you're in-school. The other way that they receive leases is through the olpc-update-query cronjob which basically ends up with olpc-update-query querying the internet-based paraguayeduca mothership once per day. This server will deliver updated leases to the XO laptops *before* they expire, which has a few advantages. (for example, there was one time when Raul realised that the current round of leases were set to expire in the middle of a long school holiday. this system was used to deliver much-extended leases in the final week of school before the holidays set in). I agree with the idea of using a more standard system, but I'd say that yum is not yet a suitable replacement based on a discussion that I started based on this exact question in the beginning of the XO-1.5 development cycle. It's in the archives. Interesting. Do you remember the subject? update mechanism for new releases Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] ANNOUNCE: F11 for the XO-1 build 140py released
On 15 April 2010 15:48, Bernie Innocenti ber...@codewiz.org wrote: I noticed that Stephen Parrish had removed olpc-update from F11-XO1, which made /versions also superfluous. Besides the nice saving in space, disabling the versioned fs considerably sped up olpc-os-builder. I'd be surprised if there is any significant saving of space. As for build time, that would also surprise me but I'm not so familiar with the technicalities of mkfs.jffs2 - perhaps it does take a lot longer for lots of links. Hmmm... perhaps I should reconsider this decision. We'd first have to do some testing to ensure your original work still works well with F11-XO1. Last time I looked, the hostname of the update server was hardcoded inside olpc-update. Did you create a custom package to point it at the schoolserver? olpc-update-query is the component in question. You need to point it at the mothership like was done in the 801 image, not the school server. If there is an update available, the mothership will ask olpc-update-query to run olpc-update using rsync from the local school server. The new olpc-update-query version will look on the school server first, then a server configured in /etc. (make sure you're using olpc-update-2.22 then you can use the oats_cfg module of olpc-os-builder for this configuration). There is also the option to make it bypass the school server and use the other one directly -- thats what I'd suggest for Paraguay. Regardless of whether you use the updates bit or not, you'll want to reinstate that server configuration so that the laptops can receive lease updates before expiration (Raul told me that they have switched this feature on a while back when school holidays were approaching). For a future release cycle, we may want to re-evaluate yum-updatesd as an alternative to olpc-updates which provides different trade-offs in terms of performance, robustness and distro integration. At the time olpc-update was written, yum was still awfully buggy and unreliable. I agree with the idea of using a more standard system, but I'd say that yum is not yet a suitable replacement based on a discussion that I started based on this exact question in the beginning of the XO-1.5 development cycle. It's in the archives. Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] ANNOUNCE: F11 for the XO-1 build 140py released
On 14 April 2010 13:22, Bernie Innocenti ber...@codewiz.org wrote: * Remove olpc-update and disable the /versions kludge (me, smparrish) Great work Bernie! This is the only bit that seems a bit surprising to me. Granted, the /versions system is a little perplexing (but it works, and is being shipped on XO-1.5, so it has good support in the present day). And granted, it doesn't work for large substantial updates, and doesn't update activities. But it is a nice system for small updates, with fairly good documentation. It has only a 15mb overhead. I also set up all the infrastructure in Paraguay to push these to schools and XOs automatically, and we actually rolled out a tiny update in 1 school to test it (worked perfectly first time). And I documented it. Being the first deployment to run with this substantial software update, it seems somewhat likely that you'll find a few niggly bugs that would be nice to fix in the coming weeks. olpc-update would provide you with a mechanism to do that with minimal effort. Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Future of Zero Sugar
On Tue, 2009-12-15 at 06:07 +, Aleksey Lim wrote: * as a 3rd party developer, I don't see such teachers requests listed somewhere on wiki, that let me see what can I do and peek most interesting/suitable-for-my-skils/etc task There's enough going around that you could work on which would be a huge benefit to deployments. Here are a few ideas. We know about projects from Paraguay and Uruguay implementing 3G support. Why not step in early and review their code and send them some patches? Look for bug reports from Soas developers and users, and OLPC too. These people are likely closer to deployments than you are. Here are OLPC ones: http://dev.laptop.org/report/43 (you'll have to filter the list) You could perhaps try and put yourself into a role where you address these needs on an ongoing basis. This would be a dream come true for deployers and distributors. Some more project ideas here: http://www.mail-archive.com/sugar-de...@lists.sugarlabs.org/msg10631.html Documentation: there's very little good documentation on how to deploy sugar in a classroom scenario. If you were to start some documentation, not only would it be a huge help for deployments, it would also make you think more about the real-life challenges which may lead to some development projects. Bryan's point about Sugar not supporting the classroom scenario of handing work to your teacher is a good one. Some things that I think would be of large benefit: Supporting the mass of content that has already been generated: http://wiki.sugarlabs.org/go/Features/Content_support This would help simplify ad-hoc networking: http://lists.laptop.org/pipermail/devel/2009-December/026831.html This is a biggie: http://bugs.sugarlabs.org/ticket/1608 I suspect this flicker is going to be quite disruptive for field users: http://bugs.sugarlabs.org/ticket/1596 F11-for-XO1 work would be of a huge impact to the largest part of sugar's current userbase. Right now they cannot receive any of the improvements you make to sugar because the project is not (quite) stable enough for deployments. It has a buildmaster but not much development progress apart from the bits that can be directly picked up from OLPC's XO-1.5 work. We seem to even lack good diagnosis of the outstanding problems. You could look at Sayamindu's recent tickets on bugs.sugarlabs.org. We have identified various places where sugar cannot gracefully deal with corruption. I believe there are still various well-known 0.86 regressions (over 0.84). For example, Record not working. These regressions are going to be a huge headache to anyone who tries to upgrade, perhaps you could squash a few of those. OLPC mesh: NM-0.8 now supports this, sugar patch needs to be brushed up and merged. And help backporting the patches to NM-0.7 would be useful too. * I'm feeling huge discomfort as a developer when I need to package binary blobs to my .xo, w/o instrument which let me unify installing/upgrading process of such non-SP/specific-to-my-activity dependencies I feel this too. But you can solve it with less drastic changes. Which you seemed to be doing already. I've read briefly over your various 0install feature proposals and I've yet to form an opinion on the technology. I need to read them again, but at least on my quick reads, I'm still left unaware what the user experience will be like, nor the developer experience, and what the inefficiencies of the system will be. Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] decision panel: waste of time
I've looked at some initial discussion on the decision panel (I don't even have time to read all of it) and I think it's time to go back to the start. For each question: who's asking? is it a reasonable question? have we definitely failed to reach community consensus? what effects will the answer have? Sebastian asked the original question: Is the current SoaS going to be the primary way Sugar Labs distributes a Sugar-centric GNU/Linux distribution? After communicating with Sebastian by IRC and email (me being skeptical and curious why this question was even being asked), I learned that Sebastian is not trying to make his SoaS project be the king-of-all-distributions (he encourages competition) but simply wants to know if it is safe to call his project Sugar on a stick. The original question doesn't matter to him, or perhaps we can say that the original question was developed to becoming a simple question of project naming. So that leads to what I believe is the only question with any importance: Should 'Sugar on a Stick' be a phrase that SL asks its community to avoid using unless they refer to the SoaS-Fedora distribution? Who's asking? Sebastian Is it a reasonable question? Yes. There has been some confusion about use of the name: - Sugar on a stick has been a concept within the community for a long time, only recently has it become a solid, mainstream implementation (and even then, there was still a strong element of concept in the marketing) - Non-Fedora distros have also started making sugar distros that run from live USB, and although they haven't been named Sugar on a stick, I recall at least a few mentions from people in the community referring to them that way - Another party registered the domain name sugaronastick.com Have we definitely failed to reach community consensus? Yes, there seem to be 2 common conflicting viewpoints: - Sebastian has done great work, let's give him the name and get any other projects to use new names - No, lets reserve the name as a marketing term, for clarity of message. (even though Sebastian can use it for now) It's trivial to find examples of these conflicting viewpoints in the threads that have emerged so far What effects will the answer have? Sebastian has indicated that it's important to him, and a decision here would affect how he names his work and possibly where he hosts it, and which umbrella organisation he sees his work underneath. The other questions all fail the tests in my opinion - nobody is asking them for any practical purpose, and the results from a decision panel will not have any effect. For example, the decision panel could say that SL should focus on being a distro builder, but what does that even mean? All SL work is volunteer based, that answer isn't going to magically make people start doing that work where they weren't before. I also think that any kind of decision delegation should be done by a small group, in a short time, and with only a small amount of extra community input (the decision was handed off to a panel precisely because the community could not reach consensus). Let's finish the politics quickly and move back to real work... remember our goal: education? Daniel p.s. I'm still not clear if this decision panel has been formed for every undecided question that might possibly form in the future, or if it will be torn down after this particular session? ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] [SLOBS] Long-term support for Sugar
Hi, 2009/9/22 Benjamin M. Schwartz bmsch...@fas.harvard.edu: This is incompatible with our (or at least my) goal of allowing users to throw packages around as atomic objects, without internet access and without having to understand anything beyond my friend has Sugar, so it will work. It is also incompatible with allowing novices to generate first-class Activities. And to throw in a contrasting view: I feel it's unrealistic and uninteresting for the field. (even though I would personally be thrilled to see this) Before I go further, I want to re-enumerate the items of discussion and the outstanding problems with the .xo format. First of all the problems with our current activity packaging: 1. Versioning system sucks, in that it's not obvious which version of Sugar's activity-exposed APIs each activity is compatible with and you can't even specify this in the metadata, and hence Sugar can't even reject activities that we know simply will not work on version x.y.z. 2. Because there is no user-friendly way of installing system-level libraries, and the bundles itself cannot specify dependencies to be automatically installed, and even because of a variance of system libraries available on different sugar distros, we end up with a common practice of including precompiled libraries within activities. This is a waste of disk space, makes bundles architecture-specific, sometimes even makes the bundle specific to a certain set of system libraries or a specific ABI even within the same architecture, and includes the usual disadvantages equivalent to regular software using static instead of dynamic linking (if a single bug in a supporting library is uncovered, multiple bits of software must be patched, released, distributed, built, and installed). 3. Sometimes, even though the activity does not require any extra libraries, an activity bundle includes native code -- for example, someone ports a C/GTK+ app to Sugar - this often involves the C code being compiled for Fedora/x86 then bundled up with a Python wrapper inside a .xo bundle. This has some of the same disadvantages as above - it becomes architecture-specific and ABI-specific. and, in addition to solutions to the problems described above, people want: 4. The ability to send a Sugar activity to any other Sugar user, regardless of Sugar version, underlying distribution and version, and even system architecture 5. The ability to modify activities, revert modifications, and share modified versions with other Sugar users. (there are other difficult/controversial things that people want too -- for example, a guarantee that a shared activity instance of ActivityX on Sugar-0.86 will continue to be compatible with the shared activity instance of ActivityX on Sugar-0.94, but I'll try and keep this discussion limited to the .xo bundle format itself) and features that we have already that people regard as important: 6. The ability to create a .xo bundle in a simple way from any platform, and ease of installation onto XO My own thoughts: 1. Versioning scheme - probably the easiest thing to discuss as it can be solved easily within the current format. My vote would be to adopt GNOME's versioning scheme of basing component and application versions on the version number of the platform. e.g. Write-0.88.1, Paint-0.86.4, etc. 2. Shipping of binary libraries within bundles - I hate this, even just because of the duplication. Never mind that it's become a common practice and is wholly incompatible with Sugar's cross-platform goals. I think we have 3 options available - switch to using distribution package systems which have already solved these problems. let the distributors take care of this... - move to a model where several .xo bundles are generated for each activity release (e.g. one for Fedora9/x86, one for Fedora11/x86, one for Fedora11/ppc, one for Ubuntu/x86, etc) - ban or discourage this practice, and clearly define which system libraries are available for activities My opinion is that distro packaging is the best option, so that installing the Physics activity can install a system copy of Box2D from distro repos at the same time. For the Sugar-side implementation, PackageKit would be the obvious way to go, but as a plan B it would even be OK (in my opinion) to individually support the common package managers in modular fashion. 3. Native code on the application-level only: almost exactly the same set of solutions as (2) and my opinion is the same. 4. Sharing of activities between hugely varying systems: The only real solution to this that I have seen proposed is for *all* activities to switch to some kind of cross-platform VM platform (e.g. Java) which guarantees eternal forward-compat and backwards-compat and will be able to run on any architecture that we might want Sugar to end up on. There is no other workable solution that has been discussed -- shipping .xo bundles with native code cannot work if we are to accept that Sugar runs on
Re: [IAEP] XO Special interest group at Sugar Labs
2009/9/21 David Farning dfarn...@sugarlabs.org: The project is starting with work flow focused goals. 1. Create a team. 2. Create a release cycle. 3. Start cranking out releases each one better than the last. The missing gap in the current Sugar- distro- XO workflow is that CJB is working from the deployment and hardware back to the distro and Sugar. This is both necessary and exactly what OLPC _needs_ Chris to focus on. (Think of the relationship between redhat and fedora) But, he and the entire ecosystem would benefit from a time based release focus upstream. That way they can pick an upstream and spend six or eight months making it deployment ready rather than starting from scratch every year or eighteen months. I don't understand this. How is what you are proposing different from what has been done before, and is happening now? When are we starting from scratch? It would be great if you would bring your work into the project. As far as I can tell, you and Chris are the two most knowledgeable people working on this problem. Not sure what your time available is:) Hopefully, we can build a tight team to make your work more widely available. The goal is to provide a place where the various people working on 'upstream' XO, disto, and Sugar issues can come together, tighten focus, and make their work available to the widest possible audience. I think we have most of those things quite well covered already: - we have mailing lists for coming together, which are already being used for this purpose - we have hosting from OLPC - Stephen Parrish appears to be a focused buildmaster I think what's missing is developers and/or high-calibre testers who are able to provide detailed technical diagnosis of bugs. If your group could bring in some of those resources, it would be of huge value. I don't feel that a release cycle would be that useful. At least to me, that implies that you'll spend some time on feature development, then close that off for bug-fixes only as the release date nears. Well, really all the features have been developed already, and the only thing left is bug fixing anyway. And the couple of features that are missing are big regressions for deployments. I would think that putting a date on a release and closing the door to the feature regressions is not really going to do anything positive at this stage. Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] XO Special interest group at Sugar Labs
2009/9/22 David Farning dfarn...@sugarlabs.org: Because of time restrictions, the F11 on XO effort seems to be reactive. They take the output from cjb and the fedora packages and create builds. Is this a criticism? Are you proposing changing this? I believe that the XO SIG could help generate interest and attract more developers and testers to the project. That would be excellent. I'd encourage you to go ahead and create it so that these resources can start flowing. I don't think you need to say that F11-for-XO1 is part of the XO SIG -- the fact is that we all have the same goals, and Steven isn't going to reject help from anyone. This is the same way that the Fedora OLPC SIG was set up to help OLPC - it provides valuable assistance on various fronts but the actual product was still quite firmly under the OLPC roof. If you do want to formalise things and say this is now a Sugar project, then that could be done at any point, but this should not be a barrier to getting people involved right now. Would it be useful if we started by combining your work and Stevens into an automatic build system. This could help identify breakages. By creating the daily builds and widely broadcasting the various releases, we can engage a larger community of testers. The build system would be trivial to automate, and I'd encourage you to do it as an exercise. Coordinated testing and a release cycle would of course be very beneficial to achieving the same quality of release as OLPC has done previously. It would be of value if you were to set that up. However, at this stage, I feel that both of those things would be severely hampered by the slow development pace. I would instead suggest that you focus on bringing in developers and technical resources at this point in time, leaving testing and release planning for a little later down the line. Thanks for your efforts! Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] [SLOBS] SoaS: Searching for Decision Panel volunteers.
2009/9/20 Bernie Innocenti ber...@codewiz.org: I can't volunteer to serve as a member of the volunteer panel, but I'd like to offer my viewpoint on this issue. I agree and I also feel that we have consensus on those 2 things (SL should promote SoaS, SL should treat distributors equally). The 3rd, about naming, is where we have conflicting viewpoints. Some feel that the sugar on a stick name should be permanently assigned to Sebastian's Fedora-based project, but there are some opposing viewpoints: Sean wrote: Of course, such a scenario raises other questions. If Fedora SoaS is the official version offered to parents and teachers, what happens if a different distro does a better job with a liveUSB implementation? The day a liveUSB version of Sugar contains a risk-free hard-drive installer (if such a thing is even possible) and close integration with the XS server, entire fleets of schools' machines can be flipped to Sugar. Should that better version become Sugar on a Stick? My answer is yes - because it is Sugar Labs building up the brand equity in Sugar on a Stick, and it is Sugar Labs that should have final say about what it is and what it means. Tomeu wrote: I think the problem is that SLs may want to market an user-end distro and only one, and call it the same regardless of the underlying technologies, because the user doesn't care about those. Yamandu wrote: I believe SL should support and highlight the best, generally allowing the others to call themselves a SOAS if they want to, and also be mentioned in SL web pages and presentations, with the reasonable caveat that they are even more so works in progress than the highlighted SOAS I don't quite understand this decision panel stuff. Is a different decision panel elected every time there is an undecided issue at hand? Or do we elect one group that remains in place for all unanswered questions, present and future? Everyone here seems to already have their own opinions already, and we have already discussed them, provided our own reasoning, and read the views of others. So it seems like the vote of the decision panel would only be unanimous if you were to pick people only on 1 side of the argument.. and the number of votes each way would depend exactly on who you pick for it. Why can't the oversight board make decisions directly? It seems to me that they were voted for based on the fact we trust their vision for the direction of sugarlabs. and it would save us a lot of time and email... Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] XO Special interest group at Sugar Labs
2009/9/21 David Farning dfarn...@sugarlabs.org: My idea is to start by getting a working version of the current versions of Sugar and Fedora running on an XO. The SIG might lose some of the specific hardware benefits and mass deployment features on the first couple of iterations. But, it can work towards the larger deployments needs as the development, testing, and triaging processes improve. Thanks for the initiative. How do you plan to work with the existing efforts? e.g. SoaS ported and modified for XO, and F11-for-XO1 Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] SLOBs Position on SoaS
2009/9/16 Sebastian Dziallas sebast...@when.com: Let me rephrase again, to make things clear. I'd love to hear an official answer on this. Soon. Is the current SoaS going to be the primary way Sugar Labs distributes a Sugar-centric GNU/Linux distribution? Isn't there a wider question first? the one that asks if Sugar Labs is actually interested in being a distributor rather than just an upstream. I raised that question in my recent discussion and my feeling is that the responses basically said well we should really just focus on being an upstream since we already are overworked there, but actually Sugar Labs is just a platform where everyone interested in Sugar can get together and run Sugar-related projects Based on that, I'd say that SoaS is a fine project to sit under Sugar Labs but there shouldn't be a primary way of getting Sugar. Like other upstream projects, Sugar Labs should work with multiple downstreams (treating them equally) in order to achieve wide adoption of the software. Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] SLOBs Position on SoaS
2009/9/16 Daniel Drake d...@laptop.org: 2009/9/16 Sebastian Dziallas sebast...@when.com: Let me rephrase again, to make things clear. I'd love to hear an official answer on this. Soon. Is the current SoaS going to be the primary way Sugar Labs distributes a Sugar-centric GNU/Linux distribution? and to answer a question with a question: how does the answer to this affect your work? I can't immediately see its importance. Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] [SLOBS] SLOBs Position on SoaS
2009/9/16 Sebastian Dziallas sebast...@when.com: Now it comes to what I think is important in a project. And that is - also - certainty and trust. Those are pretty important factors. For developers, as well as for users, to know where one stands. Personally i would just get on with it and let the code do the talking... Produce the best distribution that you can and people will use, respect and protect it. In the unlikely event that SL screws you over, take the project somewhere else, you'll still have your users because your work is high quality. And in the worst-case scenario you have to change the name, but everything else can stay, and you'll still achieving your goals - education. Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] [SLOBS] SLOBs Position on SoaS
2009/9/16 Tomeu Vizoso to...@sugarlabs.org: I cannot speak for Sebastian nor the whole SoaS community, but something like making SoaS an official project in SLs could go a long way. This would mean saying that Sugar on a Stick is a project with this vision, this mission, this roadmap, this governance model, etc. Yes, that makes sense. Sebastian, if it were made a project would that clear up your doubts? This isn't giving SoaS any special treatment -- any project that comes close to the calibre of soas is obviously candidate to become recognised as an official project. Also discussing like Sean has made the possibility of an hypothetical switch to another distro is very good I think. Better have this on the table than letting it be hidden in the backs of our minds. I don't think it would be fair to take over the name of another project. If another distro project comes along, I feel that it should pick its own name. And is the name really that important? As an example, the existing OLPC distros never really had a name. I call them e.g. OLPC OS 8.2.0 but there doesn't seem to be any consensus, and it hasn't been a hinderance in adoption. The users don't really get to see the bits that are underneath, so they only refer to Sugar anyway. Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Deployment Team meeting on Wednesday September 2nd - 14:00 UTC
Hi, 2009/8/31 Pilar Saenz mapis...@gmail.com: Next deployment team meeting Wednesday September 2nd - at 14 UTC (9 EST) on irc.freenode.net (English channel: #sugar-meeting Spanish channel: #sugar-reunion). Thanks for organsing the meeting. Can we please introduce some variance in the day and time for these meetings? Like the last Wednesday 1400 meeting, I will not be able to attend :( Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] (Ab)using the Journal for stuff that the user didn't do, create, or access
2009/8/17 Tomeu Vizoso to...@sugarlabs.org: On Mon, Aug 17, 2009 at 12:52, Daniel Draked...@laptop.org wrote: 2009/8/17 Tomeu Vizoso to...@sugarlabs.org: I don't see where we disagree any of us OK.. so what do you suggest as the next steps? File a ticket? Start a feature page? Feature pages, I would say. We have already some design proposals in the wiki, but I'm not sure if they cover all we have mentioned in this thread. OK I wrote down some thoughts here: http://wiki.sugarlabs.org/go/Features/Content_support ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] (Ab)using the Journal for stuff that the user didn't do, create, or access
2009/8/11 Tomeu Vizoso to...@sugarlabs.org: You mean that you cannot open that library bundle by clicking on its journal entry? Correct me if I'm wrong, but none of the methods that could be used by deployments to distribute materials this way in mass would result in a journal entry appearing for their users. These methods are installing through a package into /usr/whatever/library or unzipping into ~/Library. Didn't thought about pushed updates, can they execute post-install scripts? If so, they could use copy-to-journal. This only works when there is a journal created, so deployers would have to hook into the exact moment after the user types in their name and chooses colours as this is the earliest time when the journal is created. Doesn't sound sensible. This also wastes disk space as it results in 1 copy of the library bundle in the journal, and another copy uncompressed on disk. And am I the only one who feels like this is a role for the Sugar shell and not for the journal? I've seen this kind of Journal-based solution proposed for a couple of problems now, and I'm not keen on it. At least until this point, the journal has been for recording what the user has done, created, or accessed. With this kind of approach, we'd now be going into classrooms asking users to look for something in their journal which they've never seen before, and has never been a part of their interactions. I much preferred the previous trail of discussion which was that content would be treated as the same class as activities -- i.e. we'd be extending the home screen somehow, to deal with potentially lots of activity icons, or to become additionally a hub for opening any books that are saved on the system, or something like that. In other words, moving the functionality of olpc-library directly onto the home screen. Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] (Ab)using the Journal for stuff that the user didn't do, create, or access
2009/8/17 Tomeu Vizoso to...@sugarlabs.org: I don't see where we disagree any of us OK.. so what do you suggest as the next steps? File a ticket? Start a feature page? Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Deployment feedback braindump
Hi Tomeu, 2009/8/10 Tomeu Vizoso to...@sugarlabs.org: Hi, some thoughts follow. Please keep in mind that these are just my personal opinions and that not everybody at Sugar Labs share the same idea of what SLs is or should be. Thanks for the response. What you are saying makes sense -- it is indeed a nice idea to keep SugarLabs as more of a loose structure, as a place for collaboration on anything that might further the general mission. It is a sensible idea to keep SugarLabs away from doing too much work on the OS building and deployment implementing side of things, because as you point out, even when you exclude those broad topics there is still a lack of resources on the bits that remain. That said, in a way, the gap that we're discussing is in some ways more important than any of the Sugar features currently being worked on, because the large majority of sugar users are currently a long way away from even having access to the features that were finished 6 months ago. Difficult. I disagree about local labs being key to filling the gap. While a nice idea, I think it is necessary for there to be a central and location-independent deployment-focused upstream, otherwise there will be a lack of coordination accompanied by lots of duplication of work. Local labs need to feed into something bigger, which doesn't currently exist, although it could probably sit under the realm of sugarlabs if the right people were to step up. Also, when talking of scale, I am a little wary of local community efforts because they have previously proven disruptive to deployments. The sad reality is that you absolutely require more of a NGO or business setup to be working with the relevant authorities. And when this happens, the community efforts automatically become a bit distanced. For example in many of these places, the official organisation receives permission from the government for their staff to enter government schools - but only their staff (not community volunteers). You mention lack of involvement and feedback from deployments -- why do you think this is? Here are some of my thoughts: - The majority people we're working with are alien to the idea that they might be able to talk to the people who are writing the software that they are using. Since when has anyone been able to do that? Us open source people are still the oddities in the world. - People are afraid or mythed by the idea of this stuff being public and global (why would I want my feedback to be public?), and are confused/challenged by mailing lists. - The people most able to give the kind of feedback you are looking for are the teachers, who are probably even more distanced from these ideas. Many will lack connectivity and english language skills. - Many people who support the project with technical skills (e.g. Linux) come from purely academic backgrounds which means they understand the technical stuff well, but have little interest, experience (and sometimes ability) to become good community members. To put it plainly: in my opinion, wishing for substantially more involvement from deployments is not realistic. SugarLabs would benefit from being proactive here, especially by using the telephone rather than email to contact deployments, but this is of course subject to the where are the resources? question. Hopefully over time a proactive approach from our side would likewise encourage a proactive approach to communication from the deployments, but I suspect we'll have to be patient. and yes, this makes your job pretty difficult. On Sun, Aug 9, 2009 at 19:41, Daniel Draked...@laptop.org wrote: At least from what I have seen, this kind of clarity seems to be missing from discussions that define the Sugar platform nowadays, as well as in the code that is flowing through the system. Does SugarLabs still have a high degree of interest in bigger-than-you-can-believe deployments in remote and really difficult parts of the world on low-spec hardware, or are we moving towards looking at occasional 30-student deployments on powerful computers in schools along the Charles? Or are we trying to do both? Are we still focusing on 6-12 year olds or has that changed? How do you expect that the SLs volunteers know what OLPC deployments need if they don't voice their needs? If you look at the Sugar commit logs, you will see that almost all commits are from someone sitting in a room somewhere in Europe, working on their free time. By which kind of epiphany do you expect them to know what's best for OLPC deployments? I think you misunderstood my position here. I am personally having trouble trying to formulate this kind of feedback because I no longer know what is important to Sugar. Maybe it is a personal misunderstanding, but after seeing some recent discussions and features I feel that some of the core goals that formed the project in its earlier stages have been lost. I am glad to see your response which suggests that these things are still
