[Dextrose] [Sugar-devel] Stability stuff

[Tomeu Vizoso]

On Fri, Sep 3, 2010 at 23:59, Bernie Innocenti <bernie at codewiz.org> wrote:
> El Fri, 03-09-2010 a las 11:23 -0400, Martin Abente escribió:
>
>> Well, thats true in theory, assuming all the activities are properly
>> designed for sugar. In the field you already know thats not the case.
>> Also... even when the activities are being implemented in python
>> through the Activity Class, the read and write methods needs to be
>> implemented by the programmer. That means it
>> depends on the activity specifics again.
>
> Yes, but if an activity fails to save when Sugar asks it to quit, then
> it's already buggy today: we also have a "Stop" item in the menu of the
> activity frame icon.
>
>
>> > This is also a very good suggestion. We could start by doing this, which
>> > is a lot easier and almost equally effective.
>>
>> I see it this way: Why waiting to get sick to do something about it.
>> Preventive medicine
>> is always better. Why waiting for the machine to freeze (waiting 3 or more
>> minutes until its back
>> to a usable state again) to do something about it, also with potential
>> data loss.
>>
>> Having a message telling kids that the machine is too overloaded should be
>> enough, with
>> recommendations about saving any current work and closing earlier
>> activities.
>>
>> This kind of mechanisms should help to the overall stability, and it makes
>> even more sense when you
>> think about XO's 1 scenarios.
>>
>> :)
>
> Yes, I already agreed with you on this. The hard part of this patch
> would be setting a threshold to disallow opening another activity.
> Memory footprint of activities varies wildly. Shall we take the worst
> case, pissing off users who knew what they were doing, or shall we be
> optimistic, risking the current behavior in some cases?
>
> If we also had both the "graceful stop on oom" that I was thinking of,
> we could afford to be be optimistic in the "oom prevention" code.
>
> Anyway, for now I'd vote for doing what you suggest in the easiest
> possible way even if it saves the system only 50% of the times. It would
> still be a huge improvement upon the current behavior.

Whatever we end up doing, we should not leave much chance of
undercalculating the available memory of we may render Sugar mostly
useless.

This remembers me when we deployed the free-space warning and users
were able to get into situations where they could not use Sugar
because of not enough space but also couldn't remove stuff.

Regards,

Tomeu

> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>