Óriási munkát végzett, melynek gyümölcse igen jelentős előrelépés; mindenkinek ajánlom. Csomagolva egyelőre Gentoo-ban láttam. A Debian csomag (szponzorált) maintainer-e egyelőre én vagyok, de itt is változások várhatók.
A 0.23 továbbra is letölthető marad az eddigi címekről; hozzányúlni csak kritikus biztonsági hiba esetén fogok.
Enjoy!
- uid_2716 blogja
- A hozzászóláshoz be kell jelentkezni
- 957 megtekintés
Hozzászólások
Jól hangzik. De jó lenne, ha
a) gabor@freebsd betolná a portsba mihamarabb
b) -"- az oprendszerbe mihamarabb (jelenleg bzip2 v1.0.5, 10-Dec-2007. van benne). Mondjuk ahhoz a GPLv3 sajnos nem OK, valami bsd-sek számára elfogadhatóbb (dual-)licenc kellene.
- A hozzászóláshoz be kell jelentkezni
Hm, az (a)-hoz elég volna megpingelni Beanie-t, de ezzel adtál egy jobb ötletet. Inkább a disztrók által automatikusan vizsgált cím alá beraktam egy kamu 2.0-ás csomagot az új elérhetőségekkel.
A (b) nagyon valószínűtlen. A saját kódomat biztosan nem fogom GPLv2-nél engedékenyebb alatt kiadni. Idővel persze az utolsó sorom is "kikophat" a kódból, ugyanakkor Mikołaj szerintem még szigorúbban gondolkozik. Az én GPLv2+ kikötésemet pl. felhúzta GPLv3+-ra.
(Nem vagyunk elvakultak; egyszerűen így gondoljuk és kész.)
A bzip2-1.0.5-öt egyébként sürgősen frissíteni kellene 1.0.6-ra, mert az előbbiben van egy csúnya luk (CVE-2010-0405). Lehet persze, hogy a javítást már backport-olták; nem néztem.
- A hozzászóláshoz be kell jelentkezni
Hát ha nem is frissítettek 1.0.6-ra, de a backport úgy nézem megvolt.
http://security.freebsd.org/advisories/FreeBSD-SA-10:08.bzip2.asc
Ami a licencelést illeti, én Dual-licencre gondoltam, de ha nem, hát nem. Anno Kirk McKusick-nak volt valami trükkös licence a soft-update-re, aminek lényege az volt, hogy *BSD-nek BSD licenc, másnak keményen fizetni kell(ett volna) ha használni akarja. De van pár progi, ami úgy dual-licence, hogy amúgy GPL-valami, de betehették *BSD-sek valami kevésbé BSDL ellenes licence segítségével. Nyilván ha marad GPLv3, akkor - mondjuk - FreeBSD-be az alaprendszerbe nem kerül be az életben sem, hanem marad ports-ban/package-ként elérhető. (GPLv2-s licencű dolog még csak-csak akad az alaprendszerben - bár igyekeznek kigyomlálni hosszú távon azokat is.) Más BSD-k ehhez másként állnak, ugye DragonFlyBSD szó nélkül lépett 4.2.1-es gcc utánra.
Aztán persze lehet, hogy az egész felvetésemnek semmi értelme nem volt, mert rajtam kívül a kutyának eszébe nem jut, hogy ez szempont legyen - végül is ha jól tudom, a bináris csomagoknál használt alapértelmezett tömörítő gzip - bzip2 - xz/lzma váltása miatt lehet annyira nem lényeges, hogy a(z épp leváltott szoftver) többszálúságával foglalkozzanak. Nyilván az lenne a legfontosabb, hogy az épp aktuálisan használt tömörítő teljesítsen legjobban. És mivel gzip-ből se a többszállú pigs (vagy ha van bármi egyéb) került be, lehet itt sem érdekes a dolog másnak. (Ha már, akkor minimalista szinten megnéztem, hogy ennek az xz-nek van-e MT-verziója, azt látom, hogy a p7zip tud ilyet, illetve hogy van egy https://github.com/vasi/pixz eszköz amiről azt írják, hogy többszálú. Tudsz más ilyenekről? Bocs, ha már írtad esetleg.)
- A hozzászóláshoz be kell jelentkezni
Éppen lacos írta meg :)
http://hup.hu/node/96968
http://hup.hu/node/99012
A 7zip szarul skálázódik, ezért nem jó alternatíva szerintem.
- A hozzászóláshoz be kell jelentkezni
Én ezeket ismerem legalább hallomásból:
- tamp, QuickLZ alapokon
- gzip: pigz
- bzip2: pbzip2, bzip2smp, smpbzip2, dbzip2, p7zip, lbzip2
- lzip (LZMA implementáció): plzip
- xz (LZMA implementáció): p7zip, xz (a legújabb xz már tud több szálon futni, azt hiszem), pxz, lxz
A pbzip2-et ma is fejlesztik, ráadásul két ágon (1.x és 2.x), bár azt hiszem, a 2.x-et még egyáltalán nem adták ki. A bzip2smp és smpbzip2 egyikét sem tartják már karban tudtommal. A dbzip2 a Wikimedia alapítvány cluster-es bzip2 implementációja, amellyel pl. a Wikipedia dump-ot tömörítik. A p7zip-nek van egy független, task parallel (asszem max. 4 szálig gyorsuló) bzip2 modulja.
A pixz-ről eddig nem hallottam, de most megnéztem a linket. Annyit tanácsolnék a szerzőnek, hogy a szöveges állományait 80 karakter szélesre tördelje.
Az lxz nem rossz szerintem (én írtam :)), de iszonyatosan sok memóriát zabál. A pxz temp file-okkal dolgozik és OpenMP-s. Leveleztem egy ideig a szerzőjével, és végső soron meggyőzött, hogy teljesen jogos, amit csinál; a buffer cache meglepően sokat segít a programnak, úgyhogy jó a teljesítménye, nem kell végig a diszkre várni. Arra meg, hogy sok diszket eszik, azt lehet mondani, hogy egyébként meg rengeteg virtuális memóriát zabálna (ahogy az lxz is).
Azt hiszem, hogy a "legjobb" (nem (csak) data parallel, hanem task parallel) LZMA tömörítő most GNU/Linux-ra a p7zip (7za), ennek viszont katasztrofális a parancssora; valahogy egyáltalán nem illik a UNIX(R) környezetbe. Én egy wrapper shell script-tel használom, ami lényegében így hívja meg tömörítéshez (filterként):
7za a /dev/null -bd -txz -mmt=on -si -so -mx=9 -ms=on -mf=offés így kitömörítéshez:
7za e -bd -txz -mmt=on -si -soWindows-on egyébként van a WinRAR, ami egy iszonyatosan jó program. Rendkívül sokoldalú, 4 szálig minimum tud skálázódni (láttam), és több szálon is nagyon jó tömörítési rátája van. A RAR formátum kifejezetten hajlékony (solid archive, indexed archive, recovery record, titkosítás stb). Látszik, hogy orosz családi vállalkozásban készül már cirka 20 éve.
- A hozzászóláshoz be kell jelentkezni
Azt hiszem az elérhető SSD technológia nagy I/O sávszélessége miatt most még inkább kívánatos és hatékonyabb lesz a párhuzamos tömörítés.
Talán nem lenne rossz, ha az felé tendálna néhány fejlesztési törekvés az oprendszerek terén, ha alap komponenseket párhuzamosítanának, vagy lecserélnének párhuzamos verziókra. Habár van olyan vélemény is, hogy kevésbé megbízhatóak a többszálú megoldások, ezt nem tudom, illetve hinném hogy csak implementáció kérdése. Azért sok core komponens használ be és kitömörítést állandóan. Gondolom sokat dobhatna a rendszer sebességén is, nem csak a specifikus task-okon.
- A hozzászóláshoz be kell jelentkezni
Talán nem lenne rossz, ha az felé tendálna néhány fejlesztési törekvés az oprendszerek terén, ha alap komponenseket párhuzamosítanának, vagy lecserélnének párhuzamos verziókra.
Ilyen törekvés létezik; valahol mintha csiripelték volna a madarak, hogy a coreutils ebbe az irányba megy. Hm hm...
http://lists.gnu.org/archive/html/bug-coreutils/2009-10/msg00179.html
http://lists.gnu.org/archive/html/bug-coreutils/2010-03/msg00037.html
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518696#74
https://github.com/hpc/Parallel-coreutils
Egyébként az Apple-nek van ugye a Grand Central Dispatch-e; viszonylag egyszerű párhuzamosításra pedig a gcc-ben ott van az OpenMP támogatás.
- A hozzászóláshoz be kell jelentkezni