Questions de n00b mac - Page 15

Brunni (./416) :
Tu n'as pas besoin d'un topic comme ça pour troller, il te suffirait de tester un Mac. Ca te donnerait 40000 raisons de plus de troller, mais ce n'est pas dit que tu aurais toujours autant envie de le faire ^^

Merci pour les conseils (et oui Nil j'ai cité 7zx), je vais tester tout ça. Perso j'adore le 7zip file manager sous Windows (et Ark est bien aussi sous KDE), j'apprécierais un truc du genre sous Mac, pouvoir visualiser les fichiers avant de tout extraire quoi, parce que ça peut prendre pas mal de temps et laisser du bordel derrière.

BetterZip est la solution a ta question

Bon au final on dirait qu'il faut en rester à la solution par défaut, double clic pour extraire (automatique si téléchargé), et 'show in finder' + quicklook juste pour voir le contenu (mais pas extraire un fichier spécifique...). J'ai utilisé un workflow fourni avec keka pour pouvoir compresser en 7zip depuis un menu contextuel, mais pas trouvé comment enlever l'entrée "Compresser" par défaut de l'OS

Y a vraiment un intérêt à 7zip comparé à du zip ou du tar.gz ?

Ça compresse mieux, et il me semble que le cryptage (si on l'utilise) est de meilleure qualité. Je sais pas s'il y a pas aussi une correction d'erreur au cas où l'archive est corrompue (comme pour le RAR), aussi.

Zerosquare (./424) :
Ça compresse mieux

Mieux que tgz, peut ^tre, j'ai pas vérifié, mais comparé à zip (et RAR, j'en parle pas) j'ai toujours eu des fichiers plus gros au format 7zip...

tgz compresse nettement mieux que le zip ^^
Enfin, personnellement je m'en moque un peu de la taille, que ça fasse 2 ou 3 Mo ne changera pas grand-chose à ma vie, et je compresse rarement des fichiers de 10 Go ^^

Oui, 7zip compresse très nettement mieux que zip et un peu mieux que rar. Bien sur après ça dépend des fichiers, parfois ça ne changera presque rien, mais parfois la différence peut être énorme (j'ai eu des cas où c'était un facteur 10, comme sur des images ROM ou des logs de musique de jeu). D'une façon générale avec ce que je distribue c'est assez couramment un facteur 2, et c'est un gros plus pour la bande passante de mon site, le temps d'upload, etc.

Par exemple si je prends une grosse appli au hasard:

Ici autant dire que le distributeur et l'utilisateur apprécieront

(et chacun donne ses expériences, mais comme ça peut dépendre des types de fichiers compressés, ça ne veut au final pas dire grand chose ^^)

Ben oui que ça veut dire quelque chose... entre 39 Meg et 70 Meg si je dois distribuer une appli sur mon site j'ai une préférence pour la plus petite (surtout qu'il y a encore pas longtemps j'avais 25k/sec d'upload). Si tu me donnes un cas où un fichier compressé en 7-zip est 2x plus gros que le ZIP ou RAR équivalent à ce moment je veux bien, mais actuellement j'ai jamais eu de cas où le 7-zip était même plus grand que les autres...
Après si tu compresses une image PNG ça ne changera rien c'est sûr, mais faut pas être non plus...
D'ailleurs je viens de faire un test avec le répertoire de mon rapport de projet de diplôme, qui a pas mal d'images, des PDF et des fichiers latex source et générés (donc un peu de tout quoi), et j'obtiens:
* 24.9 Meg non compressé
* 21.5 Meg compressé en ZIP
* 7.4 Meg compressé en 7-zip

Brunni (./429) :
Après si tu compresses une image PNG ça ne changera rien c'est sûr, mais faut pas être non plus...

Entièrement d'accord, c'est bien pour ça que les retours des uns et des autres, sans aucun contexte, ça n'a, amha, pas grande valeur.

Par contre, ton exemple est plutôt bluffant

Brunni, questio bete, mais quel sont les options que tu as utilisé pour généré le .zip ? si les options ne sont pas les memes, tu peux obtenir des résultats très différents

J'ai utilisé Keka et j'ai mis en Ultra pour les 2 (on peut pas configurer plus que ça... #apple# quoi). J'ai la flemme de sortir mon PC et utiliser 7-zip, dont je sais que le compresseur ZIP est de bonne qualité et intègre beaucoup d'options.
Je ne sais pas si Keka a le meilleur compresseur ZIP, c'est sûr, mais j'ai testé avec le compresseur d'Apple intégré, et il donne des ZIP un peu plus gros que Keka, donc on ne doit pas être trop loin.

Non mais cherchez pas les gens Brunni a raison et c'est pas la peine d'essayer de chercher la petite bête ou autre… À moins d'utiliser un format encore plus "exotique" que le 7z (surtout que celui-ci est devenu assez standard dernièrement ^^) vous obtiendrez assez rarement des résultats de compressions supérieurs de plus de 1% à 2% au 7z…
Y'a une deux explications très simple au fait que le 7-zip compresse mieux que les autres formats "quasiment tout le temps".
D'une part il embarque des algorithmes de compression qui font partie des meilleurs disponibles. D'autre part, il permet de créer des archives "solides" (comme le format RAR). Ce que le format ZIP ne gère pas.
Ça veut dire que si on compresse une archive avec 5 fichiers très similaires (mettons 90% ), de base on sait déjà que le format zip sera à peu près 5 fois plus gros que le format 7z…
En fait il faudrait compresser les archives en .tar.zip pour se faire une idée plus juste de la différence au niveau des algorithmes purs

Folco a raison, sans le contexte ça donne pas beaucoup d'infos

J'ai fait le test y'a pas longtemps (en fait c'était un collègue de taf qui était -comme vous- persuadé que 7zip ferait mieux que winrar...) :
- un peu plus de 2 millions de fichiers
- des tailles allant de 0 ou 1 octet à 3Go
- une taille totale de ~50Go (80Go "sur le disque", même après defrag)
- compression en archive "solide"
- taux de compression maximal possible

=> avec winrar, ~12heures pour un fichier final d'un peu moins de 8Go
=> avec 7zip, près de 20 heures pour un fichier qui faisait près de 32Go au final...

Et les fois précédentes où j'ai utilisé 7zip, l'archive était corrompue dès la fin de la compression quand il l'atteignait...

Dommage... ^^ Fais plus de tests, et avec des jeux de données raisonnables (et utilise le compresseur officiel, parce que le plantage c'est pas normal)

Vince: t'as choisi quelle taille de dico et quel algo pour le 7-zip ? Ça peut influencer les résultats.

Autre truc à propos de Mac, j'ai de la peine à supporter le grattage incessant du disque dur au démarrage de l'ordinateur. Et ça dure longtemps en plus, pendant ce temps spotlight n'est pas accessible (je l'utilise beaucoup pour lancer les applications...). Il faut attendre à peu près 5 minutes avant que l'indexation soit disponible et que le disque se calme un petit peu...
(J'ai un 5400 rpm, ça peut jouer, mais pas question de changer car cet ordi est en prêt; inutile aussi de me dire de ne jamais redémarrer, les performances graphiques du système se cassant la gueule avec le temps, je préfère redémarrer pas trop rarement)
Un regard à fs_usage montre que ce con (mds/mdsworker, qui s'occupent des métadata/indexation) parcourt tout plein de fichiers, y compris sur ma partition BOOTCAMP non indexée.


Question: c'est normal? Y a-t-il moyen de le faire cesser, tout en bénéficiant quand même de l'indexation? (par exemple je serais heureux s'il n'indexait que ~/Documents et /Applications et évite d'avoir à parcourir tout le FS, qui est encore amené à grossir)

Brunni (./435) :
Dommage... ^^ Fais plus de tests, et avec des jeux de données raisonnables (et utilise le compresseur officiel, parce que le plantage c'est pas normal)

C'est quoi cette mentalité à la con ? Juste parce que mon cas d'utilisation ne correspond pas à tes attentes je dois en changer ?

"7zip, il compresse super bien certains types de fichiers, les autres, supprimez-les"



0² > je n'ai pas joué avec la taille de dico, l'algo j'ai laissé celui par défaut...

vince> Non, je te conseille juste de ne pas généraliser sur un seul test peu formel et étoffer un peu ton expérience avant de déconseiller si vivement quelque chose aux autres, c'est valable en général ça (et j'émets des doutes sur la validité de ton compresseur, car je n'ai jamais eu de plantage sur 5 ans d'utilisation du format, mais ça c'est toujours pareil; mon Mac a "planté" 2 fois en une semaine alors que certains te diront que c'est jamais arrivé)

Non, le Mac plante "beaucoup" quand tu t'en sers la première fois
Par contre, par la suite heu... ^^
Et de même que 0^2 je pense que tu aurais du regarder la taille du dictionnaire. Les valeurs par défaut permettent de faire tourner le compresseur sur la plupart des machines sans les mettre a terre, mais si tu utilise le truc de manière un peu plus poussée il me semble logique de ne pas se contenter de la config par défaut (Mais qui dit données monstrueuses dit pc monstrueux)
En tout cas, jamais eu d'archive corrompue non plus... Et de nos jours lama est utilisé partout alors vaut mieux que ça marche

GoldenCrystal (./440) :
Et de nos jours lama est utilisé partout alors vaut mieux que ça marche

(tu veux dire LZMA, non ? ^^)

Bruni: tu le laisse tourner jusqu'a bout, il ne te ferra plus "chier" apres. Forcement si tu le coupe a chaque fois il recommencera du début

Godzil (./442) :
Bruni: tu le laisse tourner jusqu'a bout, il ne te ferra plus "chier" apres. Forcement si tu le coupe a chaque fois il recommencera du début

Hum comment savoir s'il est au bout? Parce que là il a travaillé 15 minutes, et maintenant (2h plus tard) le disque ne gratte plus. Mais si je reboote, alors le disque recommence à gratter 5 minutes après le démarrage, et mds/mdsworker est le responsable

GoldenCrystal (./440) :
Non, le Mac plante "beaucoup" quand tu t'en sers la première fois Par contre, par la suite heu... ^^

Comme Windows sur une config potable je suppose. Enfin j'ai laissé "plantage" entre guillemets car ce n'est rien que je n'aie jamais vu sur aucun OS et je ne m'en plains pas, la 1ère fois c'étaient les performances graphiques qui ont chuté au-dessous de l'acceptable après un retour de veille (genre 5 fps en bougeant une petite fenêtre), m'obligeant à rebooter. Aujourd'hui ce sont les touches de volume et luminosité qui ont tout à coup cessé de fonctionner, et le système ne répondait plus à "Log out", "Shutdown", etc. ne laissant comme solution qu'un sudo reboot.
D'ailleurs, quel genre d'erreur tu peux faire qui le fasse planter? (à part comme moi un rm -rf monUser)

Brunni (./443) :

Hum comment savoir s'il est au bout? Parce que là il a travaillé 15 minutes, et maintenant (2h plus tard) le disque ne gratte plus. Mais si je reboote, alors le disque recommence à gratter 5 minutes après le démarrage, et mds/mdsworker est le responsable

Quand il indexe pour la premiere fois, le menu spotlight est assez explicite

Ok, jamais vu. Bah j'imagine que l'indexation s'est bien faite alors, surtout que je lui ai laissé le temps... par contre ça n'explique pas que mds ait besoin de parcourir toutes les partitions au démarrage non?
GC, Godzil et les autres, c'est normal qu'il fasse ça? J'ai pas vraiment les moyens de réinstaller pour m'en assurer...

./441 > Ouais, correction auto de l'iPhone… :/
Brunni > Un défaut de Mac OS est qu'il n'est pas très réactif… Si au niveau fiabilité il n'y a rien à redire (je parle pas de la sécurité hein ), ils ont encore pas mal d'améliorations à faire si je compare à Windows 7 sur la même machine. (Sérieusement…)
Sur Windows, les applications démarrent plus vite, la mémoire arrive moins vite à saturation, la 3D est plus fluide…
Personnellement en revanche quel que soit l'OS, les services d’indexation mettent une plombe à démarrer, et c'est vrai qu'il faut attendre assez longtemps qu'ils aient tout scanné, au début… J'ai installé Alfred l'autre jour (après t'en avoir parlé, je me suis dit que je pourrai aussi l'essayer, me^me n'étant pas grand fan de ce genre d'outil) et y'a pas photo pour lancer une Application… Ça trouve plus « justement » et bien plus rapidement que spotlight l'application à lancer, en fait…

Brunni (./445) :
Ok, jamais vu. Bah j'imagine que l'indexation s'est bien faite alors, surtout que je lui ai laissé le temps... par contre ça n'explique pas que mds ait besoin de parcourir toutes les partitions au démarrage non?
GC, Godzil et les autres, c'est normal qu'il fasse ça? J'ai pas vraiment les moyens de réinstaller pour m'en assurer...

C'est pas normal qu'il décrete que le disque a trop changé avant que le service ai été remis en marche... Normalement une fois le scan préliminaires terminé, il y a un mecanisme (fsevent) qui lui permet (ainsi qu'a TimeMachine) de savoir ce qui est changé/supprimé/ajouté en temps reel, donc il a la liste des fichiers a indexer.

Ou alors tu as des trucs au démarrage qui créé une chié de fichier qui sont indexé, mais ce n'est pas vraiment normal

Ca remarche \o/ J'ai fait plein de trucs donc je ne peux pas donner la solution exacte, mais:
- J'ai désactivé et supprimé l'index (# mdutil -i -a off; rm -rf ./Spotlight*) puis réactivé juste pour ma partition (# mdutil -i on /)
- Ca n'a pas eu d'effet, alors j'ai utilisé Spotless pour effacer tous les fichiers et reconstruire l'index:

Le service d'indexation a travaillé pendant environ 15 minutes, durant lesquelles il n'a pas accédé à ma partition Windows. Après trois heures j'ai rebooté et... toujours pareil. Après j'ai rajouté des répertoires dans les préférences de Spotlight en lui disant de ne pas chercher là-dedans, et il a recommencé à travailler comme un malade. Contre toute logique, l'index a augmenté de taille (200 Meg -> 320) et depuis plus de souci. Je croise les doigts...

Godzil (./447) :
C'est pas normal qu'il décrete que le disque a trop changé avant que le service ai été remis en marche... Normalement une fois le scan préliminaires terminé, il y a un mecanisme (fsevent) qui lui permet (ainsi qu'a TimeMachine) de savoir ce qui est changé/supprimé/ajouté en temps reel, donc il a la liste des fichiers a indexer.

En fait je pensais que ça pourrait être normal, parce que naïvement il semble logique de devoir parcourir le système de fichiers pour vérifier qu'il n'a pas été modifié en dehors de l'OS

Trop laid