Re: [IAEP] Sugar oversight board meeting
Well, my impression is that at the moment we have a well defined
educational vision and a pretty solid UX design based on it. What we lack
is an hardware+software platform to run it on. So I don't think trying to
find a solution for that is getting bogged down, all the contrary.
On Tuesday, 5 November 2013, Caryl Bigenho wrote:
Hi…
Last year at SCaLE George Hunt helped me get Sugar running on my RPi.
Because our booth was so busy, it took parts of both Saturday and Sunday to
get it going. I then tried it when I got home and found that it was prone
to stalls. Of course, this was back in late February and there may have
been improvements since then. If so, please let me know where to find the
download and instructions for installing.
I would like to suggest we keep the idea of Sugar on the RPi in mind, but
perhaps in a smaller, reduced size with only a few carefully selected
Activities. Perhaps it could be called A Taste Of Sugar.
Remember, the whole idea behind the RPi is to get young people involved in
really learning about computers and computing and to do creative things
with them. With this in mind, some of the Activities that could be part
of a small version of Sugar might include Turtle Blocks for robotics, a
small version of Tam Tam for experimenting with creating musical sounds and
actually composing with loops (I realize even a tiny version of Tam Tam
would be a huge undertaking, but very worthwhile), Pippy for learning
Python, etc.
As we discuss where our group(s) should focus in the future, let's try not
to get to bogged down in discussions of hardware platforms and software
solutions. First and foremost we might want to consider the educational
experience we want to make available to students. Hopefully, it will be
something that fosters creativity, collaboration, and problem solving while
making projects of all kinds imaginable.
Caryl
Date: Tue, 5 Nov 2013 13:46:31 +1100
From: qu...@laptop.org javascript:_e({}, 'cvml', 'qu...@laptop.org');
To: satelli...@gmail.com javascript:_e({}, 'cvml',
'satelli...@gmail.com');
CC: dwnarv...@gmail.com javascript:_e({}, 'cvml',
'dwnarv...@gmail.com');; market...@lists.sugarlabs.orgjavascript:_e({},
'cvml', 'market...@lists.sugarlabs.org');;
sugar-de...@lists.sugarlabs.org javascript:_e({}, 'cvml',
'sugar-de...@lists.sugarlabs.org');;
iaep@lists.sugarlabs.orgjavascript:_e({}, 'cvml',
'iaep@lists.sugarlabs.org');;
olpc-...@lists.laptop.org javascript:_e({}, 'cvml',
'olpc-...@lists.laptop.org');
Subject: Re: [IAEP] [Sugar-devel] [Marketing] [Sur] Sugar oversight
board meeting
On Mon, Nov 04, 2013 at 04:40:51PM -0800, Thomas Gilliard wrote:
On 11/4/2013 4:17 PM, Daniel Narvaez wrote:
On 4 November 2013 23:05, Peter Robinson
pbrobin...@gmail.comjavascript:_e({}, 'cvml', 'pbrobin...@gmail.com');
wrote:
Sugar on Android or the Raspberry Pi might have an interesting
marketing effect but the result would be truly terrible as it would be
essentially unusable and have a terrible experience.
Can you elaborate on why you think it would be a terrible experience
on the
Raspberry Pi? I never tested it there, I was just hoping it could be a
nice
target...
Look at these older tests of sugar on the RPi:
http://wiki.sugarlabs.org/go/Testing/Reports/ARM_RPi
This part of the Advanced topics wiki page on the sugarlabs wiki:
http://wiki.sugarlabs.org/go/Sugar_Creation_Kit/sck/Advanced_Topics#ARM
Tom Gilliard
I could not find any evidence of user experience testing, or
performance evaluation, in the two links you gave. Did you give the
right ones?
I agree with Peter, I don't think it will perform well, but I don't
know in what way it won't perform well, so I can't guess where effort
would have to be spent to fix it.
(especially in comparison to an XO-1)
--
James Cameron
http://quozl.linux.org.au/
___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org javascript:_e({}, 'cvml',
'IAEP@lists.sugarlabs.org');
http://lists.sugarlabs.org/listinfo/iaep
--
Daniel Narvaez
___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Sugar oversight board meeting
Sorry for the top posting, quoting on gmail on iPhone is a pain. * I'm glad that you see some runway for the XO and I really hope you are right, it would be awesome. I think even just the uncertainity is a big issue for upstream development at the moment. Not knowing if anyone is going to build F20 based images for example... * The issue I see with Chromebook is that it's mostly a locked down platform. It has a supported developer mode which is better than nothing but I'm not sure is enough. How many people will feel like going through the hassle and risk to break their working OS? Will deployments be able to work with something like that? It even requires to ctrl-d on every boot... I sort of wish the ARM vendors started to use secure uefi, and that's saying it all :/ On Tuesday, 5 November 2013, Walter Bender wrote: On Mon, Nov 4, 2013 at 7:42 PM, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: On 4 November 2013 22:53, Sean DALY sdaly...@gmail.com javascript:; wrote: * It's not clear to me where we are going. The OLPC/Sugar development ecosystem seems to be at a crossroads. I am encouraged by the web activity work, but don't understand the path of transposing the value proposition of Sugar (interface, Journal, collaboration, Activities) to handheld tactile devices (tablets to smartphones). PCs (of any size) with keyboards are no longer competitive with tablets for grade-school classroom use. Perhaps the XO-4 could still be in the running; there is no clear message from OLPC. I'll try to express briefly my feelings about the directions the project could take. Note that I might be missing a lot of what is going on above the technical level. * The XO is not a viable hardware platform other than for existing deployments. OLPC is pretty clearly going in a different direction. I may be alone in thinking that there will be some runway left with the XO. But deployments need alternatives regardless. * Sugar web activities on the top of a full Android loses too much of the Sugar value proposition. It's great to have it in addition to Sugar-the-OS, but it's not enough alone. I agree. * From the technical point of view there are several ways to get Sugar-the-OS running on tactile devices. Unfortunately it's not clear to me that any of these devices is open enough to be viable for deployments or ordinary users. We looked at ChromeOS a few years back, but at the time it was too heavy for our hardware. Today, it is a different story. Might be a viable option. Certainly running GNU/Linux/Sugar on a ChromeBook is not a bad starting point. -- Daniel Narvaez ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org javascript:; http://lists.sugarlabs.org/listinfo/sugar-devel -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sur] Sugar oversight board meeting
On Tue, Nov 5, 2013 at 12:17 AM, Daniel Narvaez dwnarv...@gmail.com wrote: On 4 November 2013 23:05, Peter Robinson pbrobin...@gmail.com wrote: Sugar on Android or the Raspberry Pi might have an interesting marketing effect but the result would be truly terrible as it would be essentially unusable and have a terrible experience. Can you elaborate on why you think it would be a terrible experience on the Raspberry Pi? I never tested it there, I was just hoping it could be a nice target... It's generally not particularly fast and has a number of HW problems, as a look at how cool we are I wouldn't be chosing the RPi to run sugar on Android, even on Linux the experience isn't great. There are a number of other ARM devices that sugar runs beautifully on though. It would also be interesting to know more about these devices. With OLPC going the Android way, I wish there was at least one popular enough device on which we could provide a really good experience (with our scarce resources). Well Fedora produces SoaS on ARM images that will run on any of the ARM platforms Fedora supports. I would be looking at BeagleBone Black [1] (improvements still needed, should be much better soon), Wandboard [2], Utilite [3] (little brother to the TrimSlice) or the CuBox-i [4]. The last of which has the cheapest model at $45 in a case and will be much faster, we should have OOTB graphics for the last 3 devices (all based on the i.MX6) in Fedora 21 (maybe later in the F-20 cycle) and the experience will be much better for little to no price increase over the RPi. [1] http://beagleboard.org/Products/BeagleBone%20Black [2] http://www.wandboard.org/ [3] http://utilite-computer.com/ [4] http://cubox-i.com/table/ ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] [Sur] Sugar oversight board meeting
On Tue, Nov 5, 2013 at 2:14 AM, Walter Bender walter.ben...@gmail.com wrote: On Mon, Nov 4, 2013 at 7:42 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On 4 November 2013 22:53, Sean DALY sdaly...@gmail.com wrote: * It's not clear to me where we are going. The OLPC/Sugar development ecosystem seems to be at a crossroads. I am encouraged by the web activity work, but don't understand the path of transposing the value proposition of Sugar (interface, Journal, collaboration, Activities) to handheld tactile devices (tablets to smartphones). PCs (of any size) with keyboards are no longer competitive with tablets for grade-school classroom use. Perhaps the XO-4 could still be in the running; there is no clear message from OLPC. I'll try to express briefly my feelings about the directions the project could take. Note that I might be missing a lot of what is going on above the technical level. * The XO is not a viable hardware platform other than for existing deployments. OLPC is pretty clearly going in a different direction. I may be alone in thinking that there will be some runway left with the XO. But deployments need alternatives regardless. * Sugar web activities on the top of a full Android loses too much of the Sugar value proposition. It's great to have it in addition to Sugar-the-OS, but it's not enough alone. I agree. * From the technical point of view there are several ways to get Sugar-the-OS running on tactile devices. Unfortunately it's not clear to me that any of these devices is open enough to be viable for deployments or ordinary users. We looked at ChromeOS a few years back, but at the time it was too heavy for our hardware. Today, it is a different story. Might be a viable option. Certainly running GNU/Linux/Sugar on a ChromeBook is not a bad starting point. Given that ChromeOS is locked down I don't believe it's viable to ask a School to have to break/hack the HW to get it working OOTB. Having been involved in the OLPC OS side of things I believe you would be much better taking the work done by OLPC with things like olpc-os-builder and the work upstream with Fedora to use it to build out OS images that will work in a similar way across both XOs and other HW be it x86 netbook or cheap ARM devices rather than reinventing the wheel! Peter ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] [Marketing] [Sur] Sugar oversight board meeting
Look at these older tests of sugar on the RPi: http://wiki.sugarlabs.org/go/Testing/Reports/ARM_RPi This part of the Advanced topics wiki page on the sugarlabs wiki: http://wiki.sugarlabs.org/go/Sugar_Creation_Kit/sck/Advanced_Topics#ARM Tom Gilliard I could not find any evidence of user experience testing, or performance evaluation, in the two links you gave. Did you give the right ones? The links I see above provide a lot of random links and information but it seems to be a confusing mish-mash of stuff. Useful for someone who is extremely technical but not to a school which wants an off the shelf experience that just works. I agree with Peter, I don't think it will perform well, but I don't know in what way it won't perform well, so I can't guess where effort would have to be spent to fix it. Somethings are HW or closed source drivers so I don't believe it would be possible to get a reasonable, reproducible QAed experience that would be of decent performance on a reproducible platform. If we want to look at a platform where we can produce a consistent nice platform I would suggest the Beagle Bone black where we can produce and image to fix on the onboard eMMC or something like the bottom end Cubox-i where each could cost less than $50 and be a consistent controllable experience. (especially in comparison to an XO-1) Well it would be likely similar performance to an XO-1 which is TERRIBLE! Peter ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] [Marketing] [Sur] Sugar oversight board meeting
On Tue, Nov 5, 2013 at 6:15 AM, Caryl Bigenho cbige...@hotmail.com wrote: Hi… Last year at SCaLE George Hunt helped me get Sugar running on my RPi. Because our booth was so busy, it took parts of both Saturday and Sunday to get it going. I then tried it when I got home and found that it was prone to stalls. Of course, this was back in late February and there may have been improvements since then. If so, please let me know where to find the download and instructions for installing. I would like to suggest we keep the idea of Sugar on the RPi in mind, but perhaps in a smaller, reduced size with only a few carefully selected Activities. Perhaps it could be called A Taste Of Sugar. I think there's a lot better cheap ARM dev boards out there that offer a better experience and performance for the same price. Having been actively involved in low level ARM stuff for well over 2 years I think we should forget about it and spend time on the other cheap devices that are more open and easier to support. Remember, the whole idea behind the RPi is to get young people involved in really learning about computers and computing and to do creative things with them. With this in mind, some of the Activities that could be part of a small version of Sugar might include Turtle Blocks for robotics, a small version of Tam Tam for experimenting with creating musical sounds and actually composing with loops (I realize even a tiny version of Tam Tam would be a huge undertaking, but very worthwhile), Pippy for learning Python, etc. I don't think any of that is unachievable. If you use the Pidora image for SoaS you can have it now. If you have any number of other cheap ARM boards you can even have a full Sugar 0.100 on Fedora 20 _NOW_ will all of that! As we discuss where our group(s) should focus in the future, let's try not to get to bogged down in discussions of hardware platforms and software solutions. First and foremost we might want to consider the educational experience we want to make available to students. Hopefully, it will be something that fosters creativity, collaboration, and problem solving while making projects of all kinds imaginable. We already have the basis of the educational experience from the current releases of Sugar. In terms of HW I think we should use upstream distros and let them care about the HW and work with one or two of them to ensure that the Sugar experience on them is great OOTB so that people can then focus on development of the platform. That's what I've been doing with Fedora and Sugar for 5 years! IMO the sugar OOTB there just works Peter ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Sugar 0.100.0 (stable)
On Mon, Nov 4, 2013 at 11:13 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On 5 November 2013 00:07, Peter Robinson pbrobin...@gmail.com wrote: On Mon, Nov 4, 2013 at 10:59 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Broken annotation in abiword. Trying to figure out the correct one then I'll open a bug + patch. Thanks! Let me know when you've got a patch and I'll test it. Here it is http://bugzilla.abisource.com/show_bug.cgi?id=13572 Thanks, that's fixed the running issue for me on Fedora 20, I've pushed the patch to the Fedora abiword 3 and will do more testing later. Thanks for your quick assistance with this. Peter ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Sugar oversight board meeting
Thanks a lot for the feedback Peter. I will check these out. For the record, I was thinking about Sugar on Linux on Raspberry, not Android. On Tuesday, 5 November 2013, Peter Robinson wrote: On Tue, Nov 5, 2013 at 12:17 AM, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: On 4 November 2013 23:05, Peter Robinson pbrobin...@gmail.comjavascript:; wrote: Sugar on Android or the Raspberry Pi might have an interesting marketing effect but the result would be truly terrible as it would be essentially unusable and have a terrible experience. Can you elaborate on why you think it would be a terrible experience on the Raspberry Pi? I never tested it there, I was just hoping it could be a nice target... It's generally not particularly fast and has a number of HW problems, as a look at how cool we are I wouldn't be chosing the RPi to run sugar on Android, even on Linux the experience isn't great. There are a number of other ARM devices that sugar runs beautifully on though. It would also be interesting to know more about these devices. With OLPC going the Android way, I wish there was at least one popular enough device on which we could provide a really good experience (with our scarce resources). Well Fedora produces SoaS on ARM images that will run on any of the ARM platforms Fedora supports. I would be looking at BeagleBone Black [1] (improvements still needed, should be much better soon), Wandboard [2], Utilite [3] (little brother to the TrimSlice) or the CuBox-i [4]. The last of which has the cheapest model at $45 in a case and will be much faster, we should have OOTB graphics for the last 3 devices (all based on the i.MX6) in Fedora 21 (maybe later in the F-20 cycle) and the experience will be much better for little to no price increase over the RPi. [1] http://beagleboard.org/Products/BeagleBone%20Black [2] http://www.wandboard.org/ [3] http://utilite-computer.com/ [4] http://cubox-i.com/table/ -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sur] Sugar oversight board meeting
Ok, I will reply to your points, just in different order: On Mon, Nov 4, 2013 at 6:53 PM, Sean DALY sdaly...@gmail.com wrote: Gonzalo - I'm sorry, I was unable to attend the SLOBs meeting today. There are issues with doing PR about the release * Our target market, the ten million or so grade-school teachers worldwide, can't benefit from the release; there are no installers. There are detailed instructions for using virtualization on the wiki thanks to satellit, and the consistently good work of probinson on SoaS, but the release itself won't be news if no one can use it. You are right. May be is better wait until we have images to install. I am working now on this, and can report when is finished. SoaS is the the other candidate. * It's not clear to me where we are going. The OLPC/Sugar development ecosystem seems to be at a crossroads. I am encouraged by the web activity work, but don't understand the path of transposing the value proposition of Sugar (interface, Journal, collaboration, Activities) to handheld tactile devices (tablets to smartphones). PCs (of any size) with keyboards are no longer competitive with tablets for grade-school classroom use. Perhaps the XO-4 could still be in the running; there is no clear message from OLPC. Yes, we are at a crossroads. But Sugar is not OLPC. Is sad lost the support of OLPC, but also open the opportunity of re-think who are we and what is our space. OLPC was, from the name, driven by hardware, running a run difficult to win when you are small, but needed because nobody else was interested in doing it. This situation did OLPC invest more in the low level stuff than in Sugar. Also, in retrospective, is possible we had a attitude of we know better and wasn't trying to solve the specific problems of teacher in classrooms. As you say, the landscape now is different, cheap (and at times crap) hardware is available, but also there are a expensive option (all the Apple stuff) and a almost open option (Android). Google started to monetize the education space ̣[1] [2], how we will fight against that? In my personal view, we are the option of software, open, free, focused in our specific range of ages, with a special design to work in schools, with a pedagogical background and with the possibility to work with low connectivity. The low connectivity space will be smaller every time, but we can (and need) improve the solutions we provide to teachers and to schools, and improve our use of free and open resources. If you ask me about a strategy, is the best I can think right now :) For these reasons (as mentioned on the marketing list) an Activity/pedagogical focus is a safe bet. I agree. Unfortunately our Turtle Art Day PR flopped because publication of the Spanish PR was delayed by two days (technical bottleneck which I very much hope we will be able to solve). The PR will however fulfill its role of background for interested journalists (www.sugarlabs.org/press). I haven't expected any wider press coverage for some time now, since we don't have any easy-to-try products available and OLPC's press communications are meant to imply that laptops are out and the Android tablet is in, leaving Sugar in limbo. An easy installation use procedure for Sugar on Android or the Raspberry Pi could have major press impact, but I don't know how near or far we are from those. Even if we install Sugar in a RasperryPi, this solve the testing for hobbyists, is not a solution for schools or kids. The upcoming TA Days and internationalization work grant will give us ample opportunity to mention the release, but we need to know where we are going if we hope to get a message out on that topic. I agree. We need focus our (few) resources, thing strategically, and have a consistent message and development. Gonzalo Sean [1] http://developer.android.com/distribute/googleplay/edu/index.html [2] http://www.google.com/edu/android/ On Mon, Nov 4, 2013 at 12:34 AM, Gonzalo Odiard gonz...@laptop.org wrote: One topic to add could be do a PR about our recent sugar 0.100 release. Gonzalo On Sun, Nov 3, 2013 at 1:12 PM, Walter Bender walter.ben...@gmail.com wrote: We have a SLOB meeting scheduled for Monday, 4 November at 9AM EST (2PM GMT). Please join us on irc.freenode.net #sugar-meeting (chat.sugarlabs.org) Tenemos una reunión SLOB programada para el lunes, 4 de noviembre a 09 a.m. EST (14:00 GMT). Por favor, únase a nosotros en irc.freenode.net #-sugar-meeting (chat.sugarlabs.org) Topics: (1) election (2) ambassadors (3) tech/learning meetups (4) status of Trip Advisor grant (5) Google Code In (6) your topic here... -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Lista olpc-Sur olpc-...@lists.laptop.org http://lists.laptop.org/listinfo/olpc-sur ___ Lista olpc-Sur
Re: [IAEP] Sugar oversight board meeting
Do you know what's the status of graphics with the BeagleBone Black? On Tuesday, 5 November 2013, Peter Robinson wrote: On Tue, Nov 5, 2013 at 12:17 AM, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: On 4 November 2013 23:05, Peter Robinson pbrobin...@gmail.comjavascript:; wrote: Sugar on Android or the Raspberry Pi might have an interesting marketing effect but the result would be truly terrible as it would be essentially unusable and have a terrible experience. Can you elaborate on why you think it would be a terrible experience on the Raspberry Pi? I never tested it there, I was just hoping it could be a nice target... It's generally not particularly fast and has a number of HW problems, as a look at how cool we are I wouldn't be chosing the RPi to run sugar on Android, even on Linux the experience isn't great. There are a number of other ARM devices that sugar runs beautifully on though. It would also be interesting to know more about these devices. With OLPC going the Android way, I wish there was at least one popular enough device on which we could provide a really good experience (with our scarce resources). Well Fedora produces SoaS on ARM images that will run on any of the ARM platforms Fedora supports. I would be looking at BeagleBone Black [1] (improvements still needed, should be much better soon), Wandboard [2], Utilite [3] (little brother to the TrimSlice) or the CuBox-i [4]. The last of which has the cheapest model at $45 in a case and will be much faster, we should have OOTB graphics for the last 3 devices (all based on the i.MX6) in Fedora 21 (maybe later in the F-20 cycle) and the experience will be much better for little to no price increase over the RPi. [1] http://beagleboard.org/Products/BeagleBone%20Black [2] http://www.wandboard.org/ [3] http://utilite-computer.com/ [4] http://cubox-i.com/table/ -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Sugar oversight board meeting
On Tue, Nov 5, 2013 at 1:16 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Do you know what's the status of graphics with the BeagleBone Black? Sugar on the BBB should work fine with the modesetting driver OOTB (I've still got some kernel bits to do in Fedora, 3.12 should be much better) as it doesn't need 3D. The i.MX6 devices (WandBard, Utilite, CuBox-i etc) should have accelerated graphics in the F-21 time frame. Peter On Tuesday, 5 November 2013, Peter Robinson wrote: On Tue, Nov 5, 2013 at 12:17 AM, Daniel Narvaez dwnarv...@gmail.com wrote: On 4 November 2013 23:05, Peter Robinson pbrobin...@gmail.com wrote: Sugar on Android or the Raspberry Pi might have an interesting marketing effect but the result would be truly terrible as it would be essentially unusable and have a terrible experience. Can you elaborate on why you think it would be a terrible experience on the Raspberry Pi? I never tested it there, I was just hoping it could be a nice target... It's generally not particularly fast and has a number of HW problems, as a look at how cool we are I wouldn't be chosing the RPi to run sugar on Android, even on Linux the experience isn't great. There are a number of other ARM devices that sugar runs beautifully on though. It would also be interesting to know more about these devices. With OLPC going the Android way, I wish there was at least one popular enough device on which we could provide a really good experience (with our scarce resources). Well Fedora produces SoaS on ARM images that will run on any of the ARM platforms Fedora supports. I would be looking at BeagleBone Black [1] (improvements still needed, should be much better soon), Wandboard [2], Utilite [3] (little brother to the TrimSlice) or the CuBox-i [4]. The last of which has the cheapest model at $45 in a case and will be much faster, we should have OOTB graphics for the last 3 devices (all based on the i.MX6) in Fedora 21 (maybe later in the F-20 cycle) and the experience will be much better for little to no price increase over the RPi. [1] http://beagleboard.org/Products/BeagleBone%20Black [2] http://www.wandboard.org/ [3] http://utilite-computer.com/ [4] http://cubox-i.com/table/ -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Sugar oversight board meeting
Is 3D support for the BBB not planned/possible? I know we don't require it at the moment but it would be nice to have in the future (and it *might* speed up things even with the current software...). On Tuesday, 5 November 2013, Peter Robinson wrote: On Tue, Nov 5, 2013 at 1:16 PM, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: Do you know what's the status of graphics with the BeagleBone Black? Sugar on the BBB should work fine with the modesetting driver OOTB (I've still got some kernel bits to do in Fedora, 3.12 should be much better) as it doesn't need 3D. The i.MX6 devices (WandBard, Utilite, CuBox-i etc) should have accelerated graphics in the F-21 time frame. Peter On Tuesday, 5 November 2013, Peter Robinson wrote: On Tue, Nov 5, 2013 at 12:17 AM, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: On 4 November 2013 23:05, Peter Robinson pbrobin...@gmail.comjavascript:; wrote: Sugar on Android or the Raspberry Pi might have an interesting marketing effect but the result would be truly terrible as it would be essentially unusable and have a terrible experience. Can you elaborate on why you think it would be a terrible experience on the Raspberry Pi? I never tested it there, I was just hoping it could be a nice target... It's generally not particularly fast and has a number of HW problems, as a look at how cool we are I wouldn't be chosing the RPi to run sugar on Android, even on Linux the experience isn't great. There are a number of other ARM devices that sugar runs beautifully on though. It would also be interesting to know more about these devices. With OLPC going the Android way, I wish there was at least one popular enough device on which we could provide a really good experience (with our scarce resources). Well Fedora produces SoaS on ARM images that will run on any of the ARM platforms Fedora supports. I would be looking at BeagleBone Black [1] (improvements still needed, should be much better soon), Wandboard [2], Utilite [3] (little brother to the TrimSlice) or the CuBox-i [4]. The last of which has the cheapest model at $45 in a case and will be much faster, we should have OOTB graphics for the last 3 devices (all based on the i.MX6) in Fedora 21 (maybe later in the F-20 cycle) and the experience will be much better for little to no price increase over the RPi. [1] http://beagleboard.org/Products/BeagleBone%20Black [2] http://www.wandboard.org/ [3] http://utilite-computer.com/ [4] http://cubox-i.com/table/ -- Daniel Narvaez -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Sugar oversight board meeting
Going a bit off topic, but a pretty major issue I see in our workflow with Fedora is that we don't have a good way to develop unstable Sugar on a stable Fedora. Rawhide is, or at least is perceived as, unstable. And I'm not sure what would be a good way to, for example, produce and distribute 0.100 rpms for Fedora 19. We can setup our custom automated build system and repository of course, but I'm not sure that's a good approach? Part of the problem here is that upstream tends to depend strongly on very recent libraries which are not yet available in the stable fedora, though maybe now that the gi conversion is over we can avoid that. On Tuesday, 5 November 2013, Peter Robinson wrote: On Tue, Nov 5, 2013 at 2:14 AM, Walter Bender walter.ben...@gmail.comjavascript:; wrote: On Mon, Nov 4, 2013 at 7:42 PM, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: On 4 November 2013 22:53, Sean DALY sdaly...@gmail.com javascript:; wrote: * It's not clear to me where we are going. The OLPC/Sugar development ecosystem seems to be at a crossroads. I am encouraged by the web activity work, but don't understand the path of transposing the value proposition of Sugar (interface, Journal, collaboration, Activities) to handheld tactile devices (tablets to smartphones). PCs (of any size) with keyboards are no longer competitive with tablets for grade-school classroom use. Perhaps the XO-4 could still be in the running; there is no clear message from OLPC. I'll try to express briefly my feelings about the directions the project could take. Note that I might be missing a lot of what is going on above the technical level. * The XO is not a viable hardware platform other than for existing deployments. OLPC is pretty clearly going in a different direction. I may be alone in thinking that there will be some runway left with the XO. But deployments need alternatives regardless. * Sugar web activities on the top of a full Android loses too much of the Sugar value proposition. It's great to have it in addition to Sugar-the-OS, but it's not enough alone. I agree. * From the technical point of view there are several ways to get Sugar-the-OS running on tactile devices. Unfortunately it's not clear to me that any of these devices is open enough to be viable for deployments or ordinary users. We looked at ChromeOS a few years back, but at the time it was too heavy for our hardware. Today, it is a different story. Might be a viable option. Certainly running GNU/Linux/Sugar on a ChromeBook is not a bad starting point. Given that ChromeOS is locked down I don't believe it's viable to ask a School to have to break/hack the HW to get it working OOTB. Having been involved in the OLPC OS side of things I believe you would be much better taking the work done by OLPC with things like olpc-os-builder and the work upstream with Fedora to use it to build out OS images that will work in a similar way across both XOs and other HW be it x86 netbook or cheap ARM devices rather than reinventing the wheel! Peter -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Sugar oversight board meeting
On Tue, Nov 5, 2013 at 8:40 AM, Daniel Narvaez dwnarv...@gmail.com wrote: Going a bit off topic, but a pretty major issue I see in our workflow with Fedora is that we don't have a good way to develop unstable Sugar on a stable Fedora. Rawhide is, or at least is perceived as, unstable. And I'm not sure what would be a good way to, for example, produce and distribute 0.100 rpms for Fedora 19. We can setup our custom automated build system and repository of course, but I'm not sure that's a good approach? Part of the problem here is that upstream tends to depend strongly on very recent libraries which are not yet available in the stable fedora, though maybe now that the gi conversion is over we can avoid that. I think it is doable. The more difficult part is getting the Fedora bits to run properly on the XO hardware -- something OLPC had spent lots of time on. So while I think we can make Fedora releases -- and probably should -- they probably won't do much good directly for our major user community. -walter On Tuesday, 5 November 2013, Peter Robinson wrote: On Tue, Nov 5, 2013 at 2:14 AM, Walter Bender walter.ben...@gmail.com wrote: On Mon, Nov 4, 2013 at 7:42 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On 4 November 2013 22:53, Sean DALY sdaly...@gmail.com wrote: * It's not clear to me where we are going. The OLPC/Sugar development ecosystem seems to be at a crossroads. I am encouraged by the web activity work, but don't understand the path of transposing the value proposition of Sugar (interface, Journal, collaboration, Activities) to handheld tactile devices (tablets to smartphones). PCs (of any size) with keyboards are no longer competitive with tablets for grade-school classroom use. Perhaps the XO-4 could still be in the running; there is no clear message from OLPC. I'll try to express briefly my feelings about the directions the project could take. Note that I might be missing a lot of what is going on above the technical level. * The XO is not a viable hardware platform other than for existing deployments. OLPC is pretty clearly going in a different direction. I may be alone in thinking that there will be some runway left with the XO. But deployments need alternatives regardless. * Sugar web activities on the top of a full Android loses too much of the Sugar value proposition. It's great to have it in addition to Sugar-the-OS, but it's not enough alone. I agree. * From the technical point of view there are several ways to get Sugar-the-OS running on tactile devices. Unfortunately it's not clear to me that any of these devices is open enough to be viable for deployments or ordinary users. We looked at ChromeOS a few years back, but at the time it was too heavy for our hardware. Today, it is a different story. Might be a viable option. Certainly running GNU/Linux/Sugar on a ChromeBook is not a bad starting point. Given that ChromeOS is locked down I don't believe it's viable to ask a School to have to break/hack the HW to get it working OOTB. Having been involved in the OLPC OS side of things I believe you would be much better taking the work done by OLPC with things like olpc-os-builder and the work upstream with Fedora to use it to build out OS images that will work in a similar way across both XOs and other HW be it x86 netbook or cheap ARM devices rather than reinventing the wheel! Peter -- Daniel Narvaez -- 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 oversight board meeting
Yeah, my target here is development and testing, not final users. Basically I'm talking about what Gonzalo has been doing for 0.100. We could automate that work, it just feels a bit wrong to me because it's not using the normal Fedora infrastructure... On Tuesday, 5 November 2013, Walter Bender wrote: On Tue, Nov 5, 2013 at 8:40 AM, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: Going a bit off topic, but a pretty major issue I see in our workflow with Fedora is that we don't have a good way to develop unstable Sugar on a stable Fedora. Rawhide is, or at least is perceived as, unstable. And I'm not sure what would be a good way to, for example, produce and distribute 0.100 rpms for Fedora 19. We can setup our custom automated build system and repository of course, but I'm not sure that's a good approach? Part of the problem here is that upstream tends to depend strongly on very recent libraries which are not yet available in the stable fedora, though maybe now that the gi conversion is over we can avoid that. I think it is doable. The more difficult part is getting the Fedora bits to run properly on the XO hardware -- something OLPC had spent lots of time on. So while I think we can make Fedora releases -- and probably should -- they probably won't do much good directly for our major user community. -walter On Tuesday, 5 November 2013, Peter Robinson wrote: On Tue, Nov 5, 2013 at 2:14 AM, Walter Bender walter.ben...@gmail.comjavascript:; wrote: On Mon, Nov 4, 2013 at 7:42 PM, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: On 4 November 2013 22:53, Sean DALY sdaly...@gmail.comjavascript:; wrote: * It's not clear to me where we are going. The OLPC/Sugar development ecosystem seems to be at a crossroads. I am encouraged by the web activity work, but don't understand the path of transposing the value proposition of Sugar (interface, Journal, collaboration, Activities) to handheld tactile devices (tablets to smartphones). PCs (of any size) with keyboards are no longer competitive with tablets for grade-school classroom use. Perhaps the XO-4 could still be in the running; there is no clear message from OLPC. I'll try to express briefly my feelings about the directions the project could take. Note that I might be missing a lot of what is going on above the technical level. * The XO is not a viable hardware platform other than for existing deployments. OLPC is pretty clearly going in a different direction. I may be alone in thinking that there will be some runway left with the XO. But deployments need alternatives regardless. * Sugar web activities on the top of a full Android loses too much of the Sugar value proposition. It's great to have it in addition to Sugar-the-OS, but it's not enough alone. I agree. * From the technical point of view there are several ways to get Sugar-the-OS running on tactile devices. Unfortunately it's not clear to me that any of these devices is open enough to be viable for deployments or ordinary users. We looked at ChromeOS a few years back, but at the time it was too heavy for our hardware. Today, it is a different story. Might be a viable option. Certainly running GNU/Linux/Sugar on a ChromeBook is not a bad starting point. Given that ChromeOS is locked down I don't believe it's viable to ask a School to have to break/hack the HW to get it working OOTB. Having been involved in the OLPC OS side of things I believe you would be much better taking the work done by OLPC with things like olpc-os-builder and the work upstream with Fedora to use it to build out OS images that will work in a similar way across both XOs and other HW be it x86 netbook or cheap ARM devices rather than reinventing the wheel! Peter -- Daniel Narvaez -- Walter Bender Sugar Labs http://www.sugarlabs.org -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Sugar oversight board meeting
On Tue, Nov 5, 2013 at 1:40 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Going a bit off topic, but a pretty major issue I see in our workflow with Fedora is that we don't have a good way to develop unstable Sugar on a stable Fedora. Rawhide is, or at least is perceived as, unstable. And I'm not sure what would be a good way to, for example, produce and distribute 0.100 rpms for Fedora 19. We can setup our custom automated build system and repository of course, but I'm not sure that's a good approach? Part of the problem here is that upstream tends to depend strongly on very recent libraries which are not yet available in the stable fedora, though maybe now that the gi conversion is over we can avoid that. Actually a lot of that will be solved perfectly with COPR (similar in style to Ubuntu PPA) which is being worked upon at the moment and it should solve all the problems you see by enabling newer versions to be built for older releases while maintaining the stable shipped release in mainline. Peter On Tuesday, 5 November 2013, Peter Robinson wrote: On Tue, Nov 5, 2013 at 2:14 AM, Walter Bender walter.ben...@gmail.com wrote: On Mon, Nov 4, 2013 at 7:42 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On 4 November 2013 22:53, Sean DALY sdaly...@gmail.com wrote: * It's not clear to me where we are going. The OLPC/Sugar development ecosystem seems to be at a crossroads. I am encouraged by the web activity work, but don't understand the path of transposing the value proposition of Sugar (interface, Journal, collaboration, Activities) to handheld tactile devices (tablets to smartphones). PCs (of any size) with keyboards are no longer competitive with tablets for grade-school classroom use. Perhaps the XO-4 could still be in the running; there is no clear message from OLPC. I'll try to express briefly my feelings about the directions the project could take. Note that I might be missing a lot of what is going on above the technical level. * The XO is not a viable hardware platform other than for existing deployments. OLPC is pretty clearly going in a different direction. I may be alone in thinking that there will be some runway left with the XO. But deployments need alternatives regardless. * Sugar web activities on the top of a full Android loses too much of the Sugar value proposition. It's great to have it in addition to Sugar-the-OS, but it's not enough alone. I agree. * From the technical point of view there are several ways to get Sugar-the-OS running on tactile devices. Unfortunately it's not clear to me that any of these devices is open enough to be viable for deployments or ordinary users. We looked at ChromeOS a few years back, but at the time it was too heavy for our hardware. Today, it is a different story. Might be a viable option. Certainly running GNU/Linux/Sugar on a ChromeBook is not a bad starting point. Given that ChromeOS is locked down I don't believe it's viable to ask a School to have to break/hack the HW to get it working OOTB. Having been involved in the OLPC OS side of things I believe you would be much better taking the work done by OLPC with things like olpc-os-builder and the work upstream with Fedora to use it to build out OS images that will work in a similar way across both XOs and other HW be it x86 netbook or cheap ARM devices rather than reinventing the wheel! Peter -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Sugar oversight board meeting
My humble opinion (please stick to one): To put into perspective the opinion, I should remember that besides developing for sugar since 2009, I am also a teacher in high school, so I've been inside ceibal classrooms during this time. From the beginning, I said I saw the fate of sugar linked to the xo, the one without the other does not seem to make sense. Now, OLPC xo 4 and manufactures their away strip. For those who did the port to gtk3 last year, and we have also had to deal with the problems of arm processors, etc.. . ., We do not easily see how much time is lost in these strategic decisions while it ignores the feedback from deployments. I think this whole issue of android and html5, is a very grave mistake, probably the last. But hey, I'm just a teacher, probably the only one in this list. 2013/11/5 Daniel Narvaez dwnarv...@gmail.com Oh, awesome, COPR seems to be exactly what we need. On Tuesday, 5 November 2013, Peter Robinson wrote: On Tue, Nov 5, 2013 at 1:40 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Going a bit off topic, but a pretty major issue I see in our workflow with Fedora is that we don't have a good way to develop unstable Sugar on a stable Fedora. Rawhide is, or at least is perceived as, unstable. And I'm not sure what would be a good way to, for example, produce and distribute 0.100 rpms for Fedora 19. We can setup our custom automated build system and repository of course, but I'm not sure that's a good approach? Part of the problem here is that upstream tends to depend strongly on very recent libraries which are not yet available in the stable fedora, though maybe now that the gi conversion is over we can avoid that. Actually a lot of that will be solved perfectly with COPR (similar in style to Ubuntu PPA) which is being worked upon at the moment and it should solve all the problems you see by enabling newer versions to be built for older releases while maintaining the stable shipped release in mainline. Peter On Tuesday, 5 November 2013, Peter Robinson wrote: On Tue, Nov 5, 2013 at 2:14 AM, Walter Bender walter.ben...@gmail.com wrote: On Mon, Nov 4, 2013 at 7:42 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On 4 November 2013 22:53, Sean DALY sdaly...@gmail.com wrote: * It's not clear to me where we are going. The OLPC/Sugar development ecosystem seems to be at a crossroads. I am encouraged by the web activity work, but don't understand the path of transposing the value proposition of Sugar (interface, Journal, collaboration, Activities) to handheld tactile devices (tablets to smartphones). PCs (of any size) with keyboards are no longer competitive with tablets for grade-school classroom use. Perhaps the XO-4 could still be in the running; there is no clear message from OLPC. I'll try to express briefly my feelings about the directions the project could take. Note that I might be missing a lot of what is going on above the technical level. * The XO is not a viable hardware platform other than for existing deployments. OLPC is pretty clearly going in a different direction. I may be alone in thinking that there will be some runway left with the XO. But deployments need alternatives regardless. * Sugar web activities on the top of a full Android loses too much of the Sugar value proposition. It's great to have it in addition to Sugar-the-OS, but it's not enough alone. I agree. * From the technical point of view there are several ways to get Sugar-the-OS running on tactile devices. Unfortunately it's not clear to me that any of these devices is open enough to be viable for deployments or ordinary users. We looked at ChromeOS a few years back, but at the time it was too heavy for our hardware. Today, it is a different story. Might be a viable option. Certainly running GNU/Linux/Sugar on a ChromeBook is not a bad starting point. Given that ChromeOS is locked down I don't believe it's viable to ask a School to have to break/hack the HW to get it working OOTB. Having been involved in the OLPC OS side of things I believe you would be much better taking the work done by OLPC with things like olpc-os-builder and the work upstream with Fedora to use it to build out OS images that will work in a similar way across both XOs and other HW be it x86 netbook or cheap ARM devices rather than reinventing the wheel! Peter -- Daniel Narvaez -- Daniel Narvaez ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Sugar oversight board meeting
On Tue, Nov 5, 2013 at 1:44 PM, Flavio Danesse fdane...@gmail.com wrote: My humble opinion (please stick to one): To put into perspective the opinion, I should remember that besides developing for sugar since 2009, I am also a teacher in high school, so I've been inside ceibal classrooms during this time. From the beginning, I said I saw the fate of sugar linked to the xo, the one without the other does not seem to make sense. Now, OLPC xo 4 and manufactures their away strip. For those who did the port to gtk3 last year, and we have also had to deal with the problems of arm processors, etc.. . ., We do not easily see how much time is lost in these strategic decisions while it ignores the feedback from deployments. I think this whole issue of android and html5, is a very grave mistake, probably the last. Flavio, Can you expand on your opinion on HTML5 and Android? i am very interested. I am a teacher, but not as fortunate as you. I teach college and graduate level students. By that time I get them, the damage is somewhat irreversible :-( Sameer But hey, I'm just a teacher, probably the only one in this list. 2013/11/5 Daniel Narvaez dwnarv...@gmail.com Oh, awesome, COPR seems to be exactly what we need. On Tuesday, 5 November 2013, Peter Robinson wrote: On Tue, Nov 5, 2013 at 1:40 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Going a bit off topic, but a pretty major issue I see in our workflow with Fedora is that we don't have a good way to develop unstable Sugar on a stable Fedora. Rawhide is, or at least is perceived as, unstable. And I'm not sure what would be a good way to, for example, produce and distribute 0.100 rpms for Fedora 19. We can setup our custom automated build system and repository of course, but I'm not sure that's a good approach? Part of the problem here is that upstream tends to depend strongly on very recent libraries which are not yet available in the stable fedora, though maybe now that the gi conversion is over we can avoid that. Actually a lot of that will be solved perfectly with COPR (similar in style to Ubuntu PPA) which is being worked upon at the moment and it should solve all the problems you see by enabling newer versions to be built for older releases while maintaining the stable shipped release in mainline. Peter On Tuesday, 5 November 2013, Peter Robinson wrote: On Tue, Nov 5, 2013 at 2:14 AM, Walter Bender walter.ben...@gmail.com wrote: On Mon, Nov 4, 2013 at 7:42 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On 4 November 2013 22:53, Sean DALY sdaly...@gmail.com wrote: * It's not clear to me where we are going. The OLPC/Sugar development ecosystem seems to be at a crossroads. I am encouraged by the web activity work, but don't understand the path of transposing the value proposition of Sugar (interface, Journal, collaboration, Activities) to handheld tactile devices (tablets to smartphones). PCs (of any size) with keyboards are no longer competitive with tablets for grade-school classroom use. Perhaps the XO-4 could still be in the running; there is no clear message from OLPC. I'll try to express briefly my feelings about the directions the project could take. Note that I might be missing a lot of what is going on above the technical level. * The XO is not a viable hardware platform other than for existing deployments. OLPC is pretty clearly going in a different direction. I may be alone in thinking that there will be some runway left with the XO. But deployments need alternatives regardless. * Sugar web activities on the top of a full Android loses too much of the Sugar value proposition. It's great to have it in addition to Sugar-the-OS, but it's not enough alone. I agree. * From the technical point of view there are several ways to get Sugar-the-OS running on tactile devices. Unfortunately it's not clear to me that any of these devices is open enough to be viable for deployments or ordinary users. We looked at ChromeOS a few years back, but at the time it was too heavy for our hardware. Today, it is a different story. Might be a viable option. Certainly running GNU/Linux/Sugar on a ChromeBook is not a bad starting point. Given that ChromeOS is locked down I don't believe it's viable to ask a School to have to break/hack the HW to get it working OOTB. Having been involved in the OLPC OS side of things I believe you would be much better taking the work done by OLPC with things like olpc-os-builder and the work upstream with Fedora to use it to build out OS images that will work in a similar way across both XOs and other HW be it x86 netbook or cheap ARM devices rather than reinventing the wheel! Peter -- Daniel Narvaez -- Daniel Narvaez
Re: [IAEP] [Sugar-devel] Sugar oversight board meeting
On Tue, Nov 5, 2013 at 4:44 PM, Flavio Danesse fdane...@gmail.com wrote: My humble opinion (please stick to one): To put into perspective the opinion, I should remember that besides developing for sugar since 2009, I am also a teacher in high school, so I've been inside ceibal classrooms during this time. From the beginning, I said I saw the fate of sugar linked to the xo, the one without the other does not seem to make sense. Now, OLPC xo 4 and manufactures their away strip. For those who did the port to gtk3 last year, and we have also had to deal with the problems of arm processors, etc.. . ., We do not easily see how much time is lost in these strategic decisions while it ignores the feedback from deployments. Just to set the record straight, Ceibal was very supportive of the push to ARM. That doesn't mean it was the correct decision. But it suggests that OLPC was not ignoring feedback from deployments regarding that issue. As far as GTK3, the only feedback I heard was after the fact from Peru that it had adverse performance impact on XO 1. This decision was made publicly by Sugar Labs for at least two reasons: touch support and future-proofing. GTK2 is no longer supported. I think this whole issue of android and html5, is a very grave mistake, probably the last. I would be interested in hearing more on this topic. But hey, I'm just a teacher, probably the only one in this list. 2013/11/5 Daniel Narvaez dwnarv...@gmail.com Oh, awesome, COPR seems to be exactly what we need. On Tuesday, 5 November 2013, Peter Robinson wrote: On Tue, Nov 5, 2013 at 1:40 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Going a bit off topic, but a pretty major issue I see in our workflow with Fedora is that we don't have a good way to develop unstable Sugar on a stable Fedora. Rawhide is, or at least is perceived as, unstable. And I'm not sure what would be a good way to, for example, produce and distribute 0.100 rpms for Fedora 19. We can setup our custom automated build system and repository of course, but I'm not sure that's a good approach? Part of the problem here is that upstream tends to depend strongly on very recent libraries which are not yet available in the stable fedora, though maybe now that the gi conversion is over we can avoid that. Actually a lot of that will be solved perfectly with COPR (similar in style to Ubuntu PPA) which is being worked upon at the moment and it should solve all the problems you see by enabling newer versions to be built for older releases while maintaining the stable shipped release in mainline. Peter On Tuesday, 5 November 2013, Peter Robinson wrote: On Tue, Nov 5, 2013 at 2:14 AM, Walter Bender walter.ben...@gmail.com wrote: On Mon, Nov 4, 2013 at 7:42 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On 4 November 2013 22:53, Sean DALY sdaly...@gmail.com wrote: * It's not clear to me where we are going. The OLPC/Sugar development ecosystem seems to be at a crossroads. I am encouraged by the web activity work, but don't understand the path of transposing the value proposition of Sugar (interface, Journal, collaboration, Activities) to handheld tactile devices (tablets to smartphones). PCs (of any size) with keyboards are no longer competitive with tablets for grade-school classroom use. Perhaps the XO-4 could still be in the running; there is no clear message from OLPC. I'll try to express briefly my feelings about the directions the project could take. Note that I might be missing a lot of what is going on above the technical level. * The XO is not a viable hardware platform other than for existing deployments. OLPC is pretty clearly going in a different direction. I may be alone in thinking that there will be some runway left with the XO. But deployments need alternatives regardless. * Sugar web activities on the top of a full Android loses too much of the Sugar value proposition. It's great to have it in addition to Sugar-the-OS, but it's not enough alone. I agree. * From the technical point of view there are several ways to get Sugar-the-OS running on tactile devices. Unfortunately it's not clear to me that any of these devices is open enough to be viable for deployments or ordinary users. We looked at ChromeOS a few years back, but at the time it was too heavy for our hardware. Today, it is a different story. Might be a viable option. Certainly running GNU/Linux/Sugar on a ChromeBook is not a bad starting point. Given that ChromeOS is locked down I don't believe it's viable to ask a School to have to break/hack the HW to get it working OOTB. Having been involved in the OLPC OS side of things I believe you would be much better taking the work done by OLPC with things like olpc-os-builder and the work upstream with Fedora
Re: [IAEP] Sugar oversight board meeting
Hi Flavio,
I'm not sure what you are flagging as a mistake exactly, there is quite a
bit of confusion around android and html5, it means very different things
to different people. So it would be good if you could clarify.
And I'm not sure what you are proposing. Certainly everyone in this thread
would be glad if the XO development continued as usual, but that's not what
seems to be happening, independently from our will.
I'm seeing a lot of educators vs developers rhetoric lately and I don't
think it's useful. It would be better if we focused on improving the
communication channels. Feedback is not taken in account because it's not
heard, most of the time.
I'm just a volunteer trying to help out, one of the many on this list :)
On Tuesday, 5 November 2013, Flavio Danesse wrote:
My humble opinion (please stick to one):
To put into perspective the opinion, I should remember that besides
developing for sugar since 2009, I am also a teacher in high school, so
I've been inside ceibal classrooms during this time.
From the beginning, I said I saw the fate of sugar linked to the xo, the
one without the other does not seem to make sense. Now, OLPC xo 4 and
manufactures their away strip.
For those who did the port to gtk3 last year, and we have also had to deal
with the problems of arm processors, etc.. . ., We do not easily see how
much time is lost in these strategic decisions while it ignores the
feedback from deployments.
I think this whole issue of android and html5, is a very grave mistake,
probably the last.
But hey, I'm just a teacher, probably the only one in this list.
2013/11/5 Daniel Narvaez dwnarv...@gmail.com javascript:_e({}, 'cvml',
'dwnarv...@gmail.com');
Oh, awesome, COPR seems to be exactly what we need.
On Tuesday, 5 November 2013, Peter Robinson wrote:
On Tue, Nov 5, 2013 at 1:40 PM, Daniel Narvaez dwnarv...@gmail.com
wrote:
Going a bit off topic, but a pretty major issue I see in our workflow
with
Fedora is that we don't have a good way to develop unstable Sugar on a
stable Fedora. Rawhide is, or at least is perceived as, unstable. And
I'm
not sure what would be a good way to, for example, produce and
distribute
0.100 rpms for Fedora 19. We can setup our custom automated build
system and
repository of course, but I'm not sure that's a good approach? Part of
the
problem here is that upstream tends to depend strongly on very recent
libraries which are not yet available in the stable fedora, though
maybe now
that the gi conversion is over we can avoid that.
Actually a lot of that will be solved perfectly with COPR (similar in
style to Ubuntu PPA) which is being worked upon at the moment and it
should solve all the problems you see by enabling newer versions to be
built for older releases while maintaining the stable shipped release
in mainline.
Peter
On Tuesday, 5 November 2013, Peter Robinson wrote:
On Tue, Nov 5, 2013 at 2:14 AM, Walter Bender walter.ben...@gmail.com
wrote:
On Mon, Nov 4, 2013 at 7:42 PM, Daniel Narvaez dwnarv...@gmail.com
wrote:
On 4 November 2013 22:53, Sean DALY sdaly...@gmail.com wrote:
* It's not clear to me where we are going. The OLPC/Sugar
development
ecosystem seems to be at a crossroads. I am encouraged by the web
activity
work, but don't understand the path of transposing the value
proposition of
Sugar (interface, Journal, collaboration, Activities) to handheld
tactile
devices (tablets to smartphones). PCs (of any size) with keyboards
are
no
longer competitive with tablets for grade-school classroom use.
Perhaps the
XO-4 could still be in the running; there is no clear message from
OLPC.
I'll try to express briefly my feelings about the directions the
project
could take. Note that I might be missing a lot of what is going on
above the
technical level.
* The XO is not a viable hardware platform other than for existing
deployments. OLPC is pretty clearly going in a different direction.
I may be alone in thinking that there will be some runway left with
the XO. But deployments need alternatives regardless.
* Sugar web activities on the top of a full Android loses too much
of
the
Sugar value proposition. It's great to have it in addition to
Sugar-the-OS,
but it's not enough alone.
I agree.
* From the technical point of view there are several ways to get
Sugar-the-OS running on tactile devices. Unfortunately it's not
clear
to me
that any of these devices is open enough to be viable for
deployments
or
ordinary users.
We looked at ChromeOS a few years back, but at the time it was too
heavy for our hardware. Today, it is a different story. Might be a
viable option. Certainly running GNU/Linux/Sugar on a ChromeBook is
not a bad starting point.
Given that ChromeOS is locked down I don't believe it's viable to ask
a School to have to
