Re: [Sugar-devel] Planning for the future (Samuel Greenfeld)
On Mon, Mar 02, 2015 at 02:13:01PM +1100, James Cameron wrote: On Sat, Feb 28, 2015 at 10:40:01AM +1100, James Cameron wrote: 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. Reinstating this change didn't solve the problem, so something else in WebKit is generating invalid instructions. Recompiling WebKit without JIT seems to fix things for now. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Planning for the future (Samuel Greenfeld)
On Sat, Feb 28, 2015 at 10:40:01AM +1100, James Cameron wrote: 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. Reinstating this change didn't solve the problem, so something else in WebKit is generating invalid instructions. Here's the backtrace: (gdb) bt #0 0xaa31b515 in ?? () #1 0xb1f03729 in JSC::JIT::privateCompile(JSC::MacroAssemblerCodePtr*, JSC::JITCompilationEffort) () from /lib/libjavascriptcoregtk-3.0.so.0 #2 0xb200f21c in JSC::UnlinkedProgramCodeBlock* JSC::CodeCache::getCodeBlockJSC::UnlinkedProgramCodeBlock, JSC::ProgramExecutable(JSC::VM, JSC::ProgramExecutable*, JSC::SourceCode const, JSC::JSParserStrictness, JSC::DebuggerMode, JSC::ProfilerMode, JSC::ParserError) () from /lib/libjavascriptcoregtk-3.0.so.0 #3 0xb25d04fe in WTF::HashMapNPClass*, JSC::Bindings::CClass*, WTF::PtrHashNPClass*, WTF::HashTraitsNPClass*, WTF::HashTraitsJSC::Bindings::CClass* ::set(NPClass* const, JSC::Bindings::CClass* const) () from /lib/libwebkitgtk-3.0.so.0 #4 0xbf808a44 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) And the invalid instruction stream: │0xaa31b515 movsd (%ebx,%ecx,8),%xmm0 │ │0xaa31b51a ucomisd %xmm0,%xmm0│ │0xaa31b51e jp 0xaa31ccde │ │0xaa31b524 movd %xmm0,%eax │ │0xaa31b528 psrlq $0x20,%xmm0 │ │0xaa31b52d movd %xmm0,%edx │ │0xaa31b531 mov%eax,0xa9424114 │ │0xaa31b536 mov%edx,0xa9424118 │ │0xaa31b53c mov%eax,0x10(%edi) │ │0xaa31b53f mov%edx,0x14(%edi) │ │0xaa31b542 mov-0x40(%edi),%eax│ │0xaa31b545 mov-0x3c(%edi),%edx│ │0xaa31b548 cmp$0xfffb,%edx│ -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [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: [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. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [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/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [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: [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: [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: [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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [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/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [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: [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/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Planning for the future (Samuel Greenfeld)
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: an unique UI for children, a reflection tool (Journal), a collaborative platform (Presence) and the most important - free an open source contents. My point of view is that we must not invest time to think how we could be compliant with a new platform, we need to think in another way: how we could port Sugar on Any platform ? Any computer (from the bigger one to the tiny one: raspberryPI), any laptop, any tablet, any mobile. And the answer is simple: web technologies allow every device to run very complex software. It's the only solution to be compliant with any device. It's where we need to put our investments. It's why I've got a personal engagement on Sugar for the Web from years: - First to allow Sugar activities to be written using web technologies. From Sugar 0.100 thanks to Sugar Web, every developer could write new Sugar activities using exclusively HTML5/JavaScript - without any line of Python/Gtk. - Second to create a Sugar container for the web - named Sugarizer - that could host any Sugar Web activities and that reproduce the unique Sugar features: Sugar UI, Journal and Presence. Sugar for the Web is not the Sugar successor, Sugar for the Web is a way to do a transition from Sugar for the XO to an universal version of Sugar that could run on any device so that could be used by any children anywhere on the world. Most important with Sugar for the Web we don't leave alone our current base of Sugar users, with Sugar 0.100+: any new Sugar Web activities will be usable both on Sugar on old devices and Sugar on new devices. With Sugarizer and Sugar Web, Sugar for any device already exist. But to become a reality, we need to invest more on it: - Have a clear roadmap of transition between old Sugar activities to Sugar Web activities. - Convince a more important community to join us. Sugar is the better learning platform, with Sugar for the Web, it should be easy to convince other communities to help us. I think specifically to Mozilla because they have a clear engagement on web and open source and Google because of their wish to embrace education with Chrome. We need to ask help from them. - Experiment: we need to start deployment as soon as possible to demonstrate. At OLPC France, we've got ambition to start a first experimental deployment of Sugarizer before the end of the year. All of us spent years on promoting the Sugar philosophy. We have the choice to look backward or look forward. My choice is clear: with Sugar for the Web I will give to every children the same opportunities I gave to XO users. Best regards from France. Lionel. Date: Mon, 23 Feb 2015 18:36:34 -0500 From: Samuel Greenfeld sam...@greenfeld.org To: IAEP SugarLabs i...@lists.sugarlabs.org Subject: [IAEP] Planning for the future Message-ID: CA+cAqjM7= hqou47mhmr9aqtnbzkrmjdb00nxbzennbo+1wk...@mail.gmail.com Content-Type: text/plain; charset=utf-8 Disclaimer: The following are my views, and not the views of my current or past employers. About a year ago, I privately expressed concern that Sugar needed to ensure it had long-term sponsorship and a long-term user base. Since then, both the historical US-based OLPC organization and Sugar Labs have not publicly said much about their long-term plans, with OLPC also being rather closemouthed about the present. Meanwhile contributors silently leave. It is hard to justify volunteering when you don't know who will benefit besides mysterious customers. Everyone seems happy to cite their past successes. No one corrects the press when they report stale information in their favor. There is no shame in being a smaller project. But we need to ask the hard questions. With Sugar, getting users and developers for a niche platform is a problem. With OLPC, everyone seems to love repeating the 2 or 2.5 million number for laptops historically shipped. Rarely is it asked how many XOs been shipped in the past year or are in active use where. Sugar OLPC need to come up with long-term strategies. While there is nothing public I have seen stopping One Education's XO Infinity from running Sugar, I haven't seen anything stopping it from running anything else. It is also unclear how much One Education is willing to engage with the
Re: [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:
