Vývojáři Arch Linuxu nahradili kompresi balíčků xz kompresí Zstandard

Vývojáři Arch Linuxu nahradili kompresi balíčků xz kompresí Zstandard, tj. názvy balíčků již nekončí xz (pkg.tar.xz) ale zst (pkg.tar.zst). Dekomprese balíčků je tak mnohem rychlejší.

5.1.2020 18:55 | Ladislav Hagara | Komunita

Komentáře

[debian+]

Zaujímavý zápis:

const seqDef* const sstart = seqStorePtr->sequencesStart;

Vo https://github.com/facebook/zstd/blob/dev/lib/compress/zstd_compress_superblock.c

[kralyk z abclinuxu]

To není nic moc divnýho, to je konstantní pointer...

[Petr]

To je prostě divnej archaickej jazyk.

[skunkOS]

Není divnej, je to pěkný jazyk. Na konstantních ukazatelích na konstantní data není nic špatného.

[MadCatX]

Konstantní pointer na konstantní data. Používám to taky a vždycky si u toho říkám, že bych nejradši psal v Rustu.

[Tomášek]

A co ti brání?

[kralyk z abclinuxu]

Rust bohužel nebyl ještě schválen významnými autoritamy jako dostatečně seriózní jazyk, takže bohužel...

[MadCatX]

Zrovna Ponkrácovy plky jsou mi těžce u zádele :)

Mně překáží hlavně spousta existujícího kódu v C++, který by se musel přepsat, nutnost použití některých knihoven, které jsou zvlášť navržené okolo specifických vlastností C++ a nutnost interagovat s Qtčky. Je to škoda, protože mám čím dál častěji dojem, že v C++ dělám přesně to, co by se v Rustu psalo daleko přirozeněji.

[kralyk z abclinuxu]

Jj tomu rozumim. Teď už pracuju v Rustu fulltime, kde není potřeba interfacovat s C++, ale ještě donedávna jsem dělal 60% C++ job a měl jsem podobnej pocit...

[Josef Kufner]

které jsou zvlášť navržené okolo specifických vlastností C++

Které například?

nutnost interagovat s Qtčky.

Qt ještě stále není vyřešené? Už to je docela dlouho, co jsem viděl nějaké projekty, které to řešily. (Ale moc tomu nevěnuju pozornost, tak mi to jen trochu vrtá hlavou.)

[MadCatX]

které jsou zvlášť navržené okolo specifických vlastností C++

Které například?

Třeba Eigen a MPFR C++. Eigen je postavený kompletně okolo expression templates a naroubovat to na cokoliv jiného prostě není možné. Jestli existuje nějaká podobně šikovná obdoba pro Rust, co by zvládala práci s libovolnými datovými typy jsem popravdě nezjišťoval.

I nějaké moje vlastní knihovny mají bohužel C++ové API, které je ale vymyšlené tak, aby poskytovalo něco jako kompilátorově agnostické ABI. Na Windows se to dost hodí. Abych si zachoval podobnou flexibilitu s Rustem, muselo by se celé API "zČckizovat", což by znamenalo rozsekat předchozí 3-4 roky práce.

nutnost interagovat s Qtčky.

Qt ještě stále není vyřešené? Už to je docela dlouho, co jsem viděl nějaké projekty, které to řešily. (Ale moc tomu nevěnuju pozornost, tak mi to jen trochu vrtá hlavou.)

Existuje nějaký prý univerzální wrapovač, který pro C++ový knihovny vygeneruje potřebné bindingy. Syntaxe těch bindingů je ale docela ošklivá a oficiální podporu to samozřejmě žádnou nemá.

Kdybych ten projektík (spíš projektíky) psal dnes, asi bych řešil UI stylem Qt+PySide2 a backedny v Rustu a C++ s čistě Cčkovým API. No jo, příště už budu chytřejší :)

[debian+]

Eust nemá standart. Serioznost tým pádom nie je.

[MadCatX]

Zatím. Až se ten jazyk dostatečně stabilizuje, nějaký standard se snad vytvoří. První skutečný standard pro C++ taky vznikl až v roce 1998 (13 let po uvedení), ANSI C vzniklo až 18 let po zavedení Cčka, K&R C 6 let po poté. Rust má ještě trochu čas.

[debian+]

O Tom som nevedel. Niečo nové.

[Cabrón]

Výborně. XZ je nepřehledná změť.

https://www.nongnu.org/lzip/xz_inadequate.html

[Tomášek]

A to je relevantní jak?
Jakože za sto let někdo bude schopen přehrát médium, najít specifikaci toho kompresního formátu, najít něco v čem otevře soubory v tom zkomprimovaném archivu, ale nebude mít po ruce zdrojáky psané v C99, tak si ho bude muset implementovat sám ručně v C++119?
Já bych jednak řekl, že dlouhodobá archivace je proces, ne že něco co jednou uděláš, zapomeneš na to, a pak zjistíš že ty magnetický pásky vydrží míň než výrobce sliboval.
Druhak bych řekl že jakákoliv komprese je nevhodná pro dlouhodobou archivaci, protože má tendence šířit chyby. ASCII text, kde je procento chyb přečteš v pohodě. Maximálně zjistíš, že ti někde chybí celej odstavec, protože chybu paměťového média odnesl celej blok. I tak si ho dost často dokážeš zhruba domyslet. Zkus ale zrekonstruovat zkomprimovanej text, ve kterém se poškodilo 1% bajtů. To už je práce na disertačku, pokud je to vůbec možný.

[hefo]

Zkus ale zrekonstruovat zkomprimovanej text, ve kterém se poškodilo 1% bajtů.

Áno, ale to je otázkou, aké samoopravné kódy boli použité v príslušnom formáte alebo na použitom médiu. Totiž samotný text v ľudskom jazyku je vysoko redundantný, a obsahuje v sebe pomerne dosť neefektívny, ale veľmi užitočný samoopravný kód - keď sa táto redundancia kompresiou odstráni, tak aj táto samoopravnosť zaniká a pre jej existenciu je nutné dáta prekódovať nanovo (alebo aj nie, záleží od spôsobu použitia).

[Heron]

Druhak bych řekl že jakákoliv komprese je nevhodná pro dlouhodobou archivaci, protože má tendence šířit chyby. ASCII text, kde je procento chyb přečteš v pohodě.

Já bych hlavně řekl, že do této úvahy je potřeba zahrnout i formát v jakém se to ukládá na médium. Protože ten plain ascii text je to možná v ram počítače, ale jakmile se to uloží na jakékoliv dnešní medium, tak je to stejně zakódované pro potřeby toho média a navíc ještě přejeto samoopravnými kódy, protože jinak bychom z toho analogu nevytáhli vůbec nic. Takže hrát si na to, že máme na záloze plain text ... no nemáme, na té pásce jsou nějaké mg domény nějakého vektoru a intenzity a udělat z toho ten plaintext dá ještě hodně práce. To už je lepší vzít do úvahy úplně všechno a poslat to na tu pásku rovnou v takovém formátu, aby bylo vzhledem k jejím obvyklým vlastnostem nejjednodušší to zrekonstruovat. Reed-Solomon na větší vzdálenost nebo rovnou na jiné medium apod. V tomto procesu komprese může hrát dobrou roli v tom, že bude potřeba méně pásek a stejně to bude více rekonstruovatelné, než "plaintex".

[j]

Na tohle ti bude stacit frekvencni analyza. Pokud znas jazyk a ocekavas text, tak nemusis znat exaktni zpusob zapisu na fyzicky vrstve. Staci zkoumat opakujici se vzory.

Jinak archivace je davno vymyslena ... kotouc s postupne se zmensujicim pismem => logika vede k tomu, pouzit lupu ... mikroskop ... a voiala, da se takhle ulozit hromada textu, pricemz dekodovani je samonavodny. Staci to vytesat do dostatecne trvanlivyho materialu.

V realu se uz v 90' resilo, jak se napriklad dostat k archivum Stasi, protoze lidi kteri by vedeli co a jak se ukladalo valem ubyvalo. V tomhle ohledu kdyby Gutenberg misto knihtisku vymyslel CD, tak dnes nemame nic.

A co zustane po nas? Hroby zadny, mrtvoly spalujem. Knihy ani hlineny desticky nevyrabime, takze jediny co budou archeologove za 1000 let zkoumat budou hromady odpadku. Pricemz jediny logicky zaver bude, ze se na prelomu 20/21 stoleti muselo stat neco strasnyho, protoze lidi prestali pouzivat pismo, vyrabet obrazky, ...

[Josef Kufner]

Github teď někdy bude dělat cold storage (doslova) všech svých repozitářů na nějakém ostrově v Arktidě. Ten by chvíli vydržet mohl.

[Heron]

Obecně nemám rád texty od konkurenčních projektů, vždy to zavání trochu uražeností, ale na druhou stranu je to hezké zamyšlení nad tím, jak by vlastně měl komprimovaný formát vypadat a co by ne/měl obsahovat. Někdo obhajuje konkrétní alg a formát nesmí umět nic jiného, a někdo si tam dá rovnou 64b identifikátor komprimačního alg a další 64b hash alg. No a někdo se ohání unixovým přístupem a potom navrhne program kombinující tar a komprimátor, protože "to nejde jinak". Ale čtení pěkné, vůbec se nám tady poslední dobou urodilo celkem zajímavých textů.

[_]

tj. názvy balíčků již nekončí xz (pkg.tar.xz) ale zst (pkg.tar.zst). Dekomprese balíčků je tak mnohem rychlejší

když přejmenuju soubory, tak dekomprese zrychlí

[uzený zelí]

A nehrozí z té rychlejší dekomprese dekompresní nemoc?

[Semo]

Ked budu robit dekompresne prestavky, tak nie.