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.
