GNU Gzip est une suite d'utilitaires de (dé)compression de fichiers utilisés par toutes les distributions GNU/Linux et dans divers environnements UNIX. Ce lundi 10 juin est sortie une nouvelle version de Gzip, dénommée gzip-1.6. Cette version apporte les nouvelles fonctionnalités et corrections de bogues suivantes :
- gzip accepte maintenant l'option --keep (-k), par souci de cohérence avec les outils comme xz, lzip et bzip2. Avec cette option, gzip ne supprime plus le fichier source lors d'une compression ou d'une décompression ;
- gzip -d ne dysfonctionne plus avec certaines données invalides au format « pack » (problème introduit dans gzip-0.8]) ;
- lors d'un écrasement, et avec certaines plateformes où il est compilé de façon optimisée, gzip n'agit plus comme si vous aviez tapé « y » lorsque vous tapez « n ». (bogue présent depuis gzip-1.3.6) ;
- zgrep ne dysfonctionne plus avec des options multi-chiffres comme -15 (équivalente à -C15). Maintenant il passe cette option à grep comme il le fait pour les options à un chiffre (problème vu depuis gzip-1.3.12) ;
- dorénavant, zmore se comporte plus comme more et est plus portable pour les hôtes POSIX.
Aller plus loin
- gzip dans gnu.org (54 clics)
- Télécharger gzip (25 clics)
- Projet gzip dans savannah (18 clics)
- Annonce de la sortie (46 clics)
# Merci
Posté par barmic . Évalué à 10.
J'aurais pensé qu'ils allaient ajouter de quoi faire de la (dé ?)compression en parallèle comme le permet pigz.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Merci
Posté par zzmaxfr . Évalué à 8.
pigz permet seulement la compression parallèle, le gain de temps sur de gros fichier est très important… J'ai mesure un x12 sur un fichier d'1To sur un 32 CPUs la saturation venant de l’accès disque.
La décompression prend un temps du même ordre de grandeur que gzip.
Et le format a pour l'instant toujours été compatible.
[^] # Re: Merci
Posté par steph1978 . Évalué à 4.
Il faut comprendre que la décompression ne tire pas de bénéfice du parallélisme, c'est ça ? Cela sature les IO avant le CPU, c'est ça ?
[^] # Re: Merci
Posté par assidu . Évalué à 3.
J'ai lu un article récemment sur pigz où il était écrit que la décompression tire des bénéfices du parallélisme du moment que l'archive ait été préalablement compressé dans les mêmes conditions (cad en multi-coeur) (et c'est vrai que pigz en multi-coeur ça déménage…). Mais bon là on parle de gzip non ?
[^] # Re: Merci
Posté par Joris Dedieu (site web personnel) . Évalué à 6.
Si le sujet intéresse, un fil sur FreeBSD-hackers (SMP version of tar) décrit assez bien la problématique http://lists.freebsd.org/pipermail/freebsd-hackers/2012-October/040632.html
# Déjà un paquet pour FUN PLUG
Posté par Memiks (site web personnel) . Évalué à 2.
Hello,
Pour ceux qui ont un NAS et qui ont installé Fun Plug dessus (voir fun_plug)
J'ai déjà compilé un petit paquet pour slacker (ffp 0.7 EABI) : gzip-1.6-arm-1.txz
Pour ceux qui veulent tester ;)
Fréd.
[^] # Re:Déjàun paquet pour FUN PLUG
Posté par Juke (site web personnel) . Évalué à 3.
Ton lien n'explique pas ce que c'est.
[^] # Re:Déjàun paquet pour FUN PLUG
Posté par Memiks (site web personnel) . Évalué à 4.
Oui effectivement…
Fun_Plug est la possibilité pour la plupart des NAS vendu sur le marché d'exécuter un script au démarrage du serveur avec les droit ROOT.
ce script est généralement appelé fun_plug et placé à la racine du disque dur.
de la a été créé ffp un ensemble de script qui ajoute uclibc ainsi que pas mal de librairies et petit programme, notamment telnet et ssh en premier lieu.
voir ici : ffp
je maintient un dépot avec les logiciels que j'utilise.
http://ffp.memiks.fr/pkg (pour les noyaux récent en EABI)
http://ffp.memiks.fr/pkg/oarm/ (pour les noyaux OABI)
Fred.
# Par rapport à xz ?
Posté par kadalka . Évalué à 3.
Et quel est l'intérêt de Gzip par rapport à XZ ?
La vitesse de compression/décompression ?
Parce qu'il est le plus répandu (enfin, je suppose) ?
Merci d'avance.
[^] # Re: Par rapport à xz ?
Posté par ariasuni . Évalué à 1. Dernière modification le 11 juin 2013 à 22:46.
Gzip compresse et décompresse plus vite et en prenant moins de ressources systèmes que XZ, qui est un monstre niveau utilisation mémoire/CPU et qui est surtout bien plus lent que Gzip.
XZ ne devrait donc être utilisé que lorsque c’est absolument nécessaire (lorsque la taille de l’archive doit vraiment être réduite au minimum). D’ailleurs je me demande si c’était une bonne idée de passer au tar.xz pour les paquets d’Arch Linux (j’ai l’impression que les paquets mettent plus longtemps à s’installer).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Par rapport à xz ?
Posté par claudex . Évalué à 8.
Si pour la mémoire, c'est vrai, le temps de décompression est seulement un facteur 2 par rapport à gzip http://pokecraft.first-world.info/wiki/Quick_Benchmark:_Gzip_vs_Bzip2_vs_LZMA_vs_XZ_vs_LZ4_vs_LZO#Decompression_time
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Par rapport à xz ?
Posté par ariasuni . Évalué à 3.
Ah cool, tu as trouvé le document qui m’a justement appris un peu ce que valais les différents algorithmes de compression/décompression.
En tout cas un rapport 2 c’est énorme. Ce qui compte c’est que ça compresse bien et rapidement. Gzip est un bon compromis entre lenteur et taux de compression. XZ est dans l’extrême du taux de compression.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Par rapport à xz ?
Posté par claudex . Évalué à 10.
Ça dépend beaucoup ce que tu fais.
Non. Ce qui compte, c'est que ça décompresse bien et rapidement. Pour tout ce qui est distribué, comme les paquets Arch, le temps de compression a peu d'importance, c'est le temps de décompression qui l'est (pour la compression à la volée comme en HTTP ou l'hibernation, c'est autre chose évidemment).
Un point que ce benchmark ne montre pas (vu qu'il fait tout en ramdisk), c'est le temps gagné en accès disque avec des fichiers plus petits à décompresser (mais c'est peut-être négligeable, je ne sais pas, et ça dépendra énormément du type de disque).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Par rapport à xz ?
Posté par claudex . Évalué à 10.
Pour compléter, avec une ligne à 2 Mo/s, ce qui fait du 16Mbps, on gagne 17 secondes lors du téléchargement pour en perdre 3,5 lors de la décompression, au final, on est gagnant sur le temps total.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Par rapport à xz ?
Posté par ariasuni . Évalué à 3.
J’ai une connexion de merde ET une machine de merde. Je suis sans doute gagnant mais pas de beaucoup… Parce que le 3,5 sorti de nulle part c’est bien joli mais c’est sur quelle machine?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Par rapport à xz ?
Posté par claudex . Évalué à 4.
C'est précisé dans les conditions de test : Intel Core i5 CPU 750 at 2.67GHz
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Par rapport à xz ?
Posté par ariasuni . Évalué à 2.
Ah tu reprenais le test…
Bon je suis toujours largement gagnant mais c’est bien d’avoir des points de repères.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Par rapport à xz ?
Posté par ariasuni . Évalué à 2.
Ce que je veux dire c’est que lorsque tu en es à pinailler sur l’algorithme de compression c’est que tu dois avoir un/des fichiers d’une taille importante déjà, donc où le temps de compression compte pas mal.
J’avais en tête le partage de fichiers par courriel, mettre les pièces jointes une par une c’est juste l’enfer, les limitations de taille de pièces jointes ridicules, etc.
Ça peut être intéressant sur un disque dur (quoique les disques durs les plus performants…), mais sur un SSD c’est contre-productif (sauf si tu as plus de place dessus! :p).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Par rapport à xz ?
Posté par claudex . Évalué à 4.
Là, l'exemple, ce sont les source du noyau (plus de 400Mo quand même). Qu'elles sorte 5 minutes plus tard n'est pas un drame. De plus, ils doivent avoir des machines qui gèrent la publication un peu plus performante qu'un vieil i5.
Oui, pour ça, xz n'est sans doute pas approprié.
Même sur un SSD, les accès sont quand même bien plus lent que la mémoire vive. C'est pour ça que je pose la question, ce n'est peut-être pas pertinent.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Par rapport à xz ?
Posté par kadalka . Évalué à -1.
De toutes les façons même en mémoire vive la compression/décompression est toujours nettement plus lente pour XZ.
(Je le vois lorsque je démarre volontairement avec tout en mémoire vive…)
Merci pour vos remarques pertinentes dans cette page.
[^] # Re: Par rapport à xz ?
Posté par ckyl . Évalué à 6.
Il existe des dizaines de cas d'utilisation d'un algo de compression, chaque cas à des critères très différents. Forcément tu vas utiliser le plus adapté au cas d'utilisation.
Un fichier qui va rester sur disque des mois, je peux faire un effort et bouffer un peu de CPU pour le stocker. Quand je cherche a saturer un lien 10Gb avec une compression en streaming pour un truc qui ne va passer qu'une fois dans le tuyaux mes critères sont opposés. De même quand je créer une archive qui va être téléchargée 10000 fois, ou si le premier fichier que j'ai stocké pour des mois va devoir être lu 10x par jour pendant toute cette période.
Bref oui, pour un usage personnel tu t'en carre dans 99% des cas. Dès que tu commences à bosser ca vaut le coup de réfléchir un peu tu peux avoir des gains réellement monstrueux.
[^] # Re: Par rapport à xz ?
Posté par Zenitram (site web personnel) . Évalué à 6.
Pour toi, peut-être.
Perso, j'ai du CPU à plus savoir qu'en faire, et des TB de fichiers à stocker qui eux me coûtent. Le CPU coûte "rien", les TB à stocker par contre ça coûte. Passer à une compression forte m'apporte plus que le problème de temps de compression. Sur ZFS, passer de LZJB à gsip-9 pourrit un peu mon CPU (mais il est au chômage 90% du temps, ça va) mais m'évite des disques en plus (il y a une réelle différence de compression avec mes fichiers), j'apprécie.
Tu as un cas, moi j'en ai un autre, merci de ne pas imaginer que ton cas est universel.
[^] # Re: Par rapport à xz ?
Posté par ariasuni . Évalué à 1.
Plusieurs To de données, je compte ça comme «une taille importante».
Zenitram a encore frappé… :p
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Par rapport à xz ?
Posté par Zenitram (site web personnel) . Évalué à 2.
Oui, et justement, tu dis "le temps de compression compte pas mal", je te répond "pas forcément".
Désolé, mais quand on balance une telle affirmation, oui je réagis : non, ton cas que tu veux généraliser (tu n'as mis aucune limitation dans ton affirmation à part la taille importante) ne s'applique pas à tous. Je m'en tamponne du temps de compression (mais LZMA n'est pas dans ZFS, dommage) alors que je suis dans ton critère ("des fichiers d’une taille importante déja").
[^] # Re: Par rapport à xz ?
Posté par ariasuni . Évalué à 1.
Ouais je dis n'importe quoi.
En fait au début je pensais au cas où tu compressais un grand volume de données d'un coup, et pas le cas où le système de fichier compressait tout.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Par rapport à xz ?
Posté par Zenitram (site web personnel) . Évalué à 2.
Mais c'est toujours la même réponse : ça dépend.
Je peux très bien accepter 20 heures de compression (merci les snapshots du FS pour avoir un truc "live") si à la fin mon archive est plus petite et que c'est ça qui est important pour moi.
[^] # Re: Par rapport à xz ?
Posté par ariasuni . Évalué à 1.
Oui après ça dépend forcément du temps pendant lequel on va le stocker… Encore une fois je suis partie du cas particulier de la compression d’un gros truc pour envoyer un courriel sans le préciser, d’où les malentendus etc. Mais évidemment ça dépend de combien de temps tu vas le stoker, combien de place sur a sur tes disques, combien de temps tu es prêt à passer pour compresser et décompresser…
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Par rapport à xz ?
Posté par Anonyme . Évalué à 1.
Ce qui compte, ca depend du cas d'utilisation, et il y en a plein de differents.
Par exemple des gens ont crée zopfli[1], qui permet de créer des fichiers au format gzip, 5% plus petits qu'avec gzip, mais en prenant 100 fois plus de temps à compresser. Et j'espere que ce qui compte pour eux ca n'est pas que ca compresse rapidement.
[1] https://code.google.com/p/zopfli/
[^] # Re: Par rapport à xz ?
Posté par wismerhill . Évalué à 10.
Il y a des choses amusantes dans ce benchmark.
En particulier, on voit qu'un xz -1 compresse mieux qu'un gzip -9 (82Mio contre 96 Mio) en étant légèrement plus rapide (32.2s contre 33s). Il faudrait que je fasse quelques essais avec des types de fichiers différents pour voir si c'est systématique.
[^] # Re: Par rapport à xz ?
Posté par NanoTech . Évalué à 5.
Crois moi, quand on a du 512K (voire du 56K), chaque octet compte. Pour le code source, xz est prèsque deux fois plus petit que gzip.
Avec du 20 Mbits, je veux bien croire qu'on y perde.
[^] # Re: Par rapport à xz ?
Posté par claudex . Évalué à 8.
Les différents miroirs doivent aussi être content de voir leur bande passante total diminuer.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Par rapport à xz ?
Posté par kadalka . Évalué à 3.
1/ XZ consomme beaucoup, je l'ai constaté mais pour chaque octet que l'on doive télécharger, il vaut mieux que le fichier soit le plus petit possible… aussi bien du côté serveur que de notre côté…
(Bande passante, taille à mobiliser pendant souvent des mois dans le serveur, etc.)
2/ Pour Arch Linux, oui, ils ont du faire des choix et je comprends leur raison: un maximum de paquets dans un minimum de place.
Ce qui est cohérent avec la possibilité de rendre la distribution facilement acceptable notamment pour ceux qui ont une petite bande passante.
Moi même qui utilise une bande passante normale, je n'aime pas toujours lorsque le paquet est trop gros.
Le choix d'archlinux est comme celui de la distribution slax: mettre un maximum de choses en un minimum de place… (Slax est un live CD)
Merci pour votre commentaire pertinent.
[^] # Re: Par rapport à xz ?
Posté par Renault (site web personnel) . Évalué à 3.
Est-ce que ArchLinux fait comme pour Fedora à savoir des delta de paquets pour les mises à jours ?
Ce dispositif permet un gain de temps et de bande passante incroyable (encre 50 et 90% de la mise à jour globale d'économisé suivant les logiciels et les changements apportés).
[^] # Re: Par rapport à xz ?
Posté par kadalka . Évalué à 0. Dernière modification le 12 juin 2013 à 00:38.
Si vous parlez de xdelta3 3.0.7-1 je dirais que oui.
[^] # Re: Par rapport à xz ?
Posté par NanoTech . Évalué à 1.
Dommage que les paquets deb ne gèrent pas encore ça. Ils sont par ailleurs aussi bien (voire legèrement meilleurs) que les rpm.
[^] # Re: Par rapport à xz ?
Posté par Anonyme . Évalué à 3.
Ah, ils permettent moins de choses, mais ils sont legèrement meilleurs ?
[^] # Re: Par rapport à xz ?
Posté par ariasuni . Évalué à 1.
On en a un.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Par rapport à xz ?
Posté par xcomcmdr . Évalué à 2.
On dirait que ça fait longtemps que c'est possible :
https://wiki.archlinux.org/index.php/Deltup
Mais ce n'est pas supporté par tous les dépôts Arch :
https://bugs.archlinux.org/task/18590
(au vu du nombre de votes, on dirait que c'est important pour pas mal de gens)
Et ça a récemment été modifié :
http://archlinux.fr/news/pacman-4-1-dans-core
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Par rapport à xz ?
Posté par Symen . Évalué à 2.
Oui, même si j'ai l'impression que le passage au XZ a rendu les mises à jour delta un poil moins intéressantes.
La dernière fois que j'ai testé, pacman semblait reconstruire les archives puis les compresser en XZ avant de les décompresser à nouveau pour l'installation. Ça tombe mal, car le XZ est plutôt rapide à la décompression mais très lent à la compression. D'ailleurs sur mon netbook les mises à jour delta sont devenues lentes à mourir.
Cela reste très intéressant pour ceux qui ont une connexion lentes ou des quotas sur la bande passante.
# Erreur dans les versions optimisées ?
Posté par gasche . Évalué à 5.
Cette erreur a l'air très croustillante. Serait-il possible d'avoir plus d'explications, en particulier un lien vers le commit corrigeant le problème ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.