TImaniac a écrit 6420 commentaires

[décuvé]
Pas les moyens ou pas le besoin? Certainement un peu des deux
Pas les moyens, j'en suis convaincu : le besoin est évident, même s'il ne concerne pas tout le monde ce genre de plateforme a des avantages indéniables, Mono ou JBoss en sont les meilleurs exemples.

Elles le sont pour moi et pour nombre de développeurs.
Je crois surtout qu'une grande partie des dev n'a pas essayer ces solutions, de par l'absence de plateforme libre dans le passé : c'est relativement nouveau dans le monde du libre, c'est d'ailleur pour cela qu'il y a beaucoup de "bruit" autour de Mono et autre Classpath.
C'est facile à vérifier : tu codes en PHP, tu essaies ASP.NET et tu reviens à PHP. C'est douloureux.

Si tu trouves que les développeurs libres ne font pas ce que tu veux, tu peux soit mettre la main à la pâte, soit retourner jouer sous windows et payer des licences.
Désolé, j'ai pas zindows sur mon PC ni aucun soft où il faut payer une licence.

Bref machin machin, de toute facon je crois qu'on a les mêmes valeurs. Le fait est que le libre n'a pas la chance d'avoir les moyens de concevoir une plateforme entière libre sur le modèle de Javaé/.NETL. C''esst bien dommage que le proprio est encore cet avantegage d'avoir le temps de concevoir dfe telle pltagefoeme et que le libre n'est que la possibilité de copier sans innovoer mais c'est un fait : ils sont un avantage technologique indusctiable. Nous avons toutes les idées, les hbommes pour coppier mais pas les moyens d'innovezr. Dommage.
BOn ben je suis à moitié tocher donc sur ce je te souhaites une bonne nuit @ plus dans l'buds :)

Mouarf. Ce n'est pas du tout parcque les développeurs du libre n'aime pas les contraintes. C'est du n'importe quoi ca. A quoi sert freedesktop.org ? Pourquoi il y a-t-il des HIG pour la plupart des desktops ? Et plus fort pourquoi y a-t-il des implémentations libre de framework proprio si ce n'est justement pas de chercher ce "graal" manquant sous Linux : l'intégration ?

Le libre ne préfère rien du tout à l'intégration. C'est juste que le libre n'a pas les moyen de gérer un framework de cette ampleur. C'est pas l'envie qui leur manque.

Et on a toujours le choix, la preuve y'a .NET ET Java. Si on suit ton raisonnement le libre devrait proposer une alternative à ces 2 là, juste pour le plaisir d'avoir le choix.

Et puis je te rappelles que l'intégration est également un gage d'interopérabilité puisqu'il faut respecter des contraintes dans les 2 cas.

Non je viens de te dire que ce n'est pas les fonctionnalités mais l'intégration, la sécurité et la productivité qui font le succès de .NET/Java. (Et des perfs décentes)
C'est quand même pas trop restrictif !
Mais le principal ecueil c'est l'intégration, construire un framework cohérent de l'ampleur de ces 2 plateformes est un boulot monstre qui est loin d'être à la portée du premier projet libre venu.

Effectivement difficile d'utiliser de l'objet avec Erlang... Mais c'est là où je voulais en venir : il est beaucoup plus facile de développer un client Java qui appelle ton serveur Java en utilisant RMI : tu ne change pas de paradigme (tu restes objet des 2 côtés) et tu utilises une techno parfaitement intégrée (RMI).
Avec Erlang d'un côté et Python/C++ de l'autre voilà quoi.

De toute façon, pour recentrer le forum, la question n'est pas intégré ou hétérogène, mais est-ce que ces plateformes libres peuvent elles répondre aux mêmes problèmes que Java/.NET avec leurs solutions à elles (intégré ou pas).
Non le problème c'est d'évoluer. Je me doute qu'on pourra toujours faire la même chose avec telle ou telle techno. Les plateforme de type .NET/Java apportent de nombreux "+", non pas en terme de fonctionnalités mais en terme d'intégration de technos dans une même plateforme unifiée, productive et sécurisée. C'est ce qui fait le succès de ces technos et c'est ce qui fait qu'elle attirent les développeurs : d'où l'apparition d'implémentation libre de ces plateformes, en l'absence de réel concurrent libre.
Donc pour rechercher une plateforme équivalente, il ne faut pas voir que la facon de créer une solution, mais rechercher une plateforme qui a les mêmes atouts qui font le succès de Java/.NET. Parcque sinon on serait resté à l'assembleur. C'est vrai quoi en cherchant bien on aurait pu tout faire avec et donc répondre à tous les problèmes.

Pour remplacer RMI, on peut faire du RPC
C'est pas du tout comparable. RMI c'est un modèle de communication entièrement objet, et vraiment transparent pour le programmeur. C'est à des années lumières question productivité de RPC.

Pour la maintenance, je ne vois pas quel problème tu auras en plus par rapport à une solution J2EE
Je l'ai dis, le support de plateformes et technos hétérogènes.

un moteur de recherche de mp3 sur le web distribué (en Erlang), une interface web en PHP et un programme en Python pour calculer un "taux d'affinité" entre une musique et un utilisateur
C'est bien ce que je dis, ca ressemble plus à du LAMP qu'à un environnement complètement unifié et intégré comme Java.

Corba c'est un protocole et un standard. Ce sont les impléméntations qui divergent.
Oué bah c'est aussi le but de Mono/.NET : proposer un standard indépendant des langages...

Et là ca ne te dérange plus de changer de techno et de langage, bizarre.
Oué bon ok. En fait il manque quelques trucs à Mono pour être à la hauteur de Java côté fonctionnalité. Même si Python a des fonctionnalités proche de Mono il reste un fossé énorme côté performances. Et même fonctionnalités. Que je sache il n'y a a aucune équivalent à ce que propose ASP.NET chez Python.

Quant aux performance le JITs c'est récent et il n'est pas exclu que des progrès soient accompli avec python aussi. Ppour ;l'instant ce n'était pas la priorité mais chaque nllle version de Cpython améliore les perforamances sans compter le projet Psyco.
Le plus rigolo c'est que l'implantation de Python la plus rapide tourne sur .NET/Mono :-p
Psycho c'est gagné en perf pour perdre en portabilité. Désolé mais ca vaut pas un bon vieux JIT.

Bref on est dans du plus pur troll.
Je crois surtout que tu n'as jamais programmer une application pour J2EE ou une application pour Mono/.NET. Tu cernerais tout seul les différences et tu aurais conclus par toi même qu'il y a un fossé entre les catégories même si certaines utilisations peuvent se recouper.

En même temps la fondation Mozilla participe à ce que tu rejettes en pétant les couilles de ceux qui veulent utiliser les noms et icones officiels dans des versions modifiées.

Tu cherches un concurrent ou une copie?
Je cherche quelque chose qui me propose de répondre aux mêmes solutions.
Donc un concurrent à Java doit me fournir une plateforme avec des API tout aussi garnies, des perfs décentes et un langage "productif".

Tu fais comment? Je n'ai pas vu cette possibilité dans Java...
Bah si tu modifies un .class lors des prochains chargements de cette classe cette nouvelle version sera pris en compte, même si des instances existent déjà.

Lesquels? Si tu n'utilises pas cette possiblité, elle ne va pas te manger!
Ca c sûr. Mais du coup je me demandes toujours quel intérêt à le langage Python, puisqu'on m'avance toujours cet argument.

Si tu en lis un consacré à Python, ils implémenteront ça d'une autre façon.
Euh désolé j'ai jamais lu de bouquin de DP appliqué à Java. Le plus fameux, le GoF fait référence au C++.
Trouve moi un livre consacré aux DP en Python. Le modèle objet de python est vraiment pas beau à voir, on sent bien que c'est un "rajout" bricolé.

Tu proposes un cluster parcque tu sais pertinement que Erlang a des perfs pitoyables ? :-)

Maintenant tu me proposes quoi pour remplacer JSP et les web-services ?
Tu me proposes quoi pour remplacer RMI ? Me dis pas que tu comptes faire du RPC avec ton client lourd en Python/C++ quand même :)

Non sérieusement c'est joli ton truc, mais paye ta maintenance : des technos par forcement compatibles avec des langages hétéroclyte, ca va être facile à maintenir tout ca dis donc.

Tiens d'ailleur tu me montres un exemple d'utilisation de ta combo qui tue ?

RMI c'est bien parcque c'est intégré au langage et ca supporte complètement Java. Corba c'est rigolo mais c'est intégré dans rien du tout. C'est tellement bien que c'est c'est une des raisons qui a poussé Icaza à faire Mono.

Bref tu considères que le tout intégré c'est la panacée mais c'est aussi la contrainte d'où le succès grandissant des solutions LAMP
Tout à fait : ca boxe pas dans la même catégorie, pour certains trucs Java est pas adapté et inversement, mais à par C# j'en connais aucun qui rivalise Java dans son domaine de compétence.

il s'exprime pleinenent sur le poste de travail car il s'intègre bien avec tout un tas de toolkit.
Oué mais là ca n'a pas plus d'intérêt que C#/Mono qui a les mêmes avantage. Désolé mais je n'arrive vraiment pas à voir ce que Python a de plus. Je vois très bien ce qu'il y a en moins mais pas en plus.

Quant aux parts de marché, Zope n'est pas soutenu par les mastodontes commme IBM BEA Sun & Co donc forcément ca ce ressent
S'il Zope n'est pas soutenu il y a peut être aussi une raison. IBM aurait très bien pu se tourner vers autre chose que Java.

Sauf que ce que j'explique c'est que c'est en train de changer.
Zope ca fait des années qu'on en parle, n'empêche que le soufflé est vite retombé. J'ai du mal à voir comment il va remonter :)

Pour la charge, ben c'est pas le langage Python qui va aider, ca n'a jamais été une foudre de guerre hein ;)

Zope/Plone/Python est une bonne alternative qui aurait pu figurer dans cette étude.
Cela dit que je suis d'accord qu'il aurait été intéressant d'avoir d'autres plateformes dans cette comparaison. Mais ne perdons pas de vu que le document vise avant tout à apprécier l'impact des brevets logiciels sur des implémentations libre de framework proprio.

Ca dépend, comme souvent pour ce genre de grosse applis, si t'as une architecture classique n-tiers avec plusieurs "interfaces" classiques : un client lourd (typiquement RMI), un client "web" (JSP) d'autres clients web (web-services), je suis pas du tout convaincu que Erlang sera tout aussi pertinent.
Il suffit pas de savoir gérer les transactions, il faut savoir "tout" gérer. Ce qui fait de Java une usine à gaz pas toujours utile (d'où le nombre important de plus "petits" projets écrits dans des frameworks moins "lourd" comme PHP ou Python), mais qui fait aussi que Java est un des seuls à boxer dans sa catégorie.

Ah oui et puis erlang il a beau gérer les transactions, quand tu vois les perfs du langage tu pries pour qu'il n'y est pas trop de monde à faire mumuse avec le serveur ;)

Héhé boubou ca tu peux je rajouter dans ton document ;)

un tableau qui montre clairement que Python n'a pas du tout de plateforme unifiée pour faire serveur d'application.

Ton document reprends point par point les technos J2EE en tantant de trouver un équivalent en Python. On s'en fou qu'il y est un remplacant point par point, il faut un remplacant global capable de remplacer l'ensemble. Le jour où y'aura une plateforme complète et unifiée capable de faire tout ce que fait Java alors je dirais ok.

Enfin visiblement le marché me donne raison : les parts de marché de Zope (qui existe quand même depuis un certain temps) sont ridicules.

Ah oui au fait c'est quoi l'équivalent de RMI en Python ?

Ecoutes, j'essai de montrer que l'intégration est un atout, je dis pas qu'il n'y a pas d'autres solutions. Donc quand je dis qu'il n'y a pas de plateforme équivalente à C#/Java je parle aussi de l'intégration.

Tu mélanges un peu tout:
Je mélange pas, je prends plusieurs caractéristiques.

le typage fort est bien pour détecter les erreurs à la compilation, mais le typage de Java n'est pas non plus super contraignant
C'est toujours mieux que Python, même si ce n'est pas aussi bien que les contrats en Effel. Seulement Effel n'a pas tous les APIs de Java. Tout est une histoire de compromis. Je demande un concurrent à Java ou C#, il faut choisir, tu ne peux pas dire une fois : Python gnagna et une autre fois Effel gnagna.

(Moi j'en vois un: mettre à jour un programme sans l'arrêter.)
Ah parcqu'en Java on est obligé d'arrêter le programme ?
Désolé mais d'une manière générale cela n'a quand même que peu d'utilité dans la pratique, et pourtant quand je demande : et qu'apporte Python ? On me ressort systématiquement cette possibilité. Pourtant moi j'y vois surtout des inconvénients.

- quel est le rapport entre la notion d'interface et la sécurité?
Avec les interfaces tu peux déjà mettre en place une première notion de contrat : une interface n'est rien d'autre qu'un contrat quand aux APIs exposés par une classe. C'est loin de Effel mais c'est déjà fort pratique. Il suffit de lire un bouquin de design pattern pour s'apercevoir que beaucoup de collaboration font appelle à des interfaces. Les interfaces font cruellement défaut à Python.

Ca va faire plaisir à tous ces gens ce que tu dis
Ma phrase n'avait de sens que dans son intégralité. Je vois même pas l'intérêt de ta remarque puisque tu est d'accord quand je te parle de transactionnel.

En plus ce sont peut-être pas les mêmes niches de marché.
C'est ce que j'explique : Python est loin d'être pertinent dans toutes les utilisations, et de ce fait ne couvre pas la même chose que Java ou C#, et donc ne boxe pas dans la même catégorie. CQFD.

Pour Python, il me semble qu'il existe plusieurs solutions de persistence et donc il doit y avoir de quoi gérer les transactions.
Vois pas le rapport. Java propose un ensemble d'API standards pour serveur d'application qui gère tout de A à Z. Il n'y a rien de comparable en Python.
Quand au bench Python vs Java, Python utilise plus de mémoire mais est nettement plus lent, plus de 15x plus lent dans certains tests. Ca se passe de commentaire. Fait le même temps en comparant Python à C# pour rire.
Erlang n'en parlons pas.
Php encore moins.

Même si tu vas trouver des API à droites à gauche pour tel ou tel langage, ce qui fait la force des plateformes associés à C#/Java c'est l'uniformité et l'intégration de ces APIs : ce n'est pas un assemblage de briques hétéroclyte mais un ensemble cohérent.

Pour ce qui est des IDE, il existe aussi un plugin C# pour Eclipse, mais autant dire qu'il n'y a aucun rapport entre faire du Java avec Eclipse et utiliser un autre langage dans Eclipse.

C'est pas pour autant que c'est pertinent.
Python est lent, pour un site web j'espère que tu n'as pas 100000 utilisateurs avec gestion de transactions. Et dans ce genre de cas tu aimes bien avoir un minimum de sécurité et de qualité. Désolé mais le côté "laxiste" du langage Python ne va pas du tout dans ce sens.

Que je sache en PHP tu peux te toucher pour espérer faire un serveur d'application. PHP ne se suffit pas lui-même il lui faut communiquer avec un autre langage.

Tous les langages ont pratiquement des APIs dans tous les domaines, c'est pas parcque les APIs sont dispos que la plateforme qu'il est pertinent de les utiliser.

Sans parler des perfsn, on peut aussi parler du langage en soit : question sécurité Python n'offre rien du tout : pas de typage fort, la possibilité de modifier dynamiquement une classe, pas de notion d'interface, que des trucs rigolos mais parfaitement inutile dans un cadre industriel.

Python est avant tout un langage de script, il n'a pas la même vocation que Java ou C#. On aura beau proposer des API similaires à Java il y aura toujours ses choix de conceptions qui en feront un mauvais choix dans des contextes ou la qualité et la sécurité sont prédominants.

System.Collections c'est pas dans le standard, peut être ?
Euh System.Collections n'a strictement rien d'innovant, ils peuvent toujours essayer et obtenir un brevet, un prior art sera facile à démontrer.

Ce document indique explicitement qu'une implémentation de Jave en open source est possible, sans enfreindre les brevets associés
Aujourd'hui mais demain ?

On ne sait pas officiellement pourquoi.
C'est bien pour ca que je prends pas leur avis en compte :) La plupart des autres distributions ont intégrés Mono, seul RedHat fait de la résistance sans donner d'explication.

La situation est radicalement différente pour .NET : on ne sait pas si une implémentation open source est possible car aucun document en valeur légale n'est disponible publiquement concernant ce point.
Ah non !
A l'heure actuelle il n'y a absolument rien qui empêche une implémentation libre de Mono, MS n'a pas donné son autorisation et n'a pas à la donner : il n'a pas encore les brevets pour le protéger.
Donc peut être que demain MS fera chier. Aussi vrai que peut être que demain Sun fera chier. Donc c'est exactement pareil. Surtout que les brevets MS peuvent s'appliquer à Java.

Imaginons qu'un des brevets soient violer dans Java par Sun, Sun et MS ayant passé un accord ils ne s'attaquent pas mutuellement, mais MS demande à Sun de plus autoriser l'utilisation des brevets en question dans des implémentations libre. que pasa ?

Oué pour SenderID effectivement le rapprochement est valable vu comme ca.

Pour Samba c'est quand même nettement plus tiré par les cheveux.

Le vrai problème c'est qu'on n'a pas d'engagement à valeur légale de MS sur la partie standardisée et que les engagements du passé sur d'autres technologies sont soit incompatible avec toutes les licences libres, soit incompatibles avec la GPL.
Oué enfin en l'occurence seul le compilo est sous GPL, et je vois pas quel brevet va empêcher Mono de parser un fichier C# pour produire du code...

Le vrai problème c'est qu'on n'a pas d'engagement à valeur légale de MS sur la partie standardisée
Là on est d'accord, c'est pourquoi on discute justement des intentions :)
Enfin ce que raconte un MSkyLight2 à propos des engagements à propos de l'ECMA est intéressant je trouve. Novell faisant parti du commité de normalisation ils sont je penses bien placés pour connaître les risques éventuels. Ce qu'ils traduisent dans leur FAQ.

Enfin ca me fait bien marrer quand même le coup de "c'est pas compatible avec la GPL". De toute façon beaucoup s'accordent à dire que les brevets logiciels sont incompatibles avec la GPL, alors même si Sun "autorise" l'utilisation de ses brevets j'ai des doutes sur la réelle "immunité" des programmes sous GPL. Il est intéressant de noter que même si Sun autorise actuellement l'utilisation de ses brevets ils peuvent à tout moment changer de licence, les implémentations actuelles seront toujours valides (une licence acquise l'est définitivement) mais elle remet en cause de nouvelles implémentation ou des travaux dérivés des implantations existantes (ce qu'autorise la GPL).
N'oublions pas que Sun a passé des accords avec MS, que Sun a toujours fait preuve de grandes contradictions quand à leur soutien aux logiciels libres. Un changement de licence est donc tout à fait possible, même si je n'y crois pas trop à court terme.

Enfin n'empêche que tous ces brevets peuvent s'appliquer à d'autres plateformes, et que ces autres plateformes sont donc toutes aussi dangereuses à utiliser, pas moins que ne l'ai Mono.

Je ne vois pas ici d'argument montrant que .NET sera sous licence royalty free, même pour la partie CLI/C#.
C'est pas ca que j'ai essayé de montrer. J'ai essayer de montrer que MS cherchait à utiliser des "standards" technique pour faciliter l'interopérabilité (tous leurs discours actuels vont dans ce sens). Après ils cherchent à protéger leur valeur ajoutée, ce qui fait leur spécificité. D'où la comparaison avec .NET.

Va voir par exemple la licence pour les schémas d'Office.
Pour moi Office c'est la valeur ajoutée aux normes XML au même titre que WinForms/ASP.NET est la valeur ajoutée aux normes CLI/C#. Donc de ce point de vue je te rejoins.

en gros, ce qu'on ne retrouve pas dans d'autres langages comme les parties unsafe
Oué mais là j'ai pas vu de brevet à ce sujet.

L'expérience montre que Sun est prêt à défendre Java et les licences officielles.
Bof même pas besoin de le supposer. MS et Sun ont passé des accords pour ne pas s'attaquer mutuellement donc de ce côté y'aura pas de problème. Par contre MS pourrait attaquer une implémentation libre de Java au même titre que Kodak pourrait attaquer JBoss. Bref c'est aussi dangereux.

Il y a tous les faits que je connais. Tu voudrais ajouter quoi ?
Je voudrais virer les exemples sur SenderID ASF et Samba alors que les objectifs et intérêt de MS ne sont pas du tout les mêmes. C'est un exemple parfait de comparaison foireuse pour conclure sur autre chose.

Je voudrais que tu conclues en disant que le vrai problème est dans l'utilisation des API spécifiques à Microsoft non normalisés, que c'est cette partie que MS cherchera à protéger. Cela enlèvera à Mono un atout : la compatibilité avec de nombreux API MS. D'où l'idée de n'encourager l'utilisation que des parties normalisées et des API spécifiques à Mono.

Mais bien sûr.
Blablabla, je préfères m'en tenir à l'interprétation de Novell. Eux n'ont pas le problème de la traduction et sont surement plus compétent que moi (toi je sais pas) pour interprêter ce mail.

Ne trouve tu pas étrange que le site web de MS qui contient de nombreux modèles d'accord de licence n'en propose aucun pour .NET ?
Y'a rien d'étrange, ils ne vont pas faire un document officiel sur un brevet qui n'existe pas encore.

Enfin, obtenir une licence royalty-free ne signifie en aucun cas que tu pourras redistribuer une implémentation open source
Là encore je me réfère à la FAQ de Mono : eux ont compris "any purpose". Là encore je préfère m'en tenir à leur interprétation.

Dans une révision de mon article, je remplacerais toute l'API par une grande partie de l'API, ça sera plus prudent.
Il serait tout de même judicieux que tu précises que cela concerne sûrement les API non normalisés, en précisant qu'il est impensable de protéger par un brevet les API normalisés (prior-art, pas innovant, etc.)

Le problème est qu'il suffit de ne pas pouvoir implémenter UN appel de méthode ou UNE classe pour que tout tombe à l'eau.
Pour peux que la méthode soit aussi présente dans son cousin Java et t'as exactement le même problème. A l'exception que MS pourrait attaquer les dev de cette implémentation car n'étant pas dans le cadre de la mise en place d'une CLI/CLR. Là l'implémentation Java serait même plus risquée ;)
Au pire Novell l'a dit : on vire le truc en question et basta.

il n'y a aucune raison pour que MS ne défende pas très fortement .NET. Et d'ailleurs tu le dis toi même au sujet des API non standardisées.
Tout à fait, je penses comme toi que le problème viendrait surement de la partie non normalisée. Au pire on s'en passe et basta Mono perdra une bonne partie de la compatibilité mais on aura toujours une plateforme complète avec l'interopérabilité technique de base, essentielle au développement d'API multi-plateforme. Tant pis si ceux de MS ne le sont pas.

Et au fait, ASF n'est pas un codec mais un format de fichier...
Oué oué oué enfin ASF c la plupart du temps associé aux codecs WMV, et si mes souvenirs sont bons VirtualDub s'est fait enmerder pour l'ensemble, pas juste le format d'encapsulation.

Ce n'est pas la même chose.
mais ca rend tout de même l'utilisation du noyau illégale et une entreprise (au pif MS) peut y voir une concurrence et attaquer. Pour .NET si les brevets sont utilisés pour implémenter les standards MS n'y a que des avantages, par contre ils peuvent attaquer en qu'à d'utilisation dans une autre utilisation (genre dans Java ?)...

Et alors que tu te gargarises de documents sans valeur légale
Genre les tiens sont légals :)

Tu te caches derrière Novell qui "a étudié les brevets en question", etc. N'es tu pas capable de lire les brevets et de te faire une opinion ?
Ben j'avoue que le jargon technique voilà quoi. y'a aussi la barrière de la langue qui fait que c'est facile de donner un autre sens en traduisant. Je préfère traduire la vulgarisation qu'en a fait Novell qui a au moins virer la barrière du jargon juridique.

Puisque que tu aimes les arguments d'autorité, pourquoi croire plus Novell que RedHat ?
Parcque Novell dit : "on a étudié, on a rien trouvé d'enmerdant"
RedHat : "oué on sait pas trop ce qu'il en est, dans le doute on fait pas".
A noter qu'en plus il n'y a pas de position officielle de RedHat, seulement d'un ou 2 développeurs, alors que la position de Novell est la position officielle. Autant dire que pour moi cela n'a pas du tout la même valeur.

Enfin tu ne m'expliques toujours pas pourquoi MS a normalisé et standardisé les bases techniques de sa plateforme, tu ne m'expliques pas pourquoi ils ont diffusé une implémentation pour montrer comment faire, tu ne m'expliques pas pourquoi MS n'a jamais râlé sur Mono et l'a au contraire encensé.
Tu dis que je refuses d'apprendre le passé. Toi tu prends des citations d'il y a 3 ans et tu refuses de constater les faits.

Moi je cherche juste à montrer qu'il n'est pas plus dangereux d'utiliser Mono qu'autre chose.