Bonjour à tous,
Je suis en train de gérer une grande quantité de fichiers sur mon serveur, et je cherche des astuces pour optimiser la compression et la décompression avec la commande gzip sous Linux. J'ai lu quelques articles qui mentionnent l'impact de certaines options de gzip sur la taille des fichiers et la vitesse de traitement, mais je me demande si vous auriez des recommandations pratiques en fonction de vos expériences.
Par exemple, quelles sont les options que vous (…)
Bonjour,
J'ai un dossier avec tellement de fichier que je ne peux plus ecrire sur le FS il me dit "out of inode".
Est-ce que si je fais un tar.gz de ce dossier j'occupe le même nombre d'inode ?
Merci de vos réponses.
Je m'intéressait aux techniques de déduplication quand je suis tombé sur cette petite perle.
http://mattmahoney.net/dc/zpaq.html
Un petit outil en ligne de commande qui n'a l'air de rien, écrit par un expert à la retraite dont c'est le passe temps entre deux courses d'ultrarunning…
La déduplication c'est quand on essaye de retrouver des bouts de fichiers communs pour éviter de les stocker à nouveau. zpaq permet de gérer la déduplication au sein de chaque fichier mais également entre les fichiers. Si (…)
Bonjour,
Aujourd'hui, je viens vous demander votre avis après une recherche infructueuse sur ce sujet.
On sait qu'il vaut mieux, si on peut, ne pas compresser avec perte un flux audio (ou vidéo, d'ailleurs) qui a déjà déjà été compressé avec perte (par exemple PCM original → OGG Vorbis → MP3) : à chaque étape, on altère l'information.
Dans le cas qu'il me questionne, on est en possession d'un flux audio PCM (disons, un CD audio) dont l'origine est une (…)
Pendant que les technologies en termes de compression vidéo continuent d’avancer, on attend toujours la relève en termes de compression d’images. JPEG2000, PNG et GIF sont des formats qui commencent à prendre de l’âge, et chaque format a sa cible d’utilisation. Peut‐être plus pour longtemps, un nouveau format entre dans l’arène, il est libre et répond au doux nom de FLIF.
Salut les moules qui font du graphisme ou qui aiment les Anime.
Je suis tombé sur une info qui je l'espère pourra intéresser certains (d'où ce journal, parce que perso, je m'en bat le coquillart).
Disclaimer: Je ne m'y connais pas du tout dans le domaine. Mon coquillart non plus.
Il s'agit d'un algo pour compresser en JPEG, qui serait apparemment spécifiquement pensé pour mieux gérer les images issues du monde de l'Anime.
La revue de presse de l'April est régulièrement éditée par les membres de l'association. Elle couvre l'actualité de la presse en ligne, liée au logiciel libre. Il s'agit donc d'une sélection d'articles de presse et non de prises de position de l'association de promotion et de défense du logiciel libre.
Les vulnérabilités découvertes pour LZ0 et pour LZ4 viennent d'un code datant de 1999.
En résumé, elles provoquent un dépassement du tas d'entier non-signé, ce qui conduit à une corruption locale de la mémoire.
Ce bogue n'est pas super pratique à utiliser, car il faut lancer la fonction incriminée avec assez de données pour dépasser la limite d'un entier non signé, ce qui dépend donc de l'architecture.
En pratique, cela signifie qu'une architecture 64 bits est plutôt à l'abri.
Le (…)
La vieille blague de linuxfr.org IPOT prédisait que le noyau 3.2.24 ne serait plus publié au format bz2, rendant la décompression de l'archive impossible avec les moyens de 2001. Cela fait un moment que les noyaux sont publiés en tar.gz, tar.bz2 et tar.xz, on apprend maintenant que les prochaines versions du noyau seront publiées uniquement en tar.gz et tar.xz. La prochaine révision longterm 3.2.54 sera donc l'une des toutes premières affectées, la différence étant d'un seul caractère avec la prédiction d'IPOT.
Plus sérieusement, je me demande quelles options de compression seront utilisées. En effet dans le cas de la compression .xz, les besoins en mémoire augmentent considérablement pour les niveaux compressions les plus élevés (source man xz) :
(traduction) « L'utilisation de mémoire avec xz varie de quelques kilooctets à plusieurs gigaoctets, en fonction de paramètres de compressions. […] Le décompresseur aura typiquement besoin de 5% à 20% de la mémoire nécessaire au compresseur pour créer le fichier. […] Cependant, il arrive que des fichiers .xz requièrent plusieurs gigaoctets de mémoire pour être décompressés. »
(texte original) « The memory usage of xz varies from a few hundred kilobytes to several gigabytes depending on the compression settings. […] Typically the decompressor needs 5 % to 20 % of the amount of memory that the compressor needed when creating the file. […] Still, it is possible to have .xz files that require several gigabytes of memory to decompress. »
NdM : merci à JGO pour son journal.
LinuxFr.org propose des dépêches et articles, soumis par tout un chacun, puis revus et corrigés par l'équipe de modération avant publication. C'est la partie la plus visible de LinuxFr.org, ce sont les dépêches qui sont le plus lues et suivies, sur le site, via Atom/RSS, ou bien via partage par messagerie instantanée, par courriel, ou encore via médias sociaux.
Ce que l’on sait moins, c’est que LinuxFr.org vous propose également à tous de tenir vos propres articles directement publiables, sans validation a priori des modérateurs. Ceux-ci s'appellent des journaux. Voici un florilège d'une dizaine de ces journaux parmi les mieux notés par les utilisateurs… qui notent. Lumière sur ceux du mois d'août passé.
Hop, voici un journal bookmark dans lequel je présente une méthode de compression de données plutôt simple, mais utilisée par les plus grands.
L'article est ici : http://www.palkeo.com/code/compression.html
C'est le résultat de quelques jours à me poser des questions existentielles sur la compression de données (for fun and profit).
À la fin, vous avez un script de moins de 300 lignes qui arrive à faire de la compression/décompression avec un ratio qui s'approche pas mal des algos classiques, et (…)