Dan Williams wrote:
>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.
uclibc is pretty friendly to the apps I have compiled it with, including
fairly large things like Asterisk. This isn't very scientific, but
Fedora x86_64: 1485672 Aug 15 15:34 /lib/libc-2.3.5.so
Our ARM distro: 256988 Jan 18 11:15 /lib/libuClibc-0.9.28.so
http://uclibc.org/FAQ.html#why and the next FAQ entry have some
information about the goals and compatibility.
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
Yep.
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.
Are these "JFFS2 image" figures, after the JFFS2 compression? Just some
example numbers, busybox on my Arm9 here is 606KB and allows you to
throw away bash (it has ash), vi, coreutils, rpm (a weaker
implementation, but still), cpio, tar, procps, etc, etc, even networking
stuff like dhcpd and dhcpc are all in there. If you accept some small
restrictions and losses of non-core functionality you can perform a
massive reduction in distro size and packagecount with busybox with or
without an alternative libc.
-Andy