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-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 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 de...@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] modified Home View
See http://wiki.sugarlabs.org/go/Features/Spiral_Home_View#Detailed_Description for the latest screen shots. I made some changes to the way I generate the Spiral -- I start from the outside rather than the inside to minimize the visual disruption between the Ring and the Spiral. I don't ever shrink the icon size in the Ring, but do so in the Spiral once the minimum radius is reached. Perhaps most controversial, I introduce an intermediate icon size between standard and small along the way. Gary: I'll post a new patch to the ticket momentarily. (http://bugs.sugarlabs.org/ticket/2143) Comments/suggestions? -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] modified Home View
Le 08/08/2010 13:59, Walter Bender a écrit : See http://wiki.sugarlabs.org/go/Features/Spiral_Home_View#Detailed_Description for the latest screen shots. I made some changes to the way I generate the Spiral -- I start from the outside rather than the inside to minimize the visual disruption between the Ring and the Spiral. I don't ever shrink the icon size in the Ring, but do so in the Spiral once the minimum radius is reached. Perhaps most controversial, I introduce an intermediate icon size between standard and small along the way. Gary: I'll post a new patch to the ticket momentarily. (http://bugs.sugarlabs.org/ticket/2143) Comments/suggestions? Don't you need a way to recreate a taxonomy when the numbers of activities grows? For example grouping related activities in spiral segments and reinforcing this with common icon color scheme in these segments. Hilaire ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] modified Home View
On Sun, Aug 8, 2010 at 8:42 AM, Hilaire Fernandes hilaire.fernan...@gmail.com wrote: Le 08/08/2010 13:59, Walter Bender a écrit : See http://wiki.sugarlabs.org/go/Features/Spiral_Home_View#Detailed_Description for the latest screen shots. I made some changes to the way I generate the Spiral -- I start from the outside rather than the inside to minimize the visual disruption between the Ring and the Spiral. I don't ever shrink the icon size in the Ring, but do so in the Spiral once the minimum radius is reached. Perhaps most controversial, I introduce an intermediate icon size between standard and small along the way. Gary: I'll post a new patch to the ticket momentarily. (http://bugs.sugarlabs.org/ticket/2143) Comments/suggestions? Don't you need a way to recreate a taxonomy when the numbers of activities grows? For example grouping related activities in spiral segments and reinforcing this with common icon color scheme in these segments. The reordering to fit a taxonomy would be orthogonal to however we render the sequence of icons. I am not sure of the optimal way to map a multidimensional space onto a one-dimensional axis, but we do have category information in ASLO. Regarding recoloring, that would be a major UI paradigm shift. But we could perhaps use some other visual attribute besides color to indicate commonality. -walter Hilaire ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Fwd: How about creating addons.gnome.org
Hi, the GNOME people are having an interesting discussion about AMO. Regards, Tomeu -- Forwarded message -- From: Johannes Schmid j...@jsschmid.de Date: Sun, Aug 8, 2010 at 15:28 Subject: Re: How about creating addons.gnome.org To: Jose Aliste jose.ali...@gmail.com Cc: Tomeu Vizoso to...@sugarlabs.org, foundation-l...@gnome.org Hi! Also, there should be a clear distinction whether an addon is Gnome approved (meaning it is reviewed, translated, probably hosted in the gnome git somewhere) or the work of a freelance dev. Distributions are welcome to keep packaging any of the addons, as they do now, but normally the maintainer's cost of distributing 100 or more addons would be too high (in my opinion). In this sense, I would love to have an easy way of installing add-ons that does not require you to copy files to some hidden directories. We should have a command line gnome-addon install add-on-name, which will download and install the add-on. That would be really neat in my opinion. While I would rather vote for a more complete GNOME Appstore solution in the far future (possibly based on OpenSuSE build service), some points to note: * This will only work for scripted plugins Python, Javascript, Ruby * All compiled languages will suffer depedency problems * It would mean that we install executable things into the user's home directory. Some admins might not like this though of course mozilla does the same. Security is an important point here. It is also a rather huge maintaince burden to check that the plugin works with the installed version of an application. But nevertheless, go for it if you have the time, it sounds like a good idea! Especially for the upcoming gnome-shell addons it could be a perfect place. Johannes signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: How about creating addons.gnome.org
On Sun, Aug 08, 2010 at 04:11:38PM +0200, Tomeu Vizoso wrote: Hi, the GNOME people are having an interesting discussion about AMO. Regards, Tomeu -- Forwarded message -- From: Johannes Schmid j...@jsschmid.de Date: Sun, Aug 8, 2010 at 15:28 Subject: Re: How about creating addons.gnome.org To: Jose Aliste jose.ali...@gmail.com Cc: Tomeu Vizoso to...@sugarlabs.org, foundation-l...@gnome.org Hi! Also, there should be a clear distinction whether an addon is Gnome approved (meaning it is reviewed, translated, probably hosted in the gnome git somewhere) or the work of a freelance dev. Distributions are welcome to keep packaging any of the addons, as they do now, but normally the maintainer's cost of distributing 100 or more addons would be too high (in my opinion). In this sense, I would love to have an easy way of installing add-ons that does not require you to copy files to some hidden directories. We should have a command line gnome-addon install add-on-name, which will download and install the add-on. That would be really neat in my opinion. While I would rather vote for a more complete GNOME Appstore solution in the far future (possibly based on OpenSuSE build service), some points to note: * This will only work for scripted plugins Python, Javascript, Ruby * All compiled languages will suffer depedency problems * It would mean that we install executable things into the user's home directory. Some admins might not like this though of course mozilla does the same. Security is an important point here. It is also a rather huge maintaince burden to check that the plugin works with the installed version of an application. But nevertheless, go for it if you have the time, it sounds like a good idea! Especially for the upcoming gnome-shell addons it could be a perfect place. Johannes I can share my own experience in code sharing case. There is a problem w/ AMO. AMO, as filesharing tool, works well only for one-file bundles w/ anyarch data, trying to reuse AMO for not trivial cases like binaries, e.g. different ABIs etc., sound overkill for AMO. Right now, I'm working on different model - Zero Sugar [1]. The core things are: * everything starts with spec file of the package - recipe file [2] * it will be possible to local launch application only having this spec file and sources tarball/vcs-checkout (in noarch case, or build application locally and start it) * keeping in mind variety of users environments and things like ABI breakages (or even different build flags on different distros), it would be useful to just build application in this particular environment. So, using [2] recipe file, on patched OBS (in progress), it will be possible to create native packages for bunch of deb/rpm distros. It sounds like meta packaging but it is not [3]. * The important thing, installing applications from OBS repos is not primary distribution method (it will work fine in case of centralized repo of applications on OBS, but attaching repositories from individuals(in my mind, regular behaviour in sugar ecosystem), i.e., from home projects on OBS, will be really overkill). The first distribution method will be 0install [4]. So, OBS will create not only native packages but 0install feeds as well (for nonarch applications, only 0install feeds, for binary based, 0install will reuse native packages). * 0install is/should-be fully integrated into GNU/Linux distributions ecosystem e.g. it is not about creating yet another distro, 0install will reuse PackageKit to install already packaged software. * OBS will be used as only one place for all file sharing/packaging stuff. Sites like AMO will be used only as catalogs (users driven, e.g., reviews, ratings etc.) of applications - they will contain only 0install links (of files stored on OBS). Even more, OBS will be auto publish info about new versions/packages on AMO. [1] http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar [2] http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar/0sugar.info_Specification [3] http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar/Native_Packages [4] http://0install.net/goals.html -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] modified Home View
On Sun, Aug 8, 2010 at 11:55 AM, Gary Martin garycmar...@googlemail.com wrote: Hi Walter, On 8 Aug 2010, at 12:59, Walter Bender wrote: See http://wiki.sugarlabs.org/go/Features/Spiral_Home_View#Detailed_Description for the latest screen shots. I made some changes to the way I generate the Spiral -- I start from the outside rather than the inside to minimize the visual disruption between the Ring and the Spiral. I don't ever shrink the icon size in the Ring, but do so in the Spiral once the minimum radius is reached. Perhaps most controversial, I introduce an intermediate icon size between standard and small along the way. Gary: I'll post a new patch to the ticket momentarily. (http://bugs.sugarlabs.org/ticket/2143) Thanks, been testing comparing it with the other patch, for those without time to try, see attached image. Left column is Walter's v1 patch, right is the v2 patch. Comments/suggestions? You'll hate me for saying this, but I rather prefer your v1 spiral patch ;) - when the circle is large (39 activities), the distance the activities are from the central XO is really visually uncomfortable and disconnected I don't think the large circle behavior has changed from before, but that doesn't mean it is correct. Maybe we want to trigger the spiral sooner? And gradually grow out to the maximum radius? I'll experiment with a few more variants. - when your v1 spiral triggers looks really good, wrapping near around the user, spiralling outwards - when v2 patch triggers to spiral, it has the same far away spacing from the user XO as the large circle, until you favourite about 90-95 activities - v2 patch also seems to trip into tiny, tiny, icon mode even though there is space still, well before v1 does (see bottom images) – large icons as long as possible are really important (think touch UI compatible) I think it is a peculiarity of fitting a spiral into a rectangle that causes the icon trigger to fire at slightly different times. Actually, it is triggering the intermediate size. Small is really small. (See http://wiki.sugarlabs.org/go/File:Spiral-small.png) If you want a more continuous transition between the v1 circle and spiral (I agree v1 is quite a large change), a close circle up to about 22-26 icons would be nice switch to spiral point, before icons feel too disconnected from the user and matching up well with the v1 spiral. As per above, I'll play with a few more variants. Thanks for testing. -walter --Gary -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 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 de...@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-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-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
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 :) Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-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). ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] modified Home View
Hi Gary--thanks for the interesting mockup! My feedback: The spiral is interesting and worth exploring. But I would continue to focus the view on a single organizational system, whether ring, spiral, freeform, list, etc. This preserves the integrity and extensibility of the UI views metaphor, and doesn't overload the screen. Because the iconographic language is already very abstract and pared down, we need to make sure that the interaction paradigm is clear and focused. Based on your rendering I think that the spiral in itself is definitely worth exploring further, and I like Walter's idea that it could start as a ring and grow into a spiral when more activities are added. That seems like an elegant and scalable solution. Favoriting could happen in the Journal, or we could opt to always display all activities--either seems like a potentially workable solution... We should also come back to the resume/start new proposal and figure out if we want to adopt any of the proposals. Christian On Sun, Aug 8, 2010 at 4:38 PM, Gary Martin garycmar...@googlemail.comwrote: On 8 Aug 2010, at 14:54, Gary Martin wrote: On 8 Aug 2010, at 13:42, Hilaire Fernandes hilaire.fernan...@gmail.com wrote: Le 08/08/2010 13:59, Walter Bender a écrit : See http://wiki.sugarlabs.org/go/Features/Spiral_Home_View#Detailed_Description for the latest screen shots. I made some changes to the way I generate the Spiral -- I start from the outside rather than the inside to minimize the visual disruption between the Ring and the Spiral. I don't ever shrink the icon size in the Ring, but do so in the Spiral once the minimum radius is reached. Perhaps most controversial, I introduce an intermediate icon size between standard and small along the way. Gary: I'll post a new patch to the ticket momentarily. (http://bugs.sugarlabs.org/ticket/2143) Comments/suggestions? Don't you need a way to recreate a taxonomy when the numbers of activities grows? Search (ghost out non matches, as per neighbourhood view design) in the fav. view would seem an ideal next step here when dealing with many activities. Allowing drag and drop that would trigger a switch from a fixed layout pattern to random mode (with the layout initially intact), and/or reordering the sequence by drag'n'drop insertions would allow some flexibility. Ideally icons would be either snapped to the shape (dragging N units close to a snapped icon or the XO) or freeform positioned (by dragging N units away from their/a set position). With different icons in either state for a single view (I.e. a spiral with a few frequent icons dragged out into empty space). The current random view could then go away (as each view could be as random or not as desired). Just as a follow up to my above comment, attached is a quick home view vector mockup. It assumes the list view is gone, with Journal stars being used to indicate (arbitrary entry) home favourites. It shows a 'snap to spiral' pattern, with several random clusters of activities/objects previously dragged out of the pattern by the user. Coloured icons would resume specific activity id objects, grey icons would be used to launch new instances (with the usual resume drop down palette of N most recent activities of that type). The spiral would re-flow once an icon is dragged out and dropped (in empty space), or dragged in and dropped (on an already snapped icon). If all icons were dragged out you would have what would look like the random layout, dragging an icon back onto the central XO would start reflowing a snapped pattern design again, as would adding new activity favourites. Again, just a future possible approach. Definitely no need to try and land something like this all in one go. --Gary But Walters spirals, without any of the above type extras, is still a huge improvement for those that want to fav many activities. I'm already hard-pressed to find new activities to fill up the view for testing, really scrapping the barrel. For those of you involved in deployments — roughly how many activities do you think kids/teachers currently commonly have? For example grouping related activities in spiral segments and reinforcing this with common icon color scheme in these segments. -1 No to a color scheme here. Colour is already used for identity. It's bad enough that the GC activities, and a few others, break the colour metaphor by not bothering with the fill_color and stroke_color variables — adding even more colour metaphors would not help! ;) --Gary -- anyth...@christianmarcschmidt.com 917/ 575 0013 http://www.christianmarcschmidt.com http://www.linkedin.com/in/christianmarcschmidt http://twitter.com/cms_ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-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-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] the livecd-creator command: -b BASE_ON, --base-on=BASE_ON, Add packages to an existing live CD iso9660 image. ?
I am asking for help: Is there some documentation on the use of the option: --base-on=BASE_ON ? I am wondering if this is a functional option in f13-f14, and how is it used? how do I add a package to an existing .iso image In: http://www.ibm.com/developerworks/linux/library/l-fedora-livecd/: Options for Livecd-creator: $ livecd-creator No packages specified. usage: livecd-creator [--help] [--repo=name1,url1 ...] [--repo=name2,url2] --package=p1 [--package=p2 ...] [--exclude-package=e1] --exclude-package=e2 ...] [--base-on=path-to-iso-file] [--fslabel=label] --help : Print usage and exit --repo : Path to yum repository --package : Include this package --exclude-package : Exclude this package --base-on : Add packages to an existing live CD iso9660 image --fslabel : File system label (default: livecd-MMDD-HHMI) ... The examples look like a very nice way to customize a .iso, without doing a full build with a .ks file BUT But in f14 liveusb-creator --help *Options provided by the livecd-creator command* f14(rawhide) livecd-creator --help Options: -h, --helpshow this help message and exit Image options: These options define the created image. -c KSCFG, --config=KSCFG Path or url to kickstart config file -b BASE_ON, --base-on=BASE_ON Add packages to an existing live CD iso9660 image. -f FS_LABEL, --fslabel=FS_LABEL File system label (default based on config name) --compression-type=COMPRESS_TYPE * *Note: NEW TO F14(rawhide)* Compression type recognized by mksquashfs (default zlib, lzma needs custom kernel) System directory options: These options define directories used on your system for creating the live image -t TMPDIR, --tmpdir=TMPDIR Temporary directory to use (default: /var/tmp) --cache=CACHEDIRCache directory to use (default: private cache Debugging options: These options control the output of logging information during image creation -d, --debug Output debugging information -v, --verbose Output verbose progress information --logfile=FILE Save debug information to FILE . Many of these options --package : Include this package --exclude-package : Exclude this package are not listed for f14. Is this a feature no longer supported in fedora? Where can one find more information and usage cases? Tom Gilliard satellit ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-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/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Adding committers on gitorious (was: Re: [PATCH] Remove nbsp chars from the html string before parsing)
On Fri, Aug 06, 2010 at 09:05:24AM +0200, Tomeu Vizoso wrote: On Fri, Aug 6, 2010 at 01:47, Marco Pesenti Gritti ma...@marcopg.org wrote: On 6 Aug 2010, at 00:20, James Cameron qu...@laptop.org wrote: On Thu, Aug 05, 2010 at 09:06:03AM +0200, Tomeu Vizoso wrote: Another option is having some script that adds committers to all sugar core modules in one go, that would be similar to what GNOME does. There are too many core modules, in my opinion (and Michael Stone's). ?I see no good reason why there isn't just one git repository for the whole of Sugar. Yeah, I think we need to look into merging core in a single repository. At the end it's basically the same problem we find again and again: we spend days-person discussing some big changes, eventually may reach an agreement (or not), then nobody finds time to actually do the work. Michael Stone did it. I tested it on an XO. It worked. It happened with the code review process and I see very well it happening here because it would require coordination with packagers, updating lots of wiki pages, etc. Well, apart from the actual code and git repository changes, there's nothing obvious that needs fixing. It's the code that counts. I don't go looking for trouble in Wiki pages or packagers. Wiki pages that document code should be in the code repository, not in the Wiki. Packagers can be told what the changes are and they will adjust wonderfully. You seem to think something else is required to complete this task, but I knew nothing of those things. Perhaps that is why things are not completed? -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
