From: Claudio Neves (neva@nevalabs.org)
Date: Fri May 19 2000 - 16:44:19 CEST
At 11:23 19/05/00 +0200, you wrote:
>On Thu, May 18, 2000 at 09:24:32PM -0300, Claudio Neves nicely wrote:
> > Hello,
> >
> > This is not directly related with the topic, but is related
> > with compression, speed and space!
> >
> > Have anyone tried UPX ?! http://wildsau.idv.uni-linz.ac.at/mfx/upx.html
> > It's a compressor for executables, and it accept many executable
> > formats, including dos, windows and linux/i386 .
>
>Already suggested and tested: no significant gain compressing ELF.
>In addition, you need of the upx binary, very big.
The UPX binary is needed only to compress the files, not to
uncompress them! There is no need to include the UPX binary
on Mulinux.
But as Emmanuel already said, it has many drawbacks, like needing
to create a temporary file of the size of the uncompressed executable.
Not very useful for Mulinux.
Have anyone tried the new bzip2 1.0.0 ?!?!
> >
> > The executables can be run normally, they are uncompressed on
> > the fly (similar to the old lzexe on DOS), with very little overhead.
> > It would benefit mulinux in the sense that the ramdisk size required
> > to store the files uncompressed from the floppies would be smaller.
> > I think it makes a difference with low-memory computers (4MB or
> > even 8MB with the EXT addon).
> > I haven't had time to play with upx + mulinux, but if anyone have the
> > time to play with it, it would be nice to know the results! :)
> >
>
>This is a general question: what is better beetwen:
>
>1) to compress a directory with many files compressed in it
>2) to compress a directory with uncompressed files in it
>
>I think 2).
Of course it's 2 !! :)
But my point was to get more free RAM (by using smaller ramdisks),
not more free space on disk!
Regards,
Claudio Neves
---------------------------------------------------------------------
To unsubscribe, e-mail: mulinux-unsubscribe@sunsite.auc.dk
For additional commands, e-mail: mulinux-help@sunsite.auc.dk
This archive was generated by hypermail 2.1.6 : Sat Feb 08 2003 - 15:27:14 CET