I don't recommend using it on the entire system; besides the obvious speed problems, I think that there are some programs that get upset if you UPX them._________________Don't believe the "n00b" under my name.

Interesting idea. At least Arch has this recommendation about their Firefox_Tweaks.
I have an idea of a UPX ebuild including some cronjob and configuration such as prelink (note that prelink doesn't work on UPX compressed files). There it would be possible to have a list of binaries such as firefox that should be re-compressed after updates, as well as excluding these from the prelink cronjob..._________________ppc:PowerBook5,8 15"(1440)-G4/1.67,2G | amd64:Acer Z5610 (Core2QuadQ8200),i5-3470,VMware VM @ i7-2620M | amd64-prefix:OpenSuse | Lila-Theme

If you want to use compression, you could consider btrfs, as it compresses files on disk. I wouldn't expect it to be hugely effective, but it should give some improvement on larger binaries._________________CFLAGS=" -O999999"

You would probably have a more meaningful improvement by using squashfs + XZ + BCJ filters on /usr/{bin,lib} instead of either of those methods, since then your binaries would both be efficiently compressed (by an executable-specific compressor) and contiguous on disk.

Yes, I already use squashfs in combination with aufs3 by mv's squash_dir scripts for portage, /var/db etc. for better performance.
But I did not think about using it for binaries. Maybe that would work and just needs to be re-squashed after updates. So I could just start and add /usr/lib64/firefox..._________________ppc:PowerBook5,8 15"(1440)-G4/1.67,2G | amd64:Acer Z5610 (Core2QuadQ8200),i5-3470,VMware VM @ i7-2620M | amd64-prefix:OpenSuse | Lila-Theme