OLPC 'upstream'

[Dan Williams]

On Wed, 2006-02-08 at 15:47 +0000, Andy Green wrote:
> > Any real code changes are going to be done upstream if possible; the

Well, by "upstream" I mean upstream in the projects for which the
changes would be made.  Like the Linux kernel, Gnome, glibc, etc.

> "We plan to use the JFFS2 journalling flash file system on the flash..."
> "At this point, OLPC looks most favorably on the GTK+/Pango/ATK toolkit"
> 
> Sounds good!  Be aware tho that large JFFS2 filesystems are really slow
> to mount.

Yep, and Dave Woodhouse knows the limitations quite well.  Which is why
he's beating JFFS2 into submission for OLPC as we speak.

> Actually quite encouraging, we'll see if "busybox" and "newlib" or
> "uclibc" form part of Rehdat's concept.

Well, remember that while this machine has some low-end specs that match
more of a "smart" cellphone rather than a real laptop, it still is more
of a laptop.  If you're running interesting apps on it, I'm not sure
that things like uclibc would really work.  Most of the highly slimmed
down environments are targeted at PDAs that are quite a bit lower-speced
than this laptop.

With glibc, most of the size is actually taken up by all the locale
information, which can certainly be stripped out for OLPC.  The plan
here is to use as much of Fedora Core as possible (including glibc) and
only if there are severe space issues rethink that strategy.  There
really aren't many space issues however.  The moderately slimmed JFFS2
image is under 250MB now, and there's still lots to be culled.  I think
the target is around 150MB - 200MB for the base OS and desktop library
stack.  That's quite reachable.

Dan