Názory k článku Komprimační program RZIP

Peknej clanek...

No na úspěch rzipu bych si tedy nevsadil. Ne, že by byl tak špatný, ale změna se prostě nevyplatí.

Ten popis těch algoritmů se mi moc nelíbil. gzip, bzip a rar jsou postaveny každý na něčem jiném.

O gzipu toho vím prd, ale tipnu si, že je to obdoba "klacického zipu" - to znamená LZW + neco navíc.

Bzip je postanen na jakési transformaci Burrows-Wheeler. Ta je sama o sobě docela výkonná, ale pravděpodobně tam už není moc velký prostor pro zlepšení. A jestli autor rzipu nějak vylepšil to předzpracování, tak je to jistě teoretický úspěch.

RAR je podlě mě o třídu lepší než výše zmiňované. Obsahuje pokročilé kontextové modelování. Zajímavé je, že vylepšení kontextového modelování nazývané Information Inheritance bylo do RARu 3 implementován snad dřív, než byl dotyčný článek dostupný v angličtině :-) Azbukou jsou psané nejen nejlepší učebnice matematické analýzy :-)

LZW používal snad compress a GIF, zip a gzip používaj deflate (LZ77+Huffman)

jinak já čekám na linuxovej port 7-zipu (http://7-zip.org), to je můj favorit

Přesně tak, 7-ZIP má nejlepší kompresní poměr -- a to bez diskuze. Windows verze je neskutečně pomalá, ale jak autor tvrdí, může za to špatné zacházení Windows s pamětí.

Linux port bude již brzy stejně také jako rozdělování do svazků.

tak jsem právě zkoušel ten 7-zip, a RAR je pořád můj favorit

Podle toho, co pisou na www.win-rar.com, RAR pouziva modifikaci algoritmu LZSS, coz neni kontextove, ale slovnikove modelovani.

Nekde nize take pisete, ze serazeni souboru dle pripony pomuze kontextovemu modelovani. Myslim, ze v pripade RARu to spise pomaha principu tzv. "solid" archivu, ktery spociva v tom, ze komprese dalsiho souboru nezacina s prazdnym slovnikem, ale pokracuje se starym slovnikem (tak, jak zustal po kompresi posledniho souboru). Soubory se stejnou priponou budou asi mit podobny obsah, takze je kvuli lepsimu vyuziti slovniku lepsi komprimovat za sebou.

Take jsem nekde slysel, ze RAR je tak uspesny protoze zkousi najednou vic metod a vybira z ni tu s nejvyssim kompresnim pomerem. Ale nemam k tomu zadne detaily, takze to taky nemusi byt pravda.

(Win)Rar od verze 3 (mozna 2.8) sice dale obsahuje nejakou podobu slovnikove metody.
Navic ale obsahuje implementaci kontextoveho modelovani, konkretneji temer urcite PPM II (Prediction by Partial Match v modifikaci Information Inheritance).
Nevim, jestli byla tato metoda v testu zapnuta (nejspis ne), ale pokud ne, urcite by dala jeste lepsi vysledky (navic s pouzitim solid archivu).

Jinak popis principu fungovani obecneho komprimacniho programu v clanku je *HODNE* nepresny. (Co treba zminovane kontextove modelovani??).

Ja se naopak divim, ze se autor porad tak divil nad tim, jak je rar dobry!-)

Vidíš, ono to unixové tar.gz je vlastně docela dost debilní. Takový rar si při pakování aspoň setřídí soubory podle přípony. Kontextovému modelování to občas _dost_ pomůže.

Mno to neni ale chyba formatu, ale chyba taru ... je fakt, ze kdyz jsem u archovu, ktery obsahuje mnoho podobnych adresaru rucne pomoci seznamu souboru zmenil poradiv jakem tar bere soubory (a nasledne pak cpe archiv bzipu) tak jsem dosahl pomerne podstatneho zlepseni komprese (uz nevim presne kolik, ale radove se archiv smrsknul azi z 600 Kb na 450Kb nebo tak nejak ...) Bohuzel tar sam o sobe soubory dle pripony seradit neumi ...

..tak zkus neco jako:

find foo-1.0|sort ....|cpio -o|gzip >foo-1.0.cpio.gz

Rozhodně, unixové tar.gz je naprosto debilní a proto se vůbec nepoužívá a všichni používají rar! Nejlepší by bylo, kdyby všichni přešli na něco mnohem chytřejšího...doporučil byste nám něco pane chytrý?

Hmm, jenomze tar, gz jsou zdarma. Ne tak rar.

.tar.gz se podle me pouziva kvuli kompatibilite. Ostatne proc byva spousta programu k dispozici pro stazeni jak v .tar.bz2 tak i v .tar.gz? Pro srandu kralikum?

Tim, ze se nejaky format/program/OS pouziva mnohem vic nez jiny, bych si NIKDY netroufnul argumentovat, pokud by predmetem diskuse bylo to, zdali je onen format/program/OS kvalitnejsi nez jiny, mene pouzivany ...

No, on bude problem asi v tom, ze tar je primarne urcen k necemu jinemu, nez ke komprimovani, takze mu asi nelze vycitat, ze netridi soubory optimalne pro ucely komprimace.

Nic Vam nebrani pustit find, setridit jak chcete a pak na to zavolat TAR + GZIP.

Nic Vam nebrani pustit find, setridit jak chcete a pak na to zavolat TAR + GZIP.

asi tak nejak...
na trideni mame sort.
dle filosofie linuxu/resp. unixu je to tedy takto:
sort(setridime) -> tar(spojime) -> bzip(komprimujeme)
je pravdou, ze nejaky preprocesor sity na miru pro tar/compress by se (zda se) hodil.
rar je opravdu _velmi_ kvalitni nastroj.
je vsak komercni se vsim co k tomu patri...
rzip se zda byt potencialnim souperem.
uvidime co predvede jiz zminovany 7-zip.
nemoznost spojovani rzipu rourou ho totiz degraduje na rucni nastroj, a to neni dobre.
Petr

kdyz takhle distribujete zdrojaky, tak vetsina souboru je stejeho typu, dokumentace byva ve samostatnem adresari, takze se zhruba zase obsahem podobne soubory dostanou k sobe i bez trideni.
Warezakum zase necini problem si ukrast rar, kazdemu co jeho jest :)

No nevim. Kdyz jsem onehda testoval ruzne komprimacni formaty tak mi vychazelo daleko lepe *.tar.rar nez cisty *.rar co se tyce vysledne velikosti. Zkouseno na cca 1,2 GB dat, cca tisic adresaru a desetitice souboru.

Nakonec jsem zvolil tar.gz (a to na Win platforme ;-)) a to z duvodu rychlosti. Tech "par" mega navic je vice nez vyvazeno ani ne polovicnim casem komprimace i dekomprimace (v souladu s tabulkou v clanku). Coz pri vetsich velikostech archivu uz je poznat.

Takze IMHO ani tar samotny ani tar.gz nejsou az tak debilni.

Mna by strasne zaujimalo porovnanie s kedysi pomerne rozsirenym ACE archivom. Aj ten sa dost hojne pouziva v spominanom warez. Existuje vobec nejaky port na unix? Musim pozriet :)

Vyhodou ACE byvala multimedialni komprese a 4MB slovnik. Diky tomu se pouzival ve Warezu na komprimaci her. S nastupem Winraru 3, ktery rovnez umoznil multimedialni kompresi a zvetsil slovnik na 4 MB se mi zda, ze i v teto oblasti je lepsi nez ACE. Zkousel jsem je mnohokrat porovnavat a Winrar mi vysel vetsinou o kousek lepsi.

Ja osobne pouzivam Ace 2.5. V testech mi vysel lepe nez RAR 3.3. Ovsem nejlepsi je stejne 7-Zip (http://www.7-zip.org/)

Opravdu zajimave vysledky. Slabinou bzip2 dosud byly soubory s vyssi entropii (programy, daove soubory atp.), zato exceloval na souborech s nizsi entropii (zdrojaky). Zrejme to bylo zpusobeno tim malym bufferem, ktery na texty byl dostacujici, ale na ostatni soubory suboptimalni. Rzip rozsirenim bufferu tuhle vlastnost eliminuje...

Neefektivita bzip2 na netextove soubory je spis zpusobena tou vyse zminenou Burrows-Wheeler trasformaci. Princip funkce bzip2 algoritmu je dost huste cteni. :-) Neco vyslo i tady na root.cz: http://www.root.cz/clanek/1610

Procpak se autor nezminil o zipu? Info-zip ho ma snad na vsechny OS zdarma vcetne zdrojaku. Alespon pro srovnani si myslim, ze ho mohl zminit.

Obávám se, že by výsledky byly vždy o pár bytů horší než gzip. Onehdá jsem koukal do jakýsi knihovny na vyrábění zipů v PHP a masivně to využívalo gzip. Je teda možný, že skutečný zip se chová jinak a může používat i jiné kompresní algorytmy (nevím, tak dalece jsem to nezkoumal, já tu knihovnu potřeboval modnout tak, abych viděl velikost výsledného zipu ještě než ho uzavřu, neb jsem tím dělal zálohy a potřeboval jsem je dělit zhruba po 2MB kusech).

Ano, souhlasím, bylo by to zajimavé...

... jenom stourava - algoritmy vetsinou rytmus neznaji :)

No zabudli ste na to, ze ak sa na kompresiu do formatu bzip2 pouzije urcita cast pamate pre buffer, taka ista cast pamate musi byt pouzita na dekompresiu. Taze ak nieco zkomprimujete na stroji s 2GB RAM a potom to budete chciet dekomprimovat na nejakom starom routri 64MB RAM, ta neviem neviem ... Ako je tomu s rzip?

Dobrá poznámka. Vzhledem k velikosti bufferu u bzipu bych to neřešil (ikdyž bych si dokázal představit zařízení, kde by i to byl problém téměř neřešitelný), ale těch 900MB u rzipu mne trochu děsí, aneb zvolna začínám chápat, proč se to nemá rádo s rourama ;-). (Ne že bych zkoumal zdrojáky, jen mne to vede k myšlence, jak by se to ,,taky'' dalo udělat.aby to nepotřebovalo tolika paměti. Seek and seek and seek... ;-)

Proc seek a seek? Rozumne systemy maji mmap(), co se vejde do bufferu a cache se pak cte z pameti i bez seekovani. Kdyz je volna pamet, tak se vyuzije.

Nejsem expert na kompresni algoritmy, ale domnivam se, ze pri dekopmpresi neni vyzadovan tak velky buffer jako pri kompresi. Pri kompresi je totiz buffer vyuzivan pro hledani redundance - cim je vetsi, tim se ji tam muze najit vice.

Navic, jestli jsem to dobre pochopil, tak ten buffer s kapacitou 900MB neni umisten v pameti; misto toho se provadi seek nad vstupnim souborem. A prave proto rzip neumi cist z roury.

U bzip2 stejne velky buffer vyzadovan je. Kouknete vyse na mnou uvedeny link.

Pokud manuálová stránka od bzip2 není výtvorem barona Prášila, pak platí:

* na kompresi je potřeba 400K + 8*block_size
* na dekompresi 100K + 4*block_size
* s "--small" stačí na dekompresi 100K + 2.5*block_size

Dekomprese tedy opravdu je paměťově náročnější než komprese, ale obojí je lineární ve velikosti bloku.

> Dekomprese tedy opravdu je paměťově náročnější
> než komprese, ale obojí je lineární ve velikosti
> bloku.

Martin, nemyslel si to s tou kompresiou/dekompresiou nahodou naopak?

Z principu Burrows-Wheeler transformace (nezabyva se kompresi), kteru bzip2 pouziva, se mi zda, ze pred kompresi je potreba velikost_bloku^2 a pred dekompresi 3*velikost_bloku. Kolik si vezme kompresni algoritmus je vec jina, ale me to funguje s takovymito naroky.

Pokud jde o dekompresi. Rzip ma stejne pametove naroky jako bzip2 a je dokonce o trochu rychlejsi. Jinak doporucuji si prohlednout zdrojovy text rzipu. Je zalozen na velmi jednoduche myslence.
Dobry je psat komprimacni program jako preprocesor k overenemu algoritmu. Ja jsem napsal 2 komprimacni programy, protoze std. algoritmy na tech datech nezabiraly. Kdybych to napsal jako preprocesor k zipu, usetril bych si mnoho prace a starosti.

Nie tak celkom. Velky buffer potrebny na kompresiu je dobry na do aby sa nasla redundancia v uvedenom bloku dat. Pre rozzipovanie vacsinou staci uz najdenu redundanciu spracovat. Pri zazipovani je teda dobre mat velky buffer a hladat v nom, zatialco pri rozzipovavani nam staci poradit si s diskovymi operaciami (samozrejme buffer pomoze)

Da sa to zhruba povedat aj takto: rozzipovanie moze potrebovat menej pamate, pretoze pracuje so zazipovanymi datami, ktorych je menej ;)
Inac by sa subory obcas nedali rozbalovat na pocitaci ktory ma menej pamate ako ten na ktorom boli balene :)

Samozrejme to zavisi na pouzitom algoritme.

stejne nechapu, proc vsichni pouzivaji takovy exotiky jako .ZIP, .TAR.GZ, .Z, ... kdyz stejne nejlepsi kompresni pomer (o ktery jde predevsim) ma porad RAR a nic se mu nevyrovna. byt na me, ZIP bych zakazal! to je tak debilni format, ze to neni mozny. tem co se v nem a v jeho strukture trosku vrtali nemusim nic vysvetlovat...
slava RARu!

No ony ty "exotiky" jsou defaultne ve vetsine Unix-like OS, coz je urcite docela rozumny duvod, proc nejsou zakazany ... :-)

Skus RARem zazalohovat treba /home aby ti to uschovalo prava a hardlinky. To TAR umi.

$HOME bych si klidne zazalohoval v RARu.. proc ne?

linux RAR 3.20, Shareware:
switches:
ol - Save symbolic links as the link instead of the file
ow - Save or restore file owner and group

Rozdil spis je v tom, PROC bych to chtel delat? na unix-like systemech najdete tar + gzip/bzip2 (skoro) vzdy. Je to neco podobneho, jako kdyz se muzete spolehnout na tom, ze sednete k unixu a najdete tam nejaky klon vi.

No ma to jeste jeden neprijemny hacek, co kdyz pouziam nejaky hyper-super souborový systém, který má nejaké metadata o kterých se autorovy raru ani nesnilo? To pak si mám zažádat o nejký jeho klon speciálně jen pro mě? Stejně by výsledkem bylo cosi, co už není rar. Není jednodužší si dudělat svůj vlastní serializátor typu tar a pak to prohnat rourou co to skomprimuje? IMHO proto jsou tyhle rar, rzip a podobné hračiky vhodné jen k něčemu, kdežto gzip je věčný :-) I ten bzip2 s tou svojí, byť malou, potřebou paměti strácí okrajové pole embedded OS. Tady mu může maximálně konkurovat UCL, který používá UPX.

hm, ale kdyz si napises vlastni tar, tak to pak muzes prohnat gzip-em a stejne dobre tak i rar-em nebo cosik_jineho_zip-em, takze jestli to chapu, tak gzip ti v tomhle smeru dava navic to, ze ten tar umi pustit pred kompresi - coz zas neni neprekonatelna prekazka

Jo, ale reagujes na hlasku o hardlinkach; to jsou linky ktere vedou na kazdy soubor a na bezne soubory jich muze vest prakticky neomezene mnozstvi, fakticky pochopitelne poctem inodu ci pocitadlem hlinku, ale to je vetsinou tusim prez 1024, coz bezne staci. Kdyz je ale takovy komprimacni program neumi, razem nabude velikost; kdyz ne komprimatu (soubory se namnozi a budou stejne, takze idealne nazvy navic), tak alespon rozbalenych dat. Pochopitelne s tim souvisi znefunkcneni veci vazanych prave na tyto linky, takze pro nektere archivy je to nepouzitelne.

Tak jsem vyzkousel 7zip vs rar, nastaveno na maximalni kompresi a 7zip jasne vyhral. Jeho nevyhodou je dost velika spotreba pameti a hodne pomala komprimace okolo 200 kb/s.

pdf soubor 1.714.968 b
rar 542.778 b
7zip 485.807 b

txt soubor 10.339.136 b
rar 502.582 b
7zip 349.407 b

200kb/s je hodne uzitecna informace, kdyz nezname zatez systemu, rychlost disku, propustnost pameti, pocet preruseni, delku casoveho kvanta scheduleru a rychlost procesoru... ;-)

Takovy dotaz, kde je oficialne dostupny port RARu (nejlepe pro linux) s GPL licenci?

Nikde, RAR je komercni program - volne pouzitelny je pouze dekompresni program (unrar) - ale mam dojem ze ani ten neni pod GPL

No, to mi prave prijde jako v podstate diskvalifikujici nevyhoda, a zaroven odpoved na Bennyho otazku, proc pouzivat neco jineho.

Protoze o kompresi samotnou az tak moc zase nejde.
Vetsinou jde o to zabalit a rozbalit to v "rozumnem" case a "rozumne" dobre a mit jistotu, ze az to budu potrebovat, tak to taky rozbalim.

(Jinak bych doporucoval prejit na PigZip (viz
http://www.hackles.org/cgi-bin/archives.pl?request=310 a http://www.hackles.org/cgi-bin/archives.pl?request=314
)

No a taky tady jde o "stylovou cistotu" a o to, ze nechci ostatni nutit, aby si kupovali ten samy sotware, ktery jsem si koupil ja. (Protoze normalni je nekrast.)

Tak, tak. Ani UNRAR neni co se tyce licence uplne "koser". Proto napriklad NetBSD-ports vyzaduji vyslovny souhlas s jeho kompilaci:

/etc/mk.conf

ACCEPTABLE_LICENSE=+UNRAR_LICENSE

No, minimalne ZIP udrzuje central directory, takze na rozdil od debilniho RARu nepotrebuju pri vypisu nazvu souboru v archivu seekovat po celem 300-megabajtovem archivu, coz vyjde skoro nastejno jako jeho dekomprimace.

Kdyz tu tak ctu ty flamy tak me napadlo:

Kdysi jsem na stare 286ce se 40 MB HDD travil hodiny zkousenim jestli je lepsi arj, rar nebo zip a jake jsou nejlepsi prepinace. Tenkrat jsem totiz pouzival 1.2MB diskety.
Dneska mi pripada, ze je to ve vetsine pripadu nepodstatne a nejlepsi je neco co ma maximalni mozne mnozstvi features a bude to pokudmozno mit vetsina lidi kterym to poslu. Tedy tgz, popr. tbz2
btw.-

Přesně, jsme v době, kdy je sice pěkné že si stáhneme o 200 kb menší soubor z netu a že se jich na disketu vejde o to víc, ale.

Kdo dneska přenáší data po disketách - ano sou tací, ale je jich čím dál méně. Na internetu to ještě pociťuje více lidí, hlavně třeba ti co platí za přenesená data. Nicméně, pokud se bavíme o běžném přesunu normálních souborů, očekává se že budou běžně použitelné na dalších stanicích, systémech.

Pokud si děláte zálohu partice, či nějaké databáze nebo co já vím nějakého extra velkého obsahu a je určena především pro Vás, pak můžete použít extra nástroj, kterým pochopitelně disponujete.

najlepsi byl stejne komprimator v m602 :)))

naprosto souhlasim.

Nene, nejlepsi byl PowerPacker na Amize!!! (Pri pakovani moc pekne blikal ruznejma barvickama ;-)))

Jo PowerPacker byl skvelej. :-) Tech softu bylo vic a pamatuju i nejakej, kterej pri pakovani hral. :-)

No právě. Při pakování se dalo nastavit, co bude při rozpakovávání blikat. Často byl nastavený border. Když jsem pak kamarádovi PCčkářovi ukazoval Amigu, tak znechucen povídal "vždyť to nahrává jako Spectrum" :-)
Pro nepamětníky - když spectrum tahalo z kazety, tak přes obrazovku jezdily barevné pruhy.

Spectrum umelo pri rozbalovavani blikat taky. Pouzivalo se to ve hrach, ktere vznikly na zacatku 90. let.

Ja teda neviem, nerozumiem, preco je velkost vstupneho bufferu 900MB. Autor sam hovori o tom, ze "rzip is not for everyone!",kedze zerie pamat a moze sa stat, ze ked budete komprimova 10 GB dat, tak si to skutocne schrustne z vasej ramky(swapu) 900 MB. Preco potom niekto nevymysli program, kde by som si velkost bufferu mohol urcit sam podla dostupnej pamate nejakym prepinacom (mam 4 GB,tak chcem pre rzip 2 GB buffer)? Ci bolo by to sialene pomale?

Ahoj,

uz drive me napadlo drobne zlepseni stavajiciho tar.bz2, a to, ze by se nejprve vstupni soubory projely pomoci file(1), a shlukly ty, ktere maji stejny (nebo podobny) typ. Mozna by to bylo temer stejne ucinne a nevyzadovalo by to novy format.
Popr. dale shlukovat podle pripony a podobnosti jmena.

Stejne nechapu kam tenhle souboj vede, protoze rozdili mezi kompresnimi algoritmy jsou mizive. Z prominutim pristup na internet i ulozna media se za poslednich 10 let minimalne 10x zvysil, tedy o 1000% a algoritmy na komrpimaci se zlepsili max. o 50%, spise mene.

Uprimne nejlepsi je podle me pouzivat ZIP, protoze je nejvice podporovany a je docela rychly. Uznavam, na Linuxu je tar.gz take dobra volba, ale jit dal mi prijde mirne receno zbytecne, tech par procent navic moc lidi nepotrebuje a proto se od zabehnute praxe tar.gz ci zip moc neustupuje.

RAR ci ACE maji podle me jine vyhody nez nejlepsi kompresi, spise bych rekl, ze jsou hodne promakane. Umoznuji 128bit sifrovani, bezproblemovy spanning apod. Ty algoritmy je podle mych zkusenosti uplne minimum, jde o promakanost jejich nastupu.

Podle me je spise dnes potreba komprimovat multimedia, tam je mezer dost. Treba mam pocit, ze jeste dost lidi neprislo na to, ze format PNG je velmi ucinna beztratova komprese a klidne dal prenaseji nejake 100MB TIFFy.

Pokud ma nastoupit novy kompresni algoritmus, mel by mit takovou podporu jako Ogg Vorbis, tedy velke mnoztsvi nastroju a co nejvetsi podporu vsemi firmami, ne neco osamoceneho.

> Stejne nechapu kam tenhle souboj vede, protoze
> rozdili mezi kompresnimi algoritmy jsou mizive

Tak to bych se docela hadal. Ty rozdily jsou dost zasadni a v podstate diktuji pouziti daneho komprimaku. Tak napriklad ten zavrhovany zip (ktery ma, pokud vim, presne stejnou kompresni rutinu jako tolerovany gzip) ma sice pro ucinnost komprese velkou nevyhodu v tom, ze nepouziva solid archivy, ale to je soucasne obrovska vyhoda v okamziku, kdy potrebujete s kazdym souborem v archivu pracovat samostatne.

Jako mizivy rozdil mi taky nepripada, kdyz mi jeden komprimak udela archiv velikosti +- 900 MB a druhy +- 200 MB (coz je, pravda, dost vyjimecny priklad, ale realny).

> tech par procent navic moc lidi nepotrebuje

Videl jsem rozdily v radove desitkach procent (jsou pripady, kdy dava 7-zip treba i polovicni archivy proti RARu s maximalnim nastavenim, ktere jsem dokazal vymyslet), takze zadnych "par procent". A ze to lidi nepotrebuji - mozna nepotrebuji, ale pockejte, az budou chtit ta data prenest pres svou linku, na ktere plati za kazdy MB dat...

Take si myslim, ze je GZIP optimalni volba. Rychly rozsireny, pomerne nenarocny, nema sice nejlepsi kompresi, ale porad srovnatelnou s ostatnimi.

Je oprosten od licencniho balastu.

Oproti vsem puvodne DOS/WIN komprimacnim programum umi pracovat primo s proudem dat a pomoci zlib knihovny jej zle snadno zadratovat do vlasniho programu a komprimovat jakykoliv vystup do souboru.

Mimochodem PDF, PNG, formaty OpenOffice.org vyuzivaji zlib/resp. GZIP kompresi. Proc asi?

To vse co jsem uvedl je take duvod, proc se RAR nehodi na nic jineho nez na distribuci warez.

Jde tady o jednu dulezitou vec. Dnes si zakompresuji dulezita data naprosto fantastickym comprimatorem blabla verze 1.185 beta, treba freeware, ale close source, ktery komprimuje o 2% lepe nez bzip2. Za 20 let budu potrebovat tento archiv rozbalit. 20 let se zda jako nekonecno, ale uz pred 20 lety existovaly diskety (tehdy jsem pouzival 8mi palcove :-).
Kde za 20 let sezenu program blabla verze 1.185 beta? Kde za 20 let sezenu operacni system, pod kterym bezel? (pred 20ti lety jsem pouzival CP/M, kde je mu dnes konec :-). Pokud nebudu mit dokumentaci k formatu komprese nebo mnohem lepe zdrojaky, uz se k tem datum asi nedostanu.
Tohle samozrejme plati i pro ruzne divoke formaty typu *.doc apod.
Takze open-source nebo alespon presna dokumentace pouziteho formatu je podminka velmi dulezita.

Open Source vám ale v žádném případě nezaručuje, že za 20 let program bude fungovat. Takže je to nerelevantní.

Srovnání programů na "large corpusu" od samotného Andrew Tridgella. Přidány sloupečky pro rar (s použitím 4k slovníku (d) resp. ppm řádu 16 (p)). Jde o kompresní poměry.

rzip | gzip | bzip2 | rar(d) | rar(p) | file
6.03 | 3.64 | 4.97 | 6.04 | 7.16* | archive
5.08 | 3.66 | 4.62 | 4.95 | 5.89* | emacs
5.54 | 4.24 | 5.23 | 5.58 | 6.54* | linux
9.55* | 3.50 | 4.78 | 7.52 | 7.36 | samba
30.0* | 8.43 | 14.2 | 25.7 | 27.6 | spamfile

V tomto světle už rzip nevypadá tak revolučně.

zase rar ma proti bzipu vetsi rozptyl, takze je trosku hur predvidatelny - to jak do velikosti vystupu podle vstupnich dat(to protoze komprimuje lip), tak podle potrebneho casu(to proto aby komprimoval lip)