Journal Java, .NET et les logiciels libres

Posté par  (site Web personnel) .
Étiquettes : aucune
0
16
juin
2005
Voilà, c'est fait, mon article paru dans GNU/Linux Magazine France 67 (http://www.ed-diamond.com/produit.php?produit=375(...) ) sur Java, .NET et les logiciels libres est enfin disponible en ligne à l'url http://apiacoa.org/publications/2004/lm-java-dotnet-free.pdf(...) . Merci à Denis Bodor et aux Editions Diamond pour avoir autorisé cette publication.

Ce journal est destiné aux discussions concernant l'article. J'espère le faire évoluer et l'améliorer. Bonne lecture !
  • # héhé

    Posté par  (site Web personnel) . Évalué à 5.

    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...)
    • [^] # Re: héhé

      Posté par  (site Web personnel) . Évalué à 5.

      pas "ou" mais ET. Cf http://web.archive.org/web/20030609164123/http://mailserver.di.unip(...)

      Non. Il est indiqué royalty-free and otherwise RAND, ce qui ne se traduit pas par et, mais par "et dans d'autres cas", ce qui veut dire ou.

      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 ?

      Tu as lu mon texte, mais tu n'as pas lu les documents pointés, c'est ça ? Lis les références et on rediscute. Cf donc
      http://www.theregister.co.uk/2003/02/11/ms_patents_everything/(...) et http://news.com.com/2100-1001_3-984052.html(...)

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

      Parce que Sun a indiqué explicitement que l'accord couvrait les licences officielles de Java et qu'une implémentation légale a nécessairement une licence officielle. Lis les documents donnés en référence.

      Et pout finir, une citation de Steve Ballmer, traduite de l'allemand (pas par moi) :
      Responding to questions about the opening-up of the .NET framework, Ballmer announced that there would certainly be a "Common Language Runtime Implementation" for Unix, but then explained that this development would be limited to a subset, which was "intended only for academic use". Ballmer rejected speculations about support for free .NET implementationens such as Mono: "We have invested so many millions in .NET, we have so many patents on .NET, which we want to cultivate."

      Et ouai, ça fout la trouille, hein ? (source http://swpat.ffii.org/players/microsoft/(...) ).
      • [^] # Re: héhé

        Posté par  (site Web personnel) . Évalué à 3.

        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.
        • [^] # Re: héhé

          Posté par  . Évalué à 2.

          Java pose exactement les mêmes problèmes que .Net, dire que l'un est plus dangereux que l'autre, c'est de la trollerie.
          Globalement l'article est intéressant mais la conclusion biaisée pas étonnant vu que l'auteur est un expert Java, donc sa position est tout aussi valable que celle de mr Timaniac, je dirais match nul.

          Amicalement votre, Michael.
          • [^] # Re: héhé

            Posté par  (site Web personnel) . Évalué à 2.

            la conclusion biaisée pas étonnant vu que l'auteur est un expert Java

            Quelle puissance dans l'argumentation ! Si 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. Je suis d'autant plus dégouté que Mono pose potentiellement des problèmes légaux que c'est pour moi une superbe réalisation logicielle. Contrairement aux projets open source Java, Mono a dès le début pris ses distances avec les API canoniques en proposant des choses très intéressantes comme gtk#. Oui, je suis un expert Java (merci), mais je n'ai rien contre le framework de MS, au contraire.

            Concernant le caractère biaisé de ma conclusion, je vois que tu te contentes d'une affirmation pour seule critique d'une argumentation de 20 pages et je ne vois donc pas l'intérêt de te répondre.
            • [^] # Re: héhé

              Posté par  (site Web personnel) . Évalué à 2.

              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.
              • [^] # Re: héhé

                Posté par  (site Web personnel) . Évalué à 2.

                il y a eu normalisation de nombreux standards où Microsoft s'est activement impliqué, comme XML, XSL, XSD, XPath & Co.

                Les standards que tu cites sont développés dans le cadre du W3 qui exige des licences royalty free. Donc soit MS collabore et fait du royalty free, soit MS ne collabore pas. Je ne vois pas ici d'argument montrant que .NET sera sous licence royalty free, même pour la partie CLI/C#.

                De plus, tu sembles ne pas vouloir lire et comprendre les licences MS. Va voir par exemple la licence pour les schémas d'Office. Cette licence n'inclue pas le droit à la sous-licence. C'est le même problème que pour le sender-id. Ms veut bien l'interopérabilité (contraint par les procès anti-trust, je te le rappelle), mais ne veut pas vraiment du logiciel libre car les licences libres sont incompatibles avec l'interdiction de faire des sous-licences.

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

                Il y a des innovations dans la partie normalisée, au coeur de celle-ci (en gros, ce qu'on ne retrouve pas dans d'autres langages comme les parties unsafe).

                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 ?

                Cf autre réponse. L'expérience montre que Sun est prêt à défendre Java et les licences officielles. Ceci dit, je n'ai pas accès au texte exact de l'accord Kodak/Sun et il est possible que Kodak attaque un jour JBoss. En tout cas, c'est une hypothèse pas totalement débile.

                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.

                Ba voyons. Et pourquoi ce n'est pas une synthèse ? Il y a tous les faits que je connais. Tu voudrais ajouter quoi ?
                • [^] # Re: héhé

                  Posté par  (site Web personnel) . Évalué à 2.

                  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.
                  • [^] # Re: héhé

                    Posté par  (site Web personnel) . Évalué à 2.

                    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.


                    Et pourquoi les objectifs et intérêts ne sont pas les mêmes ? Qu'est-ce que tu en fais ? Le Sender-ID est typiquement comparable à la partie normalisée de .NET. C'est un standard qui n'a d'intérêt que s'il est utilisé par le plus grand nombre, MS l'apporte (en partie) dans une discussion ouverte de l'IETF (encore plus ouvert que l'ECMA et l'ISO) et boum, la licence royalty free proposée est incompatible avec une implémentation open source. Je ne comprends pas la différence avec .NET.

                    Pour Samba, le parallèle est justifié pour les bibliothèques "serveur" de .NET, nous sommes d'accord sur ce point. Et la comparaison avec Java n'est pas flatteuse pour .NET puisque que c'est justement sur l'aspect serveur que Java est le plus ouvert.

                    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 c'est totalement incomplet ! 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.
                    • [^] # Re: héhé

                      Posté par  (site Web personnel) . Évalué à 2.

                      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.
            • [^] # Re: héhé

              Posté par  . Évalué à 2.

              Je reconnais que l'argument ressemblait plus à du FUD qu'autre chose mais bon. ;-)
              AU sujet de Mono, on peut distinguer 3 parties, la première étant la partie standardisé par ECMA, l'ECMA pose comme condition à ses membres de renoncer à l'exercice de leur brevet sur tout les standards qu'ils ont déposé et à les licencier selon le principe RAND. EN théorie, Microsoft aurait le droit de demander par exemple 1$ sur chaque copie de Mono, ce qui serait tout à fait raisonnable et aussi incompatible avec le libre, mais vous oubliez le fait que l'ECMA demande aussi au dépositaire du standard de statuer définitivement sur leur politique de licences et dans le cas ou le standard utilise un brevet connu au moment du vote venant d'une tierce partie , d'un accord écrit. Donc sur cette partie, Microsoft a joué le jeu, je doute que Novell ait poursuivi le projet Mono sans s'etre assuré qu'il n'y avait aucun risque, de plus, Novell participe activement aux travaux de l'ECMA avec Microsoft et HP. Donc le coeur de Mono ne pose pas plus de problème que Java, même si la politique de Microsoft reste obscure pour le grand public.
              La seconde partie est elle bien plus problèmatique, car elles concernent les API non standardisés comme ADO.net, ASP.net et les winforms, or ce sont le fer de lance de Microsoft dans le developpement de webservices, donc potentiellement une source de revenu importante, jusqu'à Mono, ASP.net ne tournait que sur IIS donc sur du windows, donc de juteuses licences serveurs. Désormais, il y a un mod apache permettant de faire tourner asp.net sous n'importe quel serveur unix-like. C'est là le véritable coeur du problème, ces APIs sont celles ou Microsoft n'a aucun engagement, soit on brise la compatibilité, soit on casse Mono, soit on joue le jeu. Soyons pessimiste et que Microsoft veuille casser Mono, Novell a 2 possibilités: faire passer ces APIs sous licence proprio et payer une licence à Microsoft, soit contourner les brevets Microsoft, dans aucun cas, le coeur de Mono n'est touché, ça génera sa progression en entreprise, sur la plateforme win32.
              Quant à la 3ème partie, les APIs particulières de Mono: gtk#, gnome#, cocoa#, gecko# .....etc, elles ne posent pas plus de problèmes que la plupart des projets libres.
              Avec Java, on a le même problème GCJ, Kaffe et cie, aucune n'implémentent entièrement Java2, malgré que ces implémentations soient largement diffusés dans le monde du libre, SUN pourrait tout à fait les écraser si il le voulait, je suis sur qu'écraser GCJ leur ferait très plaisir, surtout que ça ferait bien chier RH, leur véritable concurrent.
              D'un coté, on a une implémentation fonctionnelle entièrement libre d'une techno proprio à demi-standardisé, qui malgré les risques de brevets, a de bonnes chances de perdurer notamment sur le desktop, les APIs visant les entreprises étant elles sérieusement menacés. Et de l'autre, des implémentations incomplétes sur le desktop, jusqu'à très récemment inutilisable, qui risque potentiellement à tout moment d'etre stoppé par SUN , et des implémentations des APIs visant les serveurs certifié donc qui n'ont rien à craindre de Sun.
              Bien entendu, on peut aussi supposer que Novell bluffe et que Microsoft dans sa politique de licence n'autorise pas les implémentations libres du coeur de .Net, mais je doute que les devs qui travaille dessus l'ait accepté aussi facilement.
              • [^] # Re: héhé

                Posté par  (site Web personnel) . Évalué à 2.

                Donc sur cette partie, Microsoft a joué le jeu, je doute que Novell ait poursuivi le projet Mono sans s'etre assuré qu'il n'y avait aucun risque, de plus, Novell participe activement aux travaux de l'ECMA avec Microsoft et HP.

                Où est l'accord écrit ? Tout ça est un ensemble de suppositions.

                Avec Java, on a le même problème GCJ, Kaffe et cie, aucune n'implémentent entièrement Java2, malgré que ces implémentations soient largement diffusés dans le monde du libre, SUN pourrait tout à fait les écraser si il le voulait, je suis sur qu'écraser GCJ leur ferait très plaisir, surtout que ça ferait bien chier RH, leur véritable concurrent.

                Ouai, suppositions que tout ça. Les faits c'est que Sun a permis et faciliter la standardisation officielle de JBoss et Jonas alors que les deux produits lui bouffent énormément de parts de marché. Donc je ne vois pas pourquoi ils attaqueraient GCJ. Et de plus, la licence d'implémentation (avec le point sur le brevet) est disponible depuis des années sur le site de Sun donc on connaît les conditions légales pour implémenter Java et elles sont compatibles avec l'open source.
                • [^] # Re: héhé

                  Posté par  . Évalué à 0.

                  1.1
                  In case the proposed Standard is covered by issued patents of Ecma members only: Members of the General Assembly are asked to state the Company licensing policy with respect to these patents.

                  L'ECMA est claire, pour que les propositions ECMA-334 et ECMA-335 soient accepté, Microsoft en tant que membre ayant droit de vote à l'assemblée Générale a du statué sur sa politique de licence vis à vis des brevets couvrant ces normes. Novell en tant qu'associate member n'a pas le droit de vote à l'AG mais participe aux comités techniques dont ceux couvrant la CLI et C# et ont accès à toute la documentation nécessaire.
                  Donc Microsoft a bel et bien une position claire au sujet des brevets lui appartenant couvrant Mono et autres implémentations du framework .Net, c'est un problème de communication. En l'absence de déclaration publique de Microsoft, doit-on croire le service juridique de Novell qui s'est penché sur la question et a eu accès à toutes les données ou RedHat qui justement n'a pas intérêt à ce que .Net se developpe et pousse Java sur lequel repose toute leur stratégie ?
                  Je rappelle que comme SUN, dans les faits Microsoft n'a rien fait contre les implémentations libres de son framework bien au contraire, Novell participe activement à l'élaboration des specs et il y a de nombreux échanges entre l'équipe dotnet et Mono alors que les implémentations libres de Java sont condamnés à suivre les specs de SUN, contrairement à l'ECMA, les travaux du JCP sont controlé par un seul acteur et loin d'etre ouvert. Donc je pourrais vous retourner la balle en vous disant que votre opinion au sujet de SUN et des implémentations libres de Java ne sont que des suppositions car rien ne garantit que SUN fasse stopper la distribution de GCJ.
                  Si je me rappelle bien , la licence de SUN oblige à fournir une implémentation complète de ses specifications, or avec GCJ on est loin du compte pour qu'elle soit légale. Pour JBoss et Jonas, on est dans un cas différent car ce sont des implémentations complètes et qui pour le moment ont toujours besoin d'utiliser une implémentation proprio de Java pour tourner en production dans les faits. COntrairement à Mono qui porte réellement atteinte à .Net , GCJ ne porte nullement atteinte au business plan de SUN, quant à JBoss et Jonas, ils auront toujours un train de retard sur l'implémentation de SUN qui est passé à Java 1.5.
                  • [^] # Re: héhé

                    Posté par  (site Web personnel) . Évalué à 2.

                    Héhé boubou ca tu peux je rajouter dans ton document ;)
                  • [^] # Re: héhé

                    Posté par  (site Web personnel) . Évalué à 2.

                    In case the proposed Standard is covered by issued patents of Ecma members only: Members of the General Assembly are asked to state the Company licensing policy with respect to these patents.

                    L'ECMA est claire, pour que les propositions ECMA-334 et ECMA-335 soient accepté, Microsoft en tant que membre ayant droit de vote à l'assemblée Générale a du statué sur sa politique de licence vis à vis des brevets couvrant ces normes.

                    Oui et alors ? Qui te dis que la politique en question n'est pas "royalty free and otherwise rand", ce qui ne veut rien dire et ne garantit rien ? Pourquoi faut-il que je répète encore et encore que même royalty free n'implique pas comptible avec une implémentation libre (cf ASF, Sender-Id, etc.). Et en plus, tu ne cites que le point 1.1 de la politique général de l'ECMA (cf http://www.ecma-international.org/memento/codeofconduct.htm(...) pour le texte complet). Si tu lis attentivement le réglement complet, tu trouveras très clairement que rien n'est exigé à part du RAND et qu'aucune déclaration formelle n'est obligatoire car ne rien dire implique RAND (cf le point 2.4).

                    Novell en tant qu'associate member n'a pas le droit de vote à l'AG mais participe aux comités techniques dont ceux couvrant la CLI et C# et ont accès à toute la documentation nécessaire.

                    Quelle documentation ? La déclaration de MS sur les brevets ? Mais il suffit à MS de dire RAND pour que tout soit terminé. Il n'est indiqué nulle part que MS doit proposer un modèle licence complèt ! De plus on trouve à l'URL http://www.ecma-international.org/memento/guidance.htm(...) des modèles de déclaration pour les brevets qui ne donnent aucune précision autre que RAND.

                    Bref, rien dans le processus de l'ECMA ne permet d'affirmer que MS fera autre chose que du RAND (ce qu'il est obligé de faire pour la partie couverte par les standards).

                    En l'absence de déclaration publique de Microsoft, doit-on croire le service juridique de Novell qui s'est penché sur la question et a eu accès à toutes les données ou RedHat qui justement n'a pas intérêt à ce que .Net se developpe et pousse Java sur lequel repose toute leur stratégie ?

                    Ni l'un, ni l'autre. Novell s'est contenté d'une déclaration qui dit "on a regardé, il n'y a pas de problème" et d'un lien vers un mail sans aucune valeur juridique. Si Novell publie un rapport complet, avec une analyse détaillé des brevets qui démontre que Mono les contourne, je commencerais à croire Novell. Pour l'instant, c'est du vent.

                    Je rappelle que comme SUN, dans les faits Microsoft n'a rien fait contre les implémentations libres de son framework bien au contraire, Novell participe activement à l'élaboration des specs et il y a de nombreux échanges entre l'équipe dotnet et Mono

                    C'est vrai, j'ajouterais ça dans mon texte dans une prochaine révision.

                    lors que les implémentations libres de Java sont condamnés à suivre les specs de SUN, contrairement à l'ECMA, les travaux du JCP sont controlé par un seul acteur et loin d'etre ouvert.

                    N'importe quoi. Relis mon texte et sa description complète du JCP. Apache est membre du JCP, par exemple. Et le JCP standardise TOUT Java, contrairement à l'ECMA qui n'a qu'une petite partie de .NET sous sont contrôle.

                    Donc je pourrais vous retourner la balle en vous disant que votre opinion au sujet de SUN et des implémentations libres de Java ne sont que des suppositions car rien ne garantit que SUN fasse stopper la distribution de GCJ.

                    Sun peut faire stopper la distribution de GCJ tant que celle-ci n'est pas compatible avec la spec 1.4. Tous les jours, l'écart diminue et Sun est de moins en moins en position de stopper la distribution de GCJ. Mais c'est une éventualité, en effet. Et je l'ai largement indiqué dans mon texte.

                    COntrairement à Mono qui porte réellement atteinte à .Net , GCJ ne porte nullement atteinte au business plan de SUN,

                    Donc Sun n'a aucun intérêt particulier à stopper GCJ.

                    quant à JBoss et Jonas, ils auront toujours un train de retard sur l'implémentation de SUN qui est passé à Java 1.5.


                    Totalement ridicule. J2EE 1.5 n'existe pas ! Tout le monde utilise J2EE 1.4 avec en sous jacent une JVM 1.5. JBoss et Jonas ne sont absolument pas en retard sur le serveur de Sun. Comme la spécification de J2EE 1.5 se fait de façon relativement ouverte, JBoss et Jonas contiennent déjà des briques de cette future version. De plus, certains gros morceaux de JBoss et de Jonas tournent sur des versions libres de la JVM. C'est le cas de Tomcat, par exemple.
        • [^] # Re: héhé

          Posté par  (site Web personnel) . Évalué à 2.

          Chacun sa traduction hein.

          Mais bien sûr. La phrase complète est But Microsoft (and our co-sponsors, Intel and Hewlett-Packard) went further and have agreed that our patents essential to implementing C# and CLI will be available on a "royalty-free and otherwise RAND" basis for this purpose.

          Explique moi un instant pourquoi l'ingénieur de chez MS n'a pas utilisé le mot "and" seul ? Parce que ça ne veut rien dire ! On ne peut pas être à la fois royalty-free et RAND, sauf si on interprète RAND comme royalty-free, ce qui n'est évidemment pas le cas. La présence du otherwise est cruciale puisqu'elle montre qu'il y a justement une différence. Et on ne sait pas au final quels seront les critères de décision de MS pour le choix entre ces alternatives.

          De plus, ce mail n'a AUCUNE valeur légale. 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 ?

          Enfin, obtenir une licence royalty-free ne signifie en aucun cas que tu pourras redistribuer une implémentation open source, comme je le démontre par des exemples de chez Microsoft dans le texte.

          Oué mais justement j'ai pas trouvé, d'où ma demande.

          Et bien va lire le brevet : http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HIT(...) (et c'est seulement un des brevets). Il est possible que certaines API ne soient pas couvertes, ceci dit. Dans une révision de mon article, je remplacerais toute l'API par une grande partie de l'API, ça sera plus prudent.

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

          En effet, tout est possible dans le monde des Bisounours. 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.

          De plus, je ne considère pas les professions de foi des ingénieurs (même hauts placés) de MS comme des engagements. MS est une entreprise privée, dirigée par ses chefs. Il y a chez MS des gens très bien qui aimeraient faire plus d'open source, qui ne sont pas contre la GPL, etc. La direction les laisse collaborer avec l'extérieur et même produire de l'open source. Mais à la fin, c'est la direction qui décide, comme dans les autres entreprises. Je ne vois pas en quoi .NET n'est pas stratégique pour MS. Au contraire, je pense même que c'est un des projets les plus stratégiques pour Microsoft qui veut s'imposer de plus en plus au niveau serveur. Contrairement à ce que tu racontes, 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. Et au fait, ASF n'est pas un codec mais un format de fichier...

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

          Parce que ça n'a aucun intérêt. Le bla bla sur Mono n'est pas plus dangereux que le noyau linux parce qu'il existe pleins de brevets logiciels n'apporte rien à la discussion et nie la spécifificité de .NET (ou de Java, c'est pourquoi je n'ai pas utilisé ce "non argument" au sujet de Java). Les brevets sur .NET on pour but explicite de protéger .NET, alors que les brevets qui peuvent toucher linux ont pour but de protéger certaines fonctionnalités qu'on peut être ammené à inclure dans un noyau. Ce n'est pas la même chose.

          Quant à la solution, elle est toute trouvée, obtenir l'accord officiel de Microsoft ou de Sun pour les implémentations open source de leur technologie. Et alors que tu te gargarises de documents sans valeur légale (comme le fameux mail tant cité), dans le monde Java, des accords officiels ont déjà été passés. C'est le point que les gens de mauvaise foi comme toi passent toujours sous silence : une partie de Java est implémenté en open source de façon officielle, avec l'accord signé de Sun. Il s'agit bien sur de la partie J2EE en version 1.4 implémentée par JBoss et par Jonas. C'est ces faits qui prouvent que la situation est différente : SUN est officiellement d'accord pour qu'au moins certaines parties de Java soient implémentées sous forme libre.

          Enfin, le bla bla sur la protection des utilisateurs est comique. Où sont les versions forkées de Perl et de Python, pour ne prendre que ces exemples ?

          En conclusion, je ne te trouve pas très constructif. Tu ne cesses de t'abriter derrière de supposition, en ne retenant des documents disponibles sur le web que les moins officiels et en refusant d'apprendre du passé. 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 ? Puisque que tu aimes les arguments d'autorité, pourquoi croire plus Novell que RedHat ?
          • [^] # Re: héhé

            Posté par  (site Web personnel) . Évalué à 2.

            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.
            • [^] # Re: héhé

              Posté par  (site Web personnel) . Évalué à 2.

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

              Putain, mais va lire le brevet ! Tu es borné ou quoi ? System.Collections c'est pas dans le standard, peut être ?

              Genre les tiens sont légals :)

              Je parle de valeur légale du document. Tu ne comprends pas le français ? Le texte d'accord de licence disponible sur le site de Sun est un document à valeur légale qui correspond à un engagement entre Sun et le signataire. Ce document indique explicitement qu'une implémentation de Jave en open source est possible, sans enfreindre les brevets associés. Il n'y a pas de document équivalent sur le site de Microsoft au sujet de .NET. Il n'y a que des documents sans valeur légale comme le fameux mail ou des interviews.

              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.


              La position officielle de RedHat est de ne pas distribuer Mono. On ne sait pas officiellement pourquoi.

              tu refuses de constater les faits.

              Quels faits ? Que les développeurs de MS aident ceux de Mono ? Et alors, pendant combien de temps Linus a-t-il utilisé bitkeeper ?

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

              On a bien compris. Je ne parle pas de danger mais de risque. Il est possible aujourd'hui de réaliser une implémentation Open source de Java, des documents qui engagent Sun sont disponibles sur le site correspondant. On ne sait pas si une implémentation complète existera un jour et on ne sait pas si d'autres brevets n'empêcherons pas cette implémentation. 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. Tu peux raconter tout ce que tu veux à ce sujet, je ne vois pas comment contourner ce fait.
              • [^] # Re: héhé

                Posté par  (site Web personnel) . Évalué à 2.

                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 ?
                • [^] # Re: héhé

                  Posté par  . Évalué à 4.

                  Euh System.Collections n'a strictement rien d'innovant, ils peuvent toujours essayer et obtenir un brevet, un prior art sera facile à démontrer.


                  Les entreprises comme Microsoft et Sun détiennent des brevets pour lesquels il est possible de démontrer un "prior art". Seulement qui dans le monde libre va leur faire un procès? Un procès est un processus long, couteux et pénible. En plus sur ce genre de problème, il faudrait faire un procès dans chaque pays ou zone juridique. Mêmes les multinationales qui ont des services juridiques capables de le supporter réflechissent à deux fois avant de faire un procès.


                  A la lecture de tes posts, tu sembles convaincu que Microsoft ne posera pas de problème par rapport à un projet libre comme Mono. En plus des divers liens donnés ici, j'aimerai rajouter une petite histoire:

                  Lorsque j'étais membre du bureau de la Junior Entreprise de mon école, j'ai eu à remplacer quelqu'un pour aller chez Microsoft. Je ne savais pas trop de quoi il s'agissait et une fois là bas je me suis retrouvé dans un brainstorming sur un projet de site web destiné à faire la promotion de Microsoft aux élèves d'écoles d'ingénieurs. Tout d'un coup la discussion a dérivé sur les licences et sur les logiciels libres. Je leur ai dis que je pensais qu'il était inutile pour eux de se justifier sur un tel site. Les employés de Microsoft sont devenus hargneux et m'ont fait clairement comprendre que le libre était l'enemi a abattre. Ils avaient presque la bave aux lèvres en disant que c'était "franco-français" (l'insulte suprême chez eux apparemment...) de penser qu'on pouvait tout avoir gratuitement et que ça allait détruire l'industrie du logiciel. Microsoft considère que les logiciels libres sont des concurrents et comme tout concurrent, ils doivent être soit écrasés soit réduit à une part de marché négligeable.
                  • [^] # Re: héhé

                    Posté par  . Évalué à 1.

                    C'est le but de la FSF, c'est pour cela qu'ils demandent aux devs de leur céder leur copyright afin de pouvoir protéger efficacement les LL en cas de procès.
  • # licence du doc

    Posté par  (site Web personnel) . Évalué à 2.

    Sans vouloir passer pour un intégriste, ta phrase m'a fait réfléchir :
    "J’ai pour objectif de faire évoluer l’article dans les mois qui viennent afin de le maintenir à jour."

    Je ne vois pas comment c'est compatible avec la licence retenue pour le document :
    "Cette création est mise à disposition selon le Contrat Paternité - Pas d’Utilisation Commerciale - Pas de Modification disponible en ligne http://creativecommons.org/licenses/by-nc-nd/2.0/fr/(...) "

    La licence précise "Chacune de ces conditions peut être levée si vous obtenez l'autorisation du titulaire des droits."

    A chaque page du PDF apparaît le copyright commun entre GMLF et toi-même, tu ne peux pas décider unilatéralement de faire une modification. ça c'est un 1er point.
    Perso, ce qui me gêne un peu plus c'est que si (à tout hasard) je souhaitais en faire une traduction en anglais, l'article pouvant intéresser un public plus large, je n'en ai pas la possibilité : seul toi et GLMF. ça m'empêche aussi de le mettre à dispo sur un wiki pour se mettre à plusieurs à le traduire (toutes les personnes n'étant pas forcément identifiées...).

    Si c'était l'effet souhaité, après ça te regarde (et GLMF).
    Y-avait-il un point bloquant à le mettre en CC-BY-SA par exemple ? Voire Art Libre ? (c'est une vraie question)
    • [^] # Re: licence du doc

      Posté par  (site Web personnel) . Évalué à 4.

      J'ai l'autorisation de Denis pour faire évoluer le document. Effectivement, personne d'autre ne peut faire des modifications et/ou des traductions. Comme j'ai vendu ce texte aux Editions Diamond, je trouve ça parfaitement normal. Cependant, il est tout à fait possible que j'obtienne un jour le droit de passer le texte en vraiment libre, ce que j'aimerais. Mais un refus des Editions Diamond me semblerait aussi parfaitement légitime. Bref, ce document, financé par les Editions Diamond, est mis à disposition du public gratuitement et si j'en ai le temps sera maintenu. C'est le mieux que je puisse faire actuellement.
    • [^] # Re: licence du doc

      Posté par  (site Web personnel) . Évalué à 1.

      Au fait, j'ai oublié un point très important : il est très peu probable que j'autorise la diffusion de versions modifiées. Ce texte comporte une grande partie factuelle, mais aussi mon opinion et je ne veux pas qu'une version modifiée reprenne les faits et propose une conclusion différente. Pour que j'autorise ça, il faudrait que le texte change de titre, et que ma conclusion reste présente verbatim (ou presque).
      • [^] # Re: licence du doc

        Posté par  (site Web personnel) . Évalué à 3.

        Tu peux lire cette analyse de la GFDL qui répond à quelques unes de tes craintes :
        http://home.twcny.rr.com/nerode/neroden/fdl.html(...)

        => oui tout texte, aussi factuel qu'il soit exprime ton opinion, mais :
        - la déformer constitue un faux que ta version en ligne permettra de corroborrer/infirmer
        - du fait du copyright, un texte dérivé porte le nom de l'auteur ayant fait les modifications... ce n'est plus seulement ton opinion qui est exprimée...

        Après faut choisir d'assumer de faire du libre ou pas : oui cela se passe sur le net visible de tout le monde, oui c'est beaucoup plus difficile à rattrapper quand par mégarde ou inattention on dit une bêtise, oui les rumeurs peuvent se propager à vitesse grand V... m'enfin faut pas être parano non plus je crois ;-)

        Ton article est de bonne facture et avait été salué à sa sortie si je me rappelle bien (je ne réussis plus à mettre la main sur une URL) néanmoins ça me paraît bizarre de choisir une licence à l'image même de ce que tu analyses (troll intended ;-) ).
        • [^] # Re: licence du doc

          Posté par  (site Web personnel) . Évalué à 2.

          Je comprends bien ton point de vue (j'espère ;-) et je vois bien ses justifications. Je ne sais pas trop quelle licence choisir pour un texte qui à la fois protège mon opinion et d'un autre côté permette une liberté maximale pour les utilisateurs et/ou éventuellement adaptateur et traducteur. Il est clair par exemple que si Timaniac prenait mon texte et l'adaptait à sa sauce, je serais vert et donc je ne veux pas ça. Par contre, une traduction, ça serait très bien. Je vais réflechir et en discuter de nouveau avec Denis Bodor.
  • # Alternative

    Posté par  . Évalué à 3.

    Si tu comptes faire évoluer, une piste serait peut être de parler des autres plateformes capables de concurrencer Java et .NET et de vérifier si elles sont vraiment libres.

    Personnellement, j'en vois deux: Erlang et Python.
    • [^] # Re: Alternative

      Posté par  (site Web personnel) . Évalué à 3.

      C'est effectivement une bonne piste, mais les langages sont très différents du couple Java/C# et les API beaucoup moins riches. Il est donc assez difficile de comparer, à mon avis.
      • [^] # Re: Alternative

        Posté par  . Évalué à 2.

        Au moins pour Python, l'API est tout aussi riche qu'en java...
        • [^] # Re: Alternative

          Posté par  (site Web personnel) . Évalué à 2.

          • [^] # Re: Alternative

            Posté par  . Évalué à 1.

            Non mais tu as ça
            http://www.python.org/doc/2.4.1/modindex.html(...)
            et ca
            http://twistedmatrix.com/(...)
            ou encore ca
            http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/Appendi(...)

            et si tu insistes tu as même ton api avec des structures de plus haut niveau
            http://www.onjava.com/pub/a/onjava/2002/03/27/jython.html(...)

            Jython also has features that allow nearly transparent usage of existing Java code. Java packages can be imported into Jython as though they were Jython modules, and Java objects can be created using Jython object creation syntax. For the most part, you can use the Java objects in your Jython program exactly as though they were Jython objects
            • [^] # Re: Alternative

              Posté par  (site Web personnel) . Évalué à 2.

              Oui, enfin, comme alternative à Java, Jython n'est pas très pertinent ;-)

              Il y a bien des choses très intéressantes qui tournent autour de Python mais franchement, l'API Java est tellement énorme que je doute vraiment qu'on trouve en Python tout ce qu'on trouve en Java. Par exemple, quid d'un moniteur transactionel à la JTA ?

              D'autre part et vraiment sans vouloir troller, existe-t-il en Python un IDE du nieavu d'Eclipse (ou de netbeans) ? Et les performances ? Je pense qu'on peut dire sans trop exagérer que les programmes Java sont tout de même plus performants en général que leur équivalent Python, non ?
              • [^] # Re: Alternative

                Posté par  (site Web personnel) . Évalué à 2.

                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.
                • [^] # Re: Alternative

                  Posté par  (site Web personnel) . Évalué à 3.

                  bon au lieux de troller comme des veaux allez coder des API pour Eiffel ou ADA ;)
                  • [^] # Re: Alternative

                    Posté par  (site Web personnel) . Évalué à 2.

                    Du calme ! On me suggère de parler dans mon article d'alternatives à .NET et à Java, et on me suggère Python et Erlang. Je ne connais pas le second. Pour le premier, je pense que la comparaison n'est malheureusement pas valide. Je dis bien malheureusement car je trouve que Python est un très beau langage. Ceci dit, c'est une question de maturité avant tout.

                    Quant à Eiffel et Ada, ce sont deux merveilleux langages, mais comme tu le dis indirectement, ils manquent énormément d'API et je ne vois pas ce qu'un pauvre développeur peut faire pour changer ça...
                • [^] # Re: Alternative

                  Posté par  . Évalué à 2.

                  Visiblement le monde de l'industrie evolue sur l'option de l'alternative faist son chemin
                  http://www.zdnet.fr/actualites/informatique/0,39040745,39233250,00.(...)

                  Le typage fort n'est pas forcément la panacée.
                  La philosophie de python est celle du unit testing qui est AMHA nettement plus sûr que le typage fort tout en luimitant les inconvénients au niveau du refactoring.
                  Certains projets proposent même d'introduire du typage fort progressivement dans ton code ce qui laisse la possibilté de prototyper rapidement et d'introduire plus de sécurité ensuite.

                  De même, il y a possibilté de faire de la programmation par contrat
                  de l'AOP, les decorator, bref Python n'a pas à rougir à cpté des dernières features Java.


                  Les interfaces: Python supporte l'heritage multiple mais mieux que ca on dispose du "duck typing" qui est encore plus souple. Si ton animal nage, court et fait coin coin c'est que c'est un canard, inutile de le préciser.


                  Les performances ne sont pas les seuls critères à prendre en compte dans le cadre d'un dévelopement, il y a aussi la productivité , la maintenabilité, la liberté, .....
                  Mais même sur ce point c'est contestable (J'avais vu des benchs surprnant sur ce point nottamment avec Psycho)
                  En outre il est toujours possible d'optimiser des parties de codes avec du compilé natif et les passerelles sont beaucoup plus aisée qu'avec du JNI.

                  Bref nous voilà parti dans un beau troll des familles.

                  Pour la conception, il suffit de voir les alternatives à J2EE qui fleurissent un peu partout y compris dans le monde Java pour comprendre que ce n'est pas la panacée notamment à cause de sa lourdeur. Et à la différence de Java ou C# , les évolutions y compris en terme de conception sont plus rapides avec Pyhton notamment en raison de son faible typage et de ses structures de haut niveau.

                  Que vous argumentiez en disant qu'il s'agit d'une technologie encore immature OK mais réduire Python à un simple langage de script alors là STOP.
                • [^] # Re: Alternative

                  Posté par  . Évalué à 3.

                  Tu mélanges un peu tout:

                  - le typage fort est bien pour détecter les erreurs à la compilation, mais le typage de Java n'est pas non plus super contraignant: pour cela il faudrait regarder du côté d'ADA ou d'Eiffel avec la programmation par contrat...
                  - ce n'est pas parce que tu n'as pas trouvé d'usage "industriel" de la modification dynamique d'une classe qu'il n'y en pas. (Moi j'en vois un: mettre à jour un programme sans l'arrêter.)
                  - quel est le rapport entre la notion d'interface et la sécurité?


                  • [^] # Re: Alternative

                    Posté par  (site Web personnel) . Évalué à 2.

                    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.
                    • [^] # Re: Alternative

                      Posté par  . Évalué à 3.

                      Tu cherches un concurrent ou une copie? Ou alors pour toi un concurrent crédible doit être obligatoirement un Java amélioré?

                      >Ah parcqu'en Java on est obligé d'arrêter le programme ?

                      Tu fais comment? Je n'ai pas vu cette possibilité dans Java...

                      >Pourtant moi j'y vois surtout des inconvénients.

                      Lesquels? Si tu n'utilises pas cette possiblité, elle ne va pas te manger!

                      >il suffit de lire un bouquin de design pattern pour s'apercevoir que beaucoup de collaboration font appelle à des interfaces.

                      Tu veux dire "un bouquin de Design Pattern appliqué à Java"? Si tu en lis un consacré à Python, ils implémenteront ça d'une autre façon.
                      • [^] # Re: Alternative

                        Posté par  (site Web personnel) . Évalué à 2.

                        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é.
                      • [^] # Re: Alternative

                        Posté par  (site Web personnel) . Évalué à 2.

                        Tu fais comment? Je n'ai pas vu cette possibilité dans Java...

                        On utilise une astuce basée sur les classloaders. Quand tu charges une classe, elle est en fait chargée par une classe spéciale, le classloader. Si tu veux charger une nouvelle version de cette classe, il suffit de changer de classloader. Ca marche très bien, mais ce n'est quand même pas automatique, ça demande une certaine programmation, contrairement à ce que semble dire Timaniac.
                • [^] # Re: Alternative

                  Posté par  (site Web personnel) . Évalué à 3.

                  Python est avant tout un langage de script

                  De même que Java est un langage destiné à faire des applets. Tu n'en as pas marre de passer ton temps à troller ?
                  • [^] # Re: Alternative

                    Posté par  (site Web personnel) . Évalué à 2.

                    De même que Java est un langage destiné à faire des applets.
                    Et ? Quel est le rapport avec ma phrase ?
                    Je dis que Python est un langage de script, c'est un fait. L'utilisation que tu fais d'un langage comme Java dépend de ses API et peut fluctuer.
                    Je vois pas où est le troll, j'essai de montrer que les avantages de Python réside dans ses choix de conception "dynamique", et qui sont tout à fait pertinent dans un contexte de langage de script. Dans un contexte d'application côté serveur où l'on recherche les perfs mais aussi la sécurité, Python n'a plus aucun intérêt face aux autres solutions.
                    C'est pas parcque tu vas réussir à manger un steack avec une cuillère que c'est pertinent.
              • [^] # Re: Alternative

                Posté par  . Évalué à 3.

                Je ne connais pas bien JTA, mais je suis en train d'écrire un utilitaire de synchronisation de bases de données en Erlang et je m'en passe très bien, car ce langage a toutes les API nécessaires pour implémenter des transactions.

                Pour Python, il me semble qu'il existe plusieurs solutions de persistence et donc il doit y avoir de quoi gérer les transactions.

                Côté performance, c'est difficile de comparer, mais on peut voir que Java et Python sont assez proche sur ce test: http://shootout.alioth.debian.org/benchmark.php?test=all&lang=all&sort=fullcpu&calc=Calculate&xfullcpu=1&xmem=0&xloc=0&ackermann=1&binarytrees=5&wc=3&fannkuch=3&fasta=3&harmonic=1&knucleotide=4&mandelbrot=4&nbody=3&nsieve=3&nsievebits=2&methcall=0&pidigits=2&random=3&raytracer=5&regexmatch=4&revcomp=3&spectralnorm=2&spellcheck=4&hello=0&sumcol=3&takfp=1&tcpecho=2&tcprequest=4&tcpstream=3&process=2&message=5&wordfreq=5

                Erlang est bien en dessous, mais il n'y a pas de comparaison en environnement distribué...

                Au niveau IDE, qu'il y a des plugins Python et Erlang pour Eclipse.
                • [^] # Re: Alternative

                  Posté par  (site Web personnel) . Évalué à 2.

                  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.
                  • [^] # Re: Alternative

                    Posté par  . Évalué à 2.

                    Que tu trouves que l'intégration de Java/C# soit un point positif rend-t-il impossible l'utilisation de plateforme plus hétéroclyte comme alternative?
                    • [^] # Re: Alternative

                      Posté par  (site Web personnel) . Évalué à 2.

                      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.
                • [^] # Re: Alternative

                  Posté par  (site Web personnel) . Évalué à 2.

                  Le benchmark que tu cites est totalement merdique et débile. Les micro benchmark défavorisent fortement les langages comme Java et Python (et C#, d'ailleurs). Ca ne prouve rien du tout, ni dans un sens, ni dans l'autre.
      • [^] # Re: Alternative

        Posté par  . Évalué à 3.

        Concurrencer ne veut pas dire faire la même chose avec les mêmes solutions. Ce n'est pas parce que Python, Erlang ou PHP ne sont pas identiques de C# et Java que leur utilisation n'est pas pertinente pour les mêmes types d'applications.

        Pour la réalisation de sites webs, par exemple, toutes ces plateformes proposent des approches différentes adaptés à leurs langages, leurs API...
        • [^] # Re: Alternative

          Posté par  (site Web personnel) . Évalué à 0.

          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.
          • [^] # Re: Alternative

            Posté par  . Évalué à 1.


            Python est lent, pour un site web


            Ca va faire plaisir à tous ces gens ce que tu dis
            http://www.zope.org/Resources/Testimonials(...)
            http://www.weblmi.com/manage_copyright(...)

            Bon d'accord y'a peut-être pas de transactionnel là-dedans mais il faut laisser le temps au temps, l'API J2EE ne s'est pas créée en un jour que je sache.

            En plus ce sont peut-être pas les mêmes niches de marché.
            Une PME n'a pas forcément les moyens de payer des millions pour une solution B2C de la mort qui tue en J2EE.
            • [^] # Re: Alternative

              Posté par  (site Web personnel) . Évalué à 1.

              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.
              • [^] # Re: Alternative

                Posté par  . Évalué à 1.

                Sauf que ce que j'explique c'est que c'est en train de changer.
                Je ne prétends pas pas que la technologie Zope/Python peut encore se mesurer aux grand comptes mais elle est en train de monter et ca pourrait changer.

                Zope est un véritable serveur d'application et supporte le transactionnel.
                La charge, je ne sais pas, je ne suis pas "Zope architect" ;-)

                En tout cas je n'ai pas l'impression que l'audience de Gnu linux magazine (cf. sujet du journal) correspondent principalement à des "daicideurs" de grands comptes donc pour moi Zope/Plone/Python est une bonne alternative qui aurait pu figurer dans cette étude.

                C'est tout.
                • [^] # Re: Alternative

                  Posté par  (site Web personnel) . Évalué à 2.

                  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.
            • [^] # Re: Alternative

              Posté par  . Évalué à 1.

              Et juste pour montrer qu'il y a tout ce qui faut avec Zope en tant que serveur d'application

              une petite table de comparaison
              http://www.boddie.org.uk/python/web_modules_enterprise.html(...)
              • [^] # Re: Alternative

                Posté par  (site Web personnel) . Évalué à 2.

                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 ?
                • [^] # Re: Alternative

                  Posté par  . Évalué à 1.

                  RMI pas besoin, tu as Corba pour ca au moins c'est multilangage mais en cherchant un peu je suis sûr qu'on peut trouver.

                  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

                  Concernant la table , les equivalences sont sur la plateforme Zope ce qui montre que cette plateforme est quasi- complète et donc intégrée.

                  Il faut aussi comprendre que la plateforme est dédiée au langage donc qu'il est nullement obligatoire de respecter le JSR??? pour proposer un serveur d'application équivalent.

                  L'avantage de python c'est qu'il est versatile et ne cible pas uniquement le monde du Web il s'exprime pleinenent sur le poste de travail car il s'intègre bien avec tout un tas de toolkit.

                  Quand t'as un programme qui doit effectuer des manips sur le poste, des fois le modèle de sécurité de Java, il est pesant

                  Quant aux parts de marché, Zope n'est pas soutenu par les mastodontes commme IBM BEA Sun & Co donc forcément ca ce ressent mais les entreprises appéecient de plus en plus la liberté y compris de technologie.
                  • [^] # Re: Alternative

                    Posté par  (site Web personnel) . Évalué à 1.

                    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.
                    • [^] # Re: Alternative

                      Posté par  . Évalué à 1.

                      Oui mais Corba ne te limite pas à l'usage d'un langage.
                      Corba c'est un protocole et un standard. Ce sont les impléméntations qui divergent.

                      Mono implémente son propre protocole dans son coin (.net remoting je suppose) tout comme RMI


                      Oué mais là ca n'a pas plus d'intérêt que C#/Mono qui a les mêmes avantage. ....

                      Et là ca ne te dérange plus de changer de techno et de langage, bizarre.


                      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.

                      Ou peut être qu'il y a pas assez de business à se faire et qu'il ont déjà pas mal investi dans java au moment ou zope a démarré. Python a surtout évolué ces denières années.

                      D'ailleur c'est pas les mêmes qui on créé un tk graphique pour concurrencer un autre parce qu'il le trouvait "inadapté".
                      Qui sait ? ils finiront peut être par comprendre que c'est la même chose avec Java

                      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.
                      L'engouement de la communauté du libre est assez récent..
                      L'avantage avec python c'est son coté dynamique lui permet d'evoluer très vite.

                      Bref on est dans du plus pur troll.
                      Merci pour ton point de vue mais je crois que chacun campera sur ses positions
                      ===> [ ]
                      • [^] # Re: Alternative

                        Posté par  (site Web personnel) . Évalué à 1.

                        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.
          • [^] # Re: Alternative

            Posté par  . Évalué à 2.

            Si tu as 100000 utilisateurs avec gestion de transactions, Erlang n'est-il pas plus pertinent que Java?
            • [^] # Re: Alternative

              Posté par  (site Web personnel) . Évalué à 2.

              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 ;)
              • [^] # Re: Alternative

                Posté par  . Évalué à 2.

                Pour une architecture n-tiers classique,avec vraiment besoin de puissance, je verrais comme alternative à J2EE:

                - un cluster Erlang côté serveur pour les traitements.
                - un serveur Yaws pour l'interface web.
                - un client lourd écrit en Python ou même en C++.

                L'ensemble a de grandes chances d'être plus performant qu'un ensemble 100% Java, car Erlang n'est peut être pas performant pour les calculs, par contre sa gestion des processus et du réseau est beaucoup plus légère que celle de Java. De plus si tu as besoin de puissance, tu ajoutes une ou deux machines au cluster pour gérer la montée en charge.

                Comme mesure de performance d'Erlang (et surtout Yaws) dans le domaine web, je connais ce comparatif: http://www.sics.se/~joe/apachevsyaws.html

                Peut être que quelqu'un en a d'autre?
                • [^] # Re: Alternative

                  Posté par  (site Web personnel) . Évalué à 1.

                  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 ?
                  • [^] # Re: Alternative

                    Posté par  . Évalué à 2.

                    Erlang est fait pour faire des applications réseaux et des clusters, autant l'utiliser dans une configuration qui convient. Surtout si tu veux gérer des centaines de millers de client.

                    Mais ça marche très bien avec de petites configs, car la gestion de la concurrence (très importante pour ce genre d'applications) est très légère par rapport à Java. Mon wiki tourne sous Yaws sur ma vieille machine (P700) avec une connexion 512 et est réactif même avec de gros téléchargements en parallèle.

                    Dans l'architecture décrite, c'est Yaws (http://yaws.hyber.org/) qui correspond aux JSP.

                    Pour remplacer RMI, on peut faire du RPC (qu'est-ce que ça de ridicule? RMI est un mécanisme de type RPC...) ou utiliser le système de messages d'Erlang (accessible via des API C++, Python, Java, C#).

                    Pour les web services, je n'en ai jamais fait avec Erlang donc je ne sais pas comment ça marche.

                    Pour la maintenance, je ne vois pas quel problème tu auras en plus par rapport à une solution J2EE (à part la difficulté de trouver des gens compétents dans cette technologie, mais là c'est un problème de type l'oeuf et la poule...).

                    Un exemple proche de ma "combo qui tue" était mon projet de fin d'étude: 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.



                    • [^] # Re: Alternative

                      Posté par  (site Web personnel) . Évalué à 2.

                      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.
                      • [^] # Re: Alternative

                        Posté par  . Évalué à 2.

                        Faut sortir un peu du monde java de temps en temps! Le terme RPC désigne à la fois un paradigme et un protocole (celui de Sun il me semble). En tant que paradigme, RMI c'est du RPC appliqué aux langages objets. Si pour un autre langage tu compares les versions Java de RPC et RMI, ça n'a pas de sens. Surtout ici où Erlang est un langage fonctionnel, non objet et donc pour lequel invoquer des "méthodes" ne correspond à rien. Pour te montrer un peu à quoi ressemble Erlang, voici le code d'un serveur RPC ( tiré de http://www.unsw.adfa.edu.au/~lpb/seminars/erlang-intro.html(...) ):
                        %%% start - rexec server on this node
                        start() -> 
                            Pid = spawn(rexec, server, []),
                            register(rexec, Pid),
                            Pid.
                        
                        %%% server - master server loop listening for next message
                        server() ->
                            receive
                                {From, Ref, M, F, A} ->
                                    io:format("rexec: handling ~w~n", [{From, Ref, M, F, A}]),
                                    spawn(rexec, handler, [From, Ref, M, F, A]),
                                    server();
                                Error ->
                                    io:format("rexec: ERROR received~w~n", [Error]),
                                    server()
                            end.
                        
                        %%% handler -> handle current rexec request
                        handler(From, Ref, M, F, A) ->
                            Res = (catch apply(M, F, A)),
                            From ! {Ref, Res},
                            Res.
                        
                        Je l'ai dis, le support de plateformes et technos hétérogènes.
                        Tu l'as dit, mais pas expliqué. Même avec J2EE tu auras d'autres technologies qui rentreront en jeu, ne serait-ce que Javascript, SQL, XML... L'architecture que je propose se base sur deux outils (et encore on pourrait tout faire avec un seul), pas 10000. Tu ne te sers que d'une fourchette pour manger? Pas de couteau et de cuillère parce que ce n'est pas intégré et unifié? :-)
                        C'est bien ce que je dis, ca ressemble plus à du LAMP
                        Dans ce projet, on aurait pu tout faire avec Python, Erlang ou PHP, mais nous voulions apprendre ces technologies. De plus, LAMP est aussi intégré que Java: L pour Linux, Java a besoin d'un OS pour le faire tourner. A pour Apache, une interface web même J2EE demande un serveur web. M pour MySQL, il y a aussi une base de données derrière ton système Java. P pour PHP, c'est ici que Java prends place. 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).
                        • [^] # Re: Alternative

                          Posté par  (site Web personnel) . Évalué à 2.

                          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.
                          • [^] # Re: Alternative

                            Posté par  . Évalué à 2.

                            Si par "évoluer", tu veux dire copier une à une les fonctionnalités de Java/.NET, effectivement les seules plateformes que tu vas trouver sont les implémentations libres de Java/.NET.

                            L'alternative oui, mais identique.
                            • [^] # Re: Alternative

                              Posté par  (site Web personnel) . Évalué à 2.

                              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.
                              • [^] # Re: Alternative

                                Posté par  . Évalué à 2.

                                Alors oublie l'idée d'un framework libre de ce type qui ne soit pas une implémentation d'un propriétaire.

                                Pour avoir un framework aussi intégré, il faut une et une seule vision que tu n'auras pas avec des développeurs libres d'implémenter leurs idées sans contraintes.

                                Le libre préfère l'intéropérabilité à l'intégration, sinon on aurait un seul environnement graphique, un seul système de fichier, un seul navigateur web, une seule API...
                                • [^] # Re: Alternative

                                  Posté par  (site Web personnel) . Évalué à 2.

                                  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.
                                  • [^] # Re: Alternative

                                    Posté par  . Évalué à 2.

                                    freedesktop.org et les autres initiatives du même genre c'est de l'intéropérabilité pas de l'intégration telle que tu l'as décris. De plus n'importe qui peut s'en écarter s'il y trouve un intérêt.

                                    Si l'implémentation de frameworks propriétaires est possible en libre, c'est parce qu'il n'y a pas de choix de conception à faire. Implémenter une norme prête beaucoup moins à discussion que définir une norme.

                                    C'est juste que le libre n'a pas les moyens de gérer un framework de cette ampleur.


                                    Pas les moyens ou pas le besoin? Certainement un peu des deux, mais beaucoup de développeurs sont satisfaits d'utiliser LAMP&co et sont plus productifs avec.

                                    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.


                                    Pas pour le plaisir, mais pour pleins de raisons:

                                    - avoir des outils vraiment libres, non soumis à des brevets et des contraintes légales (actuelles ou potentielles).
                                    - pour innover.
                                    - parce que la norme n'évolue pas assez vite.
                                    - pour palier à des défauts de conception fondamentaux de ces plateformes.
                                    - parce que telle fonctionnalité n'existe pas ou est mal géré par la norme
                                    - parce que se faire dicter la loi par une norme propriétaire est pénible.
                                    ...
                                    - parce que il y aura toujours quelqu'un pour avoir un besoin spécifique qui lui fera choisir une voix différente!

                                    Et puis je ne dis pas "le libre DEVRAIT", mais "le libre PROPOSE". Si les solutions que j'utilise ne sont pas des alternatives à J2EE et .NET pour toi tant pis. Elles le sont pour moi et pour nombre de développeurs.

                                    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.
                                    • [^] # Re: Alternative

                                      Posté par  (site Web personnel) . Évalué à 2.

                                      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 :)
                                    • [^] # Re: Alternative

                                      Posté par  (site Web personnel) . Évalué à 2.

                                      [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.
                                      • [^] # Re: Alternative

                                        Posté par  . Évalué à 2.

                                        <blockquote> : c'est relativement nouveau dans le monde du libre </blockquote>

                                        Ce n'est pas du tout nouveau dans le libre, Java et C# puisent beaucoup de leurs idées des plateformes Objective C et Smalltalk.
                                        • [^] # Re: Alternative

                                          Posté par  (site Web personnel) . Évalué à 2.

                                          Comme d'hab je parle de l'ensemble, du niveau d'intégration des API dans la plateforme, pas des langages en soit.
                                          • [^] # Re: Alternative

                                            Posté par  . Évalué à 2.

                                            Parce qu'Objective C et Smalltalk n'ont pas d'API, pas d'environnement? Et OpenStep? Et Cocoa? Et Squeak?

                                            Je n'y avais pas penser mais ces plateformes sont peut être aussi de bonnes alternatives à J2EE. A étudier...

                                            Sinon, je viens de lire la dépêche sur Ruby on Rail, ça a l'air pas mal aussi.
                                            • [^] # Re: Alternative

                                              Posté par  (site Web personnel) . Évalué à 2.

                                              La plateforme autour d'Objective-C, notamment par Apple, est effectivement un bon exemple de plateforme complète, mais uniquement pour le desktop. Pour ce qui concerne les serveurs d'application par contre c'est pas du tout ca à mon avis.

                                              Pour Ruby on Rails, ca semble être un joli jouer pour faire du RAD, mais pour faire une vrai grosse appli 3-tiers, c'est pareil c'est pas du tout comparable à J2EE. Tout celà allié à la vélocité (hem) de Ruby tu vas rigoler à la monter en charge.
                                              • [^] # Re: Alternative

                                                Posté par  . Évalué à 3.

                                                Bon ce n'est pas la peine d'insister, si ça n'est pas J2EE ou .NET tu n'en voudras quoi qu'on te propose puisque ces deux plateformes représentent la perfection, l'aboutissement ultime en matière de développement et que tout ce qui ose en dévier ne serait-ce que d'une ligne de code ne mérite qu'un profond mépris.

                                                Quand je vois en ce moment même comment .NET rame pour afficher la moindre fenêtre sur mon Pocket PC et qu'il s'agit d'une tes références en terme de performance...
                                                • [^] # Re: Alternative

                                                  Posté par  (site Web personnel) . Évalué à 2.

                                                  Ah mais j'insiste seulement pour dire qu'il n'y a MALHEURESEMENT pas d'équivalent à ces 2 plateformes. Je trouve ca dommage qu'il n'y est pas eu d'initiative libre et indépendante pour en créer une. Je constate, mais en même temps je comprends : rassembler une bande de hacker pour coder un soft OK, mais rassembler toute une troupe d'architecte dans une même pièce (le braiinstroming à distance c'est pas encore ca) pour concevoir l'architecture d'une telle plateforme, ben, c'est pas tellement à la portée de n'importe quel communauté du libre :-(.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.