Challenge: Put all of Shakespeare's works into the smallest HTML file you can
github.com
github.com
Of course, the decompressor itself also needs to be compressed, which I suspect will be where most of the competition will happen.
I'm not so sure; PAQ is pretty slow and the challenge has a 30m time limit. Check out the 1GB text compression benchmark in the wiki - it's orders of magnitude slower than the next best algorithm for a 5% improvement, and the benchmark case is basically the same as this challenge.
Edit: I mean, it took 17 hours.
30 minutes to decompress 5324821B is only slightly less, at 2958 bytes/s. This "on a modern computer", certainly not one from 15 years ago, even after factoring in JS overhead, sounds doable, if not easy. Have CPUs gotten more than an order of magnitude faster since then? Probably (but perhaps not for the type of code that would be encountered in a decompressor --- the biggest boost has been for vector operations, which are neither particularly suitable for high compression algorithms nor easily usable from JS.) Is JS overhead less than 10x native code? Probably for some cases too.
In fact, I just tried paq8hp12 on the file and it compressed it to 1059027 bytes in 208 seconds on a moderately old system (i7 870). Decompression took the same time.