Re: [Sugar-devel] Killing activities when memory gets short
On 8 Aug 2010, at 01:37, Marco Pesenti Gritti ma...@marcopg.org wrote: On 7 Aug 2010, at 21:08, Tiago Marques tiago...@gmail.com wrote: Just killing a random activity is a terrible idea becayse you don't want your product behaving like it's defective; the pop up idea is way more acceptable(and a lot better than having the system randomly behaving like it's crashed). Either way, this is the extremely important use of swap memory that doesn't exist here. I understand your engineering constraints on the hardware but randomly killing activities is poised to confuse users and cause people considering the hardware for deployment to think that you're selling them something defective/baddly manufactured. 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... +1, that would be an ideal solution. Minimal interface distinction between active and dormant activities; fast resume (perhaps some visual trickery using the thumbnail image to help cover any delay); improve activity UI state saving. --G Marco ___ 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: Killing activities when memory gets short
On Sat, Aug 7, 2010 at 22:08, Tiago Marques tiago...@gmail.com wrote: Hi all, On Sat, Aug 7, 2010 at 6:31 PM, Bernie Innocenti ber...@codewiz.org wrote: El Sat, 07-08-2010 a las 18:14 +0200, Tomeu Vizoso escribió: So we would have a periodic wakeup? The test would be the amount of free memory plus buffers and caches? A polled design is clearly inferior to a proper notification system, but it has the advantage of being simple and not requiring a particular kernel. Once this is done, switching to a better solution should not require extensive changes to the UI code. BTW, looking at top, it seems that Sugar and other processes wake up quite frequently when the system is supposed to be completely idle. It may be background checks for updates, NetworkManager updates or the presence service. Plus, there are a bunch of cron jobs that run in the background, inclding the ds-backup and olpc-update. All these things drain battery power and cause the UI to become jerky, so we should try to limit them if possible. Or, maybe, we could make this a manual process: pop up a notification when memory is short and ask which activity should be closed. I would just close one of the background activities, the LRU or the biggest one. +1. Just killing a random activity is a terrible idea becayse you don't want your product behaving like it's defective; the pop up idea is way more acceptable(and a lot better than having the system randomly behaving like it's crashed). Either way, this is the extremely important use of swap memory that doesn't exist here. I understand your engineering constraints on the hardware but randomly killing activities is poised to confuse users and cause people considering the hardware for deployment to think that you're selling them something defective/baddly manufactured. I tihnk I have been sloppy with my words, so let me clarify two things: - killing processes should be done only to avoid OOM (because currently the kernel kills the wrong thing most of the time). - before the need for killing arises, we can do a myriad of things to prepare the user for what is coming and maybe to avoid it (some good ideas have already been posted in this thread). Regards, Tomeu Best regards, Tiago Marques This, however, makes non-sugarized activities more dangerous to deal with. One more reason to demand proper sugarization. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity packaging
On Wed, 04 Aug 2010 20:05:06 +0100, pbrobin...@gmail.com wrote: On Tue, Jul 6, 2010 at 5:02 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: On 07/06/2010 11:51 AM, Bernie Innocenti wrote: Ok, I think the requirements for activity bundles could be: 1) Support multiple CPU architectures 2) Support multiple distros (and different versions of same distro) 3) Centralized build cluster (submit one source package, get multiple binary packages) 4) Support inter-bundle dependencies (e.g.: GCompris + voices, OOo4Kids + dictionaries) 5) Support activity - OS dependencies (e.g.: espeak for Speak, squeak for etoys...) 6) Work with any programming language (setup.py is python-centric) 7) Easy to learn for activity writers without too much distro-hacking experience These requirements would fit well both rpm and deb, with OpenSUSE Build Service or their native build clusters. I think you are missing an important requirement: installation without elevated permissions. PackageKit can already do that. There was a furore around 6 months ago when someone enabled it by default for Fedora. I think that's a little different. Fedora allowed an unprivileged user to install a package, but giving the package full privileges. For 0sugar, I assume, the user is fully privileged (it's their machine); it's the package that should be restricted, not the user. This distinction has caused a lot of confusion in the past, and I've now added a section to http://0install.net/injector-security.html to try and clarify it. I've also added a demonstration of using 0install for sandboxing, showing how sandboxed processes can still share libraries (which doesn't happen if you just create lots of separate RPM databases): http://0install.net/ebox.html Hope that helps, -- Dr Thomas Leonard http://0install.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity packaging
On Wed, Aug 04, 2010 at 08:05:06PM +0100, pbrobin...@gmail.com wrote: On Tue, Jul 6, 2010 at 5:02 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: On 07/06/2010 11:51 AM, Bernie Innocenti wrote: Ok, I think the requirements for activity bundles could be: 1) Support multiple CPU architectures 2) Support multiple distros (and different versions of same distro) 3) Centralized build cluster (submit one source package, get multiple binary packages) 4) Support inter-bundle dependencies (e.g.: GCompris + voices, OOo4Kids + dictionaries) 5) Support activity - OS dependencies (e.g.: espeak for Speak, squeak for etoys...) 6) Work with any programming language (setup.py is python-centric) 7) Easy to learn for activity writers without too much distro-hacking experience These requirements would fit well both rpm and deb, with OpenSUSE Build Service or their native build clusters. I think you are missing an important requirement: installation without elevated permissions. PackageKit can already do that. There was a furore around 6 months ago when someone enabled it by default for Fedora. Thats right, and all PackageKit benefits will be reused within 0sugar/0install (but mostly for non-sugar dependencies, it will be possible to reuse native packages for sugar application as well but see below). But the one of core ideas to not use only regular packaging systems (via PackageKit or directly) is having this, natural and desired, scenario for sugar ecosystem: * there is an activity, * several users might decide to experiment w/ this activity (i.e. change its code) and share this results * third user wants to try all these experiments (including pristine activity) This scenario is pretty undoable (by design) in native packaging systems but 0install is designed to support scenarios like that (all activity implementation are stored in separate directories in user's home and can be launched in any time and even at the same time). -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Killing activities when memory gets short
On Sun, Aug 8, 2010 at 4:01 AM, Tomeu Vizoso to...@sugarlabs.org wrote: I tihnk I have been sloppy with my words, so let me clarify two things: - killing processes should be done only to avoid OOM (because currently the kernel kills the wrong thing most of the time). Can't we just _close it nicely_? I have extremely rarely seen a Sugar app not closing. Sugar shell can decide it's a good idea to close an activity because too many are open and system is under memory pressure. Sugar apps auto-save, so closing nicely should work very nicely... 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] Killing activities when memory gets short
On Sun, Aug 8, 2010 at 15:15, Martin Langhoff martin.langh...@gmail.com wrote: On Sun, Aug 8, 2010 at 4:01 AM, Tomeu Vizoso to...@sugarlabs.org wrote: I tihnk I have been sloppy with my words, so let me clarify two things: - killing processes should be done only to avoid OOM (because currently the kernel kills the wrong thing most of the time). Can't we just _close it nicely_? When you are about to get into OOM? Don't think so because it's very probable that the kernel will block or kill something randomly before the activity or the user react. But as I said, before we reach this point we should have given the activities and/or the user the option to avoid this situation. Regards, Tomeu I have extremely rarely seen a Sugar app not closing. Sugar shell can decide it's a good idea to close an activity because too many are open and system is under memory pressure. Sugar apps auto-save, so closing nicely should work very nicely... 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] Activity packaging
But the one of core ideas to not use only regular packaging systems (via PackageKit or directly) is having this, natural and desired, scenario for sugar ecosystem: * there is an activity, * several users might decide to experiment w/ this activity (i.e. change its code) and share this results * third user wants to try all these experiments (including pristine activity) This scenario is pretty undoable (by design) in native packaging systems but 0install is designed to support scenarios like that (all activity implementation are stored in separate directories in user's home and can be launched in any time and even at the same time). This doesn't sound like a package management system scenario. Really this sounds like a revision control system is needed. Wouldn't it make the most sense to integrate bzr or git into sugar to handle code sharing like this? Then you could continue to have all the Activities in a single directory with multiple branches to can be switched between on the fly through a sugar interface. -Jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity packaging
On Sun, Aug 08, 2010 at 07:18:51AM -0700, Jon Nettleton wrote: But the one of core ideas to not use only regular packaging systems (via PackageKit or directly) is having this, natural and desired, scenario for sugar ecosystem: * there is an activity, * several users might decide to experiment w/ this activity (i.e. change its code) and share this results * third user wants to try all these experiments (including pristine activity) This scenario is pretty undoable (by design) in native packaging systems but 0install is designed to support scenarios like that (all activity implementation are stored in separate directories in user's home and can be launched in any time and even at the same time). This doesn't sound like a package management system scenario. Really this sounds like a revision control system is needed. Wouldn't it make the most sense to integrate bzr or git into sugar to handle code sharing like this? Then you could continue to have all the Activities in a single directory with multiple branches to can be switched between on the fly through a sugar interface. Well, I thought also about vcs but came to decision that it sounds like misusing of vcs: * vcs is all about sources (storing binaries is possible but is misusing), * all sugar related code will be shared only in sources, which is not bad in general (especially as an option) but sounds overkill for binary-based activities * all dependencies should be stored in vcs and deployed via vcs as well (otherwise system should be not pure vcs and will look pretty ugly) Also there is no need in storing results of experiments in vcs at all, e.g., doer just tweaks his local code and let 0sugar share it w/o commiting to vcs server(which should be used to fetch sources on client side), supporting per doer vcs servers would sound pretty overkill. Some kind of binding vcs repos with packaging/distribution stuff is possible and afaik many GNU/Linux distribution do packaging from, e.g., git repos (we can do similar things on our OBS), but they don't mix vcs and distribution. -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Killing activities when memory gets short
On Sun, Aug 8, 2010 at 9:33 AM, Tomeu Vizoso to...@sugarlabs.org wrote: Can't we just _close it nicely_? When you are about to get into OOM? Early on so we avoid OOM for most cases. Right now our OOM use cases have nothing to do with misbehaved activities. Once you're in about to get into OOM, sugar-shell is unlikely to get many cycles (and python is a bad lang to try handling this). If you can seed the OOM scores of the process early on, you have a chance that OOM will kill a reasonably correct one. (Not sure what the state of play is with seeding the OOM scores from userland). point we should have given the activities and/or the user the option to avoid this situation. I think it's the only thing we can reasonably do. And [if possible], seed OOM scores. When things get tight, only the kernel has a standing chance to run code. 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] Killing activities when memory gets short
On Sun, Aug 8, 2010 at 8:42 AM, Martin Langhoff martin.langh...@gmail.com wrote: On Sun, Aug 8, 2010 at 9:33 AM, Tomeu Vizoso to...@sugarlabs.org wrote: Can't we just _close it nicely_? When you are about to get into OOM? Early on so we avoid OOM for most cases. Right now our OOM use cases have nothing to do with misbehaved activities. Once you're in about to get into OOM, sugar-shell is unlikely to get many cycles (and python is a bad lang to try handling this). If you can seed the OOM scores of the process early on, you have a chance that OOM will kill a reasonably correct one. (Not sure what the state of play is with seeding the OOM scores from userland). point we should have given the activities and/or the user the option to avoid this situation. I think it's the only thing we can reasonably do. And [if possible], seed OOM scores. When things get tight, only the kernel has a standing chance to run code. Has anyone looked into the Android Low Memory Killer kernel patch? Google has already addressed this limitation with Android and done a relatively good job at it. Their stuff is fit to run in 128MB of memory which is much less than an XO has. Jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Killing activities when memory gets short
On Sun, Aug 8, 2010 at 11:42 AM, Martin Langhoff martin.langh...@gmail.com wrote: (Not sure what the state of play is with seeding the OOM scores from userland). http://linux-mm.org/OOM_Killer The pid of the activity should have its oomadj bumped up a bit -- so OOM knows to spare sugar-shell and friends... 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] Killing activities when memory gets short
On Sun, Aug 8, 2010 at 17:42, Martin Langhoff martin.langh...@gmail.com wrote: On Sun, Aug 8, 2010 at 9:33 AM, Tomeu Vizoso to...@sugarlabs.org wrote: Can't we just _close it nicely_? When you are about to get into OOM? Early on so we avoid OOM for most cases. Right now our OOM use cases have nothing to do with misbehaved activities. Once you're in about to get into OOM, sugar-shell is unlikely to get many cycles (and python is a bad lang to try handling this). If you can seed the OOM scores of the process early on, you have a chance that OOM will kill a reasonably correct one. (Not sure what the state of play is with seeding the OOM scores from userland). I tried to make clear before that by all means I think we should give the user and activities the chance to do what is best early on. point we should have given the activities and/or the user the option to avoid this situation. I think it's the only thing we can reasonably do. And [if possible], seed OOM scores. When things get tight, only the kernel has a standing chance to run code. Well, the shell would kill activities before we get that tight. But I agree that if if we can use OOM scores to have the kernel kill the less bad thing, that sounds better. Regards, Tomeu 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] Killing activities when memory gets short
Hi Tomeu, in general, I think we are saying the same thing :-) With one exception -- OOM happens because memory is allocated. Sugar-shell cannot (and I say should not) try to arbitrage in there. If we try to do it from sugar-shell, all we can do is poll. If we poll infrequently, we won't catch them, if we poll frequently, we'll burn battery, introduce random lags... and still not catch many. When the shell is in the bg, IMHO it should be as dormant as possible. There are some opportunities for the shell to step-in in a friendly manner -- activity open, activity switch, I propose that those events are a natural place; and if a delay happens there is not very disruptive for users. Between those events checking for low-mem and seeding the OOM killer to catch runaways, we'll have something. I don't know of there's a way to ask the OOM killer to run a process on a lower threshold -- or send a signal to an existing one, that'd make more sense :-) . If it does, we could have a tight C process listening there of OOM warnings and sending friendly close now plz dbus signals. 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] Activity packaging
On 8 Aug 2010, at 15:18, Jon Nettleton jon.nettle...@gmail.com wrote: But the one of core ideas to not use only regular packaging systems (via PackageKit or directly) is having this, natural and desired, scenario for sugar ecosystem: * there is an activity, * several users might decide to experiment w/ this activity (i.e. change its code) and share this results * third user wants to try all these experiments (including pristine activity) This scenario is pretty undoable (by design) in native packaging systems but 0install is designed to support scenarios like that (all activity implementation are stored in separate directories in user's home and can be launched in any time and even at the same time). This doesn't sound like a package management system scenario. Really this sounds like a revision control system is needed. Wouldn't it make the most sense to integrate bzr or git into sugar to handle code sharing like this? Then you could continue to have all the Activities in a single directory with multiple branches to can be switched between on the fly through a sugar interface. FWIW this is certainly the way I've worked on activities in Sugar for some time now, my ~/Activities is mainly git clones. --Gary -Jon ___ 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: [Sugar-devel] Killing activities when memory gets short
On Sun, Aug 8, 2010 at 18:11, Martin Langhoff martin.langh...@gmail.com wrote: Hi Tomeu, in general, I think we are saying the same thing :-) My impression as well. With one exception -- OOM happens because memory is allocated. Sugar-shell cannot (and I say should not) try to arbitrage in there. If we try to do it from sugar-shell, all we can do is poll. If we poll infrequently, we won't catch them, if we poll frequently, we'll burn battery, introduce random lags... and still not catch many. Well, we certainly should not poll, I started this thread because recent kernels have a mechanism for getting notified when a certain threshold of free memory is reached (see below). When the shell is in the bg, IMHO it should be as dormant as possible. Sounds a worthy goal. There are some opportunities for the shell to step-in in a friendly manner -- activity open, activity switch, I propose that those events are a natural place; and if a delay happens there is not very disruptive for users. Between those events checking for low-mem and seeding the OOM killer to catch runaways, we'll have something. Yeah, oomadj would be updated on activity open and switch if we go that way. I don't know of there's a way to ask the OOM killer to run a process on a lower threshold -- or send a signal to an existing one, that'd make more sense :-) . If it does, we could have a tight C process listening there of OOM warnings and sending friendly close now plz dbus signals. The kernel docs linked here mention such a mechanism: http://lists.sugarlabs.org/archive/sugar-devel/2010-August/025851.html Regards, Tomeu 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: OLPC 10.1.2 Release Candidate 1
--- On Thu, 8/5/10, Chris Ball c...@laptop.org wrote: From: Chris Ball c...@laptop.org Subject: OLPC 10.1.2 Release Candidate 1 To: Fedora OLPC fedora-olpc-l...@redhat.com Cc: test...@lists.laptop.org, Devel devel@lists.laptop.org Date: Thursday, August 5, 2010, 2:45 PM http://wiki.laptop.org/go/Release_notes/10.1.2 http://build.laptop.org/10.1.2/xo-1.5/os850 http://build.laptop.org/10.1.2/xo-1/os850 I do not know if anyone is monitoring http://www.olpcnews.com/forum/index.php?topic=4867 on os850 but so far we have: An issue with yum not working properly without swap for anything bigger than 10-15 MB. Notably crashes on yum update. This may worth looking at before final release. Wifi disappearing after switching back and forth from sugar to gnome. 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. Any pointers on how to identify possible issues in case it reappears? (instructions for the olpcnews.com/forum/ kind of people would be appreciated...:-) Is there (planned) printing support in 10.1.2 or latter. People trying to get it going apparently stumble upon Unable to set ACLs on root certificate '/var/run/cups/certs/0' - Operation Not Supported Thx ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Killing activities when memory gets short
On Sun, Aug 8, 2010 at 12:36 PM, Tomeu Vizoso to...@sugarlabs.org wrote: Well, we certainly should not poll, I started this thread because recent kernels have a mechanism for getting notified when a certain threshold of free memory is reached (see below). ... http://lists.sugarlabs.org/archive/sugar-devel/2010-August/025851.html u. apologies for wasting bandwidth. Over the course of the thread I missed that bit. Excellent info. thanks for your patience! 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] Killing activities when memory gets short
On Sun, Aug 8, 2010 at 2:33 PM, Tomeu Vizoso to...@sugarlabs.org wrote: On Sun, Aug 8, 2010 at 15:15, Martin Langhoff martin.langh...@gmail.com wrote: On Sun, Aug 8, 2010 at 4:01 AM, Tomeu Vizoso to...@sugarlabs.org wrote: I tihnk I have been sloppy with my words, so let me clarify two things: - killing processes should be done only to avoid OOM (because currently the kernel kills the wrong thing most of the time). Can't we just _close it nicely_? When you are about to get into OOM? Don't think so because it's very probable that the kernel will block or kill something randomly before the activity or the user react. But as I said, before we reach this point we should have given the activities and/or the user the option to avoid this situation. Not sure what the requirements would be of implementing something like iphone/ipod (well versions prior to 4) where when the Activity is backgrounded it saves its state and quits so you don't really have more than one app running at a time? Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Killing activities when memory gets short
Just killing a random activity is a terrible idea becayse you don't want your product behaving like it's defective; the pop up idea is way more acceptable(and a lot better than having the system randomly behaving like it's crashed). Either way, this is the extremely important use of swap memory that doesn't exist here. I understand your engineering constraints on the hardware but randomly killing activities is poised to confuse users and cause people considering the hardware for deployment to think that you're selling them something defective/baddly manufactured. I tihnk I have been sloppy with my words, so let me clarify two things: I read through the thread but may also missed something. - killing processes should be done only to avoid OOM (because currently the kernel kills the wrong thing most of the time). True. - before the need for killing arises, we can do a myriad of things to prepare the user for what is coming and maybe to avoid it (some good ideas have already been posted in this thread). The idea of killing activities with the content closed seems ok but it would probably be a good idea to have a way to opt out of it for some apps. I'm thinking a PDF that may be left open on purpose to serve as reference to something, a browser window, etc. Are you then proposing to use the LRU policy to do the killing? I'm thinking that a popup with a cancel tied to a timeout may be a good idea. Once it is not allowed to be killed, it should not try to again for the session, or at least for a very large increase in query time. Apps like instant messaging(though I don't recall one for Sugar), would definitely need a definitive opt out, no? Best regards, Tiago Regards, Tomeu Best regards, Tiago Marques This, however, makes non-sugarized activities more dangerous to deal with. One more reason to demand proper sugarization. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Killing activities when memory gets short
On 8 August 2010 20:33, Marco Pesenti Gritti ma...@marcopg.org wrote: On 8 Aug 2010, at 18:40, Tiago Marques tiago...@gmail.com wrote: The idea of killing activities with the content closed seems ok but it would probably be a good idea to have a way to opt out of it for some apps. I'm thinking a PDF that may be left open on purpose to serve as reference to something, a browser window, etc. An opt out could be easily abused... In the PDF case the activity could be closed and reopened under the hoods, without the user even noticing (well, startup time aside). Are you then proposing to use the LRU policy to do the killing? I'm thinking that a popup with a cancel tied to a timeout may be a good idea. Once it is not allowed to be killed, it should not try to again for the session, or at least for a very large increase in query time. Imo a confirmation popup would become annoying very quickly. Also if the user refuses, the kernel will have soon to kill an activity, which is worst. Activities already write_file when they lose focus, they could write_file periodically or at least when warned of low memory. Apps like instant messaging(though I don't recall one for Sugar), would definitely need a definitive opt out, no? Yeah, that's where things get tricky :/ Same issue with a background music player for example. Ideally we would just keep the connection open somehow and close the whole UI, but that's going to get complex. As long as this causes just minor annoyances to the user (like being disconnected or music stopping), I think it's probably something we don't need to solve in the first iteration. Separating the activity from the service would help here. In the case of music, MPD would use a lot less memory than one of its GUIs. Marco ___ 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: OLPC 10.1.2 Release Candidate 1
On Aug 8, 2010, at 12:41 PM, Yioryos Asprobounitis wrote: (instructions for the olpcnews.com/forum/ kind of people would be appreciated...:-) Instructions: 1. Report bugs at http://dev.laptop.org/newticket - if necessary, register first at http://dev.laptop.org/register (as mavrothal kindly points out) 2. If you have interesting experiences or user information to contribute, please do so at http://wiki.laptop.org 3. If you're unwilling to perform steps 1 and/or 2 as appropriate, please don't expect the bug to be fixed, or for anyone else to even know about it. Thanks. - Ed ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Killing activities when memory gets short
On 8 August 2010 20:51, Marco Pesenti Gritti ma...@marcopg.org wrote: On 8 Aug 2010, at 20:38, Lucian Branescu lucian.brane...@gmail.com wrote: Imo a confirmation popup would become annoying very quickly. Also if the user refuses, the kernel will have soon to kill an activity, which is worst. Activities already write_file when they lose focus, they could write_file periodically or at least when warned of low memory. Yes, that's how I think it should work. Of course activities will need to do a better work to save all the possible state, because we are closing without user intervention. Apps like instant messaging(though I don't recall one for Sugar), would definitely need a definitive opt out, no? Yeah, that's where things get tricky :/ Same issue with a background music player for example. Ideally we would just keep the connection open somehow and close the whole UI, but that's going to get complex. As long as this causes just minor annoyances to the user (like being disconnected or music stopping), I think it's probably something we don't need to solve in the first iteration. Separating the activity from the service would help here. In the case of music, MPD would use a lot less memory than one of its GUIs. Right, I was thinking to something along these lines too. I'm not sure how the shell would enforce this policy though. Maybe we could allow the activity processes to use a minimum amount of memory when it has been asked to close. As I said, it gets complicated :) An activity frontend to MPD could be killed following activity policy and the MPD daemon itself would be killed following regular daemon policy. Music would play after the activity dies and would only be stopped if the MPD daemon is killed (which is less likely since it uses very little memory). ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC 10.1.2 Release Candidate 1
--- On Sun, 8/8/10, Ed McNierney e...@laptop.org wrote: From: Ed McNierney e...@laptop.org Subject: Re: OLPC 10.1.2 Release Candidate 1 To: Yioryos Asprobounitis mavrot...@yahoo.com Cc: Fedora OLPC fedora-olpc-l...@redhat.com, Chris Ball c...@laptop.org, Devel devel@lists.laptop.org, test...@lists.laptop.org Date: Sunday, August 8, 2010, 3:56 PM On Aug 8, 2010, at 12:41 PM, Yioryos Asprobounitis wrote: (instructions for the olpcnews.com/forum/ kind of people would be appreciated...:-) Instructions: 1. Report bugs at http://dev.laptop.org/newticket - if necessary, register first at http://dev.laptop.org/register (as mavrothal kindly points out) 2. If you have interesting experiences or user information to contribute, please do so at http://wiki.laptop.org 3. If you're unwilling to perform steps 1 and/or 2 as appropriate, please don't expect the bug to be fixed, or for anyone else to even know about it. Well, I know due process I followed it several times and I also point it everywhere I can, however in this occasion we have the case: Hey, I got a problem, what should I do to get the info needed to file a proper ticket, and: Is this feature supported in the OS or not? Thus the questions. Answering outside a ticket should not be unthinkable, so if you have an answer I would be grateful. The bigger issue however is who has the greatest interest to produce a better build, the casual user that sees something strange and even mentions it somewhere or the developer? Dismissing/ignoring real issues because they are inappropriate formulated can only turn around and bite you in more than one ways, I believe. Thanks. - Ed ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Making OLPC / Sugar Labs more approachable (was: Re: OLPC 10.1.2 Release Candidate 1)
On Sun, Aug 8, 2010 at 3:56 PM, Ed McNierney e...@laptop.org wrote: Instructions: 1. Report bugs at http://dev.laptop.org/newticket - if necessary, register first at http://dev.laptop.org/register (as mavrothal kindly points out) 2. If you have interesting experiences or user information to contribute, please do so at http://wiki.laptop.org 3. If you're unwilling to perform steps 1 and/or 2 as appropriate, please don't expect the bug to be fixed, or for anyone else to even know about it. 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. The core here is that software developers seem very reluctant to step out of their own comfort zone when it comes to processes and tools (a.k.a. point 3 a.k.a. my way or the highway) yet consistently expect teachers and other XO and Sugar users to do exactly that. This leads to the current situation in which crucial information and feedback from these users does not make it back to developers and the broader community. Therefore rather than working on things that users need or need to work reliably (e.g. the Journal) resources are spent elsewhere. But that's all just basically a recap of the IRC discussion on #sugar earlier in the week and many hours of discussions with Bernie and others in Paraguay over the past 2 weeks. Now at this point I'd normally stop but seeing that I've been increasingly frustrated about this and have subsequently complained a lot about it I'll get off my ass and try something to improve the situation a bit. Over the next 6 weeks (can't make promises beyond that since university and my job will then start again) I plan to: (a) Contact people at deployments asking for their input as to whether they see a need for a closer feedback-loop between deployments and development (because maybe I'm seeing issues when in fact there are none). For this I'll rely on the people I know plus the contacts listed at http://wiki.sugarlabs.org/go/Deployment_Team/Places for starters but please send along any suggestions on who else to get in touch with. (b) If it turns out to be a need then ask for input as to how these needs could be best communicated so we can figure out an appropriate process. (c) Try to schedule some sort of meeting with several deployments, possibly as a continuation of the Sugar Labs deployment meetings on IRC or via a Skype call or something. In my mind the focus here should be input into what deployments would like to see development focus (more) on. (d) Compile all the resulting input into a readable format and distribute it where seen appropriate. Things I most likely won't do as part of these efforts include (but aren't necessarily limited to) setting up new mailman-lists, creating a new category on w.l.o or w.s.o and following wiki talk-pages, asking for a trac instance, learning to use git send-email, switching to Mutt, booting into Ubuntu instead of Windows 7, etc. ;-) As always, let me know what you think. Cheers, Christoph -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC 10.1.2 Release Candidate 1
Yioryos - You asked for instructions for the olpcnews.com/forum/ kind of people, and that's the information I provided. I wasn't dismissing or ignoring anything; if we widely disseminate those instructions and they are followed, bugs will be far less likely to be dismissed or ignored. But a bug no one knows about is 100% certain to be ignored. - Ed On Aug 8, 2010, at 5:06 PM, Yioryos Asprobounitis wrote: Well, I know due process I followed it several times and I also point it everywhere I can, however in this occasion we have the case: Hey, I got a problem, what should I do to get the info needed to file a proper ticket, and: Is this feature supported in the OS or not? Thus the questions. Answering outside a ticket should not be unthinkable, so if you have an answer I would be grateful. The bigger issue however is who has the greatest interest to produce a better build, the casual user that sees something strange and even mentions it somewhere or the developer? Dismissing/ignoring real issues because they are inappropriate formulated can only turn around and bite you in more than one ways, I believe. ___ 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: On Sun, Aug 8, 2010 at 3:56 PM, Ed McNierney e...@laptop.org wrote: Instructions: 1. Report bugs at http://dev.laptop.org/newticket - if necessary, register first at http://dev.laptop.org/register (as mavrothal kindly points out) 2. If you have interesting experiences or user information to contribute, please do so at http://wiki.laptop.org 3. If you're unwilling to perform steps 1 and/or 2 as appropriate, please don't expect the bug to be fixed, or for anyone else to even know about it. 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. The core here is that software developers seem very reluctant to step out of their own comfort zone when it comes to processes and tools (a.k.a. point 3 a.k.a. my way or the highway) yet consistently expect teachers and other XO and Sugar users to do exactly that. What was the context for Ed's post? And who was his intended audience? Certainly not the end user. In .uy we have discussed various mechanisms for bug reporting by children and teachers. The current plan of record is to use some sort of web form where the bugs are aggregated by a technical liaison. The liaison might then be trained in filing the occasional ticket on Trac. As with any software (and hardware) project, different people in the support hierarchy utilize different tools. -walter This leads to the current situation in which crucial information and feedback from these users does not make it back to developers and the broader community. Therefore rather than working on things that users need or need to work reliably (e.g. the Journal) resources are spent elsewhere. But that's all just basically a recap of the IRC discussion on #sugar earlier in the week and many hours of discussions with Bernie and others in Paraguay over the past 2 weeks. Now at this point I'd normally stop but seeing that I've been increasingly frustrated about this and have subsequently complained a lot about it I'll get off my ass and try something to improve the situation a bit. Over the next 6 weeks (can't make promises beyond that since university and my job will then start again) I plan to: (a) Contact people at deployments asking for their input as to whether they see a need for a closer feedback-loop between deployments and development (because maybe I'm seeing issues when in fact there are none). For this I'll rely on the people I know plus the contacts listed at http://wiki.sugarlabs.org/go/Deployment_Team/Places for starters but please send along any suggestions on who else to get in touch with. (b) If it turns out to be a need then ask for input as to how these needs could be best communicated so we can figure out an appropriate process. (c) Try to schedule some sort of meeting with several deployments, possibly as a continuation of the Sugar Labs deployment meetings on IRC or via a Skype call or something. In my mind the focus here should be input into what deployments would like to see development focus (more) on. (d) Compile all the resulting input into a readable format and distribute it where seen appropriate. Things I most likely won't do as part of these efforts include (but aren't necessarily limited to) setting up new mailman-lists, creating a new category on w.l.o or w.s.o and following wiki talk-pages, asking for a trac instance, learning to use git send-email, switching to Mutt, booting into Ubuntu instead of Windows 7, etc. ;-) As always, let me know what you think. Cheers, Christoph -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ 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 9 August 2010 09:09, Christoph Derndorfer christoph.derndor...@gmail.com wrote: On Sun, Aug 8, 2010 at 3:56 PM, Ed McNierney e...@laptop.org wrote: Instructions: 1. Report bugs at http://dev.laptop.org/newticket - if necessary, register first at http://dev.laptop.org/register (as mavrothal kindly points out) 2. If you have interesting experiences or user information to contribute, please do so at http://wiki.laptop.org 3. If you're unwilling to perform steps 1 and/or 2 as appropriate, please don't expect the bug to be fixed, or for anyone else to even know about it. 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. The core here is that software developers seem very reluctant to step out of their own comfort zone when it comes to processes and tools (a.k.a. point 3 a.k.a. my way or the highway) yet consistently expect teachers and other XO and Sugar users to do exactly that. I'm not sure of the wider context here, but in general I think it's entirely appropriate to expect that people asking for help do so via the correct channels. It's also appropriate for OLPC Sugar to set realistic expectations. Placing the burden on the user may be the only way to understand what's going wrong with the software. That said, the OLPC/Sugar communities should be very good at guiding new contributors to those channels. Perhaps OLPC/Sugar could create a super simple web form for problem submissions. They would then be triaged (by support gang?) and sent to the correct ticker. That way, new contributions only have a single channel for everything. This leads to the current situation in which crucial information and feedback from these users does not make it back to developers and the broader community. Therefore rather than working on things that users need or need to work reliably (e.g. the Journal) resources are spent elsewhere. This is not the only reasons why the development of pieces of Sugar moves very slowly. The datastore is a complex piece of software engineering. I have no idea how it works and don't think I'll ever able to understand it without someone next to me explaining its operation. The real problem for me, even if I wanted to help with the Journal, is that there is nearly no code documentation through Sugar's core. I find it very difficult to justify spending a few hours learning how a module operates when I want to fix a bug. Yet, this is the situation I face every time. An associated problem for me is that I don't know if my code will break things. AFAIK , there are no unit tests in Sugar's code base. Sugar is actually quite hard to test. Secondly, many of the functions methods are not designed with (unit) testing in mind, meaning it's hard to retrospectively create tests for methods. Testing side effects is annoying. Even if unit testing was integrated into Sugar's development, it's really tough to set up development test environments. sugar-jhbuild has never built correctly for me. Looking through compiler errors trying to identify what's wrong makes me feel like an idiot. The reason I don't look into the hard problems is not that I don't know they exist. It's that they're hard to even start looking into. Tim ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Making OLPC / Sugar Labs more approachable (was: Re: OLPC 10.1.2 Release Candidate 1)
Christoph - (you're talking about OLPC and SugarLabs, of course, but I'm only responding from an OLPC perspective) There's a difference between approachable and findable. Every member of the OLPC technical staff is on the de...@laptop.org mailing list, and we all see bugs filed in trac. I expect all of us to pay attention to both those channels. I think we're all pretty approachable, and we try to be as findable as possible. We do not all read OLPCNews, nor do I expect OLPC's technical staff to cruise OLPCNews' forums in search of bug reports. I do not count proactively search for places people mention the word OLPC online as being findable. I answered a specific question about how the olpcnews.com/forum/ kind of people should report problems. It is in fact the same information mavrothal pointed out in the forum. Maybe that's not a good answer, but other than mavrothal and I, I haven't seen another answer to that question. As to your main topics, I would *love* it if we could all agree on a standard nomenclature for what we call deployments, because they're not all the same. OLPC has, I think, I pretty darn good feedback loop with the entities we consider deployments. But a lot of people use that term to mean a lot of different things - every time more than two XO laptops are in one place (or perhaps when there are two SoaS machines), it's a deployment to someone. There's nothing wrong with that, but when you then say there's a problem with getting input from deployments, it's hard to understand exactly what you mean. Particularly with volunteer-led or -driven deployments, it can be hard for anyone at OLPC to know what's going on. In your discussions with various teams, it would be great if you could emphasize the value of having a stable, findable, long-term technical contact that someone at OLPC knows about. That's a big help to us in any situation. More help is always welcome, although while you're doing all those things, please consider registering on trac and try filing one ticket. It's really not hard, and if the problem at hand is an apparent software/hardware bug, that's the best way to communicate it. - Ed P.S. I just saw Walter's reply, and things in Uruguay do indeed seem to work well. Those sorts of processes are what's needed in large deployments. On Aug 8, 2010, at 5:09 PM, Christoph Derndorfer wrote: On Sun, Aug 8, 2010 at 3:56 PM, Ed McNierney e...@laptop.org wrote: Instructions: 1. Report bugs at http://dev.laptop.org/newticket - if necessary, register first at http://dev.laptop.org/register (as mavrothal kindly points out) 2. If you have interesting experiences or user information to contribute, please do so at http://wiki.laptop.org 3. If you're unwilling to perform steps 1 and/or 2 as appropriate, please don't expect the bug to be fixed, or for anyone else to even know about it. 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. The core here is that software developers seem very reluctant to step out of their own comfort zone when it comes to processes and tools (a.k.a. point 3 a.k.a. my way or the highway) yet consistently expect teachers and other XO and Sugar users to do exactly that. This leads to the current situation in which crucial information and feedback from these users does not make it back to developers and the broader community. Therefore rather than working on things that users need or need to work reliably (e.g. the Journal) resources are spent elsewhere. But that's all just basically a recap of the IRC discussion on #sugar earlier in the week and many hours of discussions with Bernie and others in Paraguay over the past 2 weeks. Now at this point I'd normally stop but seeing that I've been increasingly frustrated about this and have subsequently complained a lot about it I'll get off my ass and try something to improve the situation a bit. Over the next 6 weeks (can't make promises beyond that since university and my job will then start again) I plan to: (a) Contact people at deployments asking for their input as to whether they see a need for a closer feedback-loop between deployments and development (because maybe I'm seeing issues when in fact there are none). For this I'll rely on the people I know plus the contacts listed at http://wiki.sugarlabs.org/go/Deployment_Team/Places for starters but please send along any suggestions on who else to get in touch with. (b) If it turns out to be a need then ask for input as to how these needs could be best communicated so we can figure out an appropriate process. (c) Try to schedule
Re: OLPC 10.1.2 Release Candidate 1
So if you please go back to the original mail and answer any question you think you can so tickets can be filed. No, no reflexes - the only other question in that email I can answer immediately is, no, there is planned printing support in 10.1.2 or later. I have not heard of anyone interested in working on it, either. - Ed ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC 10.1.2 Release Candidate 1
--- On Sun, 8/8/10, Ed McNierney e...@laptop.org wrote: From: Ed McNierney e...@laptop.org Subject: Re: OLPC 10.1.2 Release Candidate 1 To: Yioryos Asprobounitis mavrot...@yahoo.com Cc: Fedora OLPC fedora-olpc-l...@redhat.com, Chris Ball c...@laptop.org, Devel devel@lists.laptop.org, test...@lists.laptop.org Date: Sunday, August 8, 2010, 5:27 PM Yioryos - You asked for instructions for the olpcnews.com/forum/ kind of people, and that's the information I provided. I wasn't dismissing or ignoring anything; if we widely disseminate those instructions and they are followed, bugs will be far less likely to be dismissed or ignored. But a bug no one knows about is 100% certain to be ignored. I do not know if the the olpcnews.com/forum/ kind of people triggers any reflexes :-) but in this case means not technically inclined eg be as detailed and specific as possible. Tickets are always good but devel lists are neither small potatoes nor a big black hole that things disappear into. In this case there was also a good reason I believe to be used first. So if you please go back to the original mail and answer any question you think you can so tickets can be filed. ___ 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 Mon, Aug 9, 2010 at 9:36 AM, Walter Bender walter.ben...@gmail.com wrote: On Sun, Aug 8, 2010 at 5:09 PM, Christoph Derndorfer christoph.derndor...@gmail.com wrote: On Sun, Aug 8, 2010 at 3:56 PM, Ed McNierney e...@laptop.org wrote: 1. Report bugs at http://dev.laptop.org/newticket - if necessary, register first at http://dev.laptop.org/register (as mavrothal kindly points out) 2. If you have interesting experiences or user information to contribute, please do so at http://wiki.laptop.org 3. If you're unwilling to perform steps 1 and/or 2 as appropriate, please don't expect the bug to be fixed, or for anyone else to even know about it. snip The core here is that software developers seem very reluctant to step out of their own comfort zone when it comes to processes and tools (a.k.a. point 3 a.k.a. my way or the highway) yet consistently expect teachers and other XO and Sugar users to do exactly that. What was the context for Ed's post? And who was his intended audience? Certainly not the end user. In .uy we have discussed various mechanisms for bug reporting by children and teachers. The current plan of record is to use some sort of web form where the bugs are aggregated by a technical liaison. The liaison might then be trained in filing the occasional ticket on Trac. As with any software (and hardware) project, different people in the support hierarchy utilize different tools. It will need re-wording if this it something seen by the volunteers who test sugar and activities in their own time each week - some of them are the our teachers or education ministry decision makers. Can the same be said without it sounding like do it our way or go away? -- Item 3 probably could be dropped completely. It's not welcoming, and makes the project seem unapproachable. ___ 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)
Brenda - I'm assuming your teachers and education ministry decision makers don't normally interact with OLPC by asking questions on OLPCNews forums, which was the context and the specific question I was answering. The topic of, what are all the ways all interested parties worldwide communicate with OLPC is obviously a far more complex one, and not one I was attempting to answer. But people interested in communicating with OLPC and/or Sugar Labs should be able to find either of us - we usually try to point newcomers to our wiki at http://wiki.laptop.org. It's not perfect, but it's a good way to find pointers. But it is absolutely true that anyone who is volunteering (or getting paid) to test OLPC software and hardware should know how to submit a trac ticket. That is the mechanism we use to track reported problems, so using trac should be an essential part of the training any volunteer tester should get. While everyone likes nicely-researched and well-written problem reports, that shouldn't be an obstacle. If there's information missing on a ticket, people working on it can ask for more. But if the ticket's not there at all, we won't know there's a problem to fix. - Ed On Aug 8, 2010, at 6:00 PM, Brenda Wallace wrote: On Mon, Aug 9, 2010 at 9:36 AM, Walter Bender walter.ben...@gmail.com wrote: On Sun, Aug 8, 2010 at 5:09 PM, Christoph Derndorfer christoph.derndor...@gmail.com wrote: On Sun, Aug 8, 2010 at 3:56 PM, Ed McNierney e...@laptop.org wrote: 1. Report bugs at http://dev.laptop.org/newticket - if necessary, register first at http://dev.laptop.org/register (as mavrothal kindly points out) 2. If you have interesting experiences or user information to contribute, please do so at http://wiki.laptop.org 3. If you're unwilling to perform steps 1 and/or 2 as appropriate, please don't expect the bug to be fixed, or for anyone else to even know about it. snip The core here is that software developers seem very reluctant to step out of their own comfort zone when it comes to processes and tools (a.k.a. point 3 a.k.a. my way or the highway) yet consistently expect teachers and other XO and Sugar users to do exactly that. What was the context for Ed's post? And who was his intended audience? Certainly not the end user. In .uy we have discussed various mechanisms for bug reporting by children and teachers. The current plan of record is to use some sort of web form where the bugs are aggregated by a technical liaison. The liaison might then be trained in filing the occasional ticket on Trac. As with any software (and hardware) project, different people in the support hierarchy utilize different tools. It will need re-wording if this it something seen by the volunteers who test sugar and activities in their own time each week - some of them are the our teachers or education ministry decision makers. Can the same be said without it sounding like do it our way or go away? -- Item 3 probably could be dropped completely. It's not welcoming, and makes the project seem unapproachable. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ 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 Mon, Aug 9, 2010 at 10:07 AM, Ed McNierney e...@laptop.org wrote: But it is absolutely true that anyone who is volunteering (or getting paid) to test OLPC software and hardware should know how to submit a trac ticket. That is the mechanism we use to track reported problems, so using trac should be an essential part of the training any volunteer tester should get. While everyone likes nicely-researched and well-written problem reports, that shouldn't be an obstacle. If there's information missing on a ticket, people working on it can ask for more. But if the ticket's not there at all, we won't know there's a problem to fix. Nobody is disputing that bug reports should go in the one true place -- however we need to be welcoming to people when we tell them this. I'll admit i'm not a fan of olpcnews.com, but they are where new contributors end up early on in their contributing -- if only because they show up in many search results. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Making OLPC / Sugar Labs more approachable (was: Re: OLPC 10.1.2 Release Candidate 1)
Every member of the OLPC technical staff is on the de...@laptop.org mailing list, and we all see bugs filed in trac. Sorry - that's not correct. I forgot that Mitch Bradley unsubscribed from de...@laptop.org last December, as he found the noise level has gotten out of control. He does, however, see and respond to bugs filed in trac. - Ed___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable
in general I think it's entirely appropriate to expect that people asking for help do so via the correct channels I believe that asking for help should not be the only supported motivation for contacting developers. In my opinion, developers of a product ought to be interested in learning about shortcomings perceived in that product by users. Are the correct channels any different than blinders ? mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Killing activities when memory gets short
On 7 Aug 2010, at 21:08, Tiago Marques tiago...@gmail.com wrote: Just killing a random activity is a terrible idea becayse you don't want your product behaving like it's defective; the pop up idea is way more acceptable(and a lot better than having the system randomly behaving like it's crashed). Either way, this is the extremely important use of swap memory that doesn't exist here. I understand your engineering constraints on the hardware but randomly killing activities is poised to confuse users and cause people considering the hardware for deployment to think that you're selling them something defective/baddly manufactured. 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... Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [ANN] DrGeo 10.08
Le 06/08/2010 11:04, Bert Freudenberg a écrit : For people unfamiliar with Squeak, you might want to add a note about how to quit (e.g., not to save when asked). Right. I though I had to stop with last minute enhancements, so I decided to left this for the next release with some other improvements. Also, I had to manually install the bundle. After downloading, Sugar did not recognize it as an activity. I guess your wiki does not serve the right mime type. Uploading to aslo might be better (although it would be nice if Sugar was a little more forgiving). Thanks for the note. I uploaded it to aslo but it does not show up, I don't know why. Thanks for the feedback. Hilaire ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Killing activities when memory gets short
Sent from my iPad On 8 Aug 2010, at 18:40, Tiago Marques tiago...@gmail.com wrote: Just killing a random activity is a terrible idea becayse you don't want your product behaving like it's defective; the pop up idea is way more acceptable(and a lot better than having the system randomly behaving like it's crashed). Either way, this is the extremely important use of swap memory that doesn't exist here. I understand your engineering constraints on the hardware but randomly killing activities is poised to confuse users and cause people considering the hardware for deployment to think that you're selling them something defective/baddly manufactured. I tihnk I have been sloppy with my words, so let me clarify two things: I read through the thread but may also missed something. - killing processes should be done only to avoid OOM (because currently the kernel kills the wrong thing most of the time). True. - before the need for killing arises, we can do a myriad of things to prepare the user for what is coming and maybe to avoid it (some good ideas have already been posted in this thread). The idea of killing activities with the content closed seems ok but it would probably be a good idea to have a way to opt out of it for some apps. I'm thinking a PDF that may be left open on purpose to serve as reference to something, a browser window, etc. Are you then proposing to use the LRU policy to do the killing? I'm thinking that a popup with a cancel tied to a timeout may be a good idea. Once it is not allowed to be killed, it should not try to again for the session, or at least for a very large increase in query time. Apps like instant messaging(though I don't recall one for Sugar), would definitely need a definitive opt out, no? Best regards, Tiago Regards, Tomeu Best regards, Tiago Marques This, however, makes non-sugarized activities more dangerous to deal with. One more reason to demand proper sugarization. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Killing activities when memory gets short
On 8 Aug 2010, at 18:40, Tiago Marques tiago...@gmail.com wrote: The idea of killing activities with the content closed seems ok but it would probably be a good idea to have a way to opt out of it for some apps. I'm thinking a PDF that may be left open on purpose to serve as reference to something, a browser window, etc. An opt out could be easily abused... In the PDF case the activity could be closed and reopened under the hoods, without the user even noticing (well, startup time aside). Are you then proposing to use the LRU policy to do the killing? I'm thinking that a popup with a cancel tied to a timeout may be a good idea. Once it is not allowed to be killed, it should not try to again for the session, or at least for a very large increase in query time. Imo a confirmation popup would become annoying very quickly. Also if the user refuses, the kernel will have soon to kill an activity, which is worst. Apps like instant messaging(though I don't recall one for Sugar), would definitely need a definitive opt out, no? Yeah, that's where things get tricky :/ Same issue with a background music player for example. Ideally we would just keep the connection open somehow and close the whole UI, but that's going to get complex. As long as this causes just minor annoyances to the user (like being disconnected or music stopping), I think it's probably something we don't need to solve in the first iteration. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Killing activities when memory gets short
On 8 Aug 2010, at 20:57, Lucian Branescu lucian.brane...@gmail.com wrote: Separating the activity from the service would help here. In the case of music, MPD would use a lot less memory than one of its GUIs. Right, I was thinking to something along these lines too. I'm not sure how the shell would enforce this policy though. Maybe we could allow the activity processes to use a minimum amount of memory when it has been asked to close. As I said, it gets complicated :) An activity frontend to MPD could be killed following activity policy and the MPD daemon itself would be killed following regular daemon policy. Music would play after the activity dies and would only be stopped if the MPD daemon is killed (which is less likely since it uses very little memory). Ah yeah that could work for global services. It would be good if the same could be done at activity level though. You could use the a similar mechanism but it would require figuring out how to launch these services, register them with the shell etc. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable
On Sun, 2010-08-08 at 18:02 -0500, Mikus Grinbergs wrote: in general I think it's entirely appropriate to expect that people asking for help do so via the correct channels I believe that asking for help should not be the only supported motivation for contacting developers. Along these lines, Is there a community liaison? If not, why not? If so, quite frankly when was the last time they liaised with the community. I'll put this here. There is a small open handheld console. http://www.openpandora.org/ http://pandorapress.net/ The openness and friendliness of the community environment is a model for how things can work. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Killing activities when memory gets short
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.) John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable
On 9 August 2010 11:02, Mikus Grinbergs mi...@bga.com wrote: in general I think it's entirely appropriate to expect that people asking for help do so via the correct channels I believe that asking for help should not be the only supported motivation for contacting developers. Not at all, but it's a significant one. In my opinion, developers of a product ought to be interested in learning about shortcomings perceived in that product by users. Looking into the original case - we had people on a public forum[1] expressing frustration that yum fails to work among other things. I hope this doesn't come across the wrong way - but are G1G1 laptop owners considered the target market? If a user installs Skype on an XO-1, only to find that it kills the sound, then I think it's okay for OLPC to abstain from taking responsibility. Fora such as olpcnews.com attracts very motivated individuals who experiment. That's great, but once they leave the realm of the product, peer support takes over. In practice, it seems that genuine issues from these comments do find their way to the surface, albeit in roundabout way. OLPC Sugar Labs are now aware that yum doesn't seem to work. Are the correct channels any different than blinders ? mikus I'm not sure I understand what you mean by blinders. Do you mean blinkers? [edit: Wikipedia says yes] In many ways that's true, but the metaphor doesn't transfer exactly. Each channel (Trac, wiki, mailing list, local user group) deals with a different type of problem. They e simply to block unintended knowledge. However, it's likely that some people will be put off - which means that they become fairly blunt filters. Where the metaphor does fit is using a system to create focus. It's important to recognise that OLPC Sugar Labs have very constrained development resources. Therefore, systems that reduce load on developers increases time on development. Tim [1] http://www.olpcnews.com/forum/index.php?topic=4867 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable
On Aug 8, 2010, at 7:15 PM, Neil Graham wrote: There is a small open handheld console. http://www.openpandora.org/ http://pandorapress.net/ The openness and friendliness of the community environment is a model for how things can work. The support page on that wiki points you to enter the bug in their bug tracker. What part of Pandora were you holding up as an example of better practices ? wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC 10.1.2 Release Candidate 1
--- On Sun, 8/8/10, Ed McNierney e...@laptop.org wrote: From: Ed McNierney e...@laptop.org Subject: Re: OLPC 10.1.2 Release Candidate 1 To: Yioryos Asprobounitis mavrot...@yahoo.com Cc: Fedora OLPC fedora-olpc-l...@redhat.com, Chris Ball c...@laptop.org, Devel devel@lists.laptop.org, test...@lists.laptop.org Date: Sunday, August 8, 2010, 5:51 PM no, there is planned printing support in 10.1.2 or later. I have not heard of anyone interested in working on it, either. - Ed OK thanks Let me repeat the original question though because will all this issues your response generated, I'm afraid will be lost. People already think that the issue is yum and skype (when is really yum update or yum install etoys) but for which a ticket already exists anyway. The important question besides printing that you addressed is wifi access occasionally disappearing from the build when you switch back and forth to gnome, requiring re-installation. Where should someone look for relevant problem info if this reappears, so a ticket can be filed? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC 10.1.2 Release Candidate 1
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). 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/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC 10.1.2 Release Candidate 1
On Sun, Aug 08, 2010 at 05:08:48PM -0700, Yioryos Asprobounitis wrote: Where should someone look for relevant problem info if this reappears, so a ticket can be filed? It depends on how the problem is reported. Best thing is a description of the steps that lead to the problem, including each user action. If the person reporting the bug is unwilling to invest in such a description, then just post what you can to the bug tracker and a developer will ask questions to satisfy the missing pieces. There is no single place that I can say look here. Bug reporting and processing is a two-way street, communication and followup is required. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC 10.1.2 Release Candidate 1
On Sun, Aug 08, 2010 at 05:37:14PM -0700, Yioryos Asprobounitis wrote: The issue is not loss of an access point, and in my case at least, connection was established in both environments before lost during the switch. The issue is I lost eth0 altogether both from sugar and gnome. Mesh was fine. Rebooting didn't solve it. Reinstalling did (till now) I'm presuming XO-1.5. Normally in a bug I'd scroll up to find that out, since everything about a problem is in one place ... but I don't have that luxury in e-mail. If rebooting didn't solve it, then it is likely to be electrostatic damage to the wireless device. You can prove that by: 1. checking for the wireless device using ifconfig eth0 in the text root console, 2. checking for success of the scan-wifi command in OpenFirmware. The fix is replacing the wireless device. What do you mean Mesh was fine? -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC 10.1.2 Release Candidate 1
switching between the desktop environments will certainly cause one of the following: ... 2. loss of association and no reassociation (the other desktop hasn't been told to trust the access point). When phrases such as trust the access point start being used, I have great difficulty understanding how wifi with a choice of access points is supposed to work. If I want to use an access point, why does the XO need to be told to trust that access point ? How do I tell my XO: Trust 'Joe' more than 'Sam' ? Thanks, mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC 10.1.2 Release Candidate 1
Mikus, OLPC/Sugarlabs did not introduce that terminology. Take your wrath out on Linux and Apple (and possibly M$, I don't use Windows enough to know if they have also adopted that phrase.) My Mac doesn't ask if I want to use an AP, it asks me if I trust an AP. It then remembers that AP as trusted. Cheers, wad On Aug 8, 2010, at 10:52 PM, Mikus Grinbergs wrote: switching between the desktop environments will certainly cause one of the following: ... 2. loss of association and no reassociation (the other desktop hasn't been told to trust the access point). When phrases such as trust the access point start being used, I have great difficulty understanding how wifi with a choice of access points is supposed to work. If I want to use an access point, why does the XO need to be told to trust that access point ? How do I tell my XO: Trust 'Joe' more than 'Sam' ? Thanks, mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Speak.Activity v16 on Build 802 - Problem
Hi, I upgraded my OLPC XO from Build 656 to 802. Having not used the XO for the last 2 years, I was pleased with the changes. I am planning to give it to my niece who asked if she could have it.All works well except the Speak activity. After running correctly the first time, it will not start up on subsequent attempts. I thought this may have been caused by my attempt to install Skype when the problem seemed to have started. I erased Speak and reinstalled it with no luck. I first tried going back to 656 and upgrading again to 802. No luck. I should say I also tried Speak v9 which worked with no problems whatsoever. The problem is associated with the Speak v16 activity that comes with 802. I asked the forums if anyone had seen this problem and was recommended to do a no-fail update. After wiping the XO clean and installing 802, Speak v16 seemed to work again with no problems. However, when I closed it and restarted it, I got an error and would not start. I then erased it and reinstalled it. It started up okay with no problems but I get the same result when I close it and restart it. The error detail included the following messages: gst-plugins-based failed to resolve due to Unknown gstreamer failed to resolve due to Unknown gst-plugins-good failed to resolve due to Unknown Processed: 1; skipped: 0 Cancelled Is there a problem with Speak v16? Have you seen this problem before?Is there any more information I can provide?Can this be fixed? Thanx, Tony ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC 10.1.2 Release Candidate 1
On Sun, Aug 08, 2010 at 09:52:28PM -0500, Mikus Grinbergs wrote: switching between the desktop environments will certainly cause one of the following: ... 2. loss of association and no reassociation (the other desktop hasn't been told to trust the access point). When phrases such as trust the access point start being used, I have great difficulty understanding how wifi with a choice of access points is supposed to work. If I want to use an access point, why does the XO need to be told to trust that access point ? Entirely my phrasing you are criticising. There's no terminology defined on the neighbourhood view ... you click on an access point icon and a connection is attempted. In my phrasing, that's a trust. In the code the terminology is the creation of a Settings object for the access point, and the object is sent to NetworkManager as an NMSettings through a NewConnection message. As a result, the access point is added to the list of connections in .sugar/default/nm/connections.cfg, and a badge is added on the screen to the access point icon, the badge is called emblem-favorite (sic). If you have a better phrasing, let me know. How do I tell my XO: Trust 'Joe' more than 'Sam' ? No way to do that in the current Sugar 0.84 without writing additional software. Once Joe and Sam are trusted, badged, connected to, favourites, or used, whatever your terminology choice, then the first one that was trusted will be used if it is available. If it is not, then the second one will be used. So you can almost reach the goal you described if you are willing to change it to Connect to 'Joe' before you try to connect to 'Sam'. If you use the Discard network history button, all access points become untrusted. So you can almost reach the goal you described if you are willing to shorten it to Trust 'Joe' and not 'Sam'. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [support-gang] Fwd: Speak.Activity v16 on Build 802 - Problem
On Mon, Aug 9, 2010 at 3:38 PM, Adam Holt h...@laptop.org wrote: Plz CC de...@laptop.org if you can help! Subject: Speak.Activity v16 on Build 802 - Problem Date: Sun, 08 Aug 2010 19:44:23 -0700 From: Tony Rizos tri...@pacbell.nettri...@pacbell.net To: devel@lists.laptop.org Hi, I upgraded my OLPC XO from Build 656 to 802. Having not used the XO for the last 2 years, I was pleased with the changes. I am planning to give it to my niece who asked if she could have it.All works well except the Speak activity. [snip] The problem is associated with the Speak v16 activity thatcomes with 802. Hi Tony, Sorry to hear about your troubles. Thanks for your perseverance. Speak 16 was touted as a major step forward [1][2], but does have some known issues [3]. Are you able to tell us how you reinstalled it? Did you download an .xo file from http://activities.sugarlabs.org? I asked the forums if anyone had seen this problem and was recommended to do a no-fail update. After wiping the XO clean and installing 802, Speak v16 seemed to work again with no problems. However, when I closed it and restarted it, I got an error and would not start. I then erased it and reinstalled it. It started up okay with no problems but I get the same result when I close it and restart it. The error detail included the following messages: gst-plugins-based failed to resolve due to Unknown gstreamer failed to resolve due to Unknown gst-plugins-good failed to resolve due to Unknown Processed: 1; skipped: 0 Cancelled Hrm. These are issues with GStreamer, the multimedia system. [4] ~/.sugar/default/logs is where activity logs are stored. There should be a log named org.laptop.SpeakActivity.log or org.sugarlabs.SpeakActivity that should provide some clues as to why it's breaking. Tim [1] http://dev.laptop.org/ticket/10059 [2] http://bugs.sugarlabs.org/ticket/1934 [3] http://bugs.sugarlabs.org/ticket/2103 [4] http://wiki.laptop.org/go/GStreamer ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable
On Sun, 2010-08-08 at 19:55 -0400, John Watlington wrote: On Aug 8, 2010, at 7:15 PM, Neil Graham wrote: There is a small open handheld console. http://www.openpandora.org/ http://pandorapress.net/ The openness and friendliness of the community environment is a model for how things can work. The support page on that wiki points you to enter the bug in their bug tracker. What part of Pandora were you holding up as an example of better practices ? wad Goodness I didn't realise the difference was that profound. Community involvement is not a link on a webpage. If that is the level of interaction that you have been looking at then you haven't even been in the right book let alone on the right page. I doubt I ever clicked on that link, yet I know how many Pandora's are out there, where the various components of the as yet unassembled Pandora's are, what has been the most recent problem in getting them going. I don't actually have a Pandora but I know that the first few units had sticky shoulder buttons, I also know that was due to the paint, and what they did to solve the problem. There is a huge amount of transparency that just isn't there with OLPC. Perhaps that was out of necessity, most Pandora purchasers paid one or two years ago. You can't ask people for a million dollars then not produce anything for a year without letting them know something is happening. Nevertheless it has much better results. There isn't the them and us feel. The Pandora has been out maybe a month now. About a thousand units shipped. It has FireFox Chromium FBReader, Fennic, Pingus, Dink Smallwood, Pandora Panic, Lmarbles, Ur-Quan Masters, Quake 3, emulators for Linx,Amiga, MSX, psx, Oric, Amstrad CPC, PDP-11, Vice, DosBox little fairies didn't bring me that information, and neither did they port all that software. Perhaps what is needed is a KDE to olpc's gnome in order to lift the game of both. But really, I'm about done. I might just go and do other things. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable
On Sun, Aug 08, 2010 at 06:02:58PM -0500, Mikus Grinbergs wrote: In my opinion, developers of a product ought to be interested in learning about shortcomings perceived in that product by users. Certainly interested. But not willing to prance about looking for problems when some very neatly defined problems are already logged waiting for fixing. Also not willing to go and interview every user; this does not scale. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable
On Aug 9, 2010, at 12:46 AM, Neil Graham wrote: On Sun, 2010-08-08 at 19:55 -0400, John Watlington wrote: On Aug 8, 2010, at 7:15 PM, Neil Graham wrote: There is a small open handheld console. http://www.openpandora.org/ http://pandorapress.net/ The openness and friendliness of the community environment is a model for how things can work. The support page on that wiki points you to enter the bug in their bug tracker. What part of Pandora were you holding up as an example of better practices ? Goodness I didn't realise the difference was that profound. Community involvement is not a link on a webpage. If that is the level of interaction that you have been looking at then you haven't even been in the right book let alone on the right page. What thread were you responding to ? My comment was in direct response to the mail that started this thread: On Aug 8, 2010, at 5:09 PM, Christoph Derndorfer wrote: The core here is that software developers seem very reluctant to step out of their own comfort zone when it comes to processes and tools (a.k.a. point 3 a.k.a. my way or the highway) yet consistently expect teachers and other XO and Sugar users to do exactly that. This leads to the current situation in which crucial information and feedback from these users does not make it back to developers and the broader community. Therefore rather than working on things that users need or need to work reliably (e.g. the Journal) resources are spent elsewhere. I repeat my question to you: How does OpenPandora provide a better method for users to feedback comments/problems to developers ? I doubt I ever clicked on that link, yet I know how many Pandora's are out there, where the various components of the as yet unassembled Pandora's are, what has been the most recent problem in getting them going. Hmm. Most of that information is readily available for XOs as well. I don't actually have a Pandora but I know that the first few units had sticky shoulder buttons, I also know that was due to the paint, and what they did to solve the problem. And people on the OLPC devel mailing list are aware of early problems with the pre-production XO-1.5s. If you don't like mailing lists, there is the wiki page for each version of hardware, e.g. http://wiki.laptop.org/go/XO_1.5_C3 There is a huge amount of transparency that just isn't there with OLPC. Building first-rate hardware requires playing with the big boys. And while I might not like the secrecy they impose as a condition for playing, the end result is cheaper and more powerful for having played. Perhaps that was out of necessity, most Pandora purchasers paid one or two years ago. You can't ask people for a million dollars then not produce anything for a year without letting them know something is happening. Nevertheless it has much better results. There isn't the them and us feel. We usually have to do a significant amount of hardware and software development using chips that haven't even been publicly announced yet. The alternative is to use older, more power hungry chips (as with XO-1). As soon as possible, OLPC makes a significant effort to ship free prototypes to anyone asking for one for a particular purpose (e.g. working on Gnash, or Sugar).And we use the devel mailing list to keep these early users appraised of release and problems. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[Server-devel] Updating offline
Having problems trying yum --enablerepo=olpcxs-testing -y update Could not retrieve mirrorlist (Error 404: Not Found) Cannot retrieve repository metadata (repomd.xml). Please verify path and try again. Could be our bad connection here. Meanwhile we downloaded the latest rpms manually (eJabberd 2.0.3.11, Moodle xs1.6 and xs1.7, Xs config 0.6.0.18 and Xs activation 0.2.44). What is the procedure to apply them on the XS? David Leeming ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Updating offline
While i'm no expert on this, i can point to a previous answer from server-devel 2 weeks ago. http://lists.laptop.org/pipermail/server-devel/2010-July/005046.html http://lists.laptop.org/pipermail/server-devel/2010-July/005046.html Maxime Raynaud 2010/8/8 David Leeming da...@leeming-consulting.com Having problems trying yum --enablerepo=olpcxs-testing –y update Could not retrieve mirrorlist (Error 404: Not Found) Cannot retrieve repository metadata (repomd.xml). Please verify path and try again. Could be our bad connection here. Meanwhile we downloaded the latest rpms manually (eJabberd 2.0.3.11, Moodle xs1.6 and xs1.7, Xs config 0.6.0.18 and Xs activation 0.2.44). What is the procedure to apply them on the XS? David Leeming ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Updating offline
Missed that, thanks. Done. David From: plo...@gmail.com [mailto:plo...@gmail.com] On Behalf Of Maxime RAYNAUD Sent: Sunday, 8 August 2010 8:25 p.m. To: David Leeming Cc: XS Devel Subject: Re: [Server-devel] Updating offline While i'm no expert on this, i can point to a previous answer from server-devel 2 weeks ago. http://lists.laptop.org/pipermail/server-devel/2010-July/005046.html Maxime Raynaud 2010/8/8 David Leeming da...@leeming-consulting.com Having problems trying yum --enablerepo=olpcxs-testing -y update Could not retrieve mirrorlist (Error 404: Not Found) Cannot retrieve repository metadata (repomd.xml). Please verify path and try again. Could be our bad connection here. Meanwhile we downloaded the latest rpms manually (eJabberd 2.0.3.11, Moodle xs1.6 and xs1.7, Xs config 0.6.0.18 and Xs activation 0.2.44). What is the procedure to apply them on the XS? David Leeming ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
