Krzysztof Kowalczyk wrote: > 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.
A reasonably snappy blackbox running on a 400 Mhz PII with 64MB RAM disagrees. > 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 Python is getting there, and there's lots of work being done on taking it even further in that direction. > 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. I disagree; take a look at what Nokia has done with Maemo on the 770. To take a step back, though, the OOM discussion seems unnecessarily complicated to me. While solving the problem "correctly" requires significant engineering work, I'm not sure the OLPC timeline tolerates a correct solution; a pragmatic one, if it got us 80% of the way there, would do just fine. We have pragmatic solutions available: polling the available amount of RAM, or passing a notification from the kernel when available RAM drops below a certain amount will both get the job done. The user can be presented with the option of choosing an application to close, and the problem is 80% solved. In the face of an application allocating RAM so aggressively that it causes an OOM condition before the poller/user were able to address it, I think there's no harm in letting the OOM killer do its job. It's a corner case. -- Ivan Krstic <[EMAIL PROTECTED]> | GPG: 0x147C722D -- olpc-software mailing list [email protected] https://www.redhat.com/mailman/listinfo/olpc-software
