There is information in the /proc filesystem we could use to refine the heuristics.
/proc/meminfo - How much physical memory. /proc/loadavg - How many IOWAIT cycles. /proc/cpuinfo - How fast is my machine. How many CPUs. But I guess we should try out the current resource indicator on many different types of machines, to get a good idea of how bad the current heuristics really are. Btw, I wouldn't say the current heuristics are 'tuned' for the xo or any machine in particular. Here's how it works. 0 < memory free < 100 0 < cpu free < 100 0 < mem + cpu free <= 67 => unhappy 67 < mem + cpu free <= 133 => serious/normal 133 < mem + cpu free <= 200 => happy On Wed, Sep 15, 2010 at 6:48 PM, David Farning <dfarn...@gmail.com> wrote: > On Wed, Sep 15, 2010 at 5:59 AM, Tomeu Vizoso <to...@sugarlabs.org> wrote: >> On Wed, Sep 15, 2010 at 12:12, James Cameron <qu...@laptop.org> wrote: >>> On Wed, Sep 15, 2010 at 10:40:06AM +0200, Tomeu Vizoso wrote: >>>> Basically, I don't see how this could work without being tuned to very >>>> specific systems. >>> >>> I've reviewed the patch [1], and I disagree with your assessment. It >>> would work without any tuning to specific systems. The learner would >>> learn that system response correlates to the face. >> >> As said in the ticket, in some systems regardless of the load the face >> would be always happy or always sad. I expect users to be confused >> about this. >> >> I guess the intention is that after you start Sugar, the face would be >> happy. As the user activity consumes more resources, the face becomes >> neutral and when there aren't enough resources to provide a good user >> experience (things slow down or risk of OOM grows) the face becomes >> sad. >> >> Now, if you try this specific patch out in systems different enough >> from the XO, you will see that the face stays in the same state >> regardless of the user activity. Examples of such systems are most >> modern netbooks, which ship with a minimum of 1GB of RAM and often >> have CPUs with 2 cores. Another example are LTSP systems. Or systems >> with less memory than the XO but with some swap. This is because the >> current algorithm is tuned for the base free resources on the XO. >> >>> It would only work on Linux, but since that is a dependency of Sugar I >>> can't see how non-portability would be an issue. The code gracefully >>> degrades if /proc entries are not present. >>> >>> It uses documented Linux kernel interfaces, which may be invalidated in >>> future, but those interfaces have lasted a long time without significant >>> change, and there are many tools that depend on these interfaces. >>> >>>> Now, I seem to be the only one concerned about this [...] >>> >>> I'd be more concerned about your concern if I could understand how you >>> drew your conclusions about the function not working without being tuned >>> to very specific systems. >> >> Have you tried it out in something other than the XO? >> >>>> When people start complaining about their faces being always happy or >>>> sad I expect you to help out. >>> >>> As a general rule, I would expect no help from coders who contributed >>> code to an open source project in the past, but help is always welcome, >>> and the contributor could be one of the first people to be asked when >>> code breaks. >> >> As a general rule, code that depends on heuristics that are tuned to a >> specific system wouldn't be accepted because would be very hard to >> support. But I don't have enough time nor energy to discuss things >> without end. > > And this is precisely why we have Dextrose.... When deployments want > something and upstream doesn't, the patch goes into Dextrose. No > harm. No foul. > > david > _______________________________________________ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > -- Anish _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel