TImaniac a écrit 6420 commentaires

Amusant, quand on voit les bindings python et C# (par exemple).
Tu vas rire, même que y'a 30 ans, y'avait le même débat entre le C et l'assembleur, heuresement les mentalité évoluent avec les technologies, des arguments pertinents y'a 10 ans ne le sont plus forcement aujourd'hui.
Moi je parlais de la philosophie, qui est pour les développeurs, je cite la fondation Gnome :
"GNOME gives developers the greatest licensing flexibility and the greatest variety of programming languages."
( http://www.gnome.org/about/why.html )

Ce que j'adore avec toi, Timaniac, c'est que tu ne fais que répéter servillement la propagande de De Icaza.
Je n'ai jamais lu de texte où Icaza parlait de l'OpenInitiativeNetwork. Juste suivi (par pure investigation personnelle) l'actualité autour des brevets de Mono, et notamment la création de l'OIN qui a finalement décider RedHat (le dernier à ne pas inclure Mono) a l'accepter. Si toutes les distributions Linux soutenus par des entreprises ayant un service juridique ont inclu Mono (alors que certaines distri n'incluent pas certains softs pour des raisons de brevet), c'est bien qu'il n'y a pas plus de danger qu'avec un autre soft (je dis pas que y'a aucun danger !)

Je peux donc te donner moi aussi une information vérifiable : Microsoft possède au moins trois brevets sur l'API de .NET
Et ? Moi j'ai pointé des informations également vérifiable : l'OIN a toutes les cartes pour défendre Mono, notamment des brevets clés sur les web-services.

On sait aussi que Sun va mettre son JDK sous une licence open source, ce qui clôt le débat.
Oué ca fait 10 ans qu'ont a des rumeurs comme ca. On attend toujours de savoir sous quelle licence et quand. En attendant Wait&See. De toute façon je n'ai absolument rien contre Java, et des bindings pour Java dans Gnome ne me gène pas le moindre du monde, au contraire ! (Loin de moi l'idée de vouloir lancer un troll Mono vs Java ici)

Je termine par un peu de pub (honte à moi) : j'ai écris un nouveau pavé sur la situation juridique de Mono (et de Java)
Je suis heureux de l'apprendre ! Je trouvais vraiment dommage que ton article servait toujours de référence alors qu'ils manquaient les principales informations (plus récentes que l'article) qui changeaient complètement la donne.

Enfin tout ca pour dire que l'OIN protège Mono, mais protège aussi de nombreuses parties de Linux (et les softs libres qui gravitent autour comme Python), comme quoi eux aussi pose(aient?) de nombreux problème liés aux brevets. Bref Mono n'est pas un cas particulier et est autant en danger/sécurité que la plupart des technos/softs libres.

Enfin au final j'ai du mal à capter ce que tu me reproches vu que je ne trouves aucune contradiction avec ce que tu dis.

KDE 4 arrive et il n'y aucune incertitude juridique qui assombrit son code
Dire sans cesse qu'il y a des incertitudes avec Mono, on peut voir ca comme ca d'après Wikipedia :
"Un FUD (de l'anglais Fear Uncertainty and Doubt, c'est-à-dire peur, incertitude et doute) est une technique classique de désinformation basée sur le schéma suivant :
Installer le doute,
en s'appuyant sur la peur
au moyen d'informations non vérifiables (incertitude)."
Bon alors moi je vais faire pareil : je suis sûr que KDE viole de nombreux brevets, il y a clairement là un risque juridique. Voilà, je ne te donne aucune information vérifiable.
Par contre je peux te donner une information vérifiable : Mono est protégé par l'OpenInventiveNetwork qui est soutenu par des petits acteurs comme Novell, RedHat ou encore IBM et Philips.
Moinssez moi si vous voulez vu que ca fait 100 fois que je me répète, mais bon, y'en a qui FUD pour la 100ème fois, c'est de bonne guerre :)

Si Tomboy a une ou deux fonctions en plus alors pourquoi ne pas améliorer plutôt Sticky Notes ?
Ca fait 10 plombes que les débats autour des applis GTK# existent, pourtant personne n'a eu envi de modifier sticky notes. Quelqu'un l'aurait fait, la question ne se saurait pas poser, mais visiblement ca ne faisait bander personne de rentrer dans le code. Si ca se trouve les "quelques fonctionnalités" supplémentaires demandait une refonte totale de sticky, bref si ca se trouve ca aurait été plus simple de tout recommencer.

C'était bien la peine que les devs de Gnome du début bavent sur Qt et KDE et affirment que le C c'était ce qu'il y a de mieux.
Ben oué, et ils avaient raisons : le C est un langage qui s'interface très bien avec de nombreux langage (mieux que le C++ en tout cas) : on fait tout le framework de base en C et on offre de nombreux bindings aux développeurs d'applications desktop. GTK# n'est qu'un binding de plus, y'a déjà de nombreuses applis en Python ou C++ dans Gnome, sans que la philosophie est changée.

Rien de pire que d'etre dépendant d'une application propriétaire qui n'avance pas avec son temps
Toutafé. Mais plutôt que de leur râler dessus pour qu'ils tiennent compte des 1% d'utilisateur potentiel, on ferrait mieux de plancher sur une alternative non ?

Y'a un mini serveur standalone qui se lance dans le répertoire de l'appli web en ligne de commande, sinon c'est Apache ou Apache2.
Si t'as besoins d'infos n'hésites pas à me contacter ;)

Fais de l'ASP.NET avec Mono sous Linux, ca correspond à ce que tu décris : on code l'application comme on code une application Desktop :

pour l'appli Desktop :
using System.Windows.Forms;
...
Button b = new Button();
b.Text = "OK";
this.Controls.Add(b);
Label label = new Label();
label.Text = "ceci est un label";
this.Controls.Add(label);

pour l'appli web :
using System.Web.UI.WebControls;
...
Button b = new Button();
b.Text = "OK";
this.Controls.Add(b);
Label label = new Label();
label.Text = "ceci est un label web !";
this.Controls.Add(label);

Après il y a des nuances et des contrôles différents, mais globalement la technique est la même, on ne touche pas au code HTML, c'est les contrôles qui se charge de le générer comme ils l'entendent, en fonction du navigateur (Mozilla, IE ou téléphone mobile etc.)

Bref de la vraie programmation objet, uné véritable séparation entre code HTML et le reste, dans un cas ca génère un client lourd, dans l'autre du code XHTML strict et compliant, et sous Windows tu as un designer pour faire tes appli web de la même manière que tes appli lourdes.

C'est que du bonheur.

C'est le syndrôme habituel du "cestpaslibredonccestinutile". Le jour où y'aura une techno équivalente libre et tout le tralala, hop on va t'annoncer un boulversement interplanétaire qui révolutionner ta vision du grand 'ternet.
Moi on m'a même sorti une fois quand je disais que sous Nux ce qui me faisait chier c'est que y'avait pas beaucoup de jeux : "oué mais les jeux c'est futile, c'est juste bon à t'occuper le cerveau et te piquer tes sous" "...".
Flash c'est une techno comme une autre, dans certains cas c'est pertinent de l'utiliser, dans d'autres cas non. Après évidemment y'a toujours le problème que capucpaslibre, mais je ne lui connais pas d'équivalent libre (et qu'on me parle pas des animations SVG merci :) )

Pour info :
- IronPython vise à intégrer dans .NET/Mono la syntaxe, les API de base et le comportement de Python afin d'être compatible au maximum avec le CPython officiel, tout en offrant l'accès aux API du framework .NET/Mono.
- Boo est plutôt un nouveau langage inspiré de la syntaxe de Python et tirant parti de toutes les possibilités du framework .NET/Mono.

ils se foutent de nous clubic (et les autres médias)
-> les fichiers qu'on peut déplomber, faut déjà les avoir achetés...
Euh, Clubic ne se fou de personne, c'est toi qui a "oublié" de citer la phrase clé plus haute dans le texte :
"Le logiciel est capable d'éradiquer la protection PlaysForSure, utilisée par bon nombre de services de vente de musique en ligne et particulièrement par ceux qui proposent des abonnements locatifs illimités."
En gros le mec il peut désormais s'abonner un mois, télécharger l'intégral des morceaux proposés, et au lieu de ne plus pouvoir les écouter à la fin de son abonnement, ben il il peut quand même. D'où je suppose l'utilisation du terme "pillage".

Maintenant il faut relativiser, il me semble que ce logiciel de anti-DRM ne fonctionne pas avec la version 9 des codecs (pas du player), qui est la plus utilisée par les marchands en ligne (si je ne m'abuse).

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.

Ben à mon avis ils vont faire comme SuSE ou RedHat : vendre du support. Le fait d'avoir fait une version serveur d'Ubuntu et d'annoncer un support de plusieurs années va dans ce sens. Quand ils disent qu'ils vont devoir passer de quelque chose de complètement communautaire à un modèle plus commercial, c'est qu'ils vont devoir s'impliquer et prendre des responsabilités du point de vue de leurs futurs clients, et ne vont donc pas pouvoir sans arrêt dire "ah oué mais là faut demander au projet bidule de faire un patch".

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...

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...

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.

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.

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.

ou à garder plusieurs interfaces en parallèle, et du coup ceux qui utilisent une ancienne ne profite pas des améliorations des nouvelles interfaces.
Euh, je vois pas en quoi il est impossible de garder le support de l'ancienne interface tout en migrant les drivers qui peuvent l'être vers la nouvelle. Quand l'ancienne interface ne peut vraiment plus être supportée, cela ne doit pas se faire tous les 6 mois.
Bref, il est tout à fait possible de garder une compatibilité sans pour autant freiner les évolutions, c'est bidon comme argument de prétendre que compatibilité s'oppose à évolution.

Je vais reprendre encore mon cas perso, mais fut un temps, mon entrée tuner TV marchait (avec des pilotes libres et tout), et un jour, pouf, amarche plus. Le driver n'a plus le même comportement suite à une évolution. Youpi, je peux même pas garder l'ancien driver. Où est l'avantage et l'intérêt pour le end-user ?
Alors l'excuse de "oué on veut forcer à migrer vers la nouvelle interface" c'est pipo : ca fait chier le end-user que je suis, car au final tout n'est pas migrer, et on pert le support d'une partie du matos. Génial.

Sous linux tu peux créer un exécutable qui "embarque" mono et les dépendances dans un même binaire.
Sous Windows, tu peux lancer avec un double click les exécutables créé avec GTK#, mais il faut pour cela installer le GTK# installer for windows disponible sur le site de novell. Sinon c'est un exécutable windows normal. De plus généralement on aime bien faire sous Windows une GUI à base de WinForms qui tournent nativement sous Windows (avec le framework .NET)

mais il me semble que le C# se compile en CLI et pas en natif , non ?
Oui, le compilateur C# compile en visant la CLI, mais l'environnement d'exécution mono se charge ensuite de compiler ce nouveau code en code natif, soit au dernier moment juste avant l'exécution, soit à la demande.
Oui, ca fonctionne sur Mac.
c'est pas aussi chiant sur certains points? (j'aimais pas swing , j'aimais pas la gestions des fichiers , j'aimais pas les listener pour les UI)
Ben y'a plusieurs toolkit graphiques, après tu utilises celui qui te plaît le mieux : GTK, Cocoa (pour mac), WinForms, wxWidget, Qt, etc.
j'aimais pas les listener pour les UI
En C# y'a la notion d'événement, qui revient à faire des listeners mais à mon sens en plus efficace et sans la lourdeur de la mise en place d'interface pour les listeners.

Quel intérêt de me moinsser ? C'est si inutile que ca de citer une solution parmis d'autre surtout quand elle semble répondre à tous les besoins ?
Alors ok, je vais reprendre les points 1 par 1 :
Du Natif : mono utilise un modèle d'environnement d'exécution basé sur une compilation native à la volée ou même à l'avance.
De la Vitesse : C'est plus rapide que Python, mais c'est pas aussi rapide que du C.
De la Legereté : le Hello world fait environ 3Ko.
De la Productivié : c'est subjectif, mais c'est à mon goût plus productif que Java. (je parle du langage et de son framework, pas des outils/IDE associés)
Orienté Objet : c'est purement objet (modèle classique classe/instance)
Pas de pointeur : existe, mais juste pour des cas particulier d'optimisation, bref on peut très bien s'en passer, et j'ai encore vu personne les utiliser. C'est plus un "bonus" qu'un truc qui fait peur.

Ben mono/C#.
Répond à tous les critères à priori.

Tu utilises quel version (distribution) de linux ? Mandriva ? Debian ? Ubuntu ?

Clap clap clap :) Tu peux repasser ton brevet des collèges, te voilà incollable en physique et en math !

Ou est la tension ?
Ben tu viens d'en donner la définition :)
P = UI. (puissance = tension * intensité).