TImaniac a écrit 6420 commentaires

Il faut leur proposer celà en "option", en leur expliquant le pourquoi, mais surtout pas leur "imposer" la chose : un don forcer n'a que peu d'intérêt, et la boîte va considérer cela comme un "coût", et le côté "gratuit" des logiciels libres (pour une entreprise c'est un critère non négligeable) risque de passer à la trappe.

i j'avais aujourd'hui à choisir un langage et une plateforme sur des arguments exclusivement techniques, je prendrais C# et .NET car je pense que c'est ce qui se fait de mieux.
Faut aussi prendre en considération l'existant et les APIs utilisables, Java a quand même une large gamme d'API et bibliothèques plus mature par rapport à .NET ;)

Par contre j'aurai aimé que tu reprennes mes arguments :

- tu te bases sur des exemples de MS (Samba, SenderID, ASF) où MS fait preuve d'un manque flagrant d'ouverture, pour conclure sur .NET alors que là MS a fait preuve depuis 3 ans d'ouverture en exprimant clairement le pourquoi de la standardisation. Bref ce n'est pas du tout les mêmes objectifs.

Si tu tenais à faire une comparaison, pourquoi n'as tu pas par exemple pris en considération tout le travail de Microsoft autour des formats XML qui favorisent largement l'interopérabilité (même si l'a encore les brevets logiciels font chier) : il y a eu normalisation de nombreux standards où Microsoft s'est activement impliqué, comme XML, XSL, XSD, XPath & Co. Je trouves l'exemple beaucoup plus pertinent et plus proche de des objectifs qu'ils ont avec .NET : proposer une base technique favorisant l'interopérabilité (d'où mon affirmation qu'ils n'ont aucun intérêt à chercher à faire chier ceux qui utilisent les mêmes bases techniques), tout en protegeant leurs valeurs ajoutées, dans le cas de .NET il s'agit bien entendu de ASP.NET, WinForms et autres EnterpriseServices.

- tu affirmes que tout les API .NET (je carricature) seront couverts par les brevets, alors que tu sais pertinement (tu le rappelles toi même) que les APIs normalisés non rien d'innovant et qu'ils sont relativement basique (mais indispensable à l'interopérabilité). Bref, impossible à breveté entièrement, il y aurait forcement prior-art. Cela rejoint l'idée de la FAQ Mono qui dit clairement que les parties pouvant poser problème sont les parties non normalisées. Et c'est en parfait adéquation avec mon premier argument qui tend à dire que MS cherchera à protéger sa valeur ajoutée, mais pas la partie normalisé (à part pour assurer le respect des standards, comme le fait Sun d'une autre manière).

- tu ne prend en considération que quelques brevets non encore validés et tu "oublies" les autres brevets, eux validés. Je penses que tu seras d'accord pour dire que des projets de l'empleur de Mono ou Java violent sûrement d'autres brevets, au même titre que le noyau Linux en viole des centaines. Bref, les 2 sont sûrement dans l'illégalité (aux US) comme toutes les plateformes un tant soit peut conséquentes, et tu ne proposes pas de solution. Moi je dis : c'est aussi dangereux d'utiliser telle ou telle plateforme, mais ce n'est pas plus dangereux d'en utiliser plus qu'une autre.

- tu démontres avec force que les brevets Kodak s'appliquent surement à Mono, je te renvoi là encore l'ascenseur : pourquoi ne supposes-tu pas que les brevets, éventuellement validés, sur .NET ne s'appliqueraient-ils pas non plus à Java ou tout autre plateforme ?

Bref même si dans l'ensemble tes arguments sont pertinents et ton argumentation bien construite, le tout est vraiment biaisé de par le choix des arguments. C'est un bon article mais loin d'être exhaustif et ne peut pas à mon avis faire office de référence et synthèse du problème.

Les brevets logiciels ca puxorise.

Qui ne font pas du tout partis du langage auquels ils sont généralement associés.
C'est ce qui fait la force de .NET/Java : beaucoup d'aAPI en standard, sur toutes les plateformes : cela garantie une certaine homogénéité et une garantie d'interopérabilité.

Gnome ou QT doivent être utilisés comme des API externes et ne pas être considérés comme étant en standard. Il est donc impératif de ne pas les utilisés au "coeur" de l'application, en ajoutant une couche d'abstraction pour pouvoir se défaire d'un toolkit si besoin est.

T'as tout ca dans Python :
http://java.sun.com/j2ee/1.4/docs/api/index.html(...)
?

ce qui ne se traduit pas par et, mais par "et dans d'autres cas", ce qui veut dire ou.
Bizzarement les juristes anglais de chez Novell ne font pas la même interprétation que toi :
"Basically a grant is given to anyone who want to implement those components for free and for any purpose."
Chacun sa traduction hein.

Lis les documents donnés en référence.
Oué mais justement j'ai pas trouvé, d'où ma demande.

Lis les références et on rediscute.
A part dire que MS ne peut avoir un brevet valide sur tous ses API (puisqu'une grande partie n'a strictement rien d'innovant et de nombreux "prior-art" comme cherche à montrer le tableau de DotGnu, voilà quoi.
Evidemment que MS peut obtenir des brevets qui peuvent être "génant" pour Mono. Mais les APIs de MS n'innovent quasiment pas, alors soient d'autres plateformes seront impactés (autour des web services comme le laisse entendre une des tes sources), soient un prior-art sera démontré.

Et ouai, ça fout la trouille, hein ?
Kedal. Le directeur de MS dit seulement qu'ils ne comptent pas offrir de support pour Mono. Autrement dis : "implémenter les spécifs si vous voulez [même si un brevet est payant, Novell pourra obligatoirement obtenir une licence ou le contourner], mais vous vous démerder."
Enfin bizzarement c'est l'inverse qui s'est produit, les ingénieurs de MS ont aimablement aidés les dev de Mono, etc. L'avis que je t'ai donné du créateur de C# date de ce mois ci, les mentalité ont visiblement évolué depuis ta référence allemande qui date de 2002.
Ta citation foutait surement les boules y'a 3 ans. Depuis de l'eau a coulé sous les ponts : Mono a atteind maturité, Novell a étudié les brevets en question, MS a fait la promotion de Mono (invitant Icaza, argument marketing multiplateforme dans les slides PowerPoint), le fameux mail, le discours du créateur de C#, bref toutes les sources plus récentes vont à l'encontre de ce que tu essais de nous faire gober.
S'ils ne souhaitaient pas voir apparaître d'autres implémentation, pourquoi ce seraient-ils enmerder à normaliser leur plateforme ?

Plus sérieusement, je penses surtout que MS va chercher à proteger ses technos spécifiques comme ASP.NET ou les WinForms. Si un problème de brevet apparaît, ca sera sur ces parties (qui n'ont pas été normalisé, montrant clairement que MS ne souhaitait pas d'ouverture de ce côté). Mais Mono n'a besoin de ces parties que par compatibilité pour assurer la transition d'applications Windows. En aucun cas ces parties ne sont indispensable au fonctionnement de Mono qui peut rester une plateforme complète.

Enfin comme je l'ai déjà dis à plusieurs reprises, il faut :
- que MS ai effectivement ces brevets de validés : ce qui ne couvrira certainement pas tous les APIs, surtout pas les APIs normalisés sujettes à prior-art. Si des APIs sont couverts, cela ne peut être que ceux spécifiques à MS et donc à sa plateforme Windows. On va pas breveter la classe string hein ?

- que MS décide de faire payer des licences pour les brevets couvrant la CLI. (ce que je doute fortement, tout l'argumentation commerciale de MS sur le côté multiplateforme s'éffondrerait). Je dis pas qu'ils ne feraient pas payer pour ce qui n'est pas normalisé).

- que Novell ne puisse les contourner (en informatique il est quand même difficile de ne pas trouver 2 algos différents pour arriver au même résultat.

- que personne ne fork en dehors des US.

Pourquoi tu ne reprends pas mon argumentation, la 2ème partie de mon post ?

En espérant que cela reste constructif.

Microsoft et ses co-inventeurs (Intel et HP) ´etaient prˆets `a
offrir des licences Royalty Free ou RAND pour les brevets concernant C# et la CLI
pas "ou" mais ET. Cf http://web.archive.org/web/20030609164123/http://mailserver.di.unip(...)

alors que Microsoft a demand´e une protection de l’API de .NET par brevet, ce qui signifie que toute impl´ementation
de .NET sera n´ecessairement couverte par le brevet en question
Source ? D'où provient l'affirmation que les brevets en questions concernent l'ensemble des APIs et qu'il est impératif de les implémenter ? Que je sache le projet DotGNU a fait un tableau récapitulant les éventuelles parties concernées par ces fameux brevets. Visiblement les juristes de Novell ont procédés de même. Bizzarement ils ne sont absolument pas arrivé à la même conclusion que toi.

Par contre, l’affaire Kodak vs Java ne sera pas n´ecessairement sans cons´equence pour les impl´ementations libres de .NET. En effet, les brevets concern´es sont si
larges qui couvrent tr`es certainement .NET
Tout à fait d'accord. Mais il faut faire le même raisonnement pour de nombreuses plateformes de développement. Tu supposes que .NET est sûrement concerné, je ne vois pas pourquoi tu supposerais que seul cette plateforme l'ai.


Il me semble qu’il est possible (mais difficile) de faire une impl´ementation libre l´egale de
Java
Kodak et Sun ont passé un accord. Les implémentations alternatives n'ont pas cet accord auprès de Kodak. J'ai donc beaucoup de mal à comprendre en quoi tu arrives à conclure de manière "positive".

D'une manière générale j'ai vraiment du mal à te suivre. Tu arrives toujours à dire qu'il y a un problème sur telle plateforme et à montrer qu'il y a le même problème sur l'autre plateforme. Pourtant tu arrives à conclure que Java ne semble pas trop problématique alors que Mono représente un véritable danger pour les logiciels libres.

Enfin dans l'ensemble c'est plutôt pertinent. Dommage que tu refuses d'essayer d'analyser le pourquoi en te contentant plutôt de détails pratiques et juridiques, avec beaucoup de "suppositions" et de tentative de découverte d'intentions.

Que cherchent à faire Microsoft et Sun ? Protéger leur plateforme contre toutes utilisations qui casserait la compatibilité, bref ils veulent faire respecter leurs "standards" pour que personne ne s'en écarte. Evidemment que Sun ne fera pas chier Classpath s'ils sont pas parfaitement compatible : Classpath ne le fait pas exprès et ce n'est pas leur objectif.

Maintenant que penses Microsoft de Mono ?
Le créateur du langage C# chez Microsoft :
" InfoWorld: What is your take on Mono?

Hejlsberg: Oh, I think it's great, I think it's proof that standardization works, that the work that we've done in ECMA to standardize CLI [Common Language Infrastructure] and C# actually has [results] and we have seen completely independent third-party implementations of the infrastructure. So I think it's a good thing. I think it's more good for us than bad for us. "
( http://www.infoworld.com/article/05/06/10/HNhejlsberg_1.html?source(...) )
Là on apprend POURQUOI MS a cherché à standardiser sa plateforme.
Que cette citation reflète ou non une position officielle, elle s'ajoute aux nombreuses autres avis et faits qui montre clairement que leur objectif est la standardisation en vu de voir apparaître d'autres implémentations, sur de nombreuses plateformes.
Tes rapprochements avec Samba ou les formats ASF sont donc tout à fait incongru puisque là les objectifs de Microsoft sont clairement une absence totale d'ouverture. Cherchez à démontrer ce que MS va faire en se basant sur cet "existant" me paraît donc totalement foireux. Dans ce cas précis MS cherche à protéger sa propriété intellectuelle (codec entre autre) qui fait ici la différence avec la concurrence.

Pour .NET c'est totalement différent, même sans brevets accordés ils ont mis à disposition le projet Rotor. Même si celui-ci n'a que peut d'intérêt du point de vu des logiciels libres, Microsoft ne cherche pas à cacher des "secrets technologiques" comme il le fait avec ses formats vidéos par exemple (qui constituent le nerf de la guerre).

Microsoft a clairement chercher à ce que naisse Mono. Ils ont même pousser Icaza à de nombreuses reprises, et Novell a joué le jeu en choisissant des licences que Microsoft "accepte".

Maintenant ce que je ne comprends pas non plus c'est que reviens sans cesse dans ton argumentation le fait que les futurs brevets couvrirons forcement l'ensemble des API de .NET. Marrant tout de même que le service juridique de Novell n'ai pas vu cet éventuel danger.

Bref tout ca me pousse à être optimiste, au moins autant que pour Java.

Maintenant tu oublies le principal : proposer une alternative ou une solution.
Pourtant il y aurait également eu matière à analyse. Il est évident que le monde des logiciels libres a besoin d'une plateforme "moderne" du type de celles de Sun et MS. Il n'existe rien de tel d'"indépendant" mais déjà de nombreuses briques existent (que ce soit au nivaeu des APIs, des langages ou des VM). Maintenant poursuivons l'analyse. Si on suit avec quel brio tu arrives à démontrer que les brevets Kodak s'appliqueront forcement à .NET, on peut sans trop d'imagination se dire qu'ils seront applicables à cette hypothétique plateforme. D'ailleur cela s'applique déjà surement à des briques existentes. Bref, tous les projets de plateforme et/ou langage est un danger pour les logiciels libres si je fais la même conclusion que toi.

Les violations multiples de brevets logiciels dans le noyau est un autre parfait exemple.

Tu as raisons en disant que l'épée de Damoclès des brevets logiciels reposent sur la tête des logiciels libres. Mais affirmer que seuls .NET (ou Java) posent problème est vraiment se moquer du monde. Le problème est omniprésent. Le problème c'est les brevets logiciels dans leur ensemble.

Après je suis d'accord avec toi qu'il est bien dommage que ces plateformes soient dirigés par des entreprises privées, mais cela a aussi des avantages : ces entreprises savent imposer des standards (tu l'as parfaitement démontrer), ce qui fait aussi en grosse partie le succès de Java et .NET, savent les répendre (et donc les faire adopter) et aussi protéger leurs utilisateurs : Microsoft Sun ou Novell ont les moyens de riposter contre une éventuelle attaque de brevet, alors qu'un pauvre petit projet parfaitement libre qui en viole un "par hasard" va se faire bouffer tout cru.

Une dernière pensée (en totale contradiction avec le fait que je suis contre les brevets logiciels) mais qui pousse à réfléchir :
"Ahhh si seulement le HTML avait été breveté, MS nous auraient pas péter les couilles avec Internet Explorer..."
(en même temps grâce à IE on a un superbe vecteur de promotion des LL à travers Firefox actuellement...)

Ah non.
Le principe d'un brevet est que son détendeur en a l'exclusivité d'utilisation. Il peut s'il le souhaite vendre des licences d'utilisation et récupérer des royalties, mais il peut aussi conserver son exclusivité.

Ce problème de déploiement n'est pas spécifique aux éditeurs de jeux mais aussi aux développeurs de matos : ATI ou NVidia, même s'ils fournissent leur stock de pilotes (sans avoir à gérer 1500 versions de serveur X), peuvent se baser sur l'intégration de pilotes basiques dans Windows, garantissant dans la plupart des cas le fonctionnement des jeux "out-of-the-box" sans installer de nouveaux pilotes. Sous Linux, sans pilotes propriétaires, point de salut, malheuresement c'est rarement par défaut dans l'OS. Je ne remet pas en cause le pourquoi de la situation, je constate juste.

A la différence que dans le libre nous sommes des acteurs : nous contribuons à l'évolution (pas forcement logiciel mais aussi dans les idées). Même s'il y a de nombeux intégristes qui ne jurent que par la même licence ou le même logiciel, il y a tout de même un esprit d'ouverture ou tout de moins de recherche d'évolution (même si ca se barre souvent en troll).

Les maceux ont plutôt tendances à admirer leur dieu (de ce point de vu nous ne somme pas toujours mieux), mais ils sont de simples spectateurs des décisions d'une boîte aux objectifs exclusivement financiers. "Faites moi confiance !" (TM). Hein steevy.

Le principal problème vient de Linux en lui même : Microsoft propose une plateforme unifiée autour de DirectX, on peut déployer de Window 98 jusqu'à XP sans rien changer. Sous Linux, non seulement on a une part ridicule de marché, mais surtout on n'a pas de plateforme unifié qui englobe tout ce qu'englobe DirectX, et comble du comble, on a pleins de distributions avec chacunes leurs systèmes de déploiement qui constituent autant de casse-tête et de plateformes à tester.
Bref, c'est beaucoup d'investissement pour pas beaucoup de client. C'est pas rentable quoi.

au moins installe-le sur ton system
Nan mais c'est fait je t'en remercie :)
C'est d'ailleur un des avantages : il y a des paquets officiels par Novell pour Fedora. Mais ce sont surtout pour les applications tierces que cela est plus génant. Par exemple muine beagle et fspot ne sont pas dispo dans Fedora, mais le sont dans le repository nrpm. Malheuresement celui-ci "repackage" Mono, et ceux-ci sont incompatibles avec les packages officiels :-/

Oué bah c'est toujours mieux que rien et je m'en contenterait bien moi :) Il mettront Mc Cartney à la basse puisque visiblement il est tout seul, pour le batteur il faudra se résigner, ils ne trouveront pas de remplaçant à la hauteur du défin excité :-(

Oué pour le concert Live 8 à Londres, d'ailleur y'aura aussi The Who, McCartney, Elton John (et d'autres célébrités comme Madonna, Robbie Williams, The Cure et j'en passe).
Paye ton concert de ouf.
Manque plus que les Rolling stones et Led zep ^^
Dommage qu'il n'y ai plus de place (y'en avait "que" 150 000), j'en ai bien vu passer une aujourd'hui sur ebay.com, mais elle est parti à plus de 1800$ :-/

Je te rebalance la question :
où sont les brevets dans Mono ?
Peut tu le dire ?
Si oui, indique le, si non, c'est du FUD désolé.

Quand une entité a dévoilé avoir répertorié plus de 260 violations de brevets dans le kernel, même si on n'a pas eu la liste en question, tout le monde s'est accordé à dire qu'étant donné la stupidité des brevets logiciels (et leur champs d'application), et la taille du kernel, que c'était évident, et que le contraire aurait été surprennant. On peut facilement imaginer qu'il en est de même pour les projets tout aussi conséquents que sont Java et Mono/.NET. Libre à toi de considérer cela comme du FUD, pour moi c'est malheuresement une certitude. Après désolé j'ai pas le temps d'examiner le code de toutes les implémentations de Java tout en listant tous les brevets logiciels pour le vérifier.

M'enfin les dev de Fedora Core FUD comme des porcs sur Mono, je vois pas pourquoi ils ne font pas de même sur Java ou le kernel. Comme quoi l'explication est ailleur.

c'est plutot normal qu'il te previennes ...
Bien sûr, mais qu'il m'empêche après d'installer après tous paquets parcque dans la base il y a une incohérence depuis la dernière fois, c'est très saoulant. J'avais pas trouvé comment l'empêcher de râler.

a m'expliques pas pourquoi yum est une x-ieme implementation de gestion de paquet ... :)
Ben le format rpm est historiquement présent dans de nombreuses distri (à commencer par les red hat), donc bon il y avait besoin d'un équivalent à apt-get capable de gérer les rpm, d'où la naissance de yum.

déjà quand t'as forcé l'installation d'un paquet (parcque par exemple tu savais pertinament avoir les dépendances requises, mais tu les avaient compilées à la main), yum ne t'envoi pas balader comme le fait apt.

Après yum gère les rpm, apt gère les .deb. Même s'il existe des batards (apt4rpm) non maintenus, cela fait une grosse différence qui fait qu'il n'y a pas à faire le choix entre l'un et l'autre.

J'ose espérer qu'il ne fait pas ça, ça serait completement stupide.
Même s'il ne le fait pas en une fois, tôt ou tard l'utilisateur va chercher à scroller et le nombre de requête à ta bdd risque d'augmenter assez rapidement.

Enfin imagine par exemple que ta bdd réponde en 1 seconde (charge réseau, table énorme à fouiller, etc.), t'imagine le joli freeze ?
Thread je te dis, thread :)

Ah oui et je t'explique pas le raaaamage si jamais la requête à la bdd est de l'ordre du 10ème de seconde : pour chaque node que le treeview va chercher à afficher il va interroger ton implémentation, et donc ton dataset, et donc ta bdd... ouch !
Le remplissage depuis un thread t'évitera tous ces problèmes, et tu auras forcement besoin d'un tampon, le ListStore sert à ca.

L'avantage de piocher dans un recordset, c'est que lui fait un tampon transparent vers la base de donnée, en l'interogant si nécessaire. Donc toutes les infos ne seront pas forcement en mémoire.
Sauf qu'à priori le TreeView va chercher à charger toutes les données, bref il va demander toutes les items et ton recordset sera plein. D'autant plus pleins qu'il y aura dedans pleins d'informations peut être inutile qui ne sont aps afficher. Avec une méthode sans recordset le tampon est uniquement constitué d'une chaîne de caractère.

Je vois pas bien le probleme de créer un nouveau widget à ce niveau.
Qui va implémenter l'interface GtkTreeModel ?

quoi qu'on en dise yum est quand même super bien foutus et pour ceux qui ont la fleme de taper des lignes de commandes des front-end sont en developpement et sont plutôt bien conçu.
Je suis également un pro-yum, mais quoique tu dises, yum est super mal conçu, en particulier pour les front-end : une application moderne se doit de proposer un ensemble d'API pour faciliter son utilisation (notamment par un front-end) et non se contenter de proposer une interface stdin/stdout qui, bien qu'utile en ligne de commande, relève de la préhistoire de l'informatique au niveau des communications inter-programmes (dans notre cas : front-end/yum).

De toute façon à un endroit ou autre il va te falloir un tampon pour stocker la valeur à afficher dans le treeview, alors que tu t'amuses à le gérer toi même ou que tu laisses le TreeModel dispo ne changera pas grand chose question mémoire. J'ai peur que tu veuilles te prendre la tête pour pas grand chose.

De plus cela oblige ton code métier à implémenter une interface spécifique à un toolkit graphique, c'est vraiment douteux d'un point de vu méthodologique.

il n'a jamais été publié officiellement par MS
Un mail ca ne se publie pas, ca se poste.

tu prends vraiment tes rêves pour des réalités !
Mais c'est toi qui rêve. Même en supposant que MS décide de faire payer, contrairement à ce qu'ils ont laisser entendre, il faut QUE TOUTES LES CONDITIONS que j'ai énoncées soient vérifiées (bordel) pour que Mono soit inquiété. Alors maintenant que tu m'as montrer avec une argumentation convainquante que MS va sûrement faire payer pour l'utilisation de ses brevets, j'attend que tu me montres avec autant de force que toutes les autres hypothèses vont se révéler exacte.

Enfin tant mieux pour toi si t'es convaincu, t'auras la chance de te voir offrir une bière comme je l'ai promis.

Rempli ta liste dans un thread, ca sera plus simple que de t'amuser à implémenter les 10000 méthodes de GTKTreeModel.

Le fait que ce soit gratuit n'a jamais ete dit officiellement par MS.
Je l'ai déjà dis plus haut, un des co-dépositaires l'a déclaré officiellement, c'est donc une déclaration officielle de MS. Cependant cela n'a aucune valeur juridique, les brevets n'en ayant toujours aucune puisqu'il n'existe pas. C'est pourquoi le mail parle au "futur".

c'est une sacre limite a l'utilisation des logiciels libres
Que je sache c'est le même problèmes pour la plupart des logiciels libres, IBM et Sun ont par exemple donné l'autorisation explicite d'exploiter quelques brevets dans les LL, mais là pareil on ne sait pas pour combien de temps, etc, ce sont les mêmes limitations. Enfin tout cela suppose encore une fois que toutes les hypothèses soient remplies.

Par consequent, Mono a beau etre GPL, son utilisation est quand meme soumise au bon vouloir de Microsoft.
Comme je l'ai déjà expliqué, cela suppose que TOUTES les hypothèses que j'ai énoncées soient remplis. C'est de la pure paranoïa que de l'imaginer. Pour moi tout raisonnement basé sur le fait que toutes ces hypothèses sont remplis n'est que pur FUD (par définition).

Tu t'ai jamais demandé ce qu'il se passaient le jour où la fondation FSF qui détient un nombre impressionnant de copyright passait dans les mains d'une entreprise peu scrupuleuse ? Imaginer une telle situation est possible mais très difficilement envisageable. C'est exactement pareil : il y a une possibilité mais il y a suffisament de conditions pour ne pas s'inquiéter.

Ah oui j'oubliais :
- que ces brevets sont effectivement "innovant" et qu'il n'y a pas de cas d'utilisation antérieur qui pourraient les invalider.