TImaniac a écrit 6420 commentaires

On peut voler l'argent et le rendre aux pauvres, cela rend-il le délit moins mauvais ?
Faut oser, dire qu'on vole au riche pour donner aux pauvres alors que leurs richesses sont basés essentiellement sur l'exploitation des ressources (naturelles et humaines) de ces mêmes pauvres...
Quand à déclarer le monopole de MS comme illégal/délit ca me fait doucement rire... Ce monopole c'est le système économique dans lequel nous vivons qui l'a créé, MS est un produit de la société et non une tentative d'un seul homme d'enfreindre les lois (le côté illégal, délit toussa).
Comme dirait l'autre : monde de merde.

Pour ceux que ca intéresse :
http://www.microsoft.com/interop/osp/default.mspx

surtout qu'à vue de nez, le code pour passer de F# à C# n'est pas monstrueusement plus pratique/sympathique que celui pour passer de Ocaml au C.
L'intérêt, c'est qu'un wrapper écrit en C# est portable (pas de code natif, rien à recompiler en changeant de plateforme).

Sinon c'est clair que F# n'est pas aussi puissant que OCaml et aussi rapide. Alors quel est l'intérêt de F# ? La réponse est dans leur FAQ, que je vais essayer de traduire :
Quels sont les objectifs de F# ?
Une façon de voir les choses est de considérer que F# tente de résoudre les 7 problèmes majeurs décris dans la publication classique de Wadler : "Pourquoi personne n'utilise les langages fonctionnels ?" : Bibliothèques, Portabilité, Disponibilité, Facilité de déploiement, Outils, Entraînement et Popularité. Parmi ceux ci, F# résoud le problème des bibliothèques (en donnant accès immédiatement à des centaines de bibliothèques .NET de haute qualité ne nécessitant pas de wrapper), la portabilité (le bytecode .NET est portable, par exemple le projet Mono en donne une implémentation sur de nombreuses plateformes), déploiement (les assemblies .NET sont un excellent système de déploiement) et les outils (les outils pour .NET marchent également avec F#).Les autres problèmes sont en partis résolus par le fait que F# a un coeur conçu de la même manière que celui d'Ocaml, une implémentation de langage fonctionnel populaire pour lequel un bon nombre de document d'apprentissage sont disponibles, ainsi que pour la plateforme .NET où l'on trouve de nombreux document d'apprentissage sur le web.

En gros F# n'apporte pas grand chose au langage proprement dit par rapport à OCaml (comme tu le soulignes, la grammaire est la même, en moins bien supporté), mais apporte de nombreux atouts sur tout l'environnement. Il est ainsi facile d'écrire un module d'un projet .NET en F# sans que les problèmes techniques d'intégration habituels entre environnement différents apparaissent.

Pour info, le projet F# a été lancé avant ce labo commun entre Inria et MS (la version 1.0 date de janvier 2005). Le projet F# est un projet interne à MS visant à prouver que leur framework .NET peut supporter de nombreux langage, en l'occurence un langage de type fonctionnel (ML), au même titre qu'ils financent IronPython, une implémentation de Python visant à montrer que les langages dynamiques peuvent aussi s'y intégrer.
Bref si tu veux mon avis, avec ou sans ce partenariat, F# existe.

d'un côté je ne suis pas sûr que ce soit un bug de firefox, mais plutôt une fonctionalité...
C'est une fonctionnalité... mais mal implémentée, et qui introduit un bug, et pas des moindre.

Et puis le système de point n'est pas là pour donner son avis mais pour mettre en avant les commentaires pertinents et cacher les commentaires inutiles.
Ben t'as tout de suite pensé que t'avais dis une connerie, donc c'est que t'as très bien compris le système de notation :)
Le système de notation sert à tout : si c'est une blague, les gens vont dire si c'est drôle ou pas, si c'est une info, ca va être sa véracité, si c'est un avis son côté intéressant, etc.
On a débattu pendant longtemps du texte à mettre pour les boutons permettant de voter, mais globalement les gens s'en servent en fonction du résultat du vote : le post est caché, ou pas. Après suivant le contexte, on donne une info (pas forcement la pertinence effectivement) aux autres lecteurs : lisez ce post ou n'y pensez même pas. Voili voilou :) A toi de juger de la pertinence de ce post (attention, une blague subtile s'est caché quelque part dans ce commentaire, ainsi que 3 trolls et une fausse info :-p )

Ben c'est un état de fait, certes, mais c'est surtout un gros bug de Firefox. Je suppose que c'est pour ca que beaucoup on juger que c'était une connerie de ta part de préférer voir ce comportement :)

Oui, au sens où Firefox peut effectivement s'adapter à l'espace mémoire disponible, mais il doit s'adapter dans les 2 sens : c'est de sa responsabilité de libérer de la mémoire lorsque le système n'en a plus assez. Il devrait toujours s'arranger pour laisser un pourcentage de mémoire disponible pour ne pas pénaliser les autres applications. Alors en attendant de savoir gérer correctement la mémoire, Firefox devrait s'abstenir complètement de "prendre ses aises", parcque ca devient vite inutilisable pour peu qu'on fasse autre chose que naviguer sur le web en parallèle.

Ben à priori Free propose de mutualiser son réseau, et apparement ils utiliseraient les égoûts de la ville de Paris... Tu proposes quoi comme solution moins "anarchique" ? On démolit la ville, on retrace tout en rue perpendiculaire avec maillage systématique en fibre optique sans la moindre redondance ? Et dans 10 ans ton zoli modèle il évolue comment ? Tu ressors le buldozer ?

Les programmes télés, ca se paie, ils ne sont donc accessible(s) nul part gratuitement sous une forme "exploitable".
XMLTV essai de contourner le problème, le grabber FR scannant le site de telepoche, faute de mieux, et je ne suis même pas sûr que ca soit légal.

9Telecom c'est mieux (dans le sens plus fiable) ?
Bof, j'ai le même genre de retour d'expérience (inscription qui dure des mois, hotline injoignable, lenteur, etc.).

Ils font pas de téléphonie eux ?
Oui, y'a une offre du même type à 35 euros (sans abo FT et téléphonie illimitée). Seul différence par rapport à Free : visiblement c'est pas dispo dans toutes les zones (même non dégroupées !)

pis dans l'absolu il n'a pas un accès à internet pour pouvoir s'enregistrer sur free, même si je peux le faire à sa place
C'est le but recherché par Free, qu'un geek le conseil, face son inscription et le suivi de son inscription à sa place ;)

Non, abo FT non obligatoire chez Free et Neuf Telecom. (offre "ADSL Nu")

La seule et unique bonne raison de prendre free en non dégroupé c'est de parier d'être dégroupé a terme
Euh, en zone non dégroupée, Free garde quand même l'avantage d'intégrer la téléphonie illimitée associée à l'absence d'abonnement FT (offre Freebox Only), ce qui reste le moins cher par rapport à tous les concurrents. Sachant que le pékin moyen qui glande sur le net, check ses mails, papotte sur MSN et téléphone à mamie, ca me paraît loin d'être nulachier en non-dégroupé.

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.
Ca c'est ton avis que je ne partage pas.

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.
Alors celle là elle est facile ! Il dit pas la même chose que moi, donc il désinforme ! Moi je suis persuadé qu'il n'est pas plus risqué d'utiliser Mono que d'utiliser Python ou une autre plateforme de dev. T'as le droit de pas être d'accord, d'argumenter, mais franchement l'argument de la propagande, c'est vraiment bas.

Dans les faits, les applications développées pour Mono utilisent certaines api microsoft non standardisées
Certes, mais ces parties sont pour moi loin d'être au coeur de Mono, et loin d'être vital à mon sens.

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.
Ca peut effectivement être un avantage, mais on standardise pas pour ca, j'espère que tu en conviendras.

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...
Pourquoi blablabla ? Tu t'es senti obligé de rappeler le nombre de classes normalisées par rapport au nombre non normalisé, sans évidemment préciser que les 350 normalisées sont les classes essentielles à l'interopérabilité du socle technique. Moi j'ai juste voulu rappeler pourquoi seulement ces classes sont normalisés et pourquoi les autres ne le sont pas, ce qui change pour moi complètement ce qu'on doit déduire du rapport que tu présentes.
Enfin bel évitemment, au passage je te décris comment sont implémentés les web-services, je te montre que l'implémentation est instrinséquement lié aux mécanismes du CLR qui lui est normalisé. Mais non c'est du blabla.

Une fois qu'un délit est commis, on est puni même si on dit qu'on est désolé.
On est d'accord. Celà dis Novell a explicitement dit qu'ils prennaient à leur charge d'éventuel problème justement liés à leur implémentation. Je suis bien d'accord avec toi que pour un projet qui fork ou autre, cela peut être plus dangereux.

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.
Franchement j'en ai lu quelque uns, je sais pas toi mais perso le blabla des brevets peut être interprété de tellement de manière, sans doute n'est-je pas l'habitude de lire ce genre de document.

Pour être compatible .NET, Mono doit les implémenter de cette façon et c'est ce qui est fait actuellement.
Pourquoi "doit" ? Le code utilisateur n'incorpore rien en relation direct avec les web-service ci ce n'est un attribut de classe/méthode. L'implémentation est purement interne à la plateforme.

oute 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.
J'ai du mal à capter comment tu peux affirmer ce genre de truc. T'as analysé les milliers de brevets pour voir leur impact sur les autres plateformes ? Ce que je constate c'est que Mono implémente une techno issu de MS, que de nombreux détracteur de cette "source" technologique sont allé cherché les brevets déposés par MS à l'occasion pour en faire une analyse des risques. Moi je dis ok c'est très bien, mais en quoi tu peux affirmer que le risque est plus important qu'avec les autres plateformes ? Ah oui y'a pas eu d'analyse avec les autres plateformes, donc le risque est moins important c'est ca ?

Parce que ça montre qu'en utilisant l'api en question, on prend plus de risques qu'en utilisant une autre api.
Vois pas le rapport, moi je voulais juste montrer que Novell détenait des brevets enmerdant pour MS. Ta précision n'y change strictement rien, même si je te remercie pour les détails.

Donc les brevets sont peut être gênant pour une partie de Vista, mais il ne faudrait quand même pas rêver.
Certes, mais je voulais souligner le fait que si le(s) brevet(s) est enfrein par le framework .NET lui même, Novell tient la une bonne contre-attaque.

Moi ce que je vois, c'est que Mono est soutenu par Novell, c'est pour moi un gage juridique contre d'éventuelle attaque de brevets, gage que d'autres plateformes n'ont pas toujours (ce qui peut être très enmerdant). Que tu soulignes les brevets c'est très bien, mais pour moi lorsqu'ils sont anhihilés par une stratégie derrière, ils deviennent beaucoup moins dangereux que l'inconnu juridique en matière de brevet qu'on a sur d'autres plateformes.

J'espère que tu es conscients que je n'essai pas de tromper mon lecteur, que je n'ai seulement pas la même vue du niveau de dangereusité des brevets sur Mono que toi.

Qu'est-ce que change le fait que X ou Y soit breveté à la situation de Mono ? Rien du tout.
Ca change tout au contraire ! (Sinon je le dirais pas :) )
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é". 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".

C'est une méthode typique de la propagande.
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. 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. Si je suis Wikipedia, je dois faire un truc comme ca :
"Dans le langage commun, la propagande équivaut à la désinformation mise au service d'une cause politique d'intérêts privés."
Je ne désinforme pas, pas comme ceux qui sous-etende d'utiliser autre chose en "oubliant" de dire que c'est aussi dangereux.

Tu remarqueras que je te réserve cette remarque car depuis qu'on trolle sur .NET ta méthode n'a toujours pas changé.
Merci de t'apercevoir que je suis cohérent et que j'ai pas changé mes idées, comme quoi j'y crois.

e ?). Par exemple tu prends F-Spot et tu vois qu'il utilise par exemple System.Web qui n'est pas standardisé.
Euh... oué et ? Quel intérêt de standardisé System.Web ?

. 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
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.

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.
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.

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...
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,

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.
Merci de rappeler où est l'interopérabilité dans les web-services, et où la normalisation a un intérêt.

Rien n'empêche une entreprise de breveter une API de création d'un serveur ou d'appel à un service
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.

Et voilà, toujours aussi imprécis (et faux).
Oué c'est faux si tu veux, t'as raison, ils ont des brevets qui couvre une parti seulement des web services. Et ? Pourquoi tu discutes d'un détail comme ca ? 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).

et en plus, ça ne concerne qu'une infime partie de l'api de .NET qui n'est pas standardisée.
Infime mais vitale, t'as vu comment ils utilisent les web services à fond dans Vista ?

C'est juste une question de cohérence technique du projet et d'empreinte mémoire du desktop Gnome.
J'ai l'impression que t'as à des gros à priori techniques, et tu sembles persuader que cela impact négativement l'expérience utilisateur.
Faut bien voir que l'on parle d'appli Gnome, qui utilise donc les API du framework Gnome/GTK/GStreamer&Co. Globalement si tu fais une appli en C# et une autre en Python, le point commun, ca sera ces libs. Si tu as fais des cours d'optimisation, tu réfléchiras pas 2 fois, tu iras droit à l'essentiel : faut optimiser le code le plus utilisé et le plus réutilisé, chercher à améliorer le reste ne t'apportera qu'un gain dérisoir à l'échelle du système (globalement).
Voilà, c'est sans doute pourquoi l'équipe de Gnome s'attache en ce moment à améliorer les problèmes de perf de Gnome et GTK, parcque c'est pertinent, tout en acceptant des appli écrites dans divers langages, car c'est également pertinent de faire évoluer le desktop.

L'équipe qui s'occupe de choisir telle ou telle appli est beaucoup plus pragmatique que toi : ils vérifient ses performances concrêtement. Tomboy bouffe-t-il un max de ressources par rapport à ce que l'appli est censé faire ? Faut-il mieux avoir une empreinte mémoire légèrement plus grande que sticky (je dis n'importe quoi j'ai pas vérifié) et offrir un soft aux fonctionnalités/ergonomie plus intéressante ?
Ca ce sont les vraient questions. Je vois pas l'intérêt de se poser une question du genre : "est-ce en Python ou en C ?" Si c'est non, poubelle, quelque soit les qualités du soft et sa consommation de ressources. Yooupi, on a plus qu'à attendre que quelqu'un d'autre réinvente la roue dans les unique langages autorisés, et si personne ne le fait ben tant pis Gnome n'évoluera pas.

Toujours à faire ta propagande, n'est-ce pas ?
Pourquoi systématiquement cette remarque à 2 balles ? Tu préfères par dénigrer systématiquement ton interlocuteur quand t'es pas d'accord avec lui ?

En quoi ADO.NET et ASP.NET (par exemple) sont spécifiques à Windows ?
Euh, c'est ca que t'appel une lib "de base" ? 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.
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 je ne parle pas de toute l'aspect web services.
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. 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.

Non, .NET comprend 350 casses spécifiées par l'ECMA et 3000 non spécifiées, propriétés de Microsoft.
Le plus important dans l'histoire, c'est que ce soit les 350 classes de base essentielles. 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.
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#.
La normalisation du CLR/CLI et des classes de base est là pour fournir un socle d'interopérabilité, c'est ce qu'a voulu Microsoft et ce qu'a fait Mono.

Ce que j'ai voulu dire, c'est que ce n'est pas une barrière technique, et qu'elle peut sauter. La preuve, même si ce n'est pas intégralement fait dans Mono, c'est en bonne parti fait.

Pour Python si tu l'dis je te crois. Mais si les équipes de Mono y arrive, je vois pas pourquoi celles de Python n'y arriverait pas. Où alors c'est que la plateforme est vraiment mal conçu pour ca, et ca sera tant mieux si on a justement une alternative à Python :)

Je pense que tu cernes mal la situation. Evidemment, dans l'idéal, un seul framework avec un seul langage, c'est plus élégant.

Cela dis Gnome n'est pas une société comme Microsoft qui maîtrise parfaitement de A à Z ses softs. La situation est totalement différente : Gnome fourni un framework de base, des bindings, des types liés à Gnome ou non développent des applis avec leur outils préférés. Arrive un moment où ces applis deviennent "Hype" et où les gens se disent "ah oué ca serait cool de l'avoir dans Gnome". Donc effectivement, soit t'es cohérent, tu imposes un langage, et tu prends tes doigts et tu réinventes la roue (youpi). Auquel cas d'ailleur tu te fais même pas chier à faire des bindings, tu laisses ca à des personnes extérieures à Gnome. Où alors tu peux aussi être cohérent d'une autre manière : tu délivres des bindings, ce qui inévitablement conduit à des appli intéressantes les utilisants, et là tu les accepte quand elles sont intéressantes.

Mais est-ce que Gnome doit avoir, par défaut, des applications dans tous ces langages ?
Gnome est modulaire, ces applis ne sont pas indispensable à la plateforme, libre aux distributions de délivrer Gnome avec les packages qu'ils souhaitent.

La non discrimination des langages c'est bien beau mais ce qu'on attends du board de la fondation Gnome c'est qu'elle fasse des choix techniques corrects et pertinents pour le futur.
De ton point de vu ce sont des mauvais choix, on l'a compris. Mais tu crois que de leur point de vue ils ont fait le mauvais choix ?? Pour le futur justement parlons-en, si Gnome était limité au C, ca veut dire que dans 20 ans on serait encore à faire des appli desktop en C ? Et Python ? Ne sera-t-il pas périmé dans 20 ans ? Gnome suit les évolutions techniques pour justement ne pas être délaissé dans le futur parcque marqué par les développeurs comme "obsolete". Moi ce que j'attend de Gnome c'est un Desktop complet et utilisable, si de nouvelles applis à l'ergonomie intéressantes (c'est le cas de Tomboy ou F-Spot) apparaîssent, je m'en syphonne de en quoi elles sont coder, si elles améliorent l'expérience de l'utilisateur de Gnome, c'est le principal.

R un et un seul langage de haut niveau afin d'éviter la situation absurde décrite ci-dessus.
Bof, ca c'est toi qui trouve que c'est absurdre, visiblement le board de Gnome a majoritairement estimé que ca ne l'était pas.

Le problème c'est qu'on ajoute des dépendances et que ces dépendances vont entrainer l'arrivée de nouveaux logiciels par défaut (F-Spot à coup sur)
Bah oué et ? Vas-y, code C-Pot ou Python-Pot ! Gnome choisi les applis en fonction de leurs qualité (vis-à-vis de l'esprit Gnome), que le meilleur soft gagne, et l'expérience utilisateur n'en sera que meilleure ! Et ne me parle pas d'absurdité technique, les performances de l'appli sont prises en compte quand il faut choisir un soft.

sans qu'il y ait eu un choix clair pour le langage de haut niveau.
Oué et c'est justement ca que j'aime dans Gnome pour les développeurs : c'est ouvert au niveau des langages, et c'est tant mieux, ils peuvent ainsi attirer plus de développeurs qui y retrouve ses outils préférés, ce dont Gnome a fortement besoin.

Dans tous les cas, libre à toi de ne pas utiliser ces appli, ca te prend 30 secondes après install pour virer mono et l'ensemble des softs en dépendant, et hop tu te retrouveras avec le Gnome de tes rêves. Dans 10 ans ton Gnome aura pas beaucoup bouger, alors que celui des autres aura peut être pleins d'appli intéressantes à utiliser.

Mais imposer un langage de haut niveau, c'est aussi prendre des risques... En choissant le C y'a 10 ans, ils en savent quelque chose que ce genre de choix ne se fait pas à la légère !
Imposer un langage de haut niveau, c'est fermé la porte à de nombreux programmeurs et donc programmes, sans rien apporter du tout : la solution actuelle te laisse le choix, la tienne ne fera pas venir plus de programme et Gnome n'évoluera pas. Ca c'est préparer le futur.

Un bon conseil : pense à l'expérience des utilisateurs, c'est tout ce qui importe, qu'il soit devant son bureau Gnome à cliquer, où qu'il soit dans son IDE à utiliser les API.

Non, t'en as 1 par appli python ou c#.
Une machine virtuelle n'existe que pour le développeur. En effet il peut partir du principe qu'il y a une isolation stricte du matériel mais aussi de sa mémoire avec les autres applis, une machine virtuelle donc. Après techniquement y'a des libs qui sont chargés à l'exécution, et ces libs sont comme toutes les autres libs, elles sont partageables en mémoire.
Si plusieurs environnement d'exécution sont lancés en parrallèle sans partage de lib, c'est une mauvaise configuration ou une lacune technique (genre les dev de l'environnement d'exécution n'en ont pas tenu compte), mais pas du tout un problème inhérent au principe de machine virtuelle.

Les applis par défaut de Gnome doivent se baser sur GTK+ et être en C.
Y'a longtemps que Gnome a rompu ton contrat moral en utilisant Python...

Si un langage de haut niveau se révèle vraiment indispensable alors il faut en choisir un (et un seul) et s'y tenir.
Justement non, le contrat de Gnome, au cas où tu l'aurais pas compris, c'est de proposer un framework en C et un ensemble de bindings pour avoir des applis dans des langages sans discriminiation et sans choix à priori.

Ils doivent CHOISIR et s'y tenir.
Oué ben ils ont choisient de laisser le développeur sa liberté pour la partie desktop. Le fait de développer des bindings depuis des années va entièrement dans ce sens, et refuser GTK# auraient clairement été un changement de "contrat moral" comme tu dis.

On remplace une appli par défaut par une application qui dépend de Mono...et tout le monde sent bien que ce n'est que le début.
Bah oué, ben t'avais qu'à améliorer Sticky au lieu de râler. Y'en a qui codent, d'autre qui râlent, essai au moins de comprendre que certains préfèrent des outils qui ne te plaisent pas forcement sans que celà constitue une "rupture de contrat moral". Y'a des gens qui essaient de faire évoluer le bureau Gnome, qui est avant tout destiné aux utilisateurs, qui n'en a rien d'autre à faire des détails techniques : ce qu'il voit c'est une appli plus "cool" qu'avant. S'il a fallut changer de techno et utiliser un nouveau soft, c'est parcque personne n'a voulu faire évoluer l'autre.

J'aime Gnome, j'aime son interface simple et son HIG
Ca correspond beaucoup plus au contrat "moral" de Gnome ca. Et tu devrais t'enthousiasmer que de nouvelles applis sortent en respectant justement ces goûts d'ergonomie.

Mais visiblement dans Gnome il n'y a pas de direction claire et de choix qui est fait.
Les HIG sont écritent noires sur blanc, ils essaient de s'y tenir, y'a une roadmap technique sur live.gnome.org, et la roadmap philosophique est toujours la même.

Pourquoi s'alourdir avec Mono (en plus des brevets Microsoft) alors que Python remplit ce besoin parfaitement ?
Moi je te réponds :
Pourquoi s'alourdir avec Python (en plus d'éventuels brevets et pourquoi pas de MS) alors que Mono remplit ce besoin parfaitement ? La vérité c'est que Gnome ne veut pas privilégier une plateforme plus qu'une autre, ils laissent les développeurs la "liberté" de choisir la techno qu'ils préfèrent.

'ai je ne sais combien de machine virtuelles qui tournent en même temps.
Oué t'en a 2. Mon dieu. Tu sais ce qu'est une machine virtuelle ? tu sais quelle taille prend la machine virtuelle en mémoire ? Tu sais quel pourcentage de tes barrettes de RAM de Gnome 2.22 ca représentera ? Que ces plateformes engendre une consommation de mémoire supplémentaire, certes, mais les mettre côte à côte ou n'en utiliser qu'une seule n'y changera rien du tout, les programmes boufferons toujours autant de RAM. Faut pas oublier que par derrière ca sera toujours les libs GNOME/GTK qui seront chargées, et mieux vaut optimiser celles-ci. Ah oui : avoir 2 plateformes entretien aussi l'émulation et la compétition (pour la consommation de RAM par exemple, désolé je trouve plus de lien).

Non, c'est que le risque est acceptable, c'est-à-dire en dessous d'un certain seuil.
Vi je suis bien d'accord. 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).

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.
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 ! 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...

Comme roi du FUD, tu te poses bien là.
Ben en attendant on sait toujours pas à quoi ressemble la licence, y'a des licences OSI qui n'empêche en rien les brevets logiciels hein ;-) J'essai pas de FUDer en disant que je préfère aller voir ailleur, je dis juste Wait&See, et en attendant j'ai GCJ + Eclipse qui me convient très bien niveau libertés.
(Quand à l'annonce du 14 août, désolé, j'étais en vacances, j'en étais encore aux rumeurs insistantes et déclarations officieuses).

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.
Si tu veux, mais as-tu fais la même investigation de l'intégral des brevets déposés pour pouvoir juger de manière objective ? Pour moi les brevets logiciels sont une véritable plaie pour l'ensemble des logiciels (libre ou non). La seule réponse qu'est trouvé certains acteur, c'est de faire un panier comme de brevet pour défendre une éventuelle attaque.

Enfin tout ca pour dire que de toute façon, le débat côté Gnome n'a globalement pas tourné sur la légalité de Mono où tout le monde est globalement aujourd'hui d'accord, mais plutôt sur des points techniques (rapidité, techno, etc.). Je ne remet pas du tout en question le fait que Mono puisse soulever des problèmes juridiques, mais dire qu'on change de plateforme à cause de ca alors qu'on a pertinement aucune idée de la légalité de l'autre plateforme relève vraiment du FUD (vouloir faire peur en semant le doute).

Bof, tu peux voir ca comme des noms de code qui font tripper les développeurs, concrêtement en tant qu'utilisateur j'irais dans un le menu Application > Son & Musique > Lecteur de musique ou Application > Bureautique > Prises de notes. Après comment s'appel le soft...