Posté par zeiram .
En réponse à la dépêche Faille SSH.
Évalué à 4.
La lecture du rapport de Rapid7 (les découvreurs de la faille) indique que la version 0.53b (la dernière en date) de PuTTY n'est pas vulnérable. D'ailleurs, cette version est sortie pour corriger quelques problèmes de sécurité. Et elle date d'il y a quand même un mois déjà.
Conclusion : sous Windows, on peut très bien continuer à travailler avec PuTTY (contrairement à ce que laisse supposer le rapport du CERT).
Il y a toute une série de bugs dans Bugzilla liés aux profils itinérants. Presque (?) tous sont du niveau de la demande d'amélioration (RFE, request for enhancement), et il y a même une entreprise (Beonex) qui s'est proposée pour financer cet ajout de fonctionnalité. Donc, cela risque bien d'apparaître un jour... Le tout est d'être patient (la proposition de financement ne date que du mois de juin de cette année).
Je crois que l'intérêt principal de cette nouvelle tient dans le fait que le système de répartition de charge est maintenant directement intégré dans PF. Ainsi, comme avec ALTQ, il n'y a plus qu'un seul fichier de configuration pour gérer tout cela. Donc administration simplifiée.
Non, il reformule son texte pour que l'url apparaisse à un autre endroit dans le texte, il la met en note de bas de page, il diminue la taille de la police, il s'occupe lui-même de couper l'url à un endroit qui soit propice, etc... Il existe un grand nombre de possibilités, et même des packages pour automatiser les coupures des urls. Mon autre message présente d'ailleurs un package proposant cela.
Et s'il écrit en gallois (ou autre langue à longs mots) et qu'il veut utiliser un mot de 80 caractères, il s'auto-censure ?
Pour ce qui est du gallois ou d'autres langues utilisant de long mots, ce n'est pas un problème. Si elles s'écrivent, il existe des règles permettant d'effectuer des césures correctes. Par conséquent, (La)TeX coupera très bien les mots quand ils approchent de la marge (à condition de lui avoir charger les règles qui correspondent, ce qui se fait très aisément).
Bon, d'après le Merriam-Webster en ligne, le terme "cassette" (ou "casette", au choix) a fait son apparition dans la langue anglaise en 1793. Donc (je crois) bien avant que Philips invente la cassette audio ;-)
D'ailleurs, du point de vue de l'étymologie, le terme anglais vient du français, qui vient du vieux français, qui vient de l'ancien nordique (c'est déjà quoi le terme correcte pour les vieilles langues nordiques ?)
La raison de ce choix tient à plusieurs facteurs :
- les règles de coupures ne peuvent pas être les mêmes dans une url et dans le corps d'un texte ;
- une lecture aisée d'un document tient beaucoup à un espace inter-mots quasi constant ;
- lorsque LaTeX estime ne pas pouvoir couper de manière correcte, il faut que l'auteur remanie son document.
Les règles de césure de TeX privilégient le corps du texte (n'oublions pas qu'à l'époque de la création de TeX, le web n'existait pas encore) et TeX ne sait donc pas comment couper une url (et ne le saura jamais de lui-même puisque Knuth a décidé de ne plus améliorer TeX). Par conséquent, quel meilleur moyen que de laisser dépasser le texte dans la marge (quitte à ce qu'il sorte de la page) afin que l'auteur remarque rapidement, lors d'un relecture, qu'il lui faut remanier son texte ?
(La)TeX nous permet d'écire des documents agréables à l'oeil, ainsi qu'une certaine facilité dans l'édition WYSIWYM (What you see is what you mean). Toutefois, il ne faut jamais oublier que la rédaction d'un texte passe par plusieurs relectures et corrections. Des erreurs telles que ces urls dépasant dans la marge ne devraient pas exister si l'auteur avait simplement pris la peine de faire une relecture...
N'oublions pas que le but premier de TeX est l'écriture de livres avec une (relativement) haute qualité typographique. Il ne fait aucune concession sur les règles typographiques pour faciliter la vie des auteurs, donc il n'acceptera jamais des lignes ayant quatre mots sur la largeur de la page afin de passer une url complètement à la ligne suivante (comme le fait un certain logiciel de Microsoft). C'est absolument incorrect d'un point de vue typographique et c'est à l'auteur de corriger cela...
Une autre solution (qui aurait pu sans problème s'appliquer ici) est l'utilisation du package LaTeX url. C'est un package qui permet d'effectuer des passages à la ligne dans une url en respectant plusieurs règles plutôt bien pensées (par exemple, pas de passage à la ligne après un caractère '-' et préférer la coupure après les caractères '/'). De plus, l'utilisation de ce package de manière combinée avec le package hyperref permet "d'activer" les liens lorsque l'on fait du PDF. Seul bémol du package url, il n'est pas très connu, ce qui fait que peu de gens l'utilisent et cela donne des horreurs telles que celles de la page 5 du document.
Et lorsque l'on discute avec des typographes, il est vrai qu'ils vont soit vous recommander de restructurer votre document afin d'éviter que l'url soit en fin de ligne (après avoir fait d'éventuels passages à la ligne dans l'url) ou alors (solution que l'on voit de plus en plus et qui est à mon avis la plus esthétique) donner un texte explicatif pour l'url dans le corps du texte et l'url elle-même en note de bas de page. Avantages de la solution des notes de bas de page : la lecture du corps du texte est plus aisée (car ce n'est pas très agréable de lire tout d'un coup une url dans un alinéa) et l'url elle-même possède toute la largeur de la page pour s'afficher.
> pour deposer un brevet tu dois etre le premier si quelqu'un peut prouver qu'il a une anteriorité, le brevet est caduque
L'idiotie est de devoir prouver cette anteriorite a posteriori. Les offices de brevet n'ont pas le temps/l'argent/les capacités (biffer ce qui ne convient pas) pour effectuer les recherches d'art antérieur avant d'octroyer les brevets. (Pour preuve, l'office des brevets Suisse n'a des experts que pour le domaine de l'horlogerie et accepte les brevets des autres domaines sans aucune recherche, ou prenons encore l'exemple de l'office des brevets australiens qui a accepté un brevet portant sur la roue.)
Donc, le seul moyen d'invalider un brevet, même avec preuves d'art antérieur, est par un procès ; ce qui coûte de l'argent aux deux parties impliquées durant le procès. Or, puisque généralement ce sont souvent des grosses compagnies qui ont les brevets les plus stupides (BT qui détient un brevet sur le lien hypertexte, Amazon et son brevet "One-Click", ...), ils peuvent se permettre de faire durer les procès pendant que le petit plaignant perd de l'argent.
C'est une des raisons qui font que je suis absolument contre l'apparition des brevets dans le domaine du logiciel. (Je suis pour les brevets dans le principe, mais l'application actuelle fait que le système est devenu tellement foireux qu'il n'est plus utilisable et qu'il n'a plus aucun rapport avec les idées premières des brevets.)
> De plus, il date de quand ce benchmarck?
Facile, il suffit de lire les dates auxquelles les images de résultats ont été générées : la plus ancienne (comparaison Empress et MySQL) date du 26 juin 1998 et l'image la plus récente (comparaison PostgreSQL et MySQL) date du 14 juin 2001.
Donc ce benchmark n'est plus tellement d'actualité... À se demander pourquoi en faire une nouvelle ici.
N'oublions pas que, bien avant d'avoir été récupéré par une marque de fast food, le "Jack In The Box" est un jouet pour enfant. Vous en avez d'ailleurs certainement tous déjà vus dans de vieux dessins animés américains. Il s'agit de ce jouet qui se présente comme une boîte avec une manivelle sur un des côtés. Lorsque l'on remonte la manivelle, une musique se fait entendre, puis brutalement une marionnette surgit du dessus de la boîte. Cela vous rappelle des souvenirs ?
Donc, pour en faire une traduction a peu près correcte, il suffirait de jouer sur le nom en français de ce jouet... que je ne connais malheureusement pas.
K-Meleon n'est pas à "oublier." En effet, bien que cela fasse bientôt un an que l'on attend tous la version 0.7, les développeurs sont toujours actifs et proposent régulièrement une version alpha sur la liste des développeurs.
Ce qui a longtemps freiné la sortie du nouveau K-Meleon, ce sont plusieurs bogues bloquantes au niveau de Mozilla Embedded (téléchargement longtemps non fonctionnel, accès impossible à certains sites SSL, ...) Ces bogues ont finalement été corrigées (bien qu'il semble que celle liée à SSL vienne de réapparaitre) et pleins de nouvelles fonctionnalités demandées par les utilisateurs ont été ajoutées (support des "onglets," support des signets au format d'Opera, ...)
Donc le petit chaméléon se porte bien, même si sa croissance ne se fait plus au grand jour. (Rappel : les versions alpha ne sont disponibles qu'aux abonnés de la mailing-liste développeur car beaucoup trop de monde téléchargeait ces versions alpha et avaient les mêmes attentes que s'il s'agissait d'une version définitive.)
PostgreSQL est disponible pour Windows. Peut-être pas sous la forme d'un port réellement natif (je ne sais pas, je n'ai pas vérifié) mais en tout cas il existe sous forme de package pour Cygwin.
Non, effectivement cette annonce n'a aucune valeur juridique. Toutefois, il s'agit d'un travail fait par des experts indépendants qui montre que les techniques protégées par ce brevet étaient déjà connues et utilisées par les scientifiques lorsque ce brevet a été accordé. Par conséquent, le brevet n'aurait pas dû être accordé (puisqu'il couvrait quelque chose de connu et non pas une véritable innovation technologique).
Si procès il y a, les études de ce genre font partie des éléments de base pour pouvoir invalider le brevet sur la base de l'art antérieur ("prior art" en anglais).
Cette étude n'a donc bel et bien aucune valeur juridique, mais c'est une pierre très importante dans la procédure juridique qui pourrait invalider ce brevet.
> Par contre j'ai remarqué (il y a quelques années) que les document fait a partir de Latex mettait souvent les images en fin de chapitre: beurk!
J'imagine que cela doit etre plus simple comme cela avec Latex ou y-a-t-il une autre explication?
Il y a une autre explication. Si LaTeX place toutes les images en fin de chapitre, cela peut être dû à deux raisons : 1) c'est le choix du rédacteur du document ; 2) c'est qu'il y a une image que LaTeX n'arrive pas à placer pour une raison quelconque (image trop grande par exemple).
Dans le premier cas, LaTeX n'y peut rien. Par contre, dans le deuxième cas, toutes les images suivant l'image qui pose problème se retrouvent alors en fin de chapitre car LaTeX impose que les images apparaissent dans le même ordre que celui dans lequel elles sont déclarées. Dans ce cas-là, le rédacteur du document se doit en principe de comprendre pourquoi l'image qui pose problème ne peut pas être mise là où il souhaite et corriger le problème. Ce n'est donc pas parce que c'est "plus simple comme cela".
Il est vrai que l'algorithme de placement des flottants (images, tableaux, ...) en LaTeX est améliorable. Heureusement, les concepteurs de LaTeX en sont conscients et planchent sérieusement sur le problème pour LaTeX 3.
Le premier article met en avant les principes de micro-typographie utilisés par pdfTeX pour obtenir un gris de page constant (9 pages avec trois pages d'exemples). À noter que cet article ne parle que des différences entre pdfTeX et TeX, donc l'algorithme de coupures est de toutes façons par paragraphe.
Le deuxième article fait une comparaison entre Quark XPress et hz. Quark XPress utilise un algorithme de coupures par ligne, alors que hz utilise un algorithme de coupures par paragraphe (37 pages, avec des comparaisons graphiques entre les deux rendus).
Ces deux articles sont tirés des cahiers Gutenberg, qui est la publication officielle du GUT (Groupe des Utilisateurs de TeX).
Bonne lecture (et j'espère que cette fois-ci la preuve sera faite de manière "quantitative", puisque c'est ce que souhaitait sbi).
La raison qui fait que (La)TeX offre une meilleure gestion typographique des textes tient au fait simple (à énoncer) que TeX gère un paragraphe complet pour la gestion des césures de mots et des sauts de page, alors que tous les autres logiciels (à quelques exceptions près) ne gèrent cela en ne considérant que une ou deux lignes à la fois. TeX, ayant une connaissance complète du paragraphe avant de s'attaquer aux coupures de lignes, de mots et de pages, peut dont gérer l'espace inter-mots de manière beaucoup plus fine que les autres logiciels.
Petite note : l'idéal typographique dans un texte est d'avoir absolument partout le même espace inter-mots (afin de rendre la lecture plus aisée). Étant donné que cet idéal est impossible à atteindre en ayant un texte justifié, on cherche alors en tout les cas à éviter les "rivières" (ces suites d'espaces dans un paragraphe qui sont quasiment adjacents verticalement dans un texte et qui donne l'impression d'avoir une rivière qui coule à travers le texte) et à avoir des marges le plus rectilignes possibles. Bien entendu, avec une gestion par lignes, il est impossible de gérer convenablement les rivières.
Pour régler ce dernier point, certaines personnes s'intéressent alors à la micro-typographie. Certaines règles de micro-typographie font, par exemple, ressortir légèrement les caractères ayant peu d'encre du côté de la marge dans la marge afin de donner l'illusion optique d'une marge parfaitement rectiligne. pdfTeX intègre magnifiquement bien ces éléments de micro-typographie (c'était d'ailleurs le but de la thèse de doctorat de Han Thé-Than (je ne suis pas sûr de l'avoir écrit correctement, désolé)).
Quant aux "quelques exceptions" que je mentionne précédemment, il y en a deux : Adobe InDesign (qui a complètement repompé l'algorithme de gestion des coupures directement de TeX et y a apporté quelques améliorations) et hz (système typographique imaginé par Hermann Zapf, qui semble n'avoir jamais connu de réelle distribution).
Quant à avoir un document PDF qui montre les différences entre un algorithme de gestion par paragraphe et un algorithme de gestion par lignes, je me souviens d'avoir lu un article mettant cela en évidence, mais je ne me souviens plus exactement de la référence. L'article en question montrait une économie de 5 à 10% de papier sur un texte en utilisant un algorithme par paragraphe. Je vais donc me mettre en chasse et posterai la référence ici dès que je l'aurai retrouvée.
Toutefois, j'espère que mes explications sur ces différents algorithmes auront éclairé un peu cette discussion . Et qu'elles apporteront un peu d'eau au moulin de la preuve que (La)TeX est mieux que Word et consorts. Et pour une fois, je suis resté dans le sujet :-)
> Quand à ce qui est de latex par rapport à office, je me demande si tu as déjà essayé de faire rapidement un fax en latex... Latex est plutôt destiné à l'impression de docs techniques.
Oui, très facile à faire un fax en LaTeX. Il suffit d'utiliser la classe lettre de Denis Megevand et tout les champs sont placés correctement, il y a différentes mises en pages possibles, ... Sauf erreur, elle est disponible depuis quelques mois sur CTAN, bien qu'elle existe depuis plusieurs années.
Grâce à la classe lettre, je trouve maintenant beaucoup plus facile et rapide d'écrire mes fax et lettres sous LaTeX que sous Office. Et en plus, mes documents sont typographiquement nettement plus beaux ainsi.
Effectivement, la doc de valgrind annonce un ralentissement de 25 à 50 fois de l'application. Mais bon, étant donné tout ce que valgrind fait "par derrière" l'application, c'est un peu normal.
Quant à la liste des exclusions pour les librairies externes (lic, libX11, ...), elle est générée par le script configure. Donc, si ce script est bien fait, la liste s'adaptera automatiquement au système de l'utilisateur (puisque configure peut connaître assez précisément les libs de la machine).
Note : tout cela est tiré de la doc, je n'ai pas encore testé.
C'est gentil de dire qu'il est disponible en ligne sans en donner l'URL... Donc, pour tous les flemmards, voici l'adresse où trouver le Handbook Of Applied Cryptography : http://www.cacr.math.uwaterloo.ca/hac/(...)
Bon, puisque personne ne l'a fait et que je viens de retrouver l'information, je vais me répondre à moi-même (car je n'aime pas laisser des questions en suspens).
Je ne me souviens malheureusement plus quel est le facteur de correspondance sur la longueur des clés pour les deux types d'algorithme afin d'avoir le même niveau de sécurité. Peut-être quelqu'un d'autre a-t-il cela sous la main ?
Dans le hors-série numéro 36 de Pour la Science (date : juillet/octobre 2002), consacré à la cryptographie, il est indiqué en page 34 qu'il faut 10^27 MIPS.an[1] pour casser une clé symétrique de 128 bits par recherche exhaustive et "seulement" 7x10^19 MIPS.an pour casser une clé publique RSA de 2048 bits par factorisation. D'après la loi de Moore, ils estiment une date limite de résistance de ces clés à environ l'an 2100 pour les clés symétriques de 128 bits et environ l'an 2080 pour les clés RSA de 2048 bits (3x10^9 pour les clés à 1024 bits, cassable en environ l'an 2030).
Par contre, les clés symétriques de 256 bits (respectivement 4096 bits pour le RSA) resteront "à jamais" incassable car toute l'énergie du soleil ne suffirait pas à effectuer le nombre nécessaire d'opérations en supposant qu'une opération ne demande pas plus d'énergie que le changement d'orbite d'un électron autour d'un atome. Bien entendu, le terme "à jamais" est soumis à la condition qu'il n'y ait pas une découverte scientifique majeure qui change radicalement notre méthode de recherche de ces clés.
Conclusion : une "bonne" clé symétrique à 128 bits est encore plus sure qu'une clé publique à 2048 bits... donc l'utilisation de "seulement" 128 bits pour le chiffrage de "l'e-commerce" n'est pas du tout problématique.
Bonne journée.
Zeiram
[1] 1 MIPS.an correspond à 2^45 opérations élémentaires.
Sur cette même page concernant leurs licenses, ils disent qu'ils vont les soumettre à l'Open Source Initiative afin de les faire certifier. Donc il semblerait qu'ils veulent vraiment tout mettre en oeuvre pour faire les choses correctement.
Par rapport à d'autres commentaires postés ici, il faut noter que sur la page d'accueil de Helix Community, ils annoncent quels sont les composants qu'ils vont ouvrir et à quelles dates : résultat, tous les composants seront ouverts (encodeur et serveur dès le 31 décembre 2002 et le client 90 jours après l'annonce du 22 juillet 2002).
Donc pour une fois qu'une compagnie habituée à faire du proprio semble bien vouloir faire les choses correctement pour ouvrir ses sources, documentez-vous un peu avant de la descendre en flammes.
Tout à fait d'accord avec toi. J'ai lu une bonne partie du brevet en question (qui est disponible à l'adresse http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITO(...) si cela vous intéresse) et, dans ce que j'ai lu, ils n'y parlent que de transmission d'images. Même, il y est indiqué que l'algorithme de compression se base sur des différences entre images successives et est prévu pour de la compression vidéo. Donc, il me semble que ce brevet devrait plus inquiéter l'algorithme MPEG que le JPEG. Toutefois, le communiqué de presse de Forgent (disponible ici : http://www.corporate-ir.net/ireye/ir_site.zhtml?ticker=forg&scr(...) ) cible bel et bien l'algorithme JPEG. Je trouve donc la situation plutôt bizarre.
À noter également, ce brevet à été attribué en 1986 déjà, toutefois Forgent n'a jamais cherché à faire valoir ses droits jusqu'à maintenant... Pensez-vous que cela soit dû à la faible performance de leurs actions en bourse actuellement ? ;-) Ou au fait que leur brevet ne sera bientôt plus valide (durée de validité d'un brevet : 17 ans depuis qu'il a été accordé selon l'ancienne loi (donc fin de validité en 1987+17=2004), 20 ans depuis le dépôt de la demande selon la nouvelle loi (donc fin de validité en 1986+20=2006)).
En ce qui concerne les formats d'image "à perte", il existe aussi le JNG (créé par le même groupe que le PNG). Il ne fait toutefois qu'encapsuler un flux JPG dans une structure PNG. Je ne sais donc pas du tout où situer le JNG par rapport au brevet dont on discute ici. (La spécification du JNG est disponible à : http://www.libpng.org/pub/mng/spec/jng.html(...) .)
Déni standard : je ne suis pas un avocat spécialiste des brevets, donc je peux très bien me tromper dans l'interprétation du jargon volontairement flou utilisé dans les demandes de brevet (toutefois je m'intéresse depuis quelques années au sujet et je pense donc que mon interprétation est assez correcte) ; je n'ai pas lu l'intégralité de leur demande de brevet (c'est soulant à lire), il peut donc y avoir des passages qui se rapportent plus au JPG qui m'aient échappé.
De plus, il semble (à ce que j'en ai lu sur les newsgroups d'Eclipse) que la version 1.4.0 (ou 1.4.0_1) de la JVM de Sun ont quelques problèmes avec le déverminage. Particulièrement en ce qui concerne les opérations de pas à pas (step in, step out, ...). Le conseil donné par les développeurs d'Eclipse est d'utiliser plutôt la version 1.4.1Beta du JDK qui corrige également ces problèmes-là.
Remarque : je n'ai pas vérifié par moi-même ce que j'énonce ici, étant très content du JDK 1.3.1 pour l'instant. Toutefois, il y a eu beaucoup de messages se plaignant du déverminage avec le JDK 1.4.0 dans les newsgroups d'Eclipse.
Zeiram
PS: Je ne peux que vous conseiller d'essayer Eclipse. Je l'ai découvert il y a un mois et je n'arrive déjà plus à m'en passer... alors que j'étais très content de Vim jusqu'alors.
[^] # Re: Faille SSH
Posté par zeiram . En réponse à la dépêche Faille SSH. Évalué à 4.
Conclusion : sous Windows, on peut très bien continuer à travailler avec PuTTY (contrairement à ce que laisse supposer le rapport du CERT).
[^] # Re: Profils Itinérants...
Posté par zeiram . En réponse à la dépêche Mozilla 1.2 - Procurez le vous pendant qu'il est chaud !. Évalué à 4.
Quelques liens sur bugzilla associés au problème :
http://bugzilla.mozilla.org/show_bug.cgi?id=17048(...) (ajout des profils itinérants)
http://bugzilla.mozilla.org/show_bug.cgi?id=124026(...) (financement par Beonex, méta-bug pour les profils itinérants)
[^] # Re: PF supporte la répartition de charge IP
Posté par zeiram . En réponse à la dépêche PF supporte la répartition de charge IP. Évalué à 7.
[^] # Re: Problème dans le document PDF
Posté par zeiram . En réponse à la dépêche Synthèse sur les brevets logiciels. Évalué à 2.
Non, il reformule son texte pour que l'url apparaisse à un autre endroit dans le texte, il la met en note de bas de page, il diminue la taille de la police, il s'occupe lui-même de couper l'url à un endroit qui soit propice, etc... Il existe un grand nombre de possibilités, et même des packages pour automatiser les coupures des urls. Mon autre message présente d'ailleurs un package proposant cela.
Et s'il écrit en gallois (ou autre langue à longs mots) et qu'il veut utiliser un mot de 80 caractères, il s'auto-censure ?
Pour ce qui est du gallois ou d'autres langues utilisant de long mots, ce n'est pas un problème. Si elles s'écrivent, il existe des règles permettant d'effectuer des césures correctes. Par conséquent, (La)TeX coupera très bien les mots quand ils approchent de la marge (à condition de lui avoir charger les règles qui correspondent, ce qui se fait très aisément).
[^] # Re: Recyclage de VCR en convi desktop PC
Posté par zeiram . En réponse à la dépêche Recyclage de VCR en convi desktop PC. Évalué à 1.
D'ailleurs, du point de vue de l'étymologie, le terme anglais vient du français, qui vient du vieux français, qui vient de l'ancien nordique (c'est déjà quoi le terme correcte pour les vieilles langues nordiques ?)
Si vous souhaitez plus d'infos : http://www.m-w.com/cgi-bin/dictionary?va=cassette(...)
[^] # Re: Problème dans le document PDF
Posté par zeiram . En réponse à la dépêche Synthèse sur les brevets logiciels. Évalué à 2.
- les règles de coupures ne peuvent pas être les mêmes dans une url et dans le corps d'un texte ;
- une lecture aisée d'un document tient beaucoup à un espace inter-mots quasi constant ;
- lorsque LaTeX estime ne pas pouvoir couper de manière correcte, il faut que l'auteur remanie son document.
Les règles de césure de TeX privilégient le corps du texte (n'oublions pas qu'à l'époque de la création de TeX, le web n'existait pas encore) et TeX ne sait donc pas comment couper une url (et ne le saura jamais de lui-même puisque Knuth a décidé de ne plus améliorer TeX). Par conséquent, quel meilleur moyen que de laisser dépasser le texte dans la marge (quitte à ce qu'il sorte de la page) afin que l'auteur remarque rapidement, lors d'un relecture, qu'il lui faut remanier son texte ?
(La)TeX nous permet d'écire des documents agréables à l'oeil, ainsi qu'une certaine facilité dans l'édition WYSIWYM (What you see is what you mean). Toutefois, il ne faut jamais oublier que la rédaction d'un texte passe par plusieurs relectures et corrections. Des erreurs telles que ces urls dépasant dans la marge ne devraient pas exister si l'auteur avait simplement pris la peine de faire une relecture...
N'oublions pas que le but premier de TeX est l'écriture de livres avec une (relativement) haute qualité typographique. Il ne fait aucune concession sur les règles typographiques pour faciliter la vie des auteurs, donc il n'acceptera jamais des lignes ayant quatre mots sur la largeur de la page afin de passer une url complètement à la ligne suivante (comme le fait un certain logiciel de Microsoft). C'est absolument incorrect d'un point de vue typographique et c'est à l'auteur de corriger cela...
[^] # Re: Problème dans le document PDF
Posté par zeiram . En réponse à la dépêche Synthèse sur les brevets logiciels. Évalué à 3.
Et lorsque l'on discute avec des typographes, il est vrai qu'ils vont soit vous recommander de restructurer votre document afin d'éviter que l'url soit en fin de ligne (après avoir fait d'éventuels passages à la ligne dans l'url) ou alors (solution que l'on voit de plus en plus et qui est à mon avis la plus esthétique) donner un texte explicatif pour l'url dans le corps du texte et l'url elle-même en note de bas de page. Avantages de la solution des notes de bas de page : la lecture du corps du texte est plus aisée (car ce n'est pas très agréable de lire tout d'un coup une url dans un alinéa) et l'url elle-même possède toute la largeur de la page pour s'afficher.
[^] # Re: NON !
Posté par zeiram . En réponse à la dépêche "Faut-il breveter les logiciels". Évalué à 4.
[^] # Re: Un bench MySQL contre tous
Posté par zeiram . En réponse à la dépêche Un bench MySQL contre tous. Évalué à 5.
Facile, il suffit de lire les dates auxquelles les images de résultats ont été générées : la plus ancienne (comparaison Empress et MySQL) date du 26 juin 1998 et l'image la plus récente (comparaison PostgreSQL et MySQL) date du 14 juin 2001.
Donc ce benchmark n'est plus tellement d'actualité... À se demander pourquoi en faire une nouvelle ici.
[^] # Re: Austin Powers dans Goldmember
Posté par zeiram . En réponse à la dépêche Austin Powers dans Goldmember. Évalué à 1.
Donc, pour en faire une traduction a peu près correcte, il suffirait de jouer sur le nom en français de ce jouet... que je ne connais malheureusement pas.
[^] # Re: Champagne
Posté par zeiram . En réponse à la dépêche LinuxFr cherche nouvel hébergeur, et plus si affinités.... Évalué à 1.
Ce qui a longtemps freiné la sortie du nouveau K-Meleon, ce sont plusieurs bogues bloquantes au niveau de Mozilla Embedded (téléchargement longtemps non fonctionnel, accès impossible à certains sites SSL, ...) Ces bogues ont finalement été corrigées (bien qu'il semble que celle liée à SSL vienne de réapparaitre) et pleins de nouvelles fonctionnalités demandées par les utilisateurs ont été ajoutées (support des "onglets," support des signets au format d'Opera, ...)
Donc le petit chaméléon se porte bien, même si sa croissance ne se fait plus au grand jour. (Rappel : les versions alpha ne sont disponibles qu'aux abonnés de la mailing-liste développeur car beaucoup trop de monde téléchargeait ces versions alpha et avaient les mêmes attentes que s'il s'agissait d'une version définitive.)
[^] # Re: Manque qq trucs mais il y a déjà beaucoup !
Posté par zeiram . En réponse à la dépêche GNUWin II est disponible. Évalué à 5.
Notez bien qu'il y a l'installeur de Cygwin qui est inclus. Dans une installation par défaut de Cygwin, on y trouve justement Perl et wget.
[^] # Re: Humm
Posté par zeiram . En réponse à la dépêche MySQL: une bonne et une mauvaise nouvelle.. Évalué à 10.
[^] # Re: Mode ?
Posté par zeiram . En réponse à la dépêche Brevet sur le JPEG : Non !. Évalué à 10.
Si procès il y a, les études de ce genre font partie des éléments de base pour pouvoir invalider le brevet sur la base de l'art antérieur ("prior art" en anglais).
Cette étude n'a donc bel et bien aucune valeur juridique, mais c'est une pierre très importante dans la procédure juridique qui pourrait invalider ce brevet.
[^] # Re: Algorithmes de mise en forme comparés
Posté par zeiram . En réponse à la dépêche Fin de la disponibilité des fontes true-type Microsoft. Évalué à 1.
Il y a une autre explication. Si LaTeX place toutes les images en fin de chapitre, cela peut être dû à deux raisons : 1) c'est le choix du rédacteur du document ; 2) c'est qu'il y a une image que LaTeX n'arrive pas à placer pour une raison quelconque (image trop grande par exemple).
Dans le premier cas, LaTeX n'y peut rien. Par contre, dans le deuxième cas, toutes les images suivant l'image qui pose problème se retrouvent alors en fin de chapitre car LaTeX impose que les images apparaissent dans le même ordre que celui dans lequel elles sont déclarées. Dans ce cas-là, le rédacteur du document se doit en principe de comprendre pourquoi l'image qui pose problème ne peut pas être mise là où il souhaite et corriger le problème. Ce n'est donc pas parce que c'est "plus simple comme cela".
Il est vrai que l'algorithme de placement des flottants (images, tableaux, ...) en LaTeX est améliorable. Heureusement, les concepteurs de LaTeX en sont conscients et planchent sérieusement sur le problème pour LaTeX 3.
[^] # Re: Algorithmes de mise en forme comparés
Posté par zeiram . En réponse à la dépêche Fin de la disponibilité des fontes true-type Microsoft. Évalué à 7.
Améliorer la typographie de TeX par Han The-Thanh (cette fois je suis sur d'avoir orthographié correctement son nom, à l'exception des accents que je ne peux de toutes façons pas rendre en iso-latin1) à l'adresse :
http://www.gutenberg.eu.org/pub/GUTenberg/publicationsPDF/32-thanh.(...)
Le programme hz : micro-typographie pour photocomposition de haut niveau par Peter Karow à l'adresse : http://www.gutenberg.eu.org/pub/GUTenberg/publicationsPDF/27-karow.(...)
Le premier article met en avant les principes de micro-typographie utilisés par pdfTeX pour obtenir un gris de page constant (9 pages avec trois pages d'exemples). À noter que cet article ne parle que des différences entre pdfTeX et TeX, donc l'algorithme de coupures est de toutes façons par paragraphe.
Le deuxième article fait une comparaison entre Quark XPress et hz. Quark XPress utilise un algorithme de coupures par ligne, alors que hz utilise un algorithme de coupures par paragraphe (37 pages, avec des comparaisons graphiques entre les deux rendus).
Ces deux articles sont tirés des cahiers Gutenberg, qui est la publication officielle du GUT (Groupe des Utilisateurs de TeX).
Bonne lecture (et j'espère que cette fois-ci la preuve sera faite de manière "quantitative", puisque c'est ce que souhaitait sbi).
[^] # Re: Algorithmes de mise en forme comparés
Posté par zeiram . En réponse à la dépêche Fin de la disponibilité des fontes true-type Microsoft. Évalué à 9.
Petite note : l'idéal typographique dans un texte est d'avoir absolument partout le même espace inter-mots (afin de rendre la lecture plus aisée). Étant donné que cet idéal est impossible à atteindre en ayant un texte justifié, on cherche alors en tout les cas à éviter les "rivières" (ces suites d'espaces dans un paragraphe qui sont quasiment adjacents verticalement dans un texte et qui donne l'impression d'avoir une rivière qui coule à travers le texte) et à avoir des marges le plus rectilignes possibles. Bien entendu, avec une gestion par lignes, il est impossible de gérer convenablement les rivières.
Pour régler ce dernier point, certaines personnes s'intéressent alors à la micro-typographie. Certaines règles de micro-typographie font, par exemple, ressortir légèrement les caractères ayant peu d'encre du côté de la marge dans la marge afin de donner l'illusion optique d'une marge parfaitement rectiligne. pdfTeX intègre magnifiquement bien ces éléments de micro-typographie (c'était d'ailleurs le but de la thèse de doctorat de Han Thé-Than (je ne suis pas sûr de l'avoir écrit correctement, désolé)).
Quant aux "quelques exceptions" que je mentionne précédemment, il y en a deux : Adobe InDesign (qui a complètement repompé l'algorithme de gestion des coupures directement de TeX et y a apporté quelques améliorations) et hz (système typographique imaginé par Hermann Zapf, qui semble n'avoir jamais connu de réelle distribution).
Quant à avoir un document PDF qui montre les différences entre un algorithme de gestion par paragraphe et un algorithme de gestion par lignes, je me souviens d'avoir lu un article mettant cela en évidence, mais je ne me souviens plus exactement de la référence. L'article en question montrait une économie de 5 à 10% de papier sur un texte en utilisant un algorithme par paragraphe. Je vais donc me mettre en chasse et posterai la référence ici dès que je l'aurai retrouvée.
Toutefois, j'espère que mes explications sur ces différents algorithmes auront éclairé un peu cette discussion . Et qu'elles apporteront un peu d'eau au moulin de la preuve que (La)TeX est mieux que Word et consorts. Et pour une fois, je suis resté dans le sujet :-)
[^] # Fax sous LaTeX [was: Re: Comprends rien..]
Posté par zeiram . En réponse à la dépêche Fin de la disponibilité des fontes true-type Microsoft. Évalué à 8.
Oui, très facile à faire un fax en LaTeX. Il suffit d'utiliser la classe lettre de Denis Megevand et tout les champs sont placés correctement, il y a différentes mises en pages possibles, ... Sauf erreur, elle est disponible depuis quelques mois sur CTAN, bien qu'elle existe depuis plusieurs années.
Grâce à la classe lettre, je trouve maintenant beaucoup plus facile et rapide d'écrire mes fax et lettres sous LaTeX que sous Office. Et en plus, mes documents sont typographiquement nettement plus beaux ainsi.
[^] # Re: valgrind c Bien
Posté par zeiram . En réponse à la dépêche Valgrind 1.0.0. Évalué à 10.
Quant à la liste des exclusions pour les librairies externes (lic, libX11, ...), elle est générée par le script configure. Donc, si ce script est bien fait, la liste s'adaptera automatiquement au système de l'utilisateur (puisque configure peut connaître assez précisément les libs de la machine).
Note : tout cela est tiré de la doc, je n'ai pas encore testé.
[^] # Re: Autre source
Posté par zeiram . En réponse à la dépêche Hors série « Pour la science » sur la cryptographie. Évalué à 4.
Pffff... faut tout faire soi-même ici ;-)
[^] # Re: j'en ai oublié un - cassage de clés
Posté par zeiram . En réponse à la dépêche Fork d'OpenBSD. Évalué à 1.
Dans le hors-série numéro 36 de Pour la Science (date : juillet/octobre 2002), consacré à la cryptographie, il est indiqué en page 34 qu'il faut 10^27 MIPS.an[1] pour casser une clé symétrique de 128 bits par recherche exhaustive et "seulement" 7x10^19 MIPS.an pour casser une clé publique RSA de 2048 bits par factorisation. D'après la loi de Moore, ils estiment une date limite de résistance de ces clés à environ l'an 2100 pour les clés symétriques de 128 bits et environ l'an 2080 pour les clés RSA de 2048 bits (3x10^9 pour les clés à 1024 bits, cassable en environ l'an 2030).
Par contre, les clés symétriques de 256 bits (respectivement 4096 bits pour le RSA) resteront "à jamais" incassable car toute l'énergie du soleil ne suffirait pas à effectuer le nombre nécessaire d'opérations en supposant qu'une opération ne demande pas plus d'énergie que le changement d'orbite d'un électron autour d'un atome. Bien entendu, le terme "à jamais" est soumis à la condition qu'il n'y ait pas une découverte scientifique majeure qui change radicalement notre méthode de recherche de ces clés.
Conclusion : une "bonne" clé symétrique à 128 bits est encore plus sure qu'une clé publique à 2048 bits... donc l'utilisation de "seulement" 128 bits pour le chiffrage de "l'e-commerce" n'est pas du tout problématique.
Bonne journée.
[1] 1 MIPS.an correspond à 2^45 opérations élémentaires.
[^] # Re: Yo, Champagne !
Posté par zeiram . En réponse à la dépêche Real Networks : plate-forme de streaming ouverte. Évalué à 10.
Sur cette même page concernant leurs licenses, ils disent qu'ils vont les soumettre à l'Open Source Initiative afin de les faire certifier. Donc il semblerait qu'ils veulent vraiment tout mettre en oeuvre pour faire les choses correctement.
Par rapport à d'autres commentaires postés ici, il faut noter que sur la page d'accueil de Helix Community, ils annoncent quels sont les composants qu'ils vont ouvrir et à quelles dates : résultat, tous les composants seront ouverts (encodeur et serveur dès le 31 décembre 2002 et le client 90 jours après l'annonce du 22 juillet 2002).
Donc pour une fois qu'une compagnie habituée à faire du proprio semble bien vouloir faire les choses correctement pour ouvrir ses sources, documentez-vous un peu avant de la descendre en flammes.
[^] # Re: Et un de plus sur google [-1]
Posté par zeiram . En réponse à la dépêche Red Flag déjà abandonné ?. Évalué à 5.
[^] # Re: ====> Moment correcteur orthographique <====
Posté par zeiram . En réponse à la dépêche Apres GIF, le JPEG. Évalué à 8.
À noter également, ce brevet à été attribué en 1986 déjà, toutefois Forgent n'a jamais cherché à faire valoir ses droits jusqu'à maintenant... Pensez-vous que cela soit dû à la faible performance de leurs actions en bourse actuellement ? ;-) Ou au fait que leur brevet ne sera bientôt plus valide (durée de validité d'un brevet : 17 ans depuis qu'il a été accordé selon l'ancienne loi (donc fin de validité en 1987+17=2004), 20 ans depuis le dépôt de la demande selon la nouvelle loi (donc fin de validité en 1986+20=2006)).
En ce qui concerne les formats d'image "à perte", il existe aussi le JNG (créé par le même groupe que le PNG). Il ne fait toutefois qu'encapsuler un flux JPG dans une structure PNG. Je ne sais donc pas du tout où situer le JNG par rapport au brevet dont on discute ici. (La spécification du JNG est disponible à : http://www.libpng.org/pub/mng/spec/jng.html(...) .)
Déni standard : je ne suis pas un avocat spécialiste des brevets, donc je peux très bien me tromper dans l'interprétation du jargon volontairement flou utilisé dans les demandes de brevet (toutefois je m'intéresse depuis quelques années au sujet et je pense donc que mon interprétation est assez correcte) ; je n'ai pas lu l'intégralité de leur demande de brevet (c'est soulant à lire), il peut donc y avoir des passages qui se rapportent plus au JPG qui m'aient échappé.
[^] # Re: Et Netbeans ?
Posté par zeiram . En réponse à la dépêche Eclipse 2.0 est dans les bacs !. Évalué à 8.
Pour télécharger la version 1.4.1 : http://java.sun.com/j2se/1.4.1/download.html(...)
Remarque : je n'ai pas vérifié par moi-même ce que j'énonce ici, étant très content du JDK 1.3.1 pour l'instant. Toutefois, il y a eu beaucoup de messages se plaignant du déverminage avec le JDK 1.4.0 dans les newsgroups d'Eclipse.
PS: Je ne peux que vous conseiller d'essayer Eclipse. Je l'ai découvert il y a un mois et je n'arrive déjà plus à m'en passer... alors que j'étais très content de Vim jusqu'alors.