Re: FYI: dh_upx compresses i386 executables
On Sat, Apr 21, 2001 at 12:20:21PM +0200, Eduard Bloch wrote:
> What is upx good for?
> For all applications that are not used in critical environment, i.e.
> without enough free disc space, or when they are started to often, so
> the decompression time may be too long.
> For example, I will compress SDK example programs in my allegro-examples
> package. These are 52 executables with ~100k pro file => 4739kB.
> Compressed with upx the need only 1214kB. The user won't use them
> frequently and when he/she starts them, there will be no difference
> between compressed and uncompressed apps so we can save this space.
One inherant flaw of upx is that decompression code must be stored
within every binary. Using a hypothetical kernel module such as
binfmt_gzip, the kernel could execute gzipped ELF binaries. This would
remove the overhead of an embedded decompressor and make it more
possible to do advanced things such as sharing the memory of multiple
invocations of the binary.
The kernel already has gzip code for cramfs and booting, so such a
module should actually be rather trivial. The only catch is that you
would be gunzipping a binary directly to memory (not to a temporary file
like upx), which improves speed but demands more unswappable kernel
memory.
I think that UPX may have some uses, but do not see many packages that
would be good candidates. e3 is one, and it already employs upx to
reduce the size of the binary. For things such as boot disks with only
a few megabytes of binaries that must be crammed into a tiny space, a
gzipped ramdisk is far better.
Reply to: