Re: FYI: dh_upx compresses i386 executables
Ethan Benson [EMAIL PROTECTED] wrote: On Sun, Apr 22, 2001 at 09:00:13AM -0400, Itai Zukerman wrote: you want. The postinst code would call the compression routines, which might not do anything, depending on how the compressing package was configured (i.e., it wouldn't call the compressing code directly, but through a wrapper). makes sense Not if UPX were to be an option for all binaries. Having to add stuff to every package's postinst is evil (see /usr/doc, although that was necessary). -- Colin Watson [EMAIL PROTECTED]
Re: FYI: dh_upx compresses i386 executables
On Tue, 24 Apr 2001 13:14:36 +0100, [EMAIL PROTECTED] (Colin Watson) wrote: you want. The postinst code would call the compression routines, which might not do anything, depending on how the compressing package was configured (i.e., it wouldn't call the compressing code directly, but through a wrapper). Not if UPX were to be an option for all binaries. Having to add stuff to every package's postinst is evil (see /usr/doc, although that was necessary). It seems to me that each maintainer should make the decision of whether she wants UPX to apply to any of her binaries. And the easiest way to do that, IMO, is to have her add [ -x install-upx ] install-upx /usr/bin/foo /usr/bin/bar to her postinst or dh_upx to her rules. /usr/doc was evil for a number of reasons other than adding a line to postinst. You seem to want *all* binaries compressed. I'm suggesting that some binaries are best left uncompressed, and that that would be the maintainer's decision. -itai
Re: FYI: dh_upx compresses i386 executables
On Tue, Apr 24, 2001 at 01:14:36PM +0100, Colin Watson wrote: Ethan Benson [EMAIL PROTECTED] wrote: On Sun, Apr 22, 2001 at 09:00:13AM -0400, Itai Zukerman wrote: you want. The postinst code would call the compression routines, which might not do anything, depending on how the compressing package was configured (i.e., it wouldn't call the compressing code directly, but through a wrapper). makes sense Not if UPX were to be an option for all binaries. Having to add stuff to every package's postinst is evil (see /usr/doc, although that was necessary). ok, then have the upx package ask if the admin wants to compress /* it seems there is only a few ways to do this: 1) add crap to postinst. -- evil 2) packages just compress at build time -- beyond evil, don't even think about it. 3) add all the questions/compression tasks to the upx package itself. option 3 seems to be the only semi sane/non-evil way. -- Ethan Benson who personally finds the idea of upx hideous. http://www.alaska.net/~erbenson/ pgp5C4lPHa5tw.pgp Description: PGP signature
Re: FYI: dh_upx compresses i386 executables
On Tue, Apr 24, 2001 at 09:14:41AM -0400, Itai Zukerman wrote: It seems to me that each maintainer should make the decision of whether she wants UPX to apply to any of her binaries. And the easiest way to do that, IMO, is to have her add [ -x install-upx ] install-upx /usr/bin/foo /usr/bin/bar to her postinst or fine dh_upx to her rules. /usr/doc was evil for a number of reasons other than NO! this would absolutly suck. that leaves the admin in the position to have to rebuild the package or fsck with decompression every time the package is upgraded to get a fulltime normal non-upx binary if they don't want this crap. You seem to want *all* binaries compressed. I'm suggesting that some binaries are best left uncompressed, and that that would be the maintainer's decision. and more importantly the admins' decision. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpBUqqTYemzA.pgp Description: PGP signature
Re: FYI: dh_upx compresses i386 executables
On Tue, 24 Apr 2001 05:30:18 -0800, Ethan Benson [EMAIL PROTECTED] wrote: [ -x install-upx ] install-upx /usr/bin/foo /usr/bin/bar to her postinst or fine dh_upx to her rules. NO! this would absolutly suck. that leaves the admin in the position to have to rebuild the package or fsck with decompression every time the package is upgraded to get a fulltime normal non-upx binary if they don't want this crap. I think you misunderstood: I meant that dh_upx would just add the line above to the postinst, like a number of other debhelper things do. I agree that having debs contain compressed binaries is a bad idea. -itai
Re: FYI: dh_upx compresses i386 executables
Recent versions of upx can compress a linux bzImage (I've seen 13% shaved off a bzImage). debian-installer may use it to squeeze more onto the single floppy (kernel + initrd with modules). David Sat, Apr 21, 2001 at 06:25:10PM -0700 wrote: On Sat, 21 Apr 2001, John H. Robinson, IV wrote: however, on something like boot-floppies, this might be a goddess-send. No, it isn't. gzip -9 already applied to the floppies is very close to the gziped upxed binary size. I tried upx on the boot floppies last release (from which this claim is based). Andrew Lenharth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: FYI: dh_upx compresses i386 executables
On Sun, Apr 22, 2001 at 11:39:07PM -0700, David Whedon wrote: Recent versions of upx can compress a linux bzImage (I've seen 13% shaved off a bzImage). debian-installer may use it to squeeze more onto the single floppy (kernel + initrd with modules). Isn't that slightly redundant? A bzImage is compressed in the first place. If anything, it should compress the vmlinux.
Re: FYI: dh_upx compresses i386 executables
Alexander Hvostov [EMAIL PROTECTED] wrote: Since UPX only runs when a program is loaded, and only takes a few seconds to do its thing, I see no reason why weaker (eg, 486) machines couldn't handle it. Even on old 386 machines, the slowdown shouldn't be much of a headache, unless what's being compressed is a very frequently executed program (like `ls'), in which case it'd be better not to UPX it. In any event, UPX shouldn't matter to people with fast machines (who have plenty of disk space and plenty of CPU power), and would benefit people with small disk drives (who can probably live with the small load time delay). For these reasons, I agree with the sentiment that UPX should be used on almost all (if not all) executables shipped with Debian. The reliability aspects (executables suddenly start failing if you temporarily run out of hard disk space in /tmp or wherever) would be a killer for me. (Given this, compressing /bin/rm would be extremely foolish. :)) Incidentally, I assume the temporarily decompressed executables created by UPX are mode 700? -- Colin Watson [EMAIL PROTECTED]
Re: FYI: dh_upx compresses i386 executables
On Mon, Apr 23, 2001 at 11:35:12AM +0100, Colin Watson wrote: Incidentally, I assume the temporarily decompressed executables created by UPX are mode 700? I would hope that they have the same permissions as the originals. And I don't want to imagine what might happen with a suid excecutable...
Re: FYI: dh_upx compresses i386 executables
Aaron == Aaron Lehmann [EMAIL PROTECTED] writes: Aaron I would hope that they have the same permissions as the Aaron originals. And I don't want to imagine what might happen with Aaron a suid excecutable... The unstable version of UPX (1.11) doesn't use the tempfile approach anymore. From the NEWS: * linux/386: added the new direct-to-memory executable formats - no more temp files are needed for decompression! See the homepage (http://upx.tsx.org) for more info. -- Bye, Peter Korsgaard
Re: FYI: dh_upx compresses i386 executables
On Sat, Apr 21, 2001 at 07:42:00PM -0300, Carlos Laviola wrote: There is: just upx -d it. (you can even run md5sum before and after compression/decompression to find out for yourself that the decompressed file is the same as before.) Will upx -d work on a binary that was compressed with an older version of upx? The code I've seen doesn't seem to care much about that, so I wonder if the author considers it a design requirement at all. Richard Braakman
Re: FYI: dh_upx compresses i386 executables
On Sun, 22 Apr 2001 00:57:54 +0200, [EMAIL PROTECTED] wrote: On Sunday 22 April 2001 00:45, Itai Zukerman wrote: Why not compress the binaries in the postinst, maybe after asking the admin for permission? Well, if I had to answer no to compression for binary in every new package I installed, I'd go nuts rather soon. If, however, it was made the responsibility of the system somehow, packagers needn't worry of it at all, users only had to answer once, and whoever had to implement had to do the work, and nobody had to duplicate it, allowing him to feel nice about himself. Yes, dpkg needs some way to define hooks, things to be run against every installed package. That should take care of compressed binaries and purging locales documentation. Maybe dpkg already has such a thing. If not, I suggest a debhelper command to add the necessary code to the postinst. Packages that use this should, of course, depend on the binary-compressing package, which would provide the one-time question you want. The postinst code would call the compression routines, which might not do anything, depending on how the compressing package was configured (i.e., it wouldn't call the compressing code directly, but through a wrapper). Any objections? -itai
Re: FYI: dh_upx compresses i386 executables
On Sun, Apr 22, 2001 at 09:00:13AM -0400, Itai Zukerman wrote: If not, I suggest a debhelper command to add the necessary code to the postinst. Packages that use this should, of course, depend on the binary-compressing package, which would provide the one-time question why should they depend on it? if its not installed that should imply that the admin does not want compressed binaries. you want. The postinst code would call the compression routines, which might not do anything, depending on how the compressing package was configured (i.e., it wouldn't call the compressing code directly, but through a wrapper). makes sense Any objections? see above -- Ethan Benson http://www.alaska.net/~erbenson/ pgp84tJynUGQt.pgp Description: PGP signature
Re: FYI: dh_upx compresses i386 executables
On Sun, 22 Apr 2001 06:02:30 -0800, Ethan Benson wrote: On Sun, Apr 22, 2001 at 09:00:13AM -0400, Itai Zukerman wrote: If not, I suggest a debhelper command to add the necessary code to the postinst. Packages that use this should, of course, depend on the binary-compressing package, which would provide the one-time question why should they depend on it? if its not installed that should imply that the admin does not want compressed binaries. OK, I believe doc-base and install-docs is handled this way. Then, later you could install the compressing package and run dpkg-reconfigure on those packages that you want compressed? -itai
Re: FYI: dh_upx compresses i386 executables
On Sat, Apr 21, 2001 at 11:50:44AM -0700, John H. Robinson, IV wrote: On Sat, Apr 21, 2001 at 11:41:56AM -0700, Alexander Hvostov wrote: On Sat, 21 Apr 2001 11:40:15 -0700 John H. Robinson, IV wrote: however, on something like boot-floppies, this might be a goddess-send. What about filesystem-level compression? http://www.netspace.net.au/~reiter/e2compr/intro.html : I wouldn't use e2compr on a ``production'' machine (where neither faults nor delays are tolerated). I would say the same about 2.4 kernel :-) i would have to say no to that. if there were indication that it was ready to stabalize and be ready for prime time, then add it to unstable and wait for bugreports (make it an option, of course). I've run it for years (well, almost 2 :-)) on a heavily loaded production server without any problems whatsoever... -- --- | Radovan Garabik http://melkor.dnp.fmph.uniba.sk/~garabik/ | | __..--^^^--..__garabik @ melkor.dnp.fmph.uniba.sk | --- Antivirus alert: file .signature infected by signature virus. Hi! I'm a signature virus! Copy me into your signature file to help me spread!
Re: FYI: dh_upx compresses i386 executables
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.
