Dans cette interview, de Icaza présente entre autres les évolutions qu'apportera la prochaine version de Mono : l'API Windows.Forms, C# 2.1, portages vers les architectures 64 bits et de nouveaux ports, support de Java et d'autres langages, etc. Bien sûr, les problèmes liés aux brevets logiciels, souvent critiqués dans ce projet, sont aussi évoqués.
O'Reilly est un éditeur spécialisé dans les ouvrages traitant de l'informatique.
Aller plus loin
- L'interview (1 clic)
- Mono (2 clics)
- Son blog (1 clic)
# Quelques liens utiles
Posté par j (site web personnel) . Évalué à 8.
Débat 15 j + tard : http://linuxfr.org/2004/07/16/16823.html(...)
et l'article sur Wikipedia : http://fr.wikipedia.org/wiki/Mono(...)
[^] # Re: Quelques liens utiles en français
Posté par j (site web personnel) . Évalué à 3.
Acueil : http://monodevelop.org/lang/fr/(...)
Didacticiels : http://monodevelop.org/lang/fr/tutorial.aspx(...)
"Hello World" : http://monodevelop.org/lang/fr/tutorials/helloworld.aspx(...)
# Utilité de Mono
Posté par spirit . Évalué à 2.
[^] # Re: Utilité de Mono
Posté par vrm (site web personnel) . Évalué à 4.
[^] # Re: Utilité de Mono
Posté par Jiel (site web personnel) . Évalué à 1.
Bof. Les winforms, GTK#, le C# ou le Java, je trouve ça dommage de mettre ça en avant pour faire des logiciels libres. La communauté du logiciel libre a assez de bon langages... J'ai l'impression que Mono "cautionne" le monde de l'informatique propriétaire, comme si le libre était incapable d'innover! On peut être curieux et observer ce qui se passe dans l'informatique en général, mais améliorons plutôt nos outils avant d'essayer de refaire ceux des autres!
Et je parle pas des risques légaux, le rêve des éditeurs de logiciels propriétaires, c'est de voir une toute petite ligne à eux dans un gros soft libre: ainsi le soft ne serait plus du tout libre! D'autre part, est-ce qu'un logiciel libre ne marchant qu'avec une machine virtuelle java propriétaire peut vraiment être qualifié de "libre"?
Bref Miguel s'amuse et c'est son droit, mais je suis pas sûr que ca soit d'un grand intérêt pour la communauté.
[^] # Re: Utilité de Mono
Posté par TImaniac (site web personnel) . Évalué à 5.
- proposer une plateforme moderne, libre et performante pour Linux (ce qui exclu déjà pas mal de "beaux" outils comme tu dis), bref une alternative à Java.
- proposer une solution au problème récurant de la nécessité de maintenir pleins de bindings pour différents langages dans certains environnement, MDI ayant bien entendu Gnome derrière la tête. MDI veut proposer autre chose que des libs écrites en C aux programmeurs, et le C# semble un bon compromis entre sécurité/productivité et performances/intégration de l'existant.
- MDI veut attirer des développeurs venant de Windows, et même s'il attire ne serait-ce que 1% des développeurs Windows, je te laisse imaginer l'impact sur la communauté Linux :).
- MDI fait aussi un pari : il sait pertinament que cette plateforme a un avenir (parcque MS s'y est jeté) et que la plateforme .NET sera incontournable dans le futur, qu'on le veuille ou non. Proposer une compatiblité avec cette plateforme c'est aussi par soucis d'interopérabilité, au même titre que OOo gère le .doc ou que Samba existe.
D'autre part, est-ce qu'un logiciel libre ne marchant qu'avec une machine virtuelle java propriétaire peut vraiment être qualifié de "libre"?
D'où l'intérêt de proposer des VM libres tient :)
Mono a en plus l'avantage d'être multi-plateforme, le projet n'étant pas une simple VM pour Linux, mais une implémentation pour de nombreuses plateformes matérielles.
J'espère t'avoir convaincu que cette plateforme peu apporté quelque chose à la communauté Linux.
[^] # Re: Utilité de Mono
Posté par Jiel (site web personnel) . Évalué à 5.
Il va peut etre attirer quelques amoureux du C#. Les autres, s'ils n'ont pas déjà migrés sous GNU/Linux, c'est qu'ils ont leurs raisons.
[^] # Re: Utilité de Mono
Posté par fabb . Évalué à 2.
Dans ce domaine, le projet Gnome ne l'a jamais suivi. J'ai aucune crainte. C# sera un binding parmis d'autre.
[^] # Re: Utilité de Mono
Posté par TImaniac (site web personnel) . Évalué à 2.
Je croyais que c'était MDI qui avait préconisé le langage C dans Gnome parcque justement facile à binder... En tout cas ca se vérifie très bien, suffit de voir KDE le bordel que c à binder leur C++ bizzare.
[^] # Re: Utilité de Mono
Posté par fabb . Évalué à 1.
Ben oui et il avait raison. Mais il a proposé C# afin de facilité les bindings et il s'est fait renvoyé dans les choux.
Pour un binding, Gnome ne propose pas par exemple python->C# et C# fait le reste vers les librairies C. Gnome propose python->C, java->C, perl->C, etc...
[^] # Re: Utilité de Mono
Posté par TImaniac (site web personnel) . Évalué à 2.
Gnome ne propose pas par exemple python->C#
C'est pas du tout l'idée. L'idée c'est C# -> CLR -> C et Python -> CLR -> C. Et ca s'appelle IronPython, un compilateur Python pour .NET.
[^] # Re: Utilité de Mono
Posté par fabb . Évalué à 1.
Effectivement. Il ne l'a dit qu'au début de Mono. Après, il ne l'a plus jamais proposé (à ma connaissance).
> C'est pas du tout l'idée. L'idée c'est C# -> CLR -> C et Python -> CLR -> C.
Oui. Désolé pour mon imprécision.
[^] # Re: Utilité de Mono
Posté par Nicolas Évrard (site web personnel) . Évalué à 3.
Gnome ne propose pas par exemple python->C#
C'est pas du tout l'idée. L'idée c'est C# -> CLR -> C et Python -> CLR -> C. Et ca s'appelle IronPython, un compilateur Python pour .NET.
Tiens en parlant d'IronPytho, CPython est surtout très apprécié pour l'immense bibliothèque de module disponible, ces modules sont pour certains écrits en python (et alors tout va bien) mais pour tout ceux qui sont écrit en C, est-ce qu'il ne risque pas de ralentir l'adoption d'IronPython car indisponibles sous cette implémentation ?
On le voit avec Jython, c'est une implémentation vraiment intéressante mais très peu utilisée car elle ne vient pas avec "les batteries inclues" comme on dit.
Évidemment les performances annoncées par IronPython sont impressionantes mais si les bibliothèques ne suivent pas j'ai bien peur que cette implémentation reste quelque peu marginale.
On me dira qu'on s'en fout puisque de toute façon les bibliothèques seront là via la magie de la CLR, ben oui c'est vrai mais alors on court le risque d'un split de la communauté en deux ... enfin qui vivra verra.
PS: À quand un compilateur scheme -> CLR ?
[^] # Re: Utilité de Mono
Posté par TImaniac (site web personnel) . Évalué à 4.
http://www.cs.indiana.edu/~jgrinbla/index.htm(...)
[^] # Re: Utilité de Mono
Posté par Nicolas Évrard (site web personnel) . Évalué à 2.
[^] # Re: Utilité de Mono
Posté par fabb . Évalué à 5.
Petite démo :
http://people.redhat.com/overholt/nativeeclipse/index.html(...)
Devrait être dispo "out of the box" pour FC4. C'est dans FC4T1.
[^] # Re: Utilité de Mono
Posté par thaodalf . Évalué à 3.
les entreprises s'attendent a avoir les meme fonctionnalité vu que mono est présenté comme un mirroir a .net mais en faite mieux faut s'orienter vers d'autre technologie qui sont synchrone entre leur version windows et unix. ca montre beaucoup plus la "force" des LL multiplatforme.
[^] # Re: Utilité de Mono
Posté par Unixfix le Gaulois . Évalué à 4.
Ce qui m'etonnera toujours c'est son entetement a s'accrocher a Microsoft. D'abord son clone d'outlook (evolution) et maintenant Mono son clone de la platforme .NET de M$.
Ce qui est aussi particulierement etonnant c'est la description des avantages de Mono. On croirait entendre Bill.....
[^] # Re: Utilité de Mono
Posté par zerbro . Évalué à 9.
Quoiqu'on en dise MS est une formidable source d'inovation, recherche etc.. etc... Autant on peut critiquer leurs politiques commerciale et autres (et je suis le 1er), que leurs logiciels ne respectent pas assez l'utilisateurs -trop buggé etc... (et je suis encore le 1er), autant on ne peut pas critiquer le fait que leurs idées sont souvent _tres_ bonnes.
D'ailleur evolution est, pour moi, de loin le meilleur logiciel de messagerie (et c'est bien plus que ca d'ailleur) sous linux. Donc merci MDI d'avoir cloné outlook pour faire evolution.
Et pour finir, j'ajouterais que MS fait de la recherche et que leurs travaux sont qd meme vraiment exellent (je parle de leurs articles etc... et qui sont accessibles en ligne).
svp arreton de crier sur tout et n'importe quoi qd ca parle de MS. Pourtant j'aime vraiment pas cette boite, et je n'ai plus de windows d'installé depuis quelques années. Mais il faut aussi tenter de reconnaitre ce qui est bien, non ?
[^] # Re: Utilité de Mono
Posté par Croconux . Évalué à 4.
Il n'y a pas de mal à s'inspirer si en reprenant les bonnes idées.
Le commentaire précédent parlait de Outlook qui est tout sauf un bon exemple en matière d'ergonomie. C'est vraiment une horreur. Pourquoi s'en inspirer? Parce que le decidor utilise Outlook et donc on lui pond un truc qui y ressemble pour ne pas le dépayser.
Pour en revenir à Mono, JMC a raison. Les implémentation libres de .NET resteront toujours des ré-implémentation du framework de MS. Les dépots auprès de l'ECMA ne couvrent pas grand chose. Le standard, c'est le framework MS. Les implémentations libres resteront toujours à la traine par rapport au framework officiel.
[^] # Re: Utilité de Mono
Posté par TImaniac (site web personnel) . Évalué à 6.
Pourquoi considérer que Mono est plus en retard que MS ? Mono n'implémente pas toutes les parties du framework .NET de la même manière que MS n'implémente pas tout le framework Mono.
J'ai même envie de dire que Mono est en avance : ils implémentent une bonne partie des libs de MS, Mono tourne sur Linux, MacOSX, S390, PPC, AMD64, SPARC et propose des libs inédites dans .NET, notamment en matière de sécurité et crypto. Alors maintenant qui est en retard ?
Les implémentation libres de .NET resteront toujours des ré-implémentation du framework de MS.
Pour le Windozien qui veut juste la compatibilité de ses applis, oui. Pour le Linuxien qui s'en fou ou le Windozien qui souhaite développer une appli portable Non. A croire que tu fais partis des premiers :)
[^] # Re: Utilité de Mono
Posté par Guillaume Knispel . Évalué à 5.
Il y a MS et tout un écosystème qui gravite autour, et une partie du LL qui clone / tente d'obtenir une petite compatibilité partielle avec les "standards" MS, et lorsque l'on veut quelque chose de portable, il faut le prévoir d'origine.
Finallement, mono n'est-il pas condamné à échouer la ou Java à (partiellement puisque pas libre donc dispo pour un nombre assez restreint de plateformes du moins dans ses versions implantants toutes les fonctionnalités) réussit ?
Hm quoique Mono est libre donc il faudrait plutôt le comparer aux JVM libres...
Reste à étudier la question des qualités intrinsèques de C# et de la VM. Personellement je ne vois pas trop l'interet des VM dans le cadre du logiciel libre.
Et C# n'est pas vraiment une révolution par rapport à Java...
[^] # Re: Utilité de Mono
Posté par Croconux . Évalué à 7.
L'ECMA n'a fait qu'accepter une spec soumise par MS. Rien ne dit qu'ils continueront à fournir leurs specs. MS n'est pas réputé pour encourager l'interopérabilité. Au début, ils fallait bien qu'ils fassent un geste, .NET avait une étiquette "techno 100% MS" par rapport à Java. Ils ont soumis les documents de base pour montrer que leur technologie n'était pas si fermée que ça. Mais si la mayonnaise prends, ils n'ont aucune raison de continuer. Une fois qu'on a conquis 99% du marché, l'ouverture et l'interopérabilité en s'en bat la courgette.
Pourquoi considérer que Mono est plus en retard que MS
Parce que c'est MS qui fixe les règles du jeu ? Ils continueront de faire évoluer leur techno dans le sens qui leur plait en soumettant les specs comme standard tant que ça les arrangera. Ils peuvent ajouter toutes les features qu'ils veulent et qui ne seront disponible que sur leur implémentation, un peu comme les bidouilles spécial IE. Un standard, c'est bien, mais rien ne les empêche de s'en écarter, comme pour le HTML. S'ils sortent des extentions qui ne tournent que sous leur framework que peut-on faire ? Rien. C'est comme quand on reçoit des document en .doc qu'on ne peut pas lire parce qu'on n'a que la version n-1. Au final les gens migrent parce qu'ils ne peuvent pas lire les documents qu'on leur envoie.
J'ai même envie de dire que Mono est en avance
On peut dire que OOo est en avance par rapport à MSO parce qu'il est multi plateforme, sait lire les .doc et en plus les .sdw. Il n'empêche que c'est l'implémentation de MS qui fait foi pour le .doc.
et propose des libs inédites dans .NET
Qui tournent aussi sur le framework de MS. Tout ce qui tourne sur Mono tourne sur le framework MS. L'inverse ne se vérifie pas.
Pour le Windozien qui veut juste la compatibilité de ses applis, oui. Pour le Linuxien qui s'en fou ou le Windozien qui souhaite développer une appli portable Non
Les premiers sont un poil plus nombreux que les seconds. Il n'y a qu'à voir le nombre de boites qui développent en VB pour voir que l'interopérabilité n'est pas l'objectif premier de la plupart des gens. Souvent on code d'abord et on se mort la bitte après.
croire que tu fais partis des premiers :)
A titre personnel, le Rubyist que je suis s'en fout un peu. Au boulot, je vais devoir me taper du .NET et je peux te dire que comme 99.99% des boites se sera avec le framework MS. Mono a des arguments techniques intéressants mais aucune boite ne voudra se risquer à parier dessus sans avoir des garanties sur sa pérénité.
[^] # Re: Utilité de Mono
Posté par TImaniac (site web personnel) . Évalué à 1.
Au fait, les specs sont fournit par MS, Intel et HP, y'a pas que MS qui a son mot à dire.
Depuis les specs de la version 2.0 je te rappelle que Novell fait également partie intégrante du processus de normalisation.
Mais si la mayonnaise prends, ils n'ont aucune raison de continuer. Une fois qu'on a conquis 99% du marché, l'ouverture et l'interopérabilité en s'en bat la courgette.
Sauf que tu dis strictement n'importe quoi.
MS a normalisé la partie qui ne pourra plus bougé : les fondements, cad les libs de base et la VM : si MS casse la compatiblité avec cette norme ils cassent aussi la compatibilité avec toutes les applis .NET. Et si on regarde avec quelles difficultés ils conservent le support du win32 depuis des lustres, idem pour leur HTMLmadeIE (puisque tu aimes bien comparer avec le passé), alors on peut se dire que y'a pas de soucis à se faire concernant l'interopérabilité technique avec Mono.
De plus .NET n'est pas une simple évolution de win32, MS a pu repenser depuis 0 leur plateforme, ils y ont mis le temps et les moyens, c'est pas pour du jour au lendemain tout changer et faire chier le libre.
Je te rappelles aussi que Mono tourne aussi sous Windows, et que dans tous les cas les applis développées pour Mono resteront portables, quelque soit les choix de MS concernant son implémentation propriétaire.
Un standard, c'est bien, mais rien ne les empêche de s'en écarter, comme pour le HTML.
Je te rappelles que MS a fortement misé sur les technos XML (XML? XML Schema, XSLT, SOAP/Web Services, etc.) , notamment avec .NET, et qu'il est l'un des plus respectueux vis-à-vis de ces standards qui favorisent l'interopérabilité. Et jusque là tous leurs nouveaux produits vont dans ce sens.
Il n'empêche que c'est l'implémentation de MS qui fait foi pour le .doc.
Pourquoi ? Parcque le support des .doc par OOo n'est pas parfait. Pour Mono, le support des standards et parfait et la compatiblité technique l'est aussi. Après chaque projet à ses libs spécifiques, Mono s'efforcant d'implémenter celle de MS.
Tout ce qui tourne sur Mono tourne sur le framework MS. L'inverse ne se vérifie pas.
Visiblement tu aimes bien dire n'importe quoi.
Si tu parles de ce qui tourne effectivement SUR Mono ou SUR le framework .NET, alors OUI, tout ce qui tourne sur le framework tourne sur Mono et inversement (auw bugs prêts bien sûr).
Ce qui n'est pas compatible ce sont certaines lib "natives" comme les WinForms ou les API Gnome dans Mono. Comme quoi y'a des incompatibilité dans les 2 sens.
Il n'y a qu'à voir le nombre de boites qui développent en VB pour voir que l'interopérabilité n'est pas l'objectif premier de la plupart des gens.
D'où l'idée de profiter du fait que MS les force à switcher vers .NET pour assurer un minimum d'interopérabilité dans notre monde Linux : tout le monde va y gagner, et personne ne va s'en plaindre.
Mono a des arguments techniques intéressants mais aucune boite ne voudra se risquer à parier dessus sans avoir des garanties sur sa pérénité.
D'où l'intérêt d'arrêter de FUDer sur la partie juridique, qui est du même niveau que dans toutes les autres solutions à base de LL.
D'où l'intérêt aussi d'avoir une boîte derrière pour soutenir commercialement le produit : Novell.
[^] # Re: Utilité de Mono
Posté par ufoot (site web personnel) . Évalué à 3.
> Sauf que tu dis strictement n'importe quoi.
Sur ce point précis honnêtement je pense au contraire qu'il a (très) franchement raison 8-/
[^] # Re: Utilité de Mono
Posté par TImaniac (site web personnel) . Évalué à 2.
Lorsqu'ils auront conquérit 99% du marché ils ne pourront plus se permettre de casser l'interopérabilité, comme c'est le cas pour IE ou le support du win32.
[^] # Re: Utilité de Mono
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
http://about.me/straumat
[^] # Re: Utilité de Mono
Posté par TImaniac (site web personnel) . Évalué à 2.
Ce que tu dis ne contredis pas mes propos.
Ils peuvent s'amuser à "étendre" la norme en rajoutant des trucs, mais question interopérabilité ils sont obligé de garder une compatibilité avec l'existant (pour faire tourner les vieux sites).
Mais bon là ils partent sur des bases plus saines puisqu'ils utilisent des standards bien définis et propres grammaticalement. (Parcque bon les premières normes HTML étaient beaucoup trop laxistes et pas assez contraingnantes).
[^] # Re: Utilité de Mono
Posté par fabb . Évalué à 1.
Il ne l'étende pas, il la polue. C'est nettement différent. S'il ne font que l'étendre les pages qui respectent les standards devrait être rendue correctement. Mais sous IE ce n'est pas le cas.
Mozilla va aussi au-delà des standards et ça ne pose pas de problème.
> Parcque bon les premières normes HTML étaient beaucoup trop laxistes et pas assez contraingnantes
Les premières normes n'étaient laxistes. Par contre, le développement des bituneurs était plus rapide que la norme. Donc les développements n'étaient pas basés sur des standards et ce sont les butineurs qui "définissaient" les normes. Comme tout est devenu ugly, html (surtout la version 4 transitionnal) est devenu laxiste. Puis html 4 strict + css a remis de d'ordre.
[^] # Re: Utilité de Mono
Posté par Nosferatu . Évalué à 2.
Pardon ? une formidable source d'inovation ?
Les menus déroulants proviennent du mac, le système de fenêtrage tel qu'il a été prévu pour windows provient des travaux faits avec IBM sur OS/2 + inspirations sur les OS de l'époque: Next, Apple, XWindow, Unix (X window date de 1985).
Franchement, comme système de fenêtrage inovant, on trouve mieux. MacOS, eux, ils inovent.
Pour ce qui est de la recherche, il y a quelques jolies choses (NTFS, RIFF, ...), mais vu la taille de la société, il est suprenant qu'ils n'inovent pas plus.
leurs idées sont souvent _tres_ bonnes.
Souvent ? hum...
vas-y, lâches toi, tu as une liste de bonnes idées ?
Je trouve que tu extrapoles un peu.
Et puis les idées, elles sont faites pour être partagées, donc tant que tout reste dans le secret, elles sont inaceptables.
Donc merci MDI d'avoir cloné outlook pour faire evolution
C'est pas parce que tu as fait un programme qui gères ton courrier, contacts et tâches que tu es forcément un clone d'outlook!
Bon, ok, on ne peut pas nier que l'interface des 1.x y ressemble franchement.
Et pour finir, j'ajouterais que MS fait de la recherche et que leurs travaux sont qd meme vraiment exellent
C'est à dire ? tu es un mec qui lit et applique ce qu'ils expliquent ?
je ne pense pas, parce que si c'était le cas tu ne t'enflammerai pas autant.
Par exemple, ici:
http://blogs.msdn.com/oldnewthing/archive/2003/09/05/54806.aspx(...)
Tu as des exemples faux par rapport à la description qui est faite.
svp arreton de crier sur tout et n'importe quoi qd ca parle de MS.
Le jour où leurs programmes seront libres, ou déjà leurs formats.
Le jour où ils arrêteront d'être hors la loi.
Le jour où ils se calmeront avec leurs brevets à la con.
Le jour où ils seront loyaux sur le marché.
Là on pourra dire qu'ils ne font pas que de la merde. En attendant, toujours est-il qu'ils sont cons, et je vois pas où est le mal de dire ça puisque c'est vrai.
Allez, dans les news récentes tu as quelques liens intéressants:
http://slashdot.org/articles/05/03/24/0348241.shtml?tid=109&tid(...)
http://yro.slashdot.org/yro/05/03/23/2311234.shtml?tid=155&tid=(...)
Mais il faut aussi tenter de reconnaitre ce qui est bien, non ?
Oui, quand c'est justifié.
[^] # Re: Utilité de Mono
Posté par zerbro . Évalué à 9.
Oui. J'ai étudié ces 6 derniers mois deux articles en rapport avec l'image, et ils sont tres bien. J'ai donc eu l'occasion de les etudier, de les critiquer, de les comparer avec d'autres méthodes et de les implémenter.
J'ai pu en étudier un autre sur la classification des signaux audios, et les résultats obtenus sont _exellents_ le mec connaissait tres bien les descripteurs utiles pour ces signaux, les exploiter, et utiliser une méthode de classification récente et adapté. L'article se lisait de plus tout seul car très bien écrit.
Les chercheurs de microsoft font du bon travail, c'est un fait, ils sont meme tres appréciés dans le milieur de la recherche.
Il faut arreter de croire que MS bosse que sur windows, je vois dans l'image, il y a énormément a prendre dans leurs articles. MS fait de la recherche dans beaucoup de domaines.
Donc leurs idées, ils les partagent : les chercheurs de MS mettent leurs aticles en ligne comme tous les chercheurs. Ensuite, il ne faut pas regarder l'innovation que dans leurs produit vendu et encore moins windows. Je te parle d'innovation au niveau recherche, car il me semble que c'est le moteur de l'innovation...
Rien n'empeche les developpeurs de LLd'aller chercher dans les publies de MS.
Donc la tu insultes un de mes potes, et pleins de mecs qui bossent avec eux pour la recherche. Mais bon, toi, t'es un mec bien surement, qui détient la vérité absolue et a un regard objectif sur le monde...
Bref, je reponds a ce post, et je ne répondrais pas a tes posts suivants.
[^] # Re: Utilité de Mono
Posté par Nosferatu . Évalué à -6.
mais tu as dit:
Il y a une nuance, non ?
Je ne suis pas aussi catégorique que toi. C'est tout.
On choisis ses amis ^^
merci
[^] # Re: Utilité de Mono
Posté par reno . Évalué à -2.
Les chercheurs de microsoft ont aussi produit BOB.. Donc ils font de la merde aussi, c'est un fait aussi.
La leçon est qu'il faut voir au cas par cas la production pas généraliser..
Ils font parfois du bon travail, parfois de la merde.
[^] # Re: Utilité de Mono
Posté par LeMagicien Garcimore . Évalué à 2.
Kezako ?
[^] # Re: Utilité de Mono
Posté par Prosper . Évalué à 2.
[^] # Re: Utilité de Mono
Posté par mickabouille . Évalué à 1.
[^] # Re: Utilité de Mono
Posté par TImaniac (site web personnel) . Évalué à 3.
.NET propose un environnement qui défini des types de base et une syntaxe de base non spécifique à un langage, favorisant l'intégration de codes générés à partir de différents langages, avec bien entendu la possibilité de mixer le tout.
C# est pour moi un des premiers langages proposant à la fois tous les avantages d'une VM et l'intégration de notions de plus bas niveau (pointeurs, delegate) pour intégrer facilement du code natif (lib écrites en C), bref de grosses facilités de rétutilisation de l'existant.
L'intégration des web services est exemplaire et d'un simplicité déconcertante.
Le système de versionning est l'un d'es plus complet que je connaisse, pour ne pas dire le plus complet.
Le compilateur JIT est performant, le code intermédiaire étant optimisé pour.
Alors NON, .NET/C#/Mono ne sont pas une révolution, mais OUI c'est un ensemble d'innovations.
[^] # Re: Utilité de Mono
Posté par Croconux . Évalué à 6.
Pour avoir pratiqué je suis plutot dubitatif vis à vis d'ASP.NET. Mon plus gros reproche concerne la non séparation entre la partie présentation et la partie code. Les deux sont tellement liés qu'on peut se demander à quoi ça sert de les mettre dans deux fichier séparés (aspx/code behind). D'ailleurs on n'est pas obligé : On peut bricoler l'apparence des contrôles via le code ou mettre du code dans l'aspx. Si on modifie un truc d'un côté, ça explose de l'autre. Bref, tout se tient, se mélange, toutes les tambouilles sont imaginables. C'est d'ailleur un gros problème dans ma boite. On a des pros de la bidouille qui inventent des trucs pas possible. J'ose à peine imaginer ce que ça va donner en ASP.NET vu l'amplitude possible des débordements dans la goritude. S'il y a un truc à retenir de .NET ce n'est pas ASP.NET, à mon avis.
favorisant l'intégration de codes générés à partir de différents langages
En théorie c'est génial, dans le pratique tout le monde code en C# parce que c'est le langage conçu pour .NET. Pour tous les autres langages, il y a des adaptation à prévoir pour que ce soit utilisable. Sans parler des langages qui ont de base un framework bien établi. OK, il est possible de coder avec la syntaxe de Python sur .NET mais il faut utiliser les classes du framework .NET. Python s'interface aussi avec du code compilé. Mais si on veut porter un soft en Python qui utilise des modules natifs il faut porter aussi ces modules (l'interface du moins). Bref, le multi langages c'est plutot un exercice se style. Dans ma boite on a du code en Delphi qu'on a tenté de compiler en .NET avec Delphi.NET, et là, c'est le drame. Marche pas top.
C# est pour moi un des premiers langages proposant à la fois tous les avantages d'une VM et l'intégration de notions de plus bas niveau (pointeurs, delegate) pour intégrer facilement du code natif (lib écrites en C)
Là je suis d'accord. Les delegates sont vraiment bien pratiques. Celà dit pour profiter d'un langage de haut niveau et des libs natives on a déjà Python, Ruby et Perl qui marchent très bien. Comme dit Germaine : "Reviens Léon, j'ai les mêmes à la maison"
Le système de versionning est l'un d'es plus complet que je connaisse
Idem pour moi. C'est relativement simple simple et ça marche bien. C'est un truc qui manque vraiment en Java. MS a tiré la leçon du "DLL hell".
[^] # Re: Utilité de Mono
Posté par TImaniac (site web personnel) . Évalué à 2.
Mais reste que le fait de proposer des composants réutilisables en faisant abstraction de la syntaxe HTML qui est derrière, je trouve ca génial.
Si tu as codé ton site uniquement avec les WebForms par exemple il est très facile de changer le "rendu" de code derrière pour changer totalement de normes HTML par exemple. Le système de session et de viewstate est également impressionnant, on peut réellement programmer l'appli web comme on programme un interface graphique, en réagissant à des événements de boutons, avec la transparence de ce qui se passe derrière.
Bon évidemment je suis conscient que cela peut être dangereux, c'est pourquoi il est à mon avis nécessaire de bien comprendre ce qui se passe réellement entre le client et le serveur.
S'il y a un truc à retenir de .NET ce n'est pas ASP.NET, à mon avis.
Franchement c'est la première fois qu'on me propose de programmer entièrement en objet un site web, et ceci de manière plutôt élégante, alors même si c'est la partie où j'ai eu le plus de mal je crois qu'à l'arrivé que c'est ce qui m'a le plus impressionné.
Bref, le multi langages c'est plutot un exercice se style.
Dans certains cas c'est quand même fort pratique, je penses surtout à C++ managed, qui permet d'avoir une superbe transition avec du code natif, notamment grâce à la possibilité de mixer natif et managé.
Pour avoir d'autres langages utiles que C#, XAML sera un très bon exemple, les procédures stockées côté SQLServer aussi. Le multi-langage c'est surtout pour faciliter certaines transitions.
Celà dit pour profiter d'un langage de haut niveau et des libs natives on a déjà Python, Ruby et Perl qui marchent très bien.
Je peux faire l'équivalent des DllImport de manière portable ?
[^] # Re: Utilité de Mono
Posté par Nicolas Évrard (site web personnel) . Évalué à 5.
S'il y a un truc à retenir de .NET ce n'est pas ASP.NET, à mon avis.
Franchement c'est la première fois qu'on me propose de programmer entièrement en objet un site web, et ceci de manière plutôt élégante, alors même si c'est la partie où j'ai eu le plus de mal je crois qu'à l'arrivé que c'est ce qui m'a le plus impressionné.
Et Zope c'est du poulet ? :)
De l'introduction que j'ai eu à l'ASP.NET (alors que je connaissais déjà moyennement zope) je me rapelle avoir pensé (c'était il y a 2 ans un peu d'indulgence avec ma mémoire) : "Oui c'est joli, bonnes idées mais ça n'est vraiment pas révolutionnaire ça ressemble furieusement aux concepts de zope".
Car en zope, quand tu crées un site tu commences par définir un tas d'objets qui agissent différement, ces produits sont extrèmement nombreux et font un peu de tout (du traitement de formulaire au traitement d'image en passant par les inévitables connexions aux bases de données). Et tu les assembles à coup de zpt, de scripts python ou d'autres produits que tu as écrit pour l'occasion et le tour est joué (dis comme ça c'est facile, dans la vraie vie c'est autre chose).
[^] # Re: Utilité de Mono
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à -2.
Bof, c'est de l'interpreté, pas de typage fort tout ça, c'est moyen. Puis bon Perl pour développer propre de gros projets...
C# c'est bon, mangez en :)
[^] # Python
Posté par Antoine . Évalué à 2.
??? C'est compilé dynamiquement en byte-code (sauvé dans un fichier .pyc pour Python) puis exécuté par une VM.
pas de typage fort
Tu confonds typage fort et typage statique. En Python ou Ruby, le typage est fort mais dynamique.
[^] # Re: Python
Posté par TImaniac (site web personnel) . Évalué à 2.
Et la VM elle fait quoi ? Ah ben elle interprête le bytecode comme c'est rigolo :)
Tu confonds typage fort et typage statique.
Reste que le typage fort pert tout son intérêt lorsqu'il est dynamique, puisque son principal intérêt est d'effectuer des vérifications et optimisations à la compilation
[^] # Re: Python
Posté par Antoine . Évalué à 1.
Oui, c'est rigolo. Exactement comme une VM Java ou C#.
A ce compte-là, ton processeur interprète aussi les instructions qu'on lui envoie - puisqu'en interne il les convertit en micro-instructions qui n'ont plus rien à voir avec le jeu d'instructions original (dans les processeurs modernes, le backend est découplé du frontend).
Mais bon, j'imagine que je réponds à un troll.
Reste que le typage fort pert tout son intérêt lorsqu'il est dynamique, son principal intérêt est d'effectuer des vérifications et optimisations à la compilation
N'importe quoi. Les vérifications et optimisations peuvent être faites lors de l'exécution, il n'y a pas que la compilation dans la vie.
[^] # Re: Python
Posté par TImaniac (site web personnel) . Évalué à 2.
rataiii
En ce qui concerne la VM de Mono/C#, elle commence par compiler en code natif le bytecode (mécanisme JIT et AOT)
Mono est d'ailleur livré avec un interprêteur et un compilateur, le premier ayant l'avantage de tourner sur plus de plateformes, le 2ème étant beaucoup plus rapide mais limité à certaines plateformes matérielles.
A ce compte-là, ton processeur interprète aussi les instructions qu'on lui envoie
Dans tous les cas il y a une grosse différence entre l'interprété et la compilation du bytecode, dans un cas le mécanisme d'interprétation se situe au niveau de la VM, c'est du logiciel qui interprête, dans l'autre cas c'est le proc, du matos qui interprête si tu veux : et y'a d'énormes différences de perfs. Donc ce n'est pas un troll du tout.
N'importe quoi. Les vérifications et optimisations peuvent être faites lors de l'exécution, il n'y a pas que la compilation dans la vie.
Tu comprends rien à ce que je veux dire. Evidemment que ca peut être fait à l'exécution, mais question perf c'est toujours mieux d'optimiser AVANT l'exécution, et c'est toujours beaucoup mieux d'avoir une vérification statique à la compile qu'à la compile, parcque en général c'est pas le même qui développe et qui exécute.
La VM a bien assez à faire pour compiler en code natif et optimiser pour le proc en dessous, si en plus faut qu'elle se farcisse une vérification de type à tout bout de champ tout en cherchant à optimiser en conséquence, voilà quoi.
Faut chercher à faire le maximum de chose en amont, pour se bouffer moins d'erreur à l'exécution, et pour laisser faire à la VM les optimisations qui ne peuvent être faites qu'à l'exécution.
[^] # Re: Python
Posté par Antoine . Évalué à 2.
C'est un mécanisme d'optimisation, qui ne change rien au fait qu'il y ait du bytecode dans l'affaire, et rien au caractère soi-disant "interprété" du langage.
Python peut aussi être couplé avec un mécanisme ressemblant à un JIT, qui s'appelle Psyco : http://psyco.sourceforge.net/(...)
Il y a également des travaux en cours pour rendre Python auto-amorçable (compilateur écrit en Python) et plus facilement JITtable : http://codespeak.net/pypy/(...)
Evidemment que ca peut être fait à l'exécution, mais question perf c'est toujours mieux d'optimiser AVANT l'exécution
Tu te contredis. Si c'était mieux d'optimiser à la compilation, alors Java et Mono n'utiliseraient pas un JIT (qui veut dire "Just-In-Time", c'est-à-dire "juste à l'exécution" - et non à la compilation).
si en plus faut qu'elle se farcisse une vérification de type à tout bout de champ
Les vérifications de type peuvent être autant optimisées que le reste (en faisant de l'inférence de types et/ou en créant plusieurs branches du code en fonction des types rencontrés : Psyco utilise la seconde méthode, Pypy semble se diriger vers la première).
Il ne fait pas de doute que l'implémentation actuelle de Python soit souvent plus lente que celles de Mono/Java, mais les caractéristiques du langage (et notamment son caractère soi-disant "interprété") ne sont pas le facteur limitant.
[^] # Re: Python
Posté par TImaniac (site web personnel) . Évalué à 2.
Ah non ! Psycho c'est du AOT, et on perd la portabilité. D'ailleur ca tourne que sur x86.
Enfin l'existence de ce projet montre clairement qu'il y a une grosse différence entre mode compilé et mode exécuté ;-)
Tu te contredis. Si c'était mieux d'optimiser à la compilation, alors Java et Mono n'utiliseraient pas un JIT
c'est juste qu'il y a pleins de sortes d'optimisation, dont certaines sont dépendantes de la machine cible, d'où l'idée de garder un bytecode optimisé (pour le typage par exemple, mais aussi tout ce qui concerne les optimisations sur la logique du programme, déroulement de boucle, élimination de variables inutiles, résolution de méthode virtuelles, etc.), et d'effectuer les dernières optimisations à l'exécution (ou juste avant, quand on connait la machine cible).
Donc le JIT est utile (suffit de comparer les perfs avec et sans).
Il ne fait pas de doute que l'implémentation actuelle de Python soit souvent plus lente que celles de Mono/Java, mais les caractéristiques du langage (et notamment son caractère soi-disant "interprété") ne sont pas le facteur limitant.
Ce qui esst clairement limitant c'est sont côté trop dynamique. Reste que si tu fais quelques hypothèses et qut tu attaques plus tôt les optimisations tu gagneras en perfs, c'est ce qui se passe avec Psycho ou IronPython.
Enfin à part la question de perf, un langage avec typage statique est plus sûr qu'une langage sans typage statique, qui permet des choses vraiment douteuses d'un point de vu méthodologique, comme la modification en "live" d'interface.
[^] # Re: Python
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Python
Posté par Antoine . Évalué à 2.
Et alors ? Ton JIT Mono tourne sur tous les processeurs, peut-être ?
D'après la page d'accueil de Mono, les architectures supportées par le compilateur JIT sont : x86, x86-64, PPC. Tous ces portages ont été faits à la main, puisqu'il faut se farcir la génération de code natif. Sur les autres architectures, on retombe sur la VM traditionnelle.
Si autant de temps avait été investi dans Psyco que dans Mono, Psyco pourrait tourner sur autant d'architectures que Mono. Cela n'a rien à voir, encore une fois, avec la nature du langage source (Python).
qui permet des choses vraiment douteuses d'un point de vu méthodologique, comme la modification en "live" d'interface.
Oui, et qui permet aussi des choses très utiles comme faire des objects-proxy en dix lignes de code. Bref, cela a ses atouts et ses inconvénients.
[^] # Re: Python
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 1.
Bien sur, la plupart des interpretés utilise un byte-code histoire d'aller plus vite, ça change rien.
Le problème c'est que le résultat est que tu ne peux pas avoir de typage fort (ma langue a fourché), et donc pleins de vérifications ne peuvent pas etre faites en amont, t'es obligé de les faire à la main.
Comment tu fais en python pour forcer le type d'un argument ? Bah tu peux pas le spécifier dans la signature de la methode, comme tout bon language interpreté. Ce que je voulais indiquer c'est que c'est des vérifications en moins pour plus tard, perso je préfère pouvoir forcer un argument d'implémenter une interface que je définis, pour etre tranquille.
[^] # Re: Python
Posté par Antoine . Évalué à 2.
Java et .Net aussi utilisent un bytecode. Quelle est la différence alors ?
(vu que ton reproche à l'égard de Python / Perl / Ruby était qu'ils étaient interprétés, ce qui devient une notion très floue au regard des techniques actuelles...)
et donc pleins de vérifications ne peuvent pas etre faites en amont, t'es obligé de les faire à la main
Les vérifications de type (ou plus exactement de signature) sont faites à l'exécution, si le type n'accepte pas la méthode que tu lui demandes tu as droit à un traceback. Il n'y a rien à faire à la main, sauf si tu veux remplacer le traceback par un autre message d'erreur.
[^] # Re: Python
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 4.
Super, quand t'as un projet avec 20 mecs qui bossent dessus pendant 2 ans, à la fin tu commences à avoir un truc assez gros. Puis ton truc tu l'exécutes, tu le tests, tout bien nikel.
Puis plus tard, un beau jour, quand ton truc est en production, bah paf, gros crash, ouais, tu tombes dans un scénario qui n'a jamais été testé dans les tests fonctionnels. Pas de bol, et dire que ça aurait été évité avec une verif de typage à la compilation...
[^] # Re: Python
Posté par Antoine . Évalué à 2.
Heu... Tu crois franchement que si un scénario n'a jamais été testé, les seules erreurs possibles sont des erreurs de typage ?
Le typage statique te donne la conscience tranquille vis-à-vis du système de types du langage, mais c'est tout. Sans compter que les erreurs de type sont les plus faciles à débusquer, que ce soit à l'exécution ou à la compilation (elles sont explicites)...
[^] # Re: Python
Posté par TImaniac (site web personnel) . Évalué à 2.
Ben y'en a qui le compile, d'autre qui l'interprête. Question de perf.
si le type n'accepte pas la méthode que tu lui demandes tu as droit à un traceback.
C'est vrai le client il va adorer ce genre de truc. Enfin si tu fais payer très cher la maintenance ca peut être un bon moyen d'avoir des rentrées d'argent régulières :)
[^] # Re: Python
Posté par Antoine . Évalué à 2.
Tu n'es pas obligé de faire deux fois la même réponse... J'ai déjà répondu ci-dessus.
Au passage, ton bytecode .Net ne sera pas "compilé" sur les machines où le JIT n'est pas supporté.
C'est vrai le client il va adorer ce genre de truc. Enfin si tu fais payer très cher la maintenance
Oui, car les erreurs de typage sont les seules qui nécessitent de la maintenance, et il n'y a jamais de bugs en dehors des erreurs de typage. Vraiment n'importe quoi.
[^] # Re: Python
Posté par TImaniac (site web personnel) . Évalué à 2.
Houlà j'ai pas dis que c'était les seules erreurs, mais je vois pas pourquoi sous prétexte qu'il y a pleins d'erreurs possible on se refuse à chercher à en minimiser certaines. Le typage fort n'est pas la solution miracle, mais c'est la solution à plusieurs problème, permettant d'avoir un peu plus de confiance dans le code qu'on écrit.
D'ailleur le bon programmeur cherchera a typer le maximum de choses (tout va dans ce sens, comme la notion de généricité par exemple) afin de justement s'assurer que le compilo puisse vérifier le maximum de conneries. La notion de typage avec les interfaces rejoint la notion de contrat, également fortement utilisé dans le processus de qualité logiciel.
Et puis le typage fort permet des optimisations, ca sera toujours ca de gagner à l'exécution, puisque ca en moins à faire : pourquoi s'intéresser aux perfs à l'exécution et ainsi perdre un peu de perf - le fait d'optimiser bouffe des perfs - alors que cela pourrait être fait avant ? Pourquoi laisser la possibilité au programme de claquer entre les doigts de l'utilisateur alors que cela pourrait être vérifier avant ?
[^] # Re: Python
Posté par Antoine . Évalué à 2.
C'est une bonne question. Dans une grande partie d'applications (de bureau), les performances du langage applicatif sont tout à fait secondaires, par rapport à celles des bibliothèques. Sans compter qu'on peut écrire des saloperies avec un langage rapide (je ne pense pas qu'OpenOffice soit écrit en Python, ni même en Java).
[^] # Re: Python
Posté par TImaniac (site web personnel) . Évalué à 3.
Tout à fait d'accord.
Mais parfois certains langages "attaquent" un peu plus bas dans le système, afin de ne pas être uniquement des langages applicatifs mais plus "généralistes". D'autre part certaines libs ont besoin d'être portables, et les langages bas-niveau (C+/C++, ASM) demandent à être recompilé sur chaque plateforme, ce qui est très lourd au niveau déploiement.
Pour OOo et Java, attend la prochaine news en première page de LinuxFr, tu vas tout savoir :)
[^] # Re: Utilité de Mono
Posté par TImaniac (site web personnel) . Évalué à 6.
Ensuite Linux (l'OS dans son ensemble) a et a toujours eu du retard sur ses modèles concurrents, c'est pas pour ça qu'il est ignoré et qu'il est idiot de capitaliser dessus : il y a d'autres avantages, ben pour Mono c'est pareil, la compatibilté technique en plus pour favoriser la migration.
Ah oui, on peut aussi dire que le framework .NET est en retard sur Mono pour les libs GTK#, Gecko# & co.
mieux faut s'orienter vers d'autre technologie qui sont synchrone entre leur version windows et unix.
Mono est synchrone sur Windows et Unix. Et le socle technique est parfaitement synchrone, de toute facon quelque soit la plateforme tu auras toujours des libs dispo pour une seule plateforme pour une raison X ou Y.
T'en connais beaucoup des technos libres qui n'ont pas de retard sur leur modèle concurrent ? (et qui propose autant de chose que Mono bien entendu). Java, principal voir unique réel concurrent dans la même catégorie, a exactement les même problèmes d'implémentation et de retard sur la version officielle de Sun.
[^] # Re: Utilité de Mono
Posté par thaodalf . Évalué à 3.
l'histoire des lib spécifique a une plateforme sont pour moi une autre histoire.
[^] # Re: Utilité de Mono
Posté par TImaniac (site web personnel) . Évalué à 3.
Ah non ce n'est pas une autre histoire, parcque c'est justement cette partie qui n'est pas synchrone. Les bases techniques (VM, libs généralistes, compilo) sont synchrones.
, là je pense a python entre linux, windows
Sauf que j'ai dit "dans la même catégorie"
Je ne considère par Python comme exactement dans la même catégorie, même si Python est également généraliste.
c'est que si un dvlpeur passe de .net a mono et que disons 20% des fonctionnalités ne sont pas présente ou alors sont présente pour tel os mais pas pour l'autre, ca va lui paraître chiant.
T'inquiète pas ca va lui paraître beaucoup moins chiant que d'apprendre une nouvelle plateforme complète de A à Z :-) (passer de .NET à Python par exemple). Le développeur il va déjà être content de retrouver son langage, la philosophie de la plateforme, ses outils et une bonne partie de ses libs.
[^] # Re: Utilité de Mono
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
Moi j'aurais une question... Le gros avantage de .net, à mon avis, est l'outil de dev Visual Studio.. quand on développe une appli avec, est ce facile de la faire tourner sous Linux ?
http://about.me/straumat
[^] # Re: Utilité de Mono
Posté par TImaniac (site web personnel) . Évalué à 1.
Par contre évidemment si tu commences à faire du C++ mixed avec du mélange code managé/code natif, ou tout simplement que tu t'amuses à appeler des libs natives présentes uniquement sur l'OS de MS, forcement... Mais là ce n'est pas vraiment un problème spécifique à VS.NET.
Par défaut un projet VS.NET C# marche très bien sous Mono.
[^] # Re: Utilité de Mono
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
Sous visual studio 2004, j'utilise le designer d'écran, une base postgresql, j'affiche, je modifie, je supprime et j'ajoute des contacts...
Comment je fais pour passer ça sous Linux ?
http://about.me/straumat
[^] # Re: Utilité de Mono
Posté par TImaniac (site web personnel) . Évalué à 2.
Evidemment si t'utilises le designer de WinForms, ben, avec la version actuelle de Mono t'aura une chance sur 2 : soit les winforms que tu utilises sont entièrement implémentées, soit il en manque un bout. D'après la dernière version svn ils en sont à plus de 90% de réalisé.
[^] # Re: Utilité de Mono
Posté par thaodalf . Évalué à 0.
[^] # Re: Utilité de Mono
Posté par push . Évalué à 4.
J'ai peur de mal comprendre là ?
des modèles concurrents ? c'est une blague ?
Comment peut-on réduire Gnu/Linux à un vulgaire produit concurrent ?
# Copier les autres...
Posté par R4f . Évalué à 3.
- les idées sont ce qui se copie le plus, alors autant en profiter,
- reprendre une idée intéressante pour en faire quelque chose de mieux est un bienfait pour ceux qui en bénéficient. Les logiciels libres sont exemplaires en ce sens puisqu'ils bénéficient à tous !
- GNU a bien copié Unix (puisqu'il en est justement question dans le sigle Gnu is Not Unix)
À ce dernier sujet, le système GNU, plus connu sous le nom Linux (héhé ;-), est aujourd'hui le rejeton de la famille Unix qui a le plus fort taux de croissance aussi bien en terme d'adoptants (utilisateurs, contributeurs...) que de technologies et d'innovations. À ce jour ce sont plutôt les Unix qui sont à la traine derrière le bulldozer Linux : IBM abandonne AIX, Compaq abandonne True64... pour ne prendre que quelques exemples.
Concernant la dépêche, il faut noter que non seulement O'Reilly est un éditeur connu pour ses ouvrages informatiques, mais aussi (et surtout) qu'ils sont de grands adoptants du libre :
- éditeur de prédilection pour les ouvrages sur Perl (notamment),
- ils ont déjà sorti des livres dont les contenus sont ouverts,
- ils organisent des événements autour du mouvement du libre.
Une typo s'est glissée dans la dépêche : plateforme au lieu de plate-forme.
[^] # Re: Copier les autres...
Posté par LeMagicien Garcimore . Évalué à 1.
Non c'est bien plate-forme.
[^] # Re: Copier les autres...
Posté par R4f . Évalué à 2.
C'est qu'est-ce que je dis : dans la news il est utilisé plateforme au lieu de plate-forme.
Ex. : dans ma traduction du Brave Gnu World : http://www.gnu.org/brave-gnu-world/issue-30.fr.html(...) (plate-forme et plates-formes ont été utilisées à plusieurs reprises).
# liste d'applications basée sur mono
Posté par nolius . Évalué à 4.
Parmis les plus intéressantes il y a Beagle, Tomboy, F-spot, monodevelop...
je pense que la technologie .net est très utile pour ce genre de projet.
Dans cette liste y a aussi GraphMonkey, c'est une calculatrice graphique que j'ai réalisé : http://graphmonkey.sourceforge.net/(...) :-)
[^] # Re: liste d'applications basée sur mono
Posté par nolius . Évalué à 2.
# Vers une division de GNU/Linux ?
Posté par fabb . Évalué à 5.
Ça semble se profiler.
Novell pousse Mono et Red Hat pousse Java.
Novell fournira Mono et des petits programmes qui utilisent Mono, Red Hat ne le fera pas (et ni via Fedora Extra car il y a des problèmes (brevets, etc)).
Néanmoins Novell n'oublie pas Java mais :
- ne développe pas pour gcj, alors que Red Hat y est le paquet
- pousse JBoss alors que Red Hat pousse Jonas
On peut y voir simplement une façon de se démarquer, des raisons ""marketing"". Je n'y crois pas.
Red Hat a toujours été profondément pro-LL. A ce propos, Netscape Enterprise Suite acheté par Red Hat devrait être introduit dans Fedora (FC5) sous licence libre (la licence n'a pas été décidé mais elle sera libre). J'ignore si edirectory de Novell est libre.
Novell, bien que son virage vers le libre soit réussit et soit profitable au LL, a une culture logiciel propriétaire et développe/fournit encore beaucoup de logiciel propriétaire.
Je crois qu'il y a des enjeux majeurs dans cette guerre C#/Java !
Ces deux "géants" du logiciel libre s'affrontent dans un combat "à la vie, à la mort". Et je dirait "à la mort" du côté de Red Hat car dans le pire des scénario Novell peut toujours récupérer le boulot de Red Hat.
C# et .NET a des problèmes de brevets importants. De plus c'est MS qui est derrière et c'est pratiquement toujours un très mauvais signe.
MS ne dépose pas des brevets pour rien ! On le sait tous, l'histoire l'a déjà largement démontré. Lorsque que MS fait un truc, ce n'est pas pour permettre une "concurrence non-faussée" :-) (Le procès entre MS et l'Europe le prouve très clairement) ni pour aider le LL.
La FAQ de mono est "inquiétante" :
http://www.mono-project.com/FAQ:_Licensing(...)
Ça donne le droit à Novell de changer de licence. Ça parait anodin mais avec les brevets de MS ça ne l'ai plus.
Si MS utilisent ses brevets sur C# .Net, la version GPL de mono devient illégale et Novell peut décider de prendre une licence qui fait "plaisir" à MS. Peut-être toujours open source mais pas forcément dans l'esprit du logiciel libre, que j'espère on chérit tous ici.
Seth Nickell décrit les problèmes potentiels de mono :
http://www.gnome.org/~seth/blog/mono(...)
J'ai quelques questions (uniquement relatives aux brevets et non sur les mérites techniques) :
- Il y a-t-il de meilleurs infos que celles données par Seth Nickell ?
- Quelqu'un a-t-il un lien sur les problèmes que peut poser gcj et gnupath ?
- Il y a-t-il un comparatif entre les problèmes posé par mono et gcj/gnupath ?
Sur java, j'ai ça :
http://www.gnu.org/philosophy/java-trap.fr.html(...)
J'ai toujours apprécié le formidable MDI. Mais après m'être informé sur C#, ECMA, les brevets C#/NET, les conditions que fixent Novell pour l'ajout de code à mono, le crédit que j'avais pour MDI est en chute libre.
[^] # Re: Vers une division de GNU/Linux ?
Posté par TImaniac (site web personnel) . Évalué à 2.
Oui, concrêtement il n'y a pas encore de brevets sur .NET, ils n'ont pas encore été validés.
Ensuite ils ne concernent qu'une petite partie de Mono, même pas les WinForms en fin de compte. Et comme le dis MDI : y'a les mêmes problèmes dans la plupart des gros projets libres.
Quelqu'un a-t-il un lien sur les problèmes que peut poser gcj et gnupath ?
Suffit de voir comment Sun a réagit fasse à l'incompatilbité de la VM de MS pour voir que Sun a encore tous les droits sur sa techno. ((C), TM, Patents, etc.)
En ce qui concerne le copyright assigné à Novell, je te ferais remarqué au passage que la FSF est une fondation fan de ce genre de pratique également, et qu'on peut très bien imaginer que si la fondation passe entre de mauvaises mains... (même si je n'y crois pas).
Concrêtement ce copyright est plutôt rassurant : Novell s'étant engager à payer les éventuelles licences si jamais il y avait un problème de brevet (donc je suppose qu'ils ont bien vérifier et qu'ils espèrent bien ne pas avoir un kopec à débourser), ce qui garantie une sorte de pérénité à Mono.
Sur la bataille entre Novell et Red Hat je suis tout à fait d'accord, j'espère juste qu'ils vont trouver un terrain d'entente, en facilitant par exemple l'intégration des 2 technos, coomme le font Sun/IBM et MS entre .NET et Java.
[^] # Re: Vers une division de GNU/Linux ?
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
Disons que tu reprochais à Java d'etre trop lié à SUN (on en a déja beaucoup parlé)...du coup, Mono est plutot lié à Novell la non ?
http://about.me/straumat
[^] # Re: Vers une division de GNU/Linux ?
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Vers une division de GNU/Linux ?
Posté par fabb . Évalué à 0.
Microsoft est un consortium indépendant qui établit des standards ?
Fun.
> Au pire on fork et basta.
Avec des brevets ?
Regarde du côté de mp3. Novell ne fournit pas de lecteur mp3 (cause brevets) alors qu'il y a des lecteur mp3 sous GPL.
Tu m'expliques ton "basta" ?
[^] # Re: Vers une division de GNU/Linux ?
Posté par Frédéric Lopez . Évalué à 2.
SUSE LINUX Professional 9.2
package descriptions
mpg321 - A Free Command Line MP3 player :
http://www.novell.com/products/linuxpackages/professional/mpg321.ht(...)
Sinon, d'après ce lien :
http://www.mars.org/mailman/public/mad-dev/2002-August/000721.html(...)
il ne semble pas évident que Thomson/Fraunhoffer détiennent des brevets sur l'encodage. En tout cas, ils n'ont visiblement jamais attaqué de projets libres sur ce terrain, donc je ne vois pas trop pourquoi il faudrait s'en inquiéter maintenant.
[^] # Re: Vers une division de GNU/Linux ?
Posté par Frédéric Lopez . Évalué à 2.
[^] # Re: Vers une division de GNU/Linux ?
Posté par fabb . Évalué à 1.
Par contre mp3 est payant dans tous les autres cas.
Cherches lame (ou équivalent) pour Novell. Si tu le trouves, je ferme ma gueule.
Par exemple, j'ai regardé le paquet glame et j'ai :
%configure --disable-mp3lame
[^] # Re: Vers une division de GNU/Linux ?
Posté par Frédéric Lopez . Évalué à 2.
Non, c'est seulement pour la diffusion ou le streaming de MP3 si on en croit Thomson/Fraunhoffer, voir : http://www.mp3licensing.com/help/developer.html(...) . En même temps, ils disent en gros qu'il faut payer des licenses dès que le mot MP3 apparaît quelque part, difficile de leur faire confiance à ce sujet. D'autant qu'il n'est toujours pas évident qu'ils aient des brevets sur le décodage MP3.
Lame est un encodeur, pas un décodeur. Tu avais parlé de lecteurs MP3 dans ton précédent post, c'est pour ça que j'avais réagi. La librairie Lame n'est probablement pas dans SuSE, tout comme elle n'est pas dans Debian.
[^] # Re: Vers une division de GNU/Linux ?
Posté par fabb . Évalué à -1.
Il y a des brevets.
> ils n'ont pas encore été validés.
Faudrait savoir. Il n'y en a pas mais ils font être validés n'a aucun sens.
> Et comme le dis MDI : y'a les mêmes problèmes dans la plupart des gros projets libres.
Peut-être, mais évitons d'être emmerdé par MS. On sait toujours comme ça se termine avec lui.
> Suffit de voir comment Sun a réagit fasse à l'incompatilbité de la VM de MS
Tu l'as dit. MS fait une VM _incompatible_ et la nomme Java. Le problème est là. Ce n'est pas un problème de brevet. Le libre s'accomodara très bien de ne pas utiliser le nom "Java".
C'est presque positif que MS puisse faire une VM "Java" et être seulement embêté sur l'utilisation d'une marque.
> En ce qui concerne le copyright assigné à Novell, je te ferais remarqué au passage que la FSF est une fondation fan de ce genre de pratique également
Exemple de programme ?
La FSF le fait pour les licences et non pour les programmes. Ne mélanges pas tout.
De plus elle n'interdit pas de "forcker" une licence. Tu peux repprendre la GPL pour toi et la modifier mais la FSF ne cautionnera pas forcément ta version.
Enfin, il n'y a pas de brevet pour les licences.
> et qu'on peut très bien imaginer que si la fondation passe entre de mauvaises mains... (même si je n'y crois pas).
Continues ton raisonnement.
Il n'est pas nécessaire que Novell soit un "méchant" pour qu'il y ait des problèmes. C'est MS et ses brevets sur C# le problème.
En agissant ainsi, Novell n'est pas un "méchant" mais Novell se réserve une porte de sortie en cas de problème. Problème qui peut aller jusqu'à interdire les versions libres de C# (dont mono, qui changera de licence et ne sera plus libre).
> Novell s'étant engager à payer les éventuelles licences si jamais il y avait un problème de brevet
T'as la source ?
Ça ne serait pas : Novell s'est engagé à payer les éventuelles licences si jamais il y avait un problème de brevet avec ses clients.
"Ses clients" ce n'est pas "tout le monde". Le libre ne fait pas de distinction entre les clients "Novell" et les autres utilisateurs et utilisateurs potentiels.
> ce qui garantie une sorte de pérénité à Mono.
Bof. Il y a MS qui essait de passer un brevet sur FAT et qui vend son "pas encore validé" brevet sur FAT.
Surtout, ton argument ne tient pas. S'il n'y avait pas de problème de brevet, Red Hat aurait considéré mono et dotgnu n'aurait pas été créé en réaction à la création de mono et de ses risques.
[^] # Re: Vers une division de GNU/Linux ?
Posté par TImaniac (site web personnel) . Évalué à 1.
y'a des brevets en instance de validation. Donc c'est pas encore des brevets, c'est juste des demandes de brevets si tu préfères.
Pour le coup de la VM de MS, Sun a attaqué MS parcqu'ils estimait que MS fournissait en standard une VM non compatible, et Sun a fait valloir ses droits sur la techno, pas juste sur la marque "Java". La preuve, ils ont pas eu juste à changer de nom.
La FSF le fait pour les licences et non pour les programmes. Ne mélanges pas tout.
Non non elle le fait pour les programmes aussi. Exemple : tous les programmes qui doivent être défendu juridiquement si tu veux le soutient de la FSF.
Novell s'est engagé à payer les éventuelles licences si jamais il y avait un problème de brevet avec ses clients.
Si Novell paie pour avoir le droit d'implémenter les technos de MS, ce sera tous les utilisateurs qui bénéficieront de cette licence indirectement.
Il y a MS qui essait de passer un brevet sur FAT et qui vend son "pas encore validé" brevet sur FAT.
MS vend un produit, la FAT, avec spécifications techniques. MS a été obligé vendre la FAT, indépendament de la notion de brevets.
Red Hat aurait considéré mono
Tu l'as dis toi même, Red Hat a beaucoup d'autres raisons de ne pas considérer Mono.
Et comme je te l'ai déjà dis, les brevets ne concernent que des parties non vitales de Mono, on peut vivre sans, sans aucun problème.
[^] # Re: Vers une division de GNU/Linux ?
Posté par fabb . Évalué à -1.
> y'a des brevets en instance de validation. Donc c'est pas encore des brevets, c'est juste des demandes de brevets si tu préfères.
Tu fais exprès de ne pas comprendre?
Pourquoi MS déposent des brevets ?
Ils en déposent pour les obtenir. T'es surpris ?
> La preuve, ils ont pas eu juste à changer de nom.
Donnes la source stp. Je veux dire indiques la source qui explique pourquoi MS a été obligé de faire des modifications au-delà de virer la marque java.
> tous les programmes qui doivent être défendu juridiquement si tu veux le soutient de la FSF.
C'est un peu normal. Tu engages la FSF.
Sinon, t'as la source stp ?
> Si Novell paie pour avoir le droit d'implémenter les technos de MS, ce sera tous les utilisateurs qui bénéficieront de cette licence indirectement.
C'est con, ce n'est pas ce que dit Novell.
http://lists.ximian.com/archives/public/mono-list/2003-October/0162(...)
Mon pauvre, t'as vraiment pas chance... Quand t'avances une connerie, parfois des gens te contredisent. C'est bête, pas chance.
De plus, si MS ne veut pas fournir une licence pour tout le monde, il faut le subir. On a pas le choix.
Ce n'est pas de la volontée de Novell mais de Microsoft (et des législations en cours, mais MS fait tout (chantage au licenciement par exemple) pour imposer les brevets logiciels partout dans le monde).
> MS vend un produit, la FAT, avec spécifications techniques.
Quel produit ?
Ça marche sous sparc ?
> MS a été obligé vendre la FAT
Vendre quoi ?
Les sources ? Le binaire ?
> indépendament de la notion de brevets.
Donc, ils ne vendent pas de brevets sur la fat ?
C'est quoi ça :
http://www.microsoft.com/mscorp/ip/tech/fat.asp(...)
Si c'est un produit, comme se fait-il qu'il donne une aide pour faire ce "produit" et aussi certains sources ?
Si je te suis, MS fournit aussi des test pour vérifier que leur produit passe leur test et ce afin que MS fasse son produit compatible avec MS ! C'est cool.
Comprends que pour un produit "made in MS", MS n'a absolument pas besoin de brevets pour le protéger ou fixer le prix de licence ou fixer les conditions d'utilisation, etc.
MS utilise les brevets lorsque qu'il veut avoir une "influence" qui va au-delà de ces propres produits. C'est pour ça que les brevets sont un concentré de merde. C'est aussi pour ça que MS dépose des brevets. Pour ces propres produits, MS n'a pas besoin de brevet. Donc, quand MS dépose des brevets sur C#, ce n'est pas pour ces produit mais pour les produits des autres. On doit donc être doublement sur ses gardes.
Et notes, que MS n'a pas encore de brevets sur FAT !
MS n'a même pas besoin d'avoir un brevet "valide" pour faire chier. Proposer un brevet lui suffit pour faire chier le monde.
[^] # Re: Vers une division de GNU/Linux ?
Posté par fabb . Évalué à 1.
Humm. Je ne suis pas sûr de ça. Je sais seulement qu'il y a des brevets en attente.
[^] # Re: Vers une division de GNU/Linux ?
Posté par push . Évalué à 4.
Petite ou grande partie ne change rien au problème, et si d'autres gros projets sont aussi concernés par le problème des brevets, ici on parle d'une société qui ne cache pas sa haine envers les logiciels libres.
Sun à réagit car Microsoft violait les règles de base à savoir qu'une implémentation doit implémenter complètement la spécification et ne doit pas ajouter, modifier ou supprimer quelque chose dans les packages définis par la spécification.
Oser comparer Novell et la FS, il fallait oser le faire quand même... et tes affabulations sur un passage de la FSF entre de mauvaises mains n'est même pas drôle.
Le jour ou les brevets seront valides sur le globe, les pseudos partisants des logiciels libres adorateur de microsoft rigoleront moin.
[^] # Re: Vers une division de GNU/Linux ?
Posté par TImaniac (site web personnel) . Évalué à 0.
Ralala, MS ce n'est pas un être humain, c'est une boîte commerciale, et ils s'en foutent pas mal qu'une licence soit libre, tout ce qui les intéresse c'est que ca rapporte, directement ou indirectement.
Sun à réagit car Microsoft violait les règles de base à savoir qu'une implémentation doit implémenter complètement la spécification et ne doit pas ajouter, modifier ou supprimer quelque chose dans les packages définis par la spécification.
N'importe quoi. Moi je vais attaquer la fondation Mozilla, parcque c vrai quoi, ils n'implémentent pas entièrement toutes les normes HTML (même si c'est eux qui ont la meilleure implémentation).
Sun a juste fait valloir ses droits sur sa techno, et indiqué que si on veut implémenter un environnement Java, faut que ça déplaise pas trop à Sun. Donc Sun a un fort pouvoir sur Sun, CQFD.
et tes affabulations sur un passage de la FSF entre de mauvaises mains n'est même pas drôle.
Oui je sais bien que c'est pas drôle, mais techniquement c'est possible, même si je sais bien qu'ils ont essayé de faire en sorte que ca puisse être éviter, juridiquement rien n'empêche la FSF de tomber entre de mauvaise mains, ce n'est pas le domaine public, et vu la quantité impressionnante de propriété intellectuelle qu'il y a dans cette fondation, elle doit attirer des convoitises.
Enfin tout ce que je voulais dire c'est que la demande d'assignation de copyright n'est pas spécifique à Novell, et il n'y a vraiment pas de quoi s'en offusquer.
[^] # Re: Vers une division de GNU/Linux ?
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
Euh... Les dirigeants nous ont quand même traités de communiste :)
Aux états unis, ceci ne signifie pas "vous votez communiste", aux états unis, c une insulte ;)
"Sun a juste fait valloir ses droits sur sa techno, et indiqué que si on veut implémenter un environnement Java, faut que ça déplaise pas trop à Sun."
Non, sun a juste fait valoir que pour implémenter une machien virtuelle, il vallair respecter les specs.
http://about.me/straumat
[^] # Re: Vers une division de GNU/Linux ?
Posté par TImaniac (site web personnel) . Évalué à 1.
Elles n'ont aucune valeur juridique que je sache, elles ne sont même pas normalisés et encore moins dans la loi !
Faut arrêter de délirer !
Juridiquement on ne peut obliger quelqu'un a respecter des specs !
Sun a obligé MS parcque Sun a des droits de propriété intellectuelles sur la techno, et que MS étant obligé d'utiliser une partie de ces droits ils doivent se plier à certaines conditions, et là Sun a imposer le respect de ses specs, pas parcque c'est obligatoire, parcque Sun a des droits sur ses technos.
[^] # Re: Vers une division de GNU/Linux ?
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
Et ca c juridique...
Si ma botie dit qu'on est certifiée iso9002 ce que l'ont est pas, on aura des prbs :)
http://about.me/straumat
[^] # Re: Vers une division de GNU/Linux ?
Posté par TImaniac (site web personnel) . Évalué à 1.
MS aurait pu faire pareil et ne plus mentionner Java, mais Sun ayant des droits intellectuels plus fort qu'une simple marque sur son produit, ils ont obtenus que MS se conforme à la leur norme.
Je penses que tu saisies très bien la différence.
[^] # Re: Vers une division de GNU/Linux ?
Posté par fabb . Évalué à 1.
Mais c'est complètement faux ce que tu dis.
De plus tu n'as jamais mis une Url pour prouver tes dires.
MS a voulu utiliser la marque Java genre :
- "viendez ici on a java"
Et sun a dit à MS que l'utilisation de la marque java impose d'offrir un vm java compatible avec les spec java.
Ceci est totalement normal. Surtout que Sun insiste sur le "write once, run anywhere". Avec la VM de MS qui était incompatible Java, le "write once, run anywhere" il ne va pas loin.
IBM a aussi une machine java et n'a pas eu les problèmes de MS car ils respectent les specs de Java.
Imagines que Samba soit nommé par exemple "Windows share" et samba se fait explosé par MS.
[^] # Re: Vers une division de GNU/Linux ?
Posté par TImaniac (site web personnel) . Évalué à 3.
In addition, Microsoft paid Sun US$900 million to sign a covenant prohibiting both companies from collecting financial damages for all past instances of patent infringement, a move which will reduce Sun's incentive to file any patent infringement lawsuits.
Tu vois bien que ce n'est pas qu'une histoire de marque bordel !
[^] # Re: Vers une division de GNU/Linux ?
Posté par TImaniac (site web personnel) . Évalué à 2.
http://news.com.com/Sun+settles+with+Microsoft,+announces+layoffs/2(...)
the software company will pay Sun $700 million to resolve antitrust issues and $900 million to resolve patent issues,
Ayé t'as compris ? Sun a autre chose qu'un simple Java(TM).
Alors maintenant explique moi pourquoi Red Hat ne considère pas Java comme Mono. Sachant que Mono est lié à MS et que Sun l'est aussi fortement.
[^] # Re: Vers une division de GNU/Linux ?
Posté par fabb . Évalué à 2.
T'es gentil, mais il y a de tout là dedans. Le retrait de la plainte de Sun contre MS en Europe, des accords de non agression sur les brevets, l'arrêt des poursuits par Sun car MS ne fait pas une vm qui respecte les specs, etc...
Donc, trouves moi la partie qui indique :
- MS à pays XX $ pour l'utilisation des brevets de java.
> Alors maintenant explique moi pourquoi Red Hat ne considère pas Java comme Mono.
Parce qu'il n'y a pas de problème dans l'implémentation de java qu'utilise Red Hat. Si Sun pouvait attaquer Red Hat, il le ferait et vite. Red Hat (et biensur la communauté GNU/Linux) est en train de ruiner Sun.
Red Hat développe beaucoup java (via gcj/gnupath et jonas) utilise beaucoup java (c'est leur solution web), Red Hat va diffuser gcj etc dans FC4 (en fait, il le diffuse depuis RH8.0, mais était peu utilisé). Red Hat est le principal développeur de gcj et gnupath. S'il y avait des problèmes, Red Hat serait une cible idéale.
Si tu ne crois pas que Sun déteste Red Hat, regarde le blog de Jonathan Schwartz ((vice)président logiciel chez Sun) :
http://blogs.sun.com/roller/page/jonathan/(...)
Regardes le nombre de fois qu'il descend Red Hat.
Puis voit la politique de Red Hat qui vise à pique des clients Solaris :
http://www.redhat.com/about/presscenter/2005/press_rhel4.html(...)
Fais une recherche google avec "Sun Red Hat" et tu touveras plein d'article de ce genre :
http://solutions.journaldunet.com/0409/040923_sun.shtml(...)
Si on en juge par RMS (qui est un casse couille) gcj et classpath sont sûrs :
http://www.gnu.org/philosophy/java-trap.fr.html(...)
Par contre ils n'auront jamais toutes les fonctionnalités de Java fournit par Sun. Tant pis, on ferait avec. gcj/classpath ne sera probablement jamais parfaitement compatible avec les specs de Sun. C'est un fork à part entière.
Mono à l'heure actuelle n'est pas une menace pour MS. Donc MS n'attaque pas. MS "embrasse" le libre pour mieux l'étrangler. Il attend.
Red Hat à l'heure actuelle est une menace pour Sun qui fond comme neige au soleil.
[^] # Re: Vers une division de GNU/Linux ?
Posté par TImaniac (site web personnel) . Évalué à 2.
Là je suis pas concaincu, Sun a grand intérêt à ce que sa plateforme soit adopté, cela ne peut être que positif pour Sun, sachant que Sun gardera toujours une longueur d'avance sur Red Hat, parcque Sun implémentera toujours en premier les specs du JCP.
En gros c un peu la même position que MS vis à vis de Mono.
Puis voit la politique de Red Hat qui vise à pique des clients Solaris :
Faut pas tout confondre, Sun peut pas blairer MS mais ils passent des accords, IBM peut pas blairer MS, et ils sont de gros partenaires.
Par contre ils n'auront jamais toutes les fonctionnalités de Java fournit par Sun. Tant pis, on ferait avec. gcj/classpath ne sera probablement jamais parfaitement compatible avec les specs de Sun. C'est un fork à part entière.
Bah au pire ca sera pareil pour mono : on laisse tomber ce qui pose problème et on garde le reste, en particulier tous les APIs spécifiques à Gnome.
Red Hat à l'heure actuelle est une menace pour Sun qui fond comme neige au soleil.
Meuh non, Sun est bourré de pognon, y'a qu'à voir tout ce que MS a filé à Sun :)
[^] # Re: Vers une division de GNU/Linux ?
Posté par fabb . Évalué à 2.
M'enfin, c'est mon dernier message à ce sujet car tu commences à me les briser menu.
> Là je suis pas concaincu, Sun a grand intérêt à ce que sa plateforme soit adopté
Oui. Mais gcj/classpath n'a jamais prétendu faire l'équivalent du java de Sun. Il y aura des éléments manquants. Partout où il y a un doute, un brevet, il n'y aura pas d'équivalent dans gcj/classpath.
> En gros c un peu la même position que MS vis à vis de Mono.
Pas tout à fait. MS n'a actuellement aucun intérêt d'exploser Mono (ou Novell). Sun a de très bonnes raisons d'exploser Red Hat.
La position mono vis à vis de MS n'est pas la même que gcj/classpath vis à vis de Sun.
Mono part avec l'objectif d'implémenter des brevets dont la libre utilisatation n'est pas autorisée (seulement l'implémentation gratuite est autorisée).
Gcj/classpath ne part pas avec l'intention d'implémenter des brevets et de se serrer les fesses en espérant qu'ils ne se feront pas exploser le cul.
Mono joue avec le feu, gcj/classpath refuse de jouer avec le feu.
Que java telque défini par Sun pose problème à implémenter en libre est plus que probable. Mais ce n'est pas l'objectif de gcj/classpath. A venir il y aura beaucoup d'applis "java" (notes les "") sous GNU/Linux qui ne tournerons pas sur la vm standard de Sun (beaucoup d'appli "java" qui utiliseront glade, etc). Et ce sans que Sun lance de procès ou menaces.
> aut pas tout confondre, Sun peut pas blairer MS mais ils passent des accords, IBM peut pas blairer MS, et ils sont de gros partenaires.
Tu oublies un truc que tu connais certainement. J'ai du mal à croire que tu ne le fais pas exprès. Passons. Je vais t'expliquer.
Sun, IBM, MS ont des porte-feuilles de brevet énorme. Ils ont des armes de destruction massive. Ils pratiquent la dissuasion. Ça marche entre eux car ils ont tous des armes de destruction massive.
Red Hat n'a pas d'arme de destruction massive (pas de brevet[1]). Si Sun attaque Red Hat sur les brevets (en imaginant que Red Hat utilise des brevets de Sun), Red Hat se fait volatiliser par les armes de destruction massive de Sun et Sun n'a pas une égratignure.
Donc si Sun avait une oportunité d'attaquer Red Hat, Sun ne s'en priverait pas.
C'est pour celà que Red Hat est extrèmement pointilleux sur les brevets. Plus Red Hat sera un concurrent significatif des "géants" (type Sun, IBM, MS), plus Red Hat sera une cible potentielle de leurs armes de destruction massive.
Mono n'est pas un concurrent de C# de MS actuellement. Donc Mono ne risque rien. MS fait mieux d'attendre que de dégainer tout de suite histoire de faire encore plus de ravage.
> Bah au pire ca sera pareil pour mono : on laisse tomber ce qui pose problème et on garde le reste, en particulier tous les APIs spécifiques à Gnome.
Ce n'est pas ce que fait mono. Mono implémente les trucs à problèmes et serre les fesses.
gcj/classpath n'implémentent pas de trucs à problème, n'attendent pas d'avoir un procès au cul pour rectifier le tir, ne choisi pas la licence MIT pour utiliser des brevets et si nécessaire les payer, ne demande pas que le copyright soit affecté à la même personne/entité, etc. Bref, gcj/classpath sûr de son bon droit est dé-con-trac-té.
[1] En fait oui mais très peu. Et contrairement à MS, c'est compatible avec le libre car expressement reconnu par Red Hat :
http://www.redhat.com/legal/patent_policy.html(...)
Cette page est facile à trouver, il y a un lien sur cette page dans toutes les pages sur le site http://www.redhat.com/(...)
C'est purement défensif, Red Hat finance en parti le lobby anti-brevet.
[^] # Re: Vers une division de GNU/Linux ?
Posté par TImaniac (site web personnel) . Évalué à 2.
Donc si Sun avait une oportunité d'attaquer Red Hat, Sun ne s'en priverait pas.
Sun pourrait attaquer Red Hat parcque l'implémentation de gcj et classpath ne sera complète, comme Sun l'a fait pour MS non ?
Mais je suis pas persuadé comme toi que Sun est un quelconque intérêt à attaquer Red Hat, Sun a besoin d'allié pour supporter sa techno.
Ce n'est pas ce que fait mono. Mono implémente les trucs à problèmes et serre les fesses.
DotGNU fait pareil. Mais comme je me tues à te le répéter, Novell n'a aucun intérêt à se prendre un missile de MS entre les fesses, je suppose qu'ils ont largement mesurer les risques de ces fameux brevets.
Enfin n'empêche il suffirait que les brevets logiciels ne soit pas ratifier pour résoudre le problème, enfin pour nous, les américains vivent leur vie de leur côté, et je m'en fou. Dommage que Red Hat soit trop "américanisé" dans sa vision des choses : il pourrait entretenir un fedora extra rest-of-the-world.
[^] # Re: Vers une division de GNU/Linux ?
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Vers une division de GNU/Linux ?
Posté par fabb . Évalué à 1.
Je n'ai pas dit que gcj était une menace pour le java de Sun.
J'ai même parlé d'un fork à part entière.
[^] # Re: Vers une division de GNU/Linux ?
Posté par TImaniac (site web personnel) . Évalué à 2.
Donc Mono n'est pas plus dangereux pour MS que ne l'ai gcj pour SUN actuellement, et Sun peut très bien faire chier gcj pour non respect de la licence du jdk le jour où ils deviennent enmerdant (à lire c'est pas très long et compréhensible pour une licence), comme MS peut faire chier Novell... il y a quand même de nombreux points communs ! D'ailleur dans la licence du jdk il est clairement dit qu'on est obligé de respecter la norme de A à Z, au risque de s'attirer les foudres de Sun, donc si gcj n'implémente pas tout et devient donc incompatible... enfin ca reste des supposition, et perso je crois pas qu'il y aura de problème pour gcj comme je ne le crois pas pour Mono.
J'ai même parlé d'un fork à part entière.
On parle de fork quand il y a reprise du code. La c'est juste une autre implémentation des "normes" de Sun(JCP&Co)
[^] # Re: Vers une division de GNU/Linux ?
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Vers une division de GNU/Linux ?
Posté par fabb . Évalué à 1.
Non.
gcj/classpath ne fait pas ça (ce qui est en gras).
[^] # Re: Vers une division de GNU/Linux ?
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Vers une division de GNU/Linux ?
Posté par fabb . Évalué à 1.
Ici, pour cette version, en gros il ne faut pas lire la licence pour que gcj/classpath soit tranquille.
Je ne connais pas les licences des versions précédentes. Ce n'est pas un gros problème car l'objectif de gcj/classpath n'est pas d'être 100 % compatible.
[^] # Re: Vers une division de GNU/Linux ?
Posté par TImaniac (site web personnel) . Évalué à 3.
Enfin reste que le texte dit clairement que Sun a des brevets sur les technos liées à Java, que tu lises ou pas, c'est un fait.
Enfin arrêtons de nous disputer, je trouves de toute façon que c'est quelque chose de bien qu'on est enfin des plateformes de développement modernes et relativement performantes soutenues par l'industrie sous Linux. Le C/C++ ca commencait un peu à lourder.
[^] # Re: Vers une division de GNU/Linux ?
Posté par push . Évalué à 1.
Tu racontes n'importe quoi.
http://public.planetmirror.com/pub/java-sun/J2SE/5.0/docs/jdk-1_5_0(...)
[^] # Re: Vers une division de GNU/Linux ?
Posté par TImaniac (site web personnel) . Évalué à 1.
Si je n'annonce pas que je fais une JVM Java (TM) personne ne peut m'obliger à suivre la norme, elle n'a aucun caractère obligatoire SI Sun n'a qu'un TM.
Si j'y suis obligé c'est bien que Sun a d'autres droits de propriété intellectuelles sur les technos Java. Ce que je voulais démontrer.
"Sun also grants you a perpetual, non-exclusive, worldwide,
fully paid-up, royalty free, limited license (without the
right to sublicense) under any applicable copyrights or
patent rights it may have in the Specification to create
and/or distribute an Independent Implementation of the
Specification that: (i) fully implements the Spec(s)
including all its required interfaces and functionality;"
Sun préviens clairement qu'on est obligé de respecter la norme non pas parcqu'ils ont le TM, mais parqu'ils ont des droits de copyright et brevets dessus.
En gros : vous respecter les règles, c'est à nous. Même si vous n'utilisez pas le TM Java.
[^] # Re: Vers une division de GNU/Linux ?
Posté par push . Évalué à 0.
SPECIFICATION TO YOU ONLY UPON THE CONDITION THAT YOU
ACCEPT ALL OF THE TERMS CONTAINED IN THIS LICENSE AGREEMENT
("AGREEMENT"). PLEASE READ THE TERMS AND CONDITIONS OF THIS
LICENSE CAREFULLY. BY DOWNLOADING THIS SPECIFICATION, YOU
ACCEPT THE TERMS AND CONDITIONS OF THIS LICENSE AGREEMENT.
IF YOU ARE NOT WILLING TO BE BOUND BY ITS TERMS, SELECT THE
"DECLINE" BUTTON AT THE BOTTOM OF THIS PAGE AND THE
DOWNLOADING PROCESS WILL NOT CONTINUE.
Donc tu va faire une implémentation sans avoir lu ses spécifications ?
T'es vraiment très très fort toi.
[^] # Re: Vers une division de GNU/Linux ?
Posté par fabb . Évalué à 1.
Je présice afin d'éviter toute confusion que la FSF ne pocède pas de brevet. Que sa "propriété intellectuelle" est librement utilisable, modifiable, et distribuable.
[^] # Re: Vers une division de GNU/Linux ?
Posté par kra . Évalué à 2.
'fin bref, mis a part deblaterer tout et n'importe sur un domaine que tres peu de gens maitrisent ici (le droit) et que peu de gens maitrisent tout court, ou encore se gargariser de mots qui font bien dans la "communaute" (genre moi chu engage et je sais de quoi je parle) votre discussion ne mene pas a grand chose.
ouala, moinssez moi, j'ai commit le grand crime d'insinuer que la fsf n'est pas pure et immaculee, de toute facon, je m'en fous, j'suis deja a -2 par defaut, alors..
et surtout vous arretez pas, vous me faitez bien marrer
[^] # Re: Vers une division de GNU/Linux ?
Posté par TImaniac (site web personnel) . Évalué à 3.
Aujourd'hui oui. Demain peut être pas. Cela dis je suis plutôt optimiste et je ne crains pas que cela puisse arriver, je voulais juste montrer que l'assignation de copyright est monnaie courante et parfois bien pratique, sans que cela est un impact négatif.
[^] # Re: Vers une division de GNU/Linux ?
Posté par fabb . Évalué à 1.
Aujourd'hui et pour les siècles qui viennent, les "propriétés intellectuelles" actuelles de la FSF sont librement utilisables, modifiables, et distribuables.
Les futurs versions peut-être pas.
Ça n'a rien à voir avec la problématique des brevets. C'est une problématique de droit d'auteur.
Si MS demande le paiement d'un brevet, c'est valable pour tous les logiciels qui utilisent le brevet. Qu'il soit vieux ou récent.
La FSF ne possède aucun brevet.
[^] # Re: Vers une division de GNU/Linux ?
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Vers une division de GNU/Linux ?
Posté par fabb . Évalué à 1.
J'oubliais, Seth Nickell bosse chez Red Hat. Son avis peut-être biaisé. Par contre, il bosse sur Xorg/Gtk/Gnome et non sur Java.
[^] # Re: Vers une division de GNU/Linux ?
Posté par push . Évalué à 2.
http://www.ed-diamond.com/produit.php?produit=375(...)
[^] # Re: Vers une division de GNU/Linux ?
Posté par Alex G. . Évalué à 3.
Moi ça me gène vachement cette clause ! Demander au gens de contribuer à un logiciel GPL pour ensuite pouvoir prendre sois tous les droits ce n'est pas conforme à l'esprit copy-left. Au minima tu garantit une license LGPL !
Pour moi, c'est du détournement de la GPL.
Comme quelqu'un le disait plus haut, Novell n'a pas la culture du libre encore chevillée au corps comme RedHat et ça pourrait jouer des sacrés tours.
[^] # Re: Vers une division de GNU/Linux ?
Posté par kra . Évalué à 0.
- Novell redistribue le code sous GPL. Donc le projet reste libre.
- Vu que c'est une boite et qu'ils mettent des billes dans l'affaire, faut bien qu'ils arrivent a tirer profit de la chose. Ils demandent donc de ceder le copyright pour avoir le droit de re-releaser sous une licence proprio pour faire du pognon.
comme qt ou mysql (qui sont aussi cite dans ce thread), rien de neuf sous le soleil.
Donc ca reste libre, totalement conforme avec la GPL et les barbus, et eux ils rentrent dans leurs frais derriere.
[^] # Re: Vers une division de GNU/Linux ?
Posté par Alex G. . Évalué à 1.
Tu as raison de souligner que si Novell retourne sa veste, il y a tout les moyens habituels de faire un fork, et qu'il sont donc bien conforme à la GPL (abus de langage de ma part).
[^] # Re: Vers une division de GNU/Linux ?
Posté par kra . Évalué à 0.
confiance en quoi? peur de quoi?
le projet EST libre, qu'est ce que tu veux de plus?
ca se passe mal et novell laisse tomber le projet? bah ils auront deja investi plus de pognon et de personnes que toute la communaute aurait jamais put fournir, de quoi peut tu bien avoir peur?
# mono vs DotGNU
Posté par mosfet . Évalué à 1.
quelqu'un pourrait m'éclairer sur la différence entre mono et DotGnu car je suis un peu perdu.
Quel interet d'avoir deux implémentations de .NET ?
[^] # Re: mono vs DotGNU
Posté par fabb . Évalué à 2.
Passage intéressant :
Réponse de mono :
Bref, ils feront comme toutes les boîtes qui diffusent du propriétaire avec des brevets dedans.
[^] # Re: mono vs DotGNU
Posté par TImaniac (site web personnel) . Évalué à 1.
MS a été clair, l'utilisation des brevets est libre et gratuite pour implémenter un CLR ! Donc l'implémentation de Novell est valide et sans aucun problème juridique.
Tout ce qui pose problème c'est quelques libs absolument pas indispensables, donc dans la pire des situations, Mono vire ces quelques libs, et BASTA.
La liste des problèmes, libs par libs, merci DotGNU :
http://wiki2.dotgnu.info/ClassLibsOverview(...)
Franchement t'es de mauvaise foi, concrêtement ces brevets ne pose aucun problème, et Novell s'est engagé envers ses clients parqu'ils savent qu'il n'y en a pas.
Un peu comme IBM qui s'engageait contre d'éventuelle enmerde avec SCO, ils savaient qu'ils n'avaient juridiquement aucun problème.
[^] # Re: mono vs DotGNU
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
Tout ce qui pose problème c'est quelques libs
Sur 30.. il y en a 17 qui ont aucun problème... ca fait pas loin de la moitié!
La moitié des libs sont pas indispensables ?
http://about.me/straumat
[^] # Re: mono vs DotGNU
Posté par TImaniac (site web personnel) . Évalué à 3.
Sur 30 y'en a 17 sur lesquels MS est susceptible d'avoir un brevet accordé, mais comme je l'ai montré en dessous, MS a explicitement donné son accord pour la plupart, et les quelques libs non normalisés à l'ECMA qui reste sont soit non implémentées dans Mono, soit remplacé dans Mono par d'autres libs alternatives.
Bah oui Novell & MDI avait réfléchi avant vous dis donc.
[^] # Re: mono vs DotGNU
Posté par fabb . Évalué à 1.
Url stp. 2002ième requête.
[^] # Re: mono vs DotGNU
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: mono vs DotGNU
Posté par fabb . Évalué à 1.
Trop fort.
[^] # Re: mono vs DotGNU
Posté par TImaniac (site web personnel) . Évalué à 2.
Basically a grant is given to anyone who want to implement those components for free and for any purpose.
J'ai juste traduit la dernière phrase officielle de Novell.
[^] # Re: mono vs DotGNU
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
(non-commercial) purpose"
Ca pose pas prb ? je croyais qu'on avait aucune restriction ?
http://about.me/straumat
[^] # Re: mono vs DotGNU
Posté par TImaniac (site web personnel) . Évalué à 2.
(non-commercial) purpose
Si tu lis la phrase en entier et que tu comprends l'anglais aussi bien que les avocats de Novell, tu verras que cette restriction commerciale s'applique à d'autres utilisation que d'implémenter un CLR avec ces brevets. Donc il y a bien une limitation mais elle ne s'applique pas à Mono qui implémente un CLR. Le véritable problème pourrait survenir si tu veux forker mono pour faire autre chose qu'un CLR, c'est possible même si je vois pas trop l'intérêt.
[^] # Re: mono vs DotGNU
Posté par fabb . Évalué à 1.
C'est la même chose que :
[^] # Re: mono vs DotGNU
Posté par TImaniac (site web personnel) . Évalué à 2.
Mais comme je l'ai dis, en l'occurence on s'occupe de ce purpose en question, et donc en ce qui concerne Mono il n'y a pas de problème.
Effectivement il y a un problème si tu utilises leurs brevets pour faire autre chose qu'une implémentation de CLR, une machine à café par exemple.
[^] # Re: mono vs DotGNU
Posté par fabb . Évalué à 1.
Il y a problème du moment où tu fais autre chose qu'implémenter. Implémenter "for any purpose", n'est pas utiliser "for any purpose".
[^] # Re: mono vs DotGNU
Posté par kra . Évalué à 1.
repeter quelque chose a l'infini ne le rend pas plus vrai, vous avez exprime vos idees, on les a ecoutees et on en pense ce qu'on veut, alors fermez vos putains de grandes gueules ou changez de disque.
desole, j'm'enflamme, mais les debats qui tournent en rond ca saoule
[^] # Re: mono vs DotGNU
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
Tout ce qui pose problème c'est quelques libs absolument pas indispensables
alors que :
Sur 30 y'en a 17 sur lesquels MS est susceptible d'avoir un brevet accordé
Je trouve ça incroyable :)
Tu utilises que la moitié des APIs ? il y a un truc que j'ai pas compris ou quoi ?
http://about.me/straumat
[^] # Re: mono vs DotGNU
Posté par fabb . Évalué à 1.
Je doute de ça.
Surtout le "Part of ECMA Standard 335" => "Not endangered".
ECMA 335 :
http://www.ecma-international.org/publications/standards/Ecma-335.h(...)
http://www.ecma-international.org/memento/guidance.htm(...)
Et ça aussi :
http://www.ecma-international.org/memento/codeofconduct.htm(...)
"reasonable, non-discriminatory terms" n'est pas satisfesant pour la GPL ni le logiciel libre en général.
De plus (ça va chagriner TImaniac qui s'obstine à dire le contraire) et c'est MS qui le dit :
http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2887217(...) (c'est dédié C# et sa clique et ce n'est pas un pro-logiciel libre qui l'a rédigé).
Donc :
System.AppDomain
System.DirectoryServices
System.EnterpriseServices
System.Globalization
System.IO
System.Reflection.Emit
System.Runtime.CompilerServices
System.Text
System.Threading
System.Windows.Forms ?
System.Xml
pose problème avec les brevets. Ce n'est pas light.
[^] # Re: mono vs DotGNU
Posté par TImaniac (site web personnel) . Évalué à 2.
Surtout le "Part of ECMA Standard 335" => "Not endangered".
T'es pals plus intelligent que Novell ou DotGNU. Si les 2 affirment ca ce n'est pas à cause de l'ECMA, c à cause de ce que MS a autorisé pour l'utilisation de ses brevets. Ils font juste un raccourci. Puisque tu sembles faire l'idiot, voilà ce qu'ils auraient dû écrire plutôt que leur raccourci :
Part of ECMA Standard 335 => MS authorization for CLR/CLI/BCL implementation => Not endangered
tu préfères sans le raccourci ?
Par contre je te remercies pour le lien concernant Herman. Il y a effectivement un problème d'incompatibilité entre la GPL et la notion de brevet. Sauf qu'en l'occurence dans le projet Mono c'est le compilo qui est sous GPL. Hors il n'y a pas de brevet sur le compilo. Donc pas de problème d'incompatibilité : CQFD.
System.AppDomain => sous licence MIT + ECMA/accord MS
System.DirectoryServices => pas implémenté dans Mono
System.EnterpriseServices => pas implémenté dans Mono
System.Globalization => sous licence MIT + ECMA/accord MS
System.IO => sous licence MIT + ECMA/accord MS
System.Reflection.Emit => remplacé dans Mono par une lib plus puissante
System.Runtime.CompilerServices => spécifique au compilo csc de MS, implémentation totalement différente pour le compilo de Mono, donc pas d'utilisation de brevets.
System.Text => sous licence MIT + ECMA/accord MS
System.Threading => sous licence MIT + ECMA/accord MS
System.Windows.Forms ? => pas de brevets de déposé dessus
System.Xml => sous licence MIT + ECMA/accord MS
Bref, comme tu peux le constater avec quelques précisions il ne semble pas y avoir de problème. D'ailleur DotGNU implémente aussi ces parties, ce n'est pas pour rien.
[^] # Re: mono vs DotGNU
Posté par fabb . Évalué à 2.
Donnes une page MS qui indique l'autorisation d'utilisation illimité (et pas uniquement d'implémentation) de ces brevets. Tu ne l'as *jamais* fait malgrés de nombreuses requêtes.
> T'es pals plus intelligent que Novell ou DotGNU.
Novell est très intelligent de :
- garder tout les copyright pour eux.
- de garantir le paiement des brevets (déjà c'est en contratiction avec ce que tu dis) uniquement pour ses utilisateurs.
- de se garantir de passer le projet en proprio si les brevets le rendent incompatible avec le logiciel libre.
Tu m'expliques ça ? C'est rare en logiciel libre. Tu crois que c'est le fruit du hazard ?
Je ne crois absolument pas que c'est lié au hazard.
> Si les 2 affirment ca ce n'est pas à cause de l'ECMA
MS affirme qu'il faut payer ses brevets. D'ailleurs, MS n'a pas à l'affirmer, c'est comme ça avec les brevets. Si un brevet est gratuit, alors le détenteur du brevet l'a signifié. Donc, je te demande pour la 2000ième fois d'indique un document MS qui autorise l'utilisation illimité des brevets lié à C# et consort.
> à cause de ce que MS a autorisé pour l'utilisation de ses brevets.
Url, 2001ième requète.
> Part of ECMA Standard 335 => MS authorization for CLR/CLI/BCL implementation => Not endangered
ECMA (+ implémentation only gratuite) est incompatible GPL et logiciel libre.
Dès que tu dois payer pour utiliser ou même simplement demander l'autorisation pour utiliser, c'est incompatible avec logiciel libre.
C'est si dure que ça à comprendre ?
Tu ne connais pas la définition de libre ?
> Il y a effectivement un problème d'incompatibilité entre la GPL et la notion de brevet.
Tu n'as toujours pas compris. Il y a incompatibilité entre brevet et logiciel libre (et non uniquement la GPL). On peut faire du proprio avec la MIT car ce n'est pas une licence copyleft. S'il y a brevet, licence MIT ou pas, ce n'est plus du logiciel libre. Point barre. Microsoft le sait et Novell le sait (voir toute les dispositions qu'il a pris pour en tenir compte).
> Sauf qu'en l'occurence dans le projet Mono c'est le compilo qui est sous GPL.
Et comme "par hazard", Novell se donne, que dis-je, impose d'avoir la possibilité de changer la licence (le copyright des contributions doit être donné à Novell).
Tu répètes à l'envis qu'il n'y a 0 problème et pourtant Novell a tout fait pour prendre en compte les problèmes.
Tu m'expliques la logique de la chose ?
> System.AppDomain => sous licence MIT + ECMA/accord MS
L'accord MS est UNIQUEMENT pour l'implémentation et pas l'utilisation en général.
> System.DirectoryServices => pas implémenté dans Mono
Google et je tombe sur :
http://lists.ximian.com/archives/public/mono-patches/2004-January/0(...)
http://primates.ximian.com/~jackson/net_2_0/class-status-System.Dir(...)
> Bref, comme tu peux le constater avec quelques précisions il ne semble pas y avoir de problème.
C'est beau ça. MS dit que ECMA/accord MS est incompatible logiciel libre et tu persistes à dire le contraire. Dingue.
RAND, brevet et logiciel libre ne sont pas compatibles.
Alan Cox va te l'expliquer :
http://linuxtoday.com/news_story.php3?ltsn=2001-09-30-010-20-OP-CY(...)
> Franchement tes arguments sont pénibles.
Ton obstination a soutenir des choses que même MS ne dit pas est ... [beep].
Et puis mets des url dans on te le demande ou dis que tu ne trouves pas. Ça devient pénible ta façon t'affirmer des choses sans jamais les démontrer quand on te le demande. On n'a pas à te croire sur parole. Surtout que tu dis des conneries qui sont en contradiction avec les propos même de MS.
> T'es pals plus intelligent que Novell ou DotGNU.
Ils sont partis prenantes. Ils ne vont pas scier la branche sur laquelle ils sont assis.
Tu n'es pas plus intelligent que Microsoft ou Red Hat.
> Puisque tu sembles faire l'idiot
Je préfère faire l'idiot que t'être con. Bien le boujour chez toi.
[^] # Re: mono vs DotGNU
Posté par TImaniac (site web personnel) . Évalué à 3.
On va pas recommencer ce débat à la con, je te l'ai déjà expliqué, un brevet ca s'UTILISE que de 2 manières : on l'IMPLEMENTE ou on le vend/achète.
De toute façon dans le cas qui nous intéresse c'est l'implémentation qui nous concerne, donc le lien que je t'avais filé concernant cette partie nous suffit dans notre contexte.
d'indique un document MS qui autorise l'utilisation illimité des brevets lié à C# et consort.
Je te l'ai dit, on s'en balance, MS autorise l'implémentation pour faire un CLR, et c'est ce que fait Novell, donc dans le cas précis de Mono c'est tout ce qui nous intéresse.
S'il y a brevet, licence MIT ou pas, ce n'est plus du logiciel libre. Point barre.
Donc le kernel Linux qui viole des centaines de brevets n'est pas libre. Donc quand tu aura arrêter d'utiliser ce dangereux composant qui violent bien plus de brevets que Mono, tu reviens râler sur Mono, ok ?
Tu répètes à l'envis qu'il n'y a 0 problème et pourtant Novell a tout fait pour prendre en compte les problèmes.
Tu m'expliques la logique de la chose ?
Tu t'es pas dis que ca pouvait servir à autre chose cette atttribution de copyright ?
C'est pour permettre à Novell de vendre sous une autre licence Mono, comme le fait MySQL ou TrollTech.
Au fait, t'es pas obligé de leur filer le copyright, tu peux très bien le garder pour toi, c'est juste que ca ne sera pas dans la version officielle soutenu par Novell.
MS dit que ECMA/accord MS est incompatible logiciel libre
En l'occurence pour l'utilisation que fait Novell d'éventuels brevets toujours pas attribués, il n'y a à mes yeux qu'une incompatiblité : on ne pourra pas forker Mono pour faire autre chose qu'un CLR (à moins que MS autorise d'autres cas d'utilisation, ils ont préciser qu'ils étaient ouvert à toute requête).
Effectivement, cela fait un logiciel pas vraiment libre.
Mais comme je te l'ai répété, la plupart des LL ont exactement les mêmes contraintes, certains sans même avoir de licence ou la conscience de violer quelque chose. Au moins avece Mono on s'est de quoi il retourne.
Et puis mets des url dans on te le demande ou dis que tu ne trouves pas.
euh, tu me demandes juste des liens dans ce post, et le lien vers le fameux mail de MS tu le connais par coeur.
Ils sont partis prenantes. Ils ne vont pas scier la branche sur laquelle ils sont assis.
Sauf que l'un comme l'autre se sont p as assis sur la branche "par hasard". Ils ont réfléchi AVANT, notamment Novell.
Et Novell a clairement dit qu'ils n'avaient rien trouver qui empecher d'implémenter un CLR sans enfreindre de brevet. Bah oui parcque toi tu pars du principe que Mono viole forcement un brevet, tu oublies qu'on peut proposer une implémentation différente pour contourner ce problème.
Tu n'es pas plus intelligent que Microsoft ou Red Hat.
MS n'a jamais rien dit concernant la légalité de Mono.
Red Hat non plus, c'est juste un développeur interne qui s'est exprimé sur son blog, désolé je préfères les propos officiels de Novell à travers MDI, c'est légèrement plus crédible.
Et comme je te le répèterai jamais assez, en cas d'éventuel problème (avec des si on mettrait Paris en bouteille), on peut chercher une nouvelle implémentation de la partie concernée, et si vraiment on y arrive pas (il est quand même rare qu'il y est qu'un seul algo pour implémenter une lib), ben on vire la lib et on est trankil.
[^] # Re: mono vs DotGNU
Posté par fabb . Évalué à 1.
Je n'implémente pas mono. Donc je dois acheter les brevets. CQFD.
La démonstration est douteuse mais je fais avec tes raisonnements tordus.
> De toute façon dans le cas qui nous intéresse c'est l'implémentation qui nous concerne, donc le lien que je t'avais filé concernant cette partie nous suffit dans notre contexte.
Non non.
Rappel :
Field of use limitation: According to Herman (NB : responsable de la propriété intellectuelle chez MS), "This is where I'm granting a license to you to use my patent, but only for the purpose of implementing this standard."
Mais j'oubliais que tu as la prétention de te placer au-dessus du responsable de la propriété intellectuelle de MS.
> Je te l'ai dit, on s'en balance, MS autorise l'implémentation pour faire un CLR, et c'est ce que fait Novell
C'est bien pour Novell qui implémente mais ceux qui n'implémentent pas (un très très large majorité) ne s'en foutent pas.
> Donc le kernel Linux qui viole des centaines de brevets n'est pas libre.
Tu sais quoi, tu devrais militer pour les brevets logiciels. Dire "qu'on s'en fout", que ça coute rien, qu'un brevet implémenté différement n'est pas couvert par le brevet et toussa. T'es fort en "n'importe quoi".
Sinon, tu peux dire quels brevets viole le kernel ?
Tu n'arrêtes pas de mettre ça sur le tapis et on ne connait pas cette liste. L'article à l'origine des 283 brevets que violerait Linux n'a pas précisé de quels brevets c'étaient.
Donc, on a jamais pu vérifier la véracité de cette article.
> Au fait, t'es pas obligé de leur filer le copyright, tu peux très bien le garder pour toi
Biensur. Et si les brevets passent, tu n'as pas le droit de le distribuer (cf le commentaire de MS qui est très claire).
> En l'occurence pour l'utilisation que fait Novell
Tu ne parle que de l'utilisation par Novell. Un logiciel libre n'est pas caractérisé par le fait que Novell ou telle autre boîte à le droit de l'utiliser.
> ils ont préciser qu'ils étaient ouvert à toute requête
Url ?
Si c'est la même que la dernière foi, elle ne dit pas ce que tu prétends.
> Effectivement, cela fait un logiciel pas vraiment libre.
Un logiciel "pas vraiment libre" n'est pas un logiciel libre.
Heureux que tu finisses par le reconnaitre.
> Mais comme je te l'ai répété, la plupart des LL ont exactement les mêmes contraintes
Contrainte est différent de problème.
> Au moins avece Mono on s'est de quoi il retourne.
Rire, ce n'est pas grace à toi.
> le lien vers le fameux mail de MS tu le connais par coeur.
Ce "fameux mail" ne parle que de l'implémentation gratuite et pas de l'utilisation gratuite.
> Ils ont réfléchi AVANT, notamment Novell.
Peux-tu considérer que Red Hat y a réfléchi ?
Peux-tu considérer que MS en déposant des brevets y a réfléchi ?
> Et Novell a clairement dit qu'ils n'avaient rien trouver qui empecher d'implémenter un CLR sans enfreindre de brevet.
Absolument pas. Voir la faq de mono.
> tu oublies qu'on peut proposer une implémentation différente
Changer d'implémentation c'est pour éviter les problèmes de droit d'auteur et pas de brevet. Tu ne le sais pas encore ?
> MS n'a jamais rien dit concernant la légalité de Mono.
Tu vois. MS n'a jamais dit que mono était légal. Ou alors de façon tordu comme toi. Genre :
- Le développement de mono est légal et gratuit.
Mais MS se gardera bien de dire que l'utilisation et la distribution sont légals et gratuites.
> Red Hat non plus
Red Hat refuse de mettre mono dans Fedora Core et Fedora Extra.
Les conditions pour Fedora Extra (au cas où tu voudrais ajouter mono dans Fedora Extra) :
http://www.fedoraproject.org/wikifiles/attachments/Extras_2fCvsAcce(...)
(b) a perpetual, non-exclusive, worldwide, fully paid-up,
royalty free, irrevocable (subject to Section 3) patent license
to make, have made, use, offer to sell, sell, import, and
otherwise transfer your Contribution and derivative works
thereof, where such license applies only to those patent claims
licensable by you that are necessarily infringed by your
Contribution alone or by combination of your Contribution with
the work to which you submitted the Contribution. Except for
the license granted in this section, you reserve all right,
title and interest in and to your Contributions.
Bref, impossible de voir mono dans Fedora.
> désolé je préfères les propos officiels de Novell à travers MDI, c'est légèrement plus crédible.
En terme de crédibilité, t'as toujours pas mis d'url de MS qui prouve ce que tu avances (ça pourrait te servir pour mettre mono dans Fedora Extra).
> on peut chercher une nouvelle implémentation de la partie concernée
Tu confonds brevet et droit d'auteur. Je pense que tu fais exprès d'entretenir cette confusion et ça ne t'honores pas. Sinon t'es un con profond.
[^] # Re: mono vs DotGNU
Posté par TImaniac (site web personnel) . Évalué à 2.
T'as une logique bizzare toi.
Je n'ai pas de lecteur mp3 sur mon pc donc pas de licence, donc je dois payer les brevets. (??????????)
Je te l'ia déjà expliquer, tu confonds utilisation de l'implémentation et l'utilisation qui consiste à implémenter.
Tu n'arrêtes pas de mettre ça sur le tapis et on ne connait pas cette liste. L'article à l'origine des 283 brevets que violerait Linux n'a pas précisé de quels brevets c'étaient.
Donc, on a jamais pu vérifier la véracité de cette article.
Sauf que personne n'a contesté le fait que le noyau en violait sûrement, même pas IBM.
De plus MS a ouvertement menacer Linux d'utiliser certains brevets.
MS n'a jamais menacé Mono pour des brevets dont tu n'as pas non plus la liste et qui n'ont toujours pas été validé.
Donc pour moi c'est aussi dangereux, j'ai même envie de dire encore plus dangereux d'utiliser Linux.
Ce "fameux mail" ne parle que de l'implémentation gratuite et pas de l'utilisation gratuite.
Je t'ai déjà expliqué ce que m'a expliqué un avocat spécialiste en LL : il n'y a aucun lien juridique entre l'utilisation d'une implémentation et l'implémentation elle-même : si l'implémenteur a la licence et que MS n'a pas contraint l'implémenteur à lui reverser de royalties pour la distribution de cette implémentation, MS ne peut attaquer aucun utilisateur de l'implémentation.
Peux-tu considérer que Red Hat y a réfléchi ?
Ils n'ont pas donné leur avis sur Mono. Et ils peuvent avoir choisi Java pour d'autre raison, la première évidente qui me vient à l'esprit est de faire chier Novell.
Peux-tu considérer que MS en déposant des brevets y a réfléchi ?
Oui ils ont voulu assurer par ceux qui implémentent le CLR respecte la norme (sinon ils ne font plus un CLR et ils n'ont plus de licence), exactement comme le fait Sun avec Java en ayant forcer MS.
Absolument pas. Voir la faq de mono.
Absolument que si, voir FAQ Mono.
Changer d'implémentation c'est pour éviter les problèmes de droit d'auteur et pas de brevet. Tu ne le sais pas encore ?
Ah non tu fumes la moquette là. Un brevet logiciel est constitué d'un algorithme ou d'une méthode permettant d'effectuer quelque chose. Tu peux très bien utiliser une autre méthode pour arriver à un même résultat. D'ailleur DotGNU et MDI le disent très bien : ils cherchent à faire une implémentation qui contourne la méthode protégé.
Mais là encore t'es sûrement plus doué que DotGNU et MDI.
Mais MS se gardera bien de dire que l'utilisation et la distribution sont légals et gratuites.
MS n'a pas contraint dans sa licence d'utilisation des brevets pour implémentation qu'il y avait des contraintes sur l'utilisation de l'implémentation : donc il n'y a pas de contraintes et donc toutes libertés, en respectant bien sûr la licence de l'implémentation (MIT/GPL/LGPL). CQFD.
Tu confonds brevet et droit d'auteur.
Absolument pas. Je ne confond rien du tout. On n'a pas le code du framework .NET donc il ne risque pas d'y avoir de problème de copyright concernant Mono. Donc le droit d'auteur en l'occurence on s'en bat les c... dans ce contexte.
[^] # Re: mono vs DotGNU
Posté par fabb . Évalué à 1.
Mais c'est évident. Il est beaucoup moins dangereux d'utiliser des technologies MS avec plein de brevet que de chercher à ne pas utiliser de brevet.
T'as fumé du crack ?
> il n'y a aucun lien juridique entre l'utilisation d'une implémentation et l'implémentation elle-même
Très bien. Donc, l'autorisation d'implémenter un brevet n'a aucun lien avec l'autorisation d'utiliser l'implémentation de ce brevet.
MS n'autorise que l'implémentation en gratuit. Pour tous les autres utilisation il faut l'accord de MS et selon les conditions de MS. CQFD.
> si l'implémenteur a la licence et que MS n'a pas contraint l'implémenteur à lui reverser de royalties pour la distribution de cette implémentation, MS ne peut attaquer aucun utilisateur de l'implémentation.
Trouves moi un texte qui le dit.
T'es mignon. MS dit clairement que *seule* l'implémentation est autorisée gratuitement et tu en déduits que le brevets est librement utilisable.
Questions :
- pourquoi MS n'a pas dit que l'utilisation est libre et c'est limité à dire que seul l'implémentation gratuite est autorisé ?
> la première évidente qui me vient à l'esprit est de faire chier Novell.
Et quel évidence !
Si ntfs n'est pas activé, c'est pour faire chier qui ?
S'il n'y a pas de mp3, c'est pour faire chier qui ?
S'il n'y a pas ffmpeg, c'est pour faire chier qui ?
S'il n'y a pas wine, c'est pour faire chier qui ?
S'il n'y avait pas valgrind (jusqu'à ce que IBM autorise l'utilisation de certains brevets pour des projets libres) c'est pour faire chier qui ?
etc...
Je peut te confirmer un truc : les brevets logiciels font chier dans les grandes largeurs le libre.
Faut arrêter d'urgence le crack. mon coco.
> exactement comme le fait Sun avec Java en ayant forcer MS.
Tu inventes encore et tu n'as jamais avancé de preuve.
> Absolument que si, voir FAQ Mono.
T'es d'une mauvaise fois incroyable :
http://www.mono-project.com/FAQ:_Licensing#Patents(...)
> Un brevet logiciel est constitué d'un algorithme ou d'une méthode permettant d'effectuer quelque chose.
Si c'est si "simple", pourquoi le logiciel libre n'arrive pas a faire un codec mpeg4 sans utiliser les brevets ?
Pour avoir une solution libre en vidéo, il a fallu tout faire from scratch (theora) qui ne lis pas ni n'écrit de mpeg4. Idem pour mp3.
> Mais là encore t'es sûrement plus doué que DotGNU et MDI.
Tu sais quoi, puisque tu es très très fort, tu devrais aider ffmpeg, mpg321, lame, linux (et ces soit disant 283 brevets que personne connait), etc pour virer l'utilisation des brevets puisque c'est si simple.
À se demander pourquoi MS déposent des brevets si c'est si simple de les contourner.
À se demander s'il y a un intérêt à être anti-brevet puisque c'est si simple à contourner.
> MS n'a pas contraint dans sa licence d'utilisation des brevets pour implémentation qu'il y avait des contraintes sur l'utilisation de l'implémentation : donc il n'y a pas de contraintes et donc toutes libertés, en respectant bien sûr la licence de l'implémentation (MIT/GPL/LGPL). CQFD.
Encore des conneries monstrueuses et dans ta prétention absolue tu croire que le seul fait que tu les dises les rendent vrai.
Lorsqu'on a un brevet, on a l'exclusivité du brevet. Si une utilisation d'un brevet n'est pas autorisée, alors elle est interdite !
> On n'a pas le code du framework .NET donc il ne risque pas d'y avoir de problème de copyright concernant Mono.
Tu le fait exprès. Personne ne parle de problème de copyright mais de brevet. Et toi tu pars sur le copyright.
N'importe quoi.
Ce qui me fait vomir chez toi c'est que tu le fais exprès. Tu cherches intentionnellement à tromper les gens.
T'es puant.
[^] # Re: mono vs DotGNU
Posté par TImaniac (site web personnel) . Évalué à 2.
Linux utilise des technos MS puisque MS a menacé d'attaquer Linux.
Pour tous les autres utilisation il faut l'accord de MS et selon les conditions de MS. CQFD.
On est d'accord. Et quand on utilise Mono on utilise pas les brevets de MS, il n'y a que Mono qui les utilise. CQFD.
Trouves moi un texte qui le dit.
Trouve moi un texte qui me montre qu'il y a un lien, avec s'il te plait un cas concrêt de licence accordé sans restriction sur la distribution comme c'est le cas de la licence accordé par MS.
- pourquoi MS n'a pas dit que l'utilisation est libre et c'est limité à dire que seul l'implémentation gratuite est autorisé ?
Parcqu'ils veulent garder des droits sur leurs brevets s'ils sont utilisés pour faire une cafetière.
Si ntfs n'est pas activé, c'est pour faire chier qui ?
S'il n'y a pas de mp3, c'est pour faire chier qui ?
S'il n'y a pas ffmpeg, c'est pour faire chier qui ?
S'il n'y a pas wine, c'est pour faire chier qui ?
Ben ces licences indique clairement que l'implémenteur doit répondre à des contraintes sur la redistribution de son implémentation. Donc Red Hat ne peux redistribuer sans donner de royalties. Dans le cas de la licence concernant Mono et MS, il n'y a pas de contraintes (obligation de royalties etc.)
Wine c'est différent, y'a pas vraiment de licence.
Tu inventes encore et tu n'as jamais avancé de preuve.
Si si je t'ai filé 2 liens plus haut mon coco.
Si c'est si "simple", pourquoi le logiciel libre n'arrive pas a faire un codec mpeg4 sans utiliser les brevets ?
Parcque les codecs sont essentiellement constitué d'un format d'encodage qui correspond exactement à un algorithme d'encodage et/ou de décodage : bref y'a pas moy d'échapper dans ce cas précis aux algo brevetés, d'où la nécessité d'avoir une licence.
Mono n'est pas un codec, et pour implémenter une lib (bref une interface constitué de méthode), il y a un peu plus de possibilités tout de même.
À se demander pourquoi MS déposent des brevets si c'est si simple de les contourner.
Houlà j'ai pas dis que c'était simple. Je constate juste que DotGNU et MDI ont clairement dit qu'ils tentaient d'éviter les techniques brevetés.
et si c dangereux les brevets c qu'ils peuvent être trop généraliste ou contraignant, comme pour les codecs.
ncore des conneries monstrueuses et dans ta prétention absolue tu croire que le seul fait que tu les dises les rendent vrai.
Je répète ce que dis Novell et l'avocat que j'ai rencontré. J'invente rien.
[^] # Re: mono vs DotGNU
Posté par TImaniac (site web personnel) . Évalué à 2.
"Patent issues are not new for the linux kernel. Redhat patented Ingo Molnar's work, and the SELinux project faced patent claims from the company hired to do most of the coding. Now patent concerns are plauging the VM"
( http://kerneltrap.org/node/388(...) )
Linux VM hackers are engaged in ongoing discussions on both large page support (covered last week) and improving the performance of the new reverse mapping mechanism. That conversation slowed down, however, when Alan Cox pointed out that a number of the techniques being discussed are covered by SGI patents. In fact, a closer look by Daniel Phillips shows that a number of existing Linux technologies, including reverse mapping in general and the buddy allocator, are covered by these patents. This is a problem, he said, that we can't ignore.
( http://lwn.net/Articles/7632/(...) )
"Linux ally IBM turned out to own the largest number of patents uncovered in Ravicher's research. Big Blue held 60 patents that could conceivably threaten the Linux kernel. Hewlett-Packard, Intel and Novell also held some of the patents in question, Ravicher said."
( http://www.nwfusion.com/news/2004/0802linuxstu.html(...) )
ah oui dans la liste y'en a aussi 27 de MS, plus que ceux de MS sur .NET.
ca te suffit comme justificatif pour dire que Linux en viole un bon paquet ?
et personne ne le nie sauf toi.
[^] # Re: mono vs DotGNU
Posté par fabb . Évalué à 1.
Il y a les discussions pour virer les problèmes de brevets. Ça arrive.
Il y a des brevets qui ont été introduits par une boîte qui possède le brevet et là mis sous GPL. Pour le mettre dans un source GPL, ça implique qu'il accèpte la licence.
Il y a les brevets, qui comme pour mono peuvent être implémenté mais ne peuvent pas être utilisé. Typiquement, Red Hat livre les sources de ntfs mais le module n'est pas compilé.
Il y a les brevets qui sont utilisé "à tord" mais où le prio art est facile à prouver.
Enfin, et c'est les pires, il y a des brevets qui ne doivent pas se retrouver dans les sources. Dans une distribution type Fedora certaines mesures sont prises (Debian fait aussi de même je crois).
Par exemple le src.rpm de openssh n'a pas le tar.gz d'origine comme tous les autres paquets. Il a le tar.gz sans une portion qui pose un problème de brevet.
Une fois que t'a virer les "vrais-faux problème", il ne reste plus grand chose.
Ainsi, IBM introduit beaucoup de brevet de son propre chef (mais IBM autorise l'utilisation de ses brevets dans le noyau Linux). Ces "problèmes" de brevets ne devrait pas être compatilisé car il n'y a pas problème. C'est aussi certainement le cas les brevets Intel et Novell.
Donc, il faut analyser au cas par cas. Dans ce cas, je suis persuadé que Linux et plus particulièrement Red Hat (en ne compilant pas ntfs par exemple) a très peu de problème de brevet. Genre un dizaine. Vu la taille du projet, c'est remarquable.
Enfin, a titre d'exemple, si SGI par exemple lève le petit doigt, il se fait explosé par IBM ou Intel.
Donc les 283 brevets il convient de bien les modérer car la majorité des brevets ont été introduits par les propriétaires des brevets.
[^] # Re: mono vs DotGNU
Posté par TImaniac (site web personnel) . Évalué à 2.
hors la licence dis clairement qu'elle n'est pas compatible avec les brevets, quelle que soit la licence du brevet...
Il y a les brevets, qui comme pour mono peuvent être implémenté mais ne peuvent pas être utilisé. Typiquement, Red Hat livre les sources de ntfs mais le module n'est pas compilé.
Ce qui est complètement idiot puisque la licence d'implémentation d'un brevet ne se borne pas au binaire.
(mais IBM autorise l'utilisation de ses brevets dans le noyau Linux).
idem, celà reste incompatible avec la GPL quand même...
Dans ce cas, je suis persuadé que Linux et plus particulièrement Red Hat (en ne compilant pas ntfs par exemple) a très peu de problème de brevet. Genre un dizaine. Vu la taille du projet, c'est remarquable.
Peut être mais n'empêche que c'est dangereux... surtout dans un produit GPL.
Donc les 283 brevets il convient de bien les modérer car la majorité des brevets ont été introduits par les propriétaires des brevets.
Et les 27 de Microsoft ?
[^] # Re: mono vs DotGNU
Posté par patrick_g (site web personnel) . Évalué à 3.
C'était clair, argumenté et informatif et j'en avais retenu qu'il valait nettement mieux se tenir à l'écart des deux.
Ca mettrait peut-être fin aux controverses interminables comme le thread ci-dessus.
[^] # Re: mono vs DotGNU
Posté par TImaniac (site web personnel) . Évalué à 0.
MDI et Novell ont donné le leur sur Mono.
Tu m'expliques en quoi l'avis de ce Boubou aurait plus de valeur que ces 2 là.
[^] # Re: mono vs DotGNU
Posté par patrick_g (site web personnel) . Évalué à 4.
parcequ'il a pris du recul pour considérer la situation dans son ensemble ?
parceque son analyse est claire et en français ce qui pourra permettre aux non anglophones de se faire une opinion ?
[^] # Re: mono vs DotGNU
Posté par TImaniac (site web personnel) . Évalué à 0.
pourquoi plus de recul que Novell ? Quand Novell s'est intéressé à Mono il n'était toujours pas impliqué et avait autant de recul, et sans doute une batterie d'avocat pour examiner la situation.
parceque son analyse est claire et en français ce qui pourra permettre aux non anglophones de se faire une opinion ?
Il ne pourra lui même qu'analyser des textes anglais, je ne vois absolument pas en quoi sa traduction serait meilleures que l'original. Pour se faire une opinion il faut encore mieux garder le texte original. Regarde les prob de traduction de la GPL.
Bref, ce monsieur n'a pas la science infuse, et je ne vois pas en quoi il pourra arrêter le débat alors que d'autres tente de le faire avec beaucoup plus de moyens ( Novell).
[^] # Re: mono vs DotGNU
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
http://about.me/straumat
[^] # Re: mono vs DotGNU
Posté par patrick_g (site web personnel) . Évalué à 2.
[^] # Re: mono vs DotGNU
Posté par TImaniac (site web personnel) . Évalué à 0.
[^] # Re: mono vs DotGNU
Posté par Philip Marlowe . Évalué à 1.
[^] # Re: mono vs DotGNU
Posté par push . Évalué à 1.
T'es vraiment un cas toi c'est pas possible.
[^] # Re: mono vs DotGNU
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: mono vs DotGNU
Posté par patrick_g (site web personnel) . Évalué à 3.
Ca serait vraiment bien si F. Rossi (Boubou) pouvait mettre en ligne dans un avenir pas trop éloigné son article récapitulatif sur les problèmes juridiques Mono/java.
C'est justement pour t'éviter de l'acheter que je lançais cet appel.
[^] # Re: mono vs DotGNU
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: mono vs DotGNU
Posté par boubou (site web personnel) . Évalué à 3.
Qui te parle de traduction ? On te dit que mon article permet d'accéder à des informations qui sont à l'origine en anglais, pas de fournir une traduction des textes.
Bref, ce monsieur n'a pas la science infuse, et je ne vois pas en quoi il pourra arrêter le débat alors que d'autres tente de le faire avec beaucoup plus de moyens ( Novell).
Parce que je ne paye pas des développeurs à implémenter une version open source de .NET, parce que je ne cherche pas à augmenter mes parts de marché avec ma distribution linux, etc.
Ce qu'il y a de formidables avec toi, c'est qu'en plus de raconter n'importe quoi dans une "discussion" (et ceci sans aucun argument), tu es même capable d'attaquer quelqu'un que tu ne connais pas sur la pertinence d'un texte que tu n'as pas lu. En termes plus clairs, tu est un imbécile et je ne débattrai donc pas avec toi.
[^] # Re: mono vs DotGNU
Posté par TImaniac (site web personnel) . Évalué à 1.
Moi. Tu as forcement dû traduire pour ton article des propos en anglais. Je dis pas que tu as fourni des traductions mais toi comme moi avons dû procédé à l'interprétation de textes anglais, donc je ne vois pas en quoi le fait que ton article soit en français soit plus pertinent que mon interprétation des propos de MDI par exemple.
Parce que je ne paye pas des développeurs à implémenter une version open source de .NET, parce que je ne cherche pas à augmenter mes parts de marché avec ma distribution linux, etc.
Et moi je paie des gens ? Je cherche à augmenter mes parts de marché ?
Ok j'ai un parti pris, mais je ne vois pas en quoi tes propos pourront faire taire le débat, ils peuvent sûrement nourrir le débat et y apporter un point de vue bien argumenté avec une analyse clair, mais si le débat pouvait être clos les juristes l'aurait fait depuis longtemps.
Ce qu'il y a de formidables avec toi, c'est qu'en plus de raconter n'importe quoi dans une "discussion" (et ceci sans aucun argument)
C'est quoi ce n'importe quoi ?
tu es même capable d'attaquer quelqu'un que tu ne connais pas sur la pertinence d'un texte que tu n'as pas lu.
A AUCUN moment je n'ai mis en cause le contenu de ton article, j'ai juste voulu minimiser l'affirmation qui tentait de dire que ton article ferait taire le débat.
En termes plus clairs, tu est un imbécile et je ne débattrai donc pas avec toi.
D'après le maigre résumé que j'ai lu plus haut de ton article, tu conclus que les technos Java et Mono c'est à éviter tous les 2. Je suis en tout cas beaucoup plus d'accord avec toi qu'avec certains : pour moi Java et Mono c'est kif kif bourriquot légalement.
[^] # Re: mono vs DotGNU
Posté par boubou (site web personnel) . Évalué à 3.
Quelle puissance dans l'argumentation, c'est sidérant. Quand le pape parle (ce qui n'arrive plus beaucoup, ces temps ci), il a raison, parce que c'est le pape. Formidable, n'est-ce pas ? Donc, comme MDI (très connu pour son extraordinaire mauvaise foi) et RMS (très connu pour son dogmatisme) ont parlé, je n'ai plus rien à dire...
Venant de toi, ceci dit, ça ne m'étonne pas. D'autant plus que tu n'as même pas lu mon article.
[^] # Re: mono vs DotGNU
Posté par TImaniac (site web personnel) . Évalué à 2.
Cela dit tout est parti d'un mal entendu, j'ai mal lu la phrase initiale, et on m'a donné à plusieurs reprises un lien vers le journal parlant de ton article comme "argument", ce que je trouves passablement énervant quand le dit journal ne reprend aucun argument de ton article, et est donc parfaitement inutile (le lien, pas ton article).
[^] # Re: mono vs DotGNU
Posté par boubou (site web personnel) . Évalué à 3.
C'est prévu, dans quelques jours j'espère. J'ai eu l'accord de Denis Bodor, que je remercie au passage.
[^] # Re: mono vs DotGNU
Posté par patrick_g (site web personnel) . Évalué à 4.
Il faudra faire un journal (voire même une news) afin de tuer quelques trolls récurrents.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.