> Indeed.
> 
> But do not *ever* get fooled into comparing file sizes.  They
> are almost meaninless for unix binaries and they can be very very
> misleading (eg. in the case of unstripped binaries, etc.).  Always
both were stribbed.
> always always use "size" when talking about the non-disk resources used
> by binaries.
> 
> So, for /bin/ls it's actually worse (over 24 times larger!):
> 
> 	$ size -t obj.i386/*.o 
> 	text    data    bss     dec     hex     filename
> 	749     0       0       749     2ed     obj.i386/cmp.o
> 	3922    24      12      3958    f76     obj.i386/ls.o
> 	16      0       0       16      10      obj.i386/main.o
> 	3598    4       8       3610    e1a     obj.i386/print.o
> 	1563    0       128     1691    69b     obj.i386/stat_flags.o
> 	234     0       0       234     ea      obj.i386/util.o
> 	10082   28      148     10258   2812    (TOTALS)
> 	
> 	$ size /bin/ls
> 	text    data    bss     dec     hex     filename
> 	244963  2632    18844   266439  410c7   /bin/ls

so 244K of text

compare to this:

text	data	bss	dec	hex	filename
13843  	368    	544    	14755  	39a3   	/bin/ls

14KB text+the rest 230 from libc.so
but this 230 is SHARED with other binaries. 
just with sh and ls we have 230 wasted (with sharing we have about 80kB
"wasted" for dynamic loader). it isn't small numbers on 4-8MB system, and
pay divident on larger system with lots of memory be better using the CPU
cache.
> > in the other hand i can't understand why over 200kB of code is needed for
> > ls from C library?!
> 
> In this case I don't yet know....  it's rather dismal, especially given
> the frequency with which people use /bin/ls!

not about just ls we are talking about.