WinMX: Réglages, configuration et optimisation B)

En consultant mes stats sur eStat, je vois régulièrement des gens qui sont venus sur un de mes blogs suite à une recherche Goggle portant sur "winmx" ainsi que "réglage" "configuration", "optimisation" ou "bande passante". En fait j'avais mentionné WinMX à titre anecdotique pour signifier que contrairement à Morpheus (et également Kazaa je crois) il n'installait pas de spyware. Toutefois, il me parait donc aujourd'hui indispensable de dire un mot sur l'optimisation de la bande passante avec WinMX. D'autant plus que je ne sais pas pour vous, mais en ce qui me concerne je n'ai jamais vu aucune aide ou guide d'utilisation émanant des auteurs du logiciel...

En revanche, il existe des fichiers texte qui circulent sur MX et qui prétendent qu'en entrant des valeurs astronomiques dans vos maximum incomming et outgoing bandwidth vous allez atteindre des records de vitesse de transfert. N'en croyez pas un mot. Les auteurs de ces fichiers espèrent simplement vous faire débrider votre bande passante sortante pour mieux pouvoir se fournir!! Mais ils s'y prennent fort mal!

En effet, en mettant des valeurs maximales au delà de votre bande passante réelle (ou encore en ne spécifiant aucune limite) vous autorisez WinMX a envoyer des paquets au delà de ce que peut absorber votre connexion... un très grand nombre de ces paquets vont donc tout simplement être jetés aux orties par la couche réseau... et WinMX ne s'en rendra compte qu'à l'issue du timeout correspondant à ce paquet... la conséquence est l'inverse du but recherché: une dégaradation de performances. Voilà pour le principe général. Je ne peux pas m'étendre en détails sur les pourquois du comment ici... d'autant plus que la licence d'utilisation de WinMX n'autorise pas à en analyser le fonctionnement!!

Toujours est-il que pour obtenir les performances optimales, vous devez donc fixer les limites à un seuil très légèrement inférieur (disons 15 à 20%) à votre bande passante maximale. Si vous connaissez votre bande passante ça vous simplifiera la vie. Attention aussi au fait que certaines connexions (câble, ADSL...) sont asymétriques (sinon il n'y aurait d'ailleurs pas de A à ADSL) et que les bandes passantes entrante et sortante sont donc différentes.

Si vous ne connaissez pas précisément votre bande passante, procédez par tatonnements: lancez un maximum de downloads et d'uploads pour saturer votre liaison. Ensuite regardez les graphiques de l'onglet bandwidth: regardez jusqu'où ils montent et regardez si la courbe globale est bien plate et écrêtée ou bien si elle est en dents de scie. Encore une fois, ceci n'est valable qui si vous saturez votre bande avec un grand nombre de transferts. En posant une limite à 80% du maximum pour in et out, vous allez obtenir des courbes bien plates. Vous pouvez essayer de monter la limite jusqu'à ce que les dents de scie réaparraissent, vous saurez alors que vous venez de dépasser la limite.

Dernière chose: vous devez absolument régler le incomming et le outgoing de manière conjointe: en effet chaque paquet transmis à besoin d'acquittements dans l'autre sens, donc une saturation d'un sens entraine obligatoirement des perturbations sur l'autre.

Personnellement, sur mon ADSL Tiscali j'avais obtenu les meilleurs résultats avec une limite incomming à 53000 octets par seconde et une limite outgoing à 12500 octets par seconde.

Rappel: échanger des contenus copyrightés à l'aide de WinMX est illégal. Echanger vos propres créations (photos, montages vidéos... à propos de grand prix moto par exemple) est légal. Merci de ne pas utiliser les infos ci-dessus à des fins illégales.

Sans oublier l'imprimabilité ;)

Dans la suite logique de l'accessibilité, il est tout aussi important de veiller à la bonne impression de vos pages... pour tous ceux qui ne sont toujours pas prêts de s'habituer à lire sur écran et ils sont nombreux, comme le rappelle judicieusement pompage.net ce mois ci, explications à l'appui.

Deux petites astuces tout de même pour ceux qui peinent à lire sur écran:

  1. apprenez à régler la fréquence de rafraichissement de votre écran à plus de 60 Hz! Cette valeur par défaut est scandaleusement basse par rapport aux possibilités du matériel actuel. En passant, ne serait-ce qu'à 75 Hz, la diminution du scientillement aura un effet non négligeable sur votre fatigue visuelle.
  2. essayez l'écran plat! De préférence avec une connexion DVI (numérique) plutôt que VGA (analogique) afin de garantir une netteté optimale. là encore, le gain de confort va de pair avec la diminution de fatigue visuelle.

Accessibilité, Enfin!

Le sujet est dans l'air, on en parle sur StandBlog, chez Russell Beattie, plusieurs autres blogs et même le Journal du Net. C'est plutôt une bonne chose que l'on commence à s'en préoccuper un peu dans notre pays, même si nous n'avons pas de lois pour nous y obliger comme aux US... L'intérêt de rendre un site web plus accessible va d'ailleurs bien au delà du fait qu'il devienne plus accessible aux handicapés! En effet, combien de sites, designés par une agence quelconque, vous affichent des pavés de texte écrits en 6 points (ou encore 8 pixels de hauteur), vous forçant à vous rapprocher de votre écran pour pouvoir lire ce qui est écrit? Mais voyez vous... il parait que c'est plus design... Moi ça me rappelle plutôt les conditions générales de ventes imprimées de manière illisible au verso des bons de commande! Messieurs les créatifs, vous n'avez rien compris! Les lecteurs ne peuvent pas passer leurs journées à lire des tous petits caractères... (et pour les conditions de vente, figurez vous que c'est fait exprès! ;)


Il est important également de constater le fait que vous pouvez effectivement lire des petits caractères... mais que celà devient de plus en plus pénible au fur et à mesure que la journée avance et que la fatigue s'accumule... C'est également plus gênant lorsque le texte à lire est long: on ne peut pas lire un white paper en tout petit même si on peut le faire sans problème pour une brêve.


S'ajoutent à celà, les critères purement techniques de résolution d'écran utilisée par le lecteur. Un écran d'ordinateur affiche probablement entre 60 et 120 points par pouce selon la résolution et la taille de l'écran. Par exemple, des caractères de 12 points seront bien plus gros sur un écran 19 pouces configuré en 800*600 que sur un écran de portable de 15 pouces configuré en 1600*1200!


En fait, la bonne taille de caractères dépend donc intimement de la situation de chacun et il semble dès lors extrêmement prétentieux de vouloir déterminer à l'avance la taille dans laquelle l'utilisateur voudra lire un texte.


Les browsers web permettent depuis assez longtemps de changer la taille des caractères... ce qui fût bien agréable pendant une certaine époque... avant que n'apparaissent les feuilles de styles! Celles-ci ont en effet tendance à figer la taille des caractères quelle que soit la taille réglée dans le menu du navigateur. C'est surtout le cas de Internet Explorer (même en version 6) alors que Netscape 7 par exemple, s'affranchit finalement assez bien du problème.


Pourtant, il existe une solution relativement universelle: n'indiquer dans les CSS que des tailles de caractères sous forme de pourcentages! Ils pourront dès lors être redimensionnés à loisir par l'utilisateur.


A ce propos, connaissez vous les raccourcis clavier bien pratiques? Sous Netscape, faites Ctrl + pour augmenter la taille et Ctrl - pour la diminuer. Sous Internet Explorer, maintenez la touche Ctrl pendant que vous tournez la molette de la souris!

Essayez sur cette page, vous verrez!

Traduction des logiciels [Archive 1999]

[Ce post a été déterré de mes archives 1999]


Aujourd'hui j'ai été initié au terrible secret de fabrication de la déplorable médiocrité des traductions de nos logiciels quotidiens! En effet, dans le cadre d'un recrutement de chef de projets, nous avons aujourd'hui reçu un candidat ayant précédemment travaillé dans une SSII de traduction industrielle. Et non des moindres, puisqu'il était en charge de la traduction en français d'un environnement de développement assez connu permettant de réaliser des programmes Windows en disposant "visuellement" des objets et en tapant quelques lignes de Basic... (oui oui on parle bien de la même chose)!


Voici comment il procédait (selon une tradition qui se transmet de collaborateur en successeur depuis la nuit des temps de la localisation): un outil "très astucieux" commence par extraire toutes les chaines de caractères de tous les fichiers source et ressource du projet complet (je parle bien de l'environnement de développement complet!). Il en génère ensuite un fichier Excel dans lequel on retrouve le nom du fichier source, la position, le texte en anglais... reste une colonne vide pour le texte en français! Le gros du travail consiste alors à traduire les chaines de caractères ligne par ligne avant que le "très astucieux" outil ne réintègre ces traductions aux sources!!!


Moi: Mais... et le contexte?
Lui: Comment ça le contexte?

Moi: Oui, une même phrase, ou pire: un mot isolé n'a pas forcément la même traduction selon le contexte!!??
Lui: Oui, mais c'est rare... et dans ce cas, les testeurs nous le signalent lors de la phase de tests.

Moi: Ah? Et les testeurs passent par tous les écrans en comparant l'anglais et le français pour voir si le sens est respecté? Ils provoquent également l'affichage de tous les messages d'erreur?
Lui: Je ne sais pas... je n'ai pas participé aux tests.

Moi: Et vous même, quand vous traduisez, vous vous basez sur votre expérience en programmation?
Lui: Je ne suis pas programmeur!

Moi: Ah? Et ça ne pose pas de problème pour traduire un environnement de développement?
Lui: Vous savez, un logiciel reste un logiciel. D'ailleurs, sur les logiciels bureautiques [du même éditeur] les traducteurs ne sont pas non plus forcément des utilisateurs avancés, mais ce n'est pas un problème. Ce qu'on demande aux traducteurs, c'est de traduire, pas de refaire l'interface!

Moi: Passons à autre chose...


Après cette discussion, j'en suis à me demander comment les logiciels traduits en français arrivent tout de même à séduire certains utilisateurs...


Hum... probablement ceux qui ne parlent pas anglais, ne lisent pas les messages d'erreur par principe et n'ont jamais tenté d'ouvrir les options avancées, voire ne serait-ce que l'aide en ligne!

A quoi sert SSL? [Archive 1998]

[Ce post a été déterré de mes archives 1998]

Exemple concrêt:

  1. Un utilisateur souhaite transmettre son numéro de carte bancaire à un serveur de manière sécurisée.
  2. L'utilisateur doit chiffrer son message (en l'occurence son numéro de carte) grâce à une clé. Et le serveur doit déchiffrer le message grâce à une clé.
  3. Si on utilisait une méthode de chiffrement simple (symétrique), l'utilisateur et le serveur devraient au préalable se mettre d'accord sur une clé de chiffrement/déchriffrement secrête et connue d'eux seuls afin que personne d'autre ne puisse déchiffrer le message.
  4. Cet échange de clé secrête n'est pas possible par Internet, car si on pouvait se transmettre secrêtement une clé, on pourrait directement se transmettre secrêtement le numéro de la carte bancaire. On tourne en rond...
  5. La solution consiste à utiliser une méthode de chiffrement asymétrique: le chiffrement se fait avec une clé et le déchiffrement se fait avec une autre clé. Bien sûr, pour toute clé de chiffrement il n'existe qu'une seule clé de déchiffrement possible. Ces clefs fonctionnent donc exclusivement par paires.
  6. Le serveur définit donc une paire de clefs. Il en garde une secrète (la clef privée). Il en donne une autre à tous ses utilisateurs (la clef publique).
  7. Dès lors, tout utilisateur peut chiffrer son message avec la clef publiquer et l'envoyer en toute confiance au serveur qui sera le seul à pouvoir le déchiffrer car il est le seul à posséder la clef privée, indispensable au chiffrement.

    Note: en réalité, le browser va chiffrer une clef master aléatoire qu'il va envoyer au serveur qui est le seul à pouvoir la déchiffrer avec sa clef privé. Cette clef master est ensuite utilisée pour chiffrer à la fois les messages envoyés au serveur et les messages reçus du serveur. Toutes les informations échangées entre le browser et le serveur sont ainsi cryptées.
  8. Mais ça ne suffit pas. En effet: que se passe-t-il si jamais une personne malveillante diffuse une fausse clef publique? Le message chiffré envoyé par l'utilisateur ne sera plus déchiffrable par la clef privée du serveur. Par contre il sera déchiffré facilement par le pirate qui possède la clef privée correspondant à la fausse clef publique.
  9. Il est donc indispensable que l'utilisateur soit sûr d'utiliser la BONNE clef publique.
  10. Pour être sûr, il dispose d'un certificat émis par une Autorité de certification et qui certifie que la clef est la bonne.
  11. Mais comment être sûr que le certificat n'est pas un faux? Réponse: parce qu'il est signé électroniquement par une aurtorité de certification (AC) connue à l'avance. (Une liste d'AC est préenregistrée 'en dur' dans le browser Web).
  12. La signature électronique fonctionne sur le même principe: l'AC chiffre le certificat avec sa propre clef privée et l'utilisateur déchiffre le certificat avec la clef publique de l'AC. Rappelons qu'il connait cette clef publique à l'avance car les AC et leurs clefs publiques sont préenregistrées dans le browser Web.