Názory k článku Komprimační program 7-ZIP

Zdravim

Teda ja nevim, ale IMHO by se na DVD vesel i ten 189MB velky soubor databaze :-)

Zdenek

Plati porad, ze 7zip nelze pouzit na big-endian platformach?

Platí a ještě pár měsíců platit bude.
Verze 4.0 se nám trochu opožďuje (původně konec srpna) a big-endian bylo slíbeno až na konec roku.

Navrhoval bych rozsirir uvedenou mikrotabulecku alespon o zakladni data (ktery archiv byl testovan), idealne bych uvital tabulku obsahujici cas dekomprese pro vsechny archivy/metody pouzite vyse.

Takze pod FreeBSD to uz jede nativne?

To, ze nefungoval na linuxu (jinak nez pres wine) mi taky na nem dost vadilo a kdyz jsem si stahnul zdrojaky ze bych si to zkusil preportovat, tak jsem zjistil, ze ty zdrojaky jsou plny COM objektu a podobnych hovadin, kterejm nerozumim a v linuxu nejsou. Takze jsem to nechalo plavat a dale pouzivam tar.(gz|bz2) ...

Akoratze na 7-Zip.org neni o ty unixovy verzi ani zminka, takze nejspis to portoval nekdo jiny nez autor .... nevite nekdo, jestli se nekde nepovaluji zdrojaky kompilovatelne pod linuxem, eventuelne zkousel nekdo ty FreeBSD verzi pod linuxem?

Je to v clanku - viz http://p7zip.sourceforge.net/

Aha, on to byl klikaci link a ja ho prehlid :o(
No ted jsem to stahnul, rozbalil, spustil make ... dlouha kompilace (aspon na moji sunce) ... no a hura, funguje to!

V clanku se pise: "Filesystémové dumpy se obvykle komprimují přes pipe. Pokud program tuto možnost neposkytuje (7z, rzip), stává se pro tento účel nepoužitelným."
A nasleduje tabulka vysledku, kde je uveden i 7z.
Tak umi 7zip komprimovat prej pajpu nebo ne?

imho neumi. vypada to ze je to dalsi z tech multifunkcnich "fotako,zapisniko,nozo panev s telefonem" ktera umivsechno jenom ne usmazit vajicka.

to ze je problematicke provest nezkomprimovanou zalohu disku do souboru a ten nasledne zkomprimovat, neznamena ze to je nemozne.

Napriklad s RARem pouzivam zasadne -m5 -s (7z dela tusim solid archivy defaultne, RAR ne). Navic RAR nekomprimuje svoje metadata (7z ano), takze spravne by se melo zkouset RARovani taru. A kompresni pomer nebo cas taky nejsou vsechno - ja jen tak neutecu k programu co nema recovery info, versioning, ...

Snad vsechny "nove" (1990+) komprimaky krome ZIPu a ARJcka pouzivaji defaultne solid archivy, samozrejme i RAR a 7Z. Ze RAR nekomprimuje svoje metadata, to je jeho vlastni problem a nepripada mi v poradku davat mu kvuli tomu nejake vyhody (TAR).

Co se tyce neexistujicich funkci, to je nepochybne pravda a taky jsem si skoro jisty, ze to je duvod, proc se 7Z nepouziva ve warezu - neumi mimo jine delit archiv do vic souboru.

Za velkou a vyznamnou vyhodu 7Z povazuji, ze nedava uzivateli nesmyslne nizka omezeni co se velikosti kompresniho slovniku tyce. RAR se buhviproc zastavil uz na 4 MB, coz je pro radu pouziti zatracene malo - 7Z umi tusim 256 MB (vic uz mu nezvladnou dnesni 32bitove CPU). Na vhodnych datech to muze mit sakra velky vyznam, napriklad v pripadech, kdy se komprimuji podobne soubory o velikosti vetsi nez ty 4 MB (napr. emulatorove romsety - tam ma 7Z klidne i o 50% lepsi kompresni pomer nez RAR)

RAR nema solid defaultne, alespon v konzolove verzi.
Musi se nastavit v konfiguraku nebo v prostredi.
PredTARovani budto neni vyhoda, nebo se musi zakazat i pro BZ2 a GZIP. Rozdil muze byt docela znat, ale samozrejme neco stoji.
Ze ma RAR tak krute omezeny slovnik me prestalo prekvapovat uz pred lety. Nejak jsem si zvykl, no ...

A v pravidlech nevidim nic o tom, abych si daval pozor a nepouzival 'go back' misto proklikani od zacatku, kdyz se chci podivat na okolni prispevky ;)

Napriklad s RARem pouzivam zasadne -m5 -s (7z dela tusim solid archivy defaultne, RAR ne). Navic RAR nekomprimuje svoje metadata (7z ano), takze spravne by se melo zkouset RARovani taru. A kompresni pomer nebo cas taky nejsou vsechno - ja jen tak neutecu k programu co nema recovery info, versioning, ...

viz www.maximumcompression.com

PAQAR 4.0 = 371737

7-ZIP 3.13 = 442822

To sice jo, ale z tech stranek cituji:

"At the moment PAQAR is the best compressor of the three, but it's also much slower (5 Kb/s on a slightly overclocked AMD Barton 2800+)"

Takze 5Kb/s ... treba ten postgres tarball co 7-zip pakoval pri nastaveni "extreme" neco pres hodinu by PAQAR pakoval pri tehle rychlosti 84 dni (pravda, autor ma mozna jiny procesor nez barton 2800+, ale rozdil tri radu ve vysledcich tim asi nedozene) ... takze ze by to byl prakticky pouzitelny kompresor ... to asi ne ... ale je fakt, ze jsou tam i jiny kompresory lepsi (co se kompresniho pomeru tyce) nez 7-zip, co jsou i celkem pouzitelny (z nich treba jmenuji UHARC - sam jsem ho pouzival, relativne pomaly, ale vcelku srovnatelne se 7-zipem, ty zbyly dva co tam jsou napsany neznam, mozna jsou lepsi ...)

Teda já se nikdy komprimačním metodám nějak do hloubky nevěnoval, ale pokud jsem měl někde na výběr mezi bzip2 a gzip balíkem a byla u toho velikost souboru, vždy jsem stahoval ten menší.
A časem jsem si zapamatoval, že ten menší je obvykle bzip2, takže když narazím na výběr u kterého nejsou uvedeny velikosti, tak už rovnou klikám na bzip2.
Ale je fakt, že pokud sám někde nechám něco k dispozici, tak obvykle v gzipu, ani nevím proč (nikdy jsem nad tím moc nepřemýšlel).

Radsi taham bz2, protoze je mensi - to, ze spousta lidi radeji gzip me docela prekvapilo. Mozna ne nejakych starsich UNIXech bzip2 neni defaultne ...
Na bzip2 a gzipu je hezke, ze k sobe maji bzcat/zcat, bunzip2/gunzip, bzless/zless ...

bzip2 je linuxovina. Kromě něj není standardně skoro nikde.

Já téměř vždy preferuji gzip se kterým se lépe pracuje prakticky ve všech systémech. Má menší kompresní poměr ale je daleko rychlejší. Na jednom serveru provádím křížovou zálohu datového svazku přes NFS - cca 35GB dat. gzip --fast trvá asi 4,5 hodiny, bzip2 kolem 6 hodin. Rozdíl ve velikosti je v řádech desítek MB - na LAN zanedbatelné.

Každý má holt jiné potřeby...

Potvrzuju.

Pro bz2 existuje plugin do Windows/Total Commanderu a zvladne ho myslim i WinRar

Před časem mě docela nadchla možnost jak vypálit databázi o velikosti cca 2 GB na jedno CdD bez nutnosti "komprimace" - tedy tak, aby ji programy viděly nekomprimovanou.
Dělá se to pomocí kombinace "mkzftree .." + "mkisofs .. -z" a pokud mě paměť neklame, používá se přitom algoritmus gzip. Nevite někdo, jestli je možné nasadit i některý z "výkonnějších" algoritmů (bzip2, 7Zip apod.) ?

Malá poznámka k obsahu článku : Pokud nějaký komprimační nástroj nedokáže balit data která dostane z roury, je u něj buď odfláknutý interface a takový nástroj pak nestojí (doufejme "zatím") za nasazení nebo je jeho algoritmus pošahaný, protože ve vstupním souboru seek-uje a pak si nezaslouží přežít. Argument že to "jde obejít" neobstojí - pokud bych si chtěl zazálohovat data ze stroje na kterém nemám k dispozici dost místa nebo na kterém z různých důvodů nemůžu zapisovat, můžu obvykle normálně nabootovat z CD a dump prohnaný rourou přes komprimační nástroj posílat po síti pryč. Pokud mi toto nějaký komprimátor nedovolí, je nanic a pak se jen těžko dá používat univerzálně - tedy se nedá používat vůbec.

Úplný souhlas. Pokud nějaký komprimátor neumožňuje zkomprimovat cokoliv, kamkoliv a jakkoliv, není použitelný vůbec. Moc hezké, že to umí zkomprimovat adresářovou strukturu, ale jak to neumí zkomprimovat a dekomprimovat on-fly obecný proud dat, tak jako by neuměl nic. Protože, vzato do důsledku, neumí vlastně ani tu adresářovou strkturu, protože neumí všechny možné i nemožné fs co můžu používat s různými kombinacemi práv/příznaků/metadat.

rád bych poznamenal, že obdobou gzip/bzip2 je spíš samotné LZMA (stažitelné též z 7-zip.org), který samozřejmě pracovat s stdin/out umí. 7-zip je vlastně už nadstavba, která umí balit a rozbalovat do různých formátů. čili tar.gz a tar.bz2 by bylo asi lepší srovnávat s tar.lzma .