Journal Un port de 7-zip sur linux : p7-zip

Posté par  .
Étiquettes : aucune
0
16
août
2004
Si comme moi vous êtes trop impatient pour attendre le port officiel de 7-zip (http://www.7-zip.org(...)) sous linux prévu pour la fin de l'année. Vous pouvez déjà essayer le port de la version en ligne de commande : p7-zip (http://p7zip.sourceforge.net(...)).
Il y a aussi des rpms (http://www.geocities.com/mestiada/(...)) (pas testés.)

Pour ceux qui ne connaissent pas, 7-zip est un logiciel libre sous windows qui reconnaît une grande quantité de formats ( 7z, ZIP, CAB, RAR, ARJ, GZIP, BZIP2, TAR, CPIO, RPM et DEB) et qui en plus de faire des .zip beaucoup plus petit que winzip (et même gzip -9) introduit un nouveau format le 7z qui est tout simplement incroyable :
Comparatif tiré du site (mes tests personnels confirment ca aussi et des fois mieux..)

Original : 27,128,826 bytes

Archive Taille Compressée Ratio
7-Zip (7z format) 5445402 100%
WinRAR 3.10 6004155 110%
WinAce 2.3 6242424 115%
CABARC 1.0 6455327 119%
7-Zip (zip format) 9461621 174%
PKZIP 2.50 9842800 181%

PS : si quelqu'un connaissait un comparatif exhaustif je suis preneur
PS2 : N'Hésitez pas à évangéliser cet excellent logiciel libre autour de vous, sous windows il est incontournable. (je dis ca, car je viens de me rendre compte que ma boite payait une licence par poste de winzip depuis des années !)

  • # C'est quand même bugué.

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

    C'est bien joli, mais 7-zip est incapable de se débrouiller avec certaines archives .tar.gz produites par cygwin, alors que winzip s'en sort très bien.

  • # Capucestpaslibremiascesfreewareetcestpasmaldutout

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

    nous on utilise filezip ( http://www.filzip.com/en/index.html(...) ) dont l'integration aux OS de redmond est plutot reussis.

  • # Petit regret sur ton comparatif

    Posté par  . Évalué à 2.

    Ce qui aurait été vraiment intéressant, c'est de constater la différence de taille du fichier 7-Zip compressé avec des archives .tgz et .tbz2, qui sont tout de même les formats compressés les plus utilisés et les mieux connus sous GNU/Linux... J'aurai surtout voulu voir la différence de taille avec une archive tar compressée en Bzip2, à mon avis elle doit etre beaucoup moins "incroyable" que celle avec du Zip conventionnel :-)

    • [^] # Re: Petit regret sur ton comparatif

      Posté par  . Évalué à 2.

      Mon expérience d'il y a fort longtemps montre que bzip2 s'en sort mieux que gnuzip pour les fichiers texte (ou un .tar composé de fichiers textes), alors que gnuzip est meilleur lorsqu'il s'agit de compresser du binaire (j'avais utilisé un exécutable ELF il me semble).

    • [^] # Re: Petit regret sur ton comparatif

      Posté par  . Évalué à 4.

      Ca n'a rien d'officiel mais juste un petit test rapide :

      2984448 Aug 16 19:48 p7zip_0.90.tar
      391532 Aug 16 19:49 p7zip_0.90.tar.7z
      447371 Aug 16 19:24 p7zip_0.90.tar.bz2
      571598 Aug 16 19:24 p7zip_0.90.tar.gz <---gzip -9
      538631 Aug 16 19:51 p7zip_0.90.tar.zip <--- 7zip a -tzip ....

      • [^] # Re: Petit regret sur ton comparatif

        Posté par  . Évalué à 2.

        Vos benchs de comparaison de compression de fichiers ne veulent pas dirent grand chose.

        En effet d'un type de fichiers à l'autre la compression sera plus ou moin efficace.
        Peut-être que 7-zip est efficace pour compresser du fichier texte et complétement nul pour du fichier jpeg etc....
        Tout dépend de la "spécialisation" de l'algo de compression.

        Il faut faire attention avec ce genre de bench, on peut leur faire dire ce que l'on veut .........

        • [^] # Re: Petit regret sur ton comparatif

          Posté par  . Évalué à 2.

          Vos benchs de comparaison de compression de fichiers ne veulent pas dirent grand chose.

          On a pas prétendu le contraire, il me semble... Le but n'est pas de déclarer de manière universelle que tel format est meilleur que tel autre, mais se faire un début d'opinion d'après 2 ou 3 essais, représentatifs ou non, c'est toujours mieux qu'à partir de rien du tout.

          Dans ce cas précis, on constate que l'algorithme de compression 7zip s'en sort significativement mieux que celui de BZip2. On peut en déduire que dans certaines circonstances au moins, utiliser ce format permet un substantiel gain de place (et donc présente un intérêt certain par rapport aux autres). Donc ca vaut le coup d'essayer.

          C'est tout ce que je voulais savoir... Merci ioio85 !

        • [^] # Re: Petit regret sur ton comparatif

          Posté par  . Évalué à 7.

          >et complétement nul pour du fichier jpeg

          ça me fait toujours rigoler quand on parle de compresser (sans perte) des fichiers JPEG, MPEG*. Ce sont des fichiers déjà compressé avec dégradation de l'information pour améliorer le niveau de compression et à la fin du processus on applique un codage RLE et Huffman. Après ça il y a peu d'espoir de gagner en compression avec un autre algorithme ou alors 2% et encore avec les en-têtes/dictionnaire ça pourrait faire grossir le fichier.

          Par contre c'est vrai que certains algorithmes sont mieux adaptés à certains types de données et que par conséquant l'exemple précédent est un cas particulier.

          • [^] # Re: Petit regret sur ton comparatif

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

            Je vais pinailler mais:

            ça me fait toujours rigoler quand on parle de compresser (sans perte) des fichiers JPEG, MPEG*. Ce sont des fichiers déjà compressé avec dégradation de l'information pour améliorer le niveau de compression et à la fin du processus on applique un codage RLE et Huffman.


            Oui *mais*, pour MPEG1/2/4, JPEG, surement mpg2 layerIII et compagnons, brefs tous sauf h264+CABAC, cette etape de codage utilise un ditionnaire de huffman prédéfini, donc non optimal :-)

            Donc il n'est pas rare comme tu le dis de réussir à gratter quelques % de plus avec un *bon*(ou *adapté*) compresseur sans perte. En tout cas ca prouve clairement que ces tables de huffman statiques sont plutot bien définies étant donné le panel possible de data à son entrée :-)

            Fin du pinaillage

            • [^] # Re: Petit regret sur ton comparatif

              Posté par  . Évalué à 1.

              (...) tous sauf h264+CABAC (..) utilisent un ditionnaire de huffman prédéfini, donc non optimal

              Et encore, le Cabac utilise des modeles de probabilites predetermines, meme s'il les affine au fil du codage de chaque trame.

        • [^] # Re: Petit regret sur ton comparatif

          Posté par  . Évalué à 2.

          Un test généralement assez intéressant est de creer une archive d'une partition entiere (c:/, ou bien /usr/doc + /usr/bin + /home + ...)
          Cela a l'avantage:
          - de melanger fichier ASCII et binaires de toutes sortes (et donc de relativiser le taux de compression)
          - qui plus est, on peut voir si l'utilitaire est rapide et/ou stable.

          • [^] # Re: Petit regret sur ton comparatif

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

            J'ai justement une partition FAT de 5Go qui traine. Dessus doit pas y avoir plus de 2Go d'occupé maximum. Ca comprend Windows 2000 Pro SP4, les drivers qui vont bien, DirectX 9c et 7Zip 3.13. J'ai pas mesuré le temps nécessaire à la compression et j'ai pas cherché à optimiser (compression par défaut pour tous les programmes). 
            décompressé:  5000937472 (100%)
zip 2.3:                1286899949 (25.73%)
gzip 1.3.5:          1286899867 (25.73%)
bzip2 1.0.2:        1234621454 (24.69%)
rar 3.40 b4:        1097547096 (21.95%)
p7zip 0.90:          1076262566 (21.52%)
            Même si j'ai pas vraiment mesuré la vitesse, il semblerait que bz2 par le réseau sur un PII 350 soit pratiquement aussi rapide que rar en local sur un Athlon 1600+ et que p7zip soit encore plus lent. Je crois que je vais rester à gzip pour compresser mes backups: il prend beaucoup moins de temps que les autres (sans compter zip) et la perte n'est pas si conséquente.

            pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: Petit regret sur ton comparatif

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

      Voici une comparaison assez exhaustives (au niveau type de compression) des logiciels 7-zip, winace, winrar et winUHA
      http://geeksasylum.free.fr/articles/logiciels/comparatif_7zip_winac(...)

      Pour information, RAR existe sous Linux mais est un logiciel propriétaire. De même pour ACE (unace), mais je ne connais pas la licence de celui-ci... Malheureusement le comparaison ne s'effectue pas avec d'autres logiciels comme bzip2 ou gzip :-( je pense que c'est principalement du fait que l'article s'orientait résolument sur des solutions avec IHM sous windows seulement.
      Je n'ai rien trouvé sous Linux pour le format UHARC...

      Mais cet article peut donner une idée des performances de ces logiciels. On pourrait peut-être en faire un identique mais en y intégrant d'autres outils issu du monde libre! :-)

  • # sweet

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

    Ca faisait un moment que je l'attendais celui là. C'est juste dommage qu'apparement la syntaxe du programme ne suive pas celle de gzip et bzip2 (pareil pour rar d'ailleurs): un maximum d'option commune entre ces programmes serait quand même bien pratique (d'un autre côté suffit d'écrire un petit wrapper).

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # Wishlist pour file-roller

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

    http://bugzilla.gnome.org/show_bug.cgi?id=150268(...)

    Je suis un fervent supporter du 7z depuis un bon bout de temps.

    Toutes les machines Windows qui me passent sous la main reçoivent un 7-zip (avec Firefox et Thunderbird bien sur).

    Mes livres CC By-SA : https://ploum.net/livres.html

  • # Créer une archive SFX

    Posté par  . Évalué à 1.

    Y'aura-t-il possibilité de créer avec 7-Zip une archive auto-extractible sous linux comme sous windows ? Si oui, à nous le mozilla < 6 Mo alors !

    • [^] # Re: Créer une archive SFX

      Posté par  . Évalué à 6.

      C'est pas tres compliqué à faire, un auto-extractible, avec n'importe quel compresseur de fichier

      #!/bin/sh

      tail +6 "$0" > /tmp/mon_archive
      7z e /tmp/mon_archive
      # Début des données compressées à partir de la ligne 6
      ...


      Il suffit de rajouter ces quelques lignes au début de l'archive, et de le renommer en «.sh» ( ou .run), puis de le rendre executable (chmod +x).
      C'est la méthode employé, entre autre, par idsoftware (quake3, wolf, etc..)
      Ils utilisent makeself qui automatise le processus:

      http://packages.debian.org/testing/utils/makeself(...)
      par contre, makeself ne supporte que les archives tar + gzip, bzip2, ou compress
      mais c'est largement faisable « à la main » en ayant quelques connaissances en script shell.

      • [^] # Re: Créer une archive SFX

        Posté par  . Évalué à 1.

        Bof bof bof...

        Quand on fait un auto-extractible, c'est aussi parce qu'on ignore si la personne en face aura le logiciel de décompression adéquat.

        Un .exe généré par WinZip / WinRar ne nécessite pas le logiciel d'origine pour fonctionner.

        Ta solution, elle, nécessite que 7z soit présent sur le poste et dans le path.

        Pas tout à fait la même chose, donc...

        Sinon, il manque pas un exit dans ton shell, juste avant le début des données compressées ?

        • [^] # Re: Créer une archive SFX

          Posté par  . Évalué à 2.

          « Ta solution, elle, nécessite que 7z soit présent sur le poste et dans le path. »

          Aucun probleme ;-)

          $ wc -l 7z
          365 7z



          #!/bin/sh

          tail +9 "$0" > /tmp/archive_et_bin
          head -365 /tmp/archive_et_bin > /tmp/7z
          sed '1,365d' /tmp/archive_et_bin > /tmp/mon_archive
          /tmp/7z e /tmp/mon_archive
          exit 0
          # Début des données compressées
          ...


          Pour bien faire il faudrait rajouter quelques tests, Il y a peut-être des erreurs, mais ça devrait fonctionner. En tout le cas principe est utilisé, comme je l'ai dit plus haut par idsofware, mais aussi par nvidia, et d'autre.

          Je n'echangerai jamais mon shell et mes outils GNU contre les Winzip/Winrar

Suivre le flux des commentaires

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