UPX 3.00

> [...] используй ramfs (или что-то) в памяти.

забыл сказать: оперативки тоже 32 метра %) а там еще пререндеренные карты держать нада...

>Хреново он работает: распаковывает бинарник в /tmp, потом запускает. >Гораздо правильней было бы распаковывать прямо в память, а потом >передовать туда управление.

ты, наверное, только под дос программировал... на крайняк -- под винду :)) под линухом так -- нельзя ( в доках к упксу, кстати, про это написано). к тому же, учитывая наличие всяких дисковых кэшей, сильно подозреваю, что все по-любому останется в памяти...

>Посему - в топку, ибо bzip2/gzip/rar/7z рулят куда больше.

тебя в топку

>забыл сказать: оперативки тоже 32 метра %) а там еще пререндеренные карты держать нада...

Тогда начни с подбора старых версий хксов и всего остального. Которые были рассчитаны на такую среду.

> Тогда начни с подбора старых версий хксов и всего остального. Которые были рассчитаны на такую среду.

иксы то меня как раз слабо волнуют, я их обрезал достаточно неплохо, а вот с Qt4 не знаю что делать, занимают много, а делать свой конфиг для урезанной сборки Qt... я ж пока и сам не знаю, что из него использовать будут...

А тебе нужен именно 4й qt? 3й поменьше будет.

Вообще тогда можно пойти двумя путями - пытаться отхачить Makefile'ы при сборке qt на тему повставлять приведенные анонимусом `strip --strip-unneeded -R .comment -R .note *` или же если программа использующая qt будет одна - собрать программу статично с либами qt (только qt сам должен быть статично собран).Потом опять strip на получившийся здоровенный бинарь ну и пожать еще все upx'ом.

man mksquashfs

nano-X ? Qtopia? вобше лучше всего на сайте ослика посмотреть на sx1 он opie засовывал, вроде работало.

> ну не сам же я это придумал:

Виноват, каюсь. PE он жмёт и экзешники и библиотеки, поэтому я думал, что с ELF аналогично.

В любой POSIX системе можно подгрузить презагружаемую библиотеку которая заменит open() и т. д. на их декомпрессующие при необходимости аналоги, в том числе у загрузчика. Когда у меня был диск 80Mb -- использовал такое под Linux. Называлось libz или около того.

лучше бы сжатую файловую систему сделали, в NTFS давно такая фича есть, а у нас только jffs кривой а в досе Drivespace/Stacker ещё лучше было

>>Хреново он работает: распаковывает бинарник в /tmp, потом запускает. >Гораздо правильней было бы распаковывать прямо в память, а потом >передовать туда управление. >ты, наверное, только под дос программировал... на крайняк -- под винду >:)) под линухом так -- нельзя

а кто мешает сделать /tmp как tmpfs или ramfs?

Как сказали выше - это не "unix-way". Если вдаваться дальше в теорию ОС - есть переключатель исполняемых файлов в загрузчике, смотрит на magic number и определяет - как запускать исполняемый файл (например - a.out, ELF, shell script или для организации эмулятора исполняемых файлов другой архитекутры). Так скажите мне - на кой чёрт городить эти распаковщики бинарных файлов, библиотеки - если в самом ядре десятилетия назад было заложено решение такой проблемы ? Добавляем маленкий участок кода в ядро (там, где ему и пололжено быть) - и избавляемся от всех этих костылей.

>В ядре FreeBSD очень давно существует pseudo-device gzip (если правильно помню): просто сжимаешь командой gzip бинарник - вуаля: и сжат, и работает :-)

ну это намного лучше чем данный компрессор, имхо, и код распаковщика в памяти не храниться и проще.

>Этим убогим вечно неймётся, вот и gzexe получается ниасилили.

тут я с вами не согласен, удобнее когда не нужны подручные инструменты кроме самого архиватора

>А зачем ты им пытаешься библиотеки жать?

С каких пор библиотеки неисполняемые?

> полезный. им емакс можно сжать.

И для чего это полезно?

А ещё есть нотепад, им можно открыть исходники емакса. И чё?

> Ибо оперативки жрет больше пакованая прога. Плюс ресурсы - они тоже в оперативку сразу грузятся.

И ещё - оно при каждом старте приложения попусту гоняет проц для распаковки.

> Помнится на ЛОРе проскакивала инфа о джедаях грозившихся сделать дистр где все программы будут собраны статически,

Кстати, где они сейчас? Хотелось бы расспросить о достижениях, о творческих планах... А то, может, грибы им ещё что-нибудь насоветовали? :)

> проверял? че языком зря молоть?

Я проверял. Памяти жрёт ненамного, но больше.

> Классная штука, если проги на Qt статически компилишь для чего-нить, то жмёт хорошо да и грузиццо быстрее. (У мну наверн хард голимый)

А нах ты их статически компилишь?

>В случае gzip скорость распаковки обычных бинарников на Pentium 4 2400 MHz около 40 МБ/с, а степень сжатия - в два раза, скорость чтения при использовании DMA в середине харда - те же 40 МБ/с. Т. е. бинарник размером в 20 МБ сжимается до 10 МБ, он считывается за 0,25 с и распаковывается еще за 0,5 с, итого 0,75 с, когда мог бы просто считаться 0,5 с. А тут еще все это время используются ресурсы процессора, которые могли бы быть использованы на более полезные нужды.

Интересно, конкретные цифры! А можно поподробнее про методику тестирования?

>Интересно, конкретные цифры! А можно поподробнее про методику тестирования?

tar cf usrbin.tar /usr/bin

du -hs usrbin.tar

gzip -9 usrbin.tar

du -hs usrbin.tar.gz

time gunzip <usrbin.tar >/dev/null

usrbin.tar уже находится в памяти в файловом кеше, потому что памяти 1GB и она по большей части свободна.

Скорость распаковки не меняется при gzip от -1 до -9. bzip2 в 10+ раз медленнее распаковывает.

Скорость харда меряется:

sudo hdparm -t /dev/hdaX # зависит от положения на диске начала раздела.

Специально для флешек на embedded device есть такая вещь, как jffs2/3.

а мне нравится :) написал прогу, сжал - и люди будут думать, что ты пишешь компактные полнофункциональные проги, и вместо покупки толстых программ, будут покупать твою

Она только для чтения.

кстати, помнится, lnx-бинарники упакованные этой хернёй под obds умеют только в корку падать, что впрочем верно и для самой тулзы, которая кроме того нативно даже не компилилась. т.ч. в печку

А мужики-то и не знают.

не, jffs это чтение-запись но есть 2 нюанса:

1 она требует байтового mtd-устройства, на обычных блочных устройствах только через жопу в ядре 2.6 можно использовать

2 она глючит как срань господня, при интенсивном использовании появляются ошибки, больше и больше, до тех пор пока ФС не посыпется вообще (а jffs2chk в природе не существует)

это я по опыту использования этой шняги на заурусах