OLPC 'upstream'

[Andy Green]

Pete Zaitcev wrote:

> Very well, if you say so, ash may be all right. But busybox seems to
> take this too far. You know what the root of all evil is... So why don't
> we let OLPC group to actually build a system and take measurements?
> It seems too early to decide on busybox. For crying out loud, it's

That CPU has only 16K + 16K I/D cache.  The AT91RM9200 embedded chip I
use at the moment has the same cache :-O.  It does have 64-bit path to
its DRAM, but still, cache locality is going to be really critical.

And that suggests you need an extreme War On Bloat:

 - because the less going through the small caches the less wasted CPU
cycles waiting on DRAM

 - the less thrashed back and forth between the caches and the DRAM the
faster and better power efficiency

 - because you have to suck it out the NAND flash and decompress it, the
smaller the apps and libs the more responsive the system

 - because you may not have the flash you think you will -->

Having stared at the spec, it is still the first and arguably only place
cost reduction can happen, so it should be expected, in fact since I
heard it had 1GB of flash that has already softened to "512M and maybe
1GB".  In fact when people are desperate to save cents on the box you
may end up with 64MB or less of flash onboard for the OS and be expected
to use a USB flash pen to hold the actual usermode apps, if it lets them
ship at the pricepoint.

> a system with GNOME. I'm sure 10 core systems can disappear in the
> noise of that set of packages. :-)

I'm not sure how much of Gnome is planned to be in there as opposed to
GTK2.  Besides its not the way to get a tight system to say that other
things are huge so everything can stay as in Desktop Fedora.

Coming from embedded it seems to me the challenge of this game is not
understood well yet.  Fit the whole OS and X and toolkits in 20MB, not
200MB.  Anyway I see the main need right now is to ship a 0.1 version as
you suggest.

-Andy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4492 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060209/6636c5c1/attachment.bin>