Megjelent a 7-Zip archiváló első hivatalos linuxos kiadása

Szerszám

A 7-Zip széles körben ismert archiváló, de eddig mégsem volt hivatalosa Linux portja (nem keverendő a p7zip-pel). Igor Pavlov, a 7-Zip fejlesztője úgy döntött, hogy kiadja az első linuxos verziót:

It's first version of my port of 7-Zip to Linux.
That port of 7-Zip is similar to p7zip, but it's not identical to p7zip.
Please write here about any bugs and problems with that new Linux version of 7-Zip.

Részletek itt.

( Botond | 2021. 03. 13., szo – 14:58 )

"While Pavlov has not released the source yet, he shared some information on how it has been compiled."

Hajára kenheti a fordítás leírását, A p7zip nyílt forrású: https://github.com/btolab/p7zip

Igen, én ezt használom, mindig a legújabb verzió. A p7zip-nek meg úgy általában a 7-zipnek egy baja volt Linuxon, nem kezelte a linuxos jogosultságokat, symlinkeket, stb.. Nem tudom, hogy ezt Igorovics Szergejev pártfőtitkár elvtárs meg tudta-e oldani. Egyébként egy jó tömörítő, relatíve gyors, jó hatásfokkal tömörít, opensource, ingyenes, Windowsra abszolút best a proprietary WinRAR ellenében. Bár én Linuxon áttértem inkább zstd-re, a sebessége annyira meggyőző, hogy nincs értelme mást használni, csak azért, hogy az ember -1%-ot még nyerjen fájlméretben.

Ha kiadja a forráskódját, rá fogok nézni azért, mert mindig is szimpatikus szoftver volt. Valamiért Szásáéknak ez a tömörítőtéma mindig is feküdt. Commandereket is ők írják a mai napig (pl. Double Commander, régen Volkov, DOS Navigator, FAR Manager).

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

Igen, ezt én is tudom. Linuxon az összes archiváló ilyen, a tar-t használják a unixos filozófia miatt. De sok ember pont azért próbál Linux alatt 7-zip-et használni, mert az windowsos logikával önmaga tud több fájlt tömöríteni, és fájljogosultságokat kezelni (csak Windows alatt). Legalábbis a sikere ez lehetne.

A tar.akármis megoldásoknak egyébként nagy hátránya, hogy solid tömörítés, azaz az egész tömörítvényt ki kell bontani, akkor is, ha csak egy kicsi fájl kell belőle, vagy csak bele szeretnél nézni, hogy mik vannak benne.

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

De, az. Csak egyelőre a linuxos verzió nem az. Van forkja, a p7zip, de a „sima” (nem göcsörtös, vízpapírral lecsiszolt) 7-zip-nek még egyelőre nincs kiadva a linuxos forráskódja.

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

( Vamp | 2021. 03. 13., szo – 15:44 )

amig jol mukodik, addig szamit nagyon h nem nyilt forraskodu?

Szerintem nem. Én a RAR-t használom linuxon saját mentéshez, mert annak kezdettől fogva van linuxos (meg egyéb) kiadása. Ráadásul önmagában kezeli az r+w+x jogosultságokat, míg a többi ezt nem tudja, azoknak a .tar-ra kell támaszkodniuk. Ráadásul a kibontó része (unrar) nyílt forráskódú.

Igen, van a rar-nak linuxos natív kiadása, de 1) zárt forráskódú, 2) nem ingyenes (fizetős, ha nem vetted meg, akkor warezolod), 3) elvből egy zárt formátumot támogatsz. Valamint nem, a unixos jogosultságokat, symlinkeket, egyebeket nem támogatja rendesen, és itt nem csak az rwx-re gondolok, hanem a többi jogosultságbitre, pl. sticky bit, meg ugo jogok mindegyike, meg hard/soft linkek, stb.. Ráadásul ha nem a legújabb verzió, akkor a 4 GB-nál nagyobb fájlok tömörítésével is baja lehet.

Egyszerűen az lenne a Linux egyik legfőbb lényege, hogy nyílt forráskódú megoldásokat, nyílt szabványokat használj rajta, azok egyszerűen időállóbbak. Ennek ellenére magával a Rar-ral nem lenne baj, mint formátummal, ha nem lenne zárt, fizetős. A DOS korszakban nagy kedvencem volt a kora 90-es években a Rar, akkoriban még nem voltunk FOSS/licenc fetisiszták, körbejárt kisfloppy-n, és mindenki használta halál nyugalomban warezben. Akkoriban a rar-nak volt a legerősebb tömörítési foka (gyorsan háttérbe szorította az addigi piacvezető arj-t), az volt a leggyorsabb, ez tudott elsőnek szeletekbe archiválni (ezeket az előnyeit elvesztette, mert már más tömörítők is rég tudják, meg néha verik is ezekben), volt TUI interface-e (később GUI Windows alatt), szóval nagy királyság volt, szépen illett a DOS-os, DOS Navigatoros workflow-ba. Akkoriban a Linux sem számított, mert bár létezett, de még akkor ráfért 1-2 kisfloppyra, meg 1-2 pattanásos egyetemista srác hobbiprojektje volt, és nem láttuk, hogy egyszer valami nagy lesz belőle, csak hobbisták kísérleteztek vele. De ma már felnőttünk, láttuk hová tud vezetni a zárt szoftver (support megvonása, szoftver magára hagyása fejlesztés hiányában), van már egy csomó opensource alternatíva, amik nem egyszer gyorsabbak, jobban tömörítenek, és parancssori kapcsolók szintjén kompatibilisek vele. Nekem ma már a felület is mindegy, úgyis terminálból, CLI-vel használom, javarészt scriptekből, meg Vifm konfigból hívva a tömörítőket, így mindegy a felülete (akár TUI, akár szép, csilivili ikonos GUI), nem használom. Sőt, ma már szeletekbe sem nagyon archivál senki, mióta a floppy-k, CD-k, FTP kihaltak. Így meg csak elfogytak a Rar előnyei, és csak feleslegesen, pótcselekvésből, megszokásból nem veszem meg, meg nem warezolom le, meg nem erőltetem be egy nyílt, linuxos ökoszisztémába, ahová nem való. Sőt, már Windows alatt sem ragaszkodnék hozzá, hiszen ott van a 7-zip.

És itt nem a szarrágásról van szó, hogy Olcsó János valaki, nem akar licencre költeni. A zárt forráskódú szoftvernek nem is az a baja, hogy fizetős általában, hanem ha a szerző megunja, nem támogatja a szoftvert, elhagyja, bugjait nem javítja, egy platformon pár verzió múlva megszünteti a támogatását, ott fog bennehagyni a kaksiban, és ott állsz majd vendor lock-inben egy zárt formátummal, amit a hajadra kenhetsz a továbbiakban, meg konvertálgathatod át az archívumaid, ennek hiányában lehet emulátorokkal, wrapperekkel kínlódni. Ez megtörténhet az opensource-szal is, de mivel ott a kód megvan, ezért a közösség átveszi, támogatja, portolja magának. Ez a veszélye, ez a rugalmatlanság, kiszolgáltatottság, nem az, hogy X dollárt ki kell érte fizetni, ami nem nagy pénz, akár még az 1000×-ét is ki tudnám fizetni, de nem teszem. Csak ha nagyon szükséges, de nem az, mert van egy csomó opensource alternatíva, ami nem csak elviekben, hanem a gyakorlatban is ugyanolyan jól használható. Ugyanezt nem szokták megérteni a Mac-fanok sem, hogy nem azért nem veszek Macet, mert drága, hanem mert elvi bajok vannak vele.

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

Nálam az olyan tömörítő ami csak egyetlen fájlt tud önmaga tömöríteni, az béna. A rar meg a 7zip legalább ezt megugorja. Ráadásul a rar-on érezhető, hogy évtizedek óta fejlesztik és karban tartják, a kibontója nyílt kódú, tehát adatvesztés sem lehet, így ebben tudok legjobban megbízni.

Ez azért erős túlzás. A linuxos tömörítők szándékosan csak azért tudnak egy fájlt tömöríteni, mert tar archívum tömörítésére szánták őket, ez pedig a unixos filozófia miatt van, hogy egy tool csak egy dolgot tudjon, de azt jól. A tömörítő tömöríteni, az archiváló jogosultságokat, fájlrendszerspecifikumokat kezelni. Linuxon ez így lett hagyományos. Egy hátránya van, hogy ha egy fájl kell az archívumból, vagy csak bele akar valaki nézni, ahhoz az egész tar.akármit ki kell bontani. Előnye viszont a unixos filozófia és az erősebb tömörítési fok. Nem mondom, hogy én is szeretem, hogy ezt a logikát mindenáron erőltetik tradicionalitásból, de meg lehet szokni. Elsőre fura, aztán fel sem tűnik.

Egy másik hátránya a tar.akárminek, hogy windowsos felhasználók megszenvedhetnek vele, hogy nem tudják kibontani. De ez megint csak annak a folyománya, hogy más platformokon nem annyira elterjedt. Vannak rá megoldások pl. Windows alatt is, de nem közismertek.

Bár a te felhasználásodra inkább btrfs snapshotok vagy ZFS lenne való, transzparens tömörítéssel. A rar szuboptimális mindenképp erre.

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

Wow, ezt nem is tudtam. Még évekkel ezelőtt próbáltam, akkor nem nyitották, ezek szerint implementálva lett. symlink-kezelést nem is várok tőlük, azt írtam is, hogy nem tudják. Nyilván Windowson nem is lehet mit kezdeni a linuxos symlinkkel.

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

Egy hátránya van, hogy ha egy fájl kell az archívumból, vagy csak bele akar valaki nézni, ahhoz az egész tar.akármit ki kell bontani. Előnye viszont a unixos filozófia

Azért nekem ez a trade-off nem tűnik valami előnyösnek :)

Ahogy már leírták, illeszkedik a szalags médiumhoz.
Ezért is nem értem, mi azoka, hogy a pont ezeknek a gyakran emlegetett ,,hátrányoknak" a megoldására jött létre a dar.
Mégse nagyon tért át rá a világ, mindenki inkább továbbra is tar-ozik, vagy alapvetően más megoldást használ (pl. p7zip).

Amit nagyon hamar megszerettem a 7zip-ben, hogy a kezdetektől unicode-ban tárolta a fájlneveket, így megszűnt vele az inter-system szopás.

Igen, számít. Más platformokra portolhatóságában, megbízhatóságban. Forráskód alapú disztrókon forgatásnál, optimalizációnál, stb.. Persze ezért még nem szedném szét az elvtársakat, világosan írta, hogy "yet" nyet. Magyarán ki fogja adni, lehet a kódot pofásítja, hogy vállalható legyen a publikum előtt, ne maradjanak benne kínos kommentek, meg belegányolások.ú

Ami még jó lenne, bár lehet telhetetlen vagyok, ha a fejlesztő dobná ezt a sourceforgefosforcegoremalwareshitgloryhole.xyz.net.xxx oldalt, és rendesen valami gites oldalra tolná ki a kódot, ahonnan kulturáltan git clone-nal lehetne húzni, és nem 5 mp-ig letöltésre várni, meg reklámokat nézegetni, és közben malwareveszélynek kitenni a gépet. Ha már ópönszórsz, akkor legyen normálisan az.

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

Figyu, olvass tovább a több szálban, meg a hír is felhívja a figyelmet, hogy nem keverendő. Már többet leírtuk, hogy 7-zip != p7zip és hogy mi a különbség. Továbbá, attól, hogy valamiből van .deb csomag, az nem feltétlen jelenti, hogy nyílt forráskódú.

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

"attól, hogy valamiből van .deb csomag, az nem feltétlen jelenti, hogy nyílt forráskódú."

A main-be csak nyilt forráskódú kerülhet.

A többiben igazad van, jó lenne ha kiadná a szerző maga a linuxos 7-Zip kódját.

„Kb. egy hónapja elkezdtem írni egy Coelho-emulátort, ami kattintásra generál random Coelho-kompatibilis tartalmat.”
"Az Antikrisztus ledarálja Mészáros Lőrincet."

Így van, jópár éve megszűnt. Emlékszem a hírre. Sajnáltam.
Amikor linuxozni kezdtem, gyakorlatilag a freshmeat.net volt az a hely, ahová keresni mentél, ha valamire kellett egy program.
Sokmindent még forrásból kellett fordítani, mókolni vele, hogy forduljon.
Mégis mindent megoldottunk valahogy.
Akkoriban amit forgattam kernelt a vasamra, 470 kB körül volt a mérete. Aztán később ez 700 kB-ig hízott. Ma már nem is nagyon van ilyen, hogy forgatott kernelt bootolok.
Volt ennek egy romantikája.

( uid_6201 v | 2021. 03. 13., szo – 17:36 )

A jól bevált tar.xz-hez képest milyen előnye van?

Ha sebesség kell, felejtsd el mindkettőt. A zstd a leggyorsabb most, főleg kitömörítésnél iszonyat durva gyors, nem fogsz hinni a szemednek, ha eddig 7z-hez, meg tar.xz-hez szoktál. Még a Tar Gézikére is köröket ver sebességben.

A másik, hogy ezek a tömörítők sajnos nem nagyon skálázódnak jól 4 szál fölé, nem nagyon tudnak többet használni. Hiába van nálam is 8-12 szálas gép, meg SSD, hogy ne legyen I/O bottleneck, egy szinten túl nem gyorsítható.

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

Köszi a tippet.
Nézem, első tesztek alapján gzip töredéke időben a zstd, miközben tömörítésben kb. gzip-jelleg. És RFC-ben is foglalkoznak vele: https://tools.ietf.org/html/rfc8478
xz tényleg lassú. Brutál erős tömörítése miatt szeretem tar.xz formátumot.

Látom a zstd parancs lesz az általános, mert a többi tömörítést is viszi.

--format=zstd : compress files to the .zst format (default)
--format=gzip : compress files to the .gz format
--format=xz : compress files to the .xz format
--format=lzma : compress files to the .lzma format
--format=lz4 : compress files to the .lz4 format

Látom szépen paraméterezhető:
   zstd -19 xy.dat    # default compression level a -3.

A -19 esetén 358 MB RAM és 1,5-szer lassabb az xz default-jánál. Viszont 15%-kal rosszabbul tömörített az xz-hez képest.
Tehát --format=xz -6 és akkor az xz default-ot eléri minőségben, de időben is.

Lehet vele játszani annak ismeretében, hogy a tempó és tömörítés terén éppen mi a fontos és optimálisnak tűnő.

en a log-okat tomoritem xz-be, hajnal 4-kor raer a szerver tomoritgetni, es text log fileoknal koroket ver tomoritesi aranyban a bz2-re is...  kitomoriteni meg eleg ritkan kell ugyis, es van xzgrep is.

a xstd nem a merete miatt jo hanem a sebessege miatt, ott hasznaljak inkabb ahol 1x kell betomoriteni es nagyon soxor ki (web, csomagkezelok stb)

Szerintem logokat mindegy mivel tömöríted. Azok könnyen tömöríthetők, még egy gzip is alig pár %-ra összetömöríti, mivel sok ismétlődő plain text szövegrész van benne, ami szótáralapon nagyon jól tömöríthető. Binárisoknál meg nagy adattáblázatos dolgoknál már jobban kijönne a különbség. Az is igaz, hogy mivel könnyen tömöríthetők, ezért a betömörítés gyors, így meg az xz sebességbeli hátránya nem annyira jön ki. Attól függ mit honnan nézünk.

Félre ne értsetek, nem rossz az xz (LZMA) sem, nem akarok senkit lebeszélni róla, csak 1) lassú, 2) a logok tömörítése az, aminél én nem ragaszkodnék hozzá. Nekem amúgy mindegy ki mit használ, bármit ki tudok bontani, csak ne zárt, proprietary formátumban gányoljon valaki, az a lényege.

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

Igen, a zstd akkor kell, ha sebességre mész, és nem tömörítési fokra. Ha legerősebb tömörítés kell, akkor xz, nanozip, vagy paq8-klón. De ma már, a szélessáv, meg a terabájtos háttértárak korában szerintem olyan mindegy az a pár % tömörítési különbség, ami a tömörítők között van. Most az, hogy valami pár KB-tal vagy MB-tal kisebb lett, az általában a lőtéri kutyát nem érdekli, de az igen, hogy egy lassabb C2D vagy Rpi gépen a kitömörítés 10-20 mp. vagy csak 1-2 mp., az viszont igenis érdekes, főleg, ha sok apró tömörítvényt kell kibontogatni egymás után, pl. csomagkezelő bont ki sok csomagot.

A zstd-nél a sebesség nagyban függ a géptől, meg attól is, hogy beleütközöl-e I/O bottleneckbe. Pl. egy P3-as vagy P4-es gépen lehet elveszik a tömörítési sebességelőnye egy gzip-hez képest, meg amiatt sem tudja kifutni magát, ha lassú, kávédaráló HDD-ről használod. De ha SSD vagy RAM drive (tmpfs) van alatta, akkor elég durván mérhető, hogy milyen gyors a zstd.

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

Van egy Beaglebone alapú loggerem. Nagyobb sebességgel mintavételezett elektromos paramétereket logol tömörítve sok hónapon keresztül egy nagyméretű SD kártyára bizonyos anomáliák utólagos igazolására.
Egymagos ARM Cortex A8 procit tartalmaz ez a lapka. Megnéztem egy rövidke, 61 MB-os txt alapú időbélyegeket és feszültségeket tartalmazó LOG állományon:

zstd:   6,1s  és 5,7 MB-ra nyomta
gzip: 17,7s  és 8,2 MB-ra nyomta
bzip2: 84s   és 6,0 MB-ra nyomta
bzip2 -1: 39s   és 5,4 MB-ra nyomta
xz -1:  31,7s és 6,2 MB-ra nyomta
xz default: 520s és 3,7 MB-ra nyomta ... jól tömörít, de brutál lassan.

A zstd erre a célra is tetszik. A következő logger zstd alapú tömörítést fog tartalmazni.

Az is kitömöríti, csak a háttérben. A tar-ban, ha jól emlékszem, nincs egy lista tárolva az állományokról. Van egy fejléc, aztán az adat, majd megint fejléc, megint adat és így tovább minden állományra. Ahhoz hogy megnézd hogy xy állomány benne van-e, ahhoz tényleg végig kell olvasnod az egészet. Nem HDD-re/SSD-re találták, hanem szalagra. A neve is innen van, Tape Archiver.

Ettől függetlenül én szeretem, de azért vannak korlátai. Egy 600GiB-os tömörített tar-ból visszaállítani egy állományt az nem két perc. Főleg ha elsőre nem ismered a pontos útvonalat és listáznod kell az összeset.

Hát igen ... tape archive, amire az idők során  .Z   .gz   .bz2  .xz  .zstd  tömörgetés valamelyike rétegződött.
Szeretem, mert a tar integritásának megtartása mellett bármikor áttömöríhető mással. Azaz gunzip xy.tar.gz && xz xy.tar ... eközben a tar-hoz nem nyúltál.

Szelektív visszaállítás: igen, technikailag kétszer kell végigfutni a felettes tömörítővel. Először a tar listája miatt, utána a szelektív kicsomagolás miatt.
Azért szalagról ugyanez még fájdalmasabb lehetett, amikor a mechanikát kellett kétszer végigcsévéltetni a listázás, majd a kívánt fájl szelektív kiemelése okán.

Bocs, elvesztettem a fonalat. Ez hogy kapcsolódik a dar-hoz?
Ami from scratch íródott, as a replacement.

Sok gyakran emlegetett problémára igyekszik megoldást kínálni:
https://en.wikipedia.org/wiki/Dar_(disk_archiver)#Features
mégsem jön szembe az emberrel, ebből arra következtetek, nem igazán váltotta le a tar-t.

Erről a nagy cégeknél dolgozó rendszergazdákat kéne megkérdezni ;-)

Nem lehet triviális egy áttérés olyan helyen, ahol komolyabb archiválási feladatok vannak; ezeknek sok (sokszor őskövület) hardver és szoftver függősége, plusz még az egyes OS-ek közti kompatibilitási problémák.

Maga a tar program is minimum 5-6 féle változatot takar az egyes OS-ek szerint - az más kérdés, hogy mostanában legtöbbször a GNU tar-ra gondolunk, ha emlegetjük.

Egy halvány analógia: minden évben bővül a shell választék valami új, szuper parancsértelmezővel, de azért nem hiszem, hogy az sh, ksh, csh, bash négyesen kívül  elterjedten használnák bármelyiket is (mármint nagyvállalati, szerver környezetben).

Oké, de a shelleknél mások az arányok. Általában rétegproblémákat oldanak meg ezek az ,,új fejlesztések".
Másrészt maga ez a négyes is aktívan fejlődik (magam főleg a bash-t követem figyelemmel).

Míg a tar-t egy csomóan fikázzák a szalagosságból adódó mellékhatások miatt. Húsz éve van már dar, ami full-featured kinyal minden segget, és ennyi idő alatt talán már kiforrott is. Aztán ilyenkor meg úgy tűnik, valahogy mégse kell. Valahogy mégis csak elég jó a tar minden bosszantó nyűgjével együtt.

listázni lehet "tar --list -f valami.tar.gz" ... meg lehet scriptelni is, hogy 1-1 fájlt kibontani, és valamivel megnyitni.

Az mc vfs pl.  jól kezeli a tar.[x|g|b]z cuccokat, de a 7z is kibontódik ilyenkor a /tmp... -be.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

Hidd el ő sem a kommand lájnhoz hülye, nem erről volt szó.
Hanem ahhoz, hogy ez a parancs lefusson, full ki kell tömöríteni a tar-t az armorból. Ami a Te kis homokozódban az 5 MB-os macskafosnál nem számít, de neki a 600 GB-os monstrumoknál igen.
Míg ha volna lista a fejlécben, elég lenne az első bár száz kB-ot kitömöríteni és látná, mi van benne illetve mi hol van.

( sigellef | 2021. 03. 14., v – 20:04 )

Szerkesztve: 2021. 03. 14., v – 20:06

Hát.. nekem valahogy eddig is volt 7z :D

fellegis@DSK01:~$ 7z --help

7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=hu_HU.UTF-8,Utf16=on,HugeFiles=on,64 bits,4 CPUs AMD A10-7800 Radeon R7, 12 Compute Cores 4C+8G  (630F01),ASM,AES-NI)

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

Az igen, Salakban olyan verzió van, ami egy közel 5 éves változaton alapul. Igaz még Archon is csak a 17.03 az utolsó, ami 2017-08-28-as dátumot ír (igaz ez még mindig p7zip, amit rendszeresen frissítettek, csak az alapja a 17.03-as), de még a windowsos stabil verzió is csak 19-es 2019-ből. Valahogy Igor kicsit jegelte a projektet, de most elkezdett rajta dolgozni, most a 21-es ágat adja ki, és ezt teszteli Linuxra is.

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