[Sugar-devel] What should system mood really mean? (forked from #2141 UNSP: Memory and CPU status indicator for the frame.)

[Anish Mangal]

Idea!

How about extending the meaning of 'system mood' to more than just the
memory and cpu usage metrics.

What would contribute to my system being 'unhappy'? Off the top my
head, the ones I could think of are:

+ I'm almost out of resources (cpu, memory).
+ If I have a battery, its almost empty.
+ If I have wireless connectivity, I have very low signal strength.
+ I'm almost out of physical storage space.
+ <more suggestions>

If i'm unhappy, my primary palette could reveal what's wrong and my
secondary palette could display the usual system parameters.

On Wed, Sep 15, 2010 at 6:48 PM, David Farning <dfarning at gmail.com> wrote:
> On Wed, Sep 15, 2010 at 5:59 AM, Tomeu Vizoso <tomeu at sugarlabs.org> wrote:
>> On Wed, Sep 15, 2010 at 12:12, James Cameron <quozl at 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 at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>

-- 
Anish