boubou a écrit 1384 commentaires

<<le multithread est clairement un gain de performances...>> C'est quand même beaucoup plus subtil que ça. Le surcoût engendré par le scheduling entre les différents threads fait qu'un logiciel de calcul multi-thread est toujours moins performant qu'un logiciel de calcul mono-thread. Par contre, il se trouve que le hard ware PC est en fait une machine parallèle. Par exemple, on peut envoyer des données à la carte son ou en récupérer sur le disque et faire autre chose en même temps. L'avantage du multi-thread est qu'il permet de profiter (même sur une machine mono-processeur) de ce parallelisme. On peut par exemple programmer des entrées/sorties non bloquantes ce qui améliore notablement les performances des logiciels qui en font. Pour un logiciel de calcul pur et dur, le multi-thread ne sert à rien sur un mono-processeur.

Si je te comprends bien, tu trouves normal qu'une police politique espionne des militants politiques (et syndicaux, d'ailleurs) qui n'ont pas enfrein la loi et ceci sans contrôle judiciaire ? Et tu trouves ça tellement normal que tu t'opposes à la diffusion des dossiers aux personnes espionnées ? Bravo.

Quand je parle de log(n), je considère le nombre de chiffres de n. Pour reprendre tes notations, il s'agit donc de log(N), ou encore de n. Donc avec un algorithme de merde on décide si un nombre est composé en racine(N)(log(N))^2.

Premier point :
---------------
J'ai bien l'impression que les notions de NP etc. te posent quelques problèmes...

Commençons donc par le commencement (ça n'a rien à faire sur linuxfr, mais bon). Un problème P est un problème qu'on peut résoudre en temps polynomial, c'est-à-dire en un temps d'exécution qui dépend comme un polynome de la taille des données. Pour une définition formelle, cf http://www.claymath.org/prizeproblems/p_vs_np.pdf(...) (qui est excellent).

Deuxième définition : non-P. Un problème non-P est un problème pour lequel on sait prouver qu'il n'existe pas de résolution en temps polynomial. Il est extrêmement difficile de démontrer qu'un problème est non-P, mais ça a déjà été fait et donc on est bien entendu sûr que P /= non-P (ce qui est évident) et surtout que les deux ensembles ne sont pas vides.

Troisième définition : NP. Effectivement, NP signifie nondeterministic polynomial time, ce qui ne veut en aucun cas dire non-P. Ca veut dire polynomial sur une machine non déterministe (c'est-à-dire pas sur un ordinateur classique). La définition moderne est donnée dans l'article que j'ai cité au dessus (http://www.claymath.org/prizeproblems/p_vs_np.pdf(...)). Avec les mains, ça donne la chose suivante : un problème est NP si répondre à la question "cette donnée est elle une solution du problème ?" peut se faire en temps polynomial.

Propriété triviale : P est contenu dans NP.

Quatrième définition : NP-complet. On dit qu'un problème est NP-complet si tout problème NP peut se ramener en temps polynomial au problème étudié. En gros pour résoudre un problème NP, on bidouille l'énoncé du problème (en temps polynomial) et on donne l'énoncé bidouillé au programme qui résout le problème NP-complet : la réponse du programme est bonne pour le problème d'origine.

Bien entendu (et c'est tout l'aspect fun du problème), personne ne sait si P=NP (ou si P/=NP) (cf toujours le même papier).

Comme tu n'as pas l'air très fort, tu peux aussi lire la version pour les enfants du papier, i.e. http://www.claymath.org/prizeproblems/milliondollarminesweeper.htm(...)

Deuxième point :
----------------
Pour décomposer un nombre en facteurs premiers, il suffit d'appliquer récursivement le "cassage" à ses facteurs. J'appelle "cassage" un algorithme qui trouve un facteur non trivial d'un nombre p (i.e. différent de 1 et p). Si tu veux décomposer 20 en facteurs premiers, il te suffit de le casser, c'est-à-dire de trouver que 20=2x10 (à priori tu devrais d'abord trouver 2). Ensuite, tu casses récursivement 2 et 10 (soit 2x5) et donc 5. Moralité, tu as cassé 2,5,10 et 20, et non pas tous les nombres avants. Moralité de la moralité : arrêtes de dire des conneries.

Troisième point :
-----------------
Il existe un algorithme de cassage (cf après) polynomial, mais cet algorithme n'est juste que si la conjecture de riemann (un truc bien compliqué...) est vraie. La plupart des spécialistes pensent que la factorisation en temps polynomial est cependant peu probable. Donc ACTUELLEMENT il n'existe pas d'algo de factorisation en temps polynomial. MAIS CE N'EST PAS LE PROBLEME POUR RSA PUISQU'ON SE CONTENTE D'UN CASSAGE !!!!!!!!! Or, il se trouve qu'il n'existe pas pour l'instant d'algorithme de cassage en temps polynomial, ce qui est le bon argument pour RSA (tu fais de nouveau l'erreur pour la primalité). Bien entendu, la factorisation et le cassage sont dans NP, mais comme ils ne sont pas NP complets (enfin, on pense qu'ils ne le sont pas), les conjectures basés sur les gros problèmes NP-complets peuvent très bien ne pas s'appliquer à eux. En d'autres termes, même si tout le monde pense que les problèmes NP-complets demandent un temps exponentiel, ça n'apporte pas trop d'information sur le cassage.

Disclaimer : je suis maître de conférences en informatique. Oui, ça aide.

Non, mais de toute manière, on ne crypte pas ton mail avec RSA, on crypte une clé de session qui est elle utilisée pour crypter le mail. Donc ce n'est pas trop dramatique d'allonger le temps de calcul (surtout que cet allongement n'est pas monstreux (linéaire avec le nombre de bits de la clé))

N'importe quoi, sur toute la ligne.

D'abord, on peut tester raisonnablement rapidement si un nombre est premier, et surtout on ne fait pas ça en factorisant le nombre, car c'est très coûteux (cf en dessous). On utilise un test de primalité genre Miller-Rabin.

De plus, pour le problème qui nous intéresse, on sait qu'une partie de la clé RSA (la partie intéressante) est un produit de deux nombres premiers. Il suffit donc de trouver un diviseur de la clé, sans se soucier si ce diviseur est premier. Bien entendu, c'est tout aussi coûteux.

L'algorithme proposé dans le post auquel tu réponds est effectivement mal évalué, mais ça n'a aucun rapport avec ton argument incorrect. Si on divise un nombre par un autre, le temps de calcul naïf est en (log n)^2, où n désigne le plus grand des deux nombres. Pour tester naïvement si un nombre est premier (et non pas pour le décomposer en facteurs, mais on s'en fout pour RSA), il faut donc en gros sqrt(n)(log n)^2 opérations. Le gros problème, c'est que dans cette analyse, n désigne la VALEUR de la clé, pas son nombre de bits. Or, pour une clé de p bits, la valeur de la clé est au minimum de 2^{p-1}. On a donc une complexité qui est bien exponentielle avec le nombre de bits de la clé. D'ailleurs on ne sait pas faire mieux, cf le post de CNS plus bas.

Enfin, je te conseille vivement la lecture d'un bon cours d'informatique, car les problèmes NP et NP-complets ne sont pas définis comme non polynomiaux, vu qu'il s'agit seulement d'une conjecture. La définition est assez technique et je ne vois pas trop l'intérêt de la donner ici, mais bon, ce n'est pas non polynomial.

Sauf que tu confonds complètement recherche exhaustive et factorisation. Une technique pour casser RSA est de factoriser un grand nombre produit de deux nombres premiers. Le temps de factorisation est proportionnel à la longueur du nombre à factoriser, c'est-à-dire à la longueur de la clé. Bernstein a trouvé un algorithme et une machine particulière qui permettent de multiplier par trois (et pas par quatre) la longueur d'un nombre factorisé dans un temps donné. Il faut donc multiplier par trois la longueur de la clé RSA pour garder le même niveau de sécurité.

Pour le choix d'une distribution en Open Source, cela relève de la volonté du décideur de l'établissement public. Par exemple, dans une fac, cela relève du président et du conseil d'administration. Le moins qu'on puisse dire c'est qu'il y a un clair manque de motivation des personnes concernées. Mais ça bouge. Certains chercheurs de Paris-VII ont obtenu que la commission de valorisation accepte d'étudier la question et d'éventuellement de permettre aux chercheurs une distribution open source.

Il faut bien comprendre que le but de la majorité des chercheurs, c'est la diffusion la plus large de leurs résultats et la seule solution c'est l'Open Source. Mais comme les logiciels des chercheurs sont très spécialisés en général, je doute qu'on puisse vendre de tels logiciels. Il ne faut pas rêver, pour un logiciel scientifique évolué, le coût de la maintenance est astronomique.

Quant aux contrats de recherche, il est clair qu'il est presque impossible dans signer un sans accord de confidentialité, accord qui est parfaitement légal et très compréhensible. Un petit exemple : j'ai travaillé sur des bases de données marketing d'un grand groupe et j'ai donc eu accès à des informations qui n'ont pas de prix pour la concurrence. Je trouve parfaitement normal de ne pas pouvoir en dire plus sans l'accord du grand groupe en question.

Notons aussi que la fonction publique doit appliquer aux personnels des grilles de salaires qui ne cadrent pas vraiment avec les tarifs du marché pour les informaticiens. Par contre, il n'y a pas de grilles de salaires pour les intervenants qui ne sont pas salariés directement par un service public, d'où le recours massif à la soutraitance. Ceci étant, cette externalisation n'a rien de spécifique à la fonction publique.

- Comme l'ont déjà dit certains posteurs, un problème clair posé par cette initiative est celui du financement mixte. Certains naïfs pensent que le financement public est correct... En réalité on est loin du compte et il est presque indispensable pour un chercheur de trouver de l'argent privé pour financer son matériel informatique et ses déplacements en congrès. Chaque obtention de fonds correspond à une négociation avec le bailleur privé. Si on veut appliquer les idées de l'initiative OReilly (que je trouve très bonnes), il faut en tenir compte dans le contrat négocié. A titre personnel, je ne vends que des prestations intellectuelles, jamais les logiciels que je développe pour les produire. De ce fait, je n'ai aucun problème pour ces logiciels, je peux en faire ce que je veux (enfin, pas vraiment, voir ci dessous)

- La plupart des posts contiennent des confusions concernant la propriété intellectuelle des travaux des chercheurs. Le code de la propriété intellectuelle est relativement peu clair concernant les chercheurs du public, mais en gros, les juristes s'accordent à dire que les chercheurs sont individuellement propriétaires de leurs résultats de recherche, ce qui n'inclut pas les logiciels. Comme le disait un posteur, un chercheur peut donc publier ses résultats pour les rendre accessibles par le plus grand nombre. Cependant, il arrive très souvent que le financement privé interdise cette possibilité (dans les termes du contrat)...

- La situation pour les logiciels est très claire et donc très merdique. D'après le code de la propriété intellectuelle, les logiciels développés par les chercheurs sont propriétés de l'établissement public avec lequel ils ont un contrat. De ce fait, seule l'Université, le CNRS, l'INRIA, etc. a le pouvoir de placer un logiciel en open source. Le chercheur n'a rien à dire. Or, la tendance est plutôt à la "valorisation de la recherche" (lire la vente des résultats au privé), en particulier depuis ce c*****d d'Allègre.

Tout à fait. Ce que je voulais simplement dire, c'est que rien ne permet d'affirmer a priori que l'écran d'apple est bon. Par contre, on peut sans risque dire que ce n'est pas du haut de gamme, vue la faible résolution. Il est peut être très bien dans sa catégorie, mais à titre personnel, j'avoue que je ne vois vraiment pas l'intéret d'un 15" plat basse résolution. L'affichage sur un 17" CRT de même prix sera largement meilleur. Mais bon, on s'éloigne du sujet.

Ok, mais un écran 15" en 1024x768, c'est bas de gamme et d'ailleurs assez pourri (on voit les pixels). J'ai un 1400x1050 sur mon portable et je peux te dire que c'est le jour et la nuit (je n'imagine même pas des derniers 1600x1200). Donc peut être que le 15" d'Apple est correct, mais ce n'est sûrement pas un écran de bonne qualité. Juste un écran moyen.

Bon la solution est trouvée donc ... Postfix !





Sauf qu'il y a déjà eu plusieurs bugs de sécurité dans Postfix et jamais aucun dans qmail.

Tout à fait d'accord, écrire du MathML à la main, c'est tout simplement du délire.

Par contre, ça apporte clairement quelque chose par rapport à TeX : MathML comprend un langage de rendu (genre TeX) et un langage d'évaluation qui permet de calculer une valeur pour une expression par exemple, et ce de façon beaucoup plus simple qu'à partir du langage de rendu. De ce fait, si tu utilises un logiciel genre Mupad, Maple ou Mathématica, tu peux espérer taper ta formule une seule fois. Le logiciel fait son petit calcul formel et peut exporter ta formule en MathML, en incluant la présentation et l'évaluation. C'est récupérable pour la présentation, mais aussi pour d'autres manipulations formelles. Bref, c'est une bonne idée, mais c'est clairement totalement inadapté à la manipulation par un humain, ce qui craint un peu, tout de même.

Surtout que bon, présenter FO comme concurrent de TeX, c'est vraiment n'importe quoi. TeX, ça se PROGRAMME. Pas FO. J'aime beaucoup XML, on peut faire des choses très intéressantes grâce à l'aspect plateforme du langage : comme c'est un standard, il existe presque toujours un logiciel open-source qui fait ce qu'on veut ! Mais il ne faut quand même pas en rajouter. Je me vois mal utiliser fo pour faire des maths, par exemple (même si un des moteurs de rendu en TeX permet l'interprétation (par TeX, bien sûr) de formules MathML).

Sinon, il existe une assez bonne présentation de FO à l'URL suivant : http://www.ibiblio.org/xml/books/bible2/chapters/ch18.html(...)

Je crois qu'on se comprend mal. J'ai pas mal d'amis dessinateurs, maquetistes, graphistes, etc. (ma femme est journaliste, ça aide). Tu peux toujours ne pas croire ce que je te dis, ça ne changera rien aux faits : les artisans des arts graphiques ont besoin d'un fort couplage entre la main et l'oeil. C'est comme ça. Je ne sais pas expliquer ou rationnaliser ça plus que par ce que j'ai déjà donné comme exemples (les jeux vidéos, les montres, etc.). Une belle maquette (celle de joystick est un modèle du genre) n'obéit qu'à des règles très informelles (genre la taille des titres, et encore). Par exemple dans joystick, il est clair que la couleur du texte dépend de la couleur des screenshoots inclus dans l'article et le maquetiste trouve ça par essai, en général en bidouillant avec la pipette pour prendre une couleur de l'image. Autre point intéressant, en général le texte est justifié. Parfois, le logiciel ne peut pas justifier de façon propre (trop de blanc). Alors le maquetiste passe en non justifié. Problème : pour l'harmonie de la page, il faut parfois passer les textes proches en non justifié, alors que ces textes sont très bien justifiés par le programme. Le seul moyen de décider, c'est d'essayer et on fait ça beaucoup plus vite avec un outil wysiwyg.

Pour l'automatisation de mon histoire de paragraphe, je pense qu'il y a quelque part un problème (peut être au niveau du modèle de rendu de TeX), vu que (bis repetita) il n'existe à ma connaissance aucun package (La)TeX qui le fait, alors que c'est une présentation classique dans pas mal d'ouvrages. Bien entendu, si il existe une solution, elle sera réutilisable. Si tu ne vois pas la différence avec XPress, je ne peux rien pour toi. Comme tu le dis, il faut être un expert TeX pour résoudre le problème. En XPress, c'est accessible à tout le monde (dans les attributs d'un paragraphe...). A ma connaissance, il n'existe aucune feature de TeX qui ne soit pas présente de façon au moins aussi simple d'utilisation dans XPress, sauf la gestion des ligatures.

Entendons nous bien pour la fin de ton post : je ne prétends pas que l'approche Wysiwyg est meilleure que l'approche par programmation (ou vice-versa) et je suis d'accord pour dire qu'un spécialiste de l'une pourra en général produire le même résultat qu'un spécialiste de l'autre. Cependant, je suis convaincu par mon expérience d'enseignant (de la programmation) qu'il est beaucoup plus difficile d'apprendre à programmer que d'apprendre à utiliser un logiciel de "à la souris". Certains de mes élèves, qui sont des truelles en Java, maîtrisent complètement Excel par exemple (graphisme, mise en page, etc.). Ils ont appris tous seuls. En ce sens, l'apprentissage de XPress est très certainement plus rapide que celui de TeX, en particulier pour les besoins d'une maquette de journal. Entendons nous bien, je ne parle pas d'apprendre à faire un article avec LaTeX, mais bien de pouvoir résoudre tous les problèmes qui se posent pour créer une maquette, ce qui implique presque obligatoirement de la programmation en TeX (langage bien merdique quant il s'agit de faire certaines manipulations, par exemple des calculs). Les formations XPress durent quelques jours et à la sortie, un bon graphiste est capable de faire une maquette, même très complexe. Je suis certain qu'un bon graphiste est incapable de résoudre mon problème (toujours le même) après 4 ou 5 jours de formation TeX.

Quand malgré les césures, on obtient un paragraphe laid (trop de blanc), TeX le dit et ou bien laisse du blanc, ou bien laisse dépasser le ou les derniers mots d'une ou plusieurs lignes. Ce que fait un bon maquettiste, c'est souvent de passer toute la colonne en non justifié, ou un autre astuce du genre. On peut faire ça en TeX sans problème. Ce n'est pas automatique (comme en XPress). C'est plus clair ?

Je pense que tu fais une erreur fondamentale en pensant que le résultat ne dépend pas de l'outil utilisé. Je commence par une anecdote : les montres à affichage digital n'ont par encore remplacé les montres à aiguilles et elles se maintiennent à une part de marché à peu près fixe (je ne connais pas cette part, malheureusement). Des psychologues se sont penchés sur le problème et ont obtenu une réponse simple : une montre à aiguille t'indique physiquement combien de temps s'est écoulé depuis un instant donné, simplement par la distance angulaire entre les aiguilles. Pour une montre digitale, il faut faire un calcul. La perception de certains éléments physiques améliore grandement la qualité des informations reçues. On pourrait multiplier les exemples à l'infini : sur certains jeux, le game pad permet de mieux jouer (c'est un fait), pour d'autres, c'est le joystick. Il est très rare de trouver des artistes qui réalisent des oeuvres de qualité à la palette graphique, ou pire encore à la souris. Simplement parce qu'il manque le retour d'effort de l'instrument de dessin (pinceau, crayon, fusain, etc.).

Pour caricaturer ta position, il est tout à fait possible de produire un dessin avec un programme, sans jamais utiliser la souris ou un autre outil faisant partie d'une chaîne wysiwyg. Et pourtant, même pour des schémas simples, tout le monde utilise un truc wysiwyg (genre xfig en couple avec TeX). Etonnant, n'est-ce pas ? Bien sûr pour certains schémas, il vaut mieux utiliser un truc comme PSTricks, mais en général, l'outil wysiwyg permet de faire réellement les choses, même si elles sont théoriquement réalisables avec d'autres outils.

Pour revenir à la comparaison TeX/XPress, il n'y a aucun problème de réutilisation dans XPress. La notion de style est tout à fait performante et s'applique à plusieurs pages. Tu peux appliquer un style et obtenir une brouillon de page dans lequel tu n'as plus qu'à insérer le texte (dans les différentes boites). Chaque boite peut être éditée en réseau, avec un système de versionning et de lock. Je sais, c'est faisable en TeX, mais pas en pratique (pas avec cette granularité). Les styles se définissent facilement à partir d'un modèle réalisé en wysiwyg...

Tu indiques toi même que la mise en page est difficile en TeX. A titre personnel (je me trompe peut être), je pense que certaines choses sont impossibles à faire automatiquement. Je pense en particulier à des attributs de paragraphe genre mise en boite, fond coloré, etc. Il est facile de faire ça avec divers package en général basés sur postscript. Maintenant je ne connais pas de solution qui permette d'avoir un paragraphe réparti sur au moins deux pages avec ce genre d'attribut. Les solutions que je connais ne sont pas capables de mettre un paragraphe dans une boite par exemple si ce paragraphe débute sur une page et termine sur une autre (je pense que ça merde aussi en multicolonnes, mais je n'ai pas essayé, à vrai dire). Je connais des solutions qui s'appliquent à du texte organisé en lignes indépendantes (par exemple un tableau qui s'étale sur plusieurs pages, ou encore un programme dans une boite), mais pas à du texte simple. Bien entendu, je peux couper le paragraphe à la main, mais c'est franchement à chier comme solution. Si tu es capables de me montrer comment faire, j'accepte de dire que tout est faisable en TeX, parce que c'est la seule vraie limitation que je connaisse. Bien entendu, je parle ici d'une limitation théorique, parce que je pense qu'il existe de nombreuses limitations pratiques (le multicolonne n'est quand même par très bien géré par les packages que je connais, par exemple).

Oups, j'allais oublier : bien entendu la maîtrise de XPress est assez délicate, comme celle de TeX. Je pense cependant qu'il y a une différence fondamentale de niveau de conceptualisation. Dans XPress, rien n'est abstrait : tu vois le paragraphe, tu vois le modèle, etc. Dans TeX il y a de façon sous-jacente la notion de langage de programmation (en plus le langage en question est particulièrement tordu, même s'il s'adapte bien au but recherché). Donc, je pense que XPress est plus accessible que TeX.

Je suis d'accord avec toi sur le non justifié ou le réglagle fin de l'approche en automatique. Sauf erreur de ma part, XPress fait ça aussi bien que TeX. Le problème, c'est justement le non automatique. Il me semble que quand TeX n'arrive pas à faire quelque chose de justifié, il ne passe pas le paragraphe entier en non justifié (XPress non plus). Un bon maquetiste fait la modification à la main, en observant en temps réel l'effet de son choix sur le rendu global de la page. De même pour l'approche.

Pour les secrétaires, je n'ai jamais mis en doute les capacités d'apprentissage. J'ai cependant comparé le travail de deux secrétaires, une experte word et une personne bien formée en LaTeX (incapable de définir des macros évoluées, mais capable d'utiliser toute sorte de package). Sur du texte scientifique, il n'y a pas photo, non seulement le LaTeX donne un meilleur résultat, mais en plus, la secrétaire est plus productive. Par contre, pour un travail genre PAO (réalisation d'une maquette), il ne faut pas chercher : la secrétaire LaTeX est totalement incapable de réaliser ce que fait la secrétaire Word, simplement parce qu'il faut du wysiwyg, point barre.

Je suppose que ta justification pour surencherir sur mes considérations sur ton niveau intellectuel sera que j'ai commencé le premier, c'est de bonne guerre.

Tu sais sûrement que TeX est aussi fait pour les secrétaires, c'était le but de Knuth dès le départ, et ça a bien marché, comme tu le sais.

Tu ne sembles pas avoir compris que ma réponse ne cherchait pas à être pertinente, simplement parce que la tienne ne l'était absolument pas. Bien sûr, qu'on peut tout faire en assembleur. Du moins en théorie. Est-ce qu'on peut VRAIMENT tout faire en assembleur ? Est-ce qu'à partir d'un certain moment, la complexité devient-elle que nécessairement, un humain n'y arrive plus ? Est-ce que PRATIQUEMENT, on peut vraiment tout faire en assembleur ? Pour reprendre l'exemple d'une mise en page complexe, du point de vue pratique, on ne peut pas faire en TeX, parce qu'il y trop de choses qui ne sont pas automatisable, comme par exemple des réglagles fins de l'approche, le passage d'un morceau de texte en non justifié parce que c'est plus beau, etc. Bien sûr, en XPress, il faut toujours faire ça à la main. Mais c'est wysiwyg, donc on peut faire ça vite. Du point de vue PRATIQUE, c'est IMPOSSIBLE à faire en TeX (trop long, trop chiant, trop merdique (comment un artiste (un maquetiste de haut vol) peut-il travailler sans un retour direct de l'effet de sa main (par l'intermédiaire de la souris) sur le rendu de la page ?). Donc, ta réponse est totalement inutile. De fait, certaines choses ne sont pas faisables en TeX, ce qui n'enlève rien à la qualité de cet outil.

De plus, certaines choses évoluées ne sont possibles que grâce au passage par postscript (un overlay d'une image, un texte qui suit une courbe arbitraire, etc.), ce qui n'est pas trop du plain tex, il me semble. Je sais bien que cette remarque est aussi con que la tienne, mais elle est autant valable...

Si c'est possible, fait le. Et automatiquement, comme avec XPress. Et après tu repasses pour nous faire une démonstration. Quant à LaTeX pour les secrétaires, faut vraiment être un crétin pour affirmer ça (désolé mon gars). Enfin, peut être pas un crétin, mais plutôt quelqu'un qui n'a jamais bossé avec une secrétaire.

Bof. Dans les journaux profesionnels, on ne sait même pas ce qu'est LaTeX et on ne change pas tout les jours de maquette, loin s'en faut. Les outils de création de styles fonctionnent très bien sous XPress, de même que la gestion réseau à la RCS/SCSS.

Il ne faut pas croire qu'un logiciel qui marche à la souris est simple d'utilisation (exemple : XPress,AutoCAD, etc.). La première approche est plus simple, c'est tout. Il ne faut pas croire non plus qu'un logiciel qui marche à la souris est nécessairementmoins bon qu'un logiciel qu'on programme. J'aimerais bien voir une classe LaTeX (ou des macros TeX) pour réaliser une maquette haut de gamme (genre celle de Joystick par exemple). Je pense sérieusementque c'est impossible.

Pourtant, je suis un fan de LaTeX, parce que pour l'édition scientifique, c'est difficile de faire aussi bien. Mais de là à dire que c'est un outil universel...

C'est faux, des implantations open-source de c#
et de .NET sont prévues : http://www.ximian.com/about_us/press_center/press_releases/mono_ann(...)

C'est le projet mono.

Pour broadcast2000, il me semble que ça n'a rien à voir avec les brevets, mais plutôt avec des histoires de garanties. En gros, les auteurs du soft ont peut de se prendre un procès pour dommage causé par leur logiciel, malgré l'exception clairement indiquée dans la GPL (cf http://www.heroinewarrior.com/bcast2000.php3(...) ).

D'autre part, je ne suis pas sûr que les développeurs refusent à tout voyage aux USA après avoir hebergé leur travail en dehors des USA, cf la news sur le DMCA.

Quant aux développeurs US, ce n'est pas parce que leur travail n'est pas hébérgé aux USA qu'ils ne risquent rien...

L'idée est sympa, sauf qu'ils peuvent quand même attaquer, parce que la base d'un brevet, c'est de délirer. En gros, dans un brevet tu as des "prétentions" (je ne me rappelle plus du terme technique en français, en anglais, c'est claim) que tu ranges de la plus générale à la plus spécifique (en France). Imaginons par exemple que j'ai inventé un algo de compression d'images basé sur les ondelettes. Voici ce que je prétend couvert par mon brevet :

- la compression
- la compression d'images
- la compression d'images à base de décomposition spéctrale
- la compression d'images à base de décomposition spéctrale par ondelettes
- etc.

avec de plus en plus de détails sur l'algorithme. Il est clair que les premières prétentions ne tiennent pas la route, mais il faut aller en justice (ou disons en concilliation) pour prouver ça.

Rien ne dit donc que Macromedia prétende couvrir plus que l'édition de page web (sur le site proposé, on ne peut pas lire l'intégralité des claims, donc...).