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 !
Journal Java, .NET et les logiciels libres
16
juin
2005
# héhé
Posté par TImaniac (site web personnel) . Évalué à 5.
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 boubou (site web personnel) . Évalué à 5.
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 TImaniac (site web personnel) . Évalué à 3.
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 M_Skylight2 . Évalué à 2.
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 boubou (site web personnel) . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 2.
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 boubou (site web personnel) . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 2.
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 boubou (site web personnel) . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 2.
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 M_Skylight2 . Évalué à 2.
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 boubou (site web personnel) . Évalué à 2.
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 M_Skylight2 . Évalué à 0.
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 TImaniac (site web personnel) . Évalué à 2.
[^] # Re: héhé
Posté par boubou (site web personnel) . Évalué à 2.
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 boubou (site web personnel) . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 2.
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 boubou (site web personnel) . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 2.
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 bobefrei . Évalué à 4.
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 M_Skylight2 . Évalué à 1.
# licence du doc
Posté par BAud (site web personnel) . Évalué à 2.
"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 boubou (site web personnel) . Évalué à 4.
[^] # Re: licence du doc
Posté par boubou (site web personnel) . Évalué à 1.
[^] # Re: licence du doc
Posté par BAud (site web personnel) . Évalué à 3.
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 boubou (site web personnel) . Évalué à 2.
# Alternative
Posté par bobefrei . Évalué à 3.
Personnellement, j'en vois deux: Erlang et Python.
[^] # Re: Alternative
Posté par boubou (site web personnel) . Évalué à 3.
[^] # Re: Alternative
Posté par norbs . Évalué à 2.
[^] # Re: Alternative
Posté par TImaniac (site web personnel) . Évalué à 2.
http://java.sun.com/j2ee/1.4/docs/api/index.html(...)
?
[^] # Re: Alternative
Posté par golum . Évalué à 1.
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(...)
[^] # Re: Alternative
Posté par boubou (site web personnel) . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 2.
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 vrm (site web personnel) . Évalué à 3.
[^] # Re: Alternative
Posté par boubou (site web personnel) . Évalué à 2.
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 golum . Évalué à 1.
Ruby on Rails
http://linuxfr.org/2005/06/18/19160.html(...)
Si tu as un avis eclairé là dessus?
[^] # Re: Alternative
Posté par golum . Évalué à 2.
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 bobefrei . Évalué à 3.
- 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 TImaniac (site web personnel) . Évalué à 2.
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 bobefrei . Évalué à 3.
>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 TImaniac (site web personnel) . Évalué à 2.
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 boubou (site web personnel) . Évalué à 2.
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 boubou (site web personnel) . Évalué à 3.
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 TImaniac (site web personnel) . Évalué à 2.
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 bobefrei . Évalué à 3.
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®exmatch=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 TImaniac (site web personnel) . Évalué à 2.
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 bobefrei . Évalué à 2.
[^] # Re: Alternative
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Alternative
Posté par boubou (site web personnel) . Évalué à 2.
[^] # Re: Alternative
Posté par bobefrei . Évalué à 3.
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 TImaniac (site web personnel) . Évalué à 0.
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 golum . Évalué à 1.
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 TImaniac (site web personnel) . Évalué à 1.
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 golum . Évalué à 1.
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 TImaniac (site web personnel) . Évalué à 2.
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 golum . Évalué à 1.
une petite table de comparaison
http://www.boddie.org.uk/python/web_modules_enterprise.html(...)
[^] # Re: Alternative
Posté par TImaniac (site web personnel) . Évalué à 2.
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 golum . Évalué à 1.
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 TImaniac (site web personnel) . Évalué à 1.
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 golum . Évalué à 1.
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 TImaniac (site web personnel) . Évalué à 1.
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 bobefrei . Évalué à 2.
[^] # Re: Alternative
Posté par TImaniac (site web personnel) . Évalué à 2.
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 bobefrei . Évalué à 2.
- 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 TImaniac (site web personnel) . Évalué à 1.
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 bobefrei . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 2.
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 bobefrei . Évalué à 2.
%%% 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.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é? :-) 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 TImaniac (site web personnel) . Évalué à 2.
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 bobefrei . Évalué à 2.
L'alternative oui, mais identique.
[^] # Re: Alternative
Posté par TImaniac (site web personnel) . Évalué à 2.
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 bobefrei . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 2.
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 bobefrei . Évalué à 2.
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.
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.
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 TImaniac (site web personnel) . Évalué à 2.
BOn ben je suis à moitié tocher donc sur ce je te souhaites une bonne nuit @ plus dans l'buds :)
[^] # Re: Alternative
Posté par TImaniac (site web personnel) . Évalué à 2.
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 bobefrei . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Alternative
Posté par bobefrei . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 2.
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 bobefrei . Évalué à 3.
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 TImaniac (site web personnel) . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.