Full Circle Magazine FR

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
**So I had to export something from MySQL at work and send it to myself so I could email that to one of our developers. While I still retained some of my know-how when it came to MySQL I almost hit a blank when it came to the compression part. How long has it been since I have archived something on the command line? Donkey’s years!! I felt like a total n00b, and here are my thoughts as a ‘n00b’ as I can totally relate. I’m not going to tell you muscle memory kicked in, rather the ugly truth, I went on to duckduckgo.com and looked it up. Most of this stuff I have not done in 10 years plus. I have been so spoiled by the archivers in the GUI, that I never needed to use it really. Un-archiving was not a problem, but zipping something with sane switches? Having been a wizard with ARJ back in the DOS days, I felt it was time to get reacquainted with compression algorithms. I will start you off with the basics, and try to keep switches out of it.

Let’s start with the one everyone knows, zip.
For .zip files it is simple: 

command <destination file> <source file>

Plain ol’ zip does not delete the source file once the destination file is created.

Just for completeness sake, zip’s opposite is: 

unzip <filename.zip>**

Bon, j'ai dû exporter quelque chose de MySQL au travail et me l'envoyer pour que je puisse le transmettre par courriel à l'un de nos développeurs. Bien que j'aie conservé une partie de mon savoir-faire en ce qui concerne MySQL, j'ai failli me retrouver sans idée lorsqu'il s'est agi de la partie compression. Depuis combien de temps n'avais-je pas archivé quelque chose en ligne de commande ? Des années ! J'avais l'impression d'être un vrai débutant, et voici mes réflexions en tant que « n00b », car je peux tout à fait les comprendre. Je ne vais pas vous dire que la mémoire musculaire s'est mise en marche, mais plutôt l'horrible vérité ; je suis donc allé sur duckduckgo.com et j'ai cherché. La plupart de ces choses, je ne les ai pas faites depuis plus de 10 ans. J'ai été tellement gâté par les archiveurs de l'interface graphique que je n'ai jamais eu besoin de les utiliser. Désarchiver n'était pas un problème, mais zipper quelque chose avec des commutateurs sains ? Ayant été un magicien de l'ARJ à l'époque du DOS, j'ai pensé qu'il était temps de me familiariser à nouveau avec les algorithmes de compression. Je vais commencer par les bases, en essayant de ne pas parler des commutateurs.

Commençons par celui que tout le monde connaît, zip.
Pour les fichiers .zip, c'est simple : 

commande <fichier de destination> <fichier source>

Le bon vieux zip ne supprime pas le fichier source une fois que le fichier de destination est créé.

Pour être complet, le contraire de zip est : 

unzip <fichier.zip>


**What stands out with plain ol’ zip is that you can split your zipped files. What you will find, more often-than-not is gzip. 

Gzip aims to be a simpler zipper, with only one parameter needed.

Gzip <source file> 

and bam! All your base are belong to us. Gzip DOES delete the source file once the destination file is created.

Again for completeness sake, the opposite is:

gunzip <filename.gz>

If you ever need help with gzip, simply type 

gzip -h

Bzip or bzip2 that you will see on modern systems works the same as gzip or all intents and purposes. The opposite is bunzip2.

When you install a Linux OS you may have noticed xz. So it may be available everywhere too, and it works just the same as the above, so unxz it is.**

Ce qui distingue le bon vieux zip, c'est qu'il est possible de diviser les fichiers zippés. Ce que vous trouverez, le plus souvent, c'est gzip. 

Gzip vise à être un zipper plus simple, ayant besoin d'un seul paramètre.

Gzip <fichier source> 

et bam ! toutes les bases y sont. Gzip supprime le fichier source une fois que le fichier de destination est créé.

Toujours dans un souci d'exhaustivité, l'inverse est :

gunzip <fichier.gz>

Si vous avez besoin d'aide avec gzip, tapez simplement 

gzip -h

Bzip ou bzip2, que vous verrez sur les systèmes modernes, fonctionne de la même manière que gzip pour nos besoins. Le contraire est bunzip2.

Lorsque vous installez un système d'exploitation Linux, vous avez peut-être remarqué xz. Il est donc possible qu'il soit également disponible partout et qu'il fonctionne de la même manière que le précédent, et c'est donc unxz.


**I’m not getting into compression ratios or speed here, this is more like an overview to help you remember what goes where.

If you do not need any real compression, simply blobbing files together, there is always tar, the tape archiver. It blobs, it does not delete the source file once done. However, I prefer compressing things tightly that need to be transferred over a network. I hate waiting. With tar, you need to remember switches. IN it will be cfz (yes the c is for compression, but it is meh) and OUT it will be xvf. So honestly, I have probably used it twice in my life, though for some reason I remember the switches as cz for the old Czechoslovakia and fx for effects.

Since remembering what does what, is something I’d rather not do, I’d suggest picking a tool and sticking to it. Whilst it is not usually found on servers, unless the person setting it up had proper foresight, p7zip would be my poison. I remember that by: “It’s and a and an e and it’s non-destructive” meaning, you use an ‘a’ to archive and an ‘e’ to extract and it does not delete the source file. Though the package is name p7zip (not to be confused with peazip) the command is simply 7z.**

Je ne parle pas ici de taux de compression ou de vitesse, il s'agit plutôt d'une vue d'ensemble pour vous aider à vous souvenir de ce qui va où.

Si vous n'avez pas besoin d'une réelle compression, mais simplement de regrouper des fichiers, il y a toujours tar, pour l'archivage sur bande. Il compresse et ne supprime pas le fichier source une fois que c'est fait. Cependant, je préfère compresser hermétiquement les choses qui doivent être transférées sur un réseau. Je déteste attendre. Avec tar, il faut se souvenir des commutateurs. IN sera cfz (oui, le c est pour compression, mais c'est nul) et OUT sera xvf. Honnêtement, je l'ai probablement utilisé deux fois dans ma vie, bien que, pour une raison quelconque, je me souvienne de commutateurs comme cz, pour l'ancienne Tchécoslovaquie, et fx, pour les effets.

Comme je préfère ne pas me souvenir de ce qui fait quoi, je suggère de choisir un outil et de s'y tenir. Bien qu'on ne le trouve généralement pas sur les serveurs, p7zip serait mon choix, à moins que la personne qui l'a mis en place n'ait fait preuve de prévoyance. Je m'en souviens grâce à : « C'est un a et un e et ce n'est pas destructif », ce qui signifie que vous utilisez un « a » pour archiver et un « e » pour extraire et qu'il ne supprime pas le fichier source. Bien que le paquet s'appelle p7zip (à ne pas confondre avec peazip), la commande est simplement 7z.


**That said, I was looking at our logs the other day and I was thinking, if I had to take those, (literally gigabytes in size) I’d use gzip. It is the fastest one on the list above.

Now... Your mission.... Should you choose to accept it...

Take one of your movie files and use ‘time’ to see how long each one takes to compress and uncompress that movie and draw your own conclusions. You know how to do this, I was three issues ago.

As to the switches. This is the reason I suggest you pick one and stick to it. 

Now I’m not saying everything you read here is 100% accurate, my observation skills are not the best, probably why my role play characters always have a really high perception skill, but it should be close enough as damnit is to swearing. To add insult to injury, I just realised my seed brittle is a sesame seed brittle, that no-one but my budgies will like…**

Cela étant dit, je regardais nos journaux l'autre jour et je me suis dit que si je devais les prendre (ils font littéralement des gigaoctets), j'utiliserais gzip. C'est le plus rapide de la liste ci-dessus.

Et maintenant... Votre mission.... Si vous l'acceptez...

Prenez un de vos fichiers vidéo et utilisez « time » pour voir combien de temps il faut à chacun pour compresser et décompresser ce film et tirez vos propres conclusions. Vous savez comment faire, je l'ai fait il y a trois ans.

En ce qui concerne les commutateurs. C'est la raison pour laquelle je vous suggère d'en choisir un et de vous y tenir. 

Je ne dis pas que tout ce que vous lisez ici est exact à 100 %, mes capacités d'observation ne sont pas les meilleures, ce qui explique sans doute pourquoi mes personnages de jeu de rôle ont toujours une capacité de perception très élevée, mais cela devrait être assez proche. Pire encore, je viens de réaliser que mon biscuit aux graines est un biscuit aux graines de sésame, que personne n'aimera à part mes perruches...


**Back in the days of floppies, the split ability was very important, hence my ARJ obsession, but just so you know ARJ, LHA, RAR etc are all still valid. (You may have noticed some files, like when you use NZB are split up into smaller compressed ones.) Just not in a base Linux distro as they are not free or open source. So chances are that your alpine Linux container will not have any, but zip, gzip or xz. Keep that in mind. Should base Linux contain non-free or proprietary compression algorithms? Are free and open source compression algorithms behind the times? Is the network transfer time saved by using better compression, wasted on the compression time itself? Let us know your thoughts.

Did I make a boo-boo? misc@fullcirclemagazine.org**

À l'époque des disquettes, la possibilité de diviser les fichiers était très importante, d'où mon obsession pour ARJ, mais sachez que ARJ, LHA, RAR, etc. sont toujours valables. (Vous avez peut-être remarqué que certains fichiers, comme lorsque vous utilisez NZB, sont divisés en fichiers compressés plus petits). Mais pas dans une distro Linux de base, car ils ne sont ni libres ni Open Source. Il y a donc de fortes chances que votre conteneur Linux alpin n'en contienne pas, mais des zip, gzip ou xz. Gardez cela à l'esprit. Linux de base doit-il contenir des algorithmes de compression non libres ou propriétaires ? Les algorithmes de compression libres et open source sont-ils à la traîne ? Le temps de transfert sur le réseau économisé grâce à une meilleure compression est-il gaspillé dans le temps de compression lui-même ? Faites-nous part de vos réflexions.

Ai-je fait une erreur ? misc@fullcirclemagazine.org