Arch: .pkg.tar.xz -> .pkg.tar.zst

Linux

Az Arch Linux 2019. december 27-én változtatott a csomagtömörítési sémáján, pontosabban xz-ről (.pkg.tar.xz) zstd-re (.pkg.tar.zst) váltott. A zstd a Zstandard rövidítése. Mit profitálnak belőle? Állításuk szerint, miközben a csomagok helyfoglalása alig kimutathatóan nőtt, a kicsomagolási idő drámaian lecsökkent:

zstd and xz trade blows in their compression ratio. Recompressing all packages to zstd with our options yields a total ~0.8% increase in package size on all of our packages combined, but the decompression time for all packages saw a ~1300% speedup.

Részletek itt.

( arpi_esp v | 2020. 01. 05., v – 10:44 )

"In March 2018, Canonical tested[19] to enabling zstd as a deb package compression method by default for the Ubuntu Linux distribution. Compared with xz compression of deb packages, zstd at level 19 decompresses significantly faster, but at the cost of 6% larger package files."

( the_manni | 2020. 01. 05., v – 11:25 )

Érdekes, h a debianosok level 19 compressionnel teszteltek, és mégis szignifikánsan kisebb gyorsulást mértek, mint az arch level 20-assal. Valamint a fileméret is egy nagyságrenddel többet változik. (Nem is vezették be.)

( arpi_esp v | 2020. 01. 05., v – 13:11 )

csomagtomoritesnel amugy mi ertelme van a gyorsitasnak? nem hiszem, hogy a cpu a szuk keresztmetszet, sokkal inkabb az i/o (olvasni valahonnan (net? cd? usb?) a tomoritett csomagot es kiirni diskre/ssd-re a kitomoritettet (de most is 500mb/s korul van, annal keves ssd ir gyorsabban, de ahol olyan ssd van ott altalaban a cpu is izmosabb).

Így van. Ezt azok látják világosan, akik rollingot használnak, hogy akár naponta lehet egy rakat frissítés. Az is igaz, hogy ha valakinek nagyon tré gépe van, akkor az I/O bottleneck miatt nem lesz gyorsabb a zstd sem, de alapvetően, ha van SSD a gépben, és nem annyira lassú a proci, akkor segíthet.

Nekem sincs jó gépem, a fő masinám egy 8 éves i5-2520M-es nyomi szubnoti. Határozottan gyorsabbnak tűnik Archon a frissítés pár napja. Pedig nem is láttam, hogy már átálltak zstd-re, szóval nem placebóhatás, hanem valóban érezhetően gyorsabb. Egyébként ezt szeretem az Archban, nem a konzervatívok biztonsági játékára gyúrnak, hogy jajj istenem, mi lesz azokkal, akik 486-ost használnak, meg úristen, minden „stabil” 1000 éves LTS verzió legyen, hanem rendesen követik a technológiai fejlődést, ráadásul úgy, hogy a ténylegesen elér stabilitás is nagyon jó marad. Már 3. éve használom, és nem bántam meg. Szerintem évek óta a legjobb disztró a bináris, általános disztrók között. Egy kár, hogy systemd-s disztró, meg hogy nem vezették még be az LTO optimalizálást.

Ráadásul vannak még olyan konzervatív disztrók, akik még mindig Tarr Giziken vannak, nem hogy a zsdt-fázsiba nem jutottak el, de még az xz-sbe sem.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Yay-nál meg makepkg scripteknél be tudod állítani, hogy mivel tömörítse a kész csomagot, akár gz-t is megadhatsz, ami rettenet gyors, az Arch Wiki-ben van erről cikk. De én sose éreztem, hogy a yay sokáig tömörítene, általában a fordítási idő a tétel AUR-os csomagnál, a tömörítés még az én gyenge gépemen is megvan néhány mp. alatt. Sose éreztem, hogy amiatt túl sok időt vesztenék, mert a tömörítés sokáig tartana.

Ez a zst csak a hivatalos tárolókban válik egyeduralkodóvá. Te, a saját tárolódban, meg AUR-os csomag készítésekor azt használsz, amit csak akarsz. A pacman továbbra is tud kezelni tar.gz-t, tar.xz-t, meg amit akarsz.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

( hnsz2002 v | 2020. 01. 06., h – 07:45 )

Remek. Én a drpm-et is kikapcsolom by default, mert semmi értelme, hogy lehúz egy 100KB-os drpm-et, majd újraépít 20 másodperc alatt egy firefoxot, és utána felrakja, amikor 10 másodperc alatt letölti a komplett RPM-et is.

"Sose a gép a hülye."