S komprimovaným filesystémem je jedno, jestli je to elf, skript v perlu, sdílená knihovna, katalog zpráv nebo topinkovač. Navíc se nemusím bát setuid a spol., všechno se děje transparentně v jádře.
Když mám na jednom filesystému dohromady adresáře a soubory, kam se neustále zapisuje (a nechci je komprimovat kvůli výkonu), se soubory, které jsou prakticky read-only, tak chce samozřejmě člověk zkomprimovat jen něco, ale nevím, jestli se pak nestala chyba někde na začátku ;-)
BTW dokumentaci jsem moc podrobně nečetl, ale bez explicitního EXTRA_LDFLAGS=-lstdc++ se mi UPX nějak nechtěl slinkovat, takže kdyby měl někdo podobný problém...
Tak ted mozna budu vypadat jako lama, ale na linuxu jsem zatim o komprimovanym disku jeste necetl/neslysel. To jako muzu udelat nejakej compressed ext3?
Treba patchnut jadro, potom uz budu pristupne volby ako chattr +c apod. Existuje niekolko druhov komprimovanych fs, zial uz som zabudol ako sa volal ten co som pouzival kedysi ja. Tusim e2compr, alebo tak nejako.
jen otazka nebo pokud je predpoklad spravny, tak varovani: OTAZKA:je pravda, ze linux ma jednu peknou vlastnost?
Pokud neni blok co je na disku oznaceny v pameti jako dirty(zmeneny), tak se neprovadi swapout, ale proste se zahodi s tim, ze je nekde na disku a muze se nacist pokud je potreba a nezabira jeste navic swap.
kdezto pri dekomprimovanych binarkach neni rozbaleny program ani na disku tedy ani v cache, takze se nemuze s klidnym svedomim zahodit pokud je potreba pamet s tim, ze by se nacetl z disku, ale musi se pro nej provest swapout.
takze jestli plati todle, znamena to, ze je to takrka nepouzitelne pro stare systemy s mnozstvim pameti mensim nez malym spolecne s pomalym diskem? protoze pak je zpozdeni pri dekompresi zanedbatelne ve srovnani se zatezi pri swapovani.
navic jeste vyvstava otazka, jak je cela sprava dekomprese navrzena a co se deje pri vicenasobnych exec() stejne binarky? znamena to, ze pred zavedenim se zavola kdo vi jaka funkce, ktera zjisti, jestli uz je nekde rozbaleny program a pouziji se jeho stranky, nebo se pro kazdy exec() vytvori nova kopie toho sameho programu? navic pokud plati prvni pripad spolecnych stranek, jak do toho vseho zapadaji bity readable/writeable u x86, znamena to, ze by potom proces uzivatel, ktery spusti bash prepise vlastni text procesu a zmeni tim text nejakeho bashe s euid=0?
atd.
Právě, že se pro každé spuštění vytvoří v paměti program znovu. A nezahazuje se, protože system ví, že ta binárka už v /tmp není. Paměťově je to tím pádem náročnější.
No me taky prijde toto reseni (komprimace binarek) mirne nevhodne ve srovnani s komprimovanym fs - hlavne proto ze mam dojem ze velikost binarek v /usr/bin, /bin a /sbin je zanedbatelna oproti knihovnam, dokumentaci, fontum, a vubec ulozenym datum... takze smysl jejich komprese mi trochu unika - navic treba na mem starem notebooku sem mel linux na asi 150mb... z toho byly binarky v /usr/bin a podobne tak maximalne 20mb - pokud bych tim usetril 10mb na disku ale zpomalil si uz tak pomaly pocitac, tak to mi nepride jako idealni reseni.
Nicmene je mozne ze nekomu se to hodi (jen nevim komu..)
no tak ono spustit upx /bin/* /sbin/* /lib/* neni zrovna moc dobry napad .. komprese binarek ma i sve nevyhody ... nicmene obcas se to hodi, treba na skolnim serveru, kde jsou 10Mb diskove quoty, tak moznost spakovat linkse z 2Mb na 400K celkem potesi :o) Dalsi moznost je pouziti treba na nejaky instalator, nebo neco co se spoyusti jen jednou za dlouhy cas .... tady se na usetrit. Nebo v ruzxnych miniditribucich .. ale jinak snazit se zakompresovat vsechny binarky jen pro usetreni trochy mista obvykle nikam nevede .... teda pokud toho miasta nemame opravdu malo :o)
Ale já jsem netvrdil, že to takhle mám a už vůbec ne, že to někomu paušálně doporučuju. Byl to test, kolik se dá ušetřit a tak je to i v článku napsáno. Je jasné, že to neřeší každou situaci a nevýhody jsou zmíněny.
"Také se nedoporučuje komprimovat soubory se sticky-bitem kvůli hrozícím bezpečnostím problémům." - nespletl se autor? Po pravdě řečeno mě nenapadá, jaké bezpečnostní problémy by ze sticky bitu mohly vzniknout.
Jak již bylo v článku napsáno, použitím standardních linuxových programů ldd a size na UPXem komprimovaný soubor získáme informace o zaváděči programu (malá deklomprimační rutina, kterou tam přidá UPX).
Narazil jsem při použití v /usr/local/bin. Pokud projedu binárku UPXem a potom stripem, dostanu 92 bajtový naprosto nepoužitelný soubor.
Ovšem UPX exceluje při použití na DOS a Win32 *.exe a *.dll. není výjimkou, že se 3 až 4 MB soubor po komprimaci vleze na disketu.
