Помнится, когда-то в девстве, когда вин2к ещё только появлялась, я на своем старом компе с 545-мб винчом сжал acrobat reader под 98 маздаем до ~1/3 от исходного размера, используя upx. приятно.
по теме - солидарен с остальными: upx бесполезен для linux.
В ядре FreeBSD очень давно существует pseudo-device gzip (если правильно помню): просто сжимаешь командой gzip бинарник - вуаля: и сжат, и работает :-)
Дурацкая новость. Всмысле, дурацкая подача новости.
Что значит не нуждается в комментариях?
Написано компрессор исполняемых файлов (не бинарников).
А нафига он нужен только для исполняемых? :)
/usr/bin заархивировать? Я не наезжаю, объясните плиз.
Типа скорость чтения с дискового накопителя много меньше чем скорость распаковки бинаря в памяти, так что теоретически данная приблуда должна способствовать не только экономии дискового пространства но и увеличению скорости загрузки исполняемого файла. Если не ошибаюсь, то похожая ситуация описана в документации к грабу, а именно подобным образом мотивируется зачем сжимать initrd.
Эта штука очень удобна для embedded и для создания вирусов маленького размера, что даже в шеллкод могут поместиться. В оффтопике - без нее вообще жить нельзя в некоторых случаях.
А от дизассемблирования не поможет, т.к. декомпрессить можно
Гыы основное предназначение - сжимать статично собранные бинарники..
Помнится на ЛОРе проскакивала инфа о джедаях грозившихся сделать дистр где все программы будут собраны статически, походу upx будет их основным инструментом ;)
> В ядре FreeBSD очень давно существует pseudo-device gzip (если правильно помню): просто сжимаешь командой gzip бинарник - вуаля: и сжат, и работает :-)
Этим убогим вечно неймётся, вот и gzexe получается ниасилили.
> Гарик ну е-мое,давай еще к каждому бинарнику по бантику сбоку вешать будем..
Для систем (в т.ч. и с мало-мало памяти) есть всякие squashfs, и т.п. - всего дело, написать модуль под FUSE. А нафиг вообще сжимать бинарники столь костыльными способами очень и очень неясно. Тем более, что read-ahead на винтах всяко болтается в районе отнюдь не "единиц килобайт", а по новомодным тенденциям (что КДЕ, что Гном) вся логика прячется в .so, а бинари - лишь пускалки большей частью.
> Чего по твоему тот-же вайн по трушному надо линковать с каждой вендовой программой пускаемой в линуксе?
Не, портировать целиком в нативную форму. А вайн и прочие вендовые порождения должны сдохнуть.
> Это ж не логично.
Да в мире суть столько всего ипанутого, что одним моментом больше-меньше - и не заметит никто...
Для начала читаем хотя бы то, что идет в комплекте с сабжем. Пробуем давить линкованые бинарники 8) Как ни странно - пашет, несмотря на просвещенное мнение некоторых "отцов" с ЛОРа 8)
А если серьёзно: далеко не так всё тривиально, как кажется на первый взгляд. Советую покопаться - авось сгодится 8)
>Для систем (в т.ч. и с мало-мало памяти) есть всякие squashfs, и т.п. - всего дело, написать модуль под FUSE.
Батько дык жать все надо далеко не всегда ведь. Этож медленнее и сложнее чем сжатие одного конкретного бинарника.Это не тру и попирательство юниксвей в чистом виде.
> А нафиг вообще сжимать бинарники столь костыльными способами очень и очень неясно.
Дык простота же - проблемой unpack'а заниматься приходится системе а не разработчику (пусть и в виде прикрученного унпакера).
> Тем более, что read-ahead на винтах всяко болтается в районе отнюдь не "единиц килобайт",
Дык подумай сам что больше винт терзать будет - сжатая фс или все же один сжатый бинарник
> а по новомодным тенденциям (что КДЕ, что Гном) вся логика прячется в .so, а бинари - лишь пускалки большей частью.
По новомодным тенденциям основа и там и там - система удаленного вызова процедур аля com самзнаешьгде.
Просветите, кто разбирается. Читал где-то, что в линухе бинарники при старте загружаются в память не целиком, грузятся только нужные секции файла. А если он будет пожат upx, то грузится будет всегда целиком (иначе не распакует).
Т.е. upx мало того, что не очень-то и нужен, но еще и вредить может достаточно сильно, так?
> Батько дык жать все надо далеко не всегда ведь. Этож медленнее и сложнее чем сжатие одного конкретного бинарника.Это не тру и попирательство юниксвей в чистом виде.
Дык с учётом же контекста нужно действовать - если нужно вбить на 1CD файла, что занимает на 1.5-2.0 оных, как тут иначе?
> Дык простота же - проблемой unpack'а заниматься приходится системе а не разработчику (пусть и в виде прикрученного унпакера).
Да ну нафиг тогда всё это сжатие на продакшенах, пусть так сидит где оно зело нужно и без него никак, теи более что память - она всегда работает, а вот процессор - отнюдь и запрягать его сверх меры тоже некошерно.
> Дык подумай сам что больше винт терзать будет - сжатая фс или все же один сжатый бинарник
Нужно всегда мерять, да и от самой FS многое зависит - есть же спецподелки для флэшек, что ресурс оных экономят, вот и тут так сделать можно.
> По новомодным тенденциям основа и там и там - система удаленного вызова процедур аля com самзнаешьгде.
Тоже должна сдохнуть :) AI можно построить и без неё, а дальше он сам всё построит.
>Да ну нафиг тогда всё это сжатие на продакшенах, пусть так сидит где оно зело нужно и без него никак,
Ну наверное помимо продакшна есть еще гопники с 700Мб винтами и желанием запихать туда в два раза больше
> теи более что память - она всегда работает, а вот процессор - отнюдь и запрягать его сверх меры тоже некошерно.
Ты про сбойные процессоры когда-нибудь слышал? А вот про сбойную память пишут постоянно.
>Тоже должна сдохнуть :) AI можно построить и без неё, а дальше он сам всё построит.
Прежде чем создавать искусственный разум неплохо было бы понять что есть настоящий.Иначе вместо послушного инструмента можно создать skynet и терминаторов.
> Ну наверное помимо продакшна есть еще гопники с 700Мб винтами и желанием запихать туда в два раза больше > теи более что память - она всегда работает, а вот процессор - отнюдь и запрягать его сверх меры тоже некошерно.
Добавь сам себя в фортунки, у меня рука не поднимется :) А дисковая память нынче стоит копейки, в отличие от памяти оперативной, благодаря добланым вендузятнегам и свисте. Да и ECC-шную память никто не отменял, nforce* её с незапамятных времён поддерживают, Интели так вообще на это дело крупно заложились.
> Ты про сбойные процессоры когда-нибудь слышал? А вот про сбойную память пишут постоянно.
Слышал конечно, иначе нафиг туда встраивают механизмы самотестирования и самокоррекции прямо на лету? Это ещё не считая богомерзких оверклокеров, что ради 5% прироста не пойми чего готовы генератор фреона в квартиру ставить.
> Прежде чем создавать искусственный разум неплохо было бы понять что есть настоящий.Иначе вместо послушного инструмента можно создать skynet и терминаторов.
Ну, дети тоже вырастают непослушными, типа подростковый нонконформизм, ага? Особенно когда вместо деревянных игрушек пулемёт "вулкан" на подвесах, а вместо строгой няни - разьедающие вендовые "мозги" вирусы.
Вот тебе и объяснение "терминаторства" - нафиг браться за воспитание, если ничего в том не смыслишь, а большинство родителей именно что "не смыслят", думая что решают проблему на лету.
>Типа скорость чтения с дискового накопителя много меньше чем скорость распаковки бинаря в памяти, так что теоретически данная приблуда должна способствовать не только экономии дискового пространства но и увеличению скорости загрузки исполняемого файла. Если не ошибаюсь, то похожая ситуация описана в документации к грабу, а именно подобным образом мотивируется зачем сжимать initrd.
При загрузке ядра чтение с диска AFAIR происходит без DMA, поэтому скорость и правда маленькая.
В случае gzip скорость распаковки обычных бинарников на Pentium 4 2400 MHz около 40 МБ/с, а степень сжатия - в два раза, скорость чтения при использовании DMA в середине харда - те же 40 МБ/с. Т. е. бинарник размером в 20 МБ сжимается до 10 МБ, он считывается за 0,25 с и распаковывается еще за 0,5 с, итого 0,75 с, когда мог бы просто считаться 0,5 с. А тут еще все это время используются ресурсы процессора, которые могли бы быть использованы на более полезные нужды.
Хм. помнится с upx была ОЧЕНЬ неприятная бага - оно требовало для этой самой in-place decompression МЕСТО НА ДИСКЕ ... которое, на забитом под завязку рам-диске при использовании двух прог разом - КОНЧАЛОСЬ! ....
Кстати, все высказавшиеся упускают одну маленькую деталь -- он хранит checksum бинарника - и теоретически - это можно использовать для проверки tamperring'а бинарных файлов.
Не, просто присутствующие в курсе что чексумингом ведает пакетный манагер, и гимора с дополнительной работой по проверке бинарей не очень желают. Или вы уже убедили rpm-щиков, deb-ианщиков и прочих сочувствующих юзать сие поделие?
Про лицензионные тонкости тоже забывать не стоит.
А вообще Оберхумеру спасибо стоит сказать вовсе даже не за UPX, а за lzo-навеску, вот где реальная польза для комьюнити.
Устарели на сегодня принципы которые используются в нем... хотя на безрыбьи и это рыба...
З.Ы. А те кто кричит что зачем оно нужно, при этом еще и сравнивают gzip пускай для начала поймут копрессор бинарников это не архиватор и тут другие принципы. Он будет эффективен только на большом бинарнике.
Вуаля и даже какойнить монструозный апачь целиком уменьшается в 3-4 раза и безо всяких UPX умещяется в какуюнить убогенькую embeded среду. Ну, а если хочется хардкору то и продукт этих манипуляций можно им зажать, но это даст максимум 1.6х уменьшение объема и увеличение времени старта в 2 раза так как половина того что делает UPX описана выше, а жать из того что получилось ему особо нечего.
Суть: elf32, elf64 megabloated поделия(хотя exe еще трагичнее)
Хреново он работает: распаковывает бинарник в /tmp, потом запускает. Гораздо правильней было бы распаковывать прямо в память, а потом передовать туда управление.
Посему - в топку, ибо bzip2/gzip/rar/7z рулят куда больше.
> Просветите, кто разбирается. Читал где-то, что в линухе бинарники при старте загружаются в память не целиком, грузятся только нужные секции файла. А если он будет пожат upx, то грузится будет всегда целиком (иначе не распакует).
Так не только в линуксе, но и в винде. При малом размере бинаря, это не так критично. Но при размерах в мег 5-20 это уже ощутимо.
> Т.е. upx мало того, что не очень-то и нужен, но еще и вредить может достаточно сильно, так?
Вы хорошо начали размышлять. Подумайте еще - найдете и положительные стороны данного пакера.
а жать нада чтоб на 32-метровую флешку всё уместилось вместе с иксами, картами и т.п... хотя проще 64-метровую купить и не париться, но сейчас есть только 32М...