Re: OLPC 10.1.2 Release Candidate 1
On Mon, Aug 9, 2010 at 02:16, James Cameron qu...@laptop.org wrote: On Sun, Aug 08, 2010 at 09:41:32AM -0700, Yioryos Asprobounitis wrote: Wifi disappearing after switching back and forth from sugar to gnome. I've not tried to track down the original problem report that you are referring to, but Sugar and GNOME manage connection to an access point without reference to each other, so switching between the desktop environments will certainly cause one of the following: 1. loss of association and then reassociation within about 35 seconds, (because NetworkManager is told to disconnect as one desktop wraps up, and then told to connect as the other desktop starts up), 2. loss of association and no reassociation (the other desktop hasn't been told to trust the access point). Just a heads up that this is in its way to be fixed for NM 0.9 (and we'll need to adapt to API changes again): http://live.gnome.org/NetworkManager/RemovingUserSettings Regards, Tomeu This happened to me too and I thought was an issue with the olpc-update I did at the time. I then clean installed and since then works fine but something must be there. My guess is that you weren't aware of the separate storage for trusted or known access points. Once you've selected an access point in both desktops, it will appear to work as you expect. This is a Sugar enhancement request. http://bugs.sugarlabs.org/ticket/1884 (use system settings instead of user settings for NetworkManager) -- James Cameron http://quozl.linux.org.au/ ___ olpc mailing list o...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/olpc ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Killing activities when memory gets short
On 09.08.2010, at 01:21, John Gilmore wrote: As long as activities are saving and restoring properly it could be made pretty much transparent to the user. Of course that's easier said then done... Android has a whole mechanism for this: http://blog.rlove.org/2010/04/why-ipad-and-iphone-dont-support.html That explains the problem, but doesn't explain the Android answer to it, which is here: http://developer.android.com/guide/topics/fundamentals.html The section Component Lifecycles gives the summary. They call each app's onPause() method when it is obscured from visibility on the screen, and that method is responsible for recording everything the app needs to restart itself and get back to the same screen display (what file it was working on, how far down the file it was, etc). Then, any process whose onPause() method has been called is considered a cache, and can be killed without warning by the kernel. (I'm not advocating using this system -- I've only barely been exposed to it. But it's useful to see how others have solved the problem you're facing, before making your own solutions.) Sugar has a similar mechanism. From the Low-level Activity API docs: org.laptop.Activity.SetActive(b: active) Activate or passivate an activity. This is sent when switching activities, there is only one active activity at a time, all others are passive. A passive activity must immediately release resources like sound, camera etc. Also it should prepare for being killed without warning at any time in the future (see OOM) by auto-saving to the datastore. The issue is that it's hard to estimate how many Sugar activities actually do this, because until now they usually have not been killed (*). Might be an interesting test - just randomly kill activities from Terminal and see if they resume correctly ... Maybe good activities could volunteer to be shut down first. Or bad activities would have to beg to live a little longer. Might just take an entry in the activity.info file. - Bert - (*) Apple seems to have foreseen this developer psychology issue and actually killed all apps in the first three iterations of its iOS. So apps had to implement this state saving if the user was to be able to continue after leaving an app. Would be interesting to know how many Android apps actually implement it. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Killing activities when memory gets short
On 9 August 2010 11:25, Bert Freudenberg b...@freudenbergs.de wrote: On 09.08.2010, at 01:21, John Gilmore wrote: As long as activities are saving and restoring properly it could be made pretty much transparent to the user. Of course that's easier said then done... Android has a whole mechanism for this: http://blog.rlove.org/2010/04/why-ipad-and-iphone-dont-support.html That explains the problem, but doesn't explain the Android answer to it, which is here: http://developer.android.com/guide/topics/fundamentals.html The section Component Lifecycles gives the summary. They call each app's onPause() method when it is obscured from visibility on the screen, and that method is responsible for recording everything the app needs to restart itself and get back to the same screen display (what file it was working on, how far down the file it was, etc). Then, any process whose onPause() method has been called is considered a cache, and can be killed without warning by the kernel. (I'm not advocating using this system -- I've only barely been exposed to it. But it's useful to see how others have solved the problem you're facing, before making your own solutions.) Sugar has a similar mechanism. From the Low-level Activity API docs: org.laptop.Activity.SetActive(b: active) Activate or passivate an activity. This is sent when switching activities, there is only one active activity at a time, all others are passive. A passive activity must immediately release resources like sound, camera etc. Also it should prepare for being killed without warning at any time in the future (see OOM) by auto-saving to the datastore. The issue is that it's hard to estimate how many Sugar activities actually do this, because until now they usually have not been killed (*). Might be an interesting test - just randomly kill activities from Terminal and see if they resume correctly ... Maybe good activities could volunteer to be shut down first. Or bad activities would have to beg to live a little longer. Might just take an entry in the activity.info file. - Bert - (*) Apple seems to have foreseen this developer psychology issue and actually killed all apps in the first three iterations of its iOS. So apps had to implement this state saving if the user was to be able to continue after leaving an app. Would be interesting to know how many Android apps actually implement it. On Android, all (good) apps always save their state. There may be some bad ones, but all the ones I've used do it properly. Since apps are made out of activities (views) connected by intents, all the activities in an app save state. When starting an app, the main activity decides what to show (saved or new state) or it can switch to another activity that was active when the app was killed. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Killing activities when memory gets short
Sugar has a similar mechanism. From the Low-level Activity API docs: org.laptop.Activity.SetActive(b: active) Activate or passivate an activity. This is sent when switching activities, there is only one active activity at a time, all others are passive. A passive activity must immediately release resources like sound, camera etc. Also it should prepare for being killed without warning at any time in the future (see OOM) by auto-saving to the datastore. The issue is that it's hard to estimate how many Sugar activities actually do this, because until now they usually have not been killed (*). Might be an interesting test - just randomly kill activities from Terminal and see if they resume correctly ... Maybe good activities could volunteer to be shut down first. Or bad activities would have to beg to live a little longer. Might just take an entry in the activity.info file. It will not work, because the application startup time is horrible on the XO. The Dalvik VM goes a lng way to have fast application startup and to share most of the memory among applications (the Zygote process does this). Actually that was the exact thing I tried to do with the Python VM. Just at the exact time when I started to hack Python I have seen the Google I/O video about the Dalvik VM and thought that duplicating that work would have been a waste of time. So if you wanna fix the Python VM, good luck, but you know it is already been coded... :) Without fast activity startup, killing activities will be a horrible user experience. Maybe not that bad as a totally unresponsive XO though. (*) Apple seems to have foreseen this developer psychology issue and actually killed all apps in the first three iterations of its iOS. So apps had to implement this state saving if the user was to be able to continue after leaving an app. Would be interesting to know how many Android apps actually implement it. All of them. If an Android application does not implement it correctly then there will be big problems while switching apps and while navigating among application screens. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Killing activities when memory gets short
On 9 August 2010 14:44, NoiseEHC noise...@freemail.hu wrote: Sugar has a similar mechanism. From the Low-level Activity API docs: org.laptop.Activity.SetActive(b: active) Activate or passivate an activity. This is sent when switching activities, there is only one active activity at a time, all others are passive. A passive activity must immediately release resources like sound, camera etc. Also it should prepare for being killed without warning at any time in the future (see OOM) by auto-saving to the datastore. The issue is that it's hard to estimate how many Sugar activities actually do this, because until now they usually have not been killed (*). Might be an interesting test - just randomly kill activities from Terminal and see if they resume correctly ... Maybe good activities could volunteer to be shut down first. Or bad activities would have to beg to live a little longer. Might just take an entry in the activity.info file. It will not work, because the application startup time is horrible on the XO. The Dalvik VM goes a lng way to have fast application startup and to share most of the memory among applications (the Zygote process does this). Actually that was the exact thing I tried to do with the Python VM. Just at the exact time when I started to hack Python I have seen the Google I/O video about the Dalvik VM and thought that duplicating that work would have been a waste of time. So if you wanna fix the Python VM, good luck, but you know it is already been coded... :) Without fast activity startup, killing activities will be a horrible user experience. Maybe not that bad as a totally unresponsive XO though. It wouldn't be a duplication of efforts since Dalvik does not run Python and it is unlikely that it ever will. Perhaps a simple fork zygote for python wouldn't be that hard to accomplish in the sugar shell. (*) Apple seems to have foreseen this developer psychology issue and actually killed all apps in the first three iterations of its iOS. So apps had to implement this state saving if the user was to be able to continue after leaving an app. Would be interesting to know how many Android apps actually implement it. All of them. If an Android application does not implement it correctly then there will be big problems while switching apps and while navigating among application screens. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: cairo has now 16bit surfaces (was Fwd: rendering-cleanup)
El Sat, 07-08-2010 a las 12:14 -0400, Bernie Innocenti escribió: El Sat, 07-08-2010 a las 11:25 +0200, Tomeu Vizoso escribió: I'd expect well-written code to call cairo_surface_create_similar() whenever possible, but there might be hot-spots in our software stack that assume 32bpp. Have given a look to gtk+ and the xlib backend of cairo and seems to me that we are safe. We just need Maltose to come quickly to XO-1 :) ... or backport the new cairo to Fedora 11. The Cairo ABI is supposed to be 100% backwards compatible, and I've successfully rebuilt 1.8 with no issues. Building cairo-1.9.14 and pixman-0.18 went smooth on Fedora 11. They also seem to work fine on the XO. However, I did not notice any visible improvement. In case someone wants to try it out and run some benchmarks, I've uploaded the rpms here: http://people.sugarlabs.org/bernie/olpc/cairo-1.9/ -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Killing activities when memory gets short
On Mon, Aug 9, 2010 at 15:47, Lucian Branescu lucian.brane...@gmail.com wrote: On 9 August 2010 14:44, NoiseEHC noise...@freemail.hu wrote: Sugar has a similar mechanism. From the Low-level Activity API docs: org.laptop.Activity.SetActive(b: active) Activate or passivate an activity. This is sent when switching activities, there is only one active activity at a time, all others are passive. A passive activity must immediately release resources like sound, camera etc. Also it should prepare for being killed without warning at any time in the future (see OOM) by auto-saving to the datastore. The issue is that it's hard to estimate how many Sugar activities actually do this, because until now they usually have not been killed (*). Might be an interesting test - just randomly kill activities from Terminal and see if they resume correctly ... Maybe good activities could volunteer to be shut down first. Or bad activities would have to beg to live a little longer. Might just take an entry in the activity.info file. It will not work, because the application startup time is horrible on the XO. The Dalvik VM goes a lng way to have fast application startup and to share most of the memory among applications (the Zygote process does this). Actually that was the exact thing I tried to do with the Python VM. Just at the exact time when I started to hack Python I have seen the Google I/O video about the Dalvik VM and thought that duplicating that work would have been a waste of time. So if you wanna fix the Python VM, good luck, but you know it is already been coded... :) Without fast activity startup, killing activities will be a horrible user experience. Maybe not that bad as a totally unresponsive XO though. It wouldn't be a duplication of efforts since Dalvik does not run Python and it is unlikely that it ever will. Perhaps a simple fork zygote for python wouldn't be that hard to accomplish in the sugar shell. We used to do that, the problem is that we don't control our platform as Google controls Android and you need to make sure that resources that need to be specific of each child process aren't shared (dbus and X connections, etc). I'm personally more interested in reducing the amount of resources we need to start activities (which is quite insane right now), but sharing more of those resources sounds like a good idea to me. Regards, Tomeu (*) Apple seems to have foreseen this developer psychology issue and actually killed all apps in the first three iterations of its iOS. So apps had to implement this state saving if the user was to be able to continue after leaving an app. Would be interesting to know how many Android apps actually implement it. All of them. If an Android application does not implement it correctly then there will be big problems while switching apps and while navigating among application screens. ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable
On Mon, Aug 9, 2010 at 12:46 AM, Neil Graham l...@screamingduck.com wrote: Perhaps what is needed is a KDE to olpc's gnome in order to lift the game of both. We do a ton of things in relationship with our 'community' (or perhaps our different 'communities'). For example, we engage in this thread with you. As with most projects, it's up to you to help, participate positively, or not. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable (was: Re: OLPC 10.1.2 Release Candidate 1)
On Sun, Aug 8, 2010 at 5:09 PM, Christoph Derndorfer christoph.derndor...@gmail.com wrote: I know I'm repeating myself here but I find the attitude expressed in these instructions and particularly point 3 troublesome and a continued source of frustration for me as well as other people I've talked to. Even more so I think it's a very clear symptom of the much-discussed disconnect between developers and end-users in the OLPC and Sugar Labs context. Not really. There is a lot of glue people that can help bridge the gap between teachers / nontechie deployers and developers. I am one of them. I am sure you are one too. Deployments need to have a (small) technical team that also fits this role. Such bridge people are needed to boil down end users' reports into something that looks like a usable bugreport. Being a bridge person, a translator between the two worlds is sometimes frustrating (can't these people talk to eachother directly?) but the barriers are real. Rejoice in being able to do it (at least I do). And sure -- we need to get more hands (ears/eyes) into this role. It is essential social glue. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] Plans for a new xs release?
On Mon, Aug 9, 2010 at 11:29 PM, Bernie Innocenti ber...@codewiz.orgwrote: Martin, I was wondering if there are any plans to rebase the schoolserver onto a more recent version of Fedora. We seem to have stability and performance issues with ejabberd bundled with the XS 0.5. Probably also on 0.6, since it's also based on Fedora 9. I've also been running ejabberd on Karmic for a while. Stability has been good for me, but it remains an arcane and hard to manage piece of software. Robert McQueen today proposed switching from ejabberd to Prosody, which supposedly has a more active and helpful upstream. For more info, see http://prosody.im/ . Thoughts? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Server-devel mailing list server-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devehttp://lists.laptop.org/listinfo/server-devel I was also wondering if there would be new releases. Heard that the new XS is going to be based on CentOS. We're still using the F9 based version. Regards,* Abhishek Singh* System Engineer Open Learning Exchange (OLE) Nepal ___ Server-devel mailing list server-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
ip route in rc.sysinit
Hi all, I have a script that execute ip route to get the default gateway. If I run the script when sugar has started works fine, but, I need to run it during boot. I added a line in rc.sysinit calling it, but ip route doesn't prints any data. I tried to add the line in /etc/rc (like I used to in F9-0.82) and it neither prints the route. Any idea? cheers, Esteban. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Dextrose] ip route in rc.sysinit
El Mon, 09-08-2010 a las 16:33 -0300, Esteban Bordon escribió: Hi all, I have a script that execute ip route to get the default gateway. If I run the script when sugar has started works fine, but, I need to run it during boot. I added a line in rc.sysinit calling it, but ip route doesn't prints any data. I tried to add the line in /etc/rc (like I used to in F9-0.82) and it neither prints the route. Any idea? NetworkManager starts after rc.sysinit and remains quiescent until Sugar tells it to connect. So I'm not surprised you don't get any route during boot. I wonder how it could possibly have worked in F9-0.82... -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Dextrose] ip route in rc.sysinit
If I call the script in rc.local (after NetworkManager starts), could I force to activate NetworkManager? Esteban Bordón Investigación y Desarrollo - Plan Ceibal CITS - Av. Italia 6201 - Montevideo, Uruguay 2010/8/9 Bernie Innocenti ber...@codewiz.org El Mon, 09-08-2010 a las 16:33 -0300, Esteban Bordon escribió: Hi all, I have a script that execute ip route to get the default gateway. If I run the script when sugar has started works fine, but, I need to run it during boot. I added a line in rc.sysinit calling it, but ip route doesn't prints any data. I tried to add the line in /etc/rc (like I used to in F9-0.82) and it neither prints the route. Any idea? NetworkManager starts after rc.sysinit and remains quiescent until Sugar tells it to connect. So I'm not surprised you don't get any route during boot. I wonder how it could possibly have worked in F9-0.82... -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable
On Mon, 2010-08-09 at 14:05 -0400, Martin Langhoff wrote: We do a ton of things in relationship with our 'community' (or perhaps our different 'communities'). For example, we engage in this thread with you. And yet, Developers on this list [olpc-devel] have complained when people have done that, because this is not the place for it. Of course, there isn't any other place for it. As with most projects, it's up to you to help, participate positively, or not. Indeed, and I have tried to do that. I really don't want to get combative here. This may come off as You guys all suck but what I want is for things to improve. I feel that every criticism seems to be responded with a counterattack. I would much prefer it if there were at least an acknowledgement of the frustration that people 'on the outside' are feeling. When you say it's up to you to help, participate positively, or not. it feels like the implication is that you think I should do more than just complain. That also makes it seem like I have been contributing in vain. I would also like to stress that it wasn't my intention to bring this up because I have found things hard. It's because so many of the people I have spoken to have felt the same frustration. I'm not a Python person, but a friend of mine who attended PyCon came back and said he was amazed with just how many people he met who felt burned by OLPC. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable
On Mon, Aug 9, 2010 at 4:17 PM, Neil Graham l...@screamingduck.com wrote: And yet, Developers on this list [olpc-devel] have complained when people have done that, because this is not the place for it. Of course, there isn't any other place for it. Don't take every complaint seriously ;-) I really don't want to get combative here. This may come off as You guys all suck but what I want is for things to improve. We all do. But we are damned swamped with things, and we do a ton with the community. You might not see it right now but we do. ... but a friend of mine who attended PyCon came back and said he was amazed with just how many people he met who felt burned by OLPC. Having been an external volunteer first, I can attest that it is hard to contribute to OLPC. A lot of that is because OLPC has chosen to do hard things. OLPC requires a lot of time investment. All the other open proects I know that have similarly hard goals are known to burn people out. Don't know if there's a fix for that overall problem :-/ Are there specific issues you are hoping for support with, what are they? cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ip route in rc.sysinit
On Mon, Aug 9, 2010 at 3:33 PM, Esteban Bordon ebor...@plan.ceibal.edu.uy wrote: I have a script that execute ip route to get the default gateway. If I run the script when sugar has started works fine, but, I need to run it during boot. Our initramfs does some network setup (w/o NM) and then tears it down. Later, networking is controlled by NM. I would suggest you use the early networking setup... or the other... cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Dextrose] ip route in rc.sysinit
El Mon, 09-08-2010 a las 16:33 -0300, Esteban Bordon escribió: Hi all, I have a script that execute ip route to get the default gateway. If I run the script when sugar has started works fine, but, I need to run it during boot. I added a line in rc.sysinit calling it, but ip route doesn't prints any data. I tried to add the line in /etc/rc (like I used to in F9-0.82) and it neither prints the route. Any idea? You can add a script to /etc/NetworkManager/dispatcher.d that will be run after NetworkManager brings up a connection. call it 00-default-route and make sure it is executable. Something like this will work. #!/bin/sh export LC_ALL=C if [ $2 = up ]; then /sbin/ip route add default via XXX.XXX.XXX.XXX dev $1 fi Hope that helps. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[Server-devel] Plans for a new xs release?
Martin, I was wondering if there are any plans to rebase the schoolserver onto a more recent version of Fedora. We seem to have stability and performance issues with ejabberd bundled with the XS 0.5. Probably also on 0.6, since it's also based on Fedora 9. I've also been running ejabberd on Karmic for a while. Stability has been good for me, but it remains an arcane and hard to manage piece of software. Robert McQueen today proposed switching from ejabberd to Prosody, which supposedly has a more active and helpful upstream. For more info, see http://prosody.im/ . Thoughts? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
