0
Il y a toujours eu beaucoup de critiques sur le travail de Miguel de Icaza en ce qui concerne Mono et C#. Outre la méfiance envers tout ce qui vient de Microsoft, l'argument le plus souvent employé est que le monde du libre va être perpétuellement à la traîne de Microsoft et ne pourra donc jamais innover. Comme C# est une techno Microsoft la conséquence logique c'est que de Icaza et ses développeurs vont se contenter de plus ou moins tout réimplémenter et qu'ils ne pourront jamais décider du futur de cette technologie.
Si cet argument semble de bon sens je n'en avait toutefois jamais vu de manifestation concrète....jusqu'à aujourd'hui.
Le groupe Microsoft chargé de la future version 4 de C# vient de donner une interview sur leur travail : http://channel9.msdn.com/posts/Charles/C-40-Meet-the-Design-(...)
C'est essentiellement beaucoup de blabla sans aucun détail technique spécifiques sur les nouveautés du langage.
Miguel de Icaza a posté une entrée dans son blog au sujet de cette interview. Il commence par s'extasier sur le fait que la team C# de Microsoft se réunit dans la même pièce 3 fois par semaine et depuis 9 ans. Pour Miguel cela explique pourquoi le langage a aussi bien évolué.
Mais ce qui est vraiment révélateur/fascinant/consternant/hallucinant ce sont les 2 phrases suivantes de Miguel :
"Malheureusement il n'y a pas de détails dans l'interview à propos des nouveautés de C# 4.0. Nous devons attendre jusqu'au PDC (Professional Developers Conference) pour avoir une idée de ce qui va arriver.
Heureusement, le compilateur C# de Mono est déjà compatible avec la version 3.0 et nous sommes prêt à ajouter les fonctions de la version 4.0 dès qu'elles seront rendues publiques".
C'est vraiment l'aveu franc et ingénu du mode de développement de Mono/C# par Miguel de Icaza et son team. On laisse Microsoft décider de tout et ensuite on réimplémente avec plusieurs mois/années de retard. Le monde du libre n'a rien à dire.
Autrement dit et pour reprendre la critique du début : "ils ne pourront jamais décider du futur de cette technologie".
Conclusion : Faire reposer des éléments essentiels de l'écosystème Linux sur Mono/C# est dangereux car c'est Microsoft le seul et unique décideur.
> Lire le journal (298 commentaires, moyenne: 2,8).
Vous avez demandé le commentaire #952046.
Run by 
Cette page a été générée par Templeet en 0.1179s (dont 0.0102 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Tout à fais d'accord
Histoire vraie, version courte :
1) Réception d’un cahier des charges avec comme contrainte que l’implémentation soit multi-plateforme (au moins Windows et Linux).
2) Réponse avec C# et .Net, car les décideurs pressés, ils connaissent bien C# et .Net, ça fait high-tech, alors que Qt machin et Gtk truc, c’est moins "sexy", quelques tests montrant que Mono fait l’affaire à condition de rester en version 2.0 de .Net.
Résultat de l’affaire pour le client, l’image de Microsoft en sort grandie car ils sont à l’origine de la techno utilisée, le libre n’a qu’une image de suiveur. Au final seul l’implémentation sous Windows sera utilisée, car tant qu’à utiliser des techno Crosoft autant le faire sous Windows.
Les affaires comme ça sont monnaie courante, le libre ne gagnant que si le client montre une réelle attraction dès le cahier des charges ou que le libre à une killer feature.
Ma dernière killer feature ayant été Qgis (http://www.qgis.org/), un moteur vraiment simpat pour afficher de la carto, multi-plateforme (Qt oblige) et bien plus rapide que le moteur sous Java utilisé alors par le client.
[^]Re: Tout à fais d'accord
C'est fichtrement vraie et c'est la triste vérité ...
Cependant, ces bindings et cette implémentation (mono) est également TRES nécessaire. Attention, je ne dis pas que f-spot/tomboy/beagle/banshee doivent être développé en c#/mono (On est libre ou non de les utiliser).
La couche ".net" est quand même, qu'on le veuille ou non, voué à devenir de plus en présente. Il serait quand même dommageable pour le libre, que mono n'existe pas sous un os libre. Oui, ça n'attire pas les foules actuellement. Mais il est vital (à mon sens) que mono, et le icaza, continuent leur job. Histoire de pouvoir offrir une alternative libre, le jour où "on en aura besoin".
Et dans le meilleur des mondes (mode utopique), quand il y aura plus de gens qui utiliseront linux/mono ... ça sera novell/icasa et compagnie qui leaderont les orientations de c#/mono/.net
manatlan.com
[^]Re: Tout à fais d'accord
Il faut que Mono continue à exciter et à être développé pour porter des appli qui viendraient de Window$ mais il ne faut pas baser des logiciels libre dessus si on veut les faire évoluer avec le langage. C'est, je pense, ce que veut dire ce journal.
[^]Re: Tout à fais d'accord
> il ne faut pas baser des logiciels libre dessus si on veut les faire évoluer avec le langage
En même temps, quand tu développes un logiciel, tu le penses pour le langage actuel, pas une "éventuelle amélioration future du langage". Quand tu fais du Python, tu ne le penses pas "pour qu'il évolue avec Python 3k", quand tu fais du Perl, tu ne te dis pas "je vais le coder pour qu'il puisse éventuellement profiter des améliorations de Perl 6". Et ainsi de suite pour C++/C++0x, et... Mono/C# 4.
Le dev de tomboy qui a choisi le C#, il a choisit le C# de son époque, pas en soupirant après C# 4. C'est pour ça qu'on s'en fout un peu, au final, que Mono soit à la traine. Tomboy fonctionne, il évoluera indépendamment du langage. Aucun danger venant du "retard des devs Mono".
[^]Re: Tout à fais d'accord
Je rappelle que C#, via .Net, c'est aussi, comme on l'a déjà dit plus haut, tout un ensemble de bibliothèque qui vont avec. Et l'évolution des bibliothèques est importante. Si kde avait du attendre un an de plus que les fonctionnalité de qt soient recodées, ont aurait pu attendre longtemps kde4 avec toutes ces évolutions.
[^]Re: Tout à fais d'accord
A mon avis, quand le journal parle d'"éléments essentiels de l'écosystème Linux", il ne parle pas de Tomboy.
[^]Re: Tout à fais d'accord
> Histoire de pouvoir offrir une alternative libre, le jour où "on en aura
> besoin
A développer mono et des logiciels sous mono, on participe à l'écosystème et on va se chopper une dépendance un jour...
On peut très bien faire un système sans base de registre... On n'a pas besoin dans UNIX d'avoir les API Windows qui ne sont pas POSIX !
L'important est d'avoir des logiciels sous UNIX qui sont utilisable par les utilisateurs. L'important est que Firefox marche sous UNIX et sous Windows, qu'importe comment il fonctionne sous Windows.
Tout ce qui peut être développé sous mono peut l'être dans un autre environnement. La question est donc de savoir si on aurait pas pu mettre l'énergie sur ces autres environnements ?
Le logiciel samba est très différent, le but est de faire communiquer des mondes différents. Mono n'a pas vraiment cet objectif : qui utilise mono sous Windows aujourd'hui ?
Mono, cela me rappelle le projet ReactOS. Beaucoup d'énergie pour un objectif peu satisfaisant.
Je préférerais que Novell mettent ses moyens sur Parrot. Si Novell n'avait mis qu'1/10 de ce qu'elle met sur Mono aujourd'hui dessus, je suis sur que Parrot serait déjà pleinement opérationnel de nos jours.
[^]Re: Tout à fais d'accord
Le logiciel samba est très différent, le but est de faire communiquer des mondes différents. Mono n'a pas vraiment cet objectif : qui utilise mono sous Windows aujourd'hui ?
La liste est dans la page de mono : des softs destinés à fonctionner à la fois sous windows, linux et macos X.
[^]Re: Tout à fais d'accord
Il y a plein de logiciels qui fonctionnent à la fois sous Windows, Linux et MacOS e t qui ne sont pas programmé avec mono. Il suffit de programmer dans un environnement multiplateforme et de recompiler sur chaque.
Bref, je comprends que certaines personnes programme avec .NET parce qu'elles aiment cet environnement. Mais d'un point de vue personnel, je ne vois pas ce qu'il apporte de plus a par des inconvénients.
[^]Re: Tout à fais d'accord
y'a pleins de chose qui n'apportent rien de plus. Quand aux inconvénients, je ne les vois pas. Si quelqu'un préfère C# à d'autres langage, tant mieux pour lui si mono existe, ça nous fait un developpeur potentiel pour du libre sous nos OS.
[^]Re: Tout à fais d'accord
Et il se trouve que Mono est justement un environnement multiplateforme ... Et qu'il est suffisament attractif pour que des gens le préfèrent à d'autres alternatives.
Il y a des gens par exemple qui n'aiment pas C++ (donc exit Qt, wxWidgets) et n'aiment pas non plus programmer en C des choses trop complexes (exit GObject en C, et ça ne marche même pas sous Mac OS X).
Maintenant il reste des langages comme Python, Perl ou Ruby (et d'autres que j'oublie, mais le fait que ce soient des “langages de script” peut faire fuir des gens) ... Et Vala (encore peu utilisé) pour GObject (surprise, Vala reprend la syntaxe C#) ... et Mono
La Roue du Temps
[^]Re: Tout à fais d'accord
t'en a oublié un, et pas un petit : Java
mais bon, les gens oublient vite (surtout les défenseurs de mono) que celui-ci n'a été créé que pour concurrencer java.
[^]Re: Tout à fais d'accord
> exit GObject en C, et ça ne marche même pas sous Mac OS X
Sources ? Il me semble que Gtk marchouille pas trop mal sous OSX
[^]Re: Tout à fais d'accord
La vérité, c'est que le libre n'est pas simplement suiveur. Qu'en est il des langages comme Python ou Ruby ? On ne peux pas dire que le libre ne sait pas innover. De même, Microsot innove, et lorsqu'il a de bonnes idées, je ne vois pas pourquoi on ne pourrait pas les avoir aussi (car Python et Ruby sont déjà disponibles sous Windows).
Je ne vois pas quel mal il y a à admettre que Microsoft fait des bons trucs de temps en temps, et a les implémenter.
La Roue du Temps
[^]Re: Tout à fais d'accord
On ne parle pas de la qualité du langage mais du fait qu'il est dangereux de baser des applications libre dessus.
[^]Re: Tout à fais d'accord
sauf que les arguments comme quoi ce serait dangereux, on les attend encore.
1) Les risques liés aux brevets sont applicables à tous les langages, au contraire mono est protégé puisqu'il implémente avec l'accord des détenteurs de brevets, contrairement à d'autres langages dont certaines parties peuvent être touchées par les mêmes brevets.
2) Le fait que Microsoft détient la clé des évolutions de .NET ne constitue pas un danger, mais au pire, une contrainte. Et alors ? Ce ne sont pas les dev linux qui ont décidé des choix de nombres protocoles réseaux, d'autres langages, et de la même façon ils doivent faire avec et implémenter ces choses sans le moindre pouvoir décisionnel.
3) Le fait que mono soit à la traine par rapport à .NET. Ce n'est pas plus un danger. Au pire c'est un délai qui n'empêche pas de - bien - développer une appli
4) Le fait que Microsoft pourrait s'écarter des implémentations validées par l'ECMA :
- c'est très improbable car ça ferait autant chier les dev .NET sous windows pour lesquels le code serait cassé du jour au lendemain. Bref ce n'est ni dans les intérêt de MS, ni de ses utilisateurs.
- n'est pas encore arrivé.
- n'emêche pas mono de suivre les implémentations standardisés et éventuellement une version suivant celle de Microsoft en cas de besoin : c'est chiant et ça donne du boulot supplémentaire, mais ça n'empêche pas les applis existantes de fonctionner.
Bref, on ne voit toujours pas où est le danger. ça tient surtout de la paranoïa de l'accroc aux théories de conspirations.
[^]Re: Tout à fais d'accord
>>Le fait que mono soit à la traine par rapport à .NET. Ce n'est pas plus un danger. Au pire c'est un délai qui n'empêche pas de - bien - développer une appli
Déja quand je vois que dans ma boite, on bosse avec c# 2 et il est implémenté par mono. Après c'est sur qu'on passera à c# 3 mais d'ici là il marchera depuis très longtemps sur mono. De même pour c# 4.
Et je ne pense pas que ma boite soit un cas isolé.
[^]Re: Tout à fais d'accord
Effectivement, la situation est identique dans la mienne.
MonoFrance
[^]Re: Tout à fais d'accord
Ouai c'est bien ce que je me disais, que je n'étais pas le seul dans ce cas.
[^]Re: Tout à fais d'accord
situation identique ici aussi
manatlan.com
[^]Re: Tout à fais d'accord
1) Ça peut changer, je fais confiance à m$ pour que ça arrive
2) Le fait que ce soit m$ qui détient toutes les clefs (contrairement aux autres qui sont défini par un groupe de gens/société) cela veut dire qu'il pourront ne pas intégrer des fonctionnalités qui seraient très utiles pour les applis libres et qui donc ne seraient pas disponible.
3) c'est un délai qui peut être très long
4) les gens utiliseraient .Net et ne verra pas que ce n'est pas les spécifications de l'ECMA, ça ferait juste chier les développeur Mono et leurs utilisateurs. Et ce n'est pas parce que c'est pas encore arriver que ça n'arrivera pas, la société a déjà un passé assez charger de truc dans le genre.
[^]Re: Tout à fais d'accord
>>Le fait que ce soit m$ qui détient toutes les clefs (contrairement aux autres qui sont défini par un groupe de gens/société) cela veut dire qu'il pourront ne pas intégrer des fonctionnalités qui seraient très utiles pour les applis libres et qui donc ne seraient pas disponible.
Ce n'est pas une attaque, c'est juste pour savoir. Qu'est ce qui pourrait être nécessaire à un application libre mais pas à une application "entreprise" qui entrainerait que les devs de .Net ne se penche pas sur le problème ?
[+] [^]Re: Tout à fais d'accord
Franchement, je n'en ai aucune idée pour l'instant et je n'ai pas envie de passer du temps à y réfléchir mais peut-être que le futur nous le montrera. Et ce n'est pas le fait que ce soit une appli libre mais une appli importante dans le fonctionnement de gnome.
[^]Re: Tout à fais d'accord
1) non ça ne peut pas changer, on ne peut retirer à postériori une autorisation d'utiliser un brevet.
2) les specs d'un langage n'a rien à voir avec la licence de destination des programmes qui seront créés avec. Je ne vois pas en quoi des fonctionnalités peuvent être plus utiles à des applis libres qu'à des applis non libres. Ce n'est pas un argument.
3) long ? pas au sens industriel du terme. Quand on voit que des applis java sont vendues et validées uniquement sur des jre anciennes (=< 1.4), franchement je ne vois pas où est le problème.
4) ça casserait tout de même la compatibilité d'un programme .Net 2.0 chez un utilisateur ayant la version 4.0. Donc non ce ne serait pas sans conséquences que pour les utilisateurs/developpeurs de mono.
Bon à part ça utiliser la dénomination "m$" ne fait pas preuve d'une grande maturité et objectivité devant le sujet abordé.
[^]Re: Tout à fais d'accord
1) tu as une preuve de ça, je ne l'ai trouvé nul part
2) pas des appli libre mais des applis importantes pour le fonctionnement de gnome (qu'elles soien libre ou pas)
3) a) Mono mettrait peut-être très longtemps pour la nouvelle version
b) les développeurs libre sont plus rapides
4) ça m'étonnerait que la compatibilité soient totale entre la 4 et la 2.
sinon pour m$, je vois pas ce que ça change, ce n'est pas un secret qu'ils se font plein de fric et je pense que certains trucs qu'ils ont fait ne sont pas mauvais.
[^]Re: Tout à fais d'accord
2) Mono/C#/.NET propose (comme la plupart des plateformes) d'appeler des composants écrits en "natif" (C/C++). Bref, il est virtuellement possible d'utiliser tout et n'importe quoi. D'ailleur on a GTK#, Gnome#, dbus-sharp, Mono.Unix, etc.
3) Là c'est un problème qui n'a pas grand chose à voir avec C# en soit. Les premiers draft de specs sortent bien avant l'implémentation finale de MS.
4) .NET propose de toute façon depuis sa création un mécanisme de "profile" permettant d'installer côte à côte plusieurs versions du framework. L'histoire montre que les quelques incompatibilités qu'il y a entre versions sont liées essentiellement à des contraintes de sécurité. Très peut de comportement différent, et seulement dans des libs.
De plus, il faut bien différencier langage, plateforme, et lib.
.NET 2.0, .NET 3.0 et .NET 3.5 ne sont que des (grosses)"upgrades" de libs et de langages, la plateforme n'a pas bougée, c'est le même environnement d'exécution, et ca Mono l'a et ca marche toujours.
Le nerf de la guerre, c'est les libs. Mono sera toujours en retard sur la stack Microsoft, mais ils proposent aussi une stack indépendante et orientée logiciels libres, qui n'a pas grand chose à voir avec ce que propose Microsoft. Bref, on peut faire abstraction de Microsoft (si ca gène certains) et ne garder que la plateforme Mono, qui propose des technos libres (GTK, Gnome, DBus, etc.).
MonoFrance
[^]Re: Tout à fais d'accord
1) dans le droit commun, si tu donnes une autorisation et que tu ne spécifie pas de durée, tu ne peux plus la rétracter, sauf clause spéciale préalable. Dans le cas d'un brevet, l'autorisation dure la durée dudit brevet. C'est en tout cas comme ça dans le droit français.
un lien parlant des brevets traditionnels, ce n'est pas une preuve et on n'en a pas besoin puisque de toute façon en france les brevets logiciels n'existent pas :
http://fr.jurispedia.org/index.php/Licence_de_brevet_(fr)
2)
-gnome n'est pas un élément critique de nos bureau. Il est remplaçable.
-Si une lib ou du code est à réécrire, ça peut toujours se faire le cas échéant. Quand GTK est passé à la version 2, il a bien fallu réécrire une grande partie de gnome. C'était pas de la faute de MS.
-on peut dans mono garder une compatibilité ascendante de toute manière si on a peur des changements. Rien n'oblige de baser les nouvelles versions de tomboy/beagle/banshee/autre sur les nouvelles specs de Microsoft tant que mono garde cette compatibilité
4) même si la compatibilité ne l'était pas sur le framework MS (je n'ai jamais rencontré ce cas), on peut-très facilement linker sous linux sur telle lib, donc il y'aurait toujours une issue.
pour m$, parles-tu aussi de $un, de R€dhat, de $u$e Linux, $endmail, ou My$ql ? J'en doute. Pourtant même si elles font du libre, ces entités cherchent tout autant à faire de l'argent.
[^]Re: Tout à fais d'accord
ce n'est pas une preuve et on n'en a pas besoin puisque de toute façon en france les brevets logiciels n'existent pas :
C'est vrai qu'on en pas besoin après tout
1°) Tu n'auras jamais a te défendre contre un brevet logiciel qu'a accepté l'OEB et qui devra etre annulé par la justice, et ceux contre une multinationale.
(l'OEB a accepté plus de 30 000 brevets pas tout a fait légal. Les brevets accepté par l'OEB doivent etre invalidé par la justice => procédure judiciaire longue et couteuse).
2°) Tu ne pourras jamais être inquiété si tu vas aux USA.
(cf Dmitry Sklyarov)
Ah ben tiens, si les 2 cas marche. C'est con hein.
Bref comme d'hab pas de preuve, et des affirmations fausses.
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: Tout à fais d'accord
2: va falloir m'expliquer la relation de cause "m$ détient toutes les clefs" à effet "il pourront ne pas intégrer des fonctionnalités qui seraient très utiles pour les applis libres et qui donc ne seraient pas disponible". Gtk# n'existe pas, on m'aurait menti ?
3: ça pourrait être des siècles que ce serait pas pour autant un "danger"
4: les "gens" dont on parle ici développent des applis libres pour un bureau libre, tu penses vraiment que des devs gnome seraient assez stupides pour se rendre incompatible avec Mono ? Oui, pour les industriels qui comptent sur Mono pour faire du multi plateforme, ça peut être génant. Mais ça tombe bien, ce n'est pas la question ici...
[^]Re: Tout à fais d'accord
ben, ca en fait un défaut, non ?
Windows has no users. It has hostages.