ls -1Itt lakik a HUP
Népszerű témákPartnerünkNépszerű fórum témákÚj felhasználók
|
Mit használsz elsősorban tömörítésre (UNIX környezetben)?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
»
|
KeresésNavigációBelépésÁllásajánlatokHWSWFriss blogbejegyzések
HUP napi hírlevélInformációKövess minket! |
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.
Nem mindenkinek telik multicore-os rendszerre. ;)
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "
jah
azert szavazta gzip re -- inkabb nagyobb legyen de hamarabb kilehessen csomizni
lzma?
igen :)
Mégjobbabb: lrzip + lzma :)
Ha pedig windows alatt is ki kell tudni tömöríteni, akkor 7z
---
Linux is bad juju.
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.
lzma ftw!
"A fejlesztot azert fizetik, hogy oldja meg a problemat. Ez egy kemeny szakma." - Chain-Q
LZMA
zip. bármilyen fura :)
Nem olyan fura. Az a jó benne, hogy (szabad/ingyenes) info-zip Windowson is van. Ha egy windowsos embernek tar.gz-t adok, nagy valószínűséggel nem tud vele mit kezdeni.
--
CCC3
Szerencsére a TotalCommander már megbirkózik vele mostanában, de azért még tényleg egy kezdőnek nem küldenék tar.gz2-t.
Az átlagfelhasználók többsége winrart azért szokott telepíteni. Winrarnak pedig van egy olyan jó tulajdonsága, hogy ismeri az összes elterjedt formátumot. Zip, gzip, bzip2, lzma(7zip), egyik sem okoz neki gondot.
Kezdőknek a 7zip-et telepítem / ajánlom mert jóformán ugyanaz mint a Winrar ha az átlag használatot tekintjük (csak egyszerű ki és betömörítés, semmi sfx meg egyebek) csak szabad szoftverben.
Amúgy én is úgy vagyok, tömörítőnek megy fel 7zip, ha nekem kell telepíteni. BTW tud sfx-et is. :)
Lényeges szempont nálam, hogy az info-zip szabad és ingyenes, tehát a windowsokat nem késztetem holmi shareware telepítgetésére. Persze sok hasonló van, bőven lehet közte más szabad szoftver is, amit nem ismerek.
--
CCC3
É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.
No igen.
+1
+1 lzma, de szerintem lassan jön az összes gentoos, mert ott ez igen gyakori. De kb 50-50% lzma + bzip2.
+1 lzma, mert gentoos vagyok
De ha gyorsan kell, akkor lzop.
7zip
+1
------------------------
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?" -=-
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?
tar.gz / 7zip
+1
+1
---
"A megoldásra kell koncentrálni nem a problémára."
Hi!
A gzip-re szavaztam, de amugy az esetek kb. feleben rar.
By(t)e
TBS::Antiemes
A rar-nak milyen előnye van (miközben csak proprietary szoftverrel lehet kezelni)?
Hmm. Van opensource unrar. Hm?
--
()=() Ki oda vagyik, ('Y') hol szall a galamb C . C elszalasztja a ()_() kincset itt alant.az támogatja a több szeletet és az titkosított tömörítést?
(csak kérdezem)
No rainbow, no sugar
Mivel a hivatalos RAR készítője írta, természetesen igen. Egy kivétel van a LGPL licensze mellett, hogy a kódot saját, új tömörítő program készítésére nem használhatod.
Hmm. Itt csak trial-t látok. Hol van open source? (Btw "a kódot saját, új tömörítő program készítésére nem használhatod" sem open source, de az említett oldalon ilyet se látok.)
Extras alatt van, x+1 rendszerre bináris, és source.
A GPL már önmagában elég korlátozó licensz, tehát ha azt opensource-nak tekinthetjük, akkor a GPL+"necsináljkonkurrenciát" licensz is nevezhető nyíltnak.
En az opensource-t ugy ertettem, hogy open source, vagyis nyilt forrasu. A forrasa nyilt, tehat belefer.
--
()=() Ki oda vagyik, ('Y') hol szall a galamb C . C elszalasztja a ()_() kincset itt alant.The Open Source Definition. Az "open source" fogalmat AFAIK a szakmában ők használták először, nincs értelme másra használni.
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.
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.> Torrenteknel meg elojon a rar.
Jajj. Csak erről szoknának le végre :)
hát, József Attila után küldeném, aki ezt a f@szságot kitalálta...
Tömörített adatot megint tömöríteni... hihetetlen.
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
Itt nem is inkább elsősorban a tömörítés, mint inkább a szétvágás dominál.
--
()=() Ki oda vagyik, ('Y') hol szall a galamb C . C elszalasztja a ()_() kincset itt alant.A torrent az eleve szét van vágva, sokkal kisebb darabokra. És ellenőrzőösszeg is van. Szóval _semmi_ értelme.
Kicsit régebbre nyúlik vissza ez a raros meg zipes darabolás, mint a torrent :)
Igaz, ettől függetlenül már nem sok értelmét látom én sem.
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:
Így tar és gpg közé nem nagyon lehet betenni.
arj vagy rar, a tobbit csak veletlenul es kenyszerbol.
?
elég sok említésre került, mindnek van több előnye (szabad, nyílt, gyors, többszálú, elterjedt, tömörített méret, jó gui, ..), ezeknek mik is?
> (szabad, nyílt, gyors, többszálú, elterjedt, tömörített méret, jó gui, ..)
Megbizhatok, es szinte az osszes el-, elonyos fejlesztes eloszor ezekben jelent meg.
ARJ lenyegeben a szegeny ember "bekap szervere" volt anno.
- _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
A RAR hibajavítása nagyon jó. Egy tar.{gz,bz2,lzma}-t a hajadra kenhetsz ha hiányos, RAR akár 10% feletti adatveszteségnél is visszaállít.
(megtörtént: 98 kötetes archívumból 1 nem volt meg, recovery után mégis teljes volt a kicsomagolt adat)
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 :)
Nem, nem opció. A lemezre írt kazetta (tar) különböző "pucér" algoritmusokon átnyomása minden, csak nem normális archívum.
7zip esetén FIXME.
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.
arj? az miért jobb, mint valami más? [kíváncsiságból kérdezem]
"A fejlesztot azert fizetik, hogy oldja meg a problemat. Ez egy kemeny szakma." - Chain-Q
Ideális volt, amikor nagyobbra hízott az archívum, mint 1,2 Mbyte. Ugyanis kérte a következő floppy-t.
Kb. 15 éve az arj volt az ász.
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
Sőt a 2.x-es verzióig a DOS-os RAR-nak még volt NC-t utánzó "GUI"-ja is.
A 3.x már szigorúan CLI, mert akkoriban már inkább a winrar volt a fő vonal.
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? :)
hogyne emlékeznék az LHA-ra, nagyon jó arányban tömörített, főleg az önkcsomagolós témában volt király...
--
by Mikul@s
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ű. xkcdSok 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.
tar.bz2 / 7zip / zip
7zip a favorit, a többi célfüggő.
szürkehrteg
azenoldalamponthu
++
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.
Ha nem is tudja összenyomni az adatot, attól még az algoritmus sebesség jól látszik.
hogy a cat parancsot hogyan tudod egy tömörítési algoritmushoz hasonlítani, az rejtély számomra :)
szal nem tudsz a sorok kozott olvasni :)
ha arra gondolsz hogy mivel nem nagyon tudja tömöríteni, ezért csak egy fájl írás történik gyakorlatilag, akkor nem értek egyet.
ha nem erre gondolsz, akkor tényleg nem tudok olvasni :)
lasd lentebb..
szerintem a letezo adatra gondolt
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.
Izé, ti ezt most tényleg komolyan gondoljátok?
Végülis a tesztfile méretén (1 MB) és a tartalmán (rendezetlen adat) kívül semmi baj nincs a teszttel... rofl
100 MB-ot akartál írni?
Bocs, countot nem néztem.
Amúgy, ha nagyon kísérletező kedved/kedvetek van, nézegesd előtte ezt. Találd ki hány sec alatt gugliztam, amíg te kivastagítottad hogy a gzip jobban tömörít mint minden más (ROTFLOL).
Bocs, de senki nem mondta hogy a gzip jobban tömörít. Sőt a tesztből látszik hogy a véletlen adatot nem nagyon tudják összenyomni.
Annyi látszik mindösszesen, hogy sokkal gyorsabb a gzip. Ennyi, se több, se kevesebb ;)
(gyorsabb zip-et kivéve, de az nálam nem játszik)
Ha újra megcsinálod valami létező, adatot tartalmazó fileformátummal (ld link) akkor még igazad is lehet.
Értelmetlen teszten nem lehet komoly következtetést levonni (nem, a sebességről sem)
kérdés mi számít igazi "létező adat"-nak :)
amúgy egyetértek.
jajj.
1 kernel source
2 kepek
3 mp3
stb..
ezeket kulon kulon es esetleg 1be is
na jó, bevallom, kéjes késztetést éreztem hogy az urandom-on kipróbáljam..
ez alapján talán azt mondanám, hogy gzip ha sebesség kell, és (p)bzip2 ha méret, de az eredmény nem szól a többi alternatíva mellett.
egyébként szép napot ;)
Igen, köszi, ez már tetszik :)
Kicsomagolásnál viszont pont a (p)bzip2 volt a leglassabb, szóval lehet ezt csűrni-csavarni, meg más filetípusokkal nézegetni, érdekes eredmények jönnének ki.
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. :)
---
;-(
a csak egy fájl problémára találták ki:
tar c[jz]vf tomor.tar.[bg]z2? fileok :)
—-—-— int getRandomNumber() { return 4;//szabályos kockadobással választva. } //garantáltan véletlenszerű. xkcdminek jár unix témára aki nem látja annak szépségét? :)
csak kíváncsiságból, melyikre gondoltál?
.zip = .bz2.tar
.7z = .tar.bz2
ha már hülyeséget mondasz, legalább mondj kisebbet: a zip a gz-vel (deflate), a 7z az lzma-val (lzma algoritmus) hozható egyátalán bármiféle kapcsolatba... pont a bzip2 algoritmusa az, aminek semmi köze nincs a többihez.
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.
Egy egysoros "scriptet" hajlando voltam megirni :) A rendezetlen adattal mi a baj? Egy atlag file-ra kiprobalva is hasonloak jonnek ki. Lehet, tul hetvege van nekem, de nem latom at, hol a gond, es az ertelmetlenseg? :)
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."
Bocsi, egy kicsit off. Talalkozott mar valaki olyan tomoritvennyel aminek a suffix-e .trf, a signature 0x23 0x64 0x27 0x45 (#d'E)?
/sza2
Zip, mert az alap XP install is kezeli.
És a jogosultságokkal mit kezdesz? Tudtommal a linuxos zip nem őrzi meg. (Vagy a tulajdonosokat? Valamelyiket, most nem tudom ellenőrizni.)
---
;-(
Kis esti benchmark:
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
Hosszabbacska (bár picit zavaros) teszt
---
;-(
tar + 7z/lzma
tar + gzip.
--
Coding for fun. ;)
Tar Géza
---
/* No comment */
Ketchup elementál megidézése a sajt síkra
Compress, csak hogy régivágású unixosnak mondhassam magam. :-)
Amúgy gzip.
Ave, Saabi.
Régivágású (de minimum hülye) unixos pack-ot használt (pack, unpack, pcat) mert csak az volt. Az viszont nem tudott filterként működni. Ezért jelentek meg az új fiúk (mint pl. a compress, vagy a freeze, és í. t.)
Régivágásút írtam, nem fosszíliát. :-P
Ave, Saabi.
http://hackles.org/cgi-bin/archives.pl?request=310
http://hackles.org/cgi-bin/archives.pl?request=314
Nekem leginkább a 7z tetszett meg, jól tomorit, ki- és becsomagoláshoz peazip-et (is) használok. http://peazip.sourceforge.net/
zip, tar/gzip