[olpc-software] graceful handling of out-of-memory conditions

[David Zeuthen]

Hi,

On Fri, 2006-03-31 at 04:13 -0800, Krzysztof Kowalczyk wrote:
> I know for a fact that Exchange Server or SQL Server won't crash just
> because some malloc() failed so open-source developers on projects
> 1/10th of the size should be able to do it as well. Given enough
> eyeballs and all that. For example, sqlite and cairo do the right
> thing.

Handling OOM would break lots of library API. Not to mention that
upstream probably wouldn't take it.

> To go on a tangent: to me the "how to handle OOM in kernel" discussion
> just shows that Linux (in the broad sense of Linux Kernel + X +
> standard Linux libraries and apps) is wildly inappropriate technical
> choice for OLAP.

The other OOM thread on this list concluded we can restrict OOM handling
to user apps running and not taking down the UI shell. Do you disagree?

Sure, we can add lots of (silly) UI asking what user app to kill like in
the Windows CE example I snipped. Some research on what user experience
we want will tell us what to do. I'm interested in this but it's not
really my area of expertise.

Look at it this way: We also don't need to put the software developer
into the pain of having to handle OOM; surely, as an individual written
many many lines of code myself (some having to handle OOM) I can attest
to the fact that it's annoying have to care whether malloc fails. 

And another of Havoc's point was that even when developers try to do
this they fail. So my view is that handling OOM is just not worth it for
most pieces of software. More importantly, we just don't need to for
most of the software we include in OLPC because we can restrict this to
the user apps.

> Linux stack consists of millions of lines of C code written with 
> desktop pc in mind, targeting specs of at least 1 GHz processor, 0.5
> GB of RAM, gigabytes of hard-drive, and high-resolution screens.
> 
> The design of the whole system is optimized for those specs (the UI
> assumes there's plenty of space to waste on menu bar etc. and
> programmers assume it's ok to pretend that memory is infinite, etc.).

Yes, but this trend is starting to change; just look at all the work
that's gone into GNOME to fix this. Sure, not everyone is on the same
page yet (*cough* Evolution *cough) but, really, no one forces OLPC to
ship memory pig apps. We have alternatives for almost every application.
Isn't open source great?

> And the same time it lacks some of the things that proved to be useful
> like good IPC mechanizm or system-wide, standard scripting language
> that can be used to both script the apps and as a high-level language
> for writing large class of apps (present in Amiga OS (ARexx, ports),
> Newton (Newton Script), Mac OS (Apple Script)).

Oh, more bashing. Well, this is changing too. Didn't you notice that a
modern Linux based system today uses D-BUS for many things? That's our
IPC. 

High-level scripting is important for some users; whether it's important
for the OLPC target users I'm not sure; someone with an educational
background would know better than I. 

However, I do agree that it would be nice if all apps on my desktop was
scriptable - personally I'm not sure if I would use it [1], but then
again, sometimes you don't know in advance if a certain feature is
useful. 

[1] : I prefer apps to "just work" and provide the features in a nice
intuitive way instead of whipping up a super l33t script I can share
with my friends. 

> No matter how hard you try, you're not going to do a good job at
> scaling this stack down to a reasonable size and it will still lack
> the good features.

Why? I disagree. Just look at the difference from GNOME 2.0 to GNOME
2.14 - it's just so much better. So the lesson here, I guess, is that it
is indeed possible to do revolutionary things and evolve.

> And its not like no-one created a good OS for low-powered devices before.
> 
> Amiga OS,

Where's the source?

> Newton OS

Where's the source?

> Danger's SideKick OS 

Where's the source?

> Even Lisp Machine, 

Oh my. And, btw, is the source available?

> Any of those systems seems like a better choice for OLAP than Linux
> system. Or a system designed and implemented from scratch, that uses
> the good things that can be learned from those systems (and Linux, if
> there really is anything to learn from it other than  given a chance
> to redo things, you would probably want to do everything differently).

Can I suggest 

 - Getting up to speed on the core technologies we plan to include 
   for OLPC and review these

 - Think hard about why it's so important to people for this to be open
   source and free software (and why in general this is a good idea)

Thanks,
David