Re: [iPAQ] Trimming the fat...

I have mostly been adding fat - support for more and more X11 shared
libs (libtiff, imlib, libungif), and gtk apps (xsri which lets you set
the root screen, my keyboard app, etc), but I have subtracted out many
of the same utilities as you did...

I guess the largest question for me is: does continuing to use cramfs
for /usr and / - once jffs is stable - make sense? I've long used on my
laptop a tool called "tcx", which compresses executables using gzip and
uncompresses them on the fly. Everyone seems to be trying pretty hard to
make various filesystems to compression reliably, I was about to start
fiddling with tcx to see what kind of results I got....

My further comments below:

    2) Remove all "user-level" binaries from images.
> > # Without gdb, xanim, mpg123, and gqmpeg.static, usr-2-40

In my environment, I have an entire usr filesystem mounted via NFS under
/mnt/devel/usr, which contains a full (70MB) distro of hard hat Linux. I
replaced /usr/bin/gdb in the default flash filesystem with a symlink to
/mnt/dev/usr/bin/gdb, so that so long as I'm running NFS it
transparently works.

There are a half dozen other things related to this problem, perhaps
better solutions -
        
        1) incorporate /usr/local/bin and /mnt/devel/usr/bin in the user's
default path, and remove gdb, etc, from the main flash body. (/mnt/devel
otherwise has an empty set of directories)
        2) incorporate automounting (autofs) so that it tries to mount these
additional network filesystems on demand. I like the idea of getting
smbfs to work, for example. It would make transfering files
(autosyncing) between a PC and this box a breeze. Browsing samba shares
from it would be cool too.
        3) gqmpeg shrinks a lot with shared libs. Freeamp doesn't use gtk, is a
tad smaller, but requires
           libstdc++ which is a 1.2MB lib.... but libstdc++ strikes me as
desirable...
        4) Frequently written files (twmrc for example) can move to flash6...
much of /etc/ should probably be rewritable on the fly as well....

As for xanim, methinks it would be more useful if we convinced the xanim
maintainer to provide the codecs for the more popular video formats, as
per his site at: http://xanim.va.pubnix.com/home.html
(the problem is that he can only, due to licensing restrictions, provide
binaries for most of the newer codecs)

> > # /usr/bin/X11/led
> > #
>
> Does anybody know what fromport, toport, gpio and led do???

I believe that led gets called by "xset led" - doesn't strike me as
useful... while I'm on the topic of xset, it would be interesting to
have the xserver try, periodically, to contact an X font server on the
net....

I got rid of all the X demos (ico, etc) as well. Trying to fit genuinely
useful apps in the same space.

> > # /usr/sbin/dongle_attach
> > # /usr/sbin/findchip
>
> Does anybody know what dongel_attach and findchip do???

These are tools for the irda subsystem. Findchip does exactly that -
trys to find out what irda chip you have. So you don't need it.
Dongle_attach is for things like the ESI neteye serial IR dongle, I
think. If the onboard IR is working (and although I've compiled the
modules for it, I've only got the neteye to "see" another chip, not
talk, under 2.4.0test8), you don't need this.

There were (sorry, I don't remember) some more of the irda utilities
missing or broken in the default distro...

>
> >
> > # I'm unqualified to comment on these.
> > # Could this be trimmed down at all?
> > #-------------------------------------
> > # du -s /usr/lib/terminfo
> > # 460
>
> We should probably keep the xterm stuff and the vt100 stuff. The rest can go
> unless somebody out there needs them ?????

Well, there is a wide variety of modern term types out there, most of
them emulators under xwindows....

"linux", "xterm", "ansi", "vt102", and "hpterm" are the only ones I use,
and in a pinch I always end up using vt102.

terminfo is in /usr/share/terminfo on redhat btw.

> > # du -s /dev
> > # 32 # Yes, this would be getting pretty picky about
> > the space
>
> There are two (2) dev's init/dev and root/dev. root/dev is need for booting
> before RAMFS is setup. init/dev is the whole ball of wax used at run time. I
> have cleaned up root/dev a little bit but it could use some more work.

Is there any point to adding the /dev/usb nodes or devusbfs?

How about coda? :)
Received on Tue Sep 19 16:38:49 2000