Re: less than 4 MB RAM / 2 bzip or not 2 bzip?

From: Michele Andreoli (
Date: Thu May 18 2000 - 14:50:45 CEST

On Thu, May 18, 2000 at 02:48:00AM -0400, Alfie Costa nicely wrote:
> So, starting from a P200 with lots of RAM, I rearchived the EXT and VNC addons,
> with the '-1' switch. These were about 30K bigger than the originals, but they
> still fit on the floppy. Made new floppies with these new .bz2 archives, and
> then installed them on the 386 laptop. Sure enough, it worked -- not as fast
> as PKZIP or ARJ, but only minutes to uncompress, and not several hours.
> Mu runs on the 386 well enough, but still thrashes a bit too much, but it's not
> that bad. (It's still possible there's some problem with it not seeing all 4
> megs of RAM or not.) Also it may be faster on an ext2 partition rather than in
> umsdos.

MuLinux decompress with bzip2 -ds: the -s option is to reduce memory usage.

> Which leads to a general question. New archivers are being written every so
> often, so I wonder if bzip2 is the still best archiver for something like mu
> anymore. An improved archiver should be as small a program as bzip2, produce
> equally good compression or better, use less memory, and work no slower.


> If
> there is no such program with all these good points, one trade-off that might
> be worth it would be an archiver that takes more CPU cycles to compress small,
> but decompresses quickly. In this way the main archives could be made on a
> newer machine, yet easily decompressed on an old one. The question: what
> GPL'd archivers compare well to bzip2?
> Perhaps bzip2 will turn out to be the best one after all. I shall try to look
> on a few archive sites to find out what's new out there.

In my opinion, this is a kind of Shannon theorem: high compression rate,
low size, high CPU usage.


I'd like to conclude with a positive statement, but I can't 
remember any. Would two negative ones do?       -- Woody Allen
To unsubscribe, e-mail:
For additional commands, e-mail:

This archive was generated by hypermail 2.1.6 : Sat Feb 08 2003 - 15:27:14 CET