Journal Mono et Gnome

Posté par  (site web personnel) .
Étiquettes : aucune
0
2
août
2006
La décision du Gnome release team vient de tomber : Avec la sortie d'ici quelques mois de Gnome 2.16 une nouvelle dépendance va être introduite.

Je colle l'extrait :"New modules may be accepted into the desktop or admin releases with a dependency on gtk#/mono"

Le mail : http://mail.gnome.org/archives/devel-announce-list/2006-Augu(...)

Et en français ça veut dire quoi ?
Cela signifie que si un soft utilisant Mono est jugé assez bien par la release team il pourra être inclu dans Gnome (c'est d'ores et déjà le cas avec Tomboy). Cela va donc obliger les utilisateurs de Gnome à avoir Mono et le binding GTK# sur leur ordi.

C'est une décision très controversé du fait de l'incertitude juridique et technique autour de Mono (lire à ce sujet l'article de Fabrice Rossi : http://apiacoa.org/publications/2004/lm-java-dotnet-free.pdf ).

Pour les irréductibles réfractaires à Mono il reste XFCE qui devient vraiment bien et dont la release 4.4 promet de roxer.
Il va également y avoir beaucoup de changements dans KDE avec le passage en version 4.0 et les gnomistes réfugiés peuvent espérer une grosse refonte de l'interface utilisateur afin de se rapprocher de la simplicité de Gnome.
  • # maxi-Troll

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

    Je sais, je sais, on est pas vendredi mais c'était trop tentant....
  • # pour ou contre ?

    Posté par  . Évalué à 3.

    Une bonne âme qui a suivi le débat pourrait-elle faire un résumé des arguments pour ou contre l'intégration de Mono à GNOME ?

    J'ai tendance à ne voir que les aspects sympathiques de Mono (les applications que j'aime bien comme Tomboy ou Muine et tous leurs copains http://www.osnews.com/story.php?news_id=9780 ).

    Quelle est cette incertitude juridique et technique autour de .NET ?

    BeOS le faisait il y a 20 ans !

    • [^] # Re: pour ou contre ?

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

      j'ai pourtant bien collé le lien non ?

      http://apiacoa.org/publications/2004/lm-java-dotnet-free.pdf

      C'est long mais ça vaut vraiment le coup de le lire.
      • [^] # Re: pour ou contre ?

        Posté par  . Évalué à -9.

        C'est long mais ça vaut vraiment le coup de le lire.
        C'est avec ce genre de raisonnement que la presse de vulgarisation n'existerait pas : les choses ont besoin d'être dites, redites, remachées, rabattues, pour que les gens y fassent gaffe.

        Je n'irai pas lire cette article, pour deux simples raisons :
        * c'est un pdf ; juste la paresse d'ouvrir un logiciel supplémentaire pour le lire ;
        * c'est long (tu le dis toi-même), et j'ai autre chose à faire que de la lecture rapide.

        Dommage. Pour moi, peut être, mais aussi surtout pour le message à faire passer.
        • [^] # Re: pour ou contre ?

          Posté par  . Évalué à 5.

          Si 3 lignes ce n'est pas trop long pour toi, regarde mon commentaire, ci-dessous. :-)
        • [^] # Re: pour ou contre ?

          Posté par  . Évalué à 1.

          * c'est un pdf ; juste la paresse d'ouvrir un logiciel supplémentaire pour le lire ;


          Ton navigateur ne l'ouvre pas via un plugin ?
        • [^] # Commentaire supprimé

          Posté par  . Évalué à 10.

          Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: pour ou contre ?

        Posté par  . Évalué à 4.

        J'aime beaucoup les exposés de Fabrice Rossi (j'ai passé une année entière à la fac à suivre ses remarquables cours de Java) mais je préfèrerai vraiment un résumé.

        BeOS le faisait il y a 20 ans !

        • [^] # Re: pour ou contre ?

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

          En résumé très résumé : l'auteur étudie les implications d'une utilisation de plus en plus importante des plateforme Java et .NET dans le monde libre. Il ne rentre pas dans les débats techniques, Il tente plutôt de décortiquer les risques juridiques pour conclure au final que ni l'un ni l'autre ne sont top, et que Mono/.NET est encore plus dangereux car bourré d'incertitude (Microsoft dangereux toussa).
          Moi je reprocherai à cet article de ne pas comparer avec les autres logiciels libres. En effet, il peut y avoir des problèmes juridiques avec Mono, mais il ne démontre à aucun moment qu'il n'y a aucun problème avec les autres logiciels libre.
          De plus cet article n'est plus à jour (et c'est fort dommage vu qu'il sert souvent de "référence"). Hors depuis sa rédaction, Mono est protégé par l'Open Inventive Network, sorte de gros sac à brevets alimentés par IBM, Philips et autre Novell ou Red Hat pour riposter contre d'éventuelle attaque.
          De plus Novell détient aujourd'hui les brevets les plus dangereux sur .NET : ceux sur les web-services, ca encore c'est pas dans l'article, alors que c'est une des clés de la sécurité juridique de Mono.
          Au final j'ai envie de dire qu'avec tout le rafus juridique autour de Mono, c'est une des plateformes où l'on a paradoxalement le plus de certitudes.
          • [^] # Re: pour ou contre ?

            Posté par  . Évalué à 3.

            Mais objectivement je me demande si on peut faire plus confiance à Novell qu'à Microsoft...

            Novell reste une bonne grosse boite, et si en ce moment linux à la côte chez eux, un changement dans l'équipe de direction pourrait fort bien tout remettre en question. Là je pense evidemment à SCO, qui à une époque soutenait plutôt ce qui tournait autour de Linux, et maintenant tout le monde sait ce que c'est devenu...

            Alors, ceci dit je n'ai pas non plus analysé en détail la "profondeur" de l'implication de Novell, càd à quel point suse+ximian comptent dans leur balance.

            Simplement le fait qu'ils fassent un tel "pushing" de Mono au sein de Gnome m'incite à la prudence. Mais c'est mon avis qui n'engage que moi ^^
  • # Le passage Mono dans le document

    Posté par  . Évalué à 9.

    (Pour éviter que vous passiez 10 minutes/secondes à chercher) :

    Il [Miguel de Icaza] précise que Novell a conduit une etude des brevets actuels de Microsoft qui a conclu que Mono n’enfreignait aucun d’entre eux (les brevets de Kodak ne sont pas évoqués).

    Il indique que si dans les années à venir on découvrait que du code de Mono utilise sans autorisation un algorithme breveté, ce code serait soit ré-ecrit pour contourner le problème, soitsupprimé (cf aussi le
    blog de de Icaza, [93,94]). On retrouve ce point de vue sur le site de Mono (cf [95]) et plus généralement chez les développeurs de Mono (cf [96,97]). Nous n’avons plusqu’à espérer pour Mono que la demande de brevet déposée par Microsoft portant sur l’API entière de .NET ne soit pas acceptée, car on voit mal comment on pourrait la contourner...

    (Page 14).

    Le problème est donc simple :
    * Pour les US, est-ce que ce fameux brevet a été validé ? L'article date de 2004.
    * Pour le reste, est-ce qu'il y a un autre problème que ce brevet ? Nan ? Bah alors ?
    • [^] # Re: Le passage Mono dans le document

      Posté par  (site web personnel) . Évalué à 10.

      ça c'est pour le problème juridique (et encore c'est le point de vue hyper-partial d'Icaza...d'autres personnes sont beaucoup moins sures de l'innocuité de Mono).

      Mais il ne faut pas oublier le problème technique : alors que les utilisateurs supplient les devs de faire quelque chose à propos de la lourdeur de Gnome, alors que KDE écrase Gnome sur le plan de la rapidité et de la fluidité, quelle est la réction des devs et quelle est la direction qui est empruntée ? Ajouter une bonne grosse machine virtuelle dans Gnome !!!!!!!!!

      Il est évident que cette dépendance introduite ici va être utilisée par pleins de logiciels et qu'il va devenir impossible d'être un gnomiste sans utiliser Mono.
      Conclusion : Vivement KDE 4.0. Le seul truc qui me retenait d'avoir une Kubuntu au lieu d'une Ubuntu c'est le fouillis bordélique que constitue KDE. Si ça s'améliore radicalement avec la 4.0 je switcherais sans regret.
      • [^] # Re: Le passage Mono dans le document

        Posté par  . Évalué à 1.

        C'est si lent que ça une application développée en Mono ? Tu as un exemple en tête ?
        • [^] # Re: Le passage Mono dans le document

          Posté par  . Évalué à 1.

          ça sent la question rhétorique :-)
        • [^] # Re: Le passage Mono dans le document

          Posté par  . Évalué à 5.

          Gnome ?

          (je suis déjà très, très loin, dehors)
        • [^] # Commentaire supprimé

          Posté par  . Évalué à 1.

          Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Le passage Mono dans le document

          Posté par  . Évalué à 2.

          Perso, j'attends toujours qu'on me prouve que les applis ecrites dans des langages a vm sont *vraiment* plus lentes que les applis natives.

          Et pas la peine de me sortir une appli java avec gui AWT ou SWING codee avec les pieds qui tourne sur une jvm 1.2, parce que sinon je vous ressort des applis codee en C avec les pieds qui seg fault toutes les 5 minutes.

          Et pas du "mais c'est compile a la volee, c'est forcement plus lent" non plus, du concret avec des chiffres, qui prouvent qqchose.

          Niveau ram, ca c'est clair, ca bouffe beaucoup plus. Mais avec des machines milieu de gamme qui approche les 2Go c'est beaucoup moins problematique.

          Niveau CPU, bof. Pas convaincu non plus.

          Et quand on voit le temps gagne en dev a utiliser des langages haut niveau, ca ne peut que etre benefique.
          • [^] # Performance des langages

            Posté par  . Évalué à 10.

            Suffit de demander. Là tu vas pouvoir faire les comparaisons :

            http://shootout.alioth.debian.org/

            c++ vs C# mono par exemple.

            http://shootout.alioth.debian.org/debian/benchmark.php?test=(...)

            Après je te laisse tirer les conclusions que tu veux.
            • [^] # Re: Performance des langages

              Posté par  . Évalué à 3.

              ah oui, c'est sur que toutes les applis passent leur temps a faire des algos bien complexes genre mandelbrot, fibonacci ou autre cas d'ecole comme ceux proposes.

              Et surtout ne passent pas la plupart du temps en attente d'input dans la gui...
              • [^] # Re: Performance des langages

                Posté par  . Évalué à -3.

                Algos complexes? mandelbrot et fibo sont au contraire très simples je trouve! C'est même pas du niveau lycée...
                • [^] # Re: Performance des langages

                  Posté par  . Évalué à -4.

                  t'es con ou tu le fais expres?

                  qu'est ce qu'on entends par complexite en algorithmique en general?
                  • [^] # Re: Performance des langages

                    Posté par  (Mastodon) . Évalué à 3.

                    En algorithmique, fibo n'est pas complexe... ça se calcule en O(n).

                    Après, je suppose que dans le bench c'est codé récursivement, donc que c'est un peu plus lourd. En même temps, la récursivité est pas mal utilisée, donc c'est bien de savoir si une plateforme la gère bien.
                    • [^] # Re: Performance des langages

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

                      Ah non, pas encore un troll sur la complexité de fibonacci
                      (dont tout le monde sait qu'il est en O(log n) )

                      http://linuxfr.org/comments/714501.html#714501
                      • [^] # Re: Performance des langages

                        Posté par  . Évalué à 1.

                        on s'en fout de savoir si c'est du O(n) log n ou 4n +2-(a+b)², c'est pas la question, ca reste du calcul pure et un type d'algo qui n'est que tres rarement utilise dans des applis desktops, ou tu vas passer beaucoup plus de temps sur des operations beaucoup plus terre a terre.
                        • [^] # Re: Performance des langages

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

                          Mono x times better
                          -g++ x times better

                          Program & Logs : Faster | Smaller: Memory Use | Smaller: Code Lines
                          startup : -15 | -3.5 | 1.3


                          Ah oui, startup c'est juste un hello world :

                          using System;

                          class hello {
                          public static void Main(String[] args) {
                          Console.WriteLine("hello world");
                          }
                          }

                          Ça te va comme opération de base ?
                          • [^] # Re: Performance des langages

                            Posté par  . Évalué à -7.

                            wahou, g++ est 15 fois plus rapide pour faire un programme qui se contente de printer hello world.

                            mais c'est vachement interessant dis moi!!!

                            et dis moi, mon canard, t'en connais beaucoup des programmes a une (1) ligne de code?
                            t'en fais quoi de ce truc?
                            concretement, mis a part enculer des mouche et te branler sur la tete de ton compilo C, t'essayes de dire quoi?

                            qu'une vm ca met du temps a partir? Supeeeeer, kahal viens nous eclairer de sa grande lumiere, il lui a fallu le bench shootout en 2006 pour qu'il decouvre le temps de chauffe, merci de cette intervention.
                            T'as quelque chose d'autre a rajouter ou il te faut encore 6 mois pour decouvrir qu'une vm consomme plus de ram que l'equivalent en natif?
                            • [^] # Re: Performance des langages

                              Posté par  . Évalué à 9.

                              Je constate que tu brilles dans la façon de traiter tes interlocuteurs

                              t'es con ou quoi ?

                              mais c'est vachement interessant dis moi!!!

                              et dis moi, mon canard, t'en connais beaucoup des programmes a une (1) ligne de code?


                              Et j'en passe.

                              Non seulement tu nages dans la mauvaise foi (l'algorithme est trop compliqué/trop simple/pas adapté pour montrer que mono est mieux), mais tu es carrément malpoli.

                              Je t'invite à te taire et à te faire oublier rapidement.
                              • [^] # Re: Performance des langages

                                Posté par  . Évalué à -6.

                                faut arreter d'etre con aussi et de prendre le premier exemple avec un chiffre qui arrange bien.

                                Je voudrais bien avoir une explication de ce que bench hello world. On va voir s'il fera autant le malin

                                mais tu es carrément malpoli.

                                quitte a troller autant faire les choses correctement et en profiter pour une jolie joute verbale. M'enfin tout se perd ma bonne dame.
                                • [^] # Re: Performance des langages

                                  Posté par  . Évalué à 2.

                                  Un petit exemple simple :

                                  tous les programmes en console : c'est agréable quand ils répondent directement, s'ils mettent 15x plus de temps pour juste afficher une ligne comme quoi on s'est trompé d'argument c'est génant, enfin pour moi surtout :)
                                  • [^] # Re: Performance des langages

                                    Posté par  . Évalué à 1.

                                    15 fois 3 milisecondes, tu verras pas la difference...

                                    pis bon, on parle de desktop la...
                                    • [^] # Re: Performance des langages

                                      Posté par  . Évalué à 3.

                                      On peut concilier les deux ;)

                                      Par exemple, pour compiler des documents latex avec des figures aux formats multiples dont le SVG, Inkscape [C++/Gtkmm] fourni des options en lignes de commandes pour convertir les fichiers SVG en PS ou EPS. Très pratique pour mettre dans les makefiles.

                                      % inkscape --export-text-to-path --export-eps=toto.eps toto.svg
                                      % inkscape --export-text-to-path --export-eps $@ $<

                                      Un lancement rapide (voir très rapide) est alors nécessaire pour convertir plusieurs dizaines de fichiers.
                      • [^] # Re: Performance des langages

                        Posté par  (Mastodon) . Évalué à 2.

                        Un troll ? Je n'ai pas dit que sa complexité était O(n), simplement qu'on pouvait le calculer (trivialement) en O(n), et que donc ce n'était pas "dur" (j'avoue avoir eu la flemme de réfléchir/chercher quel était l'algo le plus rapide).

                        Je n'étais pas au courant que la complexité de fibo était un sujet de troll... tu ne confondrais pas trolls et erreurs ?
                        • [^] # Re: Performance des langages

                          Posté par  . Évalué à 9.

                          Un troll et une erreur, c'est un peu pareil :

                          Certains pense que dire "Gnome est mieux que KDE" est un troll, alors qu'en fait, c'est une erreur.
              • [^] # Re: Performance des langages

                Posté par  . Évalué à 4.

                C'est vrai que c'est les calculs intensifs en entier double, c'est vraiment d'une complexité peu communes dans les programmes. Sans parler des algos utilisant les reg-ex ou les b-tree.

                Certes ce ne sont que des tests de bases. Mais si tu as un vrai benchmark (pas un fait par bibi, quoi), je n'attends que cela. Je veux bien te croire mais ils faudrait trouver des benchmarks qui vont comparer d'une manière significative des librairies différentes.

                Comme je le pensais, je vois que tu as déjà tes propres conclusions indéboulonnables. Et je me demande bien qui tu essaies de convaincre, toi ou les autres ?

                PS. tu n'es pas obligé d'insulter les autres forumeurs.
              • [^] # Re: Performance des langages

                Posté par  (site web personnel) . Évalué à 10.

                ah, c'est sur qu'une appli qui passe son temps à attendre, donc à ne rien faire, ne sera pas plus lente dans un langage que dans un autre.
              • [^] # Re: Performance des langages

                Posté par  . Évalué à 7.

                Si on parle d'une appli qui passe son temps à attendre un input, alors j'attends d'elle qu'elle consomme le moins de ram possible, qu'elle se fasse discrète dans mon système. En attendant, des gens essaient de faire des applications comme f-spot pour mono et ce n'est pas le genre d'appli qui "attends une input". Elle est, dans les faits, bien plus molle que toutes les app de gestion de photo que j'ai touché auparavant.

                Et sinon, c'est un peu facile de dire "java c'est pas plus lent" pour après se rétracter "mais heu, les applis attendent un input donc ça change rien". Faut savoir. Java c'est pas plus lent, ou sa lenteur est tolérable dans l'idée que tu te fais des applications desktop ?

                Soit honnête. Dis-le ouvertement, comme tu viens de le faire, "les applis attendent une input donc on peut tolérer la lenteur de java", mais ne viens pas dire ça :
                "Perso, j'attends toujours qu'on me prouve que les applis ecrites dans des langages a vm sont *vraiment* plus lentes que les applis natives."
                • [^] # Re: Performance des langages

                  Posté par  . Évalué à 1.

                  les deux mon capitaine: java n'est pas lent dans l'absolu et de toutes facons rien ne sert de faire un concours de celui qui pisse le plus loin vu que la plupart des applis passent suffisament de temps a glandouiller pour que la vitesse pure ne soit de toutes facons pas un critere.
                  • [^] # Re: Performance des langages

                    Posté par  . Évalué à 6.

                    Donc une appli pas réactive, ça ne te dérange pas ? Je ne comprends pas ce que tu veux dire, ce n'est pas parce qu'une application passe la plupart du temps en fond d'écran que tu n'as pas besoin de vitesse pure au moment où tu l'utilises.
                    • [^] # Re: Performance des langages

                      Posté par  . Évalué à -2.

                      putin c'est pas complique :
                      1) java n'est pas lent dans l'absolu. Qu'il mette 0.7 ms a faire un truc la ou C++ en mettra 0.6, de toutes facon j'ai pas une horloge bionique dans la tete donc je verrais pas la difference.
                      2) De toutes facons on s'en cogne passque l'application va passer la plupart du temps a rien branler.

                      Une application swing bien codee ou SWT pas trop mal codee sera reactive. J'ai deja fait du swt, faut qu'on te dise que c'est du java pour que tu t'en doutes.
                      Regarde eclipse sous windows, sous reserve que tu aies suffisament de ram (un bon 512 si le projet est pas trop gros) ca reagit tres vite, au moins autant qu'un visual studio (et pourtant il fait bien plus de choses). Ca met beaucoup plus de temps a se lancer par contre, ca ya pas photo.
                      • [^] # Re: Performance des langages

                        Posté par  . Évalué à 9.

                        Que Java en soit ne soit pas particulièrement lent, je veut bien le croire (genre freemind est d'une rapidité très correcte).
                        Par contre est-ce que le fait que la consommation mémoire soit importante ne pose un problème ? Par exemple, si tu mets ton appli en tache de fond, que la jvm ne fait plus rien, quand tu vas vouloir l'utiliser à nouveau, l'os risque de devoir la remonter de la swap avec toute ses pages mémoires, et là, question réactivité, ça peut faire mal, non ?
                    • [^] # Re: Performance des langages

                      Posté par  . Évalué à 2.

                      un autre truc au sujet de la reactivite : c'est vraiment subjectif comme ressenti et au final plus dependant de la qualite des feedback de gui que de la vitesse pure du langage.
                      Sans compter qu'il faut prendre en compte l'etat d'esprit de l'utilisateur (stresse et a la bourre le matin au taff avant un reunion super importante ou sortant du bar plein comme une loutre avec un 4 feuilles dans les mains a 2h30 du tinma un 'medi soir en trainde troller sur dlfp).

                      Une appli bien designee mais lente paraitra plus reactive qu'une appli rapide sans aucun feedback.
                      Bon, ca marche dans l'autre sens aussi, une appli rapide avec un bon feedback paraitra plus rapide qu'un truc lent sans feedback.

                      Tout ca pour dire : savior que C# execute mandelbrot en 34.75 secondes la ou C++ le fait en 29, on s'en contrebalance, nanapété.
                      On peut tout a fait utiliser un langage a vm pour faire des applis desktops agreables et c'est tout ce qui importe.

                      Bref, le choix du langage tient plus dans les contraintes du projet (besoin d'acces a un bas niveau, maintenabilite, rapidite de dev etc.) que dans un concours de grosse teub de mec qui arrive a optimiser au max un algo qui ne sera jamais utilise par personne.
                      • [^] # Re: Performance des langages

                        Posté par  . Évalué à 7.

                        Quand f-spot sur mon portable qui me sert à gérer mes photos mets 2 ou 3 secondes à afficher mes photos highres et que Picasa en mets une, pour moi ça compte. Quand j'ai tiré de grosses rafales et que je fais le ménage, je dois être le plus réactif possible et effacer tous les déchets avec un moindre effort.

                        Picasa sous wine est plus rapide qu'f-spot.
                        • [^] # Re: Performance des langages

                          Posté par  . Évalué à 2.

                          tout a fait possible, j'ai jamais essaye fspot et a peine beagle.

                          Maintenant si tu veux des applis lourde et lente ecrite en C, je peux t'en sortir aussi.

                          J'ai vu pas mal d'appli reactives dans des langages a vm, et pas forcement codee par des gurus, c'est donc que c'est possible, quoiqu'en disent les refractaires aux technos qui ont moins de 15 ans.
                          • [^] # Re: Performance des langages

                            Posté par  . Évalué à 6.

                            Ben écoutes, moi je les attends ces applis qui m'aideront, car dans aucun des domaines où j'ai besoin de softs rapide je n'ai jamais rien vu en java/c#/ruby/python/perl alors pour l'instant vos histoires de VM c'est un mirage pour moi.

                            Si ça multiplie tant que ça la productivité vos nouveaux langages pourquoi les développeurs mono font que des trucs tout pourri ? pourquoi depuis le temps qu'existe java on a pas de GIMP-like ou de bonne appli de gestion de photo ? les développeurs java sont-ils condamnés à faire des trucs quick&dirty pour les entreprises, n'atteindront jamais le desktop ?

                            Des applis lentes en C/C++ j'en connais. OpenOffice en est le meilleur représentant. Ou Nautilus. Le problème, c'est que je connais aussi d'excellentes applis dans des domaines tous très différents en C/C++. Je ne connais pas d'excellente appli desktop en java.
                            • [^] # Re: Performance des langages

                              Posté par  . Évalué à 2.

                              l'autre probleme, c'est le deploiement.

                              Deployer une appli desktop java, faut avoir la jvm sur le poste client, ca pese 40Mo et c'est un peu lourd a faire.
                              Moins chiant de deployer une appli linkee en statique que de devoir presuposer de la capacite a installer une jvm.

                              Pour le graphisme, java est plombe par swing qui est une mauvaise api de gui (trop lourd et complexe, faut etre expert pour en faire qqchose). Swt est trop jeune a mon gout et assez recent dnas le monde java, mais tres prometteur.

                              Pour mono, j'ai installe, j'ai regarde monodevelop je crois qui est l'ide. Ben j'ai passe a la soiree prit d'un fou rire monstrueux. Va leur falloir un ide aux bonhommes, passque la ils vont pas aller tres loin avec ce qu'ils ont. Ceci explique peut etre cela.
                              Pour les perfs, voir aussi l'implem du runtime (regarde la jvm linux qui est clairement a chier : je le dit haut et fort java sun sous linux ca vaut pas tripette. Par contre sous windows ca tourne tres tres bien).
                              • [^] # Re: Performance des langages

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

                                l'autre probleme, c'est le deploiement.

                                regarde la jvm linux qui est clairement a chier : je le dit haut et fort java sun sous linux ca vaut pas tripette

                                Euh... Le déploiement et la portabilité, c'était pas censé être les points forts des langages interprétés (et de java en particulier) ?
                        • [^] # Re: Performance des langages

                          Posté par  (site web personnel) . Évalué à 6.

                          Quand f-spot sur mon portable qui me sert à gérer mes photos mets 2 ou 3 secondes à afficher mes photos highres et que Picasa en mets une, pour moi ça compte.
                          Ca c'est un très mauvais exemple, vu que le control d'affichage d'une image dans f-spot est écrit en... C. Comme quoi le problème ne vient pas du langage mais du codeur.
                          • [^] # Re: Performance des langages

                            Posté par  . Évalué à 2.

                            Effectivement, maintenant que tu me l'apprends, c'est un mauvais exemple :|.
                            Mais maintenant que tu dis ça.. ils n'ont pas confiance en mono pour coder l'affichage en c# ?
                            • [^] # Re: Performance des langages

                              Posté par  (Mastodon) . Évalué à 5.

                              Qu'est-ce qui te surprend dans le fait de coder ce qui a besoin d'être rapide en C, et le reste dans un langage de haut niveau ? C'est pourtant une pratique courante. Par exemple, il y a des bindings GTK pour plein de langages, mais la lib n'est pas recodée à chaque fois: elle est codée en C et réutilisée. C'est pour ça que java-gnome est rapide, et que java-swing est lent.
                              • [^] # Re: Performance des langages

                                Posté par  . Évalué à 3.

                                note: on peut faire des trucs bien et reactifs en swing.
                                Mais faut vraiment maitriser l'api.
                                Bon, perso je suis davis a mettre swing a la poubelle et le remplacer par swt qui est quand meme nettement plus agreable a coder et avec un meilleur rendu visuel.
                                • [^] # Re: Performance des langages

                                  Posté par  . Évalué à 2.

                                  Je voudrais bien avoir au moins un exemple de ça.

                                  Ou alors c'est juste que tous les développeurs Java sont complètement nuls en Swing ...

                                  BeOS le faisait il y a 20 ans !

                                • [^] # Re: Performance des langages

                                  Posté par  . Évalué à 6.

                                  Bon, perso je suis davis a mettre swing a la poubelle et le remplacer par swt qui est quand meme nettement plus agreable a coder et avec un meilleur rendu visuel.

                                  Tu crois pas qu'il y a assez de trolls là au milieur pour ne pas en lancer un autre. Je t'ai à l'oeil, ca fait 2 fois ;-)
                                  • [^] # Re: Performance des langages

                                    Posté par  . Évalué à 2.

                                    hihi
                                    ouais, mais bon, j'en ai marre que swing et les gens qui l'utilisent mal (sont nombreux, j'en fait partie) contribuent a ce que la reputation de lenteur de java 1.2 dure jusqu'a java 7.
                                    Alors si je peux en profiter pour lui casser du suc' sur le dos, je vais pa me gener.

                                    faut juste que swt murisse encore un touuuut p'ti peu et ca serait nickel.
                                • [^] # Re: Performance des langages

                                  Posté par  . Évalué à 2.

                                  Justemen SWT n'est il pas basé en grande partie sur l'API native de l'OS écrite en C ou C++ ? Or Eclipse utilise l'API SWT.
                                  La réactivité d'Eclipse serait donc plutot à mettre sur le compte de l'API graphique de l'OS.
                                  Et comme tu le dis Swing écrit en Java est à mettre à la poubelle. ;)
                                  • [^] # Re: Performance des langages

                                    Posté par  . Évalué à 4.

                                    A un moment donné tu es bien obligé d'utilser les librraies natives d'un OS.

                                    La portion de binding de SwT est négligeable par rapport à l'ensemble de la lib.
                                    Swing ou plutôt AWT aussi fait appel aux primitives graphiques de l'OS.
                                    Le problème de Swing vient surtout du cahier des charges originel.
                                    La lib devait être thémable en dynamique. Donc le code est plus conséquent plus difficile à faire évoluer ....
                                  • [^] # Re: Performance des langages

                                    Posté par  . Évalué à 2.

                                    comme le dis golum, le pb de swing, c'est le modele de l'api et l'implem derriere.

                                    L'interet de swt (et de toute lib de GUI en general) c'est pas les widgets en soi, c'est le modele derriere, comment tu stockes les objets dans tes widgets, les layouts, ce genre de chose. Et tout ca ben c'est du java. La partie native c'est juste l'affichage des widgets, soit pas grand chose au final (316ko de dll, 1.5Mo de jar).

                                    Quand a la reactivite d'eclipse, SWT ne s'occupe pas de la compile a la volee, du refactoring, des wizards de creations de projets et d'autres trucs de ce genre.
                                    Et c'est ca qui bouffe des ressources, pas les 3 fenetres et les 2 onglets affiches.
                              • [^] # Re: Performance des langages

                                Posté par  . Évalué à 3.

                                "Qu'est-ce qui te surprend dans le fait de coder ce qui a besoin d'être rapide en C, et le reste dans un langage de haut niveau ?"

                                Rien. Dans un autre message j'ai déjà fait remarqué que j'ai vu de très bonnes apps avec une interface scriptée et un coeur en C.

                                Le problème c'est que des gens ici, et ailleurs sur le net, essaient de faire croire que Java ou c# c'est proche de la rapidité du C. Si c'est tant proche de la rapidité du C, j'attends des apologistes autre chose que des biblio C.
                                • [^] # Re: Performance des langages

                                  Posté par  . Évalué à 2.

                                  des bibliotheques en java, yen a une palanquee.
                                  pour faire tout et rien, une floppee de choses diverses et variees.
                                  On utilise assez peu le natif en java pour deux raisons tres simples :
                                  1) jni, c'est tres chiant a mettre en place et ca pete tres vite.
                                  2) c'est un peu con vu que l'interet meme de java est justement de pas avoir de natif.
                                  En gros ca se fait quand vraiment tu peux pas faire autrement.

                                  Je t'invite a jeter un oeil a apache commons, jdom, json, tout ce qui se fait sur les serveurs d'appli (jsp/jsf tout ce genre de conneries et les machins qui gravitent autour) etc.
                                  Google n'est pas ton ami vu que t'as pas du trop chercher.

                                  Maintenant, c'est sur que si t'attends une glibc ou libstdc++ en java, t'es pas pret de la voir arriver.
                            • [^] # Re: Performance des langages

                              Posté par  . Évalué à 1.

                              Supaiiiire l'argument

                              et si ca avait ete le contraire tu nous qurait sorti
                              "Pourquoi ils recodent dasn leur coin des libs qui existent déjà? Ils connaissent pas la réutilsation ?".

                              Puis après tu nous sors un peu qu'il avancent pas dans leur projet.
                              Donc ils sont déjà à la bourre mais il faudrait tout réecrire.

                              Dans le genre trolleur toi !
            • [^] # Re: Performance des langages

              Posté par  . Évalué à 2.

              j'oubliais : sur un langage a vm, ya un truc qui s'appelle temps de chauffe de la vm.

              ca met du temps a partir, mais une fois que 'est parti ca tourne aussi vite.
              Teste de visu par bibi sur du java, c'est impressionant (un facteur 2 (ie passe de 3 fois plus lent que la ref en fortran a 1.4 fois plus lent) sur des applis scientifique en fonction de la taille des donnees en input).

              Bref, c'est sur que bencher un langage comme ca sur des tirs ultra court, ca va te donner des perfs de merde.
              Maintenant, j'ai pas l'impression qu'en desktop je passe mon temps a lancer une appli pour l'arreter 2.5 secondes apres.

              Sans compter que je suis loin d'etre convaincu que la vm mono soit au top, il aurait ete plus judicieux de prendre celle de microsoft en reference.
            • [^] # Re: Performance des langages

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

              Hop, pour info, les résultats de la première compétition internationale de solveurs de CSP (problèmes de satisfaction de contraintes) : http://cpai.ucc.ie/05/CPAI_Vol_II.pdf

              La plupart des solveurs de CSP sont codés en Java, bien que ce soient par essence des programmes purement algorithmiques et forçant fortement sur le CPU.

              Le principe est simple : un millier de problèmes différents sont donnés en entrée au solveur, le solveur a un temps défini pour résoudre le problème (10 minutes pour la compétition il me semble). Le programme ayant résolu le plus de problèmes est le vainqueur.

              Il faut regarder la Table 4 page 12 du PDF pour voir les résultats généraux.

              Les deux solveurs vainqueurs sont deux variantes du même solveur, codé en C. Les deux suivants sont deux variantes d'un solveur Java (la différence tient dans un mouchoir de poche, et vient plus de problèmes d'occupation mémoire que de temps, si on regarde les résultats de plus près), le 5e est en C, le 6e en Java. Les autres je ne sais pas, mais les deux derniers solveurs au classement étaient buggés, et étaient codés en C++...
              • [^] # Re: Performance des langages

                Posté par  . Évalué à 5.

                Euh, il me semble que la derniere colone du tableau 4 de la page 12, c'est le total solution time. Si c'est bien, ce que je crois les applications Java en 3eme et 4eme position ont terminés en prenant 50% de temps en plus, il me semble.
                Ou alors, j'ai rien compris ;) ce qui serait pas étonnant pour un vendredi soir (enfin presque pour moi c'est mon dernier jour de la semaine)
                • [^] # Re: Performance des langages

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

                  Oui, mais le temps n'est pas vraiment un critère fiable. Si un solveur plante sur un problème à cause d'un manque de mémoire, le temps utilisé sera très faible, alors qu'un autre solveur réussira peut être à charger ce problème, mais galèrera 10 minutes dessus sans le résoudre pour autant. Seul le nombre de problèmes résolus est utilisé pour générer le classement final.
          • [^] # Re: Le passage Mono dans le document

            Posté par  . Évalué à 9.

            Moi c'est l'inverse, j'en attends des exemples real world de grosses applications sur le desktop codées en java. Même pour une saleté de logiciel peer-to-pire, Azureus, fait moins bien que ses concurrents (µTorrent).

            Je veux un exemple d'une suite office, d'un moteur d'affichage HTML, d'un The GIMP/photoshop killer, explorateur de fichiers [...] rapide. mais ça n'existe pas. L'industrie est-elle stupide ? les programmeurs se font-ils chier avec C/C++ uniquement pour le plaisir ? je ne crois pas. Les faits sont là : que ce soit les applis de musique assistée par ordi, de graphisme etc qu'il m'ai été donné de toucher, à part jMax, je n'ai jamais vu une appli en java/dotnet/python/perl/ruby. Certaines applis ont un langage de script pour l'interface, mais le coeur de l'appli est codé en C/C++.

            Les langages à VM ou ceux scriptés, ça va pour faire quelques interfaces graphiques, à la limite. Mais il doit y avoir un coeur natif pour avoir une appli agréable à utiliser.
      • [^] # Re: Le passage Mono dans le document

        Posté par  . Évalué à 6.

        Je ne suis pas le dernier à raler quand je dois subir la lourdeur des applications Java graphiques. Pourtant je n'ai jamais remarqué que les applications en Mono étaient plus lentes ou lourdes que les autres.

        BeOS le faisait il y a 20 ans !

        • [^] # Re: Le passage Mono dans le document

          Posté par  . Évalué à 1.

          Je remarque un leger temps en plus pour le chargement, mais ce n'est pas trop.
          Par contre, c'est au niveau CPU et memoire que cela peut etre embettant je trouve, j'ai pas vraiment regarde mais si c'est trop a mon gout, a mois d'etre une appli critique, direction /dev/null

          En meme temps on rale pour les appli mono, mais les applis python et consort, je les trouve "pas mal" aussi...
          • [^] # Re: Le passage Mono dans le document

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

            Je ne sais pas où est la couche native dans les librairies graphiques de mono, mais pour Python, c'est généralement du C ou C++ et juste une couche de binding vers Python.
            Ce qui fait qu'il n'y a plus que la logique de haut niveau qui passe par la machine virtuelle (bon, c'est sûr qu'un lourd calcul dans cette couche... et ça s'écroule - mais bonne nouvelle, il y a aussi des bindings vers des librairies de calcul en natif genre traitement d'image & Co).

            De plus, pour Java (et je pense C# - faut voir ce qui en est pour Mono), il y a la possibilité de compilation à la volée (ie. le byte code est compilé en natif lors du premier appel, après c'est direct). Ca améliore nettement les perfs.

            Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

      • [^] # Re: Le passage Mono dans le document

        Posté par  . Évalué à -4.

        As tu seulement utilisé mono ????

        Ensuite, à l'heure ou tout le monde ici pleure pour que Linux s'impose sur le desktop, tu veux fermer cette possibilité de developper des applis (géniales, tu l'a dit toit même) facilement gràce à gtk#, ou que l'on attende des millenaires qu'un désoeuvré passe 3 mois pour refaire un simple magnétophone en C/Gtk ?

        Bref, bonne nouvelle, de mon point de vue ; cela dit, je n'utilise pas Gnome :)
        • [^] # Re: Le passage Mono dans le document

          Posté par  (site web personnel) . Évalué à 10.

          >> As tu seulement utilisé mono ????

          Oui et j'ai viré Beagle vite fait.

          >> tu veux fermer cette possibilité de developper des applis (géniales, tu l'a dit toit même) facilement gràce à gtk#

          Il existe un binding Python pour GTK alors pourquoi rajouter toute une machine virtuelle complète en plus ? Sans compter le fait d'utiliser une techno Microsoft dangeureuse sur le plan juridique.

          Avec le binding Python il est possible de créer facilement une appli Gnome donc l'argument de la simplicité ne tient pas une atto-seconde.
          • [^] # Re: Le passage Mono dans le document

            Posté par  . Évalué à 9.

            Qu'est ce que tu veux, mono, c'est le truc marketing par excellence. Ils ont même réussi à faire croire au béotien que les applis développées en C# sont meilleures. Au contraire, les bonnes applis python/GTK ne reçoient aucune attention, par exemple Quod Libet : http://www.sacredchao.net/quodlibet
            Si python/GTK avait déroulé le même plan marketing, les choses auraient surement été différentes.
          • [^] # Re: Le passage Mono dans le document

            Posté par  (Mastodon) . Évalué à 1.

            Oui et j'ai viré Beagle vite fait.

            Ça fait plusieurs fois que je vois des gens juger Mono à partir de Beagle ou F-Spot... vous avez vu le numéro de version de ces logiciels ? Beagle est une 0.2.x, et fspot une 0.1.x.

            Il existe un binding Python pour GTK alors pourquoi rajouter toute une machine virtuelle complète en plus ?

            Python est interprété. Il n'y a aucune différence entre un interpréteur et une machine virtuelle. Généralement, on dit "interpréteur" quand le langage est interprété tel quel, et "machine virtuelle" quand il est d'abord traduit en "bytecode" qui est ensuite interprété, mais la séparation entre les deux est très floue. Quand tu fais du Python, du Ruby, du PHP... tu utilises une machine virtuelle (ce n'est pas sale).

            Par contre, c'est sûr qu'un desktop qui utilise des applis Python, Ruby et Mono doit charger trois machines virtuelles, et c'est d'autant plus lourd. Moralité: il faut que tout le monde utilise Python.NET et Ruby.NET, pour n'avoir que Mono :)

            (je rigole, utilisez Parott)
            • [^] # Re: Le passage Mono dans le document

              Posté par  . Évalué à 5.

              J'ai trouvé les traces du début des annonces de Beagle pour la sortie de Mono 1.0, le 30 juin 2004. Ca veut dire qu'en plus de deux ans de dévelopement sur l'application emblême de Mono avec ces outils soit-disant si performants on n'en soit que là ? Tu n'as pas l'impression qu'il y a comme un problème ?
              • [^] # Re: Le passage Mono dans le document

                Posté par  (Mastodon) . Évalué à 6.

                Il y a deux problèmes différents: juger des performances ou de la stabilité des applis Mono à partir de softs pas finis, et juger de la rapidité/facilité de développement. Je faisais référence au premier point.

                Après, pour le deuxième point, j'ai brièvement regardé C# et les libs fournies par Mono, et ça n'a pas l'air moins bien que Java, mais ça n'a rien de transcendant non plus. Je ne suis pas allé très loin dans mon expérience, mais je pense que si Beagle traine c'est plutôt:
                1- parce que c'est difficile à faire
                2- parce que ça manque de devs, ou bien que ça en a manqué pendant longtemps
                3- à cause de problèmes d'organisation

                Pendant longtemps, pour tester Beagle il fallait patcher le noyau, activer des options au niveau du système de fichiers, bref, ça n'aidait pas à s'impliquer. Je pense qu'il y a eu trop de buzz autour de ce truc avant qu'il soit suffisamment avancé.
          • [^] # Re: Le passage Mono dans le document

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

            Oui et j'ai viré Beagle vite fait.
            Et t'as mis quoi à la place ? T'as une autre solution moins buggué/moins consommatrice de ressources ?

            Il existe un binding Python pour GTK alors pourquoi rajouter toute une machine virtuelle complète en plus ?
            Ben pour justement laisser le choix aux développeurs ? Pourquoi accuser la lourdeur et la lenteur d'une appli Mono quand une appli Python a les mêmes désavantages en plus accentués ?
            Ensuite ca serait bien d'arrêter de parler d'une "bonne grosse" machine virtuelle de la "lourdeur" d'une machine virtuelle, on parle d'un truc "virtuel", ca serait bien de le rappeler, concrêtement elle n'existe pas, c'est un concept purement intellectuel pour le développeur, c'est une couche d'abstraction lors de la phase de développement. D'ailleur on peut dire que GCC a une machine virtuelle qui est représenté par l'ensemble des instructions disponibles dans son langage intermédiaire "indépendant" du processeur.
            Il y a un aspect plus "lourd" mais il ne vient pas de la machine virtuelle en soit, mais des services fournis par l'environnement d'exécution : garbage collector, isolation mémoire, sécurité, etc. On a beau dire tout ce qu'on veut, ces services contribuent à la qualité d'un soft, tous les langages modernes l'ont compris. De plus de nombreuses applis écritent dans des langages comme C/C++ réinventent la roue et "simulent" ces services, introduisant la même lourdeur.

            Sans compter le fait d'utiliser une techno Microsoft dangeureuse sur le plan juridique.
            Faut arrêter le FUD à 2 balles. Je vais donc recommencer : si y'a des brevets dangereux sur .NET, et qui existent, ils sont sur les web-services... et c'est Novell qui les détient. Ensuite Mono est protégé par l'initiative des éditeurs du monde open-source visant à offrir une sécurité juridique à ces solutions. Au même titre que Python d'ailleur. Tous les projets Open-Source sont potentiellement jurdiquement attaquables.

            Avec le binding Python il est possible de créer facilement une appli Gnome donc l'argument de la simplicité ne tient pas une atto-seconde.
            J'ai l'impression que tu n'as jamais codé en Python et en Mono. "oué y'a un binding GTK donc c'est pareil". Ce n'est pas que la présence d'un binding GTK qui en fait une plateforme "simple". Mono offre des services avancés d'intégration avec des libs existantes écritent en langage natif qui facilite grandement l'écriture de nouveaux bindings. C'est pas pour rien que .NET a un gros succès sous Windows par rapport à Java : l'intégration dans l'environement natif et avec l'existant est bien plus facile à mettre en oeuvre.
            • [^] # Re: Le passage Mono dans le document

              Posté par  . Évalué à 2.

              Et t'as mis quoi à la place ? T'as une autre solution moins buggué/moins consommatrice de ressources ?
              Strigi : http://www.vandenoever.info/software/strigi/
              http://strigi.sourceforge.net/index.php/Main_Page
              Je l'ai testé, ça marche très bien (pas de bugs apparents), l'interface est sûrement à retravailler, et la taille de l'index est important. Utilisation du CPU<1%, consommation mémoire <10Mo (impressionnant, je n'ai rien senti).
              Par contre, je n'en ai toujours pas l'utilisation

              Kio-lucene : http://kioclucene.objectis.net/ , pas testé mais j'en ai entendu du bien.
            • [^] # Re: Le passage Mono dans le document

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

              Ensuite ca serait bien d'arrêter de parler d'une "bonne grosse" machine virtuelle de la "lourdeur" d'une machine virtuelle, on parle d'un truc "virtuel", ca serait bien de le rappeler, concrêtement elle n'existe pas, c'est un concept purement intellectuel pour le développeur, c'est une couche d'abstraction lors de la phase de développement. D'ailleur on peut dire que GCC a une machine virtuelle qui est représenté par l'ensemble des instructions disponibles dans son langage intermédiaire "indépendant" du processeur.

              TImaniac, c'est pas la première fois que je te surprend à dire une connerie, et en proférant souvent moi aussi, je décèle chez toi une certaine incompréhension sur la compilation et sa théorie.

              Il y a machine virtuelle et machine virtuelle. Dans le cas qui nous préoccupe ici, Java et Mono, il s'agit d'une "vraie" machine virtuelle. C'est à dire que nous avons un programme, qui lit un espèce d'assembleur (à pile... j'en entend certain rigoler) et dispose de quelques primitives.
              Voir pout Java : http://java.sun.com/docs/books/vmspec/html/Overview.doc.html

              Donc, même si le pseudo compilateur java produit un pseudo assembleur, il faut le traduire cet assembleur, surtout qu'il est d'assez haut niveau. Ca prend du temps, tout ça

              Un programme compilé n'a pas ce problème, l'assembleur est là, prêt à être exécuté.

              Alors certes, dans une machine virtuelle, tu peux gagner du temps en faisant des tables de hashage sur des appels de fonctions très utilisées, tu peux réutiliser du code déjà "compilé". Mais toute la phase de compilation à la volée du pseudo-code (code objet) est à faire. Le compilateur est en quelques sorte dans ton programme, d'autant plus lourd que la machine virtuelle est haut niveau. La Java Virtual Machine, est assez haut niveau j'en veux pour preuve l'exemple

              void createBuffer() {
              int buffer[];
              int bufsz = 100;
              int value = 12;
              buffer = new int[bufsz];
              buffer[10] = value;
              value = buffer[11];
              }

              might be compiled to
              Method void createBuffer()

              0
              bipush 100
              // Push bufsz
              2
              istore_2
              // Store bufsz in local 2
              3
              bipush 12
              // Push value
              5
              istore_3
              // Store value in local 3
              6
              iload_2
              // Push bufsz...
              7
              newarray int
              // ...and create new array of int
              9
              astore_1
              // Store new array in buffer
              10
              aload_1
              // Push buffer
              11
              bipush 10
              // Push constant 10
              13
              iload_3
              // Push value
              14
              iastore
              // Store value at buffer[10]
              15
              aload_1
              // Push buffer
              16
              bipush 11
              // Push constant 11
              18
              iaload
              // Push value at buffer[11]
              19
              istore_3
              // ...and store it in value
              20
              return

              trouvé ici http://java.sun.com/docs/books/vmspec/html/Compiling.doc.htm(...)

              J'ose pas imaginer ça en asm x86, avec toute la gestion de la mémoire derrière... (et la super instruction "newarray int").

              Conclusion, la bataille entre compilateur et machine virtuelle fait rage depuis 20 ans, voire plus, avec les mêmes arguments.

              Je pense que le futur est à une synthèse entre les deux, ou plutôt à une intégration de concepts issu de l'interprétation dans la compilation : On peut imaginer un langage dans lequel on spécifie les intervales de définition les plus probables, où l'analse de flot détecterait des fonctions souvent rappelées et peu susceptibles de donner des résultats changeant en squeezant les appels et les remplaçant par des tables de hash. OU encore, mais ça me plait moins, d'entraîner le code sur des données et de recompiler sur des statistiques (Intel le fait).
              Bref une belle thèse de doctorat (s'il y a des étudiants en Master 2 ou 1 prometeur dans la salle, contactez moi, je ferai passer) en perspective.

              « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

              • [^] # Re: Le passage Mono dans le document

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

                Ontologia, ce n'est pas la première fois que je te surprends également à dire une connerie :)
                Je persiste et je signe, la notion de machine virtuelle est une notion abstraite. Certes, avec certains environnement d'exécution, la dernière phase de compilation est effectuée "juste à temps", mais que ce soit pour Java ou à plus forte raison pour .NET, il est tout à fait possible de compiler dès le départ en natif, bref, au final ca prend pas plus de temps.

                Un programme compilé n'a pas ce problème, l'assembleur est là, prêt à être exécuté.
                C'est pourquoi Mono implémente les spécifications d'une machine virtuelle qui a été conçue en vue de produire du code compilable à l'avance en code natif (que ce soit au dernier moment, 1h avant, ou 1 mois avant) Le résultat est identique : c'est de l'assembleur qui s'exécute, et il n'y a aucune phase de traduction/interprétation une fois la dernière phase de compilation effectuée.

                il s'agit d'une "vraie" machine virtuelle. C'est à dire que nous avons un programme, qui lit un espèce d'assembleur (à pile... j'en entend certain rigoler) et dispose de quelques primitives.
                C'est rigolo de parler d'une "vraie" machine virtuelle... Une machine virtuelle est... virtuelle, elle n'existe pas. Une machine c'est quelque chose de physique. Le jour où t'auras une vraie machine qui existe pour .NET ou Java, ca sera un proc dédié pour exécuter les instructions du langage intermédiaire. Ce dont tu parles c'est l'environnement d'exécution et plus particulièrement de son compilateur JIT.

                Pas la peine de réciter ton blabla théorique habituel, t'as beau affirmer des vérités générales, ca ne change strictement rien à ce que j'ai dis : le problème de la lourdeur vient des nombreux services offerts que n'offrent pas les langages "traditionnels" orientés machine physique sans limitations. C'est services ont un coup, c'est évident et n'importe quel bench peut le montrer, mais ils participent à la qualité du soft, tout est alors une question de juste équilibre.

                Comme je l'ai déjà dis, même GCC propose une machine virtuelle, mais ne propose pas tous les services qu'offre Mono/Java, ce qui lui permet de produire du code machine plus rapide et plus optimisé.

                Conclusion, la bataille entre compilateur et machine virtuelle fait rage depuis 20 ans, voire plus, avec les mêmes arguments.
                Sauf que depuis 20 ans pleins de choses ont évoluées : les machines sont plus puissantes, offrant la possibilité de fournir des services supplémentaires à l'exécution sans vraiment pénaliser l'application qui s'exécute, les techniques de compilation JIT ont largement évoluées pour remplacer la traditionnelle phase d'interprétation du langage intermédiaire, qui elle était réellement lente, et surtout le plus important, les programmes ont changé de taille : on ne parle plus de quelques milliers de lignes mais plutôt de millions de lignes. Et là de nombreux programmeurs ont compris l'intérêt que pouvait apporter les environnements riches en services "ajoutés", ce qui leur permet globalement d'améliorer grandement la qualité de leur code, mais aussi de faciliter la programmation à plusieurs (composants, versionning, signature numérique, introspection et j'en passe).
                Alors oué t'as raison, les pro langage natif "à l'ancienne" utilisent toujours les mêmes arguments, et pendant ce temps d'autres bossent, codent, et certains leurs offrent des outils/langages/bibliothèques/compilateurs qui leur rendent réellement services. Va coder une application d'entreprise devant facilement monter en charge en répartissant ses composants sur différentes machines dans un langage comme C/C++, bon courage.

                PS : Je ne suis pas spécialement contre le code "superoptimisédelamortquitue" écrit en assembleur, ca a toujours son intérêt pour de nombeuses applications (couches bassent de l'OS, embarqué, etc.)

                PS2 : tiens au fait, on attend toujours une release GPL de votre langage...
                • [^] # Re: Le passage Mono dans le document

                  Posté par  (Mastodon) . Évalué à 1.

                  C'est rigolo de parler d'une "vraie" machine virtuelle... Une machine virtuelle est... virtuelle, elle n'existe pas. Une machine c'est quelque chose de physique.

                  Tout le monde est d'accord pour dire qu'une machine virtuelle (MV) n'est pas une machine physique, mais il y a plusieurs manières de concrétiser les machines virtuelles. Le language C décrit une MV (une couche d'abstraction par rapport aux vraies machines), mais quand on compile un programme C vers du code natif, on obtient un programme pour une MV de niveau plus bas que quand on compile un programme en Java. Simplement pare qu'avec gcc la MV est une abstraction utilisée pendant la traduction, alors qu'avec java, la MV est une abstraction utilisée pendant l'exécution.

                  Le jour où t'auras une vraie machine qui existe pour .NET ou Java, ca sera un proc dédié pour exécuter les instructions du langage intermédiaire. Ce dont tu parles c'est l'environnement d'exécution

                  Tu fais la leçon en expliquant (tout à fait justement) que même GCC possède une machine virtuelle, mais tu oublies que même les machines physiques sont construites en couches logiques (électronique -> logique -> microinstructions -> système d'exploitation, quelque chose comme ça). À partir de quand est-ce qu'on a une machine réelle ? Est-ce qu'une machine avec un processeur x86 dédié qui ne fait qu'exécuter une JVM, c'est une machine (java) réelle ? Pourtant, vu de l'extérieur (vu de l'OS), impossible de faire la différence avec un processeur spécialisé qui comprend le bytecode java directement.

                  Au final, je n'ai pas l'impression que la distinction entre langage natif et langage à MV soit fixe, ou qu'on puisse en tirer quelque chose d'intéressant. Plus on a de couches à traverser, plus ça prendra de temps de les traverser, mais le nombre de couches à traverser dépend grandement du contexte (et de toutes façons, la traduction d'un langage à l'autre n'est pas nécessairement la partie la plus coûteuse en temps).
                • [^] # Re: Le passage Mono dans le document

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

                  Sauf que depuis 20 ans pleins de choses ont évoluées : les machines sont plus puissantes, offrant la possibilité de fournir des services supplémentaires à l'exécution sans vraiment pénaliser l'application qui s'exécute, les techniques de compilation JIT ont largement évoluées pour remplacer la traditionnelle phase d'interprétation du langage intermédiaire, qui elle était réellement lente, et surtout le plus important, les programmes ont changé de taille : on ne parle plus de quelques milliers de lignes mais plutôt de millions de lignes. Et là de nombreux programmeurs ont compris l'intérêt que pouvait apporter les environnements riches en services "ajoutés", ce qui leur permet globalement d'améliorer grandement la qualité de leur code, mais aussi de faciliter la programmation à plusieurs (composants, versionning, signature numérique, introspection et j'en passe).
                  Alors oué t'as raison, les pro langage natif "à l'ancienne" utilisent toujours les mêmes arguments, et pendant ce temps d'autres bossent, codent, et certains leurs offrent des outils/langages/bibliothèques/compilateurs qui leur rendent réellement services. Va coder une application d'entreprise devant facilement monter en charge en répartissant ses composants sur différentes machines dans un langage comme C/C++, bon courage.


                  Je suis d'accord que l'important est de disposer de langage évolué disposant donc de primitives tout aussi évolué.
                  Je suis le premier à militer" pour la montée en niveau des langages. J'ai même fait une publi là dessus.
                  Le fait que, ces services soient pour le moment offerts sur des machines virtuelles prouvent que compiler la même chose est trop compliqué, qu'on ne sait pas le faire, mais personne n'a prouvé que c'est impossible !
                  Je suis totalement d'accord avec toi dans le refus catégorique d'obliger le programmeur à l'ancienne pour utiliser un code compîlé, pour le plaisir d'avoir du code compilé. En terme de rationalité économique c'est effectivement stupide.

                  Quand je parlai de "vrai" machine virtuelle, je parle d'un programme exécutant un pseudo assembleur. Ca prend du temps de le compiler, même si c'est beaucoup plus rapide que de compiler du C++ ou du C.
                  En admettant que ce soit compilé intelligement, et souvent une bonne fois pour toute, une fois le code compilé, il n'est plus adaptable, spécialisable au contexte. On retombe toujours dans le même problème.

                  Ce que je veux simplement dire, c'est qu'il y a des recherches à faire là dedans pour essayer de synthétiser les avantages des deux, d'imaginer du code automodifiant, de l'analyse de chemin d'exécution, de contexte de données, toussa. On en parle.

                  nicO a pas mal d'idée sur le sujet, qu'il a posé ici (avec d'autres) :
                  http://wiki.loria.fr/wiki/Lisaac/Optimisation_en_taille
                  http://wiki.loria.fr/wiki/Lisaac/Optimisation_en_performance
                  http://wiki.loria.fr/wiki/Lisaac/WishList
                  http://wiki.loria.fr/wiki/Lisaac/Fonctionnalit%C3%A9_du_lang(...)

                  Les techniques d'analyse de flots le permettent. Comme je le disais c'est un beau sujet de thèse.

                  PS2 : J'ai déjà expliqué 5000 fois que je n'ai pas le pouvoir, et Benoit non plus quand à la libération du code source de Lisaac. Nous avons l'autorisation de libérer IsaacOS, ce que nous préparons dans les mois à venir (on travaille à faire une distrib pour développeur absolument impeccable, avec de la doc, des explications, le tout nouveau compilateur, etc...).
                  Mais pour Lisaac, nous n'avons pas le pouvoir de le libérer. J'aimairai beaucoup le voir en GPL crois moi.

                  « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                  • [^] # Re: Le passage Mono dans le document

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

                    Le fait que, ces services soient pour le moment offerts sur des machines virtuelles prouvent que compiler la même chose est trop compliqué
                    Je me tue à t'expliquer qu'une plateforme comme Mono tu produits un code compilé en natif et qui s'exécute comme tout autre exécutable générés par un compilateur traditionnel ! Donc oui c'est possible, mono le fait. GCJ aussi, .NET ngen aussi.
                    Si ces services sont associés à une machine virtuelle, c'est qu'il est impossible d'offrir les mêmes services associés au jeu d'instruction des machines physiques que nous connaissons, il est donc nécessaire d'introduire une couche d'abstraction purement virtuelle mais offrant un ensemble de services/instructions cohérent et intégré.

                    Quand je parlai de "vrai" machine virtuelle, je parle d'un programme exécutant un pseudo assembleur.
                    Si tu veux, et moi j'essai justement de t'expliquer qu'avec des environnement modernes comme Mono, ce n'est plus comme ca que ca marche :)

                    En admettant que ce soit compilé intelligement, et souvent une bonne fois pour toute, une fois le code compilé, il n'est plus adaptable, spécialisable au contexte. On retombe toujours dans le même problème.
                    Toutafé. Un programme compilé en code natif dès le départ (ala C) a ce problème. Mais c'est là que le fait de retarder la dernière étape de compilation au dernier moment (JIT) apporte une grande souplesse : on peut compiler à l'avance, mais aussi le faire "en live", la refaire si nécessaire, etc.

                    Ce que je veux simplement dire, c'est qu'il y a des recherches à faire là dedans pour essayer de synthétiser les avantages des deux, d'imaginer du code automodifiant, de l'analyse de chemin d'exécution, de contexte de données, toussa. On en parle.
                    Oué ca c'est cool, mais j'ai l'impression que tu n'as qu'un objectif : les performances. Ce après quoi court Lisaac (avec aussi bien sûr quelques paradigmes objets originaux et une meilleure abstraction), mais en laissant de côté tous les services qu'offrent les plateformes modernes de style .NET/Mono. Sans doute parcque ce n'est pas la même utilisation visée.
                    Ah oui, et puis bon, je sais pas si ca sert à grand chose de se "prendre" le choux pour obtenir des gains de performances générales sur l'ensemble d'un programme qui vont s'évaluer à quelques pourcent de temps d'exécution... A mon avis, à l'heure actuelle si tu veux améliorer les perfs va falloir "inventer" un langage où les concepts de parrallèlismes seront simples à appréhender et à utiliser. Je ne parle pas de la parrallèlisation automatique qui sera toujours limités, je parle d'offrir une sémantique élégante et intuitive au programmeur. Il y a de nombreux essais, mais je n'ai pas encore trouvé de langage vraiment convaincant...

                    PS2 : J'ai déjà expliqué 5000 fois que je n'ai pas le pouvoir,
                    C'était juste une question pour savoir où ca en était... Pour la libération de LisaacOS, franchement, perso je m'en tape royalement si les outils pour le compiler ne le sont pas...
                    • [^] # Re: Le passage Mono dans le document

                      Posté par  (Mastodon) . Évalué à 2.

                      Le fait que, ces services soient pour le moment offerts sur des machines virtuelles prouvent que compiler la même chose est trop compliqué

                      Je me tue à t'expliquer qu'une plateforme comme Mono tu produits un code compilé en natif

                      Simplement produire du code natif, ce n'est pas difficile: au pire il suffit d'embarquer des bouts de l'interpréteur dans l'exécutable et pouf, tu as un programme natif. Ce qui est plus intéressant, c'est de savoir à quel point l'abstraction de la VM a été traduite et adaptée vers le niveau inférieur pendant l'opération.

                      Par exemple, si tu prends un langage comme Ruby qui te permet de rajouter des méthodes aux objets quand tu veux, ça complique beaucoup l'optimisation, parce que tu ne peux pas savoir quelles sont les méthodes d'un objet à l'avance. Tu n'auras aucun mal à produire un exécutable natif si ça t'amuse, mais tu ne gagneras pas automatiquement en efficacité, si pour conserver cette fonctionnalité tu as été obligé de n'inliner aucun appel de méthode.
                      • [^] # Re: Le passage Mono dans le document

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

                        Ce qui est plus intéressant, c'est de savoir à quel point l'abstraction de la VM a été traduite et adaptée vers le niveau inférieur pendant l'opération.
                        Sur des plateformes comme Mono, la VM a été conçu pour autoriser cette compilation, tout le code intermédiaire est donc traduisible avant exécution. l'environnement d'exécution n'est alors là plus qu'un framework sous forme de bibliothèque. Le code intermédiaire reste présent pour autoriser l'introspection, mais ce n'est plus vraiment du code exécutable, plutôt un ensemble de méta-données manipulables.

                        Par exemple, si tu prends un langage comme Ruby qui te permet de rajouter des méthodes aux objets quand tu veux, ça complique beaucoup l'optimisation, parce que tu ne peux pas savoir quelles sont les méthodes d'un objet à l'avance.
                        Effectivement, ces langages n'ont pas été prévu pour être compilé, et ont un modèle de machine virtuelle qui se prête mal à la compilation post-exécution. D'ailleur Java a le même problème, pendant de nombreuses années les JVM ont continués à interpréter le bytecode (même si la compilation JIT était de plus en plus présente), seul GCJ a réussi récemment à se passer de toute phase d'interprétation autorisant la compilation en code natif. C'est un des intérêt de Mono/.NET de proposer ce support en standard. D'ailleur certains en on profité pour en déduire que la plateforme .NET n'était pas adapté aux langages dynamiques. Elle n'a effectivement pas été conçu dans ce sens, mais ca reste possible comme le montre IronPython par exemple. D'ailleur la prochaine CLR-2 vise à mieux intégrer ces langages dynamiques.
                      • [^] # Re: Le passage Mono dans le document

                        Posté par  . Évalué à 2.

                        Simplement produire du code natif, ce n'est pas difficile: au pire il suffit d'embarquer des bouts de l'interpréteur dans l'exécutable et pouf, tu as un programme natif.

                        Pour ceux qui s'intéressent à l'aspect théorique de la construction de compilateurs à partir d'interpréteurs, voire ce lien qui parle d'évaluation partielle et surtout des différentes projections Futurama :
                        http://www.jadetower.org/muses/archives/000419.html
                        La notation utilisée est du genre Haskell, et ça fait se tordre l'esprit assez longtemps avant de capter quelque chose.
                    • [^] # Re: Le passage Mono dans le document

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

                      Pour la libération de LisaacOS, franchement, perso je m'en tape royalement si les outils pour le compiler ne le sont pas...

                      Le source généré en C est en Cecill, afin qu'il soit librement distribuable sans problèmes.
                      Je sais bien que ce sera un frein aux désirs de contribuer, mais peut être que Lisaac sera devenu libre d'ici là (ie, qu'ils auront changé d'avis).
                      Mais je pense que l'intérêt pour un OS à l'archi radicalement nouvelle et qui plus est parfaitement fonctionnel, sera quand même assez fort.

                      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

              • [^] # Re: Le passage Mono dans le document

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

                c'est pas la première fois que je te surprend à dire une connerie, et en proférant souvent moi aussi, je décèle chez toi une certaine incompréhension sur la compilation et sa théorie.


                Oui oui.

                Il y a machine virtuelle et machine virtuelle. Dans le cas qui nous préoccupe ici, Java et Mono, il s'agit d'une "vraie" machine virtuelle. C'est à dire que nous avons un programme, qui lit un espèce d'assembleur (à pile... j'en entend certain rigoler) et dispose de quelques primitives.


                Non, il n'y a pas "machine virtuelle et machine virtuelle". Il y a le concept de machine virtuelle, point. Par contre on va parler d'environnement d'exécution virtuel. Le fameux VES de la CLI de .net. L'espèce d'assembleur ça s'appelle du code intermédiaire, et c'est un point commun à toutes les machines virtuelles. Dans la théorie qui t'es chère on attache à une machine virtuelle un langage, et on empile ces machines virtuelles. Pour Mono, le langage c'est donc du CIL.

                Donc dans ce sens, le commentaire auquel tu réponds n'a pas tout à fait tord. En créant une représentation abstraite sous la forme d'un langage particulier (le fameux RTL) pour les machines basées sur des registres, gcc devient donc l'hôte d'une machine virtuelle.

                C'est d'ailleurs ce qui permet de faire de la cross-compilation si je ne m'abuse.

                Donc, même si le pseudo compilateur java produit un pseudo assembleur, il faut le traduire cet assembleur, surtout qu'il est d'assez haut niveau. Ca prend du temps, tout ça.


                Tout à fait. Ça prend du temps, ce que quelqu'un a appellé ici "le temps de chauffe".

                Un programme compilé n'a pas ce problème, l'assembleur est là, prêt à être exécuté.


                Modulo les relocations, tout à fait. Mais c'est oublié tous les avantages que fournissent les environnements modernes.

                Je pense que le futur est à une synthèse entre les deux, ou plutôt à une intégration de concepts issu de l'interprétation dans la compilation : On peut imaginer un langage dans lequel on spécifie les intervales de définition les plus probables, où l'analse de flot détecterait des fonctions souvent rappelées et peu susceptibles de donner des résultats changeant en squeezant les appels et les remplaçant par des tables de hash. OU encore, mais ça me plait moins, d'entraîner le code sur des données et de recompiler sur des statistiques (Intel le fait).


                Là on entre dans le moi je.

                Concernant la synthèse issu de l'interprétation, je n'y crois pas. On n'interprète plus vraiment quoi que ce soit. Même la JVM qui pouvait balancer entre l'interprétation et la JIT compilation ne fait maintenant presque plus que de la compilation.

                Cela dit, je pense qu'on tend vers quelque chose d'encore plus dynamique. Mais encore plus dynamique que ce qu'on a dans nos environnement d'exécution. Il y a des travaux sur les JITs pour pouvoir instrumenter le code assembleur émit pour pouvoir le regénérer en optimisant les portions les plus utilisées. Mais on va mettre ça dans les environnements d'exécution, et pas dans les langages. Sinon ça va devenir encore un langage que personne n'utilisera, un de plus.

                Bref une belle thèse de doctorat (s'il y a des étudiants en Master 2 ou 1 prometeur dans la salle, contactez moi, je ferai passer) en perspective.


                Oh moi ces trucs là j'ai arrêté à cause de la théorie que tu nous tartines.
          • [^] # Re: Le passage Mono dans le document

            Posté par  . Évalué à 2.

            "Il existe un binding Python pour GTK alors pourquoi rajouter toute une machine virtuelle complète en plus ?"

            Tu as raison et pendant qu'ils y sont pourquoi pas rajouter un interprète Perl ou Lisp. Y a vraiment que python qui mérite sa place en tant qu'interpèteur ultra-rapide dans une distrib ou un desktop.

            D'ailleurs Ironpython qui tourne sur la CLR .NET de M$ explose le python C de notre cher Guido.

            Comme quoi derrière les allergique à Java ou C# dégainent plus vite que leur ombre, quitte à réfléchir après.

            Autant j'essaie de comprendre l'argument des langages compilés mais la c'est du nimportnawak.
            Et pour les langages compilés, sachez que les VM modernes sont maintenant capable de faire de l'optim à a volée en se basant sur les statistiques à l'exécution. Chose impossible en natif. Donc les différences entre les 2 tendent à s'attenuer.
      • [^] # Re: Le passage Mono dans le document

        Posté par  . Évalué à 2.

        Ajouter une bonne grosse machine virtuelle dans Gnome

        En même temps il y a de plus en plus de programmes en python/gtk et ce n'est pas prêt de s'arrêter ....
        De plus si un dev préfère développer en Mono, c'est toujours mieux que pas de soft du tout ? A moins de croire que celui-ci aurait utilisé le C, ce qui est une illusion. Un développeur qui utilise Mono, Python ou Ruby a ses raisons propres qu'il faudrait respecter ...

        Bref l'essentiel pour Linux est d'avoir des applications desktop.
  • # Bindings

    Posté par  . Évalué à 10.

    Alors dans les bindings officiels de gnome, il y a avait:

    - Java-gnome (Java)
    - gtkmm (C++)
    - pygtk (Python)
    - gtk2-perl (Perl)

    Maintenant il y a en plus gtk# (C#).

    La belle affaire...
    • [^] # Re: Bindings

      Posté par  . Évalué à 5.

      Le problème c'est que Mono/C#... les devs risquent de vraiment l'utiliser ! [:totoz]
  • # Beuurkkk

    Posté par  (site web personnel) . Évalué à 6.

    Après avoir viré l'applet mini-commander pour la remplacer par la deskbar-applet et sa dépendance à python,

    Voilà qu'il vire l'applet pense-bête pour la remplacer par tomboy et sa dépendances à mono.

    et en plus, imposer ces mastodonde au coeur du projet GNOME :((

    Il y a des décisions qui mérite des coups de pieds au cul. Pendant que des devs s'escrime a optimiser les bibliothèques, a gagner quelques centaines de ko par ci par là, à améliorer les performances, faut toujours qu'il y en ai d'autres derrière pour rajouter un bloat gigantesque sous la forme d'une dépendances de plusieurs dizaines de Mo et 10 fois moins performants que ce qu'il remplace. juste pour être hipe et dans le buzz.
    • [^] # Re: Beuurkkk

      Posté par  . Évalué à 5.

      La méthode pour imposer mono est très Crosoftienne. D'ailleurs je ne suis pas étonné de voir que cela vienne des marionnettes et autres proxy open source de Crosoft (il paraît qu'il y en a qui doutent encore :p ).
      Le principe est simple: tu prends un composant logiciel qui marchent (sticky notes), tu le re-écrits en ajoutant 3 features à 2 balles mais avec le framework qui arrange tes affaires (tomboy)... et SURTOUT tu n'améliores pas la version qui existe en avançant des arguments coup de point, genre "je sais pas coder, alors j'utilise mono.net!". Résultat, tu fais dégager une appli qui marche et tu imposes ton framework... magie!

      En plus, beaucoup occultent le côté promotion du logiciel libre dans les entreprises.
      Dans une grosse entreprise, disons que tu veux "vendre" (et oui... il faut bouffer un jour) du desktop libre... bin avec mono dans gnome tu te retrouves sur le terrain technique où Crosoft est leader dans l'esprit des décideurs (.NET=Crosoft, JAVA=Sun)... résultat, tu donnes un paquet de billes pour te faire orbitaliser par les commerciaux de Crosoft... mais ça, j'ai l'impression que peu de gens comprennent.

      Sérieux, si on doit choisir un framework, lourd, lent, inutilement complexe, c'est-à-dire du bloat, pour développer une application, pourquoi s'embêter avec ceux qui posent des pbs juridico-stratégico-commercio-andco? En plus ces derniers n'apportent rien de significatif par rapport à leur alter-ego à part ces derniers pbs et ils sont bien plus dans l'esprit d'une évolution et d'un développement "à la libre" (et oui, le libre ça n'est pas que des licences...).

      Perso, tant que gnome est packagé de telle manière que je ne suis pas forcé d'installer mono (dans les distros les plus répandues), ça ne me gène pas que le Novell Blog System s'énerve tout seul dans son coin avec son morceau de desktop gnome officiel. J'utiliserai gedit ou le stick notes qui sera peut-être maintenus par d'autres.
      • [^] # Re: Beuurkkk

        Posté par  . Évalué à 0.

        les problemes juridiques de brevets sur mono (hormis ceux de l'api, bien evidemment) touchent aussi python/perl/ruby/java.

        ya pas de raison, une vm ca reste une vm et tout le monde utilise en gros les meme technos.
        Donc si ca touche .net ca touche les autres aussi.
        • [^] # Re: Beuurkkk

          Posté par  (Mastodon) . Évalué à 2.

          À part au niveau des concepts, je doute que l'implémentation d'un interpréteur ruby ressemble beaucoup à une JVM, et un brevet qui s'attaque aux deux serait probablement trop générique pour être dangereux.

          Dans le cas de Mono, ce qui fait peur à beaucoup de gens c'est que MS a breveté des morceaux de .NET, donc il y a des chances pour que ces brevets là s'appliquent aussi à Mono.
  • # Forte dépendance ou dépendance relative ?

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

    En dehors de tous les problèmes très intéressants soulevés ci-dessus, il y a une question qui n'a pas été vraiment posée il me semble. Dans quelle mesure gnome va-t-il reposer sur Mono ?

    En effet, tant que le coeur du système reste en C/C++ et que le seul problème soit que les nouvelles killer-apps (genre beagle) utilisent Mono, il me semble que l'ampleur des dégats est toute relative. Cela signifie juste pour moi (qui ait une petite conf.) que j'installerai pas ces killer-apps. Si je suis pas seul, y'a des chances pour que des dev. se mettent à porter des (bouts de) killer-apps en C/C++ car ils les veulent sans Mono.

    Par contre, si l'objectif c'est d'utiliser Mono comme langage de référence pour implémenter le coeur de Gnome (par exemple recoder nautilus en Mono), là c'est un peu plus génant.
  • # Il est temps de passer à e17

    Posté par  . Évalué à 3.

    Et oui ici tout est fait pour la performance. C'est léger et très bien fichu. vivement la sortie officielle !!!
    • [^] # Re: Il est temps de passer à e17

      Posté par  (Mastodon) . Évalué à 4.

      Quand je pense que du temps de ma prime jeunesse, enlightenment était synonyme de gros truc lourd bourré de trucs jolis, mais inutilisable sur une machine "bon marché"... =)
    • [^] # Re: Il est temps de passer à e17

      Posté par  . Évalué à 5.

      Vu l'avancement de ces dernieres annees, il y a de bonnes chances que la sortie officielle se produise au moment ou j'atteindrai l'age de la retraite.

      C'est pratique, au moins ca m'occupera pendant un petit moment.

Suivre le flux des commentaires

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