Slackware abandonne les tgz

Posté par  (site web personnel) . Modéré par Jaimé Ragnagna.
Étiquettes :
34
10
mai
2009
Slackware
Après 16 ans de bons et loyaux services, Slackware abandonne le format tgz (.tar.gz) au profit d'un nouveau format, le txz (.tar.xz).

Rien de bien fondamental en fait, le principe des paquets reste le même, ce sont des archives tar compressées. Les archives en elles-mêmes ne changent pas du tout, par contre gzip est abandonné au profit de xz.

xz est un nouvel utilitaire de compression, similaire à gzip et bzip2, mais qui emploie l'algorithme LZMA de 7-Zip. Le résultat est sans appel : après conversion, l'arborescence /slackware est passée de 1,9 Go à 1,4 Go, soit une réduction d'environ 25 %.

NdM : OpenSuse utilise déjà LZMA. Fedora commence à fournir un support LZMA. Debian n'a pas encore de paquet xz-utils.

Aller plus loin

  • # Woah, la news fondamentale

    Posté par  . Évalué à -10.

    Et non, ça passe ni au rpm ni au deb, mais seulement, bref, aucun changement, quoi...

    Vraiment ? ... rien à fou*re !

  • # tar

    Posté par  (site web personnel) . Évalué à 8.

    C'est quoi le probleme avec lzma ? l'option J était assignée à --lzma dans tar 1.21 et maintenant elle est assignée à --xz dans tar 1.22

    • [^] # Re: tar

      Posté par  . Évalué à 10.

      En fait, si tu regardes les archives du site XZ, tu verras qu'ils ont juste renommé lzma en xz. Ceci probablement - je suppute, quoi - pour distinguer le format d'archive de l'algorithme de compression.

      Bref, xz = lzma

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

      • [^] # Re: tar

        Posté par  . Évalué à 10.

        Si j'ai bien suivi, il semble que l'auteur de xz a aussi amélioré le format au passage.

        Voila les specs du nouveau format xz : http://tukaani.org/xz/xz-file-format.txt ; elles indiquent noir sur blanc que ce nouveau format diffère de l'ancien LZMA, entre autres ici :
        « This document describes the .xz file format (filename suffix
        .xz, MIME type application/x-xz). It is intended that this
        this format replace the old .lzma format used by LZMA SDK and
        LZMA Utils.
        [...]
        LZMA2 is an extensions on top of the original LZMA. LZMA2 uses
        LZMA internally, but adds support for flushing the encoder,
        uncompressed chunks, eases stateful decoder implementations,
        and improves support for multithreading. Thus, the plain LZMA
        will not be supported in this file format.         ».

        Concernant la justification de ces divergences/améliorations du format, je cite l'auteur ( source : http://sourceforge.net/forum/forum.php?thread_id=2918394&(...) ):

        « The .lzma format is too primitive. It doesn't have an integrity check like CRC32 and it has no magic bytes to make it easy to detect the file type. The .xz format doesn't have these problems. There are some additional features like support for multiple filters (algorithms), filter chaining (like piping on the command line), and limited random-access reading. The .xz format also makes it easier to write multithreaded encoder and decoder. ».

        Est-ce que l'un d'entre vous saurait si la parallélisation (le support du « multithread ») de l'encodeur/décodeur est déjà implémentée ?

        J'imagine que cette fonctionnalité sera de plus en plus pertinente, dès lors que les CPU x86 vendues de nos jours sont pour la plupart multi-cœurs ou multithreads (avec un nombre de cœurs/threads plutôt en augmentation).

        • [^] # Re: tar

          Posté par  . Évalué à 2.

          please, codeur, pas cet horrible encodeur hérité de l'anglais. (codec = codeur/décodeur).

          • [^] # Re: tar

            Posté par  . Évalué à -4.

            si.

          • [^] # Re: tar

            Posté par  . Évalué à 0.

            Arrêtons d'encoder les mouches...

  • # ca a l'air bien, mais on veut des infos sur xz

    Posté par  . Évalué à 10.

    xz est un nouvel utilitaire de compression, similaire à gzip et bzip2, mais qui emploie l'algorithme LZMA de 7-Zip.

    c'est la première fois que j'entends parler de xz et ça a l'air pas mal, mais quelqu'un sait pourquoi il y a 2 formats différents utilisant le même algorithme ?
    si le format 7zip est libre et documenté, je m'interroge sur ce qui a pu motiver à créer un 2e format (ou est il antérieur ?), leur compatibilité, leurs différences, et aussi que je n'ai pas l'air de trouver dans mes dépôts (debian et buntu) contrairement à 7zip. Avoir 2 formats similaires ne peut-il pas devenir gênant ?

    voila qd meme quelques petites infos que j'ai pu trouver sur le site xz
    # Average compression ratio of LZMA is about 30% better than that of gzip, and 15% better than that of bzip2.
    # Decompression speed is only little slower than that of gzip, being two to five times faster than bzip2.
    # In fast mode, compresses faster than bzip2 with a comparable compression ratio.
    # Achieving the best compression ratios takes four to even twelve times longer than with bzip2. However. this doesn't affect decompressing speed.

    petite traduction :
    # Le taux de compression de LZMA est amélioré d'environ 30% par rapport à gzip, et 15% pour bzip2.
    # Vitesse de décompression est juste un petit peu plus lente que celle de gzip, et 2 à 5 fois plus rapide que bzip2.
    # En mode rapide, compresse plus vite, avec un taux similaire à celui de bzip2.
    # Obtenir le meilleur taux de compression prend environ 4 à 11 fois plus de temps qu'avec bzip2, mais sans impact sur la vitesse de décompression.

    un format sympa destiné à succéder aux vénérables gzip et bzip2, avec un mode rapide pour les usages intenses, et un mode compression maximale très lent, qui ne convient donc pas forcement pour tous les usages, mais qui présente par exemple de gros avantages pour tout ce qui est diffusion par le web, ou pour créer des ISO de distributions (ce qui était apparemment leur but).
    Et apparemment au vu des stats annoncées, je pense qu'on devrait voir pas mal de distros suivre le mouvement, pour les dépôts d'archives et les live cd. Les fichiers sont plus petit, donc ca se lit et télécharge plus vite, et ça se décompresse aussi bien plus vite, pour le seul prix d'un temps de compression plus long

    • [^] # Et pourquoi pas 7z ?

      Posté par  . Évalué à 8.

      Ils auraient pu utiliser le .7z car cil utilise aussi l'algorithme lzma, après on revient toujours au même problèmes de la multiplication inutile des formats...

      De plus le .7z est un format ouvert et a une certaine notoriété.

      « En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll

      • [^] # Re: Et pourquoi pas 7z ?

        Posté par  (site web personnel, Mastodon) . Évalué à 10.

        7z est un format de compression + un conteneur de fichiers.
        xz est juste un format de compression. Il est utilisé avec tar pour le contenur de fichiers.

        Pourquoi ? Cela permet une compatibilité bien plus facile de tous les outils utilisant des paquets type slackware. Il "suffit" juste de faire une modification pour supporter xz en plus de gzip, pas besoin de toucher à la partie avec tar.

        Juste pour nuancer la news, le format .tgz n'est pas abandonné. C'est juste que le format .txz est prioritaire. Les outils de base des distributions slackwares restent quand à eux en .tgz pour une meilleure compatibilité (en tout cas pour l'instant).
        À savoir que Slackware a mis à jour la gestion de ses paquets depuis 1 mois et permet de prendre en charge 4 extensions, 3 formats :
        - tgz : tar+gzip
        - tbz : tar+bzip2
        - tlz ou txz : tar+lzma ou tar+xz. Me demandez pas la différence entre les binaires lzma et xz, je sais pas trop (je crois qu'en fait y'en a pas, lzma est l'ancien nom).

        Donc Slackware n'abandonne pas le format d'origine, il en rajoute d'autres et change de format par défaut. À savoir que la possibilité de gérer d'autres formats de compression était une demande forte des utilisateurs de Slackware.

        Sous Zenwalk, système compatible Slackware, avec gestion de dépendances et plus de paquets, pour l'instant deux formats existent :
        - tgz pour la plupart des paquets
        - tlz pour les paquets volumineux
        Ceci est disponible sur "snapshot", c'est à dire la branche de test. On n'est donc pas à l'abri d'un changement vers .txz pour suivre Slackware...

        • [^] # Re: Et pourquoi pas 7z ?

          Posté par  . Évalué à 4.

          Merci, comme ça je sais que les paquets « home-made » déjà faits n'auront pas - forcément - à être reconvertis en txz.

        • [^] # Re: Et pourquoi pas 7z ?

          Posté par  . Évalué à 6.

          merci de cette précision qui fait que cela rend xz/lzma plus intéressant que 7z (que je n'ai jamais utilisé), du fait qu'il n'y a pas besoin de logiciel supplémentaire pour compresser / décompresser. Du coup il suffit de rajouter pour le moment --lzma à la place de z pour compresser avec lzma dans tar.

          Archlinux pourrait envisager de passer également à xz :

          http://bbs.archlinux.org/viewtopic.php?id=71896
          http://nauseamedialis.org/pacman_meets_lzma

          les taux de compressions donnés dans ce lien sont bien supérieurs et donc bien plus intéressants que ceux donnés dans le bench de http://changelog.complete.org/archives/931-how-to-think-abou(...)

          D'ailleurs chez moi un test in situ pour une petite archive de 325 ko avec du texte dedans donne une compression de 111 ko pour tgz et 69,3 ko pour tlz ce qui semble très intéressant. (même si cela à mis 0,05 s d'un côté, et 0,5 s de l'autre)

          En revanche sur une archive plus grosse de 66 Mo, avec quelques vieux et rares binaires (genre fichiers coreldraw) et le reste contenant des svg, lmza est bien resté bloqué dessus assez longtemps

          le résultat est sans appel :

          tgz :
          real 0m6.462s
          user 0m5.760s
          sys 0m0.470s
          taille : 47,7 Mo

          tlz :
          real 1m34.955s
          user 1m34.164s
          sys 0m0.567s
          taille : 40,8 Mo

          le gain de taille même si moins intéressant que plus haut n'est pas négligeable, mais le temps de compression explose. Quand j'archive (souvent se sont des archives temporaires), la taille n'est pas un problème, en revanche je n'ai pas forcément envie de passer du temps dessus (sauf si c'est un processus automatique, tache cron par exemple)
          (bon après il faut voir si ce n'est pas juste les fichiers corel qui ont plombé le petit test)

          Comme j'ai dit ailleurs, pour des archivages chez moi je reste à du gzip, pour de la distribution sur internet lmza est plus intéressant.

          Pour la décompression de l'archive de 66 Mo :

          time tar xf vector.tgz :

          real 0m1.919s
          user 0m1.033s
          sys 0m0.417s

          time tar xf vector.tlz :

          real 0m6.435s
          user 0m5.936s
          sys 0m0.437s

          pas encore vraiment négligeable dans ce cas...

          Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

          • [^] # Re: Et pourquoi pas 7z ?

            Posté par  . Évalué à 4.

            je précise que ces résultats ont été calculés avec du lzma de base, car xz n'est pas encore intégré dans ma distribution (il faudrait recompiler libarchive comme indiqué ici http://nauseamedialis.org/pacman_meets_lzma mais là je n'ai pas le temps de tester)

            Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

          • [^] # Re: Et pourquoi pas 7z ?

            Posté par  . Évalué à 2.

            Des différences 7z / tar+$COMPRESS :
            - Le format 7z ne stocke pas autant de métadonnées (comme le uid du fichier) que tar.
            - Dans .tar.gz ou .tar.*, la compression est une étape après l'archivage des fichiers, trop indépendante, qui crée des "archives solides", ce qui rend les modifications de l'archive impossibles (obligé de décompresser, modifier, puis recompresser).

        • [^] # Re: Et pourquoi pas 7z ?

          Posté par  (site web personnel) . Évalué à 9.

          Même si ça peut sembler grouik, personnellement j'utilise avec bonheur depuis pas mal de temps une combinaison de 7z et de tar avec des commandes du genre :
          tar cvf - des_répertoires_ou_fichiers | 7z a -bd -si mon_archive.tar.7z
          7z x -bd -so mon_archive.tar.7z | tar tvf -
          7z x -bd -so mon_archive.tar.7z | tar xvf -

          enfin, mis dans un script, c'est beaucoup plus simple à utiliser. De même 7z est généralement fourni avec un bout de script shell appelé p7zip qui s'utilise de la même manière que gzip. (ex : mysqldump -h localhost --add-drop-table test | p7zip > test.dmp.7z)

          Alors oui, on perd l'usage à proprement parlé de conteneur de 7z (un seul fichier compressé dans l'archive 7z). En revanche on gagne des fonctionnalités réimplémentées dans xz (présence de crc par exemple) pour un overhead lié au conteneur à mon avis assez faible. De plus, j'avais observé que 7z tirait bien parti du multicpu (du moins de 2 cpus, au delà, c'est moins vrai) alors que lzma ne gagne rien pour l'instant.

          Enfin la commande 7z supporte la plupart des formats (.zip, .gz, .bzip2, .rar ...), ce qui fait un seul outil à connaitre pour tous les formats de compression. (argument faible, mais bon, moi j'aime bien utiliser 7z pour compresser/décompresser des .zip et des .rar)

          Bref, selon moi, 7z, c'est libre, c'est multi-plateforme, c'est bon, mangez-en !

          Nota : mon commentaire n'a pas vocation à critiquer xz/lzma, mais seulement à flatter p7zip...

          • [^] # Re: Et pourquoi pas 7z ?

            Posté par  . Évalué à 8.

            Tu te compliques la vie. L'option --use-compress-program de tar te rendra service.

            • [^] # Re: Et pourquoi pas 7z ?

              Posté par  (site web personnel) . Évalué à 2.

              man tar :
              --use-compress-program PROG
              filter the archive through PROG (which must accept -d)

              Ok, donc à utiliser avec le shell p7zip (qui implémente le -d).
              tar --use-compress p7zip -cvf toto_dir toto.tar.7z
              tar --use-compress p7zip -xvf toto.tar.7z

              Testé, ça marche (tm).

              alias ztar='tar --use-compress-program p7zip'

              Donc encore un argument encore pour 7z ... ;-)

              • [^] # Re: Et pourquoi pas 7z ?

                Posté par  . Évalué à 3.

                encore un argument encore pour 7z
                Ca dépend fortement de ce qu'on a à compresser.

                Mes exports+sauvegardes MySQL par exemple sont mieux compressés avec bzip2 qu'avec 7zip (1,1 Go actuellement). Et c'est également plus rapide avec bzip2, genre moitié moins de temps. J'ai le même résultat avec la sauvegarde de pages web (quelques Mo). Et encore la même chose pour la sauvegarde de disques virtuels Windows (1,5 To chaque nuit).
                note: c'est sous Debian Etch, avec les paquets d'origine. Il y a peut-être des améliorations significatives depuis, bien que l'énorme différence que j'ai trouvé en faveur de bzip2 ne me le laisse pas présager.

                Le top reste LZO qui compresse nos flux VPN. Ca prends presque zéro en processeur, et ça compresse tout de même largement assez bien pour ce qu'on en fait.

                • [^] # Re: Et pourquoi pas 7z ?

                  Posté par  (site web personnel) . Évalué à 3.

                  Pour le temps, je ne vais pas te dire le contraire...
                  bench rapide sur un petit dump mysql :

                  time lzop 20090512-035301.dmp
                  real 0m0.221s
                  user 0m0.176s
                  sys 0m0.040s

                  time gzip 20090512-035301.dmp
                  real 0m1.123s
                  user 0m1.048s
                  sys 0m0.024s

                  time bzip2 20090512-035301.dmp
                  real 0m4.808s
                  user 0m4.784s
                  sys 0m0.024s

                  time p7zip 20090512-035301.dmp
                  real 0m8.066s
                  user 0m8.697s
                  sys 0m0.268s

                  time lzma 20090512-035301.dmp
                  real 0m14.958s
                  user 0m14.429s
                  sys 0m0.144s

                  test sur un bi-pro au repos... p7zip tire bien partie des deux cores.

                  Pour la taille, par contre, je suis surpris que tu aies observés des cas de bzip2 meilleurs que 7z :
                  (note, j'ai vraiment pris le dump au hasard, mais j'ai pas non plus cherché de contre exemple)

                  1406545 20090512-035301.dmp.lzma
                  1559779 20090512-035301.dmp.7z
                  1768026 20090512-035301.dmp.bz2
                  2153230 20090512-035301.dmp.gz
                  3238305 20090512-035301.dmp.lzo
                  13195637 20090512-035301.dmp

                  lzma sans doute significativement plus petit par rapport à 7z pour les motifs évoqués au-dessus : sans doute pas de crc, et pas d'entête non plus gérant l'enveloppe.
                  Désolé, j'ai pas xz pour tester.

    • [^] # Re: ca a l'air bien, mais on veut des infos sur xz

      Posté par  . Évalué à 10.

      quelqu'un sait pourquoi il y a 2 formats différents utilisant le même algorithme ?
      si le format 7zip est libre et documenté, je m'interroge sur ce qui a pu motiver à créer un 2e format (ou est il antérieur ?),

      De memoire la difference entre 7zip et xz est la même qu'entre zip et gzip.
      7zip comme zip ne font pas que de la compression mais aussi de l'archivage (ce que fait tar).

      Je pense que c'est la philosophie UNIX (chaque outil fait un seul truc) qui a amené a la modification du format.

      • [^] # Re: ca a l'air bien, mais on veut des infos sur xz

        Posté par  (site web personnel) . Évalué à 0.

        Je pense que c'est la philosophie UNIX (chaque outil fait un seul truc) qui a amené a la modification du format.

        Ah oui, celle qui fait que que ça prends des siècles pour lister le contenu d'une archive tar compressée parce que justement la partie compression est une surcouche bourrine au-dessus du format d'archive

        • [^] # Re: ca a l'air bien, mais on veut des infos sur xz

          Posté par  . Évalué à -10.

          C'est parce que t'es mauvas c'est tout ...... Cette approche permet une meilleur souplesse de gestion es archives.

          Si ça te plais pas retourne sous winzip ...

        • [^] # Re: ca a l'air bien, mais on veut des infos sur xz

          Posté par  . Évalué à -1.

          Non, celle qui fait que si ce qui t'interesse est la performance du listage du contenu d'une archive, tu disposes d'outils simples pour te faire ton archiveur à toi.

          Maintenant, je ne comprend pas très bien ce que tu viens faire ici si cette philosophie ne te plait pas.

        • [^] # Re: ca a l'air bien, mais on veut des infos sur xz

          Posté par  (site web personnel) . Évalué à 2.

          Je n'ai jamais vraiment cherché à faire des benchs, mais je n'ai jamais vraiment remarqué de lenteur lors du listage.

          Tu fais bien quelque chose du genre
          tar -tzvf monarchive.tar.gz
          pour lister ?

          Faire
          gunzip monarchive.tar.gz | tar -tv
          est certainement très long mais pour la méthode précédente je trouve ça correct.
          (Ceci, je ne l'utilise pas très souvent... du tout. :D)

          • [^] # Re: ca a l'air bien, mais on veut des infos sur xz

            Posté par  . Évalué à 5.

            Sauf que ces deux commandes font à peu près exactement la même chose, de la même manière ...

            • [^] # Re: ca a l'air bien, mais on veut des infos sur xz

              Posté par  . Évalué à 3.

              Elles font à peu près la meme chose, c'est sur, mais si elles le font de la meme manière, comment expliquer la différence de temps ?

              • [^] # Re: ca a l'air bien, mais on veut des infos sur xz

                Posté par  (site web personnel) . Évalué à 4.

                Sans doute que tar n'a pas besoin de decompresser tout le fichier, mais seulement un bloc au début de chaque fichier stocké dans le tar pour voir ses metadata. Bien sûr si il stockait un index au début ou à la fin du tar, tout ceci serait instantané mais là il est obligé de parcourir tout le tar, puisque les metadata sont dispersées dans l'archive. Et je maintiens que sur un tar un peu conséquent (disons 200Mo) de petits fichiers, compressé en bz2, ça prend très longtemps pour lister son contenu (genre plus d'1 minute).

                (Tout ceci est cependant une spéculation, si jamais le club des experts de tar veut me corriger ils sont les bienvenus)

                • [^] # Re: ca a l'air bien, mais on veut des infos sur xz

                  Posté par  . Évalué à 2.

                  Et en « zippant » récursivement tous les fichiers sur place puis en « tarant » seulement après la compression ? Si le besoin est là, quelques scripts pas trop compliqués doivent pouvoir le faire. Solution relativement moche je le reconnais mais n’étant pas plus expert…

                  • [^] # Re: ca a l'air bien, mais on veut des infos sur xz

                    Posté par  . Évalué à 3.

                    L'inconvenient de cette methode est que la compression de plein de petits fichiers est moins efficace que la compression d'un gros fichier les contenant tous.

                    Ma solution serait d'adjoindre à l'archive compressée un index du contenu. Ca se fait en 3 scripts basiques (un pour archiver, un autre pour lister et le troisieme pour extraire) ou bien en un script a peine plus chiadé qui devra gerer les options en ligne de commande et appeler tar.

                    Ceci dit, la lenteur de tar sur le listage d'un gros fichier ne m'a pas souvent géné.

                    • [^] # Re: ca a l'air bien, mais on veut des infos sur xz

                      Posté par  (site web personnel) . Évalué à 8. Dernière modification le 19 octobre 2023 à 17:46.

                      A noter que le fait de compresser individuellement pleins de petits fichiers ou un seul gros fichiers peut changer radicalement les résultats.

                      Cela semble logique car l'algo peut trouver plus de redondances compressables dans le gros fichier.

                      Je m'en suis aperçu quand j'ai voulu proposer une archive des nouvelles de SF sur mon site. Il s'agit de pleins de petits fichiers html (plus de 1300) et ils contiennent donc pas mal de choses communes puisque la mise en page est toujours identique.

                      Tu peux voir les résultat sur https://patrickguignot.fr/sf/introduction_sf.html

                      nouvelles_sf.zip (2,2 Mo)

                      nouvelles_sf.tar.bz2 (274 Ko)

                      L'écart est monstrueux !

  • # lien / comparatif des formats de compression libres

    Posté par  . Évalué à 10.

    Voici un lien intéressant où l'auteur a fait un petit comparatif des différents formats :
    http://changelog.complete.org/archives/931-how-to-think-abou(...)

    Cela me semble complet et la procédure de test pertinente.

    • [^] # Re: lien / comparatif des formats de compression libres

      Posté par  . Évalué à 9.

      J'ai peut-être mal regardé, mais je n'ai rien trouvé sur les besoins en mémoire vive lors de la décompression. Car c'est un élément bloquant sur les systèmes avec des ressources limitées même si les temps de décompression sont faibles.

      Je pense en particulier à des LiveCD de systèmes légers qui peuvent fonctionner avec moins de 64Mo de RAM, mais incapables de se lancer car la décompression des fichiers en lzma nécessite plus de 128Mo de RAM...

      • [^] # Re: lien / comparatif des formats de compression libres

        Posté par  . Évalué à 10.

        Ah trouvé! Il y a quelques infos ici sur les besoins en mémoire, section "Memory requirements":
        http://tukaani.org/lzma/benchmarks

        "The memory usage of lzma stays competitive with bzip2 when files have been compressed with "lzmash -6" or with a smaller option. The files compressed with the default "lzmash -7" can still be decompressed, even on machines with only 16 MB of RAM, but sometimes you don't have even that much memory available. If you compress with "lzmash -8" or "lzmash -9", you should think if the users need to be able to decompress your files also on "ancient" computers."

    • [^] # Re: lien / comparatif des formats de compression libres

      Posté par  . Évalué à -2.

      donc en gros d'après ce document xz cela met près de 2 fois plus de temps à compresser pour un gain finalement pas très important (6-7%)

      Bref, peut-être que c'est bien pour créer les paquets d'une distribution utilisée par des dizaine de millions (rhmmm) d'utilisateurs, mais pour chez moi je garde gunzip.

      De plus je ne vois pas l'intérêt de ce format xz par rapport à 7z

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: lien / comparatif des formats de compression libres

      Posté par  (site web personnel, Mastodon) . Évalué à 10.

      Merci pour le lien.

      George Vlahavas avait fait quelques tests pour Zenwalk lors du support des différents formats de compression par Slackware :


      I did some tests with the slackware package. 1st is compression time, 2nd is decompression time and last is pkg size. All using my Core2Duo 1.6 laptop.

      openoffice:
      tgz: 1m21.774s 0m5.196s 98.2MB
      tbz: 1m54.990s 0m32.059s 92.4MB
      tlz: 5m31.009s 0m15.164s 69.6MB

      iceweasel:
      tgz: 0m9.878s 0m0.733s 10.3MB
      tbz: 0m10.567s 0m3.647s 9.5MB
      tlz: 0m40.500s 0m1.810s 7.9MB

      brasero:
      tgz: 0m2.444s 0m0.307s 2.4MB
      tbz: 0m4.083s 0m1.014s 1.7MB
      tlz: 0m8.992s 0m0.485s 1.3MB


      Donc xz/lzma est bien pour un système de paquets où ce qui importe le plus est la taille et le temps de décompression plus que le temps pour créer le paquet.

  • # Evolution logique

    Posté par  . Évalué à 8.

    Pour information, le format de paquet RPM accepte aussi depuis quelques années la compression lzma, même si je ne connais aucune distribution qui y soit passée.

    Chez Mandriva, je me souviens que la migration, proposée en 2008, ne s'est pas faite car le temps de compression a été jugé trop lourd. Probablement le temps qu'ils aient de nouveaux CPU ;-)

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: Evolution logique

      Posté par  . Évalué à 5.

      openSUSE utilise LZMA depuis la release de juin 08 pour les RPMs et les différentes ISOs DVD/LiveCD.

      http://en.opensuse.org/LZMA

      Outre le fait que les téléchargements sont plus petits et les medias plus fournis grace a la meilleure compression, la décompression de ces derniers est également meilleure, d'ou une installation plus rapide (d'un facteur 2.5 dans certains cas). Le Build Service morfle cependant un peu plus, mais ils ont de la marge.

      Il aussi probable que le format des metadatas utilisé par le gestionnaire ZYpp passe à LZMA dans un futur plus ou moins proche (voir le récent billet http://duncan.mac-vicar.com/blog/archives/537 )

    • [^] # Re: Evolution logique

      Posté par  (site web personnel) . Évalué à 4.

      Mandriva utilise lzma dans la version mandriva-linux-one-2009.1-KDE4-europe1-americas-cdrom-i586 :
      $ ll loopbacks/distrib-lzma.sqfs
      -rwx------ 1 root root 705523712 2009-04-24 17:34 loopbacks/distrib-lzma.sqfs*

      C'est aussi utilisé depuis quelque temps dans les man, par exemple, "man cp" utilise : /usr/share/man/fr/man1/cp.1.lzma

  • # lzma/xz ?

    Posté par  (site web personnel) . Évalué à 4.

    texlive-src 2008 est distribué au format lzma et ça ne pose aucun problème de le décompresser sur une debian. Lzma est utilisable dans debian, xz sans doute pas encore, par contre, il n'est pas utilisé dans ses paquets.

    Parmi les autres gestionnaires de paquets pour linux ou autres, macports supporte lzma (sait utiliser les paquets sources au format lzma) depuis la version 1.7.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.