boubou a écrit 1384 commentaires

Mes connaissances sur le multi-agent sont très limitées, en fait, mais je pense que Sylvain résume bien les grandes tendances, en gros les agents peu nombreux "très" intelligents et les agents très nombreux et très cons. J'ai d'ailleurs voulu illustrer ça dans mon article, en montrant comment on peut modifier le comportement soit au niveau individuel, soit au niveau global.

Tu es un peu têtu, non ? J'ai signé l'accord de Linux Mag/Misc/Linux Pratique 12 fois et je l'ai lu. Ce texte comporte, entre autres, une clause par laquelle on renonce aux bénéfices de l'article L121-8.

Tu as parfaitement raison, ça a d'ailleurs été l'occasion de procès dans le monde du journalisme. Dans le cas des auteurs linux mag, l'exploitation web est parfaitement prévue dans le contrat signé avec Diamond Editions (et je doute que d'autres éditeurs oublient ça de nos jours :-).

Ba c'est bien cool, merci !

Non, c'est faux. Les droits patrimoniaux (d'exploitation) sont cédés à Diamond Editions qui décide donc seul de la publication (mise à la disposition du public) des articles.

Comme je te comprends, cet article est imbitable (et, à mon avis, de très mauvaise qualité). J'ai commencé des modifications importantes dans http://fr.wikipedia.org/wiki/Neurone_formel pour le rendre plus clair. Qu'en penses-tu ?

Merci pour cette remarque, parfaitement justifiée, je vais corriger ça !

Merci pour ce message sympathique. Je compte mettre toute ma production linux mag en ligne, peu à peu (la liste est ici : http://apiacoa.org/publications/vulgarisation.html ). Pour l'instant, ça traîne...

schema mal fichu

Tu parles des schémas du W3C ou en général ? Parce que franchement, les schémas Relax NG, je ne vois pas en quoi ils sont mal fichus, au contraire.

Pour paraphraser arnaudus, l'avantage par rapport à quoi ? Parce qu'XML propose tout ça, même une version binaire (en cours de spécification par le W3C), et beaucoup plus encore...

Bref, il y a d'autres format que le XML qui sont aussi bien fichu.

Ca ne fait pas l'ombre d'un doute. Par contre, aucun format n'est aussi populaire que XML et aucun format ne propose donc une telle quantité d'outils associés. Je ne parle pas simplement de bibliothèques chargement/sauvegarde, mais aussi de tout le reste (validation de schéma, transformation, langage de requête, etc.).

Encore une belle preuve de l'aberration totale qu'est XML

Il ne faut pas confondre l'outil et son utilisation. XML est un outil très utile, il faut simplement refléchir à son impact au lieu de le choisir systématiquement.

Pour moi c'est comme si on disait "ne fumez pas des malboro, c'est dangereux pour la santé". C'est pas faux, mais ca induit véritablement l'interlocuteur en erreur, il pourrait être tenté de croire qu'il y a d'autre marque peut être moins dangereuse. La phrase objective voulant faire passer un message pertinent serait de dire "ne fumez pas des cigarettes, c'est dangereux pour la santé".

J'ai bien compris, tu essayes de t'abriter derrière un danger pour refuser l'évaluation du niveau de risque. Les cigarettes sont dangereuses pour la santé, mais pas toutes de la même façon. Par exemple, on admet généralement que la quantité de goudron est un indicateur important des risques de cancer et cette quantité dépend de la marque et du type.

Toute ta stratégie autour de Mono est de minimiser le risque, soit en le niant (ça c'était au départ, quand on ne savait pas avec certitude s'il existait des brevets portant sur .NET), soit en prétendant de façon erronée qu'il est identique à ceux induits par d'autres logiciels, ce qui est faux en général.

Ben pour Mono c'est pareil, sous entendre qu'il faut mieux utiliser autre chose (sans préciser quoi), c'est une forme de mensonge par omission. Faudrait dire "N'utilisez aucun logiciel c'est dangereux juridiquement" pour être honnête, ou alors dire "Utilisez Mono ou un autre, c'est pareil".

Voilà un bon exemple de ce que je dis au dessus. Tu aurais raison de dire "la probabilité qu'un logiciel quelconque enfreigne un brevet est élevée", il y a un consensus là dessus. Il y a donc un risque inhérent à l'utilisation de tous logiciels (ou presque). Mais refuser de tenir compte de la hiérarchie des risques, c'est tout simplement nier la réalité. Dans cette hiérarchie, on a MP3 tout en haut (open source illégal dans les pays qui reconnaissent les brevets logiciels), Mono entre les deux (brevets spécifiques possédés par un acteur par super sympa avec le libre) et Java assez bas (techno qui va être libérée par son créateur qui possède un paquet de brevets pour la protéger). Que tu le veuilles ou non, il y a une différence de risque entre .NET et Java, en faveur du second.

Je suis un simple geek sans aucun intérêt dans Mono, j'admire cette techno et je cherche simplement à ce qu'on arrête de la dénigrer systématiquement pour des raisons juridiques.

Nous avons déjà eu cette "conversation". Je ne cherche pas à dénigrer Mono, que j'admire techniquement sûrement autant que toi, je cherche simplement à faire apparaître les faits, alors que tu cherches à les minimiser ou à détourner l'attention d'eux.

Alors merci d'arrêter les termes de "propagande" qui sous-entend que je cherche à pervertir le cerveau des gens en les convertissant à une idée.

Tu cherches à masquer la réalité et tu désinformes, en particulier en répétant que les risques sont les mêmes et qu'il n'y a pas d'alternative.

Euh... oué et ? Quel intérêt de standardisé System.Web ? Oué, et là encore, quel intérêt de standardisé ADO.NET ? C'est d'autant pas standard que ce n'est même pas censé être une interface commune à toutes les base de données, chaque driver à ses API spécifiques dédiée à une BDD.

Revenons à la question d'origine. Beaucoup de gens (dont toi) aiment minimiser les risques induits par Mono en répétant à l'envie que .NET est standardisé (et donc que MS est obligé de donner une licence RAND de ses brevets, ce qui nous fait une belle jambe, mais c'est une autre histoire). Or, à peine 10% de l'API de .NET est effectivement standardisé, ce qui ne fait pas beaucoup. Histoire de minimiser ce fait, tu prétends qu'on peut faire une plateforme libre en ajoutant des api à ce qui est normalisé. En théorie, c'est vrai, mais comme je te le fais remarquer avec divers exemples, ce n'est pas ce qui se passe dans les faits. Dans les faits, les applications développées pour Mono utilisent certaines api microsoft non standardisées et sont donc vulnérables à une éventuelle aggression de MS. Donc pour revenir à ta question, l'intérêt d'avoir ces api sous une forme standardisée serait de limiter les risques induits par les brevets .NET.

Comprend pas ta conclusion. On doit pas avoir la même idée de l'intérêt de normaliser quelque chose en informatique. Normaliser sert avant tout à faciliter l'interopérabilité. L'intéropérabilité au niveau des web services, c'est l'interface que tu décris (le schema w3c et ce qui va avec), comment c'est implémenté derrière justement on s'en cogne. En l'occurence pour .NET tout est dans la sérialisation XML automatique et le mécanisme d'attribut, qui sont tous les 2 normalisés, garantissant qu'une implémentation de la serialization XML soit compatible avec une autre, ce qui est tout à fait pertinent.

Bla, bla. La discussion ne porte pas sur l'intérêt de la standardisation en informatique, mais au fait que celle-ci réduit les risques pour Mono...

Pas grave, Mono fera un autre API, c'est pas vital à l'interopérabilité entre applications. Ca pose seulement un problème de compatibilité entre Mono et .NET,

Une fois qu'un délit est commis, on est puni même si on dit qu'on est désolé.

Merci de rappeler où est l'interopérabilité dans les web-services, et où la normalisation a un intérêt. Oué et ? Au pire Mono implémente les web-services comme le fond d'autres framework, à moins que les brevets bloque toute implémentation possible des web-services, ce qui ferait que tous les framework et pas spécialement Mono sont en danger.

Encore une fois, je t'invite à lire les brevets de Microsoft. Ce que MS brevete, c'est une façon d'implémenter certains web services. Pour être compatible .NET, Mono doit les implémenter de cette façon et c'est ce qui est fait actuellement. Donc, ça augmente les risques pour un développeur, car une api peut trs bien disparaître à cause d'une plainte de MS. Toute l'analyse des risques liés à Mono est justement faite de ce genre de choses qui montrent que contrairement à ce que tu repettes, les risques avec .NET ne sont pas les mêmes qu'avec d'autres technos comme Java ou Python.

Oué c'est faux si tu veux, t'as raison, ils ont des brevets qui couvre une parti seulement des web services.

Pas du tout, ils ont des brevets sur l'implémentation standard et l'api de web services en .NET, pas sur "les web services".

Et ? Pourquoi tu discutes d'un détail comme ca ?

Parce que ça montre qu'en utilisant l'api en question, on prend plus de risques qu'en utilisant une autre api.

Ca change rien au fond : Novell a des brevets, aussi infîmes soient-ils, ils sont une arme de dissuasion et ca c'est tout leur intérêt et tout ce que je voulais dire (et ce que tu as très bien compris).

Les brevets rétablissent une forme d'équilibre, ils ne font pas magiquement disparaître les risques.

Infime mais vitale, t'as vu comment ils utilisent les web services à fond dans Vista ?

As-tu fait une analyse détaillée des brevets de l'OIN pour dire que l'utilisation des web services dans Vista est couverte par ces brevets ? Ma lecture des brevets en question est qu'ils portent avant tout sur le e-commerce et je doute que Vista utilise les web services seulement pour le e-commerce. Donc les brevets sont peut être gênant pour une partie de Vista, mais il ne faudrait quand même pas rêver.

Détrompe toi. De même qu'une collection d'articles est protégée en tant qu'oeuvre composite, un brevet peut très bien protéger la combinaison de trivialités ou une amélioration par rapport à l'existant. Cela rend les accords de licence complexes. Par exemple si tu brevetes A+B où A et B sont deux choses brevetées, ça ne te donne pas le droit d'utiliser A+B, tu dois avoir une licence pour A et pour B. Par contre, quelqu'un qui veut utiliser A+B doit obtenir une licence de toi. Dans le cas d'une api, on peut donc breveter (et c'est fait par microsoft) une combinaison de classes, même si chaque classe semble totalement triviale.

Il est clair que ce système de brevets logiciels est délirant, mais c'est comme ça qu'il fonctionne.

Pourquoi systématiquement cette remarque à 2 balles ?

Parce qu'à chaque fois que quelqu'un poste une remarque "négative" (je mets des guillemets car ta perception de négative est très large), tu réponds en essayant de minimiser cette remarque, soit en parlant de choses qui n'ont aucun rapport, soit en pointant les mêmes défauts (ou des défauts apparentés) dans autre chose. Exemple : "Microsoft a des brevets qui couvrent .NET". Ta réponse "Oui mais il y a aussi des brevets sur X ou Y". C'est une méthode typique de la propagande. Qu'est-ce que change le fait que X ou Y soit breveté à la situation de Mono ? Rien du tout. Par contre, ça induit le doute dans l'esprit des lecteurs.

Tu préfères par dénigrer systématiquement ton interlocuteur quand t'es pas d'accord avec lui ?

Tu remarqueras que je te réserve cette remarque car depuis qu'on trolle sur .NET ta méthode n'a toujours pas changé.

Euh, c'est ca que t'appel une lib "de base" ?
Non, par contre dans le poste auquel je répondais tu sous-entendais qu'une des motivations de la non standardisation de bibliothèques était leur caractère spécifique Windows. Je te donne donc des exemples de bibliothèques très importantes qui ne sont pas standardisées et qui sont spécifiques windows.

Là on parle de Mono & Gnome, bref on peut très bien se passer de ADO.NET et ASP.NET et faire des applis desktop pour Gnome complète basé sur les standards de l'ECMA et les bindings de Gnome.

Ba non, affirmation typique Timaniac (propagande ?). Par exemple tu prends F-Spot et tu vois qu'il utilise par exemple System.Web qui n'est pas standardisé. En outre il stocke pour l'instant tag et compagnie dans une base sqlite. Comme ce genre de base ne scale pas des masses, je suppose qu'une interface avec des SGBD plus solides est prévue et utilisera ADO.NET, non standard (j'aouve que c'est ici de la spéculation).

Plus globalement, l'accès à des services web ou à des BD est de plus en plus important pour des applications desktop et se fait en .NET par des api non standardisées, d'ou un problème possible.

Pour ce qui est d'ADO.NET cela peut être parfois utile, mais globalement les drivers utilisés sous Linux sont des drivers spécifiques aux BDD utilisées (MySQL par exemple). Leur licence dépend généralement du fournisseur de base de données.

Et alors, le rapport ? ADO.NET n'est pas standardisé et est couvert par les brevets que j'ai mentionné (et sûrement par le brevet de FireStar, mais c'est un autre problème). Microsoft n'est pas du tout obligé de donner une licence RAND pour les brevets en question (car ce n'est pas standardisé) et pourrait donc bloquer toute implémentation de l'api d'ADO.NET. Je ne vois pas le rapport avec la licence du back end...

Oué c'est vrai que les web services c'est pas standardisé :) Z'allait pas non plus mettre à l'ECMA ce qui est déjà normalisé au W3c.

Encore aucun rapport. Ce qui est standardisé, c'est le dialecte XML (DTD et schéma), la sémantique à accorder aux différents éléments, etc. Rien n'empêche une entreprise de breveter une API de création d'un serveur ou d'appel à un service, et c'est d'ailleurs ce qu'a fait Microsoft pour celle de .NET (deux brevets, sauf erreur de ma part). Tu comprends la différence ?

Et pour ce qui est de l'implémentation de MS, ben les brevets concernant les web services c'est Novell qui les détient.

Et voilà, toujours aussi imprécis (et faux). Novell a fait don à l'OIN de trois brevets portant sur le commerce électronique et sur certaines formes de web services (dans le domaine du commerce). Ces brevets ne couvrent pas tout le concept de web services. En outre, c'est orthogonal à un brevet sur une api, et en plus, ça ne concerne qu'une infime partie de l'api de .NET qui n'est pas standardisée.

J'ai beaucoup de photos et j'ai essayé F-Spot (sous Fedora Core, donc dans sa version 0.1.10). Ca plante tout le temps. Moralité, j'utilise digikam qui est beaucoup plus complet et beaucoup plus stable. J'avoue que cet intégrisme (je ne parle pas de toi) Gnome ou Kde me fatigue. Pourquoi ne pas utiliser digikam et gaim, par exemple, sans se poser la question du desktop qui lui est associé ?

Toujours à faire ta propagande, n'est-ce pas ?

Et puis bon en réfléchissant, ca aurait été débile de chercher à normaliser des bibliothèques spécifiques aux environnements Windows, aussi débile que si on cherchait à normaliser GTK#.

En quoi ADO.NET et ASP.NET (par exemple) sont spécifiques à Windows ? Cette partie n'est pas normalisée et est pas mal couverte par les brevets Microsoft... Et je ne parle pas de toute l'aspect web services.

T'y ajoutes comme précisé plus bas les bindings Gnome & Co, et t'as une plateforme basé sur des technos libres et/ou normalisées.

Hum. Je sais bien qu'il existe des alternatives à ADO.NET, mais c'est quand même l'outil classique pour interface une BD à un programme .NET. Or, on en a besoin sur le desktop. Quant à faire une appli serveur (orientée web services par exemple), sans se servir des api microsoft non standardisées, c'est effectivement possible, mais bon...

Mais je trouve allucinant de décider de changer de plateforme pour une autre alors qu'on a pas plus de certitude juridique sur l'autre (en l'occurence KDE).


Est-ce que tu peux donner des références de brevets qui s'appliquent de façon bloquante à KDE et pas à Gnome ? Parce qu'aujourd'hui je peux faire cet exercice sans difficulté dans l'autre sens grâce à l'inclusion de Mono dans Gnome. Si tu ne comprends pas la différence, je ne peux rien pour toi.

Oué enfin Novell + RedHat + Philips + IBM + Sony, ca fait une force juridique bien plus conséquente à mon avis, MS à côté c'est un petit challenger question brevets !

Sauf que l'OIN n'a pas vocation à utiliser les brevets de ses membres fondateurs pour attaquer quelqu'un qui s'attaquerait à Mono (ou à d'autres applications protégées). l'OIN utilisera pour ça les brevets qu'elle possède, c'est à dire 13 seulement (ils ont une portée très large, ceci dit).

Je suis bien d'accord que ca ressemble à de la dissuasion, mais tu proposes quoi de mieux comme alternatives ? Je n'en vois qu'une : supprimer ces foutus brevets logiciels. En attendant, si l'OIN peut apporter une certaine garantie...

Tu déplaces toujours la discussion. Je trouve que l'OIN est une initiative géniale, d'autant que ça va me permettre de coder en Mono sans prendre trop de risque. Ca ne règle pas magiquement les problèmes de Mono, ça les réduit, c'est tout.

qu'il n'y a pas plus de danger qu'avec un autre soft

Non, c'est que le risque est acceptable, c'est-à-dire en dessous d'un certain seuil. En dessous de ce seuil, il existe toujours des risques différents.

l'OIN a toutes les cartes pour défendre Mono, notamment des brevets clés sur les web-services.

On n'en sait rien, en fait. L'OIN a des brevets gênants pour tout le monde, mais Microsoft a beaucoup beaucoup d'argent et des brevets très emmerdants pour tout le monde aussi. C'est la dissuasion nucléaire...

Oué ca fait 10 ans qu'ont a des rumeurs comme ca.

Hum, c'est annoncé officiellement par Sun depuis le 14 août 2006, la licence sera approuvée par l'OSI, les premiers morceaux sortiront en octobre 2006, avec un jdk complet avant juin 2007. C'est assez précis, non ? Comme roi du FUD, tu te poses bien là.

Bref Mono n'est pas un cas particulier et est autant en danger/sécurité que la plupart des technos/softs libres.

Les risques liés à Mono me semblent maintenant acceptables, ça ne veut pas dire qu'ils sont au même niveau que ceux posés par Java ou Python, par exemple.

Au temps pour moi. En fait, ce que je voulais dire c'est que gif était extrêmement populaire, mais que jpeg (pour lequel il n'y a pas de brevet payant) puis le png (pas de brevet à ma connaissance) ont rapidement constitué des alternatives viables. Le cas du mp3 est moins évident car son support par de nombreux hardware fait que son concurrent ogg s'impose beaucoup moins vite que jpeg et png n'ont "remplacé" gif.

Désolé pour ce jugement de valeur sans grand fondement...

Certes, certes, on compte aussi plus de 500 brevets portant directement sur Java. La question cruciale est qui possède ces brevets, quelle est leur portée, de quels autres brevets dépendent-ils, etc. Concernant .NET, on sait que les brevets de MS ont été déposés pour assurer le contrôle de la plateforme et qu'ils sont cruciaux pour son implémentation. En gros, ils sont incontournables. Il faudrait faire une analyse précise des brevets qui couvrent le noyau linux pour en savoir plus. Pour prendre un exemple, le format gif a longtemps été protégé par un brevet, ce qui ne posait pas vraiment de problème car ce format est pourri. Par contre, le format mp3 est protégé par des brevets (incontournables) ce qui pose problème jusqu'à leur disparition (en 2010). Il y a donc brevet et brevet. Ceux dont je parle pour .NET sont potentiellement dangereux.

DotNet est une spécification ECMA et pas un jouet purement Microsoft.

Non, .NET comprend 350 casses spécifiées par l'ECMA et 3000 non spécifiées, propriétés de Microsoft.

Ceci étant je suis d'accord avec toi sur l'aspect technique. Pour moi, .NET est le Java dont j'ai toujours rêvé et Mono une implémentation très intéressante.

Ah, ah, je suis de retour de vacances, on va pouvoir troller !

Ce que j'adore avec toi, Timaniac, c'est que tu ne fais que répéter servillement la propagande de De Icaza. Jamais aucune investigation personnelle... Pourtant, chercher des brevets sur le site de l'USPTO, c'est facile http://www.uspto.gov/

Je peux donc te donner moi aussi une information vérifiable : Microsoft possède au moins trois brevets sur l'API de .NET et quatre brevets sur le coeur de .NET (aspect multi-langage, représentation des types fondamentaux, gestion de version, delegates). Deux autres brevets sur l'API de .NET sont en cours d'acceptation (il ne reste plus à MS que de payer les frais) et MS à des dizaines de demandes en cours d'examen (15 demandes avec Hejlsberg, le créateur de C#, dans les auteurs). Ces brevets sont vraisemblablement incontournables, vue leur formulation très générale.

Je termine par un peu de pub (honte à moi) : j'ai écris un nouveau pavé sur la situation juridique de Mono (et de Java) qui devrait paraître dans le numéro d'Octobre de Linux Magazine (sauf contre ordre ou manque de place, vue la longueur du bousin). Résumé de l'article : la situation de .NET et de Java est maintenant plus claire. On sait que .NET (et donc Mono) est couvert par des brevets dans tous les sens, mais qu'il est relativement peu probable que Microsoft attaque Novell pour des raisons politiques et gràce à l'OIN. On sait aussi que Sun va mettre son JDK sous une licence open source, ce qui clôt le débat.

Ben oué, et ils avaient raisons : le C est un langage qui s'interface très bien avec de nombreux langage (mieux que le C++ en tout cas)

Sauf qu'ils ne bavaient pas sur le C++ pour cette raison mais en arguant qu'un programme C++ ramait à mort par rapport à un programme C. Amusant, quand on voit les bindings python et C# (par exemple).

Au temps pour moi, j'ai beau chercher dans mes exemples de pdf merdiques, soit ils sont merdiques pour acrobat et pour kpdf (par exemple), soit ils ne le sont ni pour l'un ni pour l'autre...