Contenu | Rechercher | Menus

Annonce

Si vous rencontrez des soucis à rester connecté sur le forum (ou si vous avez perdu votre mot de passe) déconnectez-vous et reconnectez-vous depuis cette page, en cochant la case "Me connecter automatiquement lors de mes prochaines visites".
Test de l'ISO d'Ubuntu francophone : nous avons besoin de testeurs pour la version francophone d'Ubuntu 14.04. Liens et informations ici.
nombre réponses : 25

#0 Re : -1 »  Commande groupée de Raspberry Pi et idées. » Le 29/05/2012, à 12:38

fabien26
Réponses : 1336

Je pense que je vais m'improviser revendeur de framboises ^^ (mode_opportuniste = yes)

#1 Re : -1 »  Commande groupée de Raspberry Pi et idées. » Le 01/06/2012, à 20:15

fabien26
Réponses : 1336

Siden: Si tu cherches à faire un NAS sous linux, achète un Seagate Goflex Home et hack le en Debian. Là tu as pas mal de puissance, un ethernet Gigabyte, du S-ata et un port USB 2.

Je vais faire une vidéo sur le hack du Goflex Home. Si tu cherches à avoir du RAID sur ton Nas le Goflex Net à deux ports S-ata. S-ata + Gigabit Ethernet, tu peux avoir un débit théorique de 100 mo/s. Avec ton bidule à 200 euros s'il n'a pas de s-ata tu seras limité par l'USB, et donc 20 mo/s idem pour le raspberry.

C'est peut être même pire avec le Raspberry car il doit envoyer 10 mo/s par l'usb pour le réseau et tirer 10mo/s par ce même USB pour récupérer les données sur le disque dur USB. En théorie le maximum en utilisation NAS pour le raspberry est 10 mo/s soit très peu ... (mais adapté car le raspberry est Fast Ethernet et non Gigabit, ce qui veut dire qu'elle ne peut de toute façon pas envoyer plus de 10 mo/S et des brouettes via ethernet).

Le Goflex n'est pas contre pas du tout adapté pour l'affichage HD. Mais pour un prix inférieur au bidule Asus, tu peux avoir le raspberry et le goflex. Le raspberry pour la HD, le goflex pour le partage de fichiers.

#2 Re : -1 »  helly est mort ! :o » Le 22/06/2012, à 00:07

fabien26
Réponses : 1807

Je ne sais pas si quelqu'un l'a déjà dit, mais placer ce topic dans être ou ne pas être semble d'un pertinent donnant un sens nouveau à cette section du Forum ...

En tout cas je suis vraiment triste d'apprendre la mort d'un camarade forumeur que j'ai aperçu plus d'une fois. J'aurais aimé le connaître...

Condoléances et grande tristesse de ma part. La fête de la musique a changé d'ambiance d'un coup dès que j'ai vu ce bandeau sur ubuntu-fr.

#3 Re : -1 »  Forum Ubuntu-fr.org : Le meilleur du pire (3) » Le 29/05/2012, à 09:44

fabien26
Réponses : 1019

C'est une critique de "fond" ^^

#4 Re : -1 »  [Résolu] Quoi ne pas oublier avant de passer à la 12.04 ? » Le 28/05/2012, à 23:03

fabien26
Réponses : 26
L_d_v_c@ a écrit :

Quel conseil bizarre... Mais que se passerait-il si tout le monde attendait avant de faire la mise à jour globale ?

C'est une question qui n'a pas lieu d'être vu que ce n'est pas le cas tongue

Après ça dépend de l'utilisation que quelqu'un fait de son ordinateur. Certains veulent tout, tout de suite, et eux suivrons les versions les unes après les autres à leur sortie.
Et d'autre veulent un système stable et fiable et dans ce cas, mieux vaux utiliser seulement les LTS et en effet migrer d'une LTS à l'autre en attendant la version ".1". Car si on attend pas la version .1, une LTS n'est pas forcement beaucoup plus fiable qu'une versions classique. (elle l'est tout de même plus faut l'avouer, mais certainement moins qu'après la sortie de la .1, voir entre la sortie et la version .1, car comme pour toute version d'Ubuntu la majorité des bugs d'incompatibilité matériel sont corrigés légèrement après la sortie)

#5 Re : -1 »  Topic général sur Unity » Le 27/05/2012, à 23:25

fabien26
Réponses : 2480

Avec 96 Mo de ram, 10 Mo de gagnés c'est pas rien, tu le verrais si tu utilisais du vrai Hardware ... Le problème avec Virtualbox c'est qu'il ne transforme pas ton disque dur actuel, qui est une bête de course (donc très bon pour le swap) en disque dur des époques 4 / 20 Go.

Dès qu'on touche le swap sur ce genre de machines ça rame sévère ! Donc mieux vaux tout faire pour éviter ça ...

#6 Re : -1 »  Topic général sur Unity » Le 27/05/2012, à 23:34

fabien26
Réponses : 2480

C'est ce que je m’efforce à dire bon sang de bois !

#7 Re : -1 »  Topic général sur Unity » Le 27/05/2012, à 23:43

fabien26
Réponses : 2480

Possible qu'il tourne sur Unity 2d car sa carte graphique n'est pas compatible. Car Unity 2d c'est une horreur quand il manque de Ram. L'ouverture du dash surtout quand il a été swappé est particulièrement longue ...

Moi j'utilise Unity 3d sans aucun problème sur un athlon XP avec 396 Mo de Ram.

#8 Re : -1 »  Vos derniers achats sur le net? » Le 28/05/2012, à 23:14

fabien26
Réponses : 113

Je commande souvent sur le net.
Là je me suis pris une carte Micro SD de 8 GO (évitez les 32 Go, il y a trop de contre façon voir de carte faussement labellée 32 GO. qui en fait perdent la boule si on stock plus de 2 go dedans)

Mais les 8 et 16 ne m'ont jamais posé de problème en achat sur Ebay.

Ensuite sur amazon j'ai acheté mais pas encore reçu un Seagate Goflex Home. Il s'agit d'un disque dur externe NAS (donc relié au réseau) qui a la particularité d’être basé sur la même architecture exactement que le Pogoplug et donc est très facilement hackable, installation d'un Linux débridé possible (Debian) et donc les possibilités sont immenses. (Je compte dans un premier temps m'en servir majoritairement comme NAS, mais NAS en NFS au lieu du seul choix possible envisagé à l'origine par le constructeur du partage SMB (et FTP, mais un Nas en FTP c'est pour moi totalement inimaginable !)). J'ajouterais un serveur FTP (proftpd) et infinoted dont j'ai besoin pour mes projets.

Et bien entendu le tout sera contrôlable à distance via SSH !

#9 Re : -1 »  Linux, c'est terminé, je retourne du côté obscur... malheureusement » Le 28/05/2012, à 18:03

fabien26
Réponses : 168

Moi ce dont j'ai l'impression c'est qu'il y a deux poids deux mesures parfois sur la reconnaissance du matériel !

Quand ça ne marche pas "out of the box" sous linux. On dit "Ça y est je retourne sous Windows" mais cette même personne passera 3 jours à fouiller le net pour trouver un pilote foireux pour son imprimante qui subitement ne marche plus depuis qu'il est passé à Seven ... Et s'il ne trouve pas de pilote il ne se dit pas "Ça y est je passe à Linux", il va au magasin s'acheter une autre imprimante bas de gamme complètement pourrie qu'il saurait lui même s'il avait tiré les bonnes conclusions de son précédent achat que le constructeur n'a pas le projet de la supportée après le système d'exploitation microsoft contemporain. (même si j'ai déjà convaincu pas mal de monde à passer à Linux à cause de matériel incompatible avec Windows Vista à l'époque, comme quoi depuis quelque temps les pilotes sous Linux ça commence à passer de défaut à qualité).

D'ailleurs il faut quand même se rendre compte de la chance que l'on a, et que l'on a tendance à oublier du nombre de matériel qu'il suffit de simplement branché pour que ça marche sous Linux. Tant que l'on ne s'aventure pas du côté de périphériques moisi (c'est à dire ceux où on voit que même le constructeur n'y crois pas ...) ou du côté de périphériques ciblés à une tranche des utilisateurs très restreinte, Quasiment tout est compatible parfaitement avec Linux.

J'ai même en tête des périphériques assez élitistes qui fonctionnement très correctement sous Linux comme le Hauppauge HDPVR, qui malgré qu'il soit peu pratique à utiliser sous Linux marche parfaitement bien. Je ne sais pas combien de linuxiens l'utilise mais il ne doit pas y en avoir des masses. Donc même dans les périphériques de ce genre on peut trouver de quoi se satisfaire sous Linux. Mais dans les périphériques "éxotiques", il faut souvent faire pas mal de recherches, souvent anglophones sur le net.

PS: D'ailleurs le coup du Hauppauge, qui est un périphérique de capture YUV pour PC, il existe des alternatives qui marchent mieux que se soit sous linux ou Windows, comme sur mac d'ailleurs (ce périphérique est connu pour ces problèmes avec les anciens Mac Intel). Cette alternative c'est de simplement prendre un périphérique indépendant d'un PC, d'ailleurs c'est le même prix quasiment ... Comme quoi comme je le disais en se renseignant on fait de meilleurs découvertes qu'en se jetant sur le premier truc venu. Et le fait que Linux force (par précaution) à se renseigner un petit peu sur le matériel compatible, fait que l'on n’oublie pas cette règle élémentaire, qui est de ne pas acheter n'importe quoi !

#10 Re : -1 »  adieu ubuntu,bonjour OpenSuse » Le 29/05/2012, à 11:05

fabien26
Réponses : 39

OpenSuse ou Ubuntu c'est du pareil au même. Quand on utilise des logiciels propriétaire ou des logiciels spéciaux qui ne sont pas dans les dépôts, on vérifie s'ils fonctionnent sur la nouvelle version et on attend qu'il soit mis à jour avant de mettre à jour son système le cas échéant ...

Exactement comme on fait sous Windows ou Mac OS avant de passer à une nouvelle version en fait ... Donc ton problème c'est du pur newbisme rien de plus ...

Surtout quand il s'agit d'un module noyau qui ne compile pas, dans tous les cas les distributions quelles qu'elles soient finissent par mettre à jour leur noyau ...

Après ça peut être l'occasion de tester un logiciel mieux supporté sous Linux, VirtualBox. Ou si ce que tu recherches c'est des performances en serveur virtuel sous Linux utilise KVM avec VirtManager (Libvirt).

#11 Re : -1 »  adieu ubuntu,bonjour OpenSuse » Le 29/05/2012, à 12:12

fabien26
Réponses : 39
@null4ever a écrit :

Une réponse plus que simple : sa monstrueuse "daube" (et l'expression est très respectueusement choisie) qui se nomme : Cherokee !

Même pas la peine d'argumenter plus d'une nano seconde !

Il suffit juste de le tester et de le comparer avec de véritables outils de test (certainement pas avec le bon vieux AB mais plutôt avec Weighttpd qui tire effectivement partie des architectures multi-cores

Je ne vois pas le problème avec Cherokee, par contre j'avoue qu'il faut que tu me dises ce qu'est "Weighttpd" parce que ni moi ni google ne connaissont ce magnifique serveur Web ^^

Je pense que tu devais parler de lighttpd mais hum ... quand on ne se rappel même pas du nom comme il faut il y a de quoi avoir des doutes sur ton expertise ...

De plus lighttpd n'est pas multithread contrairement à ce que tu sembles dire. Il est au contraire optimisé pour les serveurs ayant de faibles ressources donc n'ayant au départ qu'un seul processeur. L'optimiser multithread serait une perte de temps et une opportunité pour créer des pertes de performance pour ces plateformes.

Et comme tu es extrêmement vulgaire et irrespectueux je vais donc me permettre de te traiter de "con" vu que ce mot ne semble pas te choquer quand tu parles d’autrui ...

Ensuite pour ce qui est d'Ubuntu qui ne supporterait pas Vmware je rigole bien ! Comme si c'était pas connu que le noyau change d'API de temps en temps ! Je suis sûr que si tu attend un petit peu le pilote vmware va être mis à jour pour Linux 3.2 ... comme c'était le cas pour Linux 2.6.32 pour la 10.04, etc etc ... Car oui si on veut améliorer le système il faut se permettre de changer un petit peu le fonctionnement des pilotes ...

#12 Re : -1 »  Carrefour tourne sous Linux » Le 08/06/2012, à 09:03

fabien26
Réponses : 21

Les caisses de chez Leroy Merlin tournent sous Solaris !

Se sont des caisses Sun Microsystem. Je ne savais pas que Sun faisait du matériel à la fois pour les grosses infrastructures et ... les caisses ...

Ça m'a l'air d'être du très vieux matos car ils tournent encore sur Gnome 1 (C'est en standard sur Solaris ou c'est eux qui ont bidouillé ?!)

Rien à voir avec Linux mais ça prouve que pour ce genre d'applications Windows semble depuis longtemps le dernier système d'exploitation qui vient en tête.

#13 Re : -1 »  Carrefour tourne sous Linux » Le 08/06/2012, à 13:29

fabien26
Réponses : 21

D'expérience, les bornes de retrait d'espèces sont très souvent sous Windows CE, QNX, et OS/2.

#14 -1 »  Comparaison de compresseurs de données - LZO, Gzip, Bzip2, XZ » Le 07/06/2012, à 19:18

fabien26
Réponses : 12

Bonjour les Linuxiens,

J'ai eu besoin pour un projet obscur de comparer la vitesse et le taux de compression de différents format de compression et compresseurs attitrés libres.

Je vais les classés du plus rapide au plus lent, ceci aidant à s'y repérer et en tirer des conclusions pertinentes.

Je me suis donné deux impératifs:
  - Pouvoir compresser à une vitesse convenable sur un processeur très limité (K6-2 underclocké à 250 mhz moins performant que les premiers pentium 2 et Celeron à fréquence égale)
  - Pouvoir fonctionner parfaitement avec très très peu de ram, 28 Mo en l'occurrence. (oui c'est un PC vraiment ancien)

J'ai commencé par faire un .tar de tout mon système Debian installé sur une vielle machine ( cf: http://forum.ubuntu-fr.org/viewtopic.ph … #p4030319). Ce fichier contient donc une Debian fraîchement installée, pleine de fichiers textes, d'images et d'exécutables.

Rappel: le .tar n'est pas un fichier compressé, il s'agit plus d'une archive non compressée contenant tous les fichiers et leurs propriétés et en fait donc un seul très facile à compresser ensuite. Des formats comme le 7zip ou le .zip ont un système qui fait le travail de tar. Mais à l'origine un format de compression n'est capable de compresser qu'un seul fichier. tar faisant le travail de tout regrouper avant la compression. (ce processus peut être automatisé bien entendu et est normalement totalement transparent).

Début des résultats:

# time lzop -vc /Debackup.tar > /Debackup-def.tar.lzo
   4m42.48s real    2m19.24s user     0m30.61s system
# du -m /Debackup-def.tar.lzo  # <- Cette commande renvoie la taille en Mo d'un fichier
376    /Debackup-def.tar.lzo  # Taille en Mo puis nom du fichier, voici ce que renvoi cette commande.

Ouah ça commence vite pour un si vieux joujou !
Et comme vous le voyez au fait que "user" et "real" sont très différent, le processeur n'était qu'à 50% lors de la compression, ce qui voudrait dire que l'on pourrait aller encore plus vite si je changeais de disque dur. ("time" ajouté devant n'importe quelle commande permet de voir le temps qu'elle a mise à s'exécuter. Real correspond au temps Réel, User le temps que le programme à travaillé et System le temps que le noyau Linux a travaillé pour gérer le programme)

# time lzop -"1à6"vc /Debackup.tar > /Debackup-"1à6".tar.lzo
   sensiblement les mêmes temps et exactement la même taille de fichier.

Là je ne comprendre pas. De -1 à -6 aucune différence, ce paramètre ne sert à rien du tout...

# time gzip -1vc /Debackup.tar > /Debackup-1.tar.gz                            
/Debackup.tar:   59.8%
    8m19.20s real     7m13.40s user     0m27.04s system
315     /Debackup-1.tar.gz

Gzip lancé avec l'option -1 (-1 à -9 permettent de choisir la "force" de la compression, par défaut c'est -6) rapporte un temps très correct étant donné qu'on ne dispose pas de beaucoup de ressources. gzip -1 est donc une très bonne alternative à lzop dans ce cas. 2 fois plus de temps (4 fois plus si le HDD avait été plus rapide) et une compression bien plus forte.

# time gzip -c /Debackup.tar > /Debackup-def.tar.gz                           
/Debackup.tar:   63.0%
   19m59.64s real    18m57.31s user     0m28.28s system
290     /Debackup-def.tar.gz

Malgré qu'ils soient bien plus lents, les paramètres par défaut de gzip restent un bon compromis entre temps passé et compression. Transformer 781 Mo en 290 Mo en 20 minutes est un score surprenant.

# time xz -z0vc /Debackup.tar > /Debackup-0.tar.xz                             
/Debackup.tar (1/1)
  100 %       247,7 MiB / 781,3 MiB = 0,317   457 KiB/s      29:09             
   29m10.73s real    27m51.02s user     0m23.04s system
248     /Debackup-0.tar.xz

Pour dix minutes de plus on gagne encore 40 Mo ! Bien plus rentable que gzip ! Xz est un format de compression récent basé sur LZMA, et il m'impressionne par sa vitesse ! Bien entendu il faut pour cela activer la compression minimale. Qui reste malgré tout extrêmement compressante !

# time xz -z1vc /Debackup.tar > /Debackup-1.tar.xz                             
/Debackup.tar (1/1)
  100 %       234,6 MiB / 781,3 MiB = 0,300   350 KiB/s      38:03             
   38m5.03s real    36m33.73s user     0m23.96s system
235     /Debackup-1.tar.xz

Et encore 10 minutes de notre temps précieux de perdu pour gagner ce coup ci 13 Mo de plus ! C'est peu et c'est le maximum que l'on peut avoir dans les limites du raisonnable sur ce PC. Au delà de -1 xz utilisera en effet trop de Ram. Et les 28 mo de Ram de ce PC limitent Xz à -1. -2 créera un enfer de lag à cause de l'obligation de passer massivement par le Swap. Une très mauvaise idée si on ne veut pas compresser un fichier pendant 4 jours. Il en reste quand même que même sur un ordinausaure comme celui ci on peut parfaitement utiliser XZ. Ce qui veut dire qu'il a de beaux jours devant lui ! On pourrait en effet imaginer utiliser XZ comme format de compression par défaut des .deb et ainsi réduire énormément le temps de téléchargement des mises à jours ! (les index des dépôts sont déjà en LZMA (peut être pas XZ)).

# time lzop -7c /Debackup.tar > /Debackup-7.tar.lzo
   45m2.98s real    42m10.41s user     0m29.62s system
316    /Debackup-7.tar.lzo

Alors là nous commençons à entrer dans l'antre de la perte de temps ... Alors déjà je tiens à réaffirmer ma confusion face à lzop ... -1 jusqu'à -6 aucun changement, mais -7 commence à donner un résultat, et quel résultat ! Un résultat sans équivoques, nous avons perdu notre temps ! Et bien en plus ! Pour 7 minutes de plus que xz nous avons un fichier 80 Mo plus gros ! Le seul argument de LZO étant la vitesse c'est un peu perdre tout l'intérêt du truc. Mais bon ...

# time bzip2 -z1vc /Debackup.tar > /Debackup-1.tar.bz2                          
  /Debackup.tar:  2.829:1,  2.828 bits/byte, 64.65% saved, 819261440 in, 289574292 out.
   45m3.23s real    43m13.42s user     0m27.75s system
277     /Debackup-1.tar.bz2

Ah passons à notre gros looseur du jour, bzip2 ! Il n'est nul par sur les podiums. Peut être sur le podium de l'inutilité sur lequel il est roi désormais. Il ne faut pas non plus être trop méchant avec ce format, il fut autrefois très utile, il compresse comme vous le voyez bien plus que gzip quelque soit le réglage (même le plus rapide comme vous le voyez ici) mais depuis l'arrivée de xz il ne fait décidément plus le poids, et il ne serait pas étonnant de voir disparaître totalement les .tar.bz2 des téléchargements au profit des .tar.gz (déjà standard) et .tar.xz.
Nous sommes au réglage le plus rapide et comme vous le voyez bzip2 n'est pas bien rapide, 45 minutes pour faire moins bien que ce que peut faire xz en 30 minutes c'est plutôt pathétique.

# time bzip2 -zvc /Debackup.tar > /Debackup-def.tar.bz2                                                                          
  /Debackup.tar:  2.975:1,  2.689 bits/byte, 66.39% saved, 819261440 in, 275381190 out.
   55m38.24s real    53m8.15s user     0m25.56s system
263     /Debackup-def.tar.bz2

Pour 10 minutes avec bzip2 de plus (en utilisant les paramètres par défaut) nous gagnons 13 Mo. C'est maigre, c'est peu compétitif, ça n'apporte aucun avantage face à la concurrence, c'est bzip2 ...

# time bzip2 -z9vc /Debackup.tar > /Debackup-9.tar.bz2                                                                           
  /Debackup.tar:  2.975:1,  2.689 bits/byte, 66.39% saved, 819261440 in, 275381190 out.
   55m45.82s real    53m6.99s user     0m26.23s system
263     /Debackup-9.tar.bz2

C'est moi ou -9 est le choix par défaut chez bzip2 ? J'aime la triche !

# time gzip -9vc /Debackup.tar > /Debackup-9.tar.gz                              
/Debackup.tar:   63.2%
   59m26.76s real    57m34.01s user     0m26.62s system
# du -m /Debackup-9.tar.gz                         
289     /Debackup-9.tar.gz

L'une des plus grosses aberrations que je découvre avec ce comparatif, l'option -9 de compression maximale de gzip qui, regardez à nouveau un peu plus haut, fait gagner 1 Mo (oui 1 malheureux Mo !) au dépend de 40 minutes de travail supplémentaire ! C'est à se demander pourquoi il existe des paramètres au dessus de -6 dans gzip ... Complètement incompréhensible ...

# time xz -z0evc /Debackup.tar > /Debackup-0e.tar.xz                           
/Debackup.tar (1/1)
  100 %       224,1 MiB / 781,3 MiB = 0,287    83 KiB/s    2:41:18             
  161m19.04s real   156m29.89s user     0m25.58s system
225     /Debackup-0e.tar.xz

xz propose une option -e cette option permet d'augmenter la compression au dépend d'une utilisation plus importante du processeur. J'étais curieux de voir ce que cela pouvait donner. La réponse est là, une attente interminable ! Mais en dehors de cela on y gagne pas mal !

# time lzop -9vc /Debackup.tar > /Debackup-9.tar.lzo

Ridiculement long ! Au bout d'une heure j'étais encore à 130 Mo ... Le mode compression maximale de lzo est à oublier. Le seul intérêt de ce compresseur est sa vitesse, ce mode à de quoi dérouter car on a ni la vitesse ni la bonne compression (de toute évidence). Je ne sais pas ce qu'ils ont dans la tête quand ils ont entre les mains un compresseur qui n'a que sa vitesse pour argument et qu'ils te mettent ce genre de modes totalement inutiles. Bon je suis désolé d'être aussi énervé contre un programme de quelques Ko mais l'attente m'a mis KO ...

Changeons de PC pour analyser un peu plus en profondeur notre champion XZ.
Les tests ont été fait sur un Core 2 Quad 3,6 Ghz pour des raisons de Ram et de vitesse. Les paramètres par défauts de XZ restent parfaitement utilisables sur un PC modeste (par exemple un pentium 4 avec 512 Mo de Ram), les paramètres minimaux sont parfaitement utilisables même avec des ressources très restreintes, que peut on dire des paramètres maximums. Es-ce qu'ils ont un effet contrairement aux autres compresseurs ? Nous allons voir ça !

# time xz -zvc ./Debackup.tar > ./Debackup-def.tar.xz
./Debackup.tar (1/1)
  100 %       198,8 MiB / 781,3 MiB = 0,254   1,8 MiB/s       7:09             

real    7m9.211s
user    7m7.375s
sys    0m1.276s
utilise environ 90 Mo de ram
199    ./Debackup-def.tar.xz

Avec les paramètres par défaut xz compresse vraiment beaucoup beaucoup. Et c'est magnifique ! Gardez à l'esprit que ce fichier ne pourra pas être décompressé avec mon vieux Medion (28 Mo de ram rappel) car la RAM utilisée pour la compression est la même que pour la décompression. Le mode par défaut demande donc 90 Mo, il faudra un PC avec un minimum de 192 Mo de ram pour décompresser ce fichier à l'aise. (ou 128 Mo sans interface graphique)

# time xz -z9vc ./Debackup.tar > ./Debackup-9.tar.xz
./Debackup.tar (1/1)
  100 %       179,0 MiB / 781,3 MiB = 0,229   1,6 MiB/s       8:16             

real    8m16.503s
user    8m13.087s
sys    0m1.708s
utilise environ 670 Mo de ram
180    ./Debackup-9.tar.xz

Poussons xz à fond ! Là nous utilisons vraiment beaucoup trop de RAM et je comprend pourquoi ce mode n'est pas actif par défaut, mais le temps passé à compresser reste très raisonnable. et le gain (près de 20 Mo) est significatif. On peut donc facilement comprendre l'utilisation de ce mode si votre ordinateur à un minimum d'un GO de mémoire vive, 2 GO pour être à l'aise (attention juste à ne pas envoyer ce fichier à un windowsien avec 2 GO de ram car il va swapper à mort)

# time xz -zevc ./Debackup.tar > ./Debackup-e.tar.xz
./Debackup.tar (1/1)
  100 %       198,5 MiB / 781,3 MiB = 0,254   1,4 MiB/s       9:26             

real    9m26.819s
user    9m25.479s
sys    0m1.164s
199    ./Debackup-e.tar.xz

L'option -e utilise plus de processeur, mais pas plus de RAM, par contre, même si elle peut être ajoutée à n'importe quel autre paramètre de force de compression elle ne change plus grand chose à partir de -2

# time xz -z9evc ./Debackup.tar > ./Debackup-9e.tar.xz
./Debackup.tar (1/1)
  100 %       178,6 MiB / 781,3 MiB = 0,229   1,2 MiB/s      10:58             

real    10m58.810s
user    10m56.521s
sys    0m1.708s
-e ne change pas l'utilisation de la RAM
179    ./Debackup-9e.tar.xz

Idem ... Peut être que si le fichier à compresser faisait plus de 20 Go on pourrait voir une différence mais je doute qu'elle soit significative.

Conclusions pour XZ:
  * L'option -e requiert un très bon processeur et est utilisable avec tous les réglages pour augmenter encore plus la compression au dépend de l'utilisation processeur.
  * -0 jusqu'à -9 augmentent progressivement l'utilisation de la RAM et modérément l'utilisation du processeur. Gardez à l'esprit que la Ram demandée lors de la compression sera aussi demandé lors de la décompression (pour -9 vous ne pourrez pas le décompresser sur un PC avec 512 Mo de ram, en tout cas pas en moins d'une semaine)
  * -e ne sert à rien si on vise une haute utilisation de ram (entre -4 et -9) et que l'on ne compresse pas des dizaines de GO. Mais est très avantageux pour augmenter la compression tout en utilisant un minimum de ram (rappel la ram utilisée pour la compression est la même que pour la décompression). Cette option peut donc être très utile si vous comptez envoyer le paquet le plus petit possible et qu'il peut concerner des ordinateurs peu puissant (reste à savoir si -e allonge ou pas le temps de décompression, je pense que non mais des tests sont à faire.)

Voilà donc ce qui conclu cette comparaison des compresseurs les plus populaire dans le monde du libre. On peut en conclure que:
  - LZO est vraiment très rapide, il peut même permettre d'aller plus vite que son disque dur, et ce même sur un vieux coucou
  - XZ est le champion toute catégorie de la compression pure et ce à toutes les vitesses sauf "rapides comme le vent"(Gzip) et "rapides comme l'éclair"(LZO).
  - Utiliser Gzip en compression minimale offre un bon compromis entre LZO et XZ, c'est à dire vitesse et compression pure
  - Les options de compressions poussés à bout ne servent qu'à perdre votre temps (-9e pour XZ et -9 pour lzo, gzip et bzip2)
  - Bzip2 ne sert plus à rien et doit passer de technologie fastueuse à relique du passé ! Il n'a aucun bon point, pas un seul ! Même pas un petit ... Si en creusant on peut en trouver un ... Si votre PC n'a pas xz, il permet d'avoir un fichier plus petit à télécharger pour télécharger XZ ^^ Mais une fois que l'on a xz, il n'a absolument aucun intérêt. D'ailleurs j'ai eu la surprise de voir qu'après une installation minimale de Debian Xz était installé mais bzip2 devait être installé manuellement, ils ont tout compris.

Petit mot pour les absents:
  - zip: le zip est théoriquement identique à gzip, il utilise le même algorithme et donc doit avoir des résultats similaires.
  - lzma: lzma est en gros l'ancienne version de xz (lzma2). lzma est lent et lourd, et est connu pour compresser de manière sensiblement identique (xz fait même mieux). Pas besoin de perdre du temps à le tester donc.
  - 7zip: Très populaire sous windows, et par conséquent sous linux, ce format est lui aussi dérivé de lzma. Des tests personnels m'ont permit de voir qu'il compresse avec des taux identiques à xz. Peut être est il plus ou moins rapide, je n'ai pas pris le temps de le mesurer. Mais il ne convenait pas à mon usage. Les .tar.7z ça fait un peu bâtard comme format et il n'est pas possible à ma connaissance de faire un .tar pendant la compression comme avec les formats testés ce qui fait perdre un temps considérable. J'ouvre une parenthèse pour dire que le Tar est important sous linux, il permet de garder le fichier et aussi ces propriétés comme les permissions. Les formats zip, et 7zip ne peuvent pas les conserver ce qui peut gêner ce qui est compressé surtout quand ce que vous compressez est un programme.
  - Qpaq, Zpaq, etc formats peu diffusés. Pas assez diffusés et souvent à raison. Ou ils sont en développement, ou ils sont inutiles (recherches infructueuses), ou ils sont totalement inutilisable si on a pas un PC de malade mental (même mon core 2 qui compresse un fichier de 800 Mo en XZ en 10 minutes avec les paramètres maxi prendrait un temps phénoménal - comparables à ceux du vieux Medion) Ma curiosité aidant ça sera peut être l'occasion d'un autre test.

#15 Re : -1 »  Comparaison de compresseurs de données - LZO, Gzip, Bzip2, XZ » Le 07/06/2012, à 21:51

fabien26
Réponses : 12

Tu as totalement raison je vais mettre des balises code !

#16 Re : -1 »  Comparaison de compresseurs de données - LZO, Gzip, Bzip2, XZ » Le 08/06/2012, à 08:18

fabien26
Réponses : 12

J'ai déjà eu à faire ce genre de Benchmark. malheureusement je n'ai pas noté les résultats, mais ils étaient surprenants.

C'est à dire qu'en gros avec le même processeur, la même ram, la même carte réseau, on peut avoir un énorme gain de performance en changeant la carte mère contre une bonne carte mère (Chipset Via et SiS VS chipset Intel) J'avais testé avec un Pentium 3 533 Mhz.

Avec le Pentium 3 en NFS si on active le mode asynchrone et que l'on utilise le protocole UDP on peut atteindre 17 Mo/s dans les deux sens. Ce qui n'est pas mal du tout pour une si vielle machine.

J'ai un autre benchmark dans les bacs que j'ai fait pour faire un rapport de Bug pour gvfsd. Il concerne d'ailleurs lui aussi les NAS.

#17 Re : -1 »  Comparaison de compresseurs de données - LZO, Gzip, Bzip2, XZ » Le 08/06/2012, à 13:19

fabien26
Réponses : 12

Oui par défaut le .7z et .tar.7z utilisent le format interne LZMA sous Linux comme sous Windows. C'est le format par défaut de ce type d'archives et c'est celui qui a le meilleur rapport Temps/Compression.

Le XZ offre des compressions quasi identiques à 7zip mais est bien plus rapide que 7zip quand on cherche à faire un .tar.*

Les .tar.xz sont décompressible sous Windows avec 7zip il me semble, donc ce format ne pose pas de problèmes pour les windowsiens.

Edit: Oui file-roller comme n'importe quel GUI de compression sous Linux utilise les paramètres par défaut des différents formats de compression (les tests avec -def dans le nom du fichier compressé reflètent le comportement des GUI)

Pour ce qui est de la compression des images et des vidéos. Tout comme pour la musique en .mp3/ogg/aac. Il n'y a aucun gain à les compresser car ces formats utilisent déjà en interne des compressions diverses et variés qui sont pour la plupart adaptés spécifiquement au format qu'ils traitent et qui sont donc bien plus performants. En gros c'est comme compresser un fichier compressé, ça n'offre aucun gain. Ça peut même faire perdre de la place ! (Il n'est pas rare que lorsque l'on compresse un fichier compressé) les descriptifs de contenu s’accumulent et donc le fichier gonfle.)

Dans la pratique j'ai pu quand même voir des résultats étonnants à compresser des fichiers .jpg et des .mp3. On peut parfois gagner quelques dizaines de Mo sur une très grosse bibliothèque. Mais on aurait plus vite fait de convertir directement ces fichiers dans un format plus performant (comme passer les .mp3 en .ogg).

#18 Re : -1 »  Comparaison de compresseurs de données - LZO, Gzip, Bzip2, XZ » Le 08/06/2012, à 13:52

fabien26
Réponses : 12
The Uploader a écrit :
fabien26 a écrit :

Mais on aurait plus vite fait de convertir directement ces fichiers dans un format plus performant (comme passer les .mp3 en .ogg).

Oui, mais tu perds en qualité audio dès que tu encode avec un format de compression avec perte, tel que Ogg Vorbis.

Je parles de MP3, les passer de MP3 à Ogg n'est pas une perte vu que l'original est déjà un format à perte. Après pour les formats sans perte, hors le Wav ils sont déjà compressé lossless. Le flac par exemple compresse très bien la musique. Bien mieux que si l'on faisait un .tar.xz contenant des wav et bien plus pratique à utiliser que décompresser puis lire.

#19 Re : -1 »  Comparaison de compresseurs de données - LZO, Gzip, Bzip2, XZ » Le 08/06/2012, à 14:10

fabien26
Réponses : 12
The Uploader a écrit :
fabien26 a écrit :

Je parles de MP3, les passer de MP3 à Ogg n'est pas une perte vu que l'original est déjà un format à perte.

Oui, mais ça c'est autre chose. N'importe quel format avec perte va augmenter la perte de données par rapport à l'original, ça fait partie de leur fonctionnement. wink

C'est là où tu te trompe, c'est bien plus complexe que cela. Un format avec perte n'est pas un format qui ajoute volontairement de la perte à chaque recompression. Bien entendu à chaque recompression des bizarreries vont s'ajouter c'est le syndrome du photocopieur, quand on photocopie une photocopie et que l'on photocopie cette photocopie, etc au fur et à mesure le tout deviendra bien moins beau. Mais on a de la marge avant que la destruction prenne le pas sur le gain de place dans le cas d'un passage par exemple d'un format d'ancienne génération à un nouveau format. Le passage de MP3 à Ogg permet de garder la même qualité perçue en gagnant environ 12 kb/s (pour un 128 kb/s)

#20 Re : -1 »  Comparaison de compresseurs de données - LZO, Gzip, Bzip2, XZ » Le 08/06/2012, à 14:19

fabien26
Réponses : 12
The Uploader a écrit :

Bien sûr qu'il y a de la marge avant que la perte ne devienne audible, dans la plupart des cas... Mais je préfère ne rien risquer (donc ne pas convertir).

Je ne converti que quand j'ai besoin de place et que la différence de taille se fait ressentir. (et que la qualité reste la même). Mais je fais surtout ça avec les vidéos, la différence entre un Ogg et un Mp3 à qualité égale étant négligeable sur les disque dur d'aujourd'hui ... Sur un téléphone portable par contre !

#21 Re : -1 »  [Éco] L’histoire du piratage dans les jeux vidéos » Le 07/06/2012, à 18:44

fabien26
Réponses : 41
Hibou57 a écrit :

qui raconte comment chaque fois que le piratage est arrivé sur une plateforme, il a tout fait couler. Alors succède une nouvelle plateforme, mieux protégée, la création redevient plus florissante

Je confirme The_Uploader, N'importe quoi ! On peut difficilement plus "n'importe quoi" !

Exemples: La PS2, La Wii, la Xbox 360, je peux continuer, la Nintendo DS ... Qu'es-ce qu'ils expriment ces exemples ? Elles sont parmi les consoles les plus simples à pirater/hacker de tous les temps ! Et pourtant se sont aussi les consoles les plus vendus ... Cherchez l'erreur !

Non le piratage n'a aucun impact là dessus, d'ailleurs cet article aurait du faire un minimum de recherche en hacking avant de se faire écrire car toutes les consoles les plus populaires sont facilement piratable. (oui je sais c'est une phrase étrange mais je tiens à ne pas juger l'auteur)

D'ailleurs certaines consoles sont de vraies forts Knox et pourtant elles n'ont jamais connu le succès. La Gamecube par exemple. La PS3 aussi qui est la moins vendu de cette génération n'est facilement hackable que depuis très peu de temps relativement à sa disponibilité. Donc non, les développeurs de jeux ne "sautent" pas sur les consoles qui leur apportent de la sécurité. Non ils sautent simplement sur ce qui se vend ... Comme les hackeur d'ailleurs.

#22 Re : -1 »  Comment Compiler un programme en 32 bits sur un système 64 bits » Le 07/06/2012, à 12:00

fabien26
Réponses : 10

On peut aussi faire un chroot 32 bits, c'est ce que j'ai fait au final.

Un petit debootstrap dans un dossier, on chroot dedans et on peut carrément installer des paquets à la main, etc etc. et bien entendu compiler sans retenue.

#23 Re : -1 »  Paiements en ligne / Paiements refusés » Le 29/05/2012, à 09:39

fabien26
Réponses : 15

Je n'ai jamais testé le système de payements du crédit agricole mais j'ai toujours eu des emmerdes avec cette banque ... Si leur service Web est du même niveau que leurs prestations normales j'en donne pas cher ...

#24 Re : -1 »  Révolution matinale » Le 29/05/2012, à 08:23

fabien26
Réponses : 47

La flemme ! Meilleur moteur pour trouver des idées d'inventions ^^

Moi comme "réveil" j'utilise un système de coupure/allumage automatique.

En gros ça allume la lumière automatiquement tous les jours à la même heure sur ma lampe de chevet, très pratique pour se réveiller en douceur !

Après certains ne sont pas dérangés par la lumière dans leur sommeil.