> I agree with Albert's proposal - Newcomers to the Wellington test team > open too many apps all the time - and render their machines unusable > through memory pressure. From that experience, I like the idea of > adding a bit of metadata that hints the mem footprint, and teaching > sugar to prevent users from starting new apps if less memory than > stated is available.
We can slap a crutch like that onto the system, but we actually built and shipped a release (703) that did let you run three or four activities without serious trouble. That release is in the field, and people will expect to still be able to run three or four activities after upgrading to the new release. In theory, releases get better rather than worse. Our old release also took quick corrective action when it ran out of memory -- it rapidly killed off some program, often the largest one. Our new release doesn't do that, and nobody knows why. Instead it just gets really slow and groggy. It seems to be a kernel change, but nobody's bisected it. See http://dev.laptop.org/ticket/8316, for example. Rather than putting work into crutches, let's fix the real problems that we already know we have. John PS: We don't even know the mem footprint of our activities. It all gets jumbled up by Sugar and Security and other changes. Nobody thinks the numbers in "top" are useful, nobody has any better way to measure the "mem footprint" of an activity. So even assuming that you added a field to every activity, what values would you put in those fields? _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
