Re: [IAEP] [Sugar-devel] Planning for the future (Samuel, Greenfeld)
Hi, Sean I think we are on the same page. The model of deployments (outside of those nationally sponsored) has been a sponsor in the developed world has supplied laptops to a school in the developing world. Sugar must grow in the developed world market to continue the flow of sponsors which are needed if those on the other side can maintain some semblence of progress. The G1G1 concept was far more clever than the creators suspected. The Get1 folks learned what the laptops could do and that they were needed on the other side of the digital divide. Mike Dawson is right, the current model is the feature phone with those with more assets wishing for a smartphone. What is important is that experience with using electronic devices with computing capability is diffusing rapidly. However, I am not so hopeful of rapid spread of broadband internet at an affordable price. I was an accidental attendant at a meeting of staff from a local high school who are contemplating getting computers (Apple). They said the Department of Education will supply 48000 pesos per year to offset internet charges ($1000). In South Africa and many other areas, the usage plans charge for the amount of data transfered. This would very hard on schools which allow some 50 concurrent users to surf freely. The norm in the secondary schools is a computer lab. Some schools reuse old desktops (with CRT monitors) as 'thin clients'. The idea is to share one computer with multiple monitor-keyboard-mouse workstations (the thin clients). The problem with the Raspberry Pi is that it does not have a monitor (keyboard and mouse are easy - a touch-screen monitor may eliminate the need for a mouse). However, monitors remain very expensive, often cheaper when wrapped in an Android device. My sense is that we could attach the RPi to a school server and the students could work with it through the school server using their own XO screens as the RPi monitor. This would be very useful to support a science lab with a school kit of sensors, robots and so on. So where we are in clear agreement, success and acceptance of the Sugar initiative in the developed world is essential to keep the pool of sponsors we need for the other side of the divide. At the same time, I think we need to develop a proof of concept that shows that students can show significant improvements in learning by using Sugar - the point you are making with the Journalist. I asked the principal of the school at the meeting what was the educational objective of the program. The answer was each school was to figure that out on their own. Apple seems to have adopted the Negroponte model, buy them and students will learn (worked in Field of Dreams). Tony On 03/19/2015 04:43 PM, Sean DALY wrote: Hi Tony, I for one certainly don't feel Sugar is only for children in developed countries. I believe Sugar offers benefits for all children. I do think that widespread use of Sugar in developed countries would encourage its use in the developing world, for several reasons. One of these is the opportunity for major donors, journalists, and influential educators - who could make a difference in developing world projects - to experience Sugar directly, something they have never been able to do without difficulty. I remember a testy exchange with a journalist who described the XO (which he had never seen) in his article as a laptop running Linux. I told him that was reductionist, like calling an iPhone a FreeBSD terminal, and explained that Sugar is an environment specifically designed for children. His position was that the XO was challenging the market position of Windows - childrens' learning or the digital divide weren't the angles. In the past few years we've seen enormous changes, in particular the rise of handheld tactile devices (smartphones/tablets/phablets), which seem to offer advantages for schools (rugged, light, many fewer moving parts, software keyboard easy to localize) but which are better suited to consuming content rather than creating it. And in the developing world, the incredible rise of mobile, a large percentage of which are Internet-connected smartphones (see the Pew report of a year ago: http://www.pewglobal.org/2014/02/13/emerging-nations-embrace-internet-mobile-technology). I have been astonished at learnings from the Nosy Komba (Madagascar) micro-deployment managed by the OLPC France association (not affiliated with OLPC). There was no Internet on the island, but highspeed xDSL was available in the port on the mainland a few kilometers over open water. OLPC France volunteers designed and installed a wifi link (this involved climbing the island's volcano to set up an antenna) after initial resistance from the local telco provider. When the island's villages learned that the school had not only computers for the children, but limited Internet access, the school's attendance jumped (a dormitory had
Re: [IAEP] [Sugar-devel] Planning for the future (Samuel, Greenfeld)
Hi Tony, I for one certainly don't feel Sugar is only for children in developed countries. I believe Sugar offers benefits for all children. I do think that widespread use of Sugar in developed countries would encourage its use in the developing world, for several reasons. One of these is the opportunity for major donors, journalists, and influential educators - who could make a difference in developing world projects - to experience Sugar directly, something they have never been able to do without difficulty. I remember a testy exchange with a journalist who described the XO (which he had never seen) in his article as a laptop running Linux. I told him that was reductionist, like calling an iPhone a FreeBSD terminal, and explained that Sugar is an environment specifically designed for children. His position was that the XO was challenging the market position of Windows - childrens' learning or the digital divide weren't the angles. In the past few years we've seen enormous changes, in particular the rise of handheld tactile devices (smartphones/tablets/phablets), which seem to offer advantages for schools (rugged, light, many fewer moving parts, software keyboard easy to localize) but which are better suited to consuming content rather than creating it. And in the developing world, the incredible rise of mobile, a large percentage of which are Internet-connected smartphones (see the Pew report of a year ago: http://www.pewglobal.org/2014/02/13/emerging-nations-embrace-internet-mobile-technology). I have been astonished at learnings from the Nosy Komba (Madagascar) micro-deployment managed by the OLPC France association (not affiliated with OLPC). There was no Internet on the island, but highspeed xDSL was available in the port on the mainland a few kilometers over open water. OLPC France volunteers designed and installed a wifi link (this involved climbing the island's volcano to set up an antenna) after initial resistance from the local telco provider. When the island's villages learned that the school had not only computers for the children, but limited Internet access, the school's attendance jumped (a dormitory had to be built as a result). And the island's fishermen wanted to learn how to obtain weather and tides information. My point is that even in remote areas, people know that the Internet exists and that children need computers and connectivity to develop opportunities - there will be fewer and fewer schools which are completely off-grid. I agree that the children in those schools need help the most, that with no connectivity a local device (or device+server) is all-important, and that the XO is best-suited as that device. However Sugar offers the possibility of using a different device if XOs become unavailable. It's not farfetched to imagine a hardware/Sugar education project based on a RPi or other Single Board Computer (SBC), perhaps with an internal battery, used for example with shared keyboards and screens at school connected to a school server, maybe with satellite tablet screen for outside school... To me, the goal of Sugar Labs is to offer its benefits to all children, not just those lucky enough to have access to an XO. This can certainly include children in developing countries - witness Sugar's support for indigenous languages, always a step ahead of commercial offerings, yet of only limited interest in developed countries. Sean. On Thu, Mar 19, 2015 at 1:40 AM, Tony Anderson tony_ander...@usa.net wrote: Sean, I think you are getting at what I consider the heart of the problem. SugarLabs sees Sugar as an alternative GUI for any computing device with primary efficacy in the developed, internet-connected world. This goal is understandable since the XOs have a limited life and so Sugar must be operable on currently marketed devices. The project I signed up for is to place computers in the hands of every child at a community school in the developing world where electricity is an issue, the internet is unavailable, and teachers as well as students have no prior experience with computing. The goal of the project is to enhance the educational opportunities of these students through the use of Sugar as well as access to information others on the right side of the digital divide get from the internet. Tony ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Planning for the future (Samuel Greenfeld)
I just found this interesting powerpoint from a few years ago. Slide 25 is basically a summary of this discussion: https://docs.google.com/viewer?a=vpid=sitessrcid=ZGVmYXVsdGRvbWFpbnxtYXJrZXRsYWJzdWdhcnxneDo0Y2U3ODFjZDczMmU1Mjlh Thanks, Sam On Sun, Mar 15, 2015 at 7:16 AM Gonzalo Odiard godi...@sugarlabs.org wrote: Thanks Sameer, very good points, a few comments/questions below On Fri, Mar 13, 2015 at 5:53 PM, Sameer Verma sve...@sfsu.edu wrote: Interesting thread. I'll reply to Lionel's post, but my reply is more of my own set of ideas and understanding. Putting on my business school researcher hat: 1) The eventual goal of this project should be to influence the adoption of Sugar across the world. A person's attitude, combined with subjective norms, forms his behavioral intention (https://en.wikipedia.org/wiki/Theory_of_reasoned_action). To influence adoption, we have to address the attitudes of the potential adopter, and the subjective norms. Should Sugar be a part of that ecosystem (such as a school's curriculum) or apart from it? Do we have a option? I don't say the school is the only channel to reach kids, but is the more massive channel without doubt. 2) Role of marketing: Most of what I've seen thus far is focused on the internal producer view of OLPC/Sugarlabs. This is natural, given that that's the world view we are most familiar with. The role of marketing is to take this internal view, and adapt its value to make it attractive to the consumer. If this adaptation fails, we end up with over-engineered products that the market rejects. This adaptation is largely dependent on addressing the perceptions of the consumer. This is one of the reasons why shiny products sell - we associate shiny with expensive, be it chrome polished plastic or iPads. At this point if you are saying to yourself we don't care for marketing or consumer you are sorely mistaken. We need more marketing without doubt. 3) Vision and Mission are important for the project: Vision is an inspirational, directional, future state description. Mission is largely how we get there. Both should be referenced on the basis of a time frame. So, vision and mission for now + 5 years is a good target. These might appear cheesy, but FOSS projects are usually non-strategic by design, because we are all busy writing small bits and pieces, hoping someone will stitch it all together eventually. We scratch our own itch in a piecemeal fashion, by writing scripts for battery stats, frame icons, Journal data and such. FOSS projects strive for operational excellence. Then, we hope that all this gets weaved into a fabric that can be used by someone (kids). The same applies to Apache, Ubuntu, Drupal, Linux, etc. In all those cases, there is a foundation or association or company that puts resources (time and money) and provides strategic direction, because the project isn't designed to do so by itself. Apache Software Foundation, Canonical, Drupal Association, Linux Foundation play that important role (I am on the Board of Directors of the Drupal Association, and some of this thinking is from my observations there). Vision, Mission, Goals, Objectives etc. should come from somewhere for Sugar/olpc. For a while it came from OLPC, but right now, I don't see any of it in an organizational manner. 4) In the free and open source world, the consumer is also sometimes the producer. So, instead of treating the consumer as someone with limited feedback (as may be the case with Windows or MacOSX) the consumer can switch roles and become a producer (like Ignacio or SamP). http://www.oecd.org/sti/inno/37450155.pdf This can lead to a myopic view of the target population being only people like Ignacio or SamP. Should all kids open the hood to peek into Sugar and become developers like Ignacio and SamP? Can we get into schools where they have locked down Windows machines with no admin rights? 5) Sugar is not a product. Sugar is a project, that keeps evolving as time goes by. A product is when we take a snapshot and polish it with QC, QA and package it for delivery. OLPC's build for the XO platform is a product. Sugarizer is a product. Suagr is NOT a product. This is just like Fedora is NOT a product. It's a project. RHEL is a product. Or for that matter, take the Ubuntu phone. The phone delivered by BQ is a product that took Ubuntu 14.09 and made it RTM (release to manufacturer) and ran it through QC and QA and produced the phone with the polished stack on it. Customers buy products, while developers work with projects. It is imperative that we understand the difference and treat the two as different. I'm pretty sure Rangan Srikhanta has a strategy for OLPCAU/OneEducation. So does Rodrigo Arboleda for OLPC Inc. I think we (Sugarlabs+lowercase olpc) need a strategy going forward to address Vision, Mission, etc. We also need to operationally pick approaches (such as Sugar Web) to
Re: [IAEP] [Sugar-devel] Planning for the future (Samuel Greenfeld)
Talking about good marketing, daniel g. siegel shared this today: http://www.dgsiegel.net/news/2015_03_18-lego's_1981_ad_campaign I think we should look at this creation moments in kids using Sugar, and not limit that to programming only. There are a lot of creative, wonderful, and happy people who is not interested in programming. Gonzalo On Wed, Mar 18, 2015 at 8:47 AM, Gonzalo Odiard godi...@sugarlabs.org wrote: Thanks Sam. I never read that. Have good points. Gonzalo On Wed, Mar 18, 2015 at 8:21 AM, Sam P. sam.parkins...@gmail.com wrote: I just found this interesting powerpoint from a few years ago. Slide 25 is basically a summary of this discussion: https://docs.google.com/viewer?a=vpid=sitessrcid=ZGVmYXVsdGRvbWFpbnxtYXJrZXRsYWJzdWdhcnxneDo0Y2U3ODFjZDczMmU1Mjlh Thanks, Sam On Sun, Mar 15, 2015 at 7:16 AM Gonzalo Odiard godi...@sugarlabs.org wrote: Thanks Sameer, very good points, a few comments/questions below On Fri, Mar 13, 2015 at 5:53 PM, Sameer Verma sve...@sfsu.edu wrote: Interesting thread. I'll reply to Lionel's post, but my reply is more of my own set of ideas and understanding. Putting on my business school researcher hat: 1) The eventual goal of this project should be to influence the adoption of Sugar across the world. A person's attitude, combined with subjective norms, forms his behavioral intention (https://en.wikipedia.org/wiki/Theory_of_reasoned_action). To influence adoption, we have to address the attitudes of the potential adopter, and the subjective norms. Should Sugar be a part of that ecosystem (such as a school's curriculum) or apart from it? Do we have a option? I don't say the school is the only channel to reach kids, but is the more massive channel without doubt. 2) Role of marketing: Most of what I've seen thus far is focused on the internal producer view of OLPC/Sugarlabs. This is natural, given that that's the world view we are most familiar with. The role of marketing is to take this internal view, and adapt its value to make it attractive to the consumer. If this adaptation fails, we end up with over-engineered products that the market rejects. This adaptation is largely dependent on addressing the perceptions of the consumer. This is one of the reasons why shiny products sell - we associate shiny with expensive, be it chrome polished plastic or iPads. At this point if you are saying to yourself we don't care for marketing or consumer you are sorely mistaken. We need more marketing without doubt. 3) Vision and Mission are important for the project: Vision is an inspirational, directional, future state description. Mission is largely how we get there. Both should be referenced on the basis of a time frame. So, vision and mission for now + 5 years is a good target. These might appear cheesy, but FOSS projects are usually non-strategic by design, because we are all busy writing small bits and pieces, hoping someone will stitch it all together eventually. We scratch our own itch in a piecemeal fashion, by writing scripts for battery stats, frame icons, Journal data and such. FOSS projects strive for operational excellence. Then, we hope that all this gets weaved into a fabric that can be used by someone (kids). The same applies to Apache, Ubuntu, Drupal, Linux, etc. In all those cases, there is a foundation or association or company that puts resources (time and money) and provides strategic direction, because the project isn't designed to do so by itself. Apache Software Foundation, Canonical, Drupal Association, Linux Foundation play that important role (I am on the Board of Directors of the Drupal Association, and some of this thinking is from my observations there). Vision, Mission, Goals, Objectives etc. should come from somewhere for Sugar/olpc. For a while it came from OLPC, but right now, I don't see any of it in an organizational manner. 4) In the free and open source world, the consumer is also sometimes the producer. So, instead of treating the consumer as someone with limited feedback (as may be the case with Windows or MacOSX) the consumer can switch roles and become a producer (like Ignacio or SamP). http://www.oecd.org/sti/inno/37450155.pdf This can lead to a myopic view of the target population being only people like Ignacio or SamP. Should all kids open the hood to peek into Sugar and become developers like Ignacio and SamP? Can we get into schools where they have locked down Windows machines with no admin rights? 5) Sugar is not a product. Sugar is a project, that keeps evolving as time goes by. A product is when we take a snapshot and polish it with QC, QA and package it for delivery. OLPC's build for the XO platform is a product. Sugarizer is a product. Suagr is NOT a product. This is just like Fedora is NOT a product. It's a project. RHEL is a product. Or for that matter, take the Ubuntu phone. The phone delivered by BQ is a product that took Ubuntu
Re: [IAEP] [Sugar-devel] Planning for the future (Samuel Greenfeld)
cc'ing the Marketing list - the one everyone forgets as soon as they discuss marketing. The MarketLab study we worked on back then confirmed what we already knew - that Sugar's websites did not accompany teachers interested in Sugar, and that Sugar absolutely needed a simple installer. They also advised that we should use visuals of children heavily in our marketing. I myself could no longer donate thousands of USD to keep marketing going and organize photo shoots, so we asked the community several times for images. We were unable to obtain any usable, released images. Even before the study, we had tried to federate the multiple Sugar websites under a common menu bar until a more unified website could be created, but no one was interested in working on that - at the time I remember someone even said that teachers could prove their motivation by finding scattered information themselves (!) The biggest problem then, simplifying access to Sugar so interested educators and journalists could overcome the installation and unfamiliarity barriers, remains pertinent today. If the community really got behind Sugar on a Stick or a VM matrix or a Raspberry Pi build - testing, documentation, polish - this product could happen. Sugar is both a very different interface to classic desktop analogy GUIs familiar to adults, and (except for XOs and some Classmates) absent from any machines which could run it. To be properly evaluated by any interested educator or journalist, it must be obtained, installed and configured, then understood, and finally compared with competing solutions. These are enormous hurdles to access Sugar, and lowering or eliminating these barriers should be top priority. Are they? I believe Sugar in a browser, keeping its core values in particular View Source, is the best way to eliminate the installation and unfamiliarity barriers. It may also be in the long term the best way to run Sugar. Free/libre open source software projects are generally awful at marketing, perhaps because most engineers don't understand it. Great effort is put into technical professionalism, while most marketing efforts are breathtakingly amateurish. As someone who has worked as a developer, journalist, IT director, and the past dozen years in marketing, I like to think I understand both sides. Marketing is often assumed by developers to be recruitment - certainly important, but our real target is educators. Grassroots marketing is great - we all do it - however, it isn't sufficient to bring Sugar to tens of millions of children, through millions of teachers. We do have the competence to do world-class marketing. What we don't have is an easy-to-try, stable product, and the necessary resources (human, financial). A great product or service is at the heart of effective marketing - even companies with enormous marketing budgets (on average 11% of overall budget, source The CMO Survey by Duke University Fuqua School of Business) have difficulty moving a product unsuited to the market. Sugar has great branding, just no brand awareness. We tried to improve this in XO countries by placing a Sugar logo in the OLPC splash screen, and asking OLPC to mention Sugar in their PR (the anti-Sugar people pushed back against this). The slickness of our graphics chart has even worked against us - the Marketlab people found that we were perceived as a for-profit startup, which is why we play up the nonprofit in our PR since the study. OLPC (outside the countries with large XO deployments) has no brand awareness either. We don't have the funds to do market studies, but I would wager that unaided awareness of the OLPC logo in educators doesn't top 5%. OLPC's real brand is the XO itself, which is why even today you see Pantone-361 green and white objects everywhere (for example: https://www.kickstarter.com/projects/522717158/cognitoys-internet-connected-smart-toys-that-learn ). So yes, we need more marketing, just like we need more developing, more packaging, more testing, more documentation, more feedback from educators children, and more outreach. Lack of resources has been a critical factor in slowing Sugar, but I believe that in order to convince charitable givers, we need a plan that the community supports, and to demonstrate that we have the necessary skills to pursue the roadmap with a chance of success. Sean. On Wed, Mar 18, 2015 at 12:47 PM, Gonzalo Odiard godi...@sugarlabs.org wrote: Thanks Sam. I never read that. Have good points. Gonzalo On Wed, Mar 18, 2015 at 8:21 AM, Sam P. sam.parkins...@gmail.com wrote: I just found this interesting powerpoint from a few years ago. Slide 25 is basically a summary of this discussion: https://docs.google.com/viewer?a=vpid=sitessrcid=ZGVmYXVsdGRvbWFpbnxtYXJrZXRsYWJzdWdhcnxneDo0Y2U3ODFjZDczMmU1Mjlh Thanks, Sam On Sun, Mar 15, 2015 at 7:16 AM Gonzalo Odiard godi...@sugarlabs.org wrote: Thanks Sameer, very good points, a few comments/questions below On Fri, Mar 13, 2015
Re: [IAEP] [Sugar-devel] Planning for the future (Samuel, Greenfeld)
Tony, I don't agree with your characterization of Sugar. We've never built in any assumptions about connectivity into the GUI, core system, or core activities (even the web activities all run off disk. The decision to migrate to GTK3 was made for technical reasons -- which you may disagree with -- but not because we were trying to cater to a developed world. That said, there has been a degradation of performance on the XO-1 hardware and we can and should try to make improvements there. But I don't think it is realistic to languish in long-abandoned, unsupported libraries: we as a community cannot possibly support old versions of GTK, Gstreamer, and the countless of components of Sugar 0.94. I believe it would be much less work and much more fruitful even in the short term to invest in optimizing new code to old hardware. regards. -walter On Wed, Mar 18, 2015 at 8:40 PM, Tony Anderson tony_ander...@usa.net wrote: Sean, I think you are getting at what I consider the heart of the problem. SugarLabs sees Sugar as an alternative GUI for any computing device with primary efficacy in the developed, internet-connected world. This goal is understandable since the XOs have a limited life and so Sugar must be operable on currently marketed devices. The project I signed up for is to place computers in the hands of every child at a community school in the developing world where electricity is an issue, the internet is unavailable, and teachers as well as students have no prior experience with computing. The goal of the project is to enhance the educational opportunities of these students through the use of Sugar as well as access to information others on the right side of the digital divide get from the internet. Tony ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Planning for the future (Samuel, Greenfeld)
Sean, I think you are getting at what I consider the heart of the problem. SugarLabs sees Sugar as an alternative GUI for any computing device with primary efficacy in the developed, internet-connected world. This goal is understandable since the XOs have a limited life and so Sugar must be operable on currently marketed devices. The project I signed up for is to place computers in the hands of every child at a community school in the developing world where electricity is an issue, the internet is unavailable, and teachers as well as students have no prior experience with computing. The goal of the project is to enhance the educational opportunities of these students through the use of Sugar as well as access to information others on the right side of the digital divide get from the internet. Tony ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Planning for the future (Samuel, Greenfeld)
Hi, Walter This could lead to a most unproductive discussion. My main point is that there should be focus on what new educational opportunities we are offering to our users. I am saddened to see such wonderful new activities developed using the web technology which are totally unavailable to the majority of our user base. As I said in response to Adam's poll: I think we may need to think in terms of two efforts: development leading to support of new software and hardware technologies and maintenance - preserving the viability of the deployed hardware of which the overwhelming majority are XO-1s. Tony On 03/19/2015 09:06 AM, Walter Bender wrote: Tony, I don't agree with your characterization of Sugar. We've never built in any assumptions about connectivity into the GUI, core system, or core activities (even the web activities all run off disk. The decision to migrate to GTK3 was made for technical reasons -- which you may disagree with -- but not because we were trying to cater to a developed world. That said, there has been a degradation of performance on the XO-1 hardware and we can and should try to make improvements there. But I don't think it is realistic to languish in long-abandoned, unsupported libraries: we as a community cannot possibly support old versions of GTK, Gstreamer, and the countless of components of Sugar 0.94. I believe it would be much less work and much more fruitful even in the short term to invest in optimizing new code to old hardware. regards. -walter ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Planning for the future (Samuel Greenfeld)
On Fri, Feb 27, 2015 at 12:09 PM, Gonzalo Odiard godi...@sugarlabs.org wrote: Thanks Sora for sharing. We are working in a questionnaire to get more information from the local deployments. If you agree, we can send it to you to get more information from Haiti deployments. Somehow missed this message yesterday...yes, I'd be happy to get info from our Haiti deployments. On Sat, Feb 28, 2015 at 2:24 AM, James Cameron qu...@laptop.org wrote: On Fri, Feb 27, 2015 at 08:13:04PM -0700, Caryl Bigenho wrote: One other thing I should mention about some Sugar Activities... some of them really lack color. [...] This was possibly the design decision to support the colourless display of the XO laptop when used outdoors, as well as colour impaired children. I don't think it needs to be kept for Sugar, and would welcome a change where colour was more heavily used. (Developers: as a reproducible colouring of the background of the icons, for example, along with nicknames always shown on the neighbourhood view.) -- James Cameron http://quozl.linux.org.au/ ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Planning for the future (Samuel Greenfeld)
On Fri, Feb 27, 2015 at 10:13 PM, Caryl Bigenho cbige...@hotmail.com wrote: Someone remarked that teachers don't like to use Sugar. If not,... why not? Ask them! I hate to say that the user's not always right, but in Haiti at least, some of the teachers are disappointed when they see Sugar because they were expecting Windows. They've never used Windows, and they don't know what it can and can't do, but they do know that's the software you have to master in order to get a job. We ask our Haitian staff to speak during training about the advantages they've seen using Sugar with kids. I constantly repeat my mantra We're not learning to use computers; we're using computers to learn. But it doesn't always work. Obviously, the teachers in Uruguay like it and use it. But not all of it. So, do a survey of teachers who do use it and find the 10 or 20 top Activities and then concentrate on getting them ported to a more universal platform (e.g. Android). When I was there a few years back I did ask them... and the students. The hands-down winner was Labyrinth! Yep, Labyrinth is fantastic (the mind-mapping one, although the maze isn't bad either). Folks also like Fototoon, and the music software never gets enough credit. But I'm just reporting what I've seen and what we wrote up in our curriculum guide. I'd be up for sending out an actual survey. How important is collaboration? Ask the teachers! Can collaboration be implemented on an Android platform? If not, is there an easy work around? I hope so. I know in Haiti the teachers don't use it very often, but that's partly because it requires a new method of thinking about implementing lessons and that can be tricky. It's something I always emphasize in follow-up training sessions; once the teachers and students have gotten a basic grasp of the technology they start exploring other possibilities like this. One other thing I should mention about some Sugar Activities... some of them really lack color. When you look at the typical educational software for children, it is always bright and colorful with very simple artwork... maybe too much so. It also often has cute little tunes playing in the background. Teachers, parents, and children have grown to expect this in educational software. Perhaps considering brightening up the screens a bit on some of the Activities would be something to experiment with. I've been reading a lot about e-books and digital education for school for the past few weeks. One thing that keeps coming up is the line between engaging and distracting. As you say, bright and colorful with music is what people have come to expect, but unless it's very tightly integrated with what kids are doing it doesn't really enhance the experience. Another case where the user may not be right...but what can you do? Date: Sat, 28 Feb 2015 10:40:01 +1100 From: qu...@laptop.org To: m...@jvonau.ca CC: iaep@lists.sugarlabs.org; sugar-de...@lists.sugarlabs.org; lio...@olpc-france.org; sam...@greenfeld.org Subject: Re: [IAEP] [Sugar-devel] Planning for the future (Samuel Greenfeld) On Thu, Feb 26, 2015 at 03:31:50PM +1100, James Cameron wrote: On Wed, Feb 25, 2015 at 04:20:02PM -0600, Jerry Vonau wrote: On February 25, 2015 at 3:09 PM James Cameron qu...@laptop.org wrote: On Wed, Feb 25, 2015 at 01:20:19PM -0600, Jerry Vonau 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 which would use sse. This causes problems for some parts of sugar now that java is being used more and the XO-1 lacks sse. Fixing one package that uses sse might fix one issue but this is really a distro wide setting and other issues may float to the top in other areas. Thanks, wasn't aware -mtune=atom was being used upstream. It explains a lot. First build after Fedora 11 was 11.2.0 (os874) using Fedora 14. So if we rebuild everything there may be an improvement? That's probably something that can be set running as a test. Wouldn't all the rpms used need to be recompiled to ensure mtune is set to match throughout the distro? Don't think so. Check my logic: The GCC documentation you referenced described -mtune as Tune to cpu-type everything applicable about the generated code, except for the ABI and the set of available instructions. -march is more significant, as Generate instructions for the machine type cpu-type. The choices for cpu-type are the same as for -mtune. Moreover, specifying -march=cpu-type implies -mtune=cpu-type. If the ABI were different between i586 and i686 arch, that would be very interesting. Tall order IMHO, good luck ;-) For the moment, I'm doing a mock --rebuild of webkitgtk3 with --arch=i586, and the logs so far show -march=i586 -mtune=generic
Re: [IAEP] [Sugar-devel] Planning for the future (Samuel Greenfeld)
On Fri, Feb 27, 2015 at 08:13:04PM -0700, Caryl Bigenho wrote: One other thing I should mention about some Sugar Activities… some of them really lack color. [...] This was possibly the design decision to support the colourless display of the XO laptop when used outdoors, as well as colour impaired children. I don't think it needs to be kept for Sugar, and would welcome a change where colour was more heavily used. (Developers: as a reproducible colouring of the background of the icons, for example, along with nicknames always shown on the neighbourhood view.) -- James Cameron http://quozl.linux.org.au/ ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Planning for the future (Samuel Greenfeld)
Hi Folks… Sorry I didn't put my 2 cents worth in sooner, but here are some questions/suggestions I have re: planning for the future…. Someone remarked that teachers don't like to use Sugar. If not,… why not? Ask them! Obviously, the teachers in Uruguay like it and use it. But not all of it. So, do a survey of teachers who do use it and find the 10 or 20 top Activities and then concentrate on getting them ported to a more universal platform (e.g. Android). When I was there a few years back I did ask them… and the students. The hands-down winner was Labyrinth! How important is collaboration? Ask the teachers! Can collaboration be implemented on an Android platform? If not, is there an easy work around? Could someone write an ebook similar to James Simmons' Make Your Own Sugar Activities but with instructions for adapting or creating Sugar Activities for Android or whatever other platform is chosen? Is it possible to get the Activities to integrate like they do on the XO? i.e. be able to transfer a project from one Activity to another for further use. Currently, I'm happily involved in an online course, Harvard's CS50, where I am learning C and will also be exposed to JavaScript, HTML (been there before) and CSS. My goal is to make my final project the adaptation of some Sugar Activity to IOS and maybe Android (although Lionel's group is beating me to it and doing a good job). One other thing I should mention about some Sugar Activities… some of them really lack color. When you look at the typical educational software for children, it is always bright and colorful with very simple artwork… maybe too much so. It also often has cute little tunes playing in the background. Teachers, parents, and children have grown to expect this in educational software. Perhaps considering brightening up the screens a bit on some of the Activities would be something to experiment with. OK. 'Nuff said. Caryl Date: Sat, 28 Feb 2015 10:40:01 +1100 From: qu...@laptop.org To: m...@jvonau.ca CC: iaep@lists.sugarlabs.org; sugar-de...@lists.sugarlabs.org; lio...@olpc-france.org; sam...@greenfeld.org Subject: Re: [IAEP] [Sugar-devel] Planning for the future (Samuel Greenfeld) On Thu, Feb 26, 2015 at 03:31:50PM +1100, James Cameron wrote: On Wed, Feb 25, 2015 at 04:20:02PM -0600, Jerry Vonau wrote: On February 25, 2015 at 3:09 PM James Cameron qu...@laptop.org wrote: On Wed, Feb 25, 2015 at 01:20:19PM -0600, Jerry Vonau 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 which would use sse. This causes problems for some parts of sugar now that java is being used more and the XO-1 lacks sse. Fixing one package that uses sse might fix one issue but this is really a distro wide setting and other issues may float to the top in other areas. Thanks, wasn't aware -mtune=atom was being used upstream. It explains a lot. First build after Fedora 11 was 11.2.0 (os874) using Fedora 14. So if we rebuild everything there may be an improvement? That's probably something that can be set running as a test. Wouldn't all the rpms used need to be recompiled to ensure mtune is set to match throughout the distro? Don't think so. Check my logic: The GCC documentation you referenced described -mtune as Tune to cpu-type everything applicable about the generated code, except for the ABI and the set of available instructions. -march is more significant, as Generate instructions for the machine type cpu-type. The choices for cpu-type are the same as for -mtune. Moreover, specifying -march=cpu-type implies -mtune=cpu-type. If the ABI were different between i586 and i686 arch, that would be very interesting. Tall order IMHO, good luck ;-) For the moment, I'm doing a mock --rebuild of webkitgtk3 with --arch=i586, and the logs so far show -march=i586 -mtune=generic instead of -march=i686 -mtune=atom: This didn't change the problem, gdb core still showed SSE instructions used. Daniel Drake's change to WebKit that fixed this before has since been lost in the current WebKit sources in git. Patch is in the history, but some later patch removed the change. $ grep mtune build.log | grep i586 | wc --lines 8564 $ grep mtune build.log | grep atom | wc --lines 0 $ Jerry -- James Cameron http://quozl.linux.org.au/ -- James Cameron http://quozl.linux.org.au/ ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org
Re: [IAEP] [Sugar-devel] Planning for the future (Samuel Greenfeld)
Sora... Thanks for your thoughtful from the field answers! We need more of them. I think I'll ask my friend Rosamel in Uruguay what she thinks and if she might ask some of her collegues too. Mañana. I have to do it in Spanish so I'll wait until morning when I am thinking clearly. Caryl Date: Fri, 27 Feb 2015 22:40:17 -0500 Subject: Re: [IAEP] [Sugar-devel] Planning for the future (Samuel Greenfeld) From: s...@unleashkids.org To: cbige...@hotmail.com CC: qu...@laptop.org; m...@jvonau.ca; h...@laptop.org; iaep@lists.sugarlabs.org; sugar-de...@lists.sugarlabs.org; lio...@olpc-france.org; sam...@greenfeld.org On Fri, Feb 27, 2015 at 10:13 PM, Caryl Bigenho cbige...@hotmail.com wrote: Someone remarked that teachers don't like to use Sugar. If not,… why not? Ask them!I hate to say that the user's not always right, but in Haiti at least, some of the teachers are disappointed when they see Sugar because they were expecting Windows. They've never used Windows, and they don't know what it can and can't do, but they do know that's the software you have to master in order to get a job. We ask our Haitian staff to speak during training about the advantages they've seen using Sugar with kids. I constantly repeat my mantra We're not learning to use computers; we're using computers to learn. But it doesn't always work. Obviously, the teachers in Uruguay like it and use it. But not all of it. So, do a survey of teachers who do use it and find the 10 or 20 top Activities and then concentrate on getting them ported to a more universal platform (e.g. Android). When I was there a few years back I did ask them… and the students. The hands-down winner was Labyrinth!Yep, Labyrinth is fantastic (the mind-mapping one, although the maze isn't bad either). Folks also like Fototoon, and the music software never gets enough credit. But I'm just reporting what I've seen and what we wrote up in our curriculum guide. I'd be up for sending out an actual survey. How important is collaboration? Ask the teachers! Can collaboration be implemented on an Android platform? If not, is there an easy work around?I hope so. I know in Haiti the teachers don't use it very often, but that's partly because it requires a new method of thinking about implementing lessons and that can be tricky. It's something I always emphasize in follow-up training sessions; once the teachers and students have gotten a basic grasp of the technology they start exploring other possibilities like this. One other thing I should mention about some Sugar Activities… some of them really lack color. When you look at the typical educational software for children, it is always bright and colorful with very simple artwork… maybe too much so. It also often has cute little tunes playing in the background. Teachers, parents, and children have grown to expect this in educational software. Perhaps considering brightening up the screens a bit on some of the Activities would be something to experiment with. I've been reading a lot about e-books and digital education for school for the past few weeks. One thing that keeps coming up is the line between engaging and distracting. As you say, bright and colorful with music is what people have come to expect, but unless it's very tightly integrated with what kids are doing it doesn't really enhance the experience. Another case where the user may not be right...but what can you do? Date: Sat, 28 Feb 2015 10:40:01 +1100 From: qu...@laptop.org To: m...@jvonau.ca CC: iaep@lists.sugarlabs.org; sugar-de...@lists.sugarlabs.org; lio...@olpc-france.org; sam...@greenfeld.org Subject: Re: [IAEP] [Sugar-devel] Planning for the future (Samuel Greenfeld) On Thu, Feb 26, 2015 at 03:31:50PM +1100, James Cameron wrote: On Wed, Feb 25, 2015 at 04:20:02PM -0600, Jerry Vonau wrote: On February 25, 2015 at 3:09 PM James Cameron qu...@laptop.org wrote: On Wed, Feb 25, 2015 at 01:20:19PM -0600, Jerry Vonau 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 which would use sse. This causes problems for some parts of sugar now that java is being used more and the XO-1 lacks sse. Fixing one package that uses sse might fix one issue but this is really a distro wide setting and other issues may float to the top in other areas. Thanks, wasn't aware -mtune=atom was being used upstream. It explains a lot. First build after Fedora 11 was 11.2.0 (os874) using Fedora 14. So if we rebuild everything there may be an improvement? That's probably something that can be set running as a test. Wouldn't all the rpms used need to be recompiled to ensure mtune is set to match throughout the distro? Don't think so. Check my logic: The GCC documentation you referenced described -mtune as Tune to cpu-type everything
Re: [IAEP] [Sugar-devel] Planning for the future (Samuel Greenfeld)
Thanks Sora for sharing. We are working in a questionnaire to get more information from the local deployments. If you agree, we can send it to you to get more information from Haiti deployments. Gonzalo On Wed, Feb 25, 2015 at 5:19 PM, Sora Edwards-Thro s...@unleashkids.org wrote: I just got started with all of this in 2013, so my relationship with the project is very different from many others on this list. I'm also not a programmer. So this is just my perspective as a coordinator with schools using XOs in Haiti. I'm going to tackle the below item-by-item; looking forward to seeing what others have to say. Thanks for bringing these questions to us all. On Wed, Feb 25, 2015 at 2:09 PM, Samuel Greenfeld sam...@greenfeld.org wrote: I am not necessarily discounting XOs; but several community members have said in the past they were not upgrading to the latest Sugar/OLPC OS versions. This is because newer versions tend to need more resources and run slowly on older XO models. Here's a table Martin Dluhos generated of the start-up times on XO-1s for different OS versions. It influenced our decision-making in Haiti (we have a customized version of 12.1.0) http://wiki.laptop.org/go/HaitiOS; I don't know what they decided in Nepal, where he was based. https://docs.google.com/spreadsheet/ccc?key=0As_jQJX0Me6XdDI2clFpX1FFRHhKMHVFZGkyakdST2cusp=sharing Here was my input on that decision: My gut is keep moving forward and go with the latest thing because it's the latest, but I'm not the one who has to fix things when they go wrong...I just report them. Basically, I'm hoping those who have been involved much longer can help gauge what we're gaining and giving upin terms of not only speed loading activities but the support we'll require (12.1.0 more reliable, so less help needed?) and receive (13.2.0 more shiny, so more help offered?) to keep things running. Others should speak for themselves, but I think we stuck with 12.1.0 because the deadline to get things figured out was coming up and we wanted something that had been battle-tested for the upcoming large and ambitious deployment. XOs may always be part of the community; but they are not necessarily going to be the centerpiece going forward. Volunteers have collected and refurbished significant numbers of XO-1s that are still awaiting deployment. It would be a shame to have those go to waste when they can do good somewhere. Same goes for perhaps 1000 XOs sitting in closets in Haiti - we've identified multiple schools (see here https://projectrive.wordpress.com/2014/07/24/kenscoff-special-report/ and here http://www.unleashkids.org/2014/07/11/special-report-thomazeau/) that have abandoned these programs for lack of training and electrical solutions; a little funding and volunteer-work has been able to get those up and running again http://www.unleashkids.org/2014/07/26/lascahobas-we-do-it-all/. For my own project this summer: if we didn't have XOs, this project wouldn't be happening, because we'd be spending all our budget on tablets / laptops instead of the teacher training and programming assistance we'll need to get good results. So no, XOs aren't going to be the centerpiece, but in terms of our operations in Haiti they're definitely a big part of the picture. - An assessment of what is the current Sugar community, and what we would like to see the community become. All I can give you is what we've got in Haiti. 13,200 XOs were apparently deployed. See the blog posts mentioned above for evidence that many actually made it to schools, but those programs did not survive into 2014. In terms of schools where Unleash Kids volunteers have deployed XO-1s or revived XO-1 programs: 60 to Mission of Hope (spring 2013) 25 to Silars' Orphanage (spring 2013) 10 to Ferrier (summer 2013) 10 to Ansapit (summer 2013) 20 to Cazeau (winter 2013) 18 to Hinche (winter 2013) (I know a team went to Leogane as well; I don't know what they did there) 25 to Delmas (summer 2014) 120 in Lascahobas (summer 2014) but only 60 XOs actually being used in classes 10 in Bois D'Avril (summer 2014) Programs are still going strong at Silars', Ansapit, Cazeau, and Lascahobas. Programs have run into funding problems at Mission of Hope, Ferrier, and Hinche, and Delmas. Bois D'Avril is doing its best, but they could use some more training. In 2014 I entered college and started considering how I can approach work in Haiti from the perspective of a researcher and get funding. Nick Doiron and I collaborated with others to create software for a USAID literacy competition. My school funded a pilot test https://projectrive.wordpress.com/ of the software in December. We installed it on the schoolserver and accessed it through browsers on the XOs. I plan to acquire more funding to build on that project this summer. We'll be needing to write new software for some aspects of the project. I hope to host
Re: [IAEP] [Sugar-devel] Planning for the future (Samuel Greenfeld)
Thanks Samuel for start this public discussion. I share some of your concerns, and agree with your points. I think we agree web activities is the way to move forward. We started to work on that for Sugar 0.100, and that will provide us the possibility of run activities in any browser, in android, and in Sugar at the same time. Need more work, but the basics is here. Then we need implement/improve a cloud (or little server) solution, like Sugarizer, or develop a way to provide a Journal in Android. I also think we need a educative social network solution for Sugar. Is not 2007 anymore. I honestly wonder what will we do with our Sugar python/fedora implementation. Without funding, we can't maintain it. And deployments in general are not interested in put money in Sugar, sadly. They are used to get the software for free with the XOs. The true is that we lost the last 3 paid developers working on Sugar (walter, tch and me). Someone who does not work on development could think you can replace 3 developers working 8/10 hours/day by 30 developers working 1 hour/day, but does not work in that way. [1] In my opinion, as Sugar Labs, if we want to be relevant, we need: * Find a way to get funding/partners. Maybe we need someone with marketing skills, and pay him/her a salary. (But for that we need money) I am not a marketing guy (this mail will confirm that), nor walter or others in the slobs. We have a marketing team, but only work on press releases, and I am thinking in marketing in a broader way. * We need review our governance model. SLOBs works for the little decisions (participate or not in GSoC or GCI, support a event), but is not working to take strategic decisions. We can see how other communities are organized. Two years without enough candidates to run the elections is a signal, or the community is not here anymore, or does not care about SLOBs. * Improve our communication internal and external. We have many communities inter related (sugar-devel, iaep, olpc france, olpc sf, Unleash kids, somos azucar, etc, etc). Everyone contribute in different ways to different parts in the ecosystem. I wonder if we can improve communication and team work. Sorry if my message sounds too negative. I already discussed these issues privately but didn't find a solution. Gonzalo [1] http://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_mythical_man-month On Wed, Feb 25, 2015 at 4:09 PM, Samuel Greenfeld sam...@greenfeld.org wrote: I am not necessarily discounting XOs; but several community members have said in the past they were not upgrading to the latest Sugar/OLPC OS versions. This is because newer versions tend to need more resources and run slowly on older XO models. XOs may always be part of the community; but they are not necessarily going to be the centerpiece going forward. The Oversight Board may have more information than what is publicly known. But from the operational perspective, I would like to see: - A clear succession plan for Sugar Labs and Sugar development. It is unclear to me if there still are developers who can fill in for each other if case someone needs to stop working on Sugar, or who will champion the project if Walter becomes unable to do so. - An assessment of what is the current Sugar community, and what we would like to see the community become. - Some sort of public plan depending on the above. - Focusing on what's really out there. Quoting 2 or 3 million XOs made since the beginning of OLPC is great for press releases. But this does not reflect how many are actively used by children. Many XOs are broken, retired, in warehouses, etc. Apart from larger deployments which may have these numbers internally, I don't think anyone has collected the statistics. This is like if Apple stated there are 500 million iPhones 'in the field' (sold) running iOS when in practice many people have broken their iPhones, replaced them with newer models, switched to a different brand... Similar statistics could be taken for Intel Classmates and other things. - The ability to prove that Sugar is still relevant. Looking at the overlap between One Education's leadership and OLPC's historical structure, it is possible that the XO Infinity, when released, will become the new laptop being offered by both going forward.(*) So I would not be surprised if the XO Infinity ran XO Learning or something similar with a new interface supporting thousands of educational applications, was easier and cheaper to develop for, had more conflicting terminology with Sugar, and some improvements for initial mistakes. The use of similar icons and terms puts Sugar into a state like OLPC volunteers are with OLPC's corporations. Volunteers may claim to be part of a wider movement. But whenever the press has questions, they are going to hear the corporations' answers.
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] [Sugar-devel] Planning for the future (Samuel Greenfeld)
Friday, February 27, 2015 2:07 PM -03:00 from Gonzalo Odiard godi...@sugarlabs.org: Thanks Samuel for start this public discussion. I share some of your concerns, and agree with your points. I think we agree web activities is the way to move forward. We started to work on that for Sugar 0.100, and that will provide us the possibility of run activities in any browser, in android, and in Sugar at the same time. Need more work, but the basics is here. Then we need implement/improve a cloud (or little server) solution, like Sugarizer, or develop a way to provide a Journal in Android. I also think we need a educative social network solution for Sugar. Is not 2007 anymore. I honestly wonder what will we do with our Sugar python/fedora implementation. Without funding, we can't maintain it. And deployments in general are not interested in put money in Sugar, sadly. They are used to get the software for free with the XOs. The true is that we lost the last 3 paid developers working on Sugar (walter, tch and me). Someone who does not work on development could think you can replace 3 developers working 8/10 hours/day by 30 developers working 1 hour/day, but does not work in that way. [1] In my opinion, as Sugar Labs, if we want to be relevant, we need: * Find a way to get funding/partners. Maybe we need someone with marketing skills, and pay him/her a salary. (But for that we need money) I am not a marketing guy (this mail will confirm that), nor walter or others in the slobs. We have a marketing team, but only work on press releases, and I am thinking in marketing in a broader way. The problem with partners is that any partner who has established a history of making good decision will ask the same question Mr. Greenfeld asked to start this thread. If they get the same response Dr. Bender gave Mr. Greenfeld they take their money and go back home. Several individuals such as Mr. Abente have suggested the importance of feedback. SugarLabs seems to have difficulty hearing feedback it does not like. Rather than investigate what to improve, the project tends to belittle the reporter's lack of knowledge or vision. This has left Sugar as Dr. Bender's personal project. It might be instructive to ask the simple question, What type of project is Sugar? * We need review our governance model. SLOBs works for the little decisions (participate or not in GSoC or GCI, support a event), but is not working to take strategic decisions. We can see how other communities are organized. Two years without enough candidates to run the elections is a signal, or the community is not here anymore, or does not care about SLOBs. * Improve our communication internal and external. We have many communities inter related (sugar-devel, iaep, olpc france, olpc sf, Unleash kids, somos azucar, etc, etc). Everyone contribute in different ways to different parts in the ecosystem. I wonder if we can improve communication and team work. Sorry if my message sounds too negative. I already discussed these issues privately but didn't find a solution. Gonzalo [1] http://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_mythical_man-month On Wed, Feb 25, 2015 at 4:09 PM, Samuel Greenfeld sam...@greenfeld.org wrote: I am not necessarily discounting XOs; but several community members have said in the past they were not upgrading to the latest Sugar/OLPC OS versions. This is because newer versions tend to need more resources and run slowly on older XO models. XOs may always be part of the community; but they are not necessarily going to be the centerpiece going forward. The Oversight Board may have more information than what is publicly known. But from the operational perspective, I would like to see: * A clear succession plan for Sugar Labs and Sugar development. It is unclear to me if there still are developers who can fill in for each other if case someone needs to stop working on Sugar, or who will champion the project if Walter becomes unable to do so. * An assessment of what is the current Sugar community, and what we would like to see the community become. * Some sort of public plan depending on the above. * Focusing on what's really out there. Quoting 2 or 3 million XOs made since the beginning of OLPC is great for press releases. But this does not reflect how many are actively used by children. Many XOs are broken, retired, in warehouses, etc. Apart from larger deployments which may have these numbers internally, I don't think anyone has collected the statistics. This is like if Apple stated there are 500 million iPhones 'in the field' (sold) running iOS when in practice many people have broken their iPhones, replaced them with newer models, switched to a different brand... Similar statistics could be taken for Intel Classmates and other things. * The ability to prove that Sugar is still relevant. Looking at the overlap between One Education's leadership
Re: [IAEP] [Sugar-devel] Planning for the future (Samuel Greenfeld)
The problem with partners is that any partner who has established a history of making good decision will ask the same question Mr. Greenfeld asked to start this thread. If they get the same response Dr. Bender gave Mr. Greenfeld they take their money and go back home. Several individuals such as Mr. Abente have suggested the importance of feedback. SugarLabs seems to have difficulty hearing feedback it does not like. Rather than investigate what to improve, the project tends to belittle the reporter's lack of knowledge or vision. This has left Sugar as Dr. Bender's personal project. I can't follow you. Almost all the people participating in this thread are Sugar Labs. We have different opinions many times. It might be instructive to ask the simple question, What type of project is Sugar? Could you be more specific? That question can be replied in many different ways. Gonzalo ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Planning for the future (Samuel Greenfeld)
On February 27, 2015 at 6:23 AM Daniel Drake d...@laptop.org wrote: 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) Well sort of, that sets the minimum cpu level to be compiled for, -mfpmath has hand in the choice that is used for compiling also. I was mistaken, guess I'll now think of -mtune as the most advanced cpu features that can be used if present. Just a thought, I haven't checked yet and have no plans in doing so but compiling for i686 on a x86_64 machine might use the -mfpmath info, unless specifically overridden, from the compiling machine where mfpmath default is to use sse. 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. Good that is not the whole distro it is just WebKit but someone wrote the code with sse in mind but didn't see the need to fallback if absent. Perhaps they were working on the assumption that all i686s had sse or Fedora's lowest cpu supported would have sse available. 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. A crash is a crash, and should be fixed. What is the fix needs to be is up to those who still care. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Planning for the future (Samuel Greenfeld)
On Thu, Feb 26, 2015 at 03:31:50PM +1100, James Cameron wrote: On Wed, Feb 25, 2015 at 04:20:02PM -0600, Jerry Vonau wrote: On February 25, 2015 at 3:09 PM James Cameron qu...@laptop.org wrote: On Wed, Feb 25, 2015 at 01:20:19PM -0600, Jerry Vonau 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 which would use sse. This causes problems for some parts of sugar now that java is being used more and the XO-1 lacks sse. Fixing one package that uses sse might fix one issue but this is really a distro wide setting and other issues may float to the top in other areas. Thanks, wasn't aware -mtune=atom was being used upstream. It explains a lot. First build after Fedora 11 was 11.2.0 (os874) using Fedora 14. So if we rebuild everything there may be an improvement? That's probably something that can be set running as a test. Wouldn't all the rpms used need to be recompiled to ensure mtune is set to match throughout the distro? Don't think so. Check my logic: The GCC documentation you referenced described -mtune as Tune to cpu-type everything applicable about the generated code, except for the ABI and the set of available instructions. -march is more significant, as Generate instructions for the machine type cpu-type. The choices for cpu-type are the same as for -mtune. Moreover, specifying -march=cpu-type implies -mtune=cpu-type. If the ABI were different between i586 and i686 arch, that would be very interesting. Tall order IMHO, good luck ;-) For the moment, I'm doing a mock --rebuild of webkitgtk3 with --arch=i586, and the logs so far show -march=i586 -mtune=generic instead of -march=i686 -mtune=atom: This didn't change the problem, gdb core still showed SSE instructions used. Daniel Drake's change to WebKit that fixed this before has since been lost in the current WebKit sources in git. Patch is in the history, but some later patch removed the change. $ grep mtune build.log | grep i586 | wc --lines 8564 $ grep mtune build.log | grep atom | wc --lines 0 $ Jerry -- James Cameron http://quozl.linux.org.au/ -- James Cameron http://quozl.linux.org.au/ ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Planning for the future (Samuel Greenfeld)
On Thu, Feb 26, 2015 at 1:54 AM, Sam P. sam.parkins...@gmail.com wrote: Hi, +1 I think there are some ways to improve hardware independence. Integrating sugar with a display manager would make it work in many (traditional?) IT situations where you have computers with networked student accounts. Over the ensuing years, we have also made efforts to reach out in other ways, some more successful than others: Sugar has been ported to virtually every major flavor of GNU/Linux. As a community, it has been difficult to support all of those efforts, but some, such as Trisquel, rival Fedora, where we still do our development, in terms of stability. (We have lagged behind in our Ubuntu support; given its popularity this has been a tactical mistake.) We also initiated the Sugar on a Stick and Sugar in a virtual machine efforts, which opened the door to getting a taste of Sugar on iOS and MS Windows platforms. These products have matured and are well maintained. In anticipation of the tablet bubble, we added touch support to Sugar; (it works, but the good news is that most people serious about using tablets for learning are also including keyboards these days.) Sugar also runs nicely on Chromebooks, which are making some inroads into the classroom. Yeah, ubuntu is a big issue! And, as Lionel mentioned, already three years ago we began in earnest an effort to support Javascript as a first order language in Sugar so as to both invite a broader community of developers in and being to offer Sugar activities to users of web browsers and Android (eventually iPhone) devices. Lionel has expanded upon that effort to try to offer the whole Sugar experience, not just individual activities. This work is on-going and is the focus of our proposal to Google Summer of Code 2015. Yeah this is a really awesome movement. Just throwing around another opportunity idea, sugar activities are written in GTK, meaning it would be possible to make sugar activities work inside GNOME (or other DEs) as windows. Turtle does this, but it would be cool to expand this to a general library (#GSOC?). TB becoming a spin out is a great way to widen sugar's reach. Tb is an awesome first step towards coding, and export to python and stuff are great features that help in a further intro to coding. And it is worth noting that 50% of the patches in the latest Sugar release came from kids. Yeah, but did 50% of the ideas come from users? All of that said, our future is far from clear. OLPC and OLPC deployments have been the largest source of funding, albeit erratic, for Sugar development and maintenance. (We continue to get some funding from Google, Trip Advisor, et al., but these $s are not general funds for supporting developers and code maintenance.) It seems that the OLPC well is running dry (We have a few proposals circulating but none in hand at the moment.) We've gotten little support from other hardware vendors, I believe in part because many of them still see Sugar Labs as an extension of OLPC, with whom they were competing. Well why not do a needles ui/design change :). It would probably change people's perception if we changed the xo icon or something (a la android 5) and made ourselves less look connected to olpc. Not something to rush out and do without thinking, not something that we should waste development time on either, but an idea. So either Sugar Labs finds support for the core development team to remain focused full-time on Sugar or we scale back our release cycle to one that can be managed entirely by part-time volunteers. There are opportunities out there: for example, partnering with some of the classroom management solutions; finding funding for specific programs, such as Turtle Blocks, and finding more hardware partners. Meanwhile, we also need to keep Sugar relevant. I take the long view there, in that I think the core pedagogical ideas in Sugar are sound and that over time we'll be better situated to get these ideas into the hands of learners. (For example, Android is becoming more Sugar-friendly as it evolves.) Some of the reflection ideas that OLPC AU was pushing seemed really great. Hopefully they can get implemented. But I think whatever path we follow, consultation is the most important. One issue OLPCs and sugarlabs seems to have is the lack of consultation with students and teachers. It is great that we have some educational idea or have read some paper about education that an 'expert' has written, however we are making an OS for students and teachers. If the OS isn't helping students or if it confuses teachers, then what good is it really doing? We can load sugar with data collection tools and what not, but nothing replaces talking to teachers, watching how they use sugar, and asking what they want changed. In fact this is not unique to Sugar and OLPC. I am yet to use edutech at my school that feels like it was built
Re: [IAEP] [Sugar-devel] Planning for the future (Samuel Greenfeld)
+1 PS: 50% of the ideas came from you and Ignacio :) On Wed, Feb 25, 2015 at 11:54 PM, Sam P. sam.parkins...@gmail.com wrote: Hi, +1 I think there are some ways to improve hardware independence. Integrating sugar with a display manager would make it work in many (traditional?) IT situations where you have computers with networked student accounts. Over the ensuing years, we have also made efforts to reach out in other ways, some more successful than others: Sugar has been ported to virtually every major flavor of GNU/Linux. As a community, it has been difficult to support all of those efforts, but some, such as Trisquel, rival Fedora, where we still do our development, in terms of stability. (We have lagged behind in our Ubuntu support; given its popularity this has been a tactical mistake.) We also initiated the Sugar on a Stick and Sugar in a virtual machine efforts, which opened the door to getting a taste of Sugar on iOS and MS Windows platforms. These products have matured and are well maintained. In anticipation of the tablet bubble, we added touch support to Sugar; (it works, but the good news is that most people serious about using tablets for learning are also including keyboards these days.) Sugar also runs nicely on Chromebooks, which are making some inroads into the classroom. Yeah, ubuntu is a big issue! And, as Lionel mentioned, already three years ago we began in earnest an effort to support Javascript as a first order language in Sugar so as to both invite a broader community of developers in and being to offer Sugar activities to users of web browsers and Android (eventually iPhone) devices. Lionel has expanded upon that effort to try to offer the whole Sugar experience, not just individual activities. This work is on-going and is the focus of our proposal to Google Summer of Code 2015. Yeah this is a really awesome movement. Just throwing around another opportunity idea, sugar activities are written in GTK, meaning it would be possible to make sugar activities work inside GNOME (or other DEs) as windows. Turtle does this, but it would be cool to expand this to a general library (#GSOC?). TB becoming a spin out is a great way to widen sugar's reach. Tb is an awesome first step towards coding, and export to python and stuff are great features that help in a further intro to coding. And it is worth noting that 50% of the patches in the latest Sugar release came from kids. Yeah, but did 50% of the ideas come from users? All of that said, our future is far from clear. OLPC and OLPC deployments have been the largest source of funding, albeit erratic, for Sugar development and maintenance. (We continue to get some funding from Google, Trip Advisor, et al., but these $s are not general funds for supporting developers and code maintenance.) It seems that the OLPC well is running dry (We have a few proposals circulating but none in hand at the moment.) We've gotten little support from other hardware vendors, I believe in part because many of them still see Sugar Labs as an extension of OLPC, with whom they were competing. Well why not do a needles ui/design change :). It would probably change people's perception if we changed the xo icon or something (a la android 5) and made ourselves less look connected to olpc. Not something to rush out and do without thinking, not something that we should waste development time on either, but an idea. So either Sugar Labs finds support for the core development team to remain focused full-time on Sugar or we scale back our release cycle to one that can be managed entirely by part-time volunteers. There are opportunities out there: for example, partnering with some of the classroom management solutions; finding funding for specific programs, such as Turtle Blocks, and finding more hardware partners. Meanwhile, we also need to keep Sugar relevant. I take the long view there, in that I think the core pedagogical ideas in Sugar are sound and that over time we'll be better situated to get these ideas into the hands of learners. (For example, Android is becoming more Sugar-friendly as it evolves.) Some of the reflection ideas that OLPC AU was pushing seemed really great. Hopefully they can get implemented. But I think whatever path we follow, consultation is the most important. One issue OLPCs and sugarlabs seems to have is the lack of consultation with students and teachers. It is great that we have some educational idea or have read some paper about education that an 'expert' has written, however we are making an OS for students and teachers. If the OS isn't helping students or if it confuses teachers, then what good is it really doing? We can load sugar with data collection tools and what not, but nothing replaces talking to teachers, watching how they use sugar, and asking what they want changed. In fact this is not unique to Sugar and OLPC. I am yet to use
Re: [IAEP] [Sugar-devel] Planning for the future (Samuel Greenfeld)
On February 24, 2015 at 8:55 AM Walter Bender walter.ben...@gmail.com wrote: I don't think Sugar Labs has lacked a long-term vision. It has been since Day One to provide great tools for learning to children while being hardware agnostic. That said, our tactics have been slowly evolving as the market itself evolves. We launched Sugar Labs in early 2008 when it was clear to some of us in the community that many children would have access to computers other than the OLPC XO. We wanted to reach those children, and indeed, many Sugar users run it on netbooks such as the Intel Classmate. We've also continued to support the XO as well. There are ~3 million XOs in the field, most of which are still running Sugar as far as I know. (When I was in Nepal last year, I saw Sugar running on machines built in 2007, a testament to OLPC's hardware team. It would be interesting to know what version of sugar/OS those XO-1s are running. I am not sure why Sam thinks we need to discount those machines or the kids using them.) 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]. This causes problems for some parts of sugar[3] now that java[4] is being used more and the XO-1 lacks sse. Fixing one package that uses sse might fix one issue but this is really a distro wide setting and other issues may float to the top in other areas. Just pointing out issues with XO-1s as I see it. Jerry 1. http://fedoraproject.org/wiki/Features/F12X86Support 2. https://gcc.gnu.org/onlinedocs/gcc-4.6.2/gcc/i386-and-x86_002d64-Options.html 3. http://lists.laptop.org/pipermail/devel/2014-August/038536.html 4. http://bugs.sugarlabs.org/ticket/4785 ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Planning for the future (Samuel Greenfeld)
I am not necessarily discounting XOs; but several community members have said in the past they were not upgrading to the latest Sugar/OLPC OS versions. This is because newer versions tend to need more resources and run slowly on older XO models. XOs may always be part of the community; but they are not necessarily going to be the centerpiece going forward. The Oversight Board may have more information than what is publicly known. But from the operational perspective, I would like to see: - A clear succession plan for Sugar Labs and Sugar development. It is unclear to me if there still are developers who can fill in for each other if case someone needs to stop working on Sugar, or who will champion the project if Walter becomes unable to do so. - An assessment of what is the current Sugar community, and what we would like to see the community become. - Some sort of public plan depending on the above. - Focusing on what's really out there. Quoting 2 or 3 million XOs made since the beginning of OLPC is great for press releases. But this does not reflect how many are actively used by children. Many XOs are broken, retired, in warehouses, etc. Apart from larger deployments which may have these numbers internally, I don't think anyone has collected the statistics. This is like if Apple stated there are 500 million iPhones 'in the field' (sold) running iOS when in practice many people have broken their iPhones, replaced them with newer models, switched to a different brand... Similar statistics could be taken for Intel Classmates and other things. - The ability to prove that Sugar is still relevant. Looking at the overlap between One Education's leadership and OLPC's historical structure, it is possible that the XO Infinity, when released, will become the new laptop being offered by both going forward.(*) So I would not be surprised if the XO Infinity ran XO Learning or something similar with a new interface supporting thousands of educational applications, was easier and cheaper to develop for, had more conflicting terminology with Sugar, and some improvements for initial mistakes. The use of similar icons and terms puts Sugar into a state like OLPC volunteers are with OLPC's corporations. Volunteers may claim to be part of a wider movement. But whenever the press has questions, they are going to hear the corporations' answers. (*) An alternative they may try is to use OLPC as a way to drop past obligations, and use One Education to create a new brand. This, like the past few paragraphs, is pure speculation by me alone, and may not be the direction anyone goes. On Tue, Feb 24, 2015 at 9:55 AM, Walter Bender walter.ben...@gmail.com wrote: I don't think Sugar Labs has lacked a long-term vision. It has been since Day One to provide great tools for learning to children while being hardware agnostic. That said, our tactics have been slowly evolving as the market itself evolves. We launched Sugar Labs in early 2008 when it was clear to some of us in the community that many children would have access to computers other than the OLPC XO. We wanted to reach those children, and indeed, many Sugar users run it on netbooks such as the Intel Classmate. We've also continued to support the XO as well. There are ~3 million XOs in the field, most of which are still running Sugar as far as I know. (When I was in Nepal last year, I saw Sugar running on machines built in 2007, a testament to OLPC's hardware team. I am not sure why Sam thinks we need to discount those machines or the kids using them.) Over the ensuing years, we have also made efforts to reach out in other ways, some more successful than others: Sugar has been ported to virtually every major flavor of GNU/Linux. As a community, it has been difficult to support all of those efforts, but some, such as Trisquel, rival Fedora, where we still do our development, in terms of stability. (We have lagged behind in our Ubuntu support; given its popularity this has been a tactical mistake.) We also initiated the Sugar on a Stick and Sugar in a virtual machine efforts, which opened the door to getting a taste of Sugar on iOS and MS Windows platforms. These products have matured and are well maintained. In anticipation of the tablet bubble, we added touch support to Sugar; (it works, but the good news is that most people serious about using tablets for learning are also including keyboards these days.) Sugar also runs nicely on Chromebooks, which are making some inroads into the classroom. And, as Lionel mentioned, already three years ago we began in earnest an effort to support Javascript as a first order language in Sugar so as to both invite a broader community of developers in and being to offer Sugar activities to users of web browsers and Android (eventually iPhone) devices. Lionel has expanded upon that effort
Re: [IAEP] [Sugar-devel] Planning for the future (Samuel Greenfeld)
On Wed, Feb 25, 2015 at 03:19:18PM -0500, Sora Edwards-Thro wrote: Here's a table Martin Dluhos generated of the start-up times on XO-1s for different OS versions. It influenced our decision-making in Haiti (we have a customized version of 12.1.0); I don't know what they decided in Nepal, where he was based. https://docs.google.com/spreadsheet/ccc?key=0As_jQJX0Me6XdDI2clFpX1FFRHhKMHVFZGkyakdST2cusp=sharing No, that table was prepared by Gonzalo Odiard in July 2013, and discussed on devel@ at the time, and sugar-devel@ mailing list in November 2013. The results are all because of memory contention, and the fixes are to either: 1. run the operating system from SD card, (which releases a lot of memory), or 2. add swap partition on SD card, (which moves little used memory to the card). -- James Cameron http://quozl.linux.org.au/ ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Planning for the future (Samuel Greenfeld)
On Wed, Feb 25, 2015 at 01:20:19PM -0600, Jerry Vonau 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 which would use sse. This causes problems for some parts of sugar now that java is being used more and the XO-1 lacks sse. Fixing one package that uses sse might fix one issue but this is really a distro wide setting and other issues may float to the top in other areas. Thanks, wasn't aware -mtune=atom was being used upstream. It explains a lot. First build after Fedora 11 was 11.2.0 (os874) using Fedora 14. So if we rebuild everything there may be an improvement? That's probably something that can be set running as a test. -- James Cameron http://quozl.linux.org.au/ ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Planning for the future (Samuel Greenfeld)
Thanks for the fact-checking, James. Sorry I didn't correctly attribute credit to you, Gonzalo. On Wed, Feb 25, 2015 at 3:33 PM, James Cameron qu...@laptop.org wrote: On Wed, Feb 25, 2015 at 03:19:18PM -0500, Sora Edwards-Thro wrote: Here's a table Martin Dluhos generated of the start-up times on XO-1s for different OS versions. It influenced our decision-making in Haiti (we have a customized version of 12.1.0); I don't know what they decided in Nepal, where he was based. https://docs.google.com/spreadsheet/ccc?key=0As_jQJX0Me6XdDI2clFpX1FFRHhKMHVFZGkyakdST2cusp=sharing No, that table was prepared by Gonzalo Odiard in July 2013, and discussed on devel@ at the time, and sugar-devel@ mailing list in November 2013. The results are all because of memory contention, and the fixes are to either: 1. run the operating system from SD card, (which releases a lot of memory), or 2. add swap partition on SD card, (which moves little used memory to the card). -- James Cameron http://quozl.linux.org.au/ ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Planning for the future (Samuel Greenfeld)
On 25.02.2015, at 13:22, Nick Doiron ndoi...@mapmeld.com wrote: I've worked with the project for some time, as a developer, teacher, and teacher-trainer. There have been triumphs and setbacks in the past, but I can't escape this observation: when people have a choice, they choose not to use Sugar. For many schools, they have what was donated and there is no choice. When OLPC started, Android was an independent concept for a feature phone and not a choice for anyone. But if members of our community are talking about a major project in today's world, examine why the wider world isn't using Sugar at the same level that they adopt other edu-tech, like Scratch. Time and time again, local teachers are doing everything we ask, and our true limit is the technology and UX. As a developer, I have lost track of which of my activities might run on modern Sugar. I've seen simple UIs and browser-based activities stop working, not because of shaky code, but because dropdown menus got deprecated, or browser embedding was switched out with a different library. There are reasons behind these code changes, like touch-enabled UI, but were these reasons so real? At the end of all this continuing development, when I use an XO-1 in Haiti, I see the same Sugar that we used in 2011, but with fewer working activities. I am interested in the future of Sugar in the same way that I'm interested in the future of television. The next big thing is not a revision of the old, but something very new, something more attuned to the web and open source ecosystem as it exists today. -- Nick Doiron +1 - Bert - smime.p7s Description: S/MIME cryptographic signature ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Planning for the future (Samuel Greenfeld)
On February 25, 2015 at 3:09 PM James Cameron qu...@laptop.org wrote: On Wed, Feb 25, 2015 at 01:20:19PM -0600, Jerry Vonau 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 which would use sse. This causes problems for some parts of sugar now that java is being used more and the XO-1 lacks sse. Fixing one package that uses sse might fix one issue but this is really a distro wide setting and other issues may float to the top in other areas. Thanks, wasn't aware -mtune=atom was being used upstream. It explains a lot. First build after Fedora 11 was 11.2.0 (os874) using Fedora 14. So if we rebuild everything there may be an improvement? That's probably something that can be set running as a test. Wouldn't all the rpms used need to be recompiled to ensure mtune is set to match throughout the distro? Tall order IMHO, good luck Jerry ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Planning for the future (Samuel Greenfeld)
Hi, +1 I think there are some ways to improve hardware independence. Integrating sugar with a display manager would make it work in many (traditional?) IT situations where you have computers with networked student accounts. Over the ensuing years, we have also made efforts to reach out in other ways, some more successful than others: Sugar has been ported to virtually every major flavor of GNU/Linux. As a community, it has been difficult to support all of those efforts, but some, such as Trisquel, rival Fedora, where we still do our development, in terms of stability. (We have lagged behind in our Ubuntu support; given its popularity this has been a tactical mistake.) We also initiated the Sugar on a Stick and Sugar in a virtual machine efforts, which opened the door to getting a taste of Sugar on iOS and MS Windows platforms. These products have matured and are well maintained. In anticipation of the tablet bubble, we added touch support to Sugar; (it works, but the good news is that most people serious about using tablets for learning are also including keyboards these days.) Sugar also runs nicely on Chromebooks, which are making some inroads into the classroom. Yeah, ubuntu is a big issue! And, as Lionel mentioned, already three years ago we began in earnest an effort to support Javascript as a first order language in Sugar so as to both invite a broader community of developers in and being to offer Sugar activities to users of web browsers and Android (eventually iPhone) devices. Lionel has expanded upon that effort to try to offer the whole Sugar experience, not just individual activities. This work is on-going and is the focus of our proposal to Google Summer of Code 2015. Yeah this is a really awesome movement. Just throwing around another opportunity idea, sugar activities are written in GTK, meaning it would be possible to make sugar activities work inside GNOME (or other DEs) as windows. Turtle does this, but it would be cool to expand this to a general library (#GSOC?). TB becoming a spin out is a great way to widen sugar's reach. Tb is an awesome first step towards coding, and export to python and stuff are great features that help in a further intro to coding. And it is worth noting that 50% of the patches in the latest Sugar release came from kids. Yeah, but did 50% of the ideas come from users? All of that said, our future is far from clear. OLPC and OLPC deployments have been the largest source of funding, albeit erratic, for Sugar development and maintenance. (We continue to get some funding from Google, Trip Advisor, et al., but these $s are not general funds for supporting developers and code maintenance.) It seems that the OLPC well is running dry (We have a few proposals circulating but none in hand at the moment.) We've gotten little support from other hardware vendors, I believe in part because many of them still see Sugar Labs as an extension of OLPC, with whom they were competing. Well why not do a needles ui/design change :). It would probably change people's perception if we changed the xo icon or something (a la android 5) and made ourselves less look connected to olpc. Not something to rush out and do without thinking, not something that we should waste development time on either, but an idea. So either Sugar Labs finds support for the core development team to remain focused full-time on Sugar or we scale back our release cycle to one that can be managed entirely by part-time volunteers. There are opportunities out there: for example, partnering with some of the classroom management solutions; finding funding for specific programs, such as Turtle Blocks, and finding more hardware partners. Meanwhile, we also need to keep Sugar relevant. I take the long view there, in that I think the core pedagogical ideas in Sugar are sound and that over time we'll be better situated to get these ideas into the hands of learners. (For example, Android is becoming more Sugar-friendly as it evolves.) Some of the reflection ideas that OLPC AU was pushing seemed really great. Hopefully they can get implemented. But I think whatever path we follow, consultation is the most important. One issue OLPCs and sugarlabs seems to have is the lack of consultation with students and teachers. It is great that we have some educational idea or have read some paper about education that an 'expert' has written, however we are making an OS for students and teachers. If the OS isn't helping students or if it confuses teachers, then what good is it really doing? We can load sugar with data collection tools and what not, but nothing replaces talking to teachers, watching how they use sugar, and asking what they want changed. In fact this is not unique to Sugar and OLPC. I am yet to use edutech at my school that feels like it was built for and WITH schools. It feels locked up and controlled by visual designers and corporate managers that don't know the needs of schools. Though sugar
Re: [IAEP] [Sugar-devel] Planning for the future (Samuel Greenfeld)
On Wed, Feb 25, 2015 at 04:20:02PM -0600, Jerry Vonau wrote: On February 25, 2015 at 3:09 PM James Cameron qu...@laptop.org wrote: On Wed, Feb 25, 2015 at 01:20:19PM -0600, Jerry Vonau 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 which would use sse. This causes problems for some parts of sugar now that java is being used more and the XO-1 lacks sse. Fixing one package that uses sse might fix one issue but this is really a distro wide setting and other issues may float to the top in other areas. Thanks, wasn't aware -mtune=atom was being used upstream. It explains a lot. First build after Fedora 11 was 11.2.0 (os874) using Fedora 14. So if we rebuild everything there may be an improvement? That's probably something that can be set running as a test. Wouldn't all the rpms used need to be recompiled to ensure mtune is set to match throughout the distro? Don't think so. Check my logic: The GCC documentation you referenced described -mtune as Tune to cpu-type everything applicable about the generated code, except for the ABI and the set of available instructions. -march is more significant, as Generate instructions for the machine type cpu-type. The choices for cpu-type are the same as for -mtune. Moreover, specifying -march=cpu-type implies -mtune=cpu-type. If the ABI were different between i586 and i686 arch, that would be very interesting. Tall order IMHO, good luck ;-) For the moment, I'm doing a mock --rebuild of webkitgtk3 with --arch=i586, and the logs so far show -march=i586 -mtune=generic instead of -march=i686 -mtune=atom: $ grep mtune build.log | grep i586 | wc --lines 8564 $ grep mtune build.log | grep atom | wc --lines 0 $ Jerry -- James Cameron http://quozl.linux.org.au/ ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Planning for the future (Samuel Greenfeld)
I don't think Sugar Labs has lacked a long-term vision. It has been since Day One to provide great tools for learning to children while being hardware agnostic. That said, our tactics have been slowly evolving as the market itself evolves. We launched Sugar Labs in early 2008 when it was clear to some of us in the community that many children would have access to computers other than the OLPC XO. We wanted to reach those children, and indeed, many Sugar users run it on netbooks such as the Intel Classmate. We've also continued to support the XO as well. There are ~3 million XOs in the field, most of which are still running Sugar as far as I know. (When I was in Nepal last year, I saw Sugar running on machines built in 2007, a testament to OLPC's hardware team. I am not sure why Sam thinks we need to discount those machines or the kids using them.) Over the ensuing years, we have also made efforts to reach out in other ways, some more successful than others: Sugar has been ported to virtually every major flavor of GNU/Linux. As a community, it has been difficult to support all of those efforts, but some, such as Trisquel, rival Fedora, where we still do our development, in terms of stability. (We have lagged behind in our Ubuntu support; given its popularity this has been a tactical mistake.) We also initiated the Sugar on a Stick and Sugar in a virtual machine efforts, which opened the door to getting a taste of Sugar on iOS and MS Windows platforms. These products have matured and are well maintained. In anticipation of the tablet bubble, we added touch support to Sugar; (it works, but the good news is that most people serious about using tablets for learning are also including keyboards these days.) Sugar also runs nicely on Chromebooks, which are making some inroads into the classroom. And, as Lionel mentioned, already three years ago we began in earnest an effort to support Javascript as a first order language in Sugar so as to both invite a broader community of developers in and being to offer Sugar activities to users of web browsers and Android (eventually iPhone) devices. Lionel has expanded upon that effort to try to offer the whole Sugar experience, not just individual activities. This work is on-going and is the focus of our proposal to Google Summer of Code 2015. We have been able to enlist some new talent (and refocus some existing talent) in the Javascript arena. For example, there have already been (over the course of 4 months) almost 200 pull requests to the Javascript version of Turtle Blocks from 15 contributors, half of whom are new to Sugar. And it is worth noting that 50% of the patches in the latest Sugar release came from kids. All of that said, our future is far from clear. OLPC and OLPC deployments have been the largest source of funding, albeit erratic, for Sugar development and maintenance. (We continue to get some funding from Google, Trip Advisor, et al., but these $s are not general funds for supporting developers and code maintenance.) It seems that the OLPC well is running dry (We have a few proposals circulating but none in hand at the moment.) We've gotten little support from other hardware vendors, I believe in part because many of them still see Sugar Labs as an extension of OLPC, with whom they were competing. So either Sugar Labs finds support for the core development team to remain focused full-time on Sugar or we scale back our release cycle to one that can be managed entirely by part-time volunteers. There are opportunities out there: for example, partnering with some of the classroom management solutions; finding funding for specific programs, such as Turtle Blocks, and finding more hardware partners. Meanwhile, we also need to keep Sugar relevant. I take the long view there, in that I think the core pedagogical ideas in Sugar are sound and that over time we'll be better situated to get these ideas into the hands of learners. (For example, Android is becoming more Sugar-friendly as it evolves.) The Sugar Oversight Board agreed to host a summit on the future of Sugar some time in the coming months. We've been doing some preparatory work and hope to get something scheduled soon. Meanwhile, let's keep kicking around ideas here. regards. -walter On Tue, Feb 24, 2015 at 4:10 AM, Lionel Laské lio...@olpc-france.org wrote: Hi Samuel, Thanks to share your vision. I think you're right, SugarLabs lack of a clear long-term vision that we could share with all contributors. Hope that your mail we'll give us opportunity to share our thought on that. Here's mine. If Sugar want live, it can't be limited to a niche platform: neither the XO, neither a Fedora computer. I'm sure we're all convinced that the better platform for education is a computer but today all others decision maker in the world seems to think that it's a tablet or even a mobile. So the question is how we could answer to requests for these new platforms thought keeping our roots:
