Re: [Sugar-devel] Sugar Digest 2009-06-15
On Mon, Jun 15, 2009 at 11:33 PM, NoiseEHCnoise...@freemail.hu wrote: The real deal is that Android will be pushed by all the carriers and ARM vendors. In my humble opinion it will be the dominant phone OS in the future with even more hardware support the good thing is that android is based on the linux kernel, so most of this hardware support will be available to every linux system; the only significant exception will probably be the graphics subsystem, where google's work will stop at the framebuffer, while a standard linux system may need X. (just try out the Android SDK, it is multi platform with an emulator). Jumping to this massive smartbook bandwagon could push the OLPC idea further without any hardware development. It is probably feasible to jump on the smartbook bandwagon even without a full port to Android: a proof of concept port of sugar to ARM is already available from the work of Bernie Innocenti in OpenEmbedded, and in my free time I'm trying to update it to 0.84; another (untested?) port is available in debian, where the sugar packages are built for every supported arch, including ARM and other embedded ones. Installing such systems on an android phone is generally feasible, requiring skills broadly comparable to those needed to jailbreak an iphone; of course deployment will need support / permission from whoever is going to sell the hardware, to be able to preinstall gnu/linux + sugar instead of the standard system. -- Elena ``of Valhalla'' homepage: http://www.trueelena.org email: elena.valha...@gmail.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Digest 2009-06-15
I think you do not get what is so special with Android. 1. They killed the braindamaged X driver model and put the driver where it belongs, the kernel. Just like Windows NT and OS-X already did. Finally it is fast and really supports hardware acceleration! Did I mention that it has redraw profiling tools? 2. Python is already available on Android: http://www.damonkohler.com/2008/12/python-on-android.html The porting is not about running Python Sugar on Android but to implement the parts missing from Android in java. a. Activities store their data into a per activity file area and an SQLite instance. A common data publishing interface should be defined. The Journal should became just an aggregation. b. There is no peer to peer networking. I should be written. 802.11s will be dropped in XO 1.5 anyway. c. There is no common document format defined to share data between activities. Work is already happening on this one. d. There is no printing support. Hmmm, I have heard this before. So IMHO the job would not be to port Python since the lame Python VM would be just as lame on ARM. If you really want to port things then here is the thing: http://arstechnica.com/open-source/news/2009/05/canonical-developers-aim-to-make-android-apps-run-on-ubuntu.ars Of course this is just the (easier) technical side. The people side is a totally different beast. Currently, as I see, both OLPC and Sugar developers spend a massive amount of time fighting platform problems when the solution is already available. This time could have been spent on learning activities. Desktop application compatibility does not exist on the XO so probably it would not be a deal breaker. The next big thing which will be reimplemented is touch screen support in XO-2. I hope that the result will be just as usable than the next Android GUI for smartbooks which will be tested for years by then. Of course it will not happen overnight but can it be that this is the most future proof investment? Is not the goal putting education into children's hand rather than reimplementing the desktop paradigm over and over again when there is an alternative backed by Google, the ARM vendors and millions of $? Elena of Valhalla wrote: On Mon, Jun 15, 2009 at 11:33 PM, NoiseEHCnoise...@freemail.hu wrote: The real deal is that Android will be pushed by all the carriers and ARM vendors. In my humble opinion it will be the dominant phone OS in the future with even more hardware support the good thing is that android is based on the linux kernel, so most of this hardware support will be available to every linux system; the only significant exception will probably be the graphics subsystem, where google's work will stop at the framebuffer, while a standard linux system may need X. (just try out the Android SDK, it is multi platform with an emulator). Jumping to this massive smartbook bandwagon could push the OLPC idea further without any hardware development. It is probably feasible to jump on the smartbook bandwagon even without a full port to Android: a proof of concept port of sugar to ARM is already available from the work of Bernie Innocenti in OpenEmbedded, and in my free time I'm trying to update it to 0.84; another (untested?) port is available in debian, where the sugar packages are built for every supported arch, including ARM and other embedded ones. Installing such systems on an android phone is generally feasible, requiring skills broadly comparable to those needed to jailbreak an iphone; of course deployment will need support / permission from whoever is going to sell the hardware, to be able to preinstall gnu/linux + sugar instead of the standard system. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Digest 2009-06-15
2009/6/16 NoiseEHC noise...@freemail.hu: I think you do not get what is so special with Android. 1. They killed the braindamaged X driver model and put the driver where it belongs, the kernel. Just like Windows NT and OS-X already did. Finally it is fast and really supports hardware acceleration! Did I mention that it has redraw profiling tools? 2. Python is already available on Android: http://www.damonkohler.com/2008/12/python-on-android.html The porting is not about running Python Sugar on Android but to implement the parts missing from Android in java. a. Activities store their data into a per activity file area and an SQLite instance. A common data publishing interface should be defined. The Journal should became just an aggregation. b. There is no peer to peer networking. I should be written. 802.11s will be dropped in XO 1.5 anyway. c. There is no common document format defined to share data between activities. Work is already happening on this one. d. There is no printing support. Hmmm, I have heard this before. So IMHO the job would not be to port Python since the lame Python VM would be just as lame on ARM. If you really want to port things then here is the thing: http://arstechnica.com/open-source/news/2009/05/canonical-developers-aim-to-make-android-apps-run-on-ubuntu.ars Of course this is just the (easier) technical side. The people side is a totally different beast. Currently, as I see, both OLPC and Sugar developers spend a massive amount of time fighting platform problems when the solution is already available. Please don't tell people what they should be working on. If you want to see something happen, get to work yourself. If developers are not participating in this discussion is because we have already shipped products and now about all the hidden costs that you are so happily jumping over. And of course, are busy making things happen instead of talking. Not saying that a great educational platform cannot be built on Android, just that this is obviously not the moment to be considering it when we have hundreds of thousands of people using the existing Sugar. Good luck with your new project, Tomeu This time could have been spent on learning activities. Desktop application compatibility does not exist on the XO so probably it would not be a deal breaker. The next big thing which will be reimplemented is touch screen support in XO-2. I hope that the result will be just as usable than the next Android GUI for smartbooks which will be tested for years by then. Of course it will not happen overnight but can it be that this is the most future proof investment? Is not the goal putting education into children's hand rather than reimplementing the desktop paradigm over and over again when there is an alternative backed by Google, the ARM vendors and millions of $? Elena of Valhalla wrote: On Mon, Jun 15, 2009 at 11:33 PM, NoiseEHCnoise...@freemail.hu wrote: The real deal is that Android will be pushed by all the carriers and ARM vendors. In my humble opinion it will be the dominant phone OS in the future with even more hardware support the good thing is that android is based on the linux kernel, so most of this hardware support will be available to every linux system; the only significant exception will probably be the graphics subsystem, where google's work will stop at the framebuffer, while a standard linux system may need X. (just try out the Android SDK, it is multi platform with an emulator). Jumping to this massive smartbook bandwagon could push the OLPC idea further without any hardware development. It is probably feasible to jump on the smartbook bandwagon even without a full port to Android: a proof of concept port of sugar to ARM is already available from the work of Bernie Innocenti in OpenEmbedded, and in my free time I'm trying to update it to 0.84; another (untested?) port is available in debian, where the sugar packages are built for every supported arch, including ARM and other embedded ones. Installing such systems on an android phone is generally feasible, requiring skills broadly comparable to those needed to jailbreak an iphone; of course deployment will need support / permission from whoever is going to sell the hardware, to be able to preinstall gnu/linux + sugar instead of the standard system. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Digest 2009-06-15
On Mon, Jun 15, 2009 at 10:10 AM, Walter Benderwalter.ben...@gmail.com wrote: ===Sugar Digest=== 1. It seems that once per month the computer vs. phone debate reemerges. This time, http://edutechdebate.org/ has taken up the theme. Wayan Vota posed the question: Mobile Phones: Better Learning Tools than Computers? Michael Trucano takes the affirmative position in his essay, http://edutechdebate.org/mobile-phones-and-computers/phones-are-a-real-alternative-to-computers/ while Robert B. Kozma argues that http://edutechdebate.org/mobile-phones-and-computers/computers-are-more-capable-than-mobile-phones/. The usual arguments of pervasiveness (phones) and capacity (computers) were made. We touched on a different set of themes when we discussed this topic versus, not [http://lists.sugarlabs.org/archive/iaep/2009-May/005484.html] back in May. We were responding in part to Mark Guzdial's blog: Does There's an App for That Hurt or Help Computing Education? [http://www.amazon.com/gp/blog/post/PLNK3F4TMBURELZZK]. At the time I said that I was optimistic about the role of phones in learning—a u-turn from my long-standing position. The arguments about the differences in affordances between phones and computer remain relevant: e.g., you wouldn't write an essay on your phone if you have a computer at hand; and as Kozma points out, the large installed base of phones is not composed primarily of the latest iPhone on a 3G network. The current installed base has much less capacity. But that will change over time. My disregard of phones for learning had been based on my fear that phone culture was turning us into a society of consumers of those services that Ma Bell chose for us. But the iPhone and the Android are changing that. The meme that is rapidly becoming part of our culture is that phones are programmable, i.e., computers. This is a huge step forward. There is merit in Guzdial's argument that the Apple marketing pitch discourages end-users from becoming active participants in the creative process—we must be vigilant in combating this trend. But now that the phone company's model of phone as a service is eroding, there is reason for optimism that the corresponding model of learning as a service will also wane. The end of restrictions on who can develop what for whom is an important cultural development that will have an overall positive impact on learning, regardless of the platform. Sugar, which is designed for a relatively lightweight environments, will become more significant to learners. +1. Technologically the phone and the computer are quickly converging. They are just coming at the problem from different points of view. Phones focus on power consumption and size. Netbooks focus on screen size and general use computing. If the new ARM technology is as good inside devices as it is on paper the convergence is going to happen sooner than many of us expect it. david 2. [http://nexcopy.com Nexcopy] has generously donated a USB replicator to Sugar Labs. It will be a great help in our various Sugar-on-a-Stick pilot programs this summer. ===Help Wanted=== 3. Hamilton Chua has written some patches to enable SoaS images to register with School Servers, thus enabling backup and restore. The patch is described in http://dev.sugarlabs.org/ticket/916. Please try to test it. 4. Lionel Laske reports that OLPC France has launch a French FLOSS Manual Sprint and a large part of the work has been completed. They are now looking for help with Help. Lionel asks, is there a way to do quickly a “one shot” build of the Help Activity in French (and other languages)? 5. Samy Boutayeb is seeking input on digital media [http://lists.laptop.org/pipermail/olpc-mg/2009-June/000169.html] for the OLPC/Sugar pilot in Madagascar. 6. David Van Assche published [http://www.nubae.com/collaboration-session-sugar-june10 a report] from the collaboration-testing session that took place last week (10 June 10). Please leave your comments, especially those who took part. We plan to continue testing again on Wednesday, 17 June, at 20:00 UTC, irc.freenode.org, channel #sugar-collaboration. ===In the community=== 7. Coming up next week: Sugar at http://linuxtag.org (24–27 June in Berlin). 8. Also, Sugar at http://www.fossed.com/ in Bethel, Maine, 24–26 June. 9. And Sugar at[http://center.uoregon.edu/ISTE/NECC2009/ in Washington DC, 28 June–1 July. 10. The OLPC Learning CLub, DC, is hosting a Family XO Mesh Meetup [http://olpclearningclub.org/meetings/june-meeting-the-brightest-light-in-the-library/] Saturday, 20 June from 10 AM to 1 PM. ===Tech Talk=== 11. I modified Mitchel Charity's Ruler activity [http://activities.sugarlabs.org/en-US/sugar/addon/4192] to look up the screen resolution so that it would render properly on non-OLPC-XO displays. I'm parsing xdpyinfo, which may not be the most reliable way to get the display resolution; feedback from testers would be
Re: [Sugar-devel] Sugar Digest 2009-06-15
Technologically the phone and the computer are quickly converging. They are just coming at the problem from different points of view. Phones focus on power consumption and size. Netbooks focus on screen size and general use computing. If the new ARM technology is as good inside devices as it is on paper the convergence is going to happen sooner than many of us expect it. If you look at the Nvidia Tegra video made by Charbax then it is clear that it will converge next year. Google and the ARM companies pushed millions of $ into quick web browsing and hardware accelerated video and flash (something even Bryan Berry defines as the future of educational software development). Android implements the following things (the next version will support smartbooks): 1. Its Dalvik VM works in very limited resource environments. It is something Negroponte talked about but nothing happened (with Python memory comsumption), Google did not talk about it just fixed it. 2. The applications are separated like in Rainbow. OLPC will even loose Rainbow with the transitioning to stock Fedora. 3. There is an usable programming environment targeting Android. I can debug programs from Eclipse running on Windows!!! 4. All the activities on Android can be used by the cursor keys only (so they ARE easy to handle). Something Sugar lacks even now. 5. There is a massive army of programmers targeting Android. It is only my really humble opinion, but could that be that probably the most sane way would be porting the relevant parts of Sugar to the Android platform and ditching the rest? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Digest 2009-06-15
My major concern against porting to Android is that Java is a horrible language, even with the nice Android libs. Google have said that they will add more languages, though. A more long term solution would be using PyPy, since it has significantly lower memory usage and better optimisation prospects. Switching to PyBank for bindings should also help. 2009/6/15 NoiseEHC noise...@freemail.hu: Technologically the phone and the computer are quickly converging. They are just coming at the problem from different points of view. Phones focus on power consumption and size. Netbooks focus on screen size and general use computing. If the new ARM technology is as good inside devices as it is on paper the convergence is going to happen sooner than many of us expect it. If you look at the Nvidia Tegra video made by Charbax then it is clear that it will converge next year. Google and the ARM companies pushed millions of $ into quick web browsing and hardware accelerated video and flash (something even Bryan Berry defines as the future of educational software development). Android implements the following things (the next version will support smartbooks): 1. Its Dalvik VM works in very limited resource environments. It is something Negroponte talked about but nothing happened (with Python memory comsumption), Google did not talk about it just fixed it. 2. The applications are separated like in Rainbow. OLPC will even loose Rainbow with the transitioning to stock Fedora. 3. There is an usable programming environment targeting Android. I can debug programs from Eclipse running on Windows!!! 4. All the activities on Android can be used by the cursor keys only (so they ARE easy to handle). Something Sugar lacks even now. 5. There is a massive army of programmers targeting Android. It is only my really humble opinion, but could that be that probably the most sane way would be porting the relevant parts of Sugar to the Android platform and ditching the rest? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Digest 2009-06-15
My major concern against porting to Android is that Java is a horrible language, even with the nice Android libs. Google have said that they will add more languages, though. Yes, java sucks. IMHO it does not matter though since mostly activities consists of 1000 lines of code. A more long term solution would be using PyPy, since it has significantly lower memory usage and better optimisation prospects. Switching to PyBank for bindings should also help. Or retargeting Python to the DEX format. The real deal is that Android will be pushed by all the carriers and ARM vendors. In my humble opinion it will be the dominant phone OS in the future with even more hardware support (just try out the Android SDK, it is multi platform with an emulator). Jumping to this massive smartbook bandwagon could push the OLPC idea further without any hardware development. ps: If you did not see the video then the current plan is to sell those smartbooks for 0$ via G3 phone carrier subsidy. It can became a HUGE market. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Digest 2009-06-15
2009/6/15 NoiseEHC noise...@freemail.hu: My major concern against porting to Android is that Java is a horrible language, even with the nice Android libs. Google have said that they will add more languages, though. Yes, java sucks. IMHO it does not matter though since mostly activities consists of 1000 lines of code. A more long term solution would be using PyPy, since it has significantly lower memory usage and better optimisation prospects. Switching to PyBank for bindings should also help. Or retargeting Python to the DEX format. There is a project doing a bit of that, http://code.google.com/p/jythonroid/ Jython just got a new compiler though, it should be possible to retarget it. Google seems to love Python, maybe they will help? Perhaps OLPC could get them to at least say whether they're working on it? The real deal is that Android will be pushed by all the carriers and ARM vendors. In my humble opinion it will be the dominant phone OS in the future with even more hardware support (just try out the Android SDK, it is multi platform with an emulator). Jumping to this massive smartbook bandwagon could push the OLPC idea further without any hardware development. ps: If you did not see the video then the current plan is to sell those smartbooks for 0$ via G3 phone carrier subsidy. It can became a HUGE market. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Digest 2009-06-15
There is a project doing a bit of that, http://code.google.com/p/jythonroid/ Jython just got a new compiler though, it should be possible to retarget it. Google seems to love Python, maybe they will help? Perhaps OLPC could get them to at least say whether they're working on it? http://code.google.com/p/unladen-swallow/ It is Google's Python plan. Unfortunately it is not about reducing memory consumption, it is for servers. The problem with the Sugar path is that it has no hardware vendor backing. Android has. The new 1.5 XO makes the memory pressure bearable with 1G of memory just it also has no hardware vendor backing (in the sense of at least 10 million units per year category). ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Digest 2009-06-15
2009/6/15 NoiseEHC noise...@freemail.hu: There is a project doing a bit of that, http://code.google.com/p/jythonroid/ Jython just got a new compiler though, it should be possible to retarget it. Google seems to love Python, maybe they will help? Perhaps OLPC could get them to at least say whether they're working on it? http://code.google.com/p/unladen-swallow/ It is Google's Python plan. Unfortunately it is not about reducing memory consumption, it is for servers. The problem with the Sugar path is that it has no hardware vendor backing. Android has. The new 1.5 XO makes the memory pressure bearable with 1G of memory just it also has no hardware vendor backing (in the sense of at least 10 million units per year category). I meant Python on Android. In the short term, PyBank should help. In the very long term, PyPy would be an interesting option, but bindings are still a problem. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
