Mit használsz elsősorban tömörítésre (UNIX környezetben)?

UNIX, UNIX-szerű

compress
1% (6 szavazat)
gzip
50% (359 szavazat)
bzip2
33% (238 szavazat)
pigz
0% (0 szavazat)
pbzip2
1% (4 szavazat)
egyéb programot, megírom hozzászólásban
5% (38 szavazat)
nem tudom/csak az eredmény érdekel
11% (78 szavazat)
Összes szavazat: 723

( traktor | 2009. 05. 07., cs – 18:10 )

Leginkább arra vagyok kíváncsi, hogy a mai multi core-os világban mennyire használunk párhuzamosított tömörítőket, mint amilyen a pigz és a pbzip2. Én pl csak mostanában kezdem őket felfedezni.

( uid_14867 | 2009. 05. 10., v – 13:16 )

Hiányolom a listából az lzma-t. Lehet, hogy nem terjedt még el eléggé a köztudatban, de több szempontból is alázza a bzip2-t (pl. általában a tömörítés mértéke, kitömörítés sebessége). Hátránya viszont, hogy rohadtlassú.

Nálam lzma áll 1. helyen, de használok még bzip2-t is. Log fájlokhoz utóbbi jobban tömörít+gyorsabb.

( Yorirou | 2009. 05. 10., v – 13:20 )

lzma ftw!

"A fejlesztot azert fizetik, hogy oldja meg a problemat. Ez egy kemeny szakma." - Chain-Q

7-Zip is a file archiver with a high compression ratio.

License

7-Zip is open source software. Most of the source code is under the GNU LGPL license. The unRAR code is under a mixed license: GNU LGPL + unRAR restrictions. Check license information here: 7-Zip license.

You can use 7-Zip on any computer, including a computer in a commercial organization. You don't need to register or pay for 7-Zip. But you can make a donation to support further development of 7-Zip.

Én eddig azt hittem, hogy a WinRAR fizetős. Legalábbis ahol eddig láttam, mindenhol dobálta a figyelmeztető ablakokat, és a az EULA-jában ez van:

"A WinRAR shareware. Bárki szabadon kipróbálhatja 40 napig. Ezt követően, vagy előbb, ha folytatni kívánja A WinRAR használatát, akkor regisztrálnia kell."

A magyar átlagfelhasználók többsége nem szokott fizetni ilyesmikért, ráadásul a mai Windows-okban van ZIP-támogatás. Ezért a fentiak alapján szerintem inkább a ZIP formátum elterjedtebb, mint a RAR.

Na igen, de átlagfelhasználó magasan leszarja, hogy a 40 nap lejárta után nem használhatja a programot. Cégeknél meg (szerintem) telepítésre kerül valamilyen tömörítő, úgyhogy ott sem lehet gond.

De természetesen a legjobb a sima zip ilyen esetekben, de legtöbb esetben más formátumok sem okoznak gondot.

( emberk | 2009. 05. 10., v – 13:58 )

+1 lzma, de szerintem lassan jön az összes gentoos, mert ott ez igen gyakori. De kb 50-50% lzma + bzip2.

( Chain-Q v | 2009. 05. 10., v – 13:59 )

En sima unelit regimodi Info-ZIPpel tolom, normal esetben. Tobbnyire azert, mert erosen multiplatform kornyezetben dolgozom, ahol a zip az amit mindenhol ki lehet tomni, es nagyjabol meg a platform-specifikus maszlagokat is tamogatja. Unix specifikus dolgokat meg szinten regimodian gzippel, mivel az is szinte mindenhol kitomheto. (Es a sima gzip is lassu pl. Amigan, hat meg ilyen bzip2 es haverjai, amik meg a Pegasosban levo G4-et is szeretik megfektetni...)

Olyan meg nalam sajna nincs, hogy csak Unix kornyezetben dolgozom. :)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

( szdl | 2009. 05. 10., v – 14:19 )

Ha gyorsan kell tömöríteni GZIP, ha át kell vinni más platformra, akkor sima ZIP, egyébként, ha lehet, mindig bzip2 (vagy új kedvencem a mindent verő 7zip - ebből van amúgy java-s sőt, dos-os parancssoros változat is!)). Minek foglaljanak fölösleges helyet a cuccok?
Amúgy vindózon a 7zip GUI-s archívumkezelő mindent kinyit (tgz, tbz -t is), ha fent van.

De ezek multi-core tömörítők (pigz, pbzip2) felkeltették az érdeklődésem... Hm. Sebesség vs. méret dilemma megoldva?

( antiemes | 2009. 05. 10., v – 14:55 )

Hi!

A gzip-re szavaztam, de amugy az esetek kb. feleben rar.

By(t)e
TBS::Antiemes

( BaT | 2009. 05. 10., v – 14:59 )

Az algoritmus mindig változik, így a program is, amit használok. Gyors tömörítésre általában zip, jobb tömörítésre lzma (7zip)/bzip2. Ha csak unix(like) rendszeren belül kell gyors tömörítés, akkor gzip.

Programból linuxon sima bzip2/gzip van használatban, ráadásul parancssorból kb. szökőévente egyszer kell tömörítenem, úgyhogy ark frontenddel. :)
Windowson meg 7zip van telepítve, nem tudom, hogy mennyire tud párhuzamosítani tömörítés közben.

( hrgy84 | 2009. 05. 10., v – 15:10 )

bzip2, gzip, lzma, zip. A hasznalati gyakorisag sorrendjeben irtam.
Torrenteknel meg elojon a rar.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( uid_2716 | 2009. 05. 10., v – 15:18 )

Ha a sebesség fontos, gzip; a pigz-n még gondolkozom. (Jó) pár hónapja, ha nem tévedek, a comp.compression-ön levelezett a szerző felhasználókkal egy-két csúnya bugról; úgy éreztem, még nem elég érett ahhoz, hogy elkezdjem használni. A debian következő stabil kiadásában benne lesz (legalábbis a testing-ben már benne van), majd akkor.

Ha inkább a tömörítési arány fontos, akkor lbzip2; elvégre nekem muszáj :) Megpróbáltam futólag összehasonlítani azokat az implementációkat, amelyekről hallottam. Szerkesztés: bzip2 kitömörítéshez mindig lbzip2-t használok, elvégre azért írtam. (Ha valakit érdekelne, egy-két disztróban lassan benne lesz.)

lzma (a fent linkelt hup témából ismételve a véleményem): amíg nincs xzutils-ból (volt lzmautils-ból) többszálú változat, addig nem térek át rá, utána viszont a bzip2 variációi helyett azt fogom használni. A p7zip nevű 7-Zip port (7z, 7za) parancssorát ill. a 7z formátumot nem kedvelem. A mostani debian stable-ben található 7za (7-Zip (A) 4.58 beta) például nem is támogatja a teljes filter-ként működést: 


$ 7za a dummy -si -so </dev/zero >/dev/null

System error:
E_NOTIMPL

Így tar és gpg közé nem nagyon lehet betenni.

( vOrOn | 2009. 05. 10., v – 16:34 )

arj vagy rar, a tobbit csak veletlenul es kenyszerbol.

- _anno_, rengeteget találkozok mindegyikkel, ezekkel egyáltalán nem, (nagy ritkán torrentben egy kicsomagolás erejéig rarral:)
- megbízhatóak? ez alatt mit értesz? másik gépen is lesz kicsomagoló hozzá? nem bugos? hibás becsomagolásból is amit lehet kiszed?
- az "es ... meg" részt talán az ékezetek hiánya miatt egyáltalán nem értem

ezt úgy éri el hogy nagyobb lesz (egy opció mint más tömörítésnél is), miért akarnám növelni a méretet amikor csökkentetni akarom ?!!
ne válaszold azt hogy biztonság, meg neked is bejött:
eleve minél több redundanciát veszünk ki, annál sérülékenyebb, ne akarjunk a erre a hibatűrésre számítani, ha biztonság kell: menteni, menteni, menteni , azaz 3x akkora méret :P, nem a tömörítettnek 5-10%-al növeltje :)

Biztos, hogy nem volt bekapcsolva a "put recovery record" opció? Vagy hogy alapból nem tesz hozzá valamennyi redundanciát? Csak kíváncsiságból kérdezem, az a 10% feletti adatvesztés utáni hibajavítás nagyon sok, bár a 98-ból 1 az messze nem 10% (egyforma fájlok esetén).
Extra redundanciát a par2-vel is tudsz csinálni targizik mellé...

+1
Gyors volt, könnyen használható, millió opcióval. Verziók közti kompatibilitás szempontjából is nagy rendben volt. És amíg használtak az emberek floppy disk-et, sokáig az ARJ-nak volt a legjobb több lemezre darabolás-implementációja. (A PKZIP is tudott ilyet, de ott a kicsomagolásnál először mindig be kellett tenni a legutolsó lemezt, és utána vissza sorban a többit)
Persze ma már nem túl aktív az ARJ fejlesztése, és mondjuk hivatalos UNIX verziója nincs is.

akkoriban tomoritesi hatekonysagban es parameterezhetosegben semmi nem verte meg az arj-t. es nem volt masik tomorito, ami tudott darabolni. ( oke, talan az uc2 jobb volt tomoritesben )
ha ugyhozta a sors, mezei usernek is le lehetett diktalni, hogy arj -x akarmi.arj
aztan jott a win a beepitett zip supporttal, es a nepek szepen elfelejtettek.
csodalkozom, hogy ezert meg nem pereltek be az ms-t :D)

akkoriban tomoritesi hatekonysagban es parameterezhetosegben semmi nem verte meg az arj-t. es nem volt masik tomorito, ami tudott darabolni.

ez butaság, abban az időben is létezett a rarnak a DOS-os verziója, ami az arj-vel szemben tudott CLI felületen is nagyon kulturáltan dolgozni, és simán tudott darabolni...

én is arj-t használtam addig, amíg meg nem találtam a rar-t ;-)

--
by Mikul@s

Nem butaság amit mondott, csak mást ért "akkoriban" alatt. :)
A RAR azért később született (hú, talán 1993?), mint az ARJ (évszámot nem tudok, de tudtommal 1991-ben már 2.22-es verziószámnál járt).
Én is ARJ-ról tértem át RAR-ra, főleg a rar által "solid archive"-nak nevezett technológia és a jóval erősebb titkosítási algoritmus miatt.

Darabolni a pkzip is tudott, de az első lemez kicsomálásához be kellett tenni a legutolsót is (gondolom a szótár felépítéséhez). Rar-nál és arj-nál nem kellett ilyennel szórakozni.

Tényleg, a Yoshi mester-féle LHArc-ra emlékszik valaki? :)

( Polesz v | 2009. 05. 10., v – 17:09 )

Magamnak bzip2, ismerősnek küldeni zip, disztróhoz csomag gzip, újabban lzma ;-)

--
Elméletileg nincs különbség elmélet és gyakorlat között. Gyakorlatilag van.

kb. nekem is...
azzal a különbséggel, hogy az utolsó kettőt nem csinálom:)

bzip2 főként azért, mert rendszerint a letöltésnél a bzip archívum kisebb (empririkus benchmark, hehe).
Amúgy meg megszokás, hogy vagy gzip, vagy bzip2, főként a tar-ral való integráció (haha) miatt :) 

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

( turul16 v | 2009. 05. 10., v – 17:38 )

Sok mindentul fugg.

Ha kicsi az adathordozo lzma.
Ha relative gyors a halozat es az egyik allomas gyenge akkor lzop.
tar.gz, ha a cel allomason nincs jobb, vagy az adott helyen ez a szokas.
...
Mikor-hogy.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( log69 | 2009. 05. 10., v – 18:46 )

Csináltam egy gyors tesztet, habár nem mérvadó. Azt hiszem maradok a gzip-nél ;) 


dd if=/dev/urandom of=test.dat bs=1M count=100

time lzma -z test.dat
real    1m0.690s
106280973 bytes

time 7z a test.dat.7z test.dat
real    0m37.684s
106280680 bytes

time bzip2 test.dat
real    0m31.766s
105323242 bytes

time pbzip2 test.dat
real    0m21.278s
105333321 bytes

time gzip test.dat
real    0m6.395s
104874226 bytes

time zip test.dat.zip test.dat
real    0m5.932s
104874347 bytes


algor.     sebesség     méret
---------------------------------------
lzma       1x           100%
7z         1.61x        99%
bzip2      1.91x        99%
pbzip2     2.85x        99%
gzip       9.49x        98%
zip        10.23x       100%

nekem is van egy teszteredményem: 


time cat test.dat > test.compressed.dat
real 0m0.099s
104857600 bytes

algor.     sebesség     méret
--------------------------------------------------
cat        613x         100%

Remélem tudsz olvasni a sorok között és érted, hogy mit akarok mondani ezzel. Bár az alapján kicsit kételkedek benne, hogy képes voltál ennyi mérést végigcsinálni, anélkül, hogy egy pillanatra is elgondolkodtál volna rajta, hogy ezt mennyire értelmetlen
---
Linux is bad juju.

Egy túrót látszik jól! A tömörítési algoritmusok futási sebessége *nagyonis* függ attól, hogy mennyi redundancia van a bemenő adatban. Gondold már végig, hogy szerinted ugyanaz a kódrész fut-e le, ha van illeszkedő minta, mint akkor, amikor nincs. Vonatkoztassunk el attól, hogy mi a konkrét algoritmus, mindegyikben bemenő adattól függ a lefutási út. Arról végképp nem beszélve, hogy pl a 7zip csinál egy előzetes tömörítési próbát minden bemeneti adatblokkon lzo-val (ez kb. a leggyorsabb a Lempel-Ziv családból), és az alapján eldönti, hogy milyen algoritmussal menjen neki vagy esetleg egyáltalán ne is próbálja meg lzma-val tömöríteni, mert úgysem fog sikerülni, így csak simán változatlanul másolja a kimenetre. Emiatt a 7z például random bemenő adatra irreálisan gyors is lehet. És eközben majdnem pontosan az csinálja, mint a cat, na például ezért hasonlítottam össze vele.
---
Linux is bad juju.

Nekem is hasonlo jott ki:

lzma:
106281413 byte
real 1m37.848s

bzip2:
105324730 byte
real 0m27.928s

pbzip2:
105328545 byte
real 0m9.571s

gzip:
104874293 byte
real 0m5.180s

Eloszor azt hittem, hogy a file belefert a memoriaba /8GB/, de nem, mert az lzma-t ujra kiprobaltam, es a fentu az az. Azert 5 sec, es ~100 sec kozott van kulonbseg "felhasznaloi elmenyben" is :P Viszont a bzip2-ben jo nagyot csalodtam :(
Es a kicsomagolas is hasonlo sebesseg aranyokat mutat. 


2 magos gép, linux-2.6.29.3.tar (336199680 bytes)


algoritmus    be                 ki                méret
---------------------------------------------------------------------
lzma          1x     (286.445)   1x      (7.499)   14.2%  (47969536)
7z            1.55x  (184.132)   1.05x   (7.142)   14.4%  (48413496)
bzip2         4.44x   (64.440)   0.44x  (16.800)   16.8%  (56553508)
pbzip2        7.08x   (40.438)   0.68x  (10.982)   16.8%  (56750660)
zip           15.25x  (18.780)   1.28x   (5.843)   21.6%  (72667501)
gzip          15.89x  (18.025)   1.41x   (5.320)   21.6%  (72667370)

igaz, én is úgy néztem csak, hogy becsomagolásnál 3x gyorsabb, míg kicsomagolásnál 2x lassab a bzip mint a 7z, ezért billen nálam a mérleg bzip-hez. de gondolom ez változik az adattal.

amúgy az XP-s beépített zip-hez képest úgy tapasztaltam, hogy ezek mindegyike gyorsabb lehet. esetleg ehhez szívesen néznék egy tesztet ha valaki megcsinálná :D

pl. a 3 zip-et összehasonlítve Xp-n (free zip, Xp-s zip, 7zip)

"véletlen adatot nem nagyon tudják összenyomni"

Ezen informatikus nem csodálkozik... én azért utálom a gzipet és a bzip2-t, mert csak egy fájlt tudnak tömöríteni, a "tape archívum" meg a XXI. században egy hülyeség. A bzip2 azt a kis kompressziós előnyét jelentősen több idő alatt hozza össze, úgyhogy ha választani kell akkor inkább gzip. Vagy inkább valami jobb. :)
---
;-(

esetleg ha elolvasnád mire írtam, kérdeztem rá?
de ha valakinek valami baja van mindegy mit írok mindenhol hibát keres, nem a tömörítési algoritmusról, hanem a több fájl tárolásáról, azaz solid (van ahol tar-nak "nevezik") vagy nem, előbbinél ugye sok esetben lényegesen nagyobb a tömörítés mértéke, utóbbinál egyetlen fájl is gyorsan elérhető, nem kell az egészet kitömöríteni

"csak kíváncsiságból, melyikre gondoltál?"

Nem tudok olyat mondani, amivel teljesen elégedett lennék:
- tar.bz2 tömörítés és egy fájl kitömörítése is lassú
- tar.gz egy fájl kitömörítése lassú
- zip nem őriz meg minden attribútumot
- 7z, rar tudja az ördög, nem próbáltam
---
;-(

7z, rar nem őriz meg minden attribútumot.

Valójában nincs normális archívumkezelő *NIX-re, olyan "komoly" funkciót a tartól ne várj, hogy tömörített archívumot darabol vagy ehhez hozzáfűz, updatel, diffel.
Amire kitalálták, hogy mágnesszalagra rögzítsen tömörítetlenül, tökéletes és minden lehetőséget kihasznál. Ezen a szinten felül már csak gányolást látsz.

Régebben én is csináltam ilyen tesztet (sajnos nincs meg, mert elszállt a hdd, ha van igény, akkor megcsinálom újra). Valami olyasmi jött ki, hogy az lzma tömörít a legjobban, az lzo a leggyorsabban, a sebesség / tömörség arányban pedig az rzip nyert (alig volt nagyobb, mint az lzma, és picit volt lassabb, mint a gzip). Csak egy sima tar-ral archívumba raktam a lefordított kernel forrást (legyen benne bináris is), aztán lemásoltam jónéhány példányba, és tömörítgettem.

"A fejlesztot azert fizetik, hogy oldja meg a problemat. Ez egy kemeny szakma." - Chain-Q

pont most akartam írni az rzip-ről, érdekes-et ír a manual, ezt nem ismertem:

"rzip is a compression program able to take advantage of long distance redundancies in files, allowing greater compression ratios. rzip uses a history buffer of up to 900MB, while gzip uses 32KB and bzip2 uses 900KB."

( sza2king v | 2009. 05. 10., v – 19:08 )

Bocsi, egy kicsit off. Talalkozott mar valaki olyan tomoritvennyel aminek a suffix-e .trf, a signature 0x23 0x64 0x27 0x45 (#d'E)?

/sza2

( ellenlab | 2009. 05. 10., v – 19:15 )

Zip, mert az alap XP install is kezeli.

( Yorirou | 2009. 05. 11., h – 01:23 )

Kis esti benchmark: 

GZIP:
-----
$ dropcaches && time gzip -9 gzip.linux.tar 

real	0m43.504s
user	0m36.718s
sys	0m0.356s

BZIP2:
------
$ dropcaches && time bzip2 -9 bzip2.linux.tar 

real	1m17.613s
user	1m11.604s
sys	0m0.456s

PBZIP2:
-------
$ dropcaches && time pbzip2 -9 pbzip2.linux.tar 

real	0m44.630s
user	1m20.273s
sys	0m2.936s

LZMA:
-----
$ dropcaches && time lzma -9 lzma.linux.tar 

real	7m21.170s
user	7m12.695s
sys	0m1.084s

COMPRESS:
---------
$ dropcaches && time compress compress.linux.tar 

real	0m23.327s
user	0m14.745s
sys	0m0.552s

RZIP:
-----
$ dropcaches && time rzip -9 rzip.linux.tar 

real	1m21.980s
user	1m14.749s
sys	0m1.992s

RAR:
----
$ dropcaches && time rar a -m5 rar.linux.tar.rar rar.linux.tar 

real	1m32.964s
user	1m30.006s
sys	0m0.748s

ARJ:
----
$ dropcaches && time arj a -m4 arj.linux.tar.arj arj.linux.tar

real	0m13.746s
user	0m9.117s
sys	0m0.624s

7ZIP:
-----
$ dropcaches && time 7z a -t7z -m0=lzma -mx=9 -mfb=64 -md=32m -ms=on 7zip.linux.tar.7z 7zip.linux.tar

real	3m58.379s
user	5m54.482s
sys	0m2.144s

SIZES:
------
$ ls -lhaX linux-source-2.6.28.tar *.linux.tar.*
-rw-r--r-- 1 yorirou yorirou  46M 2009-05-11 01:17 7zip.linux.tar.7z
-rw-r--r-- 1 yorirou yorirou  91M 2009-05-11 01:11 arj.linux.tar.arj
-rw-r--r-- 1 yorirou yorirou  55M 2009-05-11 00:32 bzip2.linux.tar.bz2
-rw-r--r-- 1 yorirou yorirou  55M 2009-05-11 00:33 pbzip2.linux.tar.bz2
-rw-r--r-- 1 yorirou yorirou  70M 2009-05-11 00:32 gzip.linux.tar.gz
-rw-r--r-- 1 yorirou yorirou  45M 2009-05-11 00:34 lzma.linux.tar.lzma
-rw-r--r-- 1 yorirou yorirou  47M 2009-05-11 01:02 rar.linux.tar.rar
-rw-r--r-- 1 yorirou yorirou  53M 2009-05-11 00:34 rzip.linux.tar.rz
-rw-r--r-- 1 yorirou yorirou 323M 2009-05-11 00:31 linux-source-2.6.28.tar
-rw-r--r-- 1 yorirou yorirou 128M 2009-05-11 00:35 compress.linux.tar.Z

Legjobban a rar és az rzip áll, mögöttük a 7zip. Legtömörebb a sima lzma lett, viszont nagyon sok ideig elszöszölt. Sereghajtók az arj és a compress.

"A fejlesztot azert fizetik, hogy oldja meg a problemat. Ez egy kemeny szakma." - Chain-Q

( tiger | 2009. 05. 11., h – 10:18 )

Tar Géza
---
/* No comment */
Ketchup elementál megidézése a sajt síkra

( saabi v | 2009. 05. 11., h – 15:21 )

Compress, csak hogy régivágású unixosnak mondhassam magam. :-)
Amúgy gzip.

Ave, Saabi.