[PATCH 2/2] (g)unzip: Optimize inflate_codes()

[Dan Fandrich]

On Mon, Feb 15, 2010 at 04:34:20AM -0600, Rob Landley wrote:
> Wow, you've quite thoroughly missed the entire point of busybox.

Wow, you've quite thoroughly missed the entire point of my question.

> There is no "the goal", there are multiple goals that get balanced against 
> each other.  Reducing size is a goal, reducing complexity is a goal, reducing 
> external dependencies is a goal, reducing the number of separate executables 
> in the system (and thus the ELF overhead, filesystem block granularity, mmap 
> page granularity, and so on) is a goal...

I'm not asking for the rationale for some arbitrary BusyBox attribute that
you pulled out of your head, I'm asking about the use of small, widely-
available library.

> Busybox doesn't depend on any external libraries (except libc and friends), 
> and never has.  We emit raw ansi escape sequences rather than depend on 
> ncurses, implement our own command line history in the shell rather than 
> getline, and so on.

I thought I saw a loaded BusyBox binary linking to OpenSSL, but may have
just been libcrypt. But lots of BusyBox systems already supply things like
zlib as well as other libraries that are reimplemented in BusyBox, and 
since "reducing size is a goal", it's not unreasonable to expect BusyBox
to use their availability to reduce its size even further.  

> Keeping "old inefficient code around as a fallback" goes against everything 
> busybox stands for.  I personally re-implemented mount at least three times 
> trying to get it to do more in less code, and it's since been redone another 
> couple times since I left.  I didn't rewrite bunzip because it didn't _work_, 
> but because I thought I could do better.

Maybe you weren't reading this thread carefully enough.  It's about patching
the decompress code because it's old and inefficient.

>>> Dan
-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved