Articles précédents : Logiciel
- [59] Wormux 0.4
- [59] Nouveaux pilotes nvidia 6106
- [15] Phplop 0.7 sort prendre l'air
- [13] NuFW 0.7.1 est sorti, proposant un nouveau système pour le SSO
- [67] Mac OS X et les technologies du libre
- [86] Sortie d'Eclipse 3.0 finale
- [56] Sortie de WineX 4.0
- [20] xdTV 1.9.2 "Keuleu" est sortie : que fait donc ce petit logiciel ?
- [16] Formsess, pour les formulaires et les templates
- [33] Skype pour Linux !
Liens connexes
- Le site officiel chez Novell (2052 hits)
- La page de téléchargement (876 hits)
- Points communs et différences avec la plateforme Java (1822 hits)
- Notes de version (574 hits)
- L'ancien site de Mono (591 hits)
Dépêche modérée par
Dépêche éditée par
Logiciel : Mono 1.0 : le singe est laché
Posté par TImaniac (Jabber id, page perso, ). Modéré le 02 juillet 2004.
Cette plateforme développée par Ximian se présente comme une alternative à la plateforme Java en proposant une implémentation libre de la plateforme .NET de Microsoft ainsi qu'un ensemble d'API destiné à la programmation objet sous GNU/Linux mais aussi Mac OS X et Windows. Les principaux objectifs et atouts de cette version sont :
- un environnement d'exécution comparable à celui de Java;
- le support de plusieurs langages de programmation dont C# et Java;
- un ensemble d'API orienté, Gnome et Mozilla;
- un serveur web pour la programmation dynamique de sites web;
- le support de plusieurs architectures matérielle : x86, SPARC et PPC;
- compatibilité avec Microsoft .NET 1.0 afin de faciliter la migration d'application Windows;
Très controversé, le projet Mono a été initié par Miguel de Icaza (un des fondateurs de Gnome) il y a maintenant 3 ans. Cette plateforme est déjà utilisée en production par Novell (qui a récemment racheté Ximian) et a entre autres permis à la ville de Munich de migrer 300 de ses serveurs sous GNU/Linux.
NdM : merci à Nicam, Romanito et D. Pierre pour avoir également soumis la news
![[en]](../../../images/en.png)
Le site officiel chez Novell (2052 hits)-
La page de téléchargement (876 hits)
![[fr]](../../../images/fr.png)
Points communs et différences avec la plateforme Java (1822 hits)-
Notes de version (574 hits)
-
L'ancien site de Mono (591 hits)
> Lire la suite (88 commentaires, moyenne: 3). [dépêche : 4760 caractères]
Mono est une plateforme de développement complète basée sur une implémentation de la machine virtuelle et des API de base définis à l'ECMA (également normes ISO).
Mono propose entre autre :
- des API indépendants de l'environnement : sécurité, base de données, web services, XML, web forms;
- des API destiné à la programmation sous Linux et plus particulièrement Gnome : GTK#, Glade# Gecko#, Gst#;
- des API compatibles avec le framework .NET de Microsoft avec en preview les Winforms (utilisation de WineLib);
- un IDE (environnement de développement) : Monodevelop, avec notamment le support de la complétion de code qui fait le bonheur des utilisateurs de Visual Studio et d'Eclipse;
- un outil pour naviguer dans la documentation : Monodoc, qui a l'originalité de pouvoir être modifier par le programmeur qui peut ensuite envoyer automatiquement les modifications au CVS de Mono;
- un compilateur pour le langage C# qui est souvent présenté comme une évolution du langage Java avec une pincée de C++. Sans être une révolution, ce langage apporte de réels plus qui le rendent très agréable et puissant. Mono propose également un compilateur Javascript et VB.NET;
- une pré-version de C# 2.0 avec notamment le support des generics;
- un serveur web léger entièrement compatible avec le serveur ASP.NET qui permet d'utiliser n'importe quel langage de la plateforme pour générer des sites web dynamiques. Un module apache est également disponible.
Comparaison avec la plateforme Java :
Souvent comparé à Java, cette plateforme en partage de nombreux aspects techniques comme l'utilisation d'un langage intermédiaire (IL pour Intermediate Langage, équivalent du bytecode Java), le support d'application Web, la portabilité (toute relative cependant pour les deux plateformes) et un ensemble impressionnant d'API fournis en standards.
Mono se démarque cependant de la solution de Sun :
- le langage IL a été conçu pour être compilé et non interprété mais aussi pour supporter plusieurs langages orientés objet (C#, Java mais aussi VB.NET, Nemerle et Javascript, etc.);
- la plateforme décrit également un système facilitant l'interopérabilité entre les langages : le programmeur développe dans le langage de son choix mais sa bibliothèque pourra être utilisé par tous les langages de la plateforme, de manière transparente, sans créer de bindings souvent lourd et coûteux à utiliser et maintenir;
- des fonctionnalités supplémentaires comme les méta-données, la détection de débordement ou encore le versionning et la simplicité d'utilisation d'API écrits en C;
- la plateforme Java est une solution propriétaire alors que Mono est une implémentation libre des normes de l'ECMA qui garantissent entre autres l'impossibilité de faire valoir des brevets logiciels (seuls les WinForms, spécifiques à Windows et non normalisés à l'ECMA, sont susceptibles de poser des problèmes légaux).
Note : la plateforme est conçu pour des langages compilés et orientés objets. L'implentation de Python IronPython a cependant démontré qu'il était tout à fait possible d'obtenir des performances similaires avec un langage historiquement interprété. Il faut également noter que la plateforme est facilement interfaçable avec d'autres langages compilés de manière traditionnel comme le langage C.
Perspectives
Présentant de nombreux atouts face à son principal concurrent Java, Mono a toutefois l'handicap de la jeunesse, la documentation n'est pas complète (cependant il est possible d'aller consulter la documentation impressionnante du site MSDN de Microsoft ou encore la documentation de GTK), les performances sont encore en retrait par rapport à l'implémentation de Microsoft : il n'y a pas de comparatifs entre Mono et Java sous Linux, mais est-ce un mal étant donné l'objectivité et l'exhaustivité de ceux-ci ? De plus l'IDE n'est pas terminé, la compatibilité avec la version de Microsoft n'est que partielle et n'est prévue que dans les prochaines versions.
De nombreux débats ont lieu sur une éventuelle intégration de Mono au projet Gnome : en effet la fondation Gnome cherche a fournir une nouvelle plateforme qui éviterait notamment le support de plusieurs bindings pour différents langages tout en proposant un langage de plus haut niveau que l'actuel C. Reste le problème "philosophique" de l'intégration d'une technologie initialement développée par Microsoft. Mais il n'y a pas de réelle solution alternative qui soit libre et qui respectent des standards (DotGNU étant un projet similaire, avec les même avantages et inconvénients). Cette intégration n'est cependant pas à l'ordre du jour et il est sans doute nécessaire d'attendre que la plateforme Mono atteigne une certaine maturité.
[+] mouais
est-ce que mono est plus un sujet à troll que les news java ?
1,2,3 partez !
...
Juste une question, est-ce que les Threads ont été améliorés ??
Parce que de Windows à Linux (et du SDK officiel à Mono), il y avait de sacrés différences (il était d'ailleurs pas très conseillé de porter des applis multithread vers Mono à l'époque du 0.28...).
Debian ... gentoo moi ça et vite :)
-
[^]Re: ...
Posté par TImaniac (Jabber id, page perso, ) le 02/07/2004 à 10:32. (lien). Évalué à 11.Me semble qu'ils ont complètement réécrit les thread..., je suis en train de porter une appli Windows -> Mono, y'a une seule utilisation de thread, mais tout à l'air de marcher pareil... c'est surtout sur Mac il me semble que l'implentation des thread posait le plus de problème.
-
[^]Re: ...
Posté par xsnipe () le 02/07/2004 à 10:35. (lien). Évalué à 2.Ok je vais tester ça ce soir...
Sinon pour Monodevelop, faut-il avoir obligatoirement un kernel qui tourne à la NPTL pour pouvoir ne serait-ce que l'installer ?? Ou une bidouille est possible ??--
Debian ... gentoo moi ça et vite :)-
[^]Re: ...
Posté par Brice Carpentier (Jabber id, page perso, ) le 02/07/2004 à 16:22. (lien). Évalué à 4.nan, aucun problème sans NPTL.
Je m'occupe personnellement du paquetage Monodevelop pour ArchLinux [1] et puisque nous sommes en phase de transition 2.4 --> 2.6 (et que nous utilisons un système de paquetages binaires) nous ne pouvons pas fournir de glibc NPTL.
Monodevelop compile sans problème, par contre mono-debugger n'est pas utilisable.
Pour plus de renseignements au tout simplement pour en discuter, tu peux utiliser mon mail @dlfp
[1] http://www.archlinux.org(...)
Just my 2¢--
Développeur OpenSource-
[^]Re: ...
Posté par -=[ Benoit Plessis ]=- (page perso, ) le 02/07/2004 à 17:51. (lien). Évalué à 2.Euh la debian a une glibc binaire fournissant le nptl si possible, donc c'est faisable..
--
Il [e2fsck] a bien démarré, mais il m'a rendu la main aussitot en me disant "houlala, c'est pas beau à voir votre truc, je préfèrerai que vous teniez vous même la tronçonneuse" (traduction libr
-
-
-
[^]Re: ...
Posté par Stéphane TRAUMAT (page perso, ) le 02/07/2004 à 10:35. (lien). Évalué à 4.Je suis interessé... est ce que ton appli est une appli "d'entreprise" ? quand est prévu la mise en production ?
-
[^]Re: ...
Posté par TImaniac (Jabber id, page perso, ) le 02/07/2004 à 10:42. (lien). Évalué à 5.Euh, non c'est pas vraiment une appli d'entreprise, c'est une appli qu'on a développer dans à l'université dans un cardre universitaire : en gros une solution de d'indexation de vidéo au format MPEG-7, avec système de plugins pour analyser une vidéo, créer des index mots clés, images clés, titre, séquences, etc. C'est très spécifique mais ca peut servir dans le domaine de l'indexation de contenus multimédias. Pour la mise en production, ben, ca dépend de moi et de ma motivation, vu que je fais ca sur mon temps personnel, mais j'ai des problème avec la lecture de vidéo sous Linux, c'est vraiment la m... à côté de DirectShow... Pourtant je veux pas faire de trucs compliquer, juste pouvoir lire une vidéo, en me déplacant image par image, à un instant donné... Pour l'instant je suis sur gstreamer, mais les déplacement sont vraiment imprécis... si y'en a qui s'y connaisse...
-
[^]Re: ...
Posté par Aldoo (Jabber id, ) le 02/07/2004 à 11:08. (lien). Évalué à 1.Oh, tu ne serais pas en maîtrise à Rennes, toi ? ;-)
Et justement le "chef" du projet en question ?-
[^]Re: ...
Posté par TImaniac (Jabber id, page perso, ) le 02/07/2004 à 11:12. (lien). Évalué à 1.Si si, on se connait ? :-)
-
[+] [^]Re: ...
Posté par xsnipe () le 02/07/2004 à 11:18. (lien). Évalué à -2.Au moins, vous ne serez pas obligés de vous retrouver sur le plateau de "Y a que la vérité qui compte"
"Vous ouvrez le rideau ??"
"Noooon, je n'aime que Javaaaa !!"
"???"
Ok je ---------------------->{}--
Debian ... gentoo moi ça et vite :)
-
-
-
-
-
Munich ?
Cette plateforme est déjà utilisée en production par Novell (qui a récemment racheté Ximian) et a entre autre permis à la ville de Munich de migrer 300 de ses serveurs sous GNU/Linux.
Je n'arrive pas à trouver d'où vietn cette info. On m'avait dit que mono n'etait en production pour le moment que chez Novell.
-
[^]Re: Munich ?
-
[^]Re: Munich ?
Posté par TImaniac (Jabber id, page perso, ) le 02/07/2004 à 10:51. (lien). Évalué à 7.ma source de la migration Munich : http://www.vnunet.fr/actu/article.htm?numero=12303&th=pme&d(...)
sinon pour l'utilisation, il y a une liste sur le site de novell des entreprises qui utilisent Mono et y contribuent :
http://www.mono-project.com/using/relnotes/1.0.html(...) (Current Users)
Munich
« Cette plateforme est déjà utilisée en production par Novell (qui a récemment racheté Ximian) et a entre autre permis à la ville de Munich de migrer 300 de ses serveurs sous GNU/Linux. »
De quelle manière ?
-
[^]Re: Munich
Posté par TImaniac (Jabber id, page perso, ) le 02/07/2004 à 10:52. (lien). Évalué à 3.utilisation de la compatibilité ASP.NET de Mono je suppose, je suis moi même curieux d'avoir plus de détails, mais je n'en ai pas d'autre que le lien que j'ai mis plus haut et le précédent article sur linuxfr à propos de la première béta.
Compilé ou pas ?
Mono se démarque cependant de la solution de Sun :
- le langage IL a été conçu pour être compilé et non interprété
Je comprend pas bien ... il y a un IL (Intermediate Language), qui est compilé ! Ben s'il est compilé et non interpreté, c'est du code natif, alors ! Si c'est natif pourquoi l'avoir appellé IL ?
Quelqu'un m'explique mon erreur, je comprend pas :(
-
[^]Re: Compilé ou pas ?
Posté par TImaniac (Jabber id, page perso, ) le 02/07/2004 à 10:55. (lien). Évalué à 6.Au moment de l'exécution, le code IL, portable et présent dans le binaire, est compilé en code natif à la volée (Just In Time, JIT) avant d'être exécuté. Le code IL a été conçu avec cet objectif et est donc optimisé pour cette opération. Les VM Java commence par interpréter le bytecode Java qui a été conçu pour. Puis elles compilent à la volée les parties les plus utilisées afin d'améliorer les performances.
-
[^]Re: Compilé ou pas ?
Posté par boubou (page perso, ) le 02/07/2004 à 11:49. (lien). Évalué à 14.C'est un FUD classique concernant IL. Le bytecode Java n'a pas été conçu spécifiquement pour être interprété mais plutôt pour proposer une sorte d'assembleur de haut niveau portable. D'ailleurs il n'est pratiquement pas interprété dans les machines virtuelles modernes où il presque systématiquement compilé au vol. La différence fondamentale entre IL et le bytecode de la JVM est que certaines instructions IL ne peuvent pas être interprétées efficacement. Par exemple, il n'y a pas une variante de l'instruction add pour chaque type fondamental (contrairement au bytecode de la JVM) ce qui fait que l'intepréteur devrait accéder à des informations globales à la méthode en cours d'exécution pour savoir quelle instruction native appeler. Au contraire, le bytecode de la JVM contient des variantes qui permettent une interprétation plus efficace que dans le cas de IL. Il est donc plus simple mais en déduire (comme le fait MS dans son marketing éhonté) que IL est optimisé pour le JIT est une vaste blague. En fait IL est d'encore plus haut niveau que le bytecode de la JVM et constitue en ce sens un vrai langage intermédiaire. C'est d'ailleurs un des éléments très positifs de .NET, mais bon, ce n'est pas une raison pour se faire l'écho du pipo de MS.
-
[^]Re: Compilé ou pas ?
Posté par TImaniac (Jabber id, page perso, ) le 02/07/2004 à 12:01. (lien). Évalué à 1.Euh à partir du moment où en Java tu es obligé de commencer en mode interprété, c'est que c'est pas terriblement optimisé pour être compilé ;) Sinon effectivement comme tu le fais remarquer c'est réciproque :
- Java a été conçu pour être inteprété et peut être compilé mais c'est parfait
- le code IL a été conçu pour être compilé (bah vi dès le départ on peut compiler le code IL contrairement au bytecode qui n'est pas conçu et donc optimisé pour) et peut être interprété mais c'est pas fait pour.-
[^]Re: Compilé ou pas ?
Posté par boubou (page perso, ) le 02/07/2004 à 12:17. (lien). Évalué à 9.Euh à partir du moment où en Java tu es obligé de commencer en mode interprété, c'est que c'est pas terriblement optimisé pour être compilé
C'est faux. GCJ compile du java en code NATIF ! Il est de plus parfaitement possible de faire du JIT sans jamais interpréter le code. Je n'ai par regardé les sources de Kaffe, mais il me semble que sur une des anciennes versions, on pouvait avoir un JIT systématique. J'ai l'impression d'ailleurs que tu confonds la vérification du bytecode, étape présente aussi en IL, qui consiste effectivement en une interprétation abstraite du code, et l'exécution proprement dite.
Java a été conçu pour être inteprété
Ce n'est pas en répétant une chose fausse qu'on la fait devenir vraie. Je ne dit pas que la possibilité d'interprétation ne faisait pas partie du cahier des charges du bytecode JVM (alors qu'effectivement il est clair que cette possibilité ne faisait pas partie de celui de IL), mais d'autres éléments ont dirigé la conception.
bah vi dès le départ on peut compiler le code IL contrairement au bytecode qui n'est pas conçu et donc optimisé pour
Vu que tu affirmes avec beaucoup de force ce genre d'argument, j'aimerais que tu détailles. Ne te fais pas soucis, j'ai lu la spec de la machine virtuelle Java et la spec de LI, donc je connais un peu. Oui, IL a été conçu pour ne pas être interprété, donc quand on l'inteprete, ça rame. Maintenant donne moi un seul exemple, du même genre que celui que je donne plus haut, qui montre que le code obtenu après JIT est moins performant pour le bytecode de la JVM que pour le LI. Ou un exmple où le JIT du bytecode prendra significativement plus de temps que le JIT du LI...-
[^]Re: Compilé ou pas ?
Posté par hex () le 02/07/2004 à 13:16. (lien). Évalué à 1.IL quand on l'interprete, ça rame
Intéressant. Est-ce pour cette raison que .Net passe pour un très gros consommateur de resources CPU par rapport à Java ?-
[^]Re: Compilé ou pas ?
Posté par boubou (page perso, ) le 02/07/2004 à 13:25. (lien). Évalué à 4.A priori non, car aucune machine virtuelle CLI n'interprète. Je pense que c'est plutôt du à la relative jeunesse du produit. Il ne faut pas oublier que les JVM sont vieilles et qu'elles s'améliorent pourtant régulièrement.
-
-
-
-
-
-
[^]Re: Compilé ou pas ?
article concernant Mono sur Wikipedia : à compléter
Et au niveau du FUD, il va comment, Mono ?
C'est pas pour être lourd, mais moi, cette news me fait plutôt l'effet d'un commiqué de presse conjoint Ximian/Microsoft attaquant en règle Java. Je cite :
Comparaison avec la plateforme Java :
Souvent comparé à Java, cette plateforme en partage de nombreux aspects techniques comme l'utilisation d'un langage intermédiaire (IL pour Intermediate Langage, équivalent du bytecode Java),
Jusqu'ici, tout va bien.
le support d'application Web, la portabilité (toute relative cependant pour les deux plateformes)
Là, ça dérape déja bien. Si .Net est supportée pour Linux, Windows et Mac, grâce à Mono, la liste des plateformes supportant Java (que ce soit en Open-source ou non), est quand même un peu plus longue, incluant par exemple des téléphones portables, des PDAs, des routeurs, des automates programmables, des robots mobiles, des cartes bleues, etc, ...
Mono se démarque cependant de la solution de Sun :
- le langage IL a été conçu pour être compilé et non interprété
On sent que c'est un avantage énorme, effectivement, surtout quand la plupart des JVMs supportent le JIT compiling, qui revient à disposer d'un code ... compilé.
mais aussi pour supporter plusieurs langages orientés objet (C#, Java mais aussi VB.NET, Nemerle et Javascript, etc.);
Le site http://www.robert-tolksdorf.de/vmlanguages.html(...) donne effectivement une liste fabuleusement courte de langages pouvant être compilés en bytecode, sans passer par le langage Java. Et, chose étonnante, tous ne sont pas orientés objet (je citerai par exemple Lisp, Logo, Prolog, Eiffel, Smalltalk, Ada, mais pas Cobol, malheureusement)
- la plateforme décrit également un système facilitant l'interopérabilité entre les langages : le programmeur développe dans le langage de son choix mais sa bibliothèque pourra être utilisé par tous les langages de la plateforme, de manière transparente, sans créer de bindings souvent lourd et coûteux à utiliser et maintenir;
Là, je m'avance, mais dans la mesure où tous ces langages sont compilés en bytecode, il doit être possible de faire facilement des binbdings de l'un à l'autre. je sais que c'est au moins possible pour JScheme, implémentation java d'un interpréteur Scheme permettant d'aller de l'un à l'autre et réciproquement.
- des fonctionnalités supplémentaires comme les méta-données,la détection de débordement
Ben .. ça existe depuis un bon moment en Java, à moins qu'on ne parle pas de la même chose. Quant aux metadonnées, elle sont présentes dans Java 1.5 (ou Java 5) qui sort ces temps-ci.
ou encore le versionning et la simplicité d'utilisation d'API écrits en C;
Tu peux être plus explicite sur la simplicité d'utilisation du C ? Ca me laisse pantois !
- la plateforme Java est une solution propriétaire
Non. le langage Java est libre, et son évolution est pilotée par le java Community Process, qui va parfois à l'encontre des souhaits de Sun. En revanche, effectivement, la machine virtuelle de Sun n'est pas libre, mais il existe un certain nombre de JVM libres, qui sont cependant en retard sur celle de Sun.
alors que Mono est une implémentation libre des normes de l'ECMA qui garantissent entre autres l'impossibilité de faire valoir des brevets logiciels (seul les WinForms, spécifiques à Windows et non normalisés à l'ECMA, sont susceptibles de poser des problèmes légaux)
Ca fait peut-être un peu Don Quichotte, mais pour moi cet article est symptômatique : sous couvert de défense du libre, on assiste là) à une attaque en règle contre Java, au profit de quoi , D'une plateforme dont le développement est piloté par Microsoft ? Super.
-
[^]Re: Et au niveau du FUD, il va comment, Mono ?
Posté par TImaniac (Jabber id, page perso, ) le 02/07/2004 à 11:57. (lien). Évalué à 5.Bon, je vais donc reprendre point par point, mais je ne vais pas te cacher que je préfère Mono à Java, et je ne m'en cache pas vraiment.
la portabilité (toute relative cependant pour les deux plateformes)
Je sais très bien que la technologie Java est présente sur de nombreuses plateformes non supportées par Mono (pour le moment) mais bon. Ce que j'ai voulu dire c'est que de toute façon la portabilité est toute relative, et une application qui tourne sur un PC ne tournera pas forcement sur un PDA, même si c'est sur une JVM de Sun dans tous les cas. Pourquoi ? PArcque les API ne sont pas tous portés, que des API ne sont disponibles que sur certaines plateformes, etc. bref, il faut se limiter aux implentations de bases pour être 100% portable. d'où le terme "relative". (je rajouterai que la portabilité se fait en général au détriment de l'intégration dans l'environnement, autant graphiquement qu'ergonomiquement)
On sent que c'est un avantage énorme, effectivement, surtout quand la plupart des JVMs supportent le JIT compiling, qui revient à disposer d'un code ... compilé.
non non, jes JVM essai de faire du JIT, mais sont toujours obligé de faire de l'interprété pour commencer. D'ailleur le démarrage d'une appli Java donne une idée du travail que doit effectuer la VM derrière ;) Et celà ne change rien à ce que j'ai dit, le code IL est optimisé pour cette opération, qui est donc faite plus rapidement et sans passer par un système de profiling et d'interprétation.
Pour les implentation d'autres langages sur la plateforme Java, je suis tout à fait d'accord que celà est possible. Mais là encore, le bytecode n'a pas été conçu pour, et il existe de nombreuses limitations (le code IL de .NET et Mono en a également je te rassure) et surtout ne définit aucun standard d'implentation qui facile l'interopérabilité entre les langages (tu peux écrire une classe en ADA, l'instancier en Logo et la modifier en Perl sur une machine virtuelle Java ?). C'est ce qui fait toute la force de cette plateforme, on utilise une librairie et on se moque complètement du langage dans lequel il a été développé, sans faire aucun binding. (les bindings ne sont utiles que pour utiliser du code natif).
Ben .. ça existe depuis un bon moment en Java, [détection de déblordement]
ah bon tu peux faire ca en Java ? : http://www.dotnetguru.org/articles/CSharpVsJava.htm#_D%E9tection_de(...)
Pour les métas-données, effectivement elles existent désormais dans Java 5, d'ailleur cette version de Java n'est là que pour rattraper le retard sur C# quand on voit les nouvelles fonctionnalités et pour proposer une implentation bancale des generics. (je ne rentrerais pas dans le débat, c'est très bien expliqué ici : http://www.artima.com/intv/generics.html(...))
Tu peux être plus explicite sur la simplicité d'utilisation du C ? Ca me laisse pantois !
J'ai peut être mal formulé ma phrase, je voulais dire la simplicité d'utiliser un API écrit en C depuis la plateforme Mono, notamment en C#.
Tu considère l'ECMA comme étant dirigé par Microsoft (d'ailleur l'ECMA va parfois à l'encontre de Microsoft, un peu comme le java Community Process). Mais si j'en crois toutes les demandes faites à Sun pour libérer Java, j'en déduit qu'il n'est pas si libre que ça ;)
Et OUI, j'ai attaqué Java, parcque dans le domaine Java a plus ou moins le monopole (question plateforme complète) et Mono se présente comme une alternative libre qui respecte des standards, et qui apporte quelques innovations qui ont l'avantage de faire bouger les 2 parties, vive la concurrence et longue vie aux 2 plateformes.-
[^]Re: Et au niveau du FUD, il va comment, Mono ?
Posté par Nelis (page perso, ) le 02/07/2004 à 12:29. (lien). Évalué à 6.C'est ce que je reproche à ta news: une évidente partialité mêlée d'un brin de mauvaise foi à l'encontre de Java.
C'est dommage car à part la partie comparaison avec Java la news est intéressante.
Je ne dis pas que toutes les news doivent être 100% objectives mais lorsqu'on rédige une news, je pense qu'il faut essayer de le rester un maximum ... C'est comme si on faisait une news sur Mandrake en terminant avec une comparaison biaisée avec Redhat. A part si on veut que ça parte en troll, je ne vois pas l'intérêt.
Je suis un 100% convaincu par Java, mais ça ne m'empêche pas de me tenir informer des news .NET et à l'occasion de l'essayer. Technologiquement cette plateforme à l'air très bien, moi c'est plutôt MS qui me fait peur la dedans. Bref, tout ça pour dire que ce n'est pas parce qu'on aime l'une des plateforme qu'on doit se sentir obligé de descendre l'autre ...-
[^]Re: Et au niveau du FUD, il va comment, Mono ?
Posté par TImaniac (Jabber id, page perso, ) le 02/07/2004 à 14:03. (lien). Évalué à 3.J'espère au moins avoir été le plus partiale possible dans la première partie de la news, la partie qui s'affiche.
Pour la comparaison avec Java, j'ai surtout voulu montrer que c'était pareil, mais avec des petits plus qui justifiait l'existance de Mono. J'aurai dis : c'est pareil on peut faire la même chose, celà n'aurait montré aucun intérêt pour cette plateforme.-
[^]Re: Et au niveau du FUD, il va comment, Mono ?
Posté par Snark_Boojum () le 02/07/2004 à 16:36. (lien). Évalué à 1.Hum... Soit c'est "la plus partiale possible", soit "le plus partial possible", faut choisir son sexe!
Ensuite, je suis surpris que quelqu'un se vante d'avoir été partial. C'était pas "impartial" qui aurait dû être écrit?
Snark-
[^]Re: Et au niveau du FUD, il va comment, Mono ?
Posté par TImaniac (Jabber id, page perso, ) le 02/07/2004 à 16:40. (lien). Évalué à 2.Oué c'est vrai, c'est impartial que j'aurai du écrire, en espérant m'être fait comprendre :)
-
-
-
-
[^]Re: Et au niveau du FUD, il va comment, Mono ?
Posté par boubou (page perso, ) le 02/07/2004 à 13:02. (lien). Évalué à 15.Quoi que tu en dises, cette news est quand même un modèle de mauvaise foi et de marketing baveux. Avant d'entrer dans les détails, je précise toute de suite que j'ai une bonne expérience de Java (que j'ai enseigné 6 ans) et que bien que n'ayant qu'une connaissance livresque de C# et de .NET, je trouve ces produits très intéressants et très supérieurs à Java sur certains points. De même, je trouve le projet Mono très intéressant et assez impressionnant.
Mais venons en à la news. D'abord, la comparaison avec Java est assez biaisée.
Je passe sur le FUD concernant IL auquel j'ai déjà repondu plus haut. Il est vrai par contre que certains éléments de CLI permettent d'implémenter plus efficacement certains langages que sur la JVM. Je pense en particulier au passage par référence qui n'existe pas dans la JVM. Cependant, de très nombreux langages tournent sur la JVM, donc ce n'est pas un si gros problème que ça. D'ailleurs, un JSR s'intéresse à ce problème et envisage de fournir plus de facilités pour l'implémentation d'autres langages sur la JVM.
Le passage sur les bindings est foireux. Oui, la notion de classe étant au centre de CLI, on peut appeler des classes C# en VB. Aucun problème pour faire l'équivalent en Java, cf Jython par exemple. D'autre part, il existe des outils qui construisent automatiquement les bindings JNI (un peu lourd il est vrai), cf en particulier la réalisation du binding opengl en Java (https://jogl.dev.java.net(...)).
Le versioning existe depuis longtemps en Java. Soit, il est moins évolué qu'en .NET, mais il existe. De même que les métadonnées en 1.5. Oui JNI est relativement lourd, mais cf au dessus.
Mais bien sûr, le plus scandaleux arrive ensuite, je cite :
"la plateforme Java est une solution propriétaire alors que Mono est une implémentation libre des normes de l'ECMA qui garantissent entre autres l'impossibilité de faire valoir des brevets logiciels (seuls les WinForms, spécifiques à Windows et non normalisés à l'ECMA, sont susceptibles de poser des problèmes légaux)."
Ba voyons.
Premièrement, ne sont normalisés par l'ECMA que la CLI, C# et sa bibliothèque système. On est loin des seuls WinForms. On doit par exemple ajouter ADO.NET et ASP.NET (cf http://www.mono-project.com/about/licensing.html(...)).
D'autre part dire que des normes l'ECMA qui garantissent entre autres l'impossibilité de faire valoir des brevets logiciels est un pur mensonge. Comme l'indique un des inventeurs de .NET qui est aussi un des auteurs des brevets associés (cf http://web.archive.org/web/20030609164123/http://mailserver.di.unip(...)), l'ECMA demande seulement des licences RAND, c'est-à-dire à un coût raisonnable et de type non discriminatoire. La notion même de coût raisonnable est incompatible avec l'open source et on ne parle pas ici des parties WinForms, ADO.NET et ASP.NET, mais bien de C# et de la CLI ! Microsoft s'est engagé à fournir des licences "royalty-free and otherwise RAND", ce qui ne veut pas dire grand chose. D'ailleurs, Novell n'a pas d'autorisation officielle de MS, à ma connaissance.
Je fais remarquer au passage que la plupart des organismes de normalisation demandent du RAND. Or, quand on voit qu'il faut officiellement payer pour pouvoir faire un player mp3 (qui est un standard internationnal), on peut avoir peur pour Mono.
Bref, .NET est donc au moins aussi propriétaire que Java qui est lui-même couvert par des brevets de Sun. Cependant, la communauté des détracteurs systématiques de Java semble oublier que Sun n'est pas le méchant dans cette histoire. Je tiens à rappeler que Sun a fait beaucoup pour le libre et pour les standards. Par exemple, RPC et NFS sont deux inventions de Sun. OpenOffice.org a été rendu possible par Sun qui contribue aussi au projet Gnome. Certains composants de la plate-forme Java sont officiellement open source et soutenus pas Sun. C'est le cas par exemple de Tomcat (implémentation de référence des JSP et des servlets), de l'api XML, ainsi que de ant (un projet de Sun à l'origine). Et qu'on ne vienne pas m'emmerder en me distant qu'il faut une JVM propriétaire pour les faire tourner, c'est faux, Tomcat et ant font justement partie des logiciels Java qui existent en version native grâce à GCJ et Classpath. Enfin, le JCP est un processus semi-ouvert (en tout cas beaucoup plus que ECMA) qui a voté une résolution permettant l'implémentation officielle des composants de la plate-forme Java en open source, avec même des aides financières de Sun pour passer les tests de compatibilité (cf Jonas qui est officiellement reconnu par Sun comme un projet qui vise à obtenir la certification J2EE 1.4).
Tout ça pour dire qu'avec l'histoire de Microsoft, je suis beaucoup plus soucieux pour l'avenir de Mono que pour celui des JVM open sources.-
[^]Re: Et au niveau du FUD, il va comment, Mono ?
Posté par TImaniac (Jabber id, page perso, ) le 02/07/2004 à 13:59. (lien). Évalué à 5.Que cette news soit partiale et comportant quelques "attaques" contre Java, ok, je ne m'en cache nullement. Après je ne penses pas avoir usé de mauvaise foi et de marketing baveux (je n'ai aucune action chez Microsoft, ni aucun pot de vin), je suis juste un programmeur convaincu, ce qui est sans doute le problème, mais quand on veut décrire précisement quelque chose, il faut se sentir légèrement concerné.
reprenons la news.
Pour le code IL, tu as parfaitement argumenté plus haut. D'ailleur dans la news tu remarqueras que je n'ai donné aucun jugement, j'ai juste noté la différence d'objectifs lors de la conception des code intermédiaires. Enfin dans tous les cas, je penses honnêtement que celà est un point positif d'avoir un langage non orienté interprétation et conçu pour être multi-langages. J'ai d'ailleur bien précisé la limitation aux langages objets.
Pour les bindings, tu le dis toi même : c'est lourd. De toute façon sur les 2 plateformes c'est pareil : c'est utilisé pour wrapper du code binaire quelconque. C'est surtout un avantage pour fournir un API qui soit utilisable sans soucis par pleins de langages sans faire de bindings justement, comme le fait par exemple actuellement le projet Gnome qui doit maintenir plusieurs bindings. Et de ce point de vu là, la VM de l'ECMA est conçu pour et impose des règles d'inplentation, et c'est ce qui fait sa force. Je suis heureux de voir qu'il existe une initiative de ce genre du côté de Java, mais je n'en avais pas connaissance et ce n'est pas encore du concrêt dans les JVM actuelles. D'ailleur l'objectif de Sun est clairement de favoriser le langage Java comme langage universel.
Pour le versionning, on est bien d'accord que celui de Java est sans comparaison avec celui de .NET ou Mono.
Pour le problème de licence, etc. c'est possible que je n'ai pas du tout été partial. A vrai dire j'en ai tellement marre d'entendre dire que "Mono c'est mal parcque c'est une techno proprio et Java c'est bien c'est libre" que du coup j'ai peut être eu tendance à aller à l'opposé.
Pour les WinForms, j'ai précisé que c'était elles seules qui posaient des problèmes légaux actuellement. J'ai pas dit que c'était les seuls à ne pas être normalisé. C'est vrai que celà pouvait porter à confusion mais ce n'est pas volontaire, tu m'en vois désolé.
Pour les précisions de licence, je vais dans ton sens, tes propos étant exact.
Microsoft s'est engagé à fournir des licences "royalty-free and otherwise RAND", ce qui ne veut pas dire grand chose. D'ailleurs, Novell n'a pas d'autorisation officielle de MS, à ma connaissance.
Le fait que Microsoft se soit engager à ne pas fournir de licence discriminatoire indique clairement qu'il doit accepter que Novell puisse en acquérir s'il le souhaite (en respectant la licence évidemment), et c'est déjà ca. Ensuite, en dehors de ce débat, il y a les licences en soit, et d'après Icaza, ils n'ont rien trouvé dans ces licences qui puisse les géner.
Reste que je trouve l'ECMA plus ouvert que le consortium autour de Java, ou Sun aura toujours plus ou moins le dernier mot sur les principales direction de Java (c'est d'ailleur ce que Sun ne veut pas lacher, aillant peur de voir Java se faire forker).
Or, quand on voit qu'il faut officiellement payer pour pouvoir faire un player mp3 (qui est un standard internationnal), on peut avoir peur pour Mono.
Parcque c'est des normes ISO et parcque les licences mp3 sont explicitement payante, pas celles de C# & Co.
Enfin, tout celà pour dire que j'ai avant tout voulu présenter l'innovaiton technique de cette plateforme, et surtout le fait qu'elle soit une alternative face à Java. J'espère ne pas avoir dit trop de conneries, et j'ai voulu relativiser à la fin de la news. La partialité m'aurait peut être poussé à ne pas parler de Java du tout, mais il était pour vital d'avoir un point de comparaison pour se faire une idée de ce qu'est Mono, Java étant pour moi globalement équivalent dans les possibilités.-
[^]Re: Et au niveau du FUD, il va comment, Mono ?
Posté par imr () le 02/07/2004 à 14:15. (lien). Évalué à 3.et a entre autres permis à la ville de Munich de migrer 300 de ses serveurs sous GNU/Linux.
Tu peux préciser ce point? Je n'ai pas trouvé dans les liens que tu donnes et j'aimerais en savoir plus.-
[^]Re: Et au niveau du FUD, il va comment, Mono ?
Posté par TImaniac (Jabber id, page perso, ) le 02/07/2004 à 14:18. (lien). Évalué à 3.ben, c'est le lien que j'ai indiqué plus haut : http://www.vnunet.fr/actu/article.htm?numero=12303&th=pme&d(...)
je cite l'article :
Dans le cadre de sa migration vers Linux, la municipalité de Munich (voir édition du 10 juin 2003) a ainsi exploité Mono pour migrer 300 serveurs utilisant ASP.Net.
Si certains ont d'autres sources je suis également intéressé.-
[^]Re: Et au niveau du FUD, il va comment, Mono ?
Posté par imr () le 03/07/2004 à 11:49. (lien). Évalué à 2.pour migrer 300 serveurs utilisant ASP.Net
C'est effectivement interressant.
Un serveur qui fournit du ASP.Net, c'est si différent d'un ASP normal qu'il faille mono pour le migrer?-
[^]Re: Et au niveau du FUD, il va comment, Mono ?
Posté par TImaniac (Jabber id, page perso, ) le 03/07/2004 à 11:54. (lien). Évalué à 2.ASP.NET c'est une grosse évolution de ASP, le principe est le même, en gros fournir du contenu dynamique, un peu comme PHP. Mais en ASP.NET tu utilises le langage qui te plait pour faire la programmation dynamique, c'est à dire C#, VB.NET, Java, etc. En fait ASP.NET utilise le framework.NET et toute la partie programmation du site peut ainsi être compilé, comme n'importe quel autre programme. D'où la nécessité de Mono qui est une implentation du framework.NET .
-
[^]Re: Et au niveau du FUD, il va comment, Mono ?
Posté par gnap gnap (page perso, ) le 03/07/2004 à 17:15. (lien). Évalué à 1.Concretement, ça ne m'apparait pas comme une réussite intégrale : ça nous indique surtout que Munich s'est mis à l'ASP.net, une technologie récente qui sur un plan logiciel libre/pas libre est loin d'être une situation sans équivoque.
Est-ce une bonne chose de voir des migrations vers ASP.net ?-
[^]Re: Et au niveau du FUD, il va comment, Mono ?
Posté par Black Fox (page perso, ) le 03/07/2004 à 18:04. (lien). Évalué à 2.La migration n'était pas vers ASP.Net.
Ils avait du ASP.Net et voulait le garder tout en passant à Linux, pour cela ils se sont servis de Mono.
-
-
-
-
-
-
[^]Re: Et au niveau du FUD, il va comment, Mono ?
Posté par 007 () le 02/07/2004 à 14:56. (lien). Évalué à 1.Merci pour ces précisions/corrections.
> C'est surtout un avantage pour fournir un API qui soit utilisable sans soucis par pleins de langages sans faire de bindings justement
C'est peut-être une question bête mais là je ne comprends pas.
Prenons python.
Pour utiliser python avec Gnome, il me faut un binding vers C.
Pour utiliser python avec Gnome qui s'appuie sur C#, il me faut aussi un binding vers C# (la machine virtuelle).
C'est quoi la différence.-
[^]Re: Et au niveau du FUD, il va comment, Mono ?
Posté par TImaniac (Jabber id, page perso, ) le 02/07/2004 à 15:18. (lien). Évalué à 3.la différence ?
Ben, en l'état actuel, si tu utilises le python de base, il n'y en a pas. Maintenant si tu utilises un compilateur python (ou un interpréteur) qui a pour cible le code IL, tu peux utiliser tous les API de Mono, sans faire aucun bindings. Si tu fais un API que tu écris en Python qui cible le IL, ton API pourra être utilisé dans tous les autres langages qui cible le code IL, sans faire de bindings.
Après si tu veux utiliser un API écrit en code natif, par exemple en C depuis Mono (dans le langage que tu veux), tu fais un seul binding pour Mono (comme c'est le cas pour GTK ou Gecko par exemple), et le binding sera valable pour tous les langages. Bref, tu fais un seul binding pour Mono si ton code est natif (parcque tu veux le faire en C, que c'est vraiment du bas niveau système, etc.) sinon il n'y a pas besoin de bindings, pour les langages qui ciblent le code IL.-
[^]Re: Et au niveau du FUD, il va comment, Mono ?
Posté par 007 () le 02/07/2004 à 15:46. (lien). Évalué à 1.Finalement je me rend compte que ma question était assez bête...
Chaque librairie en IL (faite à partir de n'importe quel langage) peut-être utilisé par tous les autres langages. S'il n'y a qu'un langage c'est sans intérêt (d'où mon raisonnement limite stupide en ne pensant qu'à python).
Sur le papier c'est très interessant mais dans la réalité...
Par exemple l'API C de gnome en IL n'est pas d'un grand intérêt pour celui qui veut faire du C# ou du C++. Pour C++, mieux vaut utiliser gnomemm (surtout que C++ peut "attaquer" directement API C de gnome).-
[^]Re: Et au niveau du FUD, il va comment, Mono ?
Posté par TImaniac (Jabber id, page perso, ) le 02/07/2004 à 15:51. (lien). Évalué à 2.oué enfin attaquer directement les API C de Gnome, c'est pas ce qu'il y a de plus agréable quand même... tu te balade toujours des pointeurs, tu utilises des noms de méthodes à rallonge... Question de confort tu me diras :)
-
[^]Re: Et au niveau du FUD, il va comment, Mono ?
Posté par 007 () le 02/07/2004 à 16:03. (lien). Évalué à 1.Le C c'est comme le vélo...
Je fais du C et du C++ et chaqu'un à ces avantages. Le tout objet est parfois lourdingue à faire.
Le propos n'était de dire que l'API C de Gnome était géniale mais simplement que l'API C en IL, reste l'API C et ne permet pas de tirer avantage du C# ou du C++.
Donc pour Gnome il faut aussi faire un api orienté objet pour que l'utilisation d'IL soit intéressant pour les développeurs C++ ou C# ou python, etc...-
[^]Re: Et au niveau du FUD, il va comment, Mono ?
Posté par TImaniac (Jabber id, page perso, ) le 02/07/2004 à 16:09. (lien). Évalué à 2.C'est tout le paradoxe de Gnome, c'est codé en C, mais de manière orienté objet. D'ailleur les binds vers Mono sont fait de manière automatique grâce à ca.
-
[^]Re: Et au niveau du FUD, il va comment, Mono ?
Posté par 007 () le 02/07/2004 à 16:25. (lien). Évalué à 0.> c'est codé en C, mais de manière orienté objet.
L'API est orienté objet. Mais ça reste codé en procédurale. Je pinaille...
> D'ailleur les binds vers Mono sont fait de manière automatique grâce à ca.
Là j'ai peut-être raté un truc. En fait (au moins pour Gnome/gtk+ qui est aussi orienté objet) lorsque le "binding" pour IL est fait, il est fait en essayant d'exploiter au maximum IL. Donc normalement ce n'est pas l'API C qui est porté de façon "bête" (des fonctions, des structures, des constantes, etc), mais plutôt l'orientation objet de l'API (quelque chose de moins "bas niveau" que l'API C et qui exploite mieux les capacités de l'IL). Ça fait plus de boulot mais il n'est fait qu'une fois.
Heureument que Gnome est déjà orienté objet...-
[^]Re: Et au niveau du FUD, il va comment, Mono ?
Posté par TImaniac (Jabber id, page perso, ) le 02/07/2004 à 16:30. (lien). Évalué à 2.oué c'est ca, c'est l'orientation objet de l'API qui est porté. Et celà de manière automatique. Evidemment, faut faire quelques retouches manuelles parcque c'est pas parfait, mais celà évite déjà une bonne partie du boulot :)
et comme tu dis, heuresmeent que GNome est orienté objet :)
-
-
-
-
-
-
-
-
[^]Quel avenir pour mono ?
Posté par Hive Arc (page perso, ) le 02/07/2004 à 15:21. (lien). Évalué à 7.Franchement, l'avenir de mono est loint d'être assuré.
AMHA, croire que MS va laisser copier leur plateforme de référence sans broncher est faire preuve de crédulité vu les sommes investies en R&D et marketing par MS sur la marque.
Tant que mono sert à MS pour faire avaler la pilule du "multi-plateforme" concernant .net, il n'y a aucun problème. En ça, je serais interessé par connaitre les motivation exactent de DeIcaza, vu ses relations troubles avec MS.
Concernant le "pseudo" standard ECMA, franchement MS est de mauvaise fois, car non seulement elle n'a soumis qu'une partie de la spec de .net, mais ensuite, il faut rappeler lorsque Java avait été poussé à l'ECMA les arguments qui lui avait valu d'être rejeté ... ici on se rend compte des pressions qui ont du se produire en coulisse dans les deux cas. Je ne reviendrait pas non plus sur la soumission de Java à l'ISO, qui était plus du domaine de la série Dallas ;-) Ce sont ces lobying répétés de MS qui ont obligé Sun a créé un procéssus de standardisation des specs Java décorrélé de toute influence de MS.
De plus, pour rappel, MS était il y a qqe années à fond impliqué dans Java, Visual J++ étant l'IDE n°1 et JView la VM la plus performante de plus l'ensemble des API de windows était disponible via des API Java !!! Bien sur, ensuite est arrivé la "crise" lorsque MS a essayé d'introduire une spécificité à Java pour le rendre interdépendant avec windows.
Concernant .net, toute personne qui connait les deux mondes sait bien qu'il n'y a que peu de différence. Et que basculer de l'un à l'autre est une question de jour.
Je préciserait simplement que ton point sur la généricité est ridicule, regarde les débats et JSR dans les forums Java et regarde quand MS a commancé à en parlé ... et ensuite reviens discuter serieusement (vraiment ce point prouve particulierement que tu ne fais que répeter les publi-annonces de MS).
La seule question pertinente pour moi est la pérénité des deux solutions.
Soyons honnete, personne de sensé dans le monde de l'entreprise ne fera de mono, car il y aura toujours un point valable pourdire que .net est mieux ... entre un obscur groupe, et Microsoft, croit-tu que les DSI et autres décideurs vont selectioné ? En conséquence tout ce que va faire mono, c'est apporté de l'eau au moulin de MS et jouer contre le camp du libre. Car soyons encore honnete, la notion de opensource dans l'entreprise est souvent synonime de "gratuit" et pas vraiment de liberté.
Si vraiment tu es un apotre du libre, je te conseille vivement de rejoindre la FSF et de consacrer ton temps au projet Classpath dont le but est de passer le TCK Java et fournir une implementation intégrale de la spec J2SE. Et là au moins pas de risque de voir un quelconque éditeur balayer ton ouvrage d'un simple revers de la main (non, même pas Sun, pour t'en convaincre, je te propose de relire les licences appliqués à J2SE 5.0 par exemple, ainsi que la position claire et définitive sur les brevest potentiels autours de Java).
Oui, vraiment je pense que l'avenir de mono est assez sombre. Quand à celui de .net il est assuré ... enfin, du moins pour le nom, quand au framework, les API de longhorn sont sur le point de le mettre en pièce ....adieu veaux, vaches et winforms ;-)-
[^]Re: Quel avenir pour mono ?
Posté par TImaniac (Jabber id, page perso, ) le 02/07/2004 à 15:50. (lien). Évalué à 2.Erf, je comprend bien ton point de vue. Mono n'a aucun avenir en entreprise. Mais Mono ne sert pas qu'à celà, loin de là. Ensuite si Mono ou MainSoft a choisi d'utiliser cette techno, c'est qu'elle y a trouvé un intérêt. Un autre intérêt est de permettre d'effectuer plus facilement des migrations, et me dit pas que c'est inutile.
Pour les ClassPath, elles sont accessibles depuis Mono, ce n'est donc pas du tout incompatible.
Pour ce qui est de l'avenir de Mono, seul l'avenir nous dira ce qu'il en est.
PS : pour la genericité, penses aux scénarios qui font appel à la reflexion du code à l'exécution, juste pour le fun... Ou tiens fait une classe generique qui accepte des types primitifs sans sacrifier les perfs (sachant que ca va wrapper directement la class correspondante)-
[^]Re: Quel avenir pour mono ?
Posté par gnap gnap (page perso, ) le 03/07/2004 à 17:25. (lien). Évalué à 1.« Un autre intérêt est de permettre d'effectuer plus facilement des migrations, et me dit pas que c'est inutile. »
Des migrations vers de l'ASP(.net) ? Je m'interroge sur les détails de la migration.
Par ailleurs, sur le sens stratégique de Mono, le fait que le choix fut fait ne prouve rien. De Icaza à aussi choisit de confier le développement du gestionnaire fichier GNOME à Eazel et de créer une boite pour diffuser GNOME : au bilan, ces choix stratégiques furent vites balayés, remplacés par d'autres objectifs. Pour avoir preté un peu d'attention aux décisions de ce type, ses déclarations foudroyantes et contradictoires, sans parler des ses retournements de vestes (faut être fort pour reprocher à KDE la dépendance à Qt sous QPL et faire 2 ans après du code proprio - la QPL c'est de la rigolade par comparaison), je ne vois pas quelles preuves de fiabilité sont sur la table.
Peut-être que Mono apportera beaucoup au libre. J'espère pour Mono que ce n'est pas uniquement un tremplin pour certaines personnes. Mais pour le moment, j'observe, curieux.-
[^]Re: Quel avenir pour mono ?
Posté par Pinaraf (Jabber id, ) le 03/07/2004 à 17:29. (lien). Évalué à 1.Moi je vois en mono une opportunité d'avoir un peu plus de développeurs : tous ceux qui parlent le C#, VB.Net et compagnie pourront viendre sous linux sans apprendre un autre langage... juste remplacer windows.forms par gtk#...
-
-
-
[^]Re: Quel avenir pour mono ?
Posté par ftp (page perso, ) le 02/07/2004 à 16:08. (lien). Évalué à 4.Soyons honnete, personne de sensé dans le monde de l'entreprise ne fera de mono, car il y aura toujours un point valable pourdire que .net est mieux ... entre un obscur groupe, et Microsoft, croit-tu que les DSI et autres décideurs vont selectioné ? En conséquence tout ce que va faire mono, c'est apporté de l'eau au moulin de MS et jouer contre le camp du libre. Car soyons encore honnete, la notion de opensource dans l'entreprise est souvent synonime de "gratuit" et pas vraiment de liberté.
En changeant quelques mots, ça marche aussi
Soyons honnete, personne de sensé dans le monde de l'entreprise ne fera de gcj, car il y aura toujours un point valable pourdire que la jvm de sun est mieux ... entre un obscur groupe, et Sun, croit-tu que les DSI et autres décideurs vont selectioné ? En conséquence tout ce que va faire gcj, c'est apporté de l'eau au moulin de sun et jouer contre le camp du libre. Car soyons encore honnete, la notion de opensource dans l'entreprise est souvent synonime de "gratuit" et pas vraiment de liberté.
Donc javasapusaipalibre, puisque gcj ne compte pas il joue contre le libre...
s/é/er/ sur les trois quarts du texte aussi ;)
-
[^]Re: Quel avenir pour mono ?
-
-
-
-
[^]Re: Et au niveau du FUD, il va comment, Mono ?
Posté par Nicolas Delsaux (page perso, ) le 05/07/2004 à 11:40. (lien). Évalué à 3.
Je sais très bien que la technologie Java est présente sur de nombreuses plateformes non supportées par Mono (pour le moment) mais bon. Ce que j'ai voulu dire c'est que de toute façon la portabilité est toute relative, et une application qui tourne sur un PC ne tournera pas forcement sur un PDA, même si c'est sur une JVM de Sun dans tous les cas. Pourquoi ? PArcque les API ne sont pas tous portés, que des API ne sont disponibles que sur certaines plateformes, etc. bref, il faut se limiter aux implentations de bases pour être 100% portable. d'où le terme "relative".
S'il est vrai qu'actuellement J2SE signifie portable, n'oublions pas que les PDAs modernes ont déja des processeurs de plus de 400 MHz, ce qui fait plus que ble PC sur lequel j'ai commencé le Java. A mon avis, il sera bientôt faux de dire que la portabilité est restreinte, à moins bien sûr que ce ne soit le fait volontaire des fabricants de ces engins qui préfèrent brider les utilisateurs en imposant une méthode de téléchargement d'applications payante (ce qui risque fortement de se produire).
(je rajouterai que la portabilité se fait en général au détriment de l'intégration dans l'environnement, autant graphiquement qu'ergonomiquement)
C'est quoi cet argument à la noix non justifié ?
Je croyais avoir définitivement anéanti l'argument "Java c'est moche" ! Bref, piqûre de rappel : http://java.sun.com/products/jfc/tsc/sightings/(...) Et je connais certaines autres applis qui pourraient facilement y figurer ...
En plus, le JDK 1.4.2 amène d'importantes novueautés au niveau L&F qui mettent les applis Java au même niveau que les applis natives.
non non, jes JVM essai de faire du JIT, mais sont toujours obligé de faire de l'interprété pour commencer.
Tu as une preuve de ça ?
D'ailleur le démarrage d'une appli Java donne une idée du travail que doit effectuer la VM derrière ;)
Vachement, ouais, on est toujours dans le même niveau d'argumentaire. La machine virtuelle prend du temps à se lancer, car avant de lancer le programme, elle doit instancier le monde Java : Object, System, Class, ClassLoader et tous leurs petits potes. Après, une fois que l'appli se contente de tourner, ça va mieux. C'est d'ailleurs pour ça que certains JCP s'intéressent à des JVMs serveurs qui ne s'arrêteraient pas vraiment ...
Et celà ne change rien à ce que j'ai dit, le code IL est optimisé pour cette opération, qui est donc faite plus rapidement et sans passer par un système de profiling et d'interprétation.
Je crois que tu as eu assez d'arguments clairs à ce sujet ...
Pour les implentation d'autres langages sur la plateforme Java, je suis tout à fait d'accord que celà est possible. Mais là encore, le bytecode n'a pas été conçu pour, et il existe de nombreuses limitations (le code IL de .NET et Mono en a également je te rassure) et surtout ne définit aucun standard d'implentation qui facile l'interopérabilité entre les langages (tu peux écrire une classe en ADA, l'instancier en Logo et la modifier en Perl sur une machine virtuelle Java ?).
Déja, le faire, tout court, ça me paraît peu évident ;-)
En revanche, je l'ai déja dit, mais par exemple JScheme fournit de très efficaces moyens d'utiliser le Java en Scheme et réciproquement : http://jscheme.sourceforge.net/jscheme/doc/javaprimitives.html(...)
ah bon tu peux faire ca en Java ? : http://www.dotnetguru.org/articles/CSharpVsJava.htm#_D%E9tection_de(...))
Non, mais d'un auitre côté, quand tu mets un int dans un byte, il faut quand même être un minimum muni d'un cerveau.
Et puis, ce que j'aime bien dans cet article, c'est à quel point il démontre les différences entre Java et C#. C'est effarant de voir à quel point Microsoft a su évoluer depuis la base du VB pour produire une plateforme de qualité ;-)
Pour les métas-données, effectivement elles existent désormais dans Java 5, d'ailleur cette version de Java n'est là que pour rattraper le retard sur C# quand on voit les nouvelles fonctionnalités et pour proposer une implentation bancale des generics. (je ne rentrerais pas dans le débat, c'est très bien expliqué ici : http://www.artima.com/intv/generics.html(...(...)))
Pas besoin, les genercis sont une erreur, une stupidité innomable dont java n'avait pas besoin. En revanche, des choses comme les annotations, l'autoboxing qui apparaît enfin et le remplacement de StringBuffer me paraissent plus intéressantes, mais c'est un autre sujet ...
Tu considère l'ECMA comme étant dirigé par Microsoft (d'ailleur l'ECMA va parfois à l'encontre de Microsoft, un peu comme le java Community Process). Mais si j'en crois toutes les demandes faites à Sun pour libérer Java, j'en déduit qu'il n'est pas si libre que ça ;)
Tu me parles des demandes faites par IBM à SUN pour libérer sa machine virtuelle ? Est-ce que tu es naïf au point de ne pas voir la grossière manoeuvre stratégique ? Si IBM voulait réellement contribuer à une JVM libre, ils pourraient reprendre le projet GNU Classpath, ou d'autres (comme Blackdown, je crois), plutôt que de mendier à Sun la libération de leur travail.
Soyons sérieux cinq minutes. Si tu veux parler des gros sous entre IBM, Sun et Microsoft, pas de problèmes, mais là, ce sera DIFFICILE de ne pas marcher dans le FUD.-
[^]Re: Et au niveau du FUD, il va comment, Mono ?
Posté par Guillaume Laurent (page perso, ) le 05/07/2004 à 12:13. (lien). Évalué à 1.<<Pas besoin, les genercis sont une erreur, une stupidité innomable dont java n'avait pas besoin.>>
Là je serais curieux de connaitre tes arguments pour étayer ça.
Vu d'ici, c'est plutôt un cas classique de : "si mon langage à moi que j'aime a pas cette feature, ben c'est que cette feature c'est que d'la merdeuhhh".
Et sérieusement, as-tu seulement lu cette série d'interview de Hejlsberg ? Le gars est impressionnant par son pragmatisme et sa franchise.
-
[^]Re: Et au niveau du FUD, il va comment, Mono ?
Posté par TImaniac (Jabber id, page perso, ) le 05/07/2004 à 13:32. (lien). Évalué à 2.C'est quoi cet argument à la noix non justifié ?
Je croyais avoir définitivement anéanti l'argument "Java c'est moche" !
Désolé, mais ce qui fait la spécificité de chaque environnement (Windows, Gnome, KDE ou MacOS X), c'est surtout et avant tout leur ergonomie. L'emplacement des boutons, la disposition des menus, leurs noms, la "gueule" des fenêtre de base (ouverture/fermeture de fichier, "about", propriétés), tout celà est différents selon l'environnement. Et Java ne s'intègre nulle part.
Sans parler de ces différences qui apparaîtront toujours, il y a aussi les problèmes liés à la factorisation des points communs entre les environnements. Je prend pour exemple un contrôle très simple : l'arbre. Son utilisation et ses possibilités sont totalement différentes d'un toolkit à l'autre. Java ne permettra jamais d'utiliser les particularités de chacun (en tout cas pas pour le programmeur), ce qui est plus que dommage.
Voilà pourquoi je dis que graphiquement et ergonomiquement surtout, Java ne s'intègre nulle part. C'est les inconvénients de la portabilité.
Tu as une preuve de ça ?
désolé j'ai plus mes sources, mais tu as une preuve du contraire ?
Non, mais d'un auitre côté, quand tu mets un int dans un byte, il faut quand même être un minimum muni d'un cerveau.
C'est un exemple tout con. Parfois il n'y a qu'à l'exécution que l'on connaît le vrai type qui sera la cible de l'opération. Et de toute façon le compilateur est justement là pour éviter le maximum de bêtises liées aux bourdes du cerveau.
En revanche, je l'ai déja dit, mais par exemple JScheme fournit de très efficaces moyens d'utiliser le Java en Scheme et réciproquement
C'est bien, c'est un bon exemple, mais ce n'est pas normalisé... le compilateur C# est par exemple capable de vérifier qu'un API respecte bien ces normes justement.
Pas besoin, les genercis sont une erreur, une stupidité innomable dont java n'avait pas besoin.
C'est pas parcque toi tu trouves celà inutile qu'il ne faille par répondre aux attentes de millions de programmeurs... T'as jamais eu envie de faire une collection typée dans ta vie de programmeur ? Tu n'as jamais utilisé un squelette et fait des copié-collés et remplacé les types ? Evidemment la solution adoptée par Java ne change rien du tout au niveau de l'exécution (vérification, etc.) mais ce n'est pas pour celà que les generics sont inutiles. Et rien ne t'oblige à les utiliser...
Pour la dernière partie, je ne veux pas faire de FUD dans un sens ou autre. CE que je constate c'est que Microsoft a fait l'effort de normaliser la plateforme .NET et les API de base. l'ECMA me semble plus ouvert aux évolutions que le Java Community Process, mais c'est mon avis. Mais en dehors de celà, je crois que le plus important c'est surtout qu'il y est une réelle concurrence entre les 2 plateformes, Java 5 est un exemple flagrant d'émulation entre les 2 parties (bien que j'aurai aimé que Java 5 intègre des nouveautés plutôt que de se contenter de rattraper son adversaire).-
[^]Re: Et au niveau du FUD, il va comment, Mono ?
Posté par logout () le 08/07/2004 à 07:25. (lien). Évalué à 1.Désolé, mais ce qui fait la spécificité de chaque environnement (Windows, Gnome, KDE ou MacOS X), c'est surtout et avant tout leur ergonomie. L'emplacement des boutons, la disposition des menus, leurs noms, la "gueule" des fenêtre de base (ouverture/fermeture de fichier, "about", propriétés), tout celà est différents selon l'environnement. Et Java ne s'intègre nulle part.
Il me semblait que sous MacOSX mono utilisait X11 pour l'affichage ?
Si c'est bien le cas on ne peut pas non plus parler d'integration la...-
[^]Re: Et au niveau du FUD, il va comment, Mono ?
Posté par TImaniac (Jabber id, page perso, ) le 18/07/2004 à 09:23. (lien). Évalué à 2.tu peux utiliser GTK sous WIndows, Linux et MacOSX, alors effectivement celà ne s'intègrera nulle part, sauf sous Gnome évidemment. Mais sous Windows, les WinForms sont également supportées et Cocoa# est en développement ce n'est pas pour rien ;)
-
-
-
-
"Thème" de la dépêche
Le thème actuel pour cette dépêche est "Communauté".
"Technologie" me parait quand même plus approprié...
[+] Intense réflexion...
Usine à languages
Séquence petite humeur après une choucoutre bien garnie...
L'industrie fut une usine à copeaux !
L'informatique est une usine à languages !
Vous me direz que chaque domaines a ses modes :
- le management : le dernier concept, cette source de la productivité tant attendue,
- la politique : la décision courageuse qui va faire baisser le chômage (du moins officiellement),
- l'informatique : le dernier language, la grande fusion des paradigmes.
C'est symptomatique : sur ma babasse, la principale occupation de mon disque dur est consacrée aux langages, aux bibliothèques, aux compilateurs et autres interpréteurs.
Comment reconnaissons-t-on un informaticien (à une utilisateur avancé) ? Aux nombres des langages connus ! Quelle est la principale source financière du libre ? Les bouquins traitant des langages/bibliothèques informatiques.
Quelle est la consécration d'un informaticien ? Pondre un language ! La réalisation d'une bibliothèque, d'un interpréteur ou compilateur font néanmoins très bien sur un cv.
Question à 100 boules : Quelle est le prochain language qui fera tout péter ? ( suite de l'épisode dans 4-5ans).
Séquence recul épistémologique ...
Je ne dit pas que le diversité en soi pose problème. Loin de moi l'idée de coder uniquement en lisp (arg !) suite à un élan passéiste. J'use (souvent simultanément) moi même de beaucoup de language (prochaine conquète ocaml).
Tout simplement, je me pose juste la question sur la signification d'une telle diversité. Ainsi que de ce qu'il en reste après 10 ans ?
-
[^]Re: Usine à languages
Posté par kesako () le 02/07/2004 à 13:05. (lien). Évalué à 5.eh bien qd on regarde ces 40 dernieres annees, il reste principalement ... le fortran , le cobol et le C
c'est dire ...-
[^]Re: Usine à languages
Posté par Snark_Boojum () le 02/07/2004 à 13:39. (lien). Évalué à 4.Il me semble que LISP n'est pas tout à fait mort ; certes un peu transformé (scheme), mais le principe de base est le même...
Snark-
[^]Re: Usine à languages
-
-
-
[^]Re: Usine à languages
Posté par Ontologia (page perso, ) le 02/07/2004 à 22:42. (lien). Évalué à 2.>Question à 100 boules : Quelle est le prochain language qui fera tout péter ? ( suite de l'épisode dans 4-5ans).
Lisaac. Premier langage objet à prototype compilé multiplateforme.
Plus d'objet à classe, fini les héritages statiques. Langage bas, moyen, haut niveau, aussi voire plus performant que du C, grace à un algo novateur qui analyse ton code et supprime les étapes inutiles
(ie. si tu fait une fonction : toto{ a=7; b=9;c=a+b; return c;} il va analyser que ça sert à rien et va remplacer la séquence par 16 et le coller 16 quand tu appelera toto)
(http://www.loria.fr/serveurs/IsaacOS/language/lisaac_overview.zip(...) pour le pdf de présentation
mais vaut mieux commencer par http://www.loria.fr/serveurs/IsaacOS/divers/project_st_overview.zip(...) pour bien comprendre)
Pour le reste je suis assez d'accord avec toi. Le problème d'un entreprise est de diminuer les coûts...
Donc, à la recherche du saint langage qui nous fait gagner du temps.-
[^]Re: Usine à languages
Posté par Alex () le 03/07/2004 à 16:21. (lien). Évalué à 3.
ie. si tu fait une fonction : toto{ a=7; b=9;c=a+b; return c;} il va analyser que ça sert à rien et va remplacer la séquence par 16 et le coller 16 quand tu appelera toto
Mauvais exemple je pense, tout bon compilo fait déjà ça
J'ai survolé la doc (assez longue), et il semble y avoir quelques concepts interessants, que l'on retrouve parfois dans d'autre langage, avec l'avantage qu'il translate en C pour compiler en natif par la suite (comme ocaml je crois). Mais bon je trouve qu'on est loin de pouvoir dire qu'il fera tout péter... mais promis je lirai mieu la doc-
[^]Re: Usine à languages
Posté par Ontologia (page perso, ) le 05/07/2004 à 20:35. (lien). Évalué à 4.C'est partiellement vrai :
#include <stdio.h>
int a,b,c;
int main()
{
a=8;
b=7;
c = a+b;
return c;
}
gcc -S test.c -O3 -ggdb -o test.asm
.LCFI1:
pushl %eax
pushl %eax
.loc 1 11 0
movl $15, %eax
.loc 1 6 0
andl $-16, %esp
.loc 1 7 0
movl $8, a
.loc 1 8 0
movl $7, b
.loc 1 9 0
movl $15, c
.loc 1 11 0
leave
ret
CQFD :)
PS : en gcc sans -O3, il fait le calcul-
[^]Re: Usine à languages
Posté par Pascal Terjan (Jabber id, page perso, ) le 26/07/2004 à 20:53. (lien). Évalué à 2.C'est des globales donc il les laisse, normal. Avec des locales il les supprime, a partir de -O1.
-
-
-
-
[^]Re: Usine à languages
Posté par Guillaume Laurent (page perso, ) le 02/07/2004 à 23:26. (lien). Évalué à 1.En général chaque nouveau langage tire les leçons des précédents (typiquement : C, C++, Java, C#). On améliore l'outil de programmation, rien de plus.
-
[^]Re: Usine à languages
Posté par gnap gnap (page perso, ) le 03/07/2004 à 17:32. (lien). Évalué à 1.Est-ce à dire que chaque langage est supérieur au précédent ?
-
[^]Re: Usine à languages
Posté par Guillaume Laurent (page perso, ) le 03/07/2004 à 18:22. (lien). Évalué à 0.En général, oui (C < C++ < Java < C#), ou sinon il offre un paradigme complètement différent (Lisp, OCaml...), mais dans ce cas il va "direct à la niche", si j'ose dire, et ne sort quasiment pas des Universités, labos de recherche, ou certains segments très précis de l'industrie.
Après tu as toujours des gars qui préfèrent l' "ancien" langage et trouvent le nouveau pleins de features inutiles|dangereuses|lourdes etc... Ça ne loupe jamais, et le fait que ça se répète pour chaque nouveau langage prouve bien que leur réaction est avant tout émotionelle ("c'est mon langage qu'est le mieux et je changerai pas, na d'abord"), et non rationelle.
(il y a aussi ceux qui veulent à tout prix utiliser le nouveau langage dans des situations ou il ne convient pas du tout, par ex. quand Java est arrivé, il y avait un thread récurrent sur comp.emacs à propos de l'opportunité de ré-écrire Emacs en Java :-).
-
-
Mono...tonie
Bon, c'est bien gentil de proposer une soit-disant alternative à Java. Mais que peux-t-on réellement faire avec Mono dans une entreprise???
(la même réflexion s'applique à .Net )
Quelques questions en vrac:
- Où est le serveur d'application de Mono?
- Est-ce que Com+ va être porté sous *nix?
- Existe-t-il des alternatives à Com+ pour Mono?
- Si oui quels sont les services offerts pour les composants? (sécurité, transactions, messaging, ...)
Tout ça me rappelle la propagande Microsoftienne lors des dev days où une démo bidon est faite sur un BSD pour 'prouver' que .Net est portable. Et tous les béni-win-win de faire Hooooo devant une bête boite de dialogue affichant un bouton OK!
Java n'est surement pas la panacée et il subsiste certainement des lacunes. Mais avant de combler le fossé galactique qui le sépare des autres environnements de devt d'entreprise, m'est d'avis que l'informatique aura beaucoup changé...
-
[^]Re: Mono...tonie
Posté par TImaniac (Jabber id, page perso, ) le 02/07/2004 à 14:12. (lien). Évalué à 2.me semble qu'il y a déjà eu une tentative de portage de COM+ sous Unix, mais ce fut un échec lamentable.
Question équivalent, je penses que Corba est les même objectifs. Mais avec Mono, plus de problème de partage d'objet et d'exposition d'interface... Logiquement il n'y a plus besoin de COM & Co... sauf évidemment question compatibilité avec l'existant. C'est d'ailleur pour celà que sous WIndows cette compatibilité existe. Pas sous Linux... mais sachant que les composants COM n'existe pas sous Linux, c'est pas tellement utile à mon sens.
Sinon question messaging, transactions & co, voir doc du framework .NET.
Par contre de l'aveu même de De Icaza, il y a encore des efforts à faire du côté des API "spécial entreprise".-
[^]Re: Mono...tonie
Posté par Christophe Garault (page perso, ) le 02/07/2004 à 15:13. (lien). Évalué à 6.me semble qu'il y a déjà eu une tentative de portage de COM+ sous Unix, mais ce fut un échec lamentable.
Tiens, je n'ai jamais entendu parler de celà. Par contre de DCOM avec EntireX Dcom oui (Cf Software AG).
Question équivalent, je penses que Corba est les même objectifs.
Oulà. Corba est un bus, pas un serveur d'applis même si leurs services se ressemblent.
Mais avec Mono, plus de problème de partage d'objet et d'exposition d'interface... Logiquement il n'y a plus besoin de COM & Co...
Gnnnn? Qu'est-ce que c'est que cette histoire? Qui parle de COM? Moi je demande juste comment sont hébergés les composants? Qui se charge de leur gestion, de leur allocation, des pools, de la sécurité, des accès concurrents, des messages pour les broker, de la répartition de charge, etc...
Il ne faut surtout pas confondre COM ou DCOM qui sont des technologies propres à des composants (dont la compatibilité est assurée dans .Net), avec COM+ qui est un serveur d'applications. (anciennement Microsoft Transaction Server)
sauf évidemment question compatibilité avec l'existant. C'est d'ailleur pour celà que sous WIndows cette compatibilité existe.
Non. Encore une fois, il ne faut pas confondre la compatibilité avec des composants COM ou DCOM et le serveur d'appli intégré à Windows alias COM+.Pas sous Linux... mais sachant que les composants COM n'existe pas sous Linux
Ben si justement ça existe:
http://www2.softwareag.com/corporate/products/entirex/default.asp(...)
Sinon question messaging, transactions & co, voir doc du framework .NET.
Manquerai plus que celà: les composants qui se chargent eux-même du boulot d'un serveur d'appli! On marche sur la tête là...Par contre de l'aveu même de De Icaza, il y a encore des efforts à faire du côté des API "spécial entreprise".
Je dirais même qu'absolument tout reste à faire, et que ce ne sont pas que des API...
Bref, Mono ne sert à rien pour les applications d'entreprise. Merci de m'avoir lu jusqu'ici, vous pouvez continuer votre travail et retourner bosser sur Jonas ou Jboss.-
[^]Re: Mono...tonie
Posté par TImaniac (Jabber id, page perso, ) le 02/07/2004 à 15:37. (lien). Évalué à 4.Je doua t'avouer que je n'y connais pas grand chose dans les technos Microsoft COM & Co, j'ai cru que COM+ était une évolution de COM, désolé.
Sinon pour le serveur d'application, il me semble que c'est ASP.NET qui joue se rôle dans le monde .NET...
Après il manque effectivement System.EnterpriseServices dans Mono.
Enfin reste à voir ce que nous réserve Novell, car un de leur objectifs est de propouvoir Mono en entreprise, et il semble qu'en l'état actuel il manque vraiment beaucoup de choses...
Manquerai plus que celà: les composants qui se chargent eux-même du boulot d'un serveur d'appli! On marche sur la tête là...
Euh, j'ai jamais dis celà...
Un article qui peut t'intéresser, même si je suppose que je n'ai rien à t'apprendre dans le domaine : http://www.dotnetguru.org/articles/CoucheService.htm(...)
Enfin je suppose que ce post était surtout présent pour montrer une des lacunes de Mono, notamment pour les entreprises et tu as parfaitement bien fait de le souligner, étant incompétent dans ce domaine je n'avais pas soulever le problème dans ma news.-
[^]Re: Mono...tonie
Posté par Christophe Garault (page perso, ) le 02/07/2004 à 15:59. (lien). Évalué à 3.Un article qui peut t'intéresser, même si je suppose que je n'ai rien à t'apprendre dans le domaine
Détrompes-toi! Un informaticien qui n'a plus rien à apprendre est un informaticien mort!
L'humilité toujours tu devras garder... :)Enfin je suppose que ce post était surtout présent pour montrer une des lacunes de Mono, notamment pour les entreprises
Voilà, et aussi pour dire qu'en la matière, Java a encore de belles années devant lui.
Parce que même avec .Net on ne va pas loin, car contrairement aux dires de Ms, ce n'est pas vraiment portable.
-
[^]Re: Mono...tonie
Posté par Christophe Garault (page perso, ) le 02/07/2004 à 16:11. (lien). Évalué à 2.J'ai lu ton article et en ai trouvé un autre très interessant pas très loin, et qui explique notre malentendu plus haut sur l'implémentation dans le serveur ou dans le composant des services d'entreprise:
http://www.dotnetguru.org/articles/pooling.htm(...)
En clair, certaines propriétés des composants .Net peuvent être définies à l'écriture du code (mauvaise idée, changer d'idée) ou via la console d'admin de COM+ ce que font tous les serveurs d'applis digne de ce nom. Tu vois j'ai appris quelque chose! :)-
[^]Re: Mono...tonie
Posté par TImaniac (Jabber id, page perso, ) le 02/07/2004 à 16:19. (lien). Évalué à 2.Oué j'ai lu cet article aussi juste après, d'ailleur je trouve ce site fort itnéressant, car il discute à la fois des techno .NET mais aussi Java et notamment leur interopérabilité.
-
-
-
-
intégration Gnome
> De nombreux débats ont lieu sur une éventuelle intégration de Mono au projet Gnome
Ça reste au niveau du débat actuellement. Java est aussi très bien placé et même s'il a l'air technologiquement moins "hype" il a une grosse communauté, est mature, à plein d'outils et librairies. Pour le côté "hype", java peut toujours évoluer. Rien n'est définitivement figé. Mono a des problèmes de licences/brevets/chez_pas_quoi_d_autre qui en calme plus d'un (à tord ou à raison). Quoiqu'il en soit, Red Hat ne veut actuellement pas mettre de mono dans Fedora (ni Fedora Extra) pour des problèmes de licences/brevets/chez_pas_quoi_d_autre. Or il y a gcj, tomcat, etc dans Fedora .
Red Hat (du moins par la voie d'Havoc) a clairement une préférence pour Java. On aime ou on n'aime pas Red Hat mais son influence ne peut pas être ignorée. Et je n'oublie pas que Sun qui est plus free software friendly que MS (ya pas photo).
Bref, c'est vraiment pas gagné pour l'un ou pour l'autre.
L'intégration d'un java ou mono, c'est du long terme et aucune décision n'est prise. Il se peut que l'intégration d'un tel langage n'arrive pas avant plusieurs années. En autre car les bindings marchent et rendent service. Puis il y a aussi le raprochement de mozilla avec Gnome qui peut répondre à d'autres besoins.
Pour être honnète, je ne vois pas la situation de façon très claire car c'est techniquement très complexe et qu'il faut prendre en compte la "sensibilité" de la communauté.
Mais je suis toujours méfiant lorsqu'on annonce la déferlante d'une technologie qui va tout remplacer. L'historique de Java est un bon exemple. On devait avoir du java à tous les étages et sur une distribution Linux "classique" moderne c'est généralement limité au plug-in mozilla ou tomcat. Si je fais un tour sur freshmeat, Il n'y a pas beaucoup de projet sexy en java pour le desktop.
Puis MS a repris le développement d'IE :-)
Pour moi c'est : wait and see.
Hors-sujet:
--------------
Comme je ne peux pas faire de journaux, donc j'en profite ici.
Ébauche (donc c'est loin d'être définitif) de FC3 (servira aussi de base pour RHEL 4) :
http://www.redhat.com/archives/fedora-devel-list/2004-July/msg00056(...)
Pas aussi "révolutionnaire" que FC2.
Pour ma part je relève :
- Pango support for Mozilla
Un petit raprochement supplémentaire entre Gnome (en fait Gtk+) et mozilla.
Trou de sécurité Linux 2.4 et 2.6 :
http://www.redhat.com/archives/fedora-announce-list/2004-July/msg00(...)
During an audit of the Linux kernel, SUSE discovered a flaw in the
Linux kernel that inappropriately allows an unprivileged user to change the group ID of a file to his/her own group ID. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0497 to this issue.
Corrections
un outil pour naviguer dans la documentation : Monodoc, qui a l'originalité de pouvoir être modifié par
Mais il n'y a pas de réelle solution alternative qui soit libre et qui respecte les standard
Je remplacerait aussi solution alternative par solution concurrente, ou plus simplement autre solution.
De mauvaise foi !
Le lien "Points communs et différences avec la plateforme Java" est de mauvaise fois, car on compare ici principalement les langages et certainement pas les possibilités offertes par les plateformes ! Sans compter que l'on parle de .net sur cette page et pas du tout des possibilités de mono (sauf comme référence). Le jour au mono sera certifié .net je veux bien reconsiderer ce point. En attendant, mono n'a rien a voir avec .net ;-)
De plus, que je sache Java est disponible dans sa toute derniere version sur Linux et avec une compatibilité de 100% (merci au TCK). Alors passer aussi rapidement sur un "détail" à son importance.
Pour moi c'est de la mauvaise fois pure et simple.
Franchement, quite a faire du "portable à tout prix" autant faire du python !
Maintenant si, la portabilité doit être conservé et l'environement souple, alors Java reste le meilleur compromit. Et la confiance renouvellée de Apache avec le passage du projet Geronimo comme projet de premier niveau prouve que le temps n'est plus aux tergiversations dans la communauté.
Mieux vaut laiser icaza jouer avec son mono, moi pendant ce temps je joue avec Looking Glasses :
https://lg3d-core.dev.java.net/lg3dgettingstarted.html(...)
A chacun ces "jeux" ;-)
-
[^]Re: De mauvaise foi !
Posté par HappyPeng () le 03/07/2004 à 23:59. (lien). Évalué à 1.Et la confiance renouvellée de Apache avec le passage du projet Geronimo comme projet de premier niveau prouve que le temps n'est plus aux tergiversations dans la communauté.
Vous utilisez abusivement le mot communauté pour désigner des développeurs et des utilisateurs qui ont pour l'instant fait le choix de fonder leur travail sur une solution quasi exclusivement propriétaire, avec la machine virtuelle (les environnements J2EE libres et les projets Apache en Java ne tournent pas ou peu sur des machines virtuelles libres, etc.). Mais ce n'est pas le choix de tous (en particulier ça n'est pas le mien) et même d'entreprises importantes pour le libre telles RedHat (qui a choisi de libérer Eclipse de la machine virtuelle de Sun en adaptant la machine virtuelle de GNU, gcj/gij, et Eclipse pour qu'ils puissent fonctionner ensemble).
L'heure est donc bel et bien aux tergiversations, lorsqu'il s'agit de sujets aussi primordiaux. Comment tournerait un programme écrit en C sans compilateur ? Alors comment tournerait un programme écrit en Java ou en C# sans les environnements correspondants ? Tant qu'il subsistera un doute sur la viabilité de ces environnements pour le logiciel libre au point de vue licence, il y aura bien tergiversation.
Pour ceux qui parlent des spécifications Sun : est-il de toute façon possible qu'une implémentation libre puisse suivre au même rythme que sort le code nécessitant la toute dernière version (Looking Glass demande comme par hasard une bêta de Java 1.5) ?-
[^]Re: De mauvaise foi !
Posté par 007 () le 04/07/2004 à 06:51. (lien). Évalué à 2.> est-il de toute façon possible qu'une implémentation libre puisse suivre au même rythme que sort le code nécessitant la toute dernière version (Looking Glass demande comme par hasard une bêta de Java 1.5) ?
La réponse est forcément non.
Mais c'est une mauvais question si l'objectif est d'avoir java en libre fonctionnel pour les projets libres.
Red Hat a fait l'effort pour avoir Eclipse "totalement libéré". Le même travail peut-être fait ailleur. Si l'objectivité est la liberté, avoir une vm en retard sur la dernière vm de Sun n'est pas un problème. Malheureusement, les gens choisirons toujours (ou presque) la vm la plus complète au détriment de la plus libre.
C'est bien con. La seule solution, est de faire une vm meilleure que Sun. C'est très dure surtout si les gens "boudent" la vm libre tant qu'elle n'est pas au niveau de celle de Sun.
Mais je pense que celà peut basculer rapidement. Le problème est qu'il n'y a pas une forte demande (sauf côté serveur). Si la demande croit (peut-être avec Gnome) ça peut changer.
Pourquoi il n'y a pas de bonne vm libre ? Peut-être parceque la vm Sun est dispo (suffit de la downloader). Mono est développé rapidement car il n'y a pas le chois...
-
[^]Re: De mauvaise foi !
Posté par Nelis (page perso, ) le 04/07/2004 à 15:27. (lien). Évalué à 0.Vous utilisez abusivement le mot communauté pour désigner des développeurs et des utilisateurs qui ont pour l'instant fait le choix de fonder leur travail sur une solution quasi exclusivement propriétaire
Pourquoi ? Le terme communauté est breveté ? Seul le libre peut utiliser communauté ?-
[^]Re: De mauvaise foi !
Posté par HappyPeng () le 04/07/2004 à 16:38. (lien). Évalué à 1.Pourquoi ? Le terme communauté est breveté ? Seul le libre peut utiliser communauté ?
Il me paraissait assez clair qu'il n'y avait pas lieu de tergiverser si le mot communauté désignait ceux qui avaient de toute façon déjà opté pour Java. J'ai donc pensé qu'il parlait de la communauté du logiciel libre en général.
-
-
Point de vue d'un "javateux"
Je confirme la mauvaise foi sur tout ce qui a été dit sur Java...mais ca a été parfaitement démontré par les réponses précédentes...
Faut pas oublier de bien comparer par rapport à Java 1.5, qui implique des changements assez profonds dans le langage, et des améliorations diverses un peu partout...c'est une plateforme largement utilisée en entreprise, qui de ce fait bénéficie d'un gros feedback des utilisateurs...ce qui se voit dans les JCP.
Enfin, Java est soutenu également par des gros, dont IBM, Borland, etc...
Bref, je pense que Mono va pas remplacer tt de suite Java...
maintenant, si Mono clarifie ses pb de licences vis à vis de MS, si les API sont toutes portées sous linux, si la compatibilité devient la même que celle de Java (nombre de plateformes supportées), alors y'aura un match intéressant, qui vue l'aspect ouvert des 2 langages, pourra que déboucher sur du bon...
-
[^]Compatibilité ... oui justement !
Posté par Hive Arc (page perso, ) le 02/07/2004 à 20:24. (lien). Évalué à 3.Crois-tu que MS va "bien vouloir" sortir un TCK et publier complètement ses specs ?
Car c'est bien là le noeud du PB. Prend les fonctionalités entreprises de .net comme elle sont basés sur COM+ et qu'il n'y a aucune spec de dispo, il est impossible à mono de les supporter. Or toute platforme qui veut vraiment faire un truc qui monte en charge va passer par ces fonctionalités. Finit la "compatibilité" promise. De plus, avoir des API identique est une chose mais offrir un comportement identique en est un autre. Et le TCK est là pour ça !
Tant que MS ne fournira pas de TCK, il n'y aura pas d'avenir pour mono.
[+] Mort au libre qui ne fait que copier, longue vie au libre qui innove!
Cette page a été générée par Templeet en 0.3905s (dont 0.0913 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.