Journal Utiliser Mono sans peur

Posté par patrick_g (site web personnel) le 07 juillet 2009 à 12:20.

Étiquettes :

juil.

2009

Mono, l'implémentation libre du framework .NET de Microsoft, a toujours été un projet controversé au sein du monde libre.
Diverses choses peuvent lui être reproché mais la principale est le risque de procès du fait des brevets logiciels détenus par Microsoft.

Richard Stallman a récemment mis en garde les utilisateurs de logiciels libres en leur disant (en substance) que si ils basaient tous leurs développements sur Mono alors Microsoft aurait un pouvoir de nuisance extraordinaire sur l'écosystème du libre.
Un simple procès "à-la-Tom-Tom" pour infraction à la législation sur les brevets (US) provoquerait un séisme si énormément de logiciels se basent sur Mono et sont donc tous simultanément impactés.

RMS conseille donc de ne pas se baser sur le framework Mono : "Si nous perdons un jour le droit d’utiliser C#, nous perdrons également ces applications".

Grande nouvelle : Il semble que Microsoft se soit enfin décidé à faire ce que réclament les opposants à Mono depuis des années c'est à dire à garantir de ne pas attaquer juridiquement les implémentations libres !!!!

L'annonce a été faite ici par Peter Galli (qui est emplyé de l'équipe Open Source de Microsoft et chargé des relations avec la communauté).
En résumé Microsoft s'engage, pour le standard ECMA-334 (C#) et pour le standard ECMA-335 (CLI) auprès de la communauté. Ils font la promesse irrévocable de ne pas faire de procès pour violation de brevets aux diverses implémentations de ces standards.
Cette promesse s'effectue par le biais du Microsoft Community Promise qui est un texte qui indique que les technologies placées sous ce régime ne seront pas l'objet de procès pour violation de brevets :

"Under the Community Promise, Microsoft provides assurance that it will not assert its Necessary Claims against anyone who makes, uses, sells, offers for sale, imports, or distributes any Covered Implementation under any type of development or distribution model, including open-source licensing models such as the LGPL or GPL."

Tout est donc magnifique dans le meilleur des mondes possibles et Miguel de Icaza, le papa de Mono, s'est empressé de relayer la nouvelle sur son blog.

Pour tempérer quelque peu la joie des monophiles il faut toutefois préciser, et Miguel le reconnait lui-même, que Mono c'est bien plus que C# et le CLI.
Il annonce que dans les mois qui viennent le code source de Mono va être réorganisé afin de bien séparer ce qui est couvert par le Community Promise de Microsoft et ce qui ne l'est pas :
"Astute readers will point out that Mono contains much more than the ECMA standards, and they will be correct.
In the next few months we will be working towards splitting the jumbo Mono source code that includes ECMA + A lot more into two separate source code distributions. One will be ECMA, the other will contain our implementation of ASP.NET, ADO.NET, Winforms and others."

Est-ce que les fameux supers logiciels indispensables au libre et basés sur Mono (F-Spot, Gnome Do, Tomboy, etc) marchent en utilisant seulement C#+CLI ou est-ce qu'ils nécessitent d'autres trucs ? Je ne sais pas, je pose juste la question.

En définitive cette annonce est donc une bonne nouvelle même si, à mon humble avis, le libre n'a pas "besoin" de Mono. Que ce soit avec Qt/C++ et ses bidings ou avec GTK+/C et ses bidings (plus Vala) ou encore avec Java il y a pléthore de solutions puissantes et pratiques pour développer des logiciels libres. Que Mono s'ajoute marginalement à ces solutions depuis que le risque brevet semble s'éloigner, très bien. Mais l'exemple de Gnote a montré qu'il n'était nul besoin de ce gros framework bloaté pour développer un logiciel. Que ce soit en rapidité ou en consommation mémoire il n'y a pas photo et l'écart est impressionnant => http://jeff.ecchi.ca/blog/?p=874

Et puis n'oublions pas qu'accepter d'utiliser Mono c'est accepter de renforcer le standard logiciel de la firme qui reste l'adversaire numéro un du libre.

# YaST, Java, Mono..

Posté par Spyhawk le 07 juillet 2009 à 12:32. Évalué à 2.

Encore la mort d'un troll. Saluons l'effort de Microsoft pour mettre à mort le FUD Mono.

Je n'utilise pas Mono, mais c'est bon de voir un langage de programmation alternatif être utilisable librement dans un projet libre.

Farvadin : Tu peux changer ta signature :]
- [^] # Re: YaST, Java, Mono..
  
  Posté par rewind (Mastodon) le 07 juillet 2009 à 12:37. Évalué à 10.
  
  Ce n'est pas la mort d'un troll, au contraire, il va pouvoir continuer à vivre. Parce que, comme dit et répété dans le journal, Mono c'est beaucoup plus que C#+CLI. La partie importante de Mono, c'est quand même l'implémentation des API MS et c'est là que ça coince. Parce que tant qu'on n'utilise que Mono en tant que VM d'un langage et qu'on n'utilise pas les API MS (par exemple Gtk# à la place de Winforms), tout va bien. Mais combien font ça ? Et est-ce bien utile quand on voit Java, C++/Qt, C/Gtk/Vala ? C'est ça la vraie question...
  
  Bref, une clarification qui n'apporte pas grand chose à mon avis.
  - [^] # Re: YaST, Java, Mono..
    
    Posté par Alice (site web personnel) le 07 juillet 2009 à 16:04. Évalué à 9.
    
    Moi, je trouve qu'on perd beaucoup de temps à utiliser des technologies propriétaires et/ou sur lesquelles les grandes boîtes ont des brevets et tout, alors qu'il existe des bons outils développés par la communauté comme Python ou Ruby.
    
    Pourquoi s'embêter à utiliser C# alors qu'on sait pertinemment que c'est jouer avec le feu?
    - [^] # Re: YaST, Java, Mono..
      
      Posté par TImaniac (site web personnel) le 07 juillet 2009 à 16:06. Évalué à -3.
      
      Si nos ancètre n'avaient jamais eu les couilles de jouer avec le feu, je sais pas où en serait la civilisation aujourd'hui.
      - [^] # Re: YaST, Java, Mono..
        
        Posté par JoeltheLion (site web personnel) le 07 juillet 2009 à 16:07. Évalué à 10.
        
        Ouais enfin comparer le degré d'innovation de mono et l'invention du feu, c'est un peu osé je trouve...
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par TImaniac (site web personnel) le 07 juillet 2009 à 16:15. Évalué à -3.
        
        A peu prêt aussi osé que de comparer le risque qu'il y a à utiliser F-Spot par rapport au fait de jouer avec un bûcher.
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par JoeltheLion (site web personnel) le 07 juillet 2009 à 16:17. Évalué à 4.
        
        Comparaison que personne n'a faite.
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par Camille_B le 07 juillet 2009 à 16:18. Évalué à 1.
        
        Je cite, un tout petit peu plus haut :
        
        «Pourquoi s'embêter à utiliser C# alors qu'on sait pertinemment que c'est jouer avec le feu? »
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par Alice (site web personnel) le 07 juillet 2009 à 16:27. Évalué à 1.
        
        Je ne parlais pas du côté innovant de C# (ce n'est d'ailleurs pas la seule innovation qui existe dans le monde de la programmation), mais du côté risque juridique et liberté. Si on veut que son code soit toujours libre, accessible à tous, modifiable et tout, faire du C# n'est pas le meilleur moyen amha.
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par Guillaume Denry (site web personnel) le 08 juillet 2009 à 10:52. Évalué à 4.
        
        Dans le premier cas, c'est une tournure de phrase rentrée dans le langage commun pour désigner un risque important, dans le second cas, c'est une vraie comparaison avec le vrai feu. Mouais.
    - [^] # Re: YaST, Java, Mono..
      
      Posté par Octabrain le 07 juillet 2009 à 16:13. Évalué à 0.
      
      C'est vachement futé de démarrer exactement le même thread ("pourquoi c# ?") à plein d'endroits différents...
      - [^] # Re: YaST, Java, Mono..
        
        Posté par zebra3 le 07 juillet 2009 à 17:03. Évalué à 6.
        
        C'est normal, c'est une caractéristique du libre : multiplier les efforts.
        C'est comme créer pleins de langages qui ont le même but :-)
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
- [^] # Re: YaST, Java, Mono..
  
  Posté par JoeltheLion (site web personnel) le 07 juillet 2009 à 12:47. Évalué à 9.
  
  le FUD Mono.
  
  Maintenant que l'histoire semble s'achever, j'aimerais bien que les gens qui prétendaient qu'il n'y avait pas de problème avec mono m'expliquent pourquoi cette "promesse" de microsoft est nécessaire?
  - [^] # Re: YaST, Java, Mono..
    
    Posté par 2PetitsVerres le 07 juillet 2009 à 12:50. Évalué à 10.
    
    à cause des gens qui disaient qu'il y avait un problème ?
    Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
  - [^] # Re: YaST, Java, Mono..
    
    Posté par pasBill pasGates le 07 juillet 2009 à 15:02. Évalué à -2.
    
    Ces gens ont toujours dit que Mono avait le meme risque que le kernel Linux, OpenOffice, etc... parce que MS avait des brevets partout et tout etait donc a risque
    
    et c'etait vrai.
    
    Maintenant, si tu utilises Mono sans les APIs MS, tu as MOINS de risques qu'en utilisant le kernel, OpenOffice, ... car MS a promis de ne pas attaquer les implementations de C# et CLI
    - [^] # Re: YaST, Java, Mono..
      
      Posté par B16F4RV4RD1N le 07 juillet 2009 à 15:21. Évalué à 8.
      
      À Spyhawk et aux autres, je vais reprendre mon commentaire posté dans un autre fil :
      
      http://linuxfr.org/comments/1046581.html#1046581
      
      (et au niveau de ma signature, je peux quand même la garder, car c'est valable pour beaucoup d'autres choses également, et puis les dalles brillantes c'est toujours aussi moche et nul)
      
      Bref, utiliser Mono :
      
      1/ Cela reste quand même une technologie microsoft. En encourageant mono, on encourage la technologie d'une société qui a toujours voulu détruire le libre en général, et linux en particulier (et qui continue à le faire de manière particulièrement déloyale, cf les "get the facts" et autres annonces sans preuves comme quoi linux viole des brevets microsoft)
      
      2/ Cela vient juste d'arriver. Heu non, en fait c'est marqué "will be", donc c'est encore en cours. On attend de voir l'annonce finale. Et cela met à mal les affirmations qu'il n'y avait aucun problème avant.
      
      3/ De plus ce point me fait un peu tiquer, mais j'ai peut-être mal compris :
      
      http://www.microsoft.com/interop/cp/default.mspx
      
      Q: What if I don’t implement the entire specification? Will I still get the protections under the CP?
      
      A: The CP applies only if the implementation conforms fully to required portions of the specification. Partial implementations are not covered.
      
      Donc déjà cela se semble pas couvrir un fork éventuel, et ne peut être considéré comme libre vu qu'il ne semble pas possible de faire un produit dérivé sans risquer de ne plus être protégé. Bref, dans le meilleur des cas, cela reste un freeware.
      
      D'autre part ce genre de clause me donne envie de continuer à FUDer, en imaginant par exemple que MS pourra attaquer à un moment ou un autre tous les projets utilisant mono, parce qu'il manque tel ou tel autre truc et donc peut être considéré comme une implémentation partielle non couverte par leur "community promise"
      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
      - [^] # Re: YaST, Java, Mono..
        
        Posté par pasBill pasGates le 07 juillet 2009 à 15:27. Évalué à -3.
        
        1) Ca c'est purement politique, c'est un peu comme dire "Je vais pas utiliser Gnome car c'est De Icaza qui l'a ecrit et j'aimes pas le Bresil"
        
        2) Personne n'a jamais dit qu'il n'y avait pas de problemes avant, on a toujours dit que Mono n'avait pas plus de problemes que les autres, pas qu'il n'y en avait pas. Le plus drole est que maintenant Mono a MOINS de problemes que les autres.
        
        3) ODF est traite exactement de la meme maniere par IBM. Bref, evites OpenOffice si ca te pose un probleme...
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par tanguy_k (site web personnel) le 07 juillet 2009 à 15:43. Évalué à 6.
        
        1) Ca c'est purement politique
        
        Et cela en fait il un argument non valide ?
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par pasBill pasGates le 07 juillet 2009 à 15:48. Évalué à 4.
        
        Non, mais c'est tout autre chose que dire "je le fais car c'est dangereux", "je le fais car c'est techniquement inefficace", ...
        
        Bref, ca devient une question de gouts et de couleurs plutot qu'une question de qualites et de rapport risque/benefice.
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par tanguy_k (site web personnel) le 07 juillet 2009 à 16:17. Évalué à 8.
        
        une question de gouts et de couleurs
        
        Ouai enfin la tu minimises toute la portée politique du mouvement du logiciel libre. Une bonne partie des gens qui contribuent au libre, le font aussi de facon politique, parcequ'ils ont une vision de ce que devrait être le logiciel.
        Strategiquement/politiquement parlant c'est quand meme hyper dangereux de reposer sur des technologies de Microsoft qui est clairement le plus grand ennemi du libre. patrick_g l'a deja tres bien expliqué http://linuxfr.org/comments/1044678,1.html
        
        De plus cette annonce de MS sur .NET et les brevets contient quelques "mais" qui sentent l'entourloupe à 3km
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par pasBill pasGates le 07 juillet 2009 à 16:24. Évalué à -3.
        
        Strategiquement/politiquement parlant c'est quand meme hyper dangereux de reposer sur des technologies de Microsoft qui est clairement le plus grand ennemi du libre. patrick_g l'a deja tres bien expliqué http://linuxfr.org/comments/1044678,1.html
        
        Cela n'a rien de dangereux, ca peut etre embarrassant, genant, etc... mais il n'y a pas de danger.
        
        De plus cette annonce de MS sur .NET et les brevets contient quelques "mais" qui sentent l'entourloupe à 3km
        
        Il n'y a pas plus de mais que ce qu'IBM fait avec ses brevets sur ODF, ce qui n'a visiblement jamais gene qui que ce soit.
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par Alice (site web personnel) le 07 juillet 2009 à 16:33. Évalué à 5.
        
        Si, il y a du danger, du danger juridique. On ne vit pas dans un monde de bisounours. Tu peux développer un truc un jour, et le lendemain, on te dit que tu n'as pas le droit de le mettre sous telle ou telle licence, ou que tu dois payer des royalties à quelqu'un, voire même que tu dois arrêter ce que tu fais. C'est un danger qui peut être sacrément grand, si tu es sur un grand projet.
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par pasBill pasGates le 07 juillet 2009 à 16:39. Évalué à 1.
        
        La mise sous l'OSP de C# et CLI enleve justement ce risque juridique, donc non, il n'y a pas de danger juridique.
        
        Alors effectivement, tu peux te mettre en danger en utilisant une librairie qui n'est pas protegee, mais ca c'est la meme chose quel que soit le langage.
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par TortuXm le 07 juillet 2009 à 17:10. Évalué à 5.
        
        Sauf que l'OSP ne s'applique que si Mono implémente complètement et exclusivement la partie ECMA de .NET, c'est bien ça ?
        
        Ca voudrait donc dire que si Mono embarque Gtk# ou d'autres technos Gnome portées sur .NET, Mono en entier n'est pas couvert par l'OSP.
        
        Comme il est dit dans la dépêche, ils vont donc séparer Mono en deux, l'autre partie sera donc non couverte par l'OSP et aussi vulnérable qu'elle pouvait l'être avant (que cette vulnérabilité soit avérée ou non). Donc pas de WinForms, pas de Gtk#, pas de.... .NET est-il toujours intéressant sous Linux dans ce cas ?
        
        Le fait que Microsoft pose de telles conditions peut indiquer qu'ils comptent attaquer ceux qui sont en dehors de son OSP, sinon, pourquoi poser de telles conditions ?
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par pasBill pasGates le 07 juillet 2009 à 17:14. Évalué à -1.
        
        Ca voudrait donc dire que si Mono embarque Gtk# ou d'autres technos Gnome portées sur .NET, Mono en entier n'est pas couvert par l'OSP.
        
        Si Mono decide d'embarquer OpenOffice et qu'OpenOffice a des problemes, c'est un probleme dans OpenOffice hein.
        
        Si Gtk# est un probleme, ca veut dire que Gtk est un probleme.
        
        Si Gtk est un probleme, je te suggeres d'arreter d'utiliser Linux, car il restera pas grand-chose d'utilisable...
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par Moonz le 07 juillet 2009 à 18:00. Évalué à 4.
        
        > Si Gtk est un probleme, je te suggeres d'arreter d'utiliser Linux, car il restera pas grand-chose d'utilisable...
        Tant qu’il reste Emacs, tout le reste est superflu :)
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par pasBill pasGates le 07 juillet 2009 à 18:07. Évalué à 2.
        
        C'est bien ce que je dis, utilises un autre OS, dans ce cas-ci, Emacs.
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par totof2000 le 07 juillet 2009 à 20:01. Évalué à 2.
        
        Si Gtk est un probleme, je te suggeres d'arreter d'utiliser Linux, car il restera pas grand-chose d'utilisable...
        
        Tiens c'est bizarre, ici au taf j'ai plein de machines Linux qui n'ont pas de GTK installé .....
        
        Chez moi c'est pareil ....
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par pasBill pasGates le 07 juillet 2009 à 20:17. Évalué à 1.
        
        C'est donc que, comme je l'ai dit, tu n'a pas grand-chose sur tes machines.
        
        Enormement d'applis avec GUI dependent de Gtk, il reste alors Qt, mais entre le noyau, les fs, les systemes graphiques, ... qui sont tous sacrement importants pour l'utilisation du systeme, tu crois vraiment que seul Gtk serait un probleme niveau brevets ?
        
        Le jour ou MS poursuirvra un gros truc comme Gtk, tous les gros projets libres se mettront a trembler tres tres fort, car ils savent que plusieurs d'entre eux seront aussi sur la liste probablement.
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par totof2000 le 07 juillet 2009 à 21:32. Évalué à 4.
        
        C'est donc que, comme je l'ai dit, tu n'a pas grand-chose sur tes machines.
        
        N'importe quoi. J'ai plein de serveurs qui ont des tas de trucs qui tournent sans interface graphique. Et chez moi je n'utilise aucune appli GTK.
        
        Enormement d'applis avec GUI dependent de Gtk, il reste alors Qt, mais entre le noyau, les fs, les systemes graphiques, ... qui sont tous sacrement importants pour l'utilisation du systeme, tu crois vraiment que seul Gtk serait un probleme niveau brevets ?
        
        Quel est le rapport avec le sujet ? On parle du fait que sans GTK il n'y a rien ... pas des brevets. Ne mélange pas STP. Certes GTK est utilisé par beaucoup d'applis mais on peut s'en passer.
        
        Le jour ou MS poursuirvra un gros truc comme Gtk, tous les gros projets libres se mettront a trembler tres tres fort, car ils savent que plusieurs d'entre eux seront aussi sur la liste probablement.
        Je ne crois sincèrement pas que MS poursuivra un truc comme GTK. Puis d'abord ils poursuivraient qui ? Ensuite le retour de bato de la part d'autres monstres de l'informatique (IBM par exemple) serait quasi immédiat. Et je ne pense pas non plus que Ms poursuivra un projet comme Mono. Le but a mon avis pour MS c'est que les devs du libre le "suivent". Tant que des crétins seront occupés à réimplémenter un truc comme Mono, ils passeront moins de temps à inventer un nouveau truc ....
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par zebra3 le 07 juillet 2009 à 18:07. Évalué à 2.
        
        En même temps, GTK# n'implémente rien du tout de .Net, donc pas de danger de procès de la part de Microsoft, non ?
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par benoar le 07 juillet 2009 à 17:17. Évalué à 2.
        
        Cela n'a rien de dangereux, ca peut etre embarrassant, genant, etc... mais il n'y a pas de danger.
        Oui enfin pour l'instant, ceux qui disent qu'il n'y a pas de danger sont :
        1) des responsables de Microsoft
        2) un employé de chez Microsoft
        3) des devs de chez Novell qui ont signé un contrat avec et ont filé de la thune à Microsoft
        
        Bref, le jour ou quelqu'un d'un peu plus neutre aura un avis positif sur la question, on y réfléchira.
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par Camille_B le 07 juillet 2009 à 17:19. Évalué à 4.
        
        Je crois en avoir croisé quelques uns ici-même. Ce sont tous des employés secrets de chez Microsoft ?
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par Alice (site web personnel) le 07 juillet 2009 à 17:31. Évalué à 5.
        
        Non mais peut-être des gens qui s'intéressent d'abord à l'aspect technique du logiciel, avant l'aspect logiciel libre ?
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par pasBill pasGates le 07 juillet 2009 à 17:34. Évalué à 1.
        
        Ou alors des gens qui s'interessent aux deux aspects et qui n'ont pas cette phobie de MS que bcp ont.
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par Alice (site web personnel) le 07 juillet 2009 à 17:53. Évalué à 10.
        
        Ce n'est pas une phobie sans raison. Non, Microsoft n'est pas le "Grand Vilain" quoi qu'il fasse. Mais les gens n'en veulent pas à Microsoft sans raison. Microsoft crache sur les logiciels libres, l'intéropérabilité et les standards depuis des années, et abuse de sa position dominante; et tous les moyens sont bons.
        
        Je pense que se méfier de Microsoft, quand on fait du logiciel libre, est assez légitime. Un peu comme se méfier de Monsanto quand on fait de l'agriculture bio.
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par pasBill pasGates le 07 juillet 2009 à 18:06. Évalué à -1.
        
        Mais les gens n'en veulent pas à Microsoft sans raison. .
        
        Moi je constate simplement que les recriminations, supputations, ... contre MS sur ce site sont dans leur grande majorite completement fausses. Bref, les raisons valables de se mefier de MS ou de s'en plaindre sont en fait rarement utilisees.
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par Kangs le 07 juillet 2009 à 19:01. Évalué à 5.
        
        "Moi je constate simplement que les recriminations, supputations, ... contre MS sur ce site sont dans leur grande majorite completement fausses."
        
        Heureusement que toi tu connais la vérité absolu et que tu es là pour nous la faire connaitre. Ta crédibilité est du niveau de ta neutralité dans le discours.
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par pasBill pasGates le 07 juillet 2009 à 19:12. Évalué à 3.
        
        Je peux te donner une list longue comme la tour Eiffel des aneries que j'ai prouve fausses sur ce site, entre les gens qui croient encore qu'il n'y a pas de separation admin/utilisateur dans Windows a ceux qui n'ont pas realise que NTFS implementait a peu pres tout ce qu'il y a dans les FS Linux depuis des lustres et qu'il etait journalise depuis sa naissance aux histoires bidons de raw sockets dans XP qui allaient couler internet et autres cles de la NSA dans Windows.
        
        Toutes ces choses la sont demontees clairement sur le net hein, pas besoin de moi pour s'en rendre compte.
        
        La grosse difference c'est qu'ici je suis un des rares a amener ces elements, et c'est probablement pour ca que nombre de gens ici sont content d'avoir mes posts.
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par windu.2b le 08 juillet 2009 à 13:31. Évalué à 3.
        
        "entre les gens qui croient encore qu'il n'y a pas de separation admin/utilisateur dans Windows a ceux qui n'ont pas realise que NTFS implementait a peu pres tout ce qu'il y a dans les FS Linux depuis des lustres et qu'il etait journalise depuis sa naissance aux histoires bidons de raw sockets dans XP qui allaient couler internet et autres cles de la NSA dans Windows."
        C'est vrai ? Tu viens bien nous fournir le code-source de tout ça pour qu'on vérifie ? :-)
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par Kangs le 08 juillet 2009 à 17:40. Évalué à -2.
        
        Faux pas leur en vouloir, ils viennent du monde Windows ou dire de grosses anneries est une coutume fortement ancrée. Quand ils auront perdu leurs réflexes de windosiens tu ne les entendra plus dire ces bêtises.
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par benoar le 07 juillet 2009 à 18:05. Évalué à 2.
        
        Heu ... arrête ta parano, je parlais pas de toi, hein, je parlais des annonces officielles, de pBpG, et du blog de Icaza entre autres.
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par zebra3 le 07 juillet 2009 à 18:09. Évalué à 2.
        
        Ce qui a déjà été dit, ce n'est pas qu'il n'y a pas de danger, mais c'est qu'il n'y en a pas plus que pour n'importe quel logiciel libre, comme par exemple le noyau Linux lui-même.
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
      - [^] # Re: YaST, Java, Mono..
        
        Posté par Mildred (site web personnel) le 12 juillet 2009 à 14:38. Évalué à 1.
        
        Mono, un freeware ... il ne faut pas pousser quand même.
        
        Mono reste libre, complètement et entièrement. Qu'il y ait ou non de possibles brevets qui le menace ne change rien à cela
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par B16F4RV4RD1N le 12 juillet 2009 à 15:57. Évalué à 2.
        
        par freeware, je ne parlais pas de Mono, mais des produits couverts par le "Microsoft Community Promise".
        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par patrick_g (site web personnel) le 13 juillet 2009 à 13:07. Évalué à 3.
        
        Ce que je ne sais pas c'est si il va y avoir une annonce vraiment officielle de la part de Microsoft (avec communiqué de presse et tout le toutim) ou bien si ça va se limiter à ce post sur un blog, certes officiel mais bon...ce serait un peu léger je trouve.
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par B16F4RV4RD1N le 13 juillet 2009 à 18:25. Évalué à 2.
        
        l'info est également donnée dans ton lien sur le site officiel :
        http://www.microsoft.com/interop/cp/default.mspx
        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
    - [^] # Re: YaST, Java, Mono..
      
      Posté par JoeltheLion (site web personnel) le 07 juillet 2009 à 16:02. Évalué à 4.
      
      Maintenant, si tu utilises Mono sans les APIs MS, tu as MOINS de risques qu'en utilisant le kernel, OpenOffice, ... car MS a promis de ne pas attaquer les implementations de C# et CLI
      
      Sauf qu'en fait non:
      
      http://www.reddit.com/r/programming/comments/8yrtt/miguel_de(...)
      - [^] # Re: YaST, Java, Mono..
        
        Posté par pasBill pasGates le 07 juillet 2009 à 16:09. Évalué à 2.
        
        Ben si, parce que avec OOo, le kernel, ... meme si tu as une implementation complete et correcte, t'es toujours dans la mouise.
        
        Sinon, IBM a la meme limitation pour ODF, evite donc d'utiliser OpenOffice si ca te pose un probleme...
      - [^] # Re: YaST, Java, Mono..
        
        Posté par benoar le 07 juillet 2009 à 17:20. Évalué à 3.
        
        Effectivement, c'est dans la FAQ :
        http://www.microsoft.com/interop/cp/default.mspx#EHD
        Si l'implémentation n'est pas complète, personne n'est couvert. Bref, le modèle de développement ouvert du LL n'est pas possible.
        
        [^] # Re: YaST, Java, Mono..
        
        Posté par TImaniac (site web personnel) le 07 juillet 2009 à 17:28. Évalué à 4.
        
        Alors arrêtons d'utiliser tous ce qui est cité sur cette page, la problématique est là même :
        http://www-03.ibm.com/linux/ossstds/isplist.html
        Y'a des petits trucs intéressants pourtant, mais bon le développement ouvert de LL avec ces standards n'est pas possible : OpenDocument, XML, DITA, UDDI, SOAP, XQuery, XSL, etc.
- [^] # Re: YaST, Java, Mono..
  
  Posté par Georges Dubus (site web personnel) le 07 juillet 2009 à 12:48. Évalué à 8.
  
  Le problème, c'est que ça ne concerne que la partie standardisée. Et apparemment, Mono implémente bien plus que ça. Le troll vivra tant que l'intégralité du code de Mono ne sera pas à l'abri.
  - [^] # Re: YaST, Java, Mono..
    
    Posté par Gniarf le 07 juillet 2009 à 17:20. Évalué à 4.
    
    > Le problème, c'est que ça ne concerne que la partie standardisée. Et apparemment, Mono implémente bien plus que ça. Le troll vivra tant que l'intégralité du code de Mono ne sera pas à l'abri.
    
    bien au fond de la poubelle _o/ ou du bocal à formol avec son copain REBOL
    - [^] # Re: YaST, Java, Mono..
      
      Posté par lasher le 08 juillet 2009 à 01:59. Évalué à 2.
      
      Attends, REBOL c'est l'avenir. C'est pas moi qui le dit, c'est Dream/Login:, et on sait à quel point ils sont à la pointe de nos jours.
      - [^] # Re: YaST, Java, Mono..
        
        Posté par Gniarf le 08 juillet 2009 à 03:54. Évalué à 2.
        
        déconne pas, j'ai le hors-série /o\
# Les trolls ne meurent jamais

Posté par alice le 07 juillet 2009 à 12:40. Évalué à 10.

Quelle est la valeur légale d'une promesse?
- [^] # Re: Les trolls ne meurent jamais
  
  Posté par dyno partouzeur de drouate le 07 juillet 2009 à 12:44. Évalué à 10.
  
  demande à ton député...
  - [^] # Re: Les trolls ne meurent jamais
    
    Posté par tiot (site web personnel) le 07 juillet 2009 à 14:33. Évalué à 4.
    
    Un député n'a aucune obligation de tenir ses promesses, au contraire la constitution dit que « tout mandat impératif est nul ».
    
    Par exemple Bayrou a dit que les députés UDF qui ont rejoint l'UMP avaient signé un papier disant qu'ils ne voteront pas de motion de censure. Même si les députés nouveau centre avaient signé ce papier avec leur sang, ils ont parfaitement le droit de faire tout le contraire.
- [^] # Re: Les trolls ne meurent jamais
  
  Posté par JoeltheLion (site web personnel) le 07 juillet 2009 à 12:48. Évalué à 3.
  
  Il semble qu'aux US, cette "promesse" a une valeur légale, et qu'elle est irrévocable. Par contre je n'ai pas de source crédible pour confirmer cette information.
  - [^] # Re: Les trolls ne meurent jamais
    
    Posté par Buf (Mastodon) le 07 juillet 2009 à 14:37. Évalué à 2.
    
    Je pense que ça doit avoir une valeur légale même en dehors des US. Vu la forme du texte, ça doit très certainement être assimilable à un contrat, et donc valide devant un tribunal.
- [^] # Re: Les trolls ne meurent jamais
  
  Posté par Thomas Douillard le 07 juillet 2009 à 13:20. Évalué à 1.
  
  A mon avis le coup du "on met en confiance" avec une promesse publique, genre, tout le monde se précipite pour implémenter le truc, et on attaque ensuite, ça sent l'arnaque et la manipulation et ça doit pas très très bien passer devant un tribunal. Mais ce n'est que mon avis.
- [^] # Re: Les trolls ne meurent jamais
  
  Posté par esdeem le 07 juillet 2009 à 13:43. Évalué à 2.
  
  Quelle est la valeur légale d'une promesse?
  
  Les promesses n'engagent que ceux qui y croient.
  0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
- [^] # Re: Les trolls ne meurent jamais
  
  Posté par IsNotGood le 07 juillet 2009 à 15:26. Évalué à 2.
  
  > Quelle est la valeur légale d'une promesse?
  
  C'est "promesse" dans le sens engagement.
  Notons que Red Hat fait de même :
  http://www.redhat.com/legal/patent_policy.html
  
  Dans les communiqués et autres engagements, il en va de la crédibilité de la parole de Microsoft. Lorsque MS ne veut pas dire que certaines de ses licences sont compatibles avec la GPL, ce n'est pas pour rien.
  
  Je pense qu'on peut prendre MS tout à fait au sérieux dans cette annonce qui est du concret et pas seulement du "pipo".
  
  Comme le fait remarquer patrick_g, ça ne concerne qu'une partie de C#. Si les engagements de MS étaient bidons, MS serait allé plus loin.
- [^] # Re: Les trolls ne meurent jamais
  
  Posté par fcartegnie le 07 juillet 2009 à 16:51. Évalué à 2.
  
  Quelle est la valeur légale d'une promesse?
  
  Se baser sur une "promesse", de plus venant d'une multinationale, pour des problèmes légaux, c'est fort !
  
  Ca ajoute vraiment à la crédibilité du logiciel libre ! :/
# Oui mais non

Posté par Pierre Bourdon le 07 juillet 2009 à 13:10. Évalué à 7.

http://www.reddit.com/r/programming/comments/8yrtt/miguel_de(...)
- [^] # Re: Oui mais non
  
  Posté par TImaniac (site web personnel) le 07 juillet 2009 à 13:43. Évalué à 3.
  
  Un peu comme IBM envers OpenDocument & co :
  http://www-03.ibm.com/linux/ossstds/isplist.html
  ""Covered Implementations" are those specific portions of a product that implement and comply with a Covered Specification and are included in a fully compliant implementation of that Covered Specification
- [^] # Re: Oui mais non
  
  Posté par JoeltheLion (site web personnel) le 07 juillet 2009 à 15:50. Évalué à 2.
  
  Tiens, ça fait plaisir de voir que je ne suis pas le seul francophone sur reddit! Dommage qu'il n'y ait pas plus de gens sur les subreddits en français :-/
# Pourquoi Mono ?

Posté par Ririsoft le 07 juillet 2009 à 13:11. Évalué à 8.

Au début de la news j'ai eu une grosse frayeur : j'ai cru que patrick_g était un Mono fan ...

Heureusement il nous éclaire un peu sur son point de vue :

En définitive cette annonce est donc une bonne nouvelle même si, à mon humble avis, le libre n'a pas "besoin" de Mono. Que ce soit avec Qt/C++ et ses bidings ou avec GTK+/C et ses bidings (plus Vala) ou encore avec Java il y a pléthore de solutions puissantes et pratiques pour développer des logiciels libres.

Ouf ! Lui aussi n'est pas convaincu par l'absolue nécessité de Mono !
Franchement je ne comprend pas l'intérêt de Mono pour faire du développement de logiciels pour Gnome, KDE ou le Desktop libre en général ... voir même pour des applications serveurs !

Pour les débutants il n'y a pas plus facile que Python/QT ou Python/GTK. Mono nécessite de comprendre tout un tas de concepts ainsi qu'un environnement de dev particulier avec compilateur et toute l'artillerie.

Pour les développeurs expérimenté il y GTK/QT en natif ou via des bindings nombreux dont C/C++/Java/Python/Perl.

Franchement C# c'est sympa à utiliser (j'ai bossé 6 mois avec dans de l'embarqué sur PDA). Mais l'est-ce plus que Java ? Pas de façon notable. Est-ce plus performant que le C++ ou le C ? Clairement non.

Alors pourquoi ? Pourquoi Mono ?

J'ai l'impression que c'est surtout une technologie poussée par Miguel, son équipe de développeurs et Novell. Aussi brillants soient-ils (ils sont vraiment impressionnants dans la quantité et qualité de boulot qu'ils abattent en peu de temps), les raisons m'ont l'air plus stratégiques pour Novell que philanthropiques pour le libre ...

Je ne comprend pas Miguel non plus ! C'est un type extrêmement brillant techniquement. J'imagine qu'il s'éclate sur Mono, mais pourquoi ne pas faire avancer Gnome et le libre en générale qui a besoin d'inventer le futur, plus que de porter les technologies des autres !

Quelqu'un peu m'expliquer : pourquoi Mono ?
- [^] # Re: Pourquoi Mono ?
  
  Posté par Octabrain le 07 juillet 2009 à 13:22. Évalué à -1.
  
  Pour les débutants il n'y a pas plus facile que Python/QT ou Python/GTK. Mono nécessite de comprendre tout un tas de concepts ainsi qu'un environnement de dev particulier avec compilateur et toute l'artillerie.
  
  Quelle putain de subjectivité... (comme la comparaison Qt/GTK vs. Mono de patrick_g)
  - [^] # Re: Pourquoi Mono ?
    
    Posté par patrick_g (site web personnel) le 07 juillet 2009 à 13:43. Évalué à 9.
    
    >>> Quelle putain de subjectivité... (comme la comparaison Qt/GTK vs. Mono de patrick_g)
    
    En même temps c'est un journal et pas une dépêche hein ?
    La subjectivité c'est permis.
- [^] # Re: Pourquoi Mono ?
  
  Posté par fearan le 07 juillet 2009 à 13:24. Évalué à 3.
  
  j'ai plusieurs réponses
  a) parce que MS forme des gens en fournissant ses outils dans les écoles & université
  b) parce que pleins de dev ne connaissent que .NET comme framework
  c) parce que personne ne te reprochera d'avoir choisi .NET en entreprise, comme il fut un temps où personne n'aurait pu te reprocher d'avoir choisis IBM
  
  Alors oui ça répond principalement à pourquoi .NET, mais les 2 sont intimement liés. Si on a des dev .NET, mono permet de les faire contribuer directement, voir même migrer.
  
  Bon ensuite je pense que Qt est largement suffisant pour ce que je fais, et je m'en contente; par contre je n'ai pas de connaissance approfondie de mono, faudra bien un jour que je regarde de ce coté pour me documenter mais je ne suis pas (encore) tenté.
  Il ne faut pas décorner les boeufs avant d'avoir semé le vent
  - [^] # Re: Pourquoi Mono ?
    
    Posté par B16F4RV4RD1N le 07 juillet 2009 à 19:39. Évalué à 4.
    
    c) parce que personne ne te reprochera d'avoir choisi .NET en entreprise,
    
    par contre on pourra toujours te reprocher d'avoir choisi .NET + Linux...
    Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
- [^] # Re: Pourquoi Mono ?
  
  Posté par TImaniac (site web personnel) le 07 juillet 2009 à 13:31. Évalué à 3.
  
  Parcque le runtime offre c'est un bon compromis niveau performance / fonctionnalité comparé à C/C++ ou Python/Ruby.
  Parcque le support multi-langages est bien intégré (IronPython, Boo & co)
  Parcque le langage (C# 3) est bien plus cool et avancé que Java (LINQ, expressions lambda, event, méthodes d'extensions, etc.)
  Parcqu'on peut réutiliser ses compétences Windows.
  Parcque la compatibilité avec Microsoft assure une large documentation et l'accès à de nombreux outils et bibliothèques tierces, bref de quoi séduire les développeurs.
  Parcque mono intègre tout ce qui faut outofthebox pour développer une application Gnome.
  Parcque la communauté de developpeurs est très réactive, notamment face aux bugs.
  
  Evidemment tu trouveras beaucoup de ces atouts ailleurs, mais tout réunis ca fait une plateforme sexy.
  - [^] # Re: Pourquoi Mono ?
    
    Posté par Nicolas Boulay (site web personnel) le 07 juillet 2009 à 13:45. Évalué à 6.
    
    Oui enfin, la doc micrososft...
    "La première sécurité est la liberté"
    - [^] # Re: Pourquoi Mono ?
      
      Posté par Pierre Bourdon le 07 juillet 2009 à 14:35. Évalué à 4.
      
      À chaque fois que j'ai eu à utiliser la MSDN pour chercher un truc, que ce soit pour du .NET ou de la Win32 API, j'ai trouvé très rapidement ce qu'il me fallait et de manière très détaillée, avec parfois même de nombreux exemples d'utilisation.
      
      Non, franchement sur ce point je trouve qu'ils ne sont pas trop critiquables.
      - [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 07 juillet 2009 à 14:37. Évalué à 8.
        
        A chaque fois que j'ai du le faire (ok, cela remonte à qq temps), c'était totalement incomplet (par exemple pas de description des paramètres d'une fonction)
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par meumeu1402 le 07 juillet 2009 à 15:22. Évalué à 7.
        
        Pareil pour moi, c'est peut etre parceque j'ai l'habitude de QtAssistant mais je trouve msdn vachement pourri ...
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 07 juillet 2009 à 16:00. Évalué à 3.
        
        Comparons alors, prenons la classe string, en Python, Qt et .NET :
        http://docs.python.org/library/stdtypes.html#string-methods
        http://doc.trolltech.com/4.5/qstring.html
        http://msdn.microsoft.com/fr-fr/library/system.string_member(...) (faut cliquer sur chaque méthode pour avoir les exemples et tout). Et en français s'il te plaît.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Octabrain le 07 juillet 2009 à 16:18. Évalué à 3.
        
        Personnellement, je navigue bien mieux dans la Javadoc que dans la doc MSDN, je trouve que les hyperliens et la structure des pages sont mieux pensés.
        
        Pour comparer :
        http://java.sun.com/javase/6/docs/api/java/lang/String.html
        http://msdn.microsoft.com/fr-fr/library/system.string_member(...)
        Sur la page MSDN, on doit suivre un lien pour ne serait-ce qu'obtenir les paramètres et le retour d'une méthode, et de là, pas d'accès à la documentation des types des paramètres pour MSDN.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 07 juillet 2009 à 16:25. Évalué à 1.
        
        C'est le problème quand la documentation est plus complète, il faut ajouter des niveaux de classement supplémentaire.
        Regarde la doc de split :
        http://java.sun.com/javase/6/docs/api/java/lang/String.html#(...)
        http://msdn.microsoft.com/fr-fr/library/b873y76a.aspx
        Tu vois la doc de MS sur une seule page comme le fait Sun ?
        Regarde la doc de Python sur la même fonction, tu verras que y'a même pas besoin de sommaire tellement c'est succinct :
        http://docs.python.org/library/stdtypes.html
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Octabrain le 07 juillet 2009 à 16:35. Évalué à 2.
        
        Pas convaincu, pour cet exemple, la doc MSDN est beaucoup trop verbeuse :
        - le topo sur les perfs de la doc MSDN me semble inutile (pas que j'aime pas quand ça parle de perf, mais là ils ne font que dire des trucs à peu près évidents dont n'importe quel programmeur pas trop con se serait passé)
        - pas mal d'exemples sur la doc MSDN ne servent complètement à rien
        Le truc en plus de MSDN pour cet exemple, c'est le listage des caractères par défaut du split.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par pasBill pasGates le 07 juillet 2009 à 16:44. Évalué à 2.
        
        le topo sur les perfs de la doc MSDN me semble inutile (pas que j'aime pas quand ça parle de perf, mais là ils ne font que dire des trucs à peu près évidents dont n'importe quel programmeur pas trop con se serait passé)
        
        Ce qui est evident pour toi ne l'est pas pour bcp d'autres. Faut pas oublier que C# et Java sont utilises dans les universites par des etudiants, par des ingenieurs fraichement diplomes, etc... Il y a plein de "non-geeks" qui programment, car tout ingenieur n'est pas forcement un passionne. Leur mettre l'information directement sur la page de l'API leur apprend qqe chose qu'ils n'auraient pas soupconne. Meme chose pour les exemples.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Zenitram (site web personnel) le 07 juillet 2009 à 16:46. Évalué à 2.
        
        Pour comparer :
        http://java.sun.com/javase/6/docs/api/java/lang/String.html
        http://msdn.microsoft.com/fr-fr/library/system.string_member(...)
        
        Tu donnes un magnifique exemple :
        - La doc Java est une horreur à lire, un truc de vieux informaticien au niveau de la mise en page (j'ai les 36 variante d'une méthode dont je ne veux pas, ça noit la méthode que je cherche)
        - La doc MSDN est agréable à lire, bien plus présentable, les choses sont bien séparées, l'important est affiché sur la première page pour m'aider à trouver ce que je cherche.
        
        Note: pour rajouter un language, le C++!
        http://www.cplusplus.com/reference/string/string/
        Aussi assez agréable à lire.
        
        C'est sans doutes une question de gouts, mais clairement, MSDN dépasse JavaDoc de loin pour ma rapidité de recherche de méthode dont je ne connait pas le nom (le plus souvent, pour le reste il y a l'aut-completion de mon IDE)
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 07 juillet 2009 à 20:41. Évalué à 0.
        
        MSDN dépasse JavaDoc de loin ...
        
        Tu fais le singe qui préfère la voiture rouge...
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Zenitram (site web personnel) le 07 juillet 2009 à 20:54. Évalué à 3.
        
        Tu fais le singe qui préfère la voiture rouge...
        
        Ne t'en déplaise, une bonne documentation est un point essentiel pour un langage quand tu veux le diffuser partout.
        Une mauvaise documentation ne va pas attirer les développeurs du dimanche, qui demain seront les développeurs professionnels et feront l'effet de volume.
        
        C'est sur ce genre de détail que certaines choses peuvent échouer... Pas celui-ci tout seul, mais une mauvaise documentation aide à faire fuir les gens si ils ont d'autres reproches à faire.
        
        Bon, après, 99% des logiciels sont mono-plate-forme Windows, une bonne partie des applis web sont en PHP qui a une documentation tout aussi lisible (à défaut d'être 100% exacte ;-) ), alors bon, c'est vous qui voyaient...
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par alice le 08 juillet 2009 à 01:48. Évalué à 0.
        
        Si tu n'aimes pas le look par défaut de la doc Java, il existe des formatages plus aux goûts des amateurs de Microsoft :
        
        http://www.allimant.org/javadoc/
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Zenitram (site web personnel) le 08 juillet 2009 à 01:54. Évalué à 1.
        
        Euh... Un vieux HtmlHelp de Windows 95 c'est sensé être au goût des amateurs de Microsoft???
        
        Faut reinstaller un Windows, le monde a bien changé depuis 10 ans, et il faut aller voir un peu le MSDN plutôt que d'avoir des préjugés sur le design de MS d'aujourd'hui...
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par alice le 08 juillet 2009 à 13:18. Évalué à 2.
        
        Je plaisantais...
        
        Sinon je consulte MSDN et les docs Java régulièrement à mon boulot et il faut être d'une mauvaise foi ultime pour dire que Java est mal documenté par rapport à .NET...
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 12:16. Évalué à 3.
        
        Tu ne parles pas d'une bonne documentation mais d'une belle présentation. Cela n'a rien à voir.
        
        Et c'est le syndrome du singe et de la voiture rouge...
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par windu.2b le 08 juillet 2009 à 13:42. Évalué à 3.
        
        Donc ton reproche repose principalement sur la CSS par défaut de la JavaDoc ?
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Zenitram (site web personnel) le 08 juillet 2009 à 13:49. Évalué à 2.
        
        Mon reproche va sur la forme présentée du site de référence.
        Que ce soit "CSS" ou autre charabia, je m'en fout, mes yeux ne voient que ce qui s'affiche. Quelqu'un parle présentation, tu parles technique, et hop le quelqu'un va aller sur le MSDN parce que la c'est correct sans charabia.
        
        Plus techniquement, oui la CSS par défaut joue, mais pas que ça (les 50 possibilités d'une méthodes sont affichées d'un coup, immonde à lire quelque soit la CSS)
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par windu.2b le 08 juillet 2009 à 14:01. Évalué à 3.
        
        En quoi est-ce mal de voir les "50 possibilités d'une méthode" (tu parles bien de la surcharge de méthode ? ) ?
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Zenitram (site web personnel) le 08 juillet 2009 à 14:55. Évalué à 3.
        
        Comment travaille une personne de manière générale?
        - Elle cherche la classe qui va bien
        - Une fois la classe trouvée, elle cherche la méthode dont elle a besoin. Elle ne connait pas le nom de cette méthode (parce que bon, si elle connait, 99% du temps c'est bon, son IDE va faire l'autocompletion, sinon changer d'IDE). Elle va donc fouiller et regarder en un coup d'oeil la liste des méthodes disponibles :
        * MSDN, ou plein d'autres : on trouve assez rapidement, car il y a le nom et une description succincte de chaque méthode. Reste plus qu'à cliquer pour avoir plus d'info.
        * javadoc/doxygen : tout est balancé en vrac, faut virer de sa vue les paramètres (on s'en fou quand on cherche une méthode!), et les doublons (bordel, c'est bon, j'ai compris qu'elle existe la méthode)
        - Une fois la méthode trouvée, elle s'intéresse à son utilisation
        
        3 étapes, 3 pages facilitant ces étapes, c'est plus pratique qu'un "tout est la, démerde-toi".
        
        Dans l'exemple de String, il y a 2x plus de méthodes chez MS que Java, n'empêche si je cherche la méthode pour formater je la trouve plus rapidement en passant les yeux sur la colonne des noms de méthodes chez MS qu'en décryptant la doc Java (bon, c'est pas la pire, mais peut mieux faire).
        
        C'est peut-être subjectif, mais je connais pas mal de monde que râle sur la doc, sauf sur celle de MS (les seuls qui râlent sont des intégristes anti-MS "linux c'est le meilleur" qui ne peuvent philosophiquement pas dire qu'un truc est bien si ça vient de mal)
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par alice le 08 juillet 2009 à 16:57. Évalué à 2.
        
        C'est peut-être subjectif, mais je connais pas mal de monde que râle sur la doc, sauf sur celle de MS
        
        Bizarre moi je constate l'inverse. Ne prends pas ton petit cercle pour l'immense majorité des développeurs...
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par windu.2b le 08 juillet 2009 à 19:13. Évalué à 2.
        
        "Dans l'exemple de String, il y a 2x plus de méthodes chez MS que Java, n'empêche si je cherche la méthode pour formater je la trouve plus rapidement en passant les yeux sur la colonne des noms de méthodes chez MS qu'en décryptant la doc Java (bon, c'est pas la pire, mais peut mieux faire)."
        Ben, t'as dû rater un truc dans ce cas : en début de chaque page Javadoc, il y a 3 tableaux :
        * Field Summary ;
        * Constructor Summary ;
        * Method Summary.
        Avec pour chacun, la liste des champs/constructeurs/méthodes marqués en gras et classés par ordre alphabétique, la liste des paramètres et une description courte (1 ligne).
        
        C'est ensuite seulement que tu as tout ceci de plus détaillé ! Sauf que pour passer d'une ligne du tableau au détail, il suffit de cliquer (donc comme dans la doc MSDN). Avec une légère différence : ça se fait via des ancres (vu que c'est au sein de la même page).
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Zenitram (site web personnel) le 08 juillet 2009 à 19:21. Évalué à 2.
        
        Ben, t'as dû rater un truc dans ce cas
        
        Ah? Exemple avec format (je suis gentil, j'en prend pas avec 10 surcharges, j'ai pitié)
        
        Java:
        static String format(Locale l, String format, Object... args)
        Returns a formatted string using the specified locale, format string, and arguments.
        static String format(String format, Object... args)
        Returns a formatted string using the specified format string and arguments.
        
        MSDN:
        Format Surchargé. Remplace chaque élément de mise en forme dans un String spécifié par l'équivalent textuel de la valeur d'un objet correspondant.
        
        Java 300 signes (dont 150 qui ne m'intéressent pas quand je cherche une méthode : rien à faire des paramètres, rien à faire du texte recopié 2x, je doit lire 2x le même texte avant de savoir que ce n'est pas ce que je cherche!)
        MSDN 150 signes, et encore, c'est en Français et le français est moins concis que l'anglais.
        
        Pour une méthode surchargé 10 fois, c'est 1500 signes pour Java contre 150 signes pour MSDN.
        
        Ou alors j'ai loupé le "Method Summary." de Java... Mais je ne pense pas.
        
        C'est ensuite seulement que tu as tout ceci de plus détaillé !
        
        Justement, c'est la que le détail devrait être. Le summary est carrément trop détaillé.
      - [^] # Re: Pourquoi Mono ?
        
        Posté par briaeros007 le 07 juillet 2009 à 19:02. Évalué à 3.
        
        je viens de le faire pour gérer un DC qui avait un problème.
        Juste mis trois jour sur tout un tas de doc , certaines venant de ms, d'autres de forums, etc...
        
        Alors le coup du "j'ai trouvé très rapidement ce qu'il me fallait et de manière très détaillée, avec parfois même de nombreux exemples d'utilisation." , rien que sur le ton, ca me fait penser à une put**n de pub.
        
        La doc, sur certains point est bien faite, mais sur d'autres, mais laisse tomber.
        
        Et la volontée de ms d'afficher par défaut un truc traduit automatiquement qui veut plus rien dire (et qui change l'ordre des options , je comprenais plus rien moi sur adprep moi)
        
        Je parle pas des codes d'erreurs a recherche (dcdiag et autre renvoie des codes d'erreurs sous format hexa, très fun). Des "EventID" et autre tous plus explicites les un que les autres.
        
        Non franchement la doc de windows y'a du très bon comme du très mauvais, voir de l'inexistant.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 07 juillet 2009 à 19:29. Évalué à 1.
        
        On parle de la doc de .NET, qui elle est relativement complète et bien rangée.
    - [^] # Re: Pourquoi Mono ?
      
      Posté par Zenitram (site web personnel) le 07 juillet 2009 à 16:08. Évalué à 3.
      
      Oui enfin, la doc micrososft...
      
      Avec la doc Microsoft (MSDN, dispo online), je trouve assez rapidement ce dont j'ai besoin, de l'API CLI à l'interface graphique en passant par l'interaction avec l'Explorer.
      
      La même chose sous Linux? Je cherche encore...
      La doc Microsoft est une des choses que Microsoft fait beaucoup mieux que Linux (même si ce n'est pas parfiat, loin de la), et qui fait entre autre qu'il y a plus de développeurs Microsoft que Linux!
      La communauté du libre ferait bien de s'en inspirer plutôt que d'avoir n sites de man qui n'apportent pas grand chose sauf si on sait ce qu'on cherche (ce qui est rarement le cas)...
      - [^] # Re: Pourquoi Mono ?
        
        Posté par yellowiscool le 07 juillet 2009 à 21:36. Évalué à 2.
        
        QtAssistant, simple et efficace.
        
        C'est en anglais, mais la taille de la société n'était pas comparable jusqu'au rachat avec nokia (et encore)…
        Envoyé depuis mon lapin.
  - [^] # Re: Pourquoi Mono ?
    
    Posté par Thierry le 07 juillet 2009 à 14:35. Évalué à 1.
    
    la compatibilité avec Microsoft -et- une plateforme sexy.
    
    Dommage que l'on ne soit pas vendredi...
    
    (-1 et je je suis déja dehors...)
- [^] # Re: Pourquoi Mono ?
  
  Posté par Camille_B le 07 juillet 2009 à 13:34. Évalué à 10.
  
  Et pourquoi Ruby ?
  
  On a déjà Python.
  
  Pourquoi Python ?
  
  On a déjà Perl.
  
  Pourquoi Perl ?
  
  On a déjà C.
  
  Pourquoi C ?
  
  On a déjà LISP.
- [^] # Re: Pourquoi Mono ?
  
  Posté par Moonz le 07 juillet 2009 à 13:34. Évalué à 4.
  
  > Mais l'est-ce plus que Java ?
  Oui, dès lors que tu utilises ses fonctionnalités des versions 2 & 3
- [^] # Re: Pourquoi Mono ?
  
  Posté par patrick_g (site web personnel) le 07 juillet 2009 à 13:41. Évalué à 10.
  
  >>> Alors pourquoi ? Pourquoi Mono ?
  
  Fondamentalement Mono n'est pas utile pour le libre.
  Quel est vraiment l'intérêt d'avoir ces lourdes machines virtuelles qui exécutent du bytecode sur différentes archis ?
  Dans le monde du libre, comme le code source est disponible, on en a rien à battre d'avoir cet environnement qui fait abstraction de l'archi ! Dans le libre on prend le source et on le compile directement c'est tout.
  Mais pour les firmes qui vivent dans le monde propriétaire cette solution n'est pas envisageable...donc création de Java et .NET.
  - [^] # Re: Pourquoi Mono ?
    
    Posté par Camille_B le 07 juillet 2009 à 13:50. Évalué à 5.
    
    Bon bah, bye bye Python.
    - [^] # Re: Pourquoi Mono ?
      
      Posté par patrick_g (site web personnel) le 07 juillet 2009 à 14:24. Évalué à 1.
      
      Mon commentaire visait les compagnies qui ne veulent pas mettre le source à disposition et qui utilisent donc une VM.
      Python n'est bien entendu pas dans ce cas là puisque par définition on a le source.
      - [^] # Re: Pourquoi Mono ?
        
        Posté par Camille_B le 07 juillet 2009 à 14:33. Évalué à 5.
        
        Je cite :
        
        «Dans le monde du libre, comme le code source est disponible, on en a rien à battre d'avoir cet environnement qui fait abstraction de l'archi !»
        
        J'ai du mal à saisir le raisonnement.
        
        Le Python dispose d'une VM, vous dites qu'on n'a rien à battre des VM dans le monde du libre, je vous répond "bye bye Python" (en toute logique), et vous me répondez que Python n'entre pas dans cette catégorie parce qu'on n'a les sources...
        
        Il y a quelque chose que je n'ai pas bien saisis là.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Camille_B le 07 juillet 2009 à 14:35. Évalué à 2.
        
        J'ai oublié la phrase qui suit celle que je viens de citer :
        
        «Dans le libre on prend le source et on le compile directement c'est tout.»
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par B16F4RV4RD1N le 07 juillet 2009 à 19:37. Évalué à 2.
        
        oui et puis comme les API bougent très rapidement dans le libre, un code source ne compile plus 8 mois plus tard, donc finalement parfois c'est pas si mal que cela les VM...
        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par patrick_g (site web personnel) le 07 juillet 2009 à 15:17. Évalué à 3.
        
        >>> vous dites qu'on n'a rien à battre des VM dans le monde du libre
        
        J'exclus de ce "on n'a rien à battre" les VM pour les langages de script.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Octabrain le 07 juillet 2009 à 15:22. Évalué à 0.
        
        T'exclue ce qui t'arrange, d'ailleurs comment définirais-tu "langage de script" ?
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 07 juillet 2009 à 20:43. Évalué à 3.
        
        De façon simple : sans binaire.
        
        Le reste n'est que technique différente d'interprétation.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Octabrain le 08 juillet 2009 à 11:37. Évalué à 1.
        
        Sans binaire ? Avec des définitions aussi simplistes, le C aussi est un langage de script : http://bellard.org/tcc/tcc-doc.html#SEC4 (option -run).
        T'as pas une définition un peu mieux de ce que t'appelles un langage de script ?
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 12:43. Évalué à 2.
        
        C'est pourtant la plus parlante.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Octabrain le 08 juillet 2009 à 13:05. Évalué à 1.
        
        Ah, tu ne veux pas reconnaitre qu'elle est tellement imprécise qu'il est impossible de discuter ?
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 15:51. Évalué à 1.
        
        Elle est très précise justement. Tu as un code exécutable et distribuable. Ce n'est pas un cache, c'est les instructions effectivement exécutées par le cpu.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Octabrain le 08 juillet 2009 à 15:59. Évalué à 1.
        
        OK, t'es vraiment borné que c'est pas la peine d'essayer de discuter.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Camille_B le 07 juillet 2009 à 15:44. Évalué à -1.
        
        Ouah !
        
        1) comme le dit Octabrain : comment définiriez-vous "langage de script". Je ne suis pas certains que des programmes comme IDLE ou Mirage soient de simples scripts.
        
        2) Mono permet de faire tourner ce que vous appelez des langages de scripts (IronPython, Boo etc.). Et même C# puisque, pour répondre aux besoins de Unity3D, l'équipe de Mono a conçue un interpréteur C#.
        
        3) Il est tout à fait envisageable d'utiliser la VM de Python pour faire fonctionner d'autres langages, y compris des langages non interprétés. Dès sa VM sort de facto de la catégorie "vm pour langage de scripts".
        
        Bref, patrick_g, renseignez-vous sur le sujet, vous savez le faire, vous nous le montrez suffisamment.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 07 juillet 2009 à 20:47. Évalué à 2.
        
        C'est quoi une VM pour toi ?
        
        Un truc qui exécute du code directement depuis une représentation intermédiaire ? Perl fait ça depuis le début mais je pense qu'il ne voulait ça pour simplifier le portage.
        
        Les compilos fonctionnent aussi comme ça avec génération de code au lieu de l'exécution direct.
        
        Une VM au sens de C#, JVM c'est un environnement d'exécution dynamique qui relit du bytecode pré-compilé. On en est loin dans le cas de Perl, ou de python.
        
        Cela dis il reste cette énorme lourdeur de traduction à la volé des instructions intermédiaires.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 07 juillet 2009 à 21:08. Évalué à 1.
        
        C'est quoi une VM pour toi ?
        C'est une définition d'un jeu d'instruction définissant une machine qui n'existe pas physiquement mais qui n'est qu'une vue pour le développeur. C'est ce que propose le bytecode java, .NET ou les compilos comme GCC à travers leurs langages intermédiaires.
        
        Cela dis il reste cette énorme lourdeur de traduction à la volé des instructions intermédiaires.
        Cette énorme lourdeur ?
        hem.
        mono --aot program.exe
        hop j'obtiens un exécutable en code natif que je peux exécuter, plus d'exécution du bytecode, magique non ?
        C'est pas pour rien que mono est utilisable sur iPhone pour les techniques de JIT ne sont pas autorisées.
        Le bytecode .NET a été conçu dès le départ pour être compilé à la volée ou bien avant.
        Et même lorsqu'on demande pas explictement de le faire, l'environnement maintient un cache pour ne pas faire le JIT à chaque exécution.
        
        On en est loin dans le cas de Perl, ou de python.
        Jython, IronPython, tu connais ? La limite est vraiment devenu très flou...
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par meumeu1402 le 07 juillet 2009 à 15:20. Évalué à 2.
        
        Oui mais y'a une petite différence entre du code compilé en bytecode et python, ton code c#, tu le compile donc la machine virtuelle ne sert "a rien" elle rajoute une couche d'abstraction qui me parait inutile, c'est tout, python à beesoin de cette vm car à la base il n'est pas compilé
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Octabrain le 07 juillet 2009 à 15:25. Évalué à 1.
        
        Il n'est pas compilé ? Au contraire, il est recompilé en interne à chaque fois.
        D'ailleurs, il suffirait de rajouter un petit patch pour pouvoir mettre quelque chose comme "#!/usr/bin/javac ; /usr/bin/java" au début de ton .java
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Camille_B le 07 juillet 2009 à 15:36. Évalué à 3.
        
        Avant de rétorquer des imbécilités je vous conseille de vous renseigner un tout petit peu sur le fonctionnement d'une VM et de la VM python en particulier (puisque c'est dorénavant le sujet).
        
        Python fonctionne en interprété mais également en compilé, dans les deux cas on passe par du bytecode (c'est absolument nécessaire à la VM !) :
        
        Interprété : code source -> bytecode -> éxecution
        
        compilé : code source -> bytecode (enregistré sur le disque) ; bytecode -> éxecution
        
        C'est le fonctionnement de base d'une VM quelle qu'elle soit. Que ce soit Python ou Mono, c'est pareil.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 07 juillet 2009 à 15:52. Évalué à 4.
        
        Y'a un 3ème mode pour mono/.NET/GCJ :
        code source -> bytecode -> code natif -> exécution.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par patrick_g (site web personnel) le 07 juillet 2009 à 15:55. Évalué à 5.
        
        Tu ne veux pas comprendre ce que j'essaye de te dire (ou bien je m'explique mal).
        Ce dont je veux parler c'est de la philosophie qui conduit à utiliser une VM pour C# ou Java.
        
        Dans le cas de Python, qui est un langage de script (donc interprété) il est évident que tu a besoin d'une VM.
        Dans le cas de C# ou de Java, qui sont des langages compilés, tu n'a pas fondamentalement besoin d'une VM.
        
        Pourquoi alors interposer cette très lourde VM ? Il y a les avantages listé dans les divers posts de ce journal (protection contre les débordements mémoire, etc) mais je ne pense pas que ce soit fondamentalement ça la raison.
        Je pense que ça vient en partie d'un raisonnement qui a court dans le monde du logiciel propriétaire et qui est "comment faire tourner mon beau binaire chez le maximum de clients".
        
        Pour ça ils ont utilisé cette notion de VM qui existent sur les diverses plate-formes et d'un binaire qui peut s'exécuter sur toutes ces VM.
        
        Ce que je dis c'est que, dans une optique logiciel libre, il n'y a pas besoin de cette solution puisque le code source est disponible et qu'il peut être compilé pour les différentes plate-formes.
        
        Peut-être que je me trompe, peut-être que je raconte des conneries car je ne m'y connais pas assez mais c'est mon sentiment.
        J'espère que je me suis mieux expliqué cette fois.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Octabrain le 07 juillet 2009 à 16:03. Évalué à 2.
        
        "Dans le cas de Python, qui est un langage de script (donc interprété) il est évident que tu a besoin d'une VM."
        Pas vraiment, on ne parle pas de VM pour le shell (qui est du script je suppose) que je sache.
        
        "J'espère que je me suis mieux expliqué cette fois."
        On avait très bien compris, et on a déjà répondu.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 07 juillet 2009 à 20:49. Évalué à 2.
        
        Sauf que la VM dans ce cas n'est qu'un moyen d'interprétation, rien n'empèche d'avoir une VM pour le shell !
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Octabrain le 08 juillet 2009 à 11:38. Évalué à 1.
        
        Je ne faisais que répondre à ton affirmation (fausse). "Il est évident que", ben non c'est pas évident.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 07 juillet 2009 à 16:05. Évalué à 2.
        
        Python[...] il est évident que tu a besoin d'une VM.
        C# ou de Java[...] tu n'a pas fondamentalement besoin d'une VM.
        Tu peux compiler du Python.
        Tu peux interpréter du C# ou du Java (ce dernier a d'ailleur été conçu dans cet optique initialement).
        
        Je pense que ça vient en partie d'un raisonnement qui a court dans le monde du logiciel propriétaire et qui est "comment faire tourner mon beau binaire chez le maximum de clients".
        C'est une problématique qui existe aussi dans le logiciel libre faut pas croire. La plupart des distributions Linux populaires sont fournies sous la forme de binaires.
        Et c'est sûrement pas une partie de plaisir de fournir des ressources supplémentaires (temps, CPU, espace disque) afin de compiler les softs pour différentes architectures (ex : Debian).
        Sans parler de l'embarqué.
        Avoir accès aux sources ne veut pas dire que c'est le moyen numéro 1 de distribuer un logiciel libre.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 07 juillet 2009 à 20:52. Évalué à 2.
        
        Tu peux compiler du Python.
        Tu peux interpréter du C# ou du Java (ce dernier a d'ailleur été conçu dans cet optique initialement).
        
        Mais on s'en fout. Ce que dis patrick_g c'est qu'utiliser un binaire issue de ses langages serait infinement meilleur que passé par un bytecode lourdingue.
        
        Sans parler de l'embarqué.
        
        En effet, les distributions dans l'embarqué sont uniquement fait en source pour n'utiliser que les fonctions utilisé (cf la compilation de busybox). Utiliser un VM pour un petit système... Tu auras eu le mérite de me faire rire.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 07 juillet 2009 à 21:11. Évalué à 2.
        
        Mais on s'en fout.
        On s'en fou pas. Ca montre que techniquement il est autant acceptable d'utiliser une VM dans un cas comme dans l'autre.
        De toute façon ces langages se basent sur des services offerts par une VM.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Thomas Douillard le 07 juillet 2009 à 16:06. Évalué à 4.
        
        Rien n'interdit fondamentalement de compiler un langage de script. Ou d'interpréter un langage "compilé". Cette barrière est artificielle et fait référence aux implémentation courante (ou originale) des langages.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par pastro le 07 juillet 2009 à 16:22. Évalué à 1.
        
        d'aileurs compiler un language de script ... ben le script est un source comme un autre pas de problème (il faut 'juste' écrire le compilo).
        
        et interpréter un langage compilé ( donc du code natif d'une autre plateforme) ben ca reviends a lancer qemu (avec la bonne archi)
        
        on pourrai même recompiler un programme compilé pour une autre plateforme ( une sorte de compilo assembleur->assembleur ) .. enfin bref on peut faire un epu tous ce qu'on veux.
        
        P.S. par contre niveau performance j peut pas dire ce que ca donnerai.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Camille_B le 07 juillet 2009 à 16:36. Évalué à 2.
        
        «et interpréter un langage compilé ( donc du code natif d'une autre plateforme) ben ca reviends a lancer qemu (avec la bonne archi)»
        
        Non, ça n'est pas ce qu'il voulait dire. Ce qu'il veut dire, si je ne me trompe pas, c'est qu'un langage initialement conçu pour être compilé (en bytecode ou en code natif), peut-être bien disposer d'une implémentation interprétée.
        
        Ainsi Mono propose un interpréteur C#.
        
        Ainsi LLVM est une machine virtuelle qui créé du bytecode depuis C (je ne me trompe pas ?).
        
        etc. etc.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Camille_B le 07 juillet 2009 à 16:07. Évalué à -2.
        
        Maintenant c'est un peu plus clair.
        
        Qu'une VM facilite le développement et le portage, c'est une évidence.
        
        Qu'une entreprise qui fait du proprio souhaite utiliser des outils lui permettant de ne pas avoir à compiler et réécrire son code pour toutes les plateformes, ça semble évident.
        
        Cela dit votre raisonnement ne tient pas debout. Vous considérez qu'une VM est forcément lourde. Ça n'est pas nécessairement le cas. LLVM et Parrot sont de toutes petites VM.
        
        Vous considérez qu'on n'en a pas besoin parce qu'on peut faire pareil avec des langages compilés "classiquement". Bah oui. On peut même faire pareil avec de l'assembleur.
        
        Chaque machines virtuelles apportent leur lot de fonctionnalités qui seront utiles dans tels ou tels cas, et agréable à telle ou telle personne.
        
        Votre problème c'est que vous pensez VM = Java et Mono = langages d'entreprises = proprio = rien à faire dans le libre. Mais il vous faut maintenant vous renseigner sur les réalités du monde de la programmation et sortir de votre visions beaucoup étriquée de ce qu'est une machine virtuelle.
        
        Votre raisonnement ne tient pas car vous ne connaissez manifestement pas le monde de la programmation. Renseignez-vous et vous verrez que vos propos sont intenables.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 07 juillet 2009 à 20:58. Évalué à 1.
        
        Qu'une VM facilite le développement et le portage, c'est une évidence.
        
        ?!
        
        Votre problème c'est que vous pensez VM = Java et Mono = langages d'entreprises = proprio = rien à faire dans le libre. Mais il vous faut maintenant vous renseigner sur les réalités du monde de la programmation et sortir de votre visions beaucoup étriquée de ce qu'est une machine virtuelle.
        
        Moi, je pense que l'on attaque une technologie qui est la raison d'être de ton job. Et personne ne supporte que l'on puisse dire que sa compétence est issue d'une téchno plutot nuisible et qui sert tout sauf à aider l'utilisateur. Cela a un nom, cela s'appelle de la Dissonance_cognitive. C'est pour ça que PBPG ne pourra jamais critiquer fondamentalement son employeur.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 07 juillet 2009 à 21:13. Évalué à 3.
        
        Attaque de la personne plutôt que de ses propos. Ca montre juste que t'es à court d'argument.
        
        C'est pour ça que PBPG ne pourra jamais critiquer fondamentalement son employeur.
        N'importe quoi. S'il ne le fait pas, c'est qu'il est engagé juridiquement par un contrat qui le lit à son employeur. Et c'est ce qui lui interdit de dénigrer son employeur. Essai tu vas voir, c'est autrement plus concrêt et vérifiable que la Dissonance cognitive.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par thedude le 07 juillet 2009 à 21:53. Évalué à 0.
        
        pour pbpg, c'est surtout que s'il est chez MS depuis aussi longtemps, c'est surement parce que, de base, il est plutot bien techniquement chez eux.
        Et oui aussi choquant que ca puisse paraitre aux religieux de l'extreme libre, certaines personnes pensent que MS fait un bon boulot techniquement.
        Et il paraitraient meme qu'ils sont plusieurs millions sur terre!!!
        
        Ou alors il est SM, et il aime bien se faire fesser avec une pelle cloutee.
        GrrrRrrrRrr
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par suJeSelS le 08 juillet 2009 à 12:44. Évalué à 4.
        
        Ayant quelques amis travaillant dans cette entreprise j'ai l'impression qu'elle fait beaucoup de bourrage de crane marketing à ses employés. Parfois c'est même à se demander s'ils n'ont pas des séances de prières à réciter tous les matins sur leurs logiciels pour se convaincre qu'ils sont les meilleurs.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par guppy le 07 juillet 2009 à 23:04. Évalué à 2.
        
        Attends, pourquoi le prends-tu comme une attaque ? Tout le monde est sujet à ce genre de chose. C'est la partialité, et c'est pour ça qu'on ne peut être juge et partie.
        
        A mon avis, il a raison, mais de mon côté non plus, ce n'est pas une attaque. La plupart des intervenants de ce journal sont partiaux (c'est humain), d'un côté ou de l'autre. C'est d'ailleurs pour ça que je ne donne pas mon avis sur la question, trop difficile de se détacher de son cas personnel. ;)
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Camille_B le 07 juillet 2009 à 23:23. Évalué à 1.
        
        «Moi, je pense que l'on attaque une technologie qui est la raison d'être de ton job. Et personne ne supporte que l'on puisse dire que sa compétence est issue d'une téchno plutot nuisible et qui sert tout sauf à aider l'utilisateur.»
        
        Non seulement ce genre d'arguments est débile, mais il est surtout complètement à côté de la réalité :
        
        1) J'ai fais des études de philo, je termine tout juste un certificat webmaster, et n'ai pas de job.
        
        2) Je n'utilise pas Mono, ni Java. Les seuls trucs que j'aime vraiment c'est LISP, Perl et un peu Python (pour l'instant).
        
        J'en ai vraiment marre des réactions du type "puisque tu n'es pas contre c'est que tu es pour, que tu es un fan, et que tu as des intérêts à défendre". Et bien non, je défend Mono sur certains points car un certains nombre d'arguments défavorables me semblent faux, c'est tout.
        
        Si demain Mono se casse les dents je serai un triste pour ses devs et ceux qui l'utilisent, mais d'un point de vue strictement personnel ça ne changera rien à ma vie. Tant que j'ai mon Emacs, ma Debian et mon E17 j'suis heureux dans mon p'tit coin.
        
        C'est clair ?
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Camille_B le 07 juillet 2009 à 23:29. Évalué à 2.
        
        Dois-je préciser que Mono n'est pas installé sur ma machine ? Non que je ne l'aime pas, mais parce que je n'en ai tout simplement pas l'utilité.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par thedude le 08 juillet 2009 à 00:32. Évalué à 0.
        
        Bienvenue dans le monde de la technique politique.
        
        Ceux qui poussent le cote politique du libre en avant, qui au final font passer leur "political agenda" comme disent nos amis anglophones avant la realite technique et factuel.
        
        Tu pourras dire tout ce que tu veux, tu ne discutes pas sur le meme plan.
        Tu parles technique, ils parlent politique.
        La ou la technique est neutre et factuelle (et permet a peu pres tous les avis, tant qu'ils sont argumentes), la politique (en tout cas telle que pratiquee par le geek qui a abuse de la logique booleene bien binaire) est par essence dans un etat d'esprit qu'on pourrait appeller "Mais t'es avec qui bordel? Avec eux ou contre moi?".
        
        Quoiqu'il arrive, mono EST mauvais pour eux. Pour des raisons politiques, ce qui les regarde, et c'est leur droit.
        Le seul truc qui m'enerve au plus haut poin, c'est cette facon de defendre une position politique subjective sous couvert de technique objective.
        Et de faire un bon gros FUD bien gras, pour ensuite venir chouinasser au FUD comme une pucelle au moindre mot de MS.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par patrick_g (site web personnel) le 08 juillet 2009 à 09:47. Évalué à 5.
        
        C'est pas de la technique objective ça ? http://jeff.ecchi.ca/blog/?p=874
        
        Cela démontre que Mono c'est très, très lent par rapport à une implémentation en C++. C'est con parce qu'une application de prise de notes ben d'habitude on veut qu'elle démarre super rapidement. Si tu dois attendre 12 secondes c'est vraiment moisi.
        
        Y'a donc aussi des arguments techniques objectifs contre Mono (qui s'ajoutent aux arguments politico-économiques évoqués par ailleurs).
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par zebra3 le 08 juillet 2009 à 11:13. Évalué à 2.
        
        Faut dire aussi que Gnote n'est réellement équivalent à Tomboy que dans sa dernière version, la 0.5. Alors évidemment, si elle fait moins de choses, il y a plus de chances qu'elle soit plus rapide.
        
        Ceci dit, la dernière version reste tout de même plus vive à se lancer que Tomboy, mais une fois les deux chargés, je ne sens aucune différence, alors je reste avec l'original (qui lui au moins existe sous Windows, comme quoi, la portabilité, on lui fait dire ce qu'on veut).
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 11:47. Évalué à 2.
        
        C'est pas de la technique objective ça ? http://jeff.ecchi.ca/blog/?p=874
        Absolument pas. Tomboy a beaucoup plus de plugins à charger au démarrage que GNote.
        Toujours ce syndrôme de la nouvelle application de la mort qui va beaucoup plus vite mais qui a 3 fois moins de fonctionnalité.
        Après je ne doute pas qu'il y est un écart en faveur de GNote, mais quand ils auront exactement les mêmes fonctionnalité, l'écart sera à mon avis moins important.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par yellowiscool le 08 juillet 2009 à 12:15. Évalué à 5.
        
        Là on attaque un autre problème, l'utilité de faire une usine à gaz pour une application de prise de notes.
        Envoyé depuis mon lapin.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 12:24. Évalué à 2.
        
        Ben c'est des plugins, tu désactives les plugins qui t'intéresse pas.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par imalip le 08 juillet 2009 à 19:08. Évalué à 2.
        
        C'est pas de la technique objective ça ? http://jeff.ecchi.ca/blog/?p=874
        
        Ca, c'est du benchmark qui ne veut rien dire. Ca confirme juste qu'il y a un overhead quand on démarre un appli .NET, tout comme en Java, ne serait-ce qu'a cause de la machine virtuelle.
        Si je m'amusais a réécrire une appli KDE en GTK, je pourrais présenter le meme bench sous GNOME montrant que mon appli C démarre plus vite que l'appli C++, juste parce que l'autre doit se lancer tous les services KDE. Avec point bonus si mon appli n'implémente que la moitié de ce que fait l'originale.
        
        C'est con parce qu'une application de prise de notes ben d'habitude on veut qu'elle démarre super rapidement. Si tu dois attendre 12 secondes c'est vraiment moisi.
        
        Une appli de prise de note comme Tomboy ou Gnotes, elle n'est démarrée qu'une fois avec le bureau ; apres elle reste en tache de fond. Donc cet overhead, tu le vois une fois au lancement de ma session. Ce que j'attends d'une appli de prise de notes, c'est qu'elle me permette de créer des notes rapidement, pas qu'elle démarre vite. Mais ca, ce n'est pas testé dans le bench.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 12:22. Évalué à 1.
        
        Moi, je note qu'un diplomé en philo veut m'expliquer l'informatique.
        
        Mais je parie que dans 2s tu va me dire que la formation ne sert à rien, qu'un diplome d'ingé ne vaut rien, qu'un dea non plus.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Georges Dubus (site web personnel) le 08 juillet 2009 à 12:58. Évalué à 0.
        
        Alors là, je m'insurge contre ton commentaire complètement déplacé. C'est une attaque ad hominem, sans aucun rapport, et qui en plus sous entends qu'un type qui a fait des études littéraires serait nécessairement moins compétent que toi dans tout les domaines.
        
        Quand je vois le comportement que certains peuvent avoir, ça me fait avoir honte d'être du coté scientifique de la pseudo séparation "scientifique/littéraire".
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Camille_B le 08 juillet 2009 à 13:20. Évalué à 1.
        
        La séparation est en effet d'autant plus absurde que :
        
        1) Rien n'empêche un scientifique de lire ;)
        
        2) La philosophie n'est pas vraiment une discipline "littéraire". De nombreux philosophes écrivent très très mal. L'écrit en philo n'est que la transposition d'un dialogue réel ou intérieur avec d'autres philosophes. Ce qui compte n'est pas l'écrit, mais ce qui est dit. C'est une discipline profondément orale.
        
        3) Les champs couverts par la philosophie vont de la métaphysique à la physique. L'épistémologie (étude des méthodes en science) est une branche de la philo, et j'en ai bouffé. J'ai mangé de la logique, du Feyerabend, du Khun et du Popper. Rappelons au passage que les philosophes furent non seulement les pères des sciences modernes, et que les scientifiques furent jusqu'au XVIIe de grands philosophes.
        
        4) J'ai un bas S, c'est pas grand chose, mais c'est une petite preuve que l'opposition science et littérature c'est un peu du blabla.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 15:55. Évalué à 1.
        
        Alors là, je m'insurge contre ton commentaire complètement déplacé. C'est une attaque ad hominem, sans aucun rapport, et qui en plus sous entends qu'un type qui a fait des études littéraires serait nécessairement moins compétent que toi dans tout les domaines.
        
        Tu n'as rien compris à mon message. Pour être plus claire, je ne cherche pas à lui expliquer de la philo, et lui essaye de m'expliquer des choses en me prenant de haut, alors que j'ai fait beaucoup d'étude dans le domaine (et je passe les années d'expérience). Et c'est lui qui as parler de ses études.
        
        Ce n'est pas du tout une question de gueguerre débile ("Cela sert à quoi les études littéraires ?"), mais d'essayer de faire croire que l'on maitrise son sujet.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par allcolor (site web personnel) le 08 juillet 2009 à 16:01. Évalué à 4.
        
        alors que j'ai fait beaucoup d'étude dans le domaine (et je passe les années d'expérience).
        
        mais d'essayer de faire croire que l'on maitrise son sujet.
        
        Dis par quelqu'un qui il y a quelques mois à peine étalait son ignorance crasse face au problème de l'arrêt.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 16:36. Évalué à 2.
        
        Non je le connaissais depuis 8 ans, mais je n'acceptais pas la demo nuance.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Camille_B le 08 juillet 2009 à 16:18. Évalué à 4.
        
        «Tu n'as rien compris à mon message. Pour être plus claire, je ne cherche pas à lui expliquer de la philo, et lui essaye de m'expliquer des choses en me prenant de haut, alors que j'ai fait beaucoup d'étude dans le domaine (et je passe les années d'expérience). Et c'est lui qui as parler de ses études.»
        
        En vous prenant de haut ? C'est moi qui ai "commencé" à parler de mes études ?
        
        Je n'ai pas parlé de mes études pour vous prendre de haut, ou quoi que ce soit d'autre.
        
        J'ai parlé de mes études car vous m'avez balancé au visage la dissonance cognitive croyant que je bossais chez Microsoft. Vous démontrant que tel n'était pas le cas en dévoilant un peu mon parcours personnel, au lieu de reconnaitre que vous vous êtes objectivement trompé, c'est vous qui m'avez gentiment expliqué qu'un type qui n'a fait que philo n'a qu'à fermer sa gueule face à un type qui a des diplômes en informatique. Ce sur quoi j'ai répondu en expliquant que certes je n'ai pas de gros diplômes en info (un petit certificat webmaster au CNAM), mais j'ai un tout petit peu d'expérience, ce qui me permet de discuter sur ces sujets sans pour autant prétendre à une autorité que je n'ai pas.
        
        «Ce n'est pas du tout une question de gueguerre débile ("Cela sert à quoi les études littéraires ?"), mais d'essayer de faire croire que l'on maitrise son sujet.»
        
        Je n'essaie absolument pas de faire croire que je "maitrise le sujet". Lorsque je crois avoir compris un truc sur un sujet j'en parle. Si des arguments ne me convainquent pas, je continue de les discuter. Quand aux sujets que je ne maitrise pas du tout je n'y réponds pas. C'est tout.
        
        Si votre fierté s'est trouvée blessée après que vous ayez cru que je mettais en cause votre formation et votre expérience, j'en suis désolé et je vous prie de croire que telle n'était pas mon intention.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Camille_B le 08 juillet 2009 à 13:07. Évalué à 5.
        
        «Moi, je note qu'un diplomé en philo veut m'expliquer l'informatique.»
        
        Je ne souhaite expliquer l'informatique à personne. Mais voilà, ça fait maintenant 18 ans que j'ai un ordinateur sous les mains ; 9 ans que je traine mes guêtres dans le monde Linux ; quelques années que je m'intéresse à la programmation (sans avoir jamais vraiment pratiqué sérieusement, je le reconnais) ; et j'ai passé deux ans à travailler sur un mémoire traitant de philosophie d'Internet, et un peu plus de temps à penser la question de la technique.
        
        Ça ne fait pas de moi une autorité, même petite, dans le monde de l'informatique, mais ça me permet de comprendre deux trois trucs dans ce domaine.
        
        Ensuite, vous remarquerez que je défend moins Mono techniquement que je ne critique une posture idéologique qui vise principalement à cracher sur une techno libre parce qu'elle est une implémentation d'un produit Microsoft.
        
        Et la question de l'idéologie je la connais un tout petit peu. Car voyez-vous, s'il y a bien un truc qu'on essaye d'éviter quand on fait de la philo, c'est bien ça (en tout cas pour ma part).
        
        «Mais je parie que dans 2s tu va me dire que la formation ne sert à rien, qu'un diplome d'ingé ne vaut rien, qu'un dea non plus.»
        
        Encore une fois vous vous trompez. Je ne dirai jamais une telle chose.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 16:09. Évalué à 2.
        
        Ce que tu poses comme problème idéologique est en fait un problème de risques juridiques. Je ne sais pas si le "risque" s'étudie en philo, mais c'est un concept très courant en économie.
        
        Ici, on parle du risque juridique que représente l'entité Microsoft sur les développements lié à Mono et l'environnement C#, .NET.
        
        Cela a dérapé sur des concepts techniques comme la quasi inutilité des VM (sauf si on ne peut pas utiliser 2 process pour intégrer des plugin par exemple ou la portabilité de binaire). Mais cela n'est pas le sujet de base.
        
        Le texte de RMS et de la FSF est de dire que MS fait peser un risque juridique beaucoup trop grand sur les développements mono.
        
        Qu'est-ce qui fait dire ça ?
        
        * Les menaces répétés mais jamais démontré de violation de brevet par Linux
        * Le raid sur TomTom avec le brevet sur la Fat
        * L'accord avec Novell également sur les brevets pour gagner de l'argent sur le dos du libre
        * La "promesse" toute récente qui a été faite mais dont on est loin d'être sûr de savoir que Mono est couvert.
        
        Il y a aussi le passif
        * "Linux est un cancer"
        * Les documents halloween
        * La succession des procès anti-trust perdu
        * Le combat pour rendre le serveur samba incompatible avec leur OS
        * La corruption des instances de l'iso avec l'inscription de tout plein de nouveau pays votant comme par hasard toujours dans le sens de MS.
        
        Bref, le passif est lourd. Google fait peur par sa taille, pose des problèmes sur la respect de la vie privé mais n'a pas cet énorme passif sur la communauté FLOSS.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Camille_B le 08 juillet 2009 à 16:35. Évalué à 2.
        
        Je n'ai jamais nié le fait que Microsoft ne soit pas ami avec le monde du logiciel libre. Les risques juridiques sont bien évidemment réels, mais nous savons que ces risques existent également pour tout un tas de logiciels libres autres que Mono.
        
        Sinon pourquoi l'OIN ?
        
        Que Mono soit plus en danger que tel autre logiciel, pourquoi pas. Ça se défend.
        
        Mais lorsque je parle d'idéologie je ne parle pas de ça. Je parle de cette attitude qui consiste à rejeter de facto Mono parce que c'est du logiciel libre. Et nous l'avons bien vu : "bon très bien Mono est désormais un peu plus protégé, mais franchement il apporte quoi par rapport à... ?" ; "pourquoi utiliser une techno Microsoft alors que nous avons les notres, dans le libre ?" etc.
        
        Pour un certain nombre de personnes le risque juridique n'est qu'une occasion de critiquer une techno qu'ils haïssent parce que provenant de Microsoft.
        
        J'ai a plusieurs occasions entendus des gens confronter Mono à des langages "libres". Comme si Mono n'est pas open-source ! Or, on peut dire ce que l'on veut sur les risques juridiques, le fait est que Mono est un logiciel libre.
        
        Personnellement je ne m'intéresse pas plus que cela à Mono, mais personnellement ce genre de comportement m'insupporte, voilà pourquoi je suis là à défendre (en partie) ce projet. Dois-je le répéter encore et encore ?
        
        Finalement Tomboy et F-spot se voit casser des tonnes de morceaux de sucres sur le dos alors qu'ils sont conçus à partir d'une techno sous licence libre, alors qu'Eclipse n'a jamais trainé de telle monceaux de haines derrière lui y compris lorsque la seule manière de le faire fonctionner sur un système "complètement libre" était d'utiliser GCJ.
        
        Et pourtant en nombre d'utilisateurs (et donc de potentiels dépendants à Java) entre Eclipse et Tomboy, il y a un gouffre.
        
        La seule chose qui explique cette haine c'est la haine anti-microsoftienne.
        
        Franchement je n'ai aucune sympathie pour Microsoft, mais je n'ai aucune raison non plus de détester par principe tout ce qui peut avoir été inspiré par Microsoft, repris à Microsoft etc.
        
        Sinon, comme je l'ai dis plus bas : disons bye bye à XMLHttpRequest. Non ?
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 17:03. Évalué à 2.
        
        Les risques juridiques sont bien évidemment réels, mais nous savons que ces risques existent également pour tout un tas de logiciels libres autres que Mono.
        
        Tu dois avoir des infos que je n'ai pas. Ou alors, tu fais références aux problèmes globals des brevets logiciels.
        
        Mais il faut être gonfler pour mettre ce risque sur le même plan que le risque juridique anti-FLOSS venant de MS.
        
        "pourquoi utiliser une techno Microsoft alors que nous avons les notres, dans le libre ?" etc.
        
        Quand C# est sorti, c'était vraiment je refais un Java purement MS...
        
        Sinon, comme je l'ai dis plus bas : disons bye bye à XMLHttpRequest. Non ?
        
        ben non, c'est standardisé aujourd'hui. Ce n'est pas un produit, c'est juste une spécification qui supporté par tout le monde (interopérable).
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 17:10. Évalué à 2.
        
        Mais il faut être gonfler pour mettre ce risque sur le même plan que le risque juridique anti-FLOSS venant de MS.
        C'est exactement le même type de risque, le même type de protection.
        
        Quand C# est sorti, c'était vraiment je refais un Java purement MS...
        Depuis le départ, .NET propose plusieurs langages ce qui en fait une plateforme différente dans l'esprit.
        
        ben non, c'est standardisé aujourd'hui.
        Comme C# ca tombe bien.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 17:18. Évalué à 3.
        
        Comme C# ca tombe bien.
        
        Mais pas les API (.NET ASP ?) qui sont elle breveté et ne font pas partie de la "promesse" de MS.
        
        Donc, non ce n'est pas pareil.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 17:20. Évalué à 1.
        
        T'es sous Linux, t'utilises la pile standardisée et les API du monde Linux. (OpenGL, GTK, etc.).
        Donc c'est pas ton problème.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par tanguy_k (site web personnel) le 08 juillet 2009 à 18:17. Évalué à 3.
        
        Et donc le multiplateforme -> à la poubelle ! tu parles d'une avancé !
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 18:19. Évalué à 1.
        
        quel est le rapport ?
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par tanguy_k (site web personnel) le 08 juillet 2009 à 19:14. Évalué à 5.
        
        Sous Linux tu vas utiliser C# + GTK# + ...
        Sous Windows, C# + WinForms/WPF + ...
        
        > Quand C# est sorti, c'était vraiment je refais un Java purement MS...
        >> Depuis le départ, .NET propose plusieurs langages ce qui en fait
        >> une plateforme différente dans l'esprit
        
        Et tout ce qu'avait apporté Java dans le domaine du multiplateforme (meme si ce n'etait pas parfait), .NET fait un trait dessus. Un grand retour en arriere, c'était quand meme l'innovation la plus flagrante de Java. Es un hasard ?
        Tout ce qui est multiplateforme est une atteinte au monopole de Windows. Si un jour une implementation libre bien foutue et multiplateforme de WPF existe, je suis persuadé que MS ne restera pas les bras croisés.
        
        On boucle la boucle : C# et CLI sont standardisés + sous Community Promise mais surtout pas les librairies autour. Il faudrait etre aveugle pour ne pas voir pourquoi.
        
        Le jour où WinForms/WPF, je ferais du .NET les yeux fermés.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 19:20. Évalué à 2.
        
        Sous Linux tu vas utiliser C# + GTK# + ...
        Bah sous Windows ca marche très bien GTK#, c'est quoi le problème ?
        
        Et tout ce qu'avait apporté Java dans le domaine du multiplateforme (meme si ce n'etait pas parfait), .NET fait un trait dessus. Un grand retour en arriere, c'était quand meme l'innovation la plus flagrante de Java. Es un hasard ?
        non c'est pas un hasard. MS avaient d'autres objectifs que ceux de Sun et a donc pondu une plateforme différente.
        
        Tout ce qui est multiplateforme est une atteinte au monopole de Windows.
        Microsoft distribue Silverlight sous Mac.
        
        C# et CLI sont standardisés + sous Community Promise mais surtout pas les librairies autour.
        Une partie des libs de base si quand même.
        
        Le jour où WinForms/WPF, je ferais du .NET les yeux fermés.
        Je comprends pas, tu attends la libération des API proprio intégrées à Windows pour utiliser .NET plutôt que d'utiliser les toolkits existants que sont GTK ou Qt ?
        Ca me dépasse.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par tanguy_k (site web personnel) le 08 juillet 2009 à 20:02. Évalué à 4.
        
        > sous Windows ca marche très bien GTK#, c'est quoi le problème ?
        
        GTK# sous Windows c'est anecdotique et "marche tres bien" est surement inaproprié. De plus le probleme n'est pas d'avoir des applis Linux qui tournent sous Windows, mais des applis Windows qui tournent parfaitement sous les autres OS. C'est ce dernier cas qui pose probleme à MS.
        
        > MS avaient d'autres objectifs que ceux de Sun
        
        En effet, l'objectif est de proteger Windows, le coeur de metier de MS, le truc qui permet de faire du pognon directement ou indirectement.
        Quand Java, techno multiplateforme, a débarqué, c'etait une atteinte au monopole de Windows. Chaque logiciel developpé en Java est une mini bataille de perdu pour Windows.
        La premiere solution de MS a ete d'adopter et modifier Java histoire que ca ne soit plus multiplateforme. Sun se rebiffe -> procès -> changer de solution.
        Deuxieme solution, creer sa propre techno et bien sur ne pas la rendre multiplateforme ou si peu (et faire semblant au passage). Chaque logiciel developpé avec les technos MS est une mini bataille de gagner pour Windows.
        C'est de bonne guerre, je serais MS je fairais pareil. Mais si j'ecris sur linuxfr c'est bien parceque je me situe dans "l'autre camp".
        
        > Microsoft distribue Silverlight sous Mac
        
        Parcequ'ils sont bien obligés ! tu crois qu'ils l'ont fait avec le sourire au levres ? Mac atteint presque 10% de pdm + la concurrence (Flash, Flex, XUL) est multiplateforme. Pour que Silverlight est une chance de séduire face aux autres technos similaires, ils n'ont pas franchement eu le choix.
        
        > Une partie des libs de base si quand même.
        
        C'est vrai, mais ca ne suffit pas pour faire des applis portables. C'est justement ce que je denonce et qui a mon avis a ete strategiquement voulu des le depart pour garder les pdm de Windows.
        
        > tu attends la libération des API proprio intégrées à Windows
        > pour utiliser .NET plutôt que d'utiliser les toolkits existants
        > que sont GTK ou Qt ?
        
        Je ne veux pas developper une GUI differente pour chaque OS qui existe. GTK+ sous Windows est assez mediocre et pire encore sous Mac. J'imagine en plus que le binding GTK# doit encore rajouter une couche d'emmerdes supplementaires.
        
        La politique de MS n'est pas transparente, je n'ai pas confiance et pour le moment je prefere C++/Qt en LGPL qui me permet de faire du multiplateforme. Tant pis pour le cote sexy de .NET/C#
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 09 juillet 2009 à 11:32. Évalué à 2.
        
        Tu tournes autour du pot, ta critique est qu'il te faut avant tout une application qui tourne bien sous Windows et qui tourne accessoirement sur d'autres OS.
        Moi je te parle de technos libres : GTK, Qt, toi tu me réponds WinForms.
        Désolé, on est sur LinuxFR, on a pas les mêmes priorités.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Zenitram (site web personnel) le 08 juillet 2009 à 13:32. Évalué à 2.
        
        Mais je parie que dans 2s tu va me dire que la formation ne sert à rien, qu'un diplome d'ingé ne vaut rien
        
        Allez, c'est moi qui le dit : pour la compétence d'une personne, non, ça ne sert à rien (et c'est un diplômé d'ingé qui le dit).
        J'ai vu des bons non-ingés et de mauvais ingés à jeter le plus rapidement possible sinon ils font couler la boite : ce qu'on apprend en école d'ingé prépare plus que la fac au monde de l'entreprise, mais ce n'est pas encore ça, il manque pas mal de choses qu'on apprend dans la vraie vie, donc diplôme ou pas, c'est pareil.
        
        Maintenant, oui, ça sert dans la vraie vie car c'est un critère de sélection des recruteurs, donc faut le faire.
        
        qu'un dea non plus.
        
        Ca ne vaut pas rien, mais bon, ça ne vaut pas grand chose non plus dans des métiers techniques (je met de côté les DEA "non techniques" où il n'y a souvent pas d'école qui fait la même chose)... (a part si tu veux faire de la recherche).
        A moins que ça ai changé en quelques années? (j'en doute...)
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Duncan Idaho le 08 juillet 2009 à 16:01. Évalué à 0.
        
        AAAAAAAaaah, ça y est, j'ai mis le doigt dessus.
        
        Tu es un connard prétentieux en fait.
        
        Pfiou, tout est plus clair d'un coup.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 16:10. Évalué à 3.
        
        Prends 2 personnes au hasard avec de l'informatique dans le CV, quel est la probabilité que la personne ingénieur (ou ayant un DESS) en informatique fasse plus l'affaire qu'une autre personne sans diplome ?
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Kangs le 08 juillet 2009 à 17:49. Évalué à 3.
        
        >>Moi, je note qu'un diplomé en philo veut m'expliquer l'informatique.
        >>Mais je parie que dans 2s tu va me dire que la formation ne sert à rien, qu'un diplome d'ingé ne vaut rien, qu'un dea non plus.
        
        Pour troller la philo est peut être plus efficace ;)
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Thomas Douillard le 08 juillet 2009 à 20:57. Évalué à 2.
        
        Le boulot des philosophes, c'est de troller, certe.
        
        Cela dit c'est pas le boulot des informaticiens, mais on y arrive quand même très bien, il suffit de voir le nombre de commentaire. C'est du boulot d'amateur, mais quels amateurs :)
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par lasher le 09 juillet 2009 à 01:33. Évalué à 2.
        
        « Le boulot des philosophes, c'est de troller, certe. »
        Ah bon ? J'aurais dit que c'était le boulot des pros de la sophistique/rhétorique. Cela dit, un bon philosophe se doit d'être un bon sophiste (cf. Socrate et Schopenhauer avec son art d'avoir toujours raison, par exemple).
        
        Un philosophe qui trolle, c'est un philosophe qui ne fait pas de philosophie (éventuellement, il s'amuse).
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Thomas Douillard le 09 juillet 2009 à 12:15. Évalué à 2.
        
        Je parlais plus du débat et de l'échange d'idée que du troll à proprement parler. Et il y a de quoi faire en philosophie question débat d'idée.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par pasBill pasGates le 08 juillet 2009 à 02:16. Évalué à 1.
        
        Moi, je pense que l'on attaque une technologie qui est la raison d'être de ton job. Et personne ne supporte que l'on puisse dire que sa compétence est issue d'une téchno plutot nuisible et qui sert tout sauf à aider l'utilisateur. Cela a un nom, cela s'appelle de la Dissonance_cognitive. C'est pour ça que PBPG ne pourra jamais critiquer fondamentalement son employeur.
        
        Et cela explique pourquoi les employes de Redhat ne pourront jamais critiquer Redhat, les employes de la FSF ne pourront jamais critiquer cette fondation, ceux de Mozilla aussi, etc...
        
        Ou alors ca marche dans l'autre sens: ils bossent la et continuent d'y bosser parce qu'ils considerent qu'il n'y a pas de probleme fondamental, et qui si il commencait a y en avoir un, ils partiraient.
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 08 juillet 2009 à 10:45. Évalué à 5.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par zebra3 le 08 juillet 2009 à 11:15. Évalué à 4.
        
        Justement, n'est-ce pas une preuve d'ouverture de la part de pasBill pasGates d'être présent sur ce forum ?
        
        Parce qu'on aura beau dire, la plupart du temps, il est loin de dire des conneries, et il ne dénigre pas Linux à tout bout de champ (ou tout au moins pas sans arguments concrets).
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par briaeros007 le 08 juillet 2009 à 11:27. Évalué à 2.
        
        s/la plupart du temps/de temps en temps/
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 12:23. Évalué à -2.
        
        il ne dénigre pas Linux à tout bout de champ
        
        Il "fud" subtile la plus part du temps, mais cela reste du FUD.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par zebra3 le 08 juillet 2009 à 12:50. Évalué à 1.
        
        Disons qu'il cite ses sources et qu'il y a de la recherche derrière ;-)
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par briaeros007 le 08 juillet 2009 à 17:14. Évalué à 3.
        
        lui citer ses sources ? Tu as vu ça où ? Tu as vraiment pas du participer a beaucoup de "débats" avec lui.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 13:02. Évalué à 2.
        
        Faudrait peut être revoir ta définition du FUD.
        Le FUD c'est discréditer un produit et/ou un concurrent en cherchant à semer le doute et la confusion chez l'interlocuteur en faisant des supposition invérifiables ou en prétant des intentions négatives sur des événements futurs.
        Le FUD en l'occurence dans ce débat, c'est Stallman qui le pratique.
        http://fr.wikipedia.org/wiki/FUD
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 16:12. Évalué à 3.
        
        Je sais c'est très bien tout ça. Et je maintiens ce que j'ai dis.
        "La première sécurité est la liberté"
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 08 juillet 2009 à 15:00. Évalué à 2.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Jean-Philippe Garcia Ballester (site web personnel) le 08 juillet 2009 à 15:11. Évalué à 0.
        
        L'i ?
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Gniarf le 07 juillet 2009 à 17:33. Évalué à 2.
        
        ce n'est pas du tout comme ça avec VMWare
        
        (oui je sais, je sors)
      - [^] # Re: Pourquoi Mono ?
        
        Posté par zebra3 le 07 juillet 2009 à 15:00. Évalué à 4.
        
        Python n'est bien entendu pas dans ce cas là puisque par définition on a le source.
        
        C'est loin d'être évident, puisque la VM génère à partir d'un script du bytecode Python, lequel peut être utilisé seul.
        
        De plus, il est également possible de créer des .exe pour Windows embarquant des scripts et librairies Python.
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
    - [^] # Re: Pourquoi Mono ?
      
      Posté par fearan le 07 juillet 2009 à 15:55. Évalué à -2.
      
      cool !!!!
      Perl vaincra !
      
      Bon mis à part ce commentaire tout à fait déplacé, je pense que le python devrait disparaitre, pour au moins 11 raisons ;)
      * Impossible de gérer le problème de faute de frupes lors d'affectation de variable.
      * Utiliser les regExp est d'un galère...
      * J'aimerai parler d'autres trolls ^^
      
      j'ajouterai que l'indentation par bloc c'est une horreur, et que c'est autant objet que le perl !
      
      Bon accessoirement je considère le python comme du script (je peux le lancer par ./pythonCaPueCestPasPerl.py)
      Mais comme langage de script perl et bash sont bien mieux ;)
      Il ne faut pas décorner les boeufs avant d'avoir semé le vent
      - [^] # OSEF
        
        Posté par Octabrain le 07 juillet 2009 à 16:04. Évalué à 1.
        
        Merci de ta participation passionnante !
      - [^] # Re: Pourquoi Mono ?
        
        Posté par Camille_B le 07 juillet 2009 à 16:12. Évalué à 1.
        
        Généralement ce genre de troll facile me gonfle, mais en ce moment, avec tous ces propos débiles autour de Mono (dont la moitié relève du "c'est du Microsoft donc merde"), c'est presque rafraichissant !
        
        Donc... merci !
        
        Lisp vaincra.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Kangs le 07 juillet 2009 à 19:17. Évalué à 3.
        
        "avec tous ces propos débiles autour de Mono "
        Toi aussi ces pro microsoft inconditionnels de mauvaises fois te gonfle : je te comprends !
      - [^] # Re: Pourquoi Mono ?
        
        Posté par zebra3 le 07 juillet 2009 à 17:41. Évalué à 3.
        
        Impossible de gérer le problème de faute de frupes
        
        Je n'arrive pas à me décider si c'est voulu ou pas...
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par fearan le 07 juillet 2009 à 17:52. Évalué à 3.
        
        évidemment que c'est voulu ;) Firefox avec le dico français ne laisse pas passer ça :) (par contre j'aurais pu taper fripes, et là le doute aurait subsité :P )
        
        PS : Et pour ceux qui se demandent si j'avais vraiment voulu lancé un troll, j'aurai fait bien plus subtil, et sans humour ;)
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par zebra3 le 07 juillet 2009 à 18:02. Évalué à 2.
        
        Note qu'en tentant de faire exprès une faute de frappe, tu as réussi à en faire une vraie !
        Tu aurais pu taper juste « frape », cela aurait marché aussi ;-)
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
  - [^] # Re: Pourquoi Mono ?
    
    Posté par Octabrain le 07 juillet 2009 à 13:57. Évalué à 4.
    
    Quel est vraiment l'intérêt d'avoir ces lourdes machines virtuelles qui exécutent du bytecode sur différentes archis ?
    Dans le monde du libre, comme le code source est disponible, on en a rien à battre d'avoir cet environnement qui fait abstraction de l'archi ! Dans le libre on prend le source et on le compile directement c'est tout.
    Oui, arrêtons aussi tous les langages de script, c'est une honte pour le logiciel libre.
    
    Actuellement, dans les langages multiplateformes sans VM populaires, n'a-t-on pas uniquement des langages préhistoriques, sans véritable gestion automatisée et intégrée de la mémoire, avec des problèmes de taille différente de nombres et d'endianess selon la plateforme, avec des horreurs sur les pointeurs à portée de main, etc. ?
    - [^] # Re: Pourquoi Mono ?
      
      Posté par MrLapinot (site web personnel) le 07 juillet 2009 à 14:38. Évalué à 4.
      
      Euh, OCaml et Haskell quand même... (il existe une VM pour Caml, mais elle n'est pas obligatoire, il y un compilateur natif pour certaines plate-formes).
      - [^] # Re: Pourquoi Mono ?
        
        Posté par Octabrain le 07 juillet 2009 à 15:15. Évalué à 2.
        
        Je vais réécrire ce que j'ai écrit puisque tu n'as pas bien lu :
        Actuellement, dans les langages multiplateformes sans VM populaires
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Dr BG (site web personnel) le 07 juillet 2009 à 15:48. Évalué à 2.
        
        J'avais compris que c'était la machine virtuelle qui n'était pas populaire. Peut être l'auteur du commentaire auquel tu réponds a compris la même chose.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par JoeltheLion (site web personnel) le 07 juillet 2009 à 16:20. Évalué à 3.
        
        Tu t'es jamais demandé pourquoi lesdits langages "préhistoriques" sont populaires?
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Octabrain le 07 juillet 2009 à 16:25. Évalué à 3.
        
        A cause du poids de l'existant ? Parce que la plupart des gens sont frileux ?
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par JoeltheLion (site web personnel) le 07 juillet 2009 à 16:29. Évalué à 4.
        
        Ben pas seulement. Personnellement j'ai essayé un bon paquet de langages, et là je développe en C++, parce que pour l'application que je développe, c'est le bon compromis entre performances, simplicité de programmation et disponibilité de bonnes bibliothèques (sur ce point je suis d'accord le poids de l'existant compte énormément).
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Octabrain le 07 juillet 2009 à 16:39. Évalué à 3.
        
        Là, tu parles de ton cas précis, c'est tout de suite moins objectif et ça permet de tirer moins de conclusions malheureusement.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par JoeltheLion (site web personnel) le 07 juillet 2009 à 16:59. Évalué à 2.
        
        Mais j'essaye juste de te démontrer que tous les gens qui programment en C ou en C++ ne sont pas des dinosaures frileux! Regarde le noyau linux par exemple: est-ce que tu crois sincèrement qu'il pourrait tourner sous mono ou n'importe quel autre langage "moderne", avec le même niveau de performances?
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Octabrain le 07 juillet 2009 à 17:02. Évalué à 2.
        
        Plus bas, j'ai dit en gros que C et C++ étaient bien trop utilisés dans des cas injustifiés.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par JoeltheLion (site web personnel) le 07 juillet 2009 à 17:04. Évalué à 2.
        
        Pour ça je suis d'accord. Quand tu dis que ce sont des langages préhistoriques, je ne suis plus d'accord.
    - [^] # Re: Pourquoi Mono ?
      
      Posté par Nicolas Boulay (site web personnel) le 07 juillet 2009 à 14:38. Évalué à -1.
      
      Les VM règlent les problèmes de tailles de nombres ?
      mmh je serais curieux de voir ça.
      "La première sécurité est la liberté"
      - [^] # Re: Pourquoi Mono ?
        
        Posté par Octabrain le 07 juillet 2009 à 15:16. Évalué à 4.
        
        Quand on veut pas comprendre, c'est de suite plus facile...
    - [^] # Re: Pourquoi Mono ?
      
      Posté par JoeltheLion (site web personnel) le 07 juillet 2009 à 15:54. Évalué à 8.
      
      Actuellement, dans les langages multiplateformes sans VM populaires, n'a-t-on pas uniquement des langages préhistoriques, sans véritable gestion automatisée et intégrée de la mémoire,
      
      A ma connaissance ces languages "préhistoriques" sont toujours ceux qui donnent les executables les plus performants en pratique.
      - [^] # Re: Pourquoi Mono ?
        
        Posté par Octabrain le 07 juillet 2009 à 16:08. Évalué à -2.
        
        C'est pas mal trollesque ce que tu dis là. Nul doute que tu seras plussé.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par JoeltheLion (site web personnel) le 07 juillet 2009 à 16:13. Évalué à 3.
        
        C'est juste que ça me casse les pieds de voir les théoriciens des langages répéter les mêmes inepties jour après jour.
        
        Ne me comprends pas mal, je pense qu'il y a une place pour les langages modernes, mais quand ils arriveront au niveau de performances brutes du C ou même du Fortran, ça se saura.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Camille_B le 07 juillet 2009 à 16:17. Évalué à 0.
        
        C'est juste que ça me casse les pieds de voir les théoriciens des langages répéter les mêmes inepties jour après jour.
        
        Ne me comprends pas mal, je pense qu'il y a une place pour les langages modernes, mais quand ils arriveront au niveau de performances brutes de l'Assembleur ou même du binaire, ça se saura.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par JoeltheLion (site web personnel) le 07 juillet 2009 à 16:33. Évalué à 2.
        
        On est d'accord, et donc la programmation en assembleur, en C ou en Fortran n'a rien de préhistorique, elle correspond juste à des besoins particuliers.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Camille_B le 07 juillet 2009 à 16:38. Évalué à 1.
        
        Bien sur.
        
        D'ailleurs la plupart des concepts que vantent les langages "modernes" existaient déjà dans LISP. Rien n'est vraiment neuf, rien n'est vraiment dépassé, tout est question de besoins, d'usages, et de préférences.
        
        Désolé d'avoir mécompris le sens initial de votre intervention.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Gniarf le 07 juillet 2009 à 17:53. Évalué à 6.
        
        comme tu sais ce qu'est une machine de Turing, il te suffit d'un marqueur et d'un rouleau de PQ.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Dr BG (site web personnel) le 07 juillet 2009 à 18:10. Évalué à 8.
        
        il te suffit d'un marqueur et d'un rouleau de PQ
        
        Avec un peu d'imagination, tu peux te passer du marqueur.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par patrick_g (site web personnel) le 07 juillet 2009 à 18:47. Évalué à 5.
        
        L'ennui c'est qu'il faut un rouleau de PQ qui soit infini.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Octabrain le 07 juillet 2009 à 16:40. Évalué à 1.
        
        Sauf que C (les 2 autres ils sont morts) (et éventuellement C++) sont encore utilisés dans des cas injustifiés, et c'est un problème.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par JoeltheLion (site web personnel) le 07 juillet 2009 à 16:44. Évalué à 3.
        
        (les 2 autres ils sont morts)
        
        Mon pauvre ami, si tu savais...
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Octabrain le 07 juillet 2009 à 16:45. Évalué à 1.
        
        J'ai dit "mort", j'aurais du dire "marginal".
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 07 juillet 2009 à 21:01. Évalué à 3.
        
        Il insiste :)
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Octabrain le 08 juillet 2009 à 11:42. Évalué à 2.
        
        ? Tu vas me dire que fortran est le langage majoritairement utilisé aujourd'hui ? N'hésites pas, tu n'es plus à une connerie près.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par JoeltheLion (site web personnel) le 08 juillet 2009 à 11:55. Évalué à 2.
        
        C'est toi qui dis que des conneries. Il n'y a pas de "langage majoritairement utilisé", ça dépend des applications et des domaines. Et dans le calcul scientifique à grande échelle sur supercalculateur, oui, le fortran est le langage majoritairement utilisé. Il n'est donc ni mort ni marginal, juste cantonné à une application, comme beaucoup de langages d'ailleurs.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Octabrain le 08 juillet 2009 à 12:00. Évalué à 2.
        
        Non, je parle tous domaines confondus, mais forcément tu refuses de considérer cette situation, elle te donnerait tort.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 12:45. Évalué à 2.
        
        Tu sais que tu es entrain de te ridiculiser totalement ?
        
        Par exemple, dans le domaine de l'embarqué, C doit représenter encore plus de 50% des développements.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Octabrain le 08 juillet 2009 à 13:07. Évalué à 2.
        
        Mais bon sang, j'ai pas dit "embarqué", j'ai dit "tous domaines confondus".
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par totof2000 le 08 juillet 2009 à 13:51. Évalué à 7.
        
        j'ai dit "tous domaines confondus".
        ... et ça n'a pas de sens .....
        
        1/ Fortran a-t-il déjà été utilisé pour autre chose que du calcul scientifique ? Cobol a-t-il déjà été utilisé autre part que dans le domaine de la finance ? Non, ça n'aurait pas de sens. De même que pour développer les couches basses d'un OS, on utilise l'assembleur et le C (qui n'est à l'origine qu'un assembleur amélioré).
        
        C'est comme si tu me disais que les sous marins permettant d'explorer le fin fond des océans sont morts parce qu'il ne représentent que 0,5% des sous marins utilisés ...
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Octabrain le 08 juillet 2009 à 13:56. Évalué à 1.
        
        Et C est utilisé dans tous les domaines, et ça tombe bien, j'arrête pas de dire que l'usage de C était très souvent injustifié.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par totof2000 le 08 juillet 2009 à 14:45. Évalué à 4.
        
        La dessus je suis assez d'accord avec toi .... mais cette tendance s'inverse.
        
        Le C est resté longtemps un langage utilisé dans plein de domaines parce que :
        - langage que n'importe quel étudiant voyait en cours donc facile de trouver des compétences
        - les performances des CPU ne permettaient pas d'utiliser des langages basés sur des VM pour des applis un peu lourdes. Même les applis en C++ pouvaient poser des problèmes de perf il n'y a qu'une dizaine d'années.
        
        De ce fait le C se révélait être un choix judicieux jusqu'à peu. Maintenant la puissance des CPU permet d'utiliser des VM ou des langages de plus haut niveau, et seules les couches basses de l'OS ou certaines parties précises de certaines applications ont besoin de perfs élevéses. Cependant, certains gros projets écrits en C ne peuvent bouger du jour au lendemain (Tu vois réécrire GTK en Python ou en Java ? ). Il faudrait une refonte complète. D'autre part beaucoup de boites ou labos disposent de bibliothèques déjà écrites en C, et il serait couteux de les réécrire dans un autre langage, ce qui explique que nombre de projets sont écrits en C encore aujourd'hui. Mais la tendance s'inverse, et c'est une bonne chose.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par lasher le 09 juillet 2009 à 02:07. Évalué à 4.
        
        Le C est peut-être utilisé dans « tous les domaines », mais si sa part fait dans les 50% dans l'embarqué (comme le dit Nicolas), dans le calcul scientifique, sa part est quasi-négligeable (tout est fait en Fortran à hauteur de 70% je dirais, de C++ pour 20%, et de divers trucs pour les 10% qui restent), dans le domaine de l'informatique de gestion on a vite compris qu'utiliser Java ou C# (couplé à un bon IDE) permettait d'éviter tellement de bourdes de la part du programmeur moyen que le C n'est plus parlé que pour maintenir des codes existants.
        
        En fait, le C a la dragée haute là où il a encore de l'intérêt : là où la gestion fine des ressources est importante -- donc l'embarqué, et dans une moindre mesure, si on confond C et C++, le calcul haute performance [1]. À cela il faut rajouter les boites qui font du middleware (genre fournisseurs de bibliothèques pour boites de jeux vidéo, ou d'applications ayant de fortes contraintes niveau perfs).
        
        Bref, le C est cantonné (comme la plupart des langages) à des niches technologiques.
        
        Dans le cas du logiciel libre, c'est différent. Le C est très souvent un « presque premier langage » (ou bien le premier « langage sérieux ») que beaucoup de dévs qui officient dans le libre utilisent. Ça reste un langage du cœur selon moi, et c'est pour ça qu'on voit tant d'applications utilisant le C là où d'autres langages seraient plus adaptés. Mais ce qui est drôle c'est que dans le même temps les langages de scripts (perl/python/ruby) sont aussi nés de la mouvance libre, et que ceux qui sont revenus de leurs errements en C en font l'apologie. C'est à la fois la grande force et la grande faiblesse du libre : la réactivité immédiate [2].
        
        Au contraire, ce qui fait qu'en entreprise encore plein d'applis se retrouvent écrite en C (++ ? ;-)) alors qu'on devrait clairement tout casser et recommencer avec des langages de script/4è génération (avec un temps de dév 5 fois moins grand), c'est qu'en fait, elles ne sont qu'étendues, ces applis. Pas écrites from scratch, mais plutôt maintenues. Il y a une très grande inertie, et forcément, le C peine à partir. De la même façon que Java a eu du mal à s'imposer au début (entre autres à cause de sa lenteur initiale), mais que ça fait bien 10 ans qu'il est à peu près clair que Java ce n'est plus « l'avenir », mais le présent (au sens d'une boite : sauf cataclysme, tant que l'appli tourne, on ne change rien).
        
        [1] Pour être précis, le C est souvent utilisé en tant que « glu » entre divers modules de compilation écrits en Fortran, typiquement pour les entrées/sorties ou les communications de type MPI.
        
        [2] Faiblesse aussi, car dès que ça brille on en voit souvent beaucoup se précipiter sur une nouvelle techno sans avoir bien digéré la précédente... Ça fait des gens touche à tout mais pas forcément pointus sur un domaine précis...
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Guillaume Denry (site web personnel) le 08 juillet 2009 à 12:35. Évalué à 2.
        
        homme de paille (ça faisait longtemps :) ) ; il n'a jamais dit que le fortran est le langage majoritairement utilisé aujourd'hui, juste sous-entendu qu'il n'est ni mort, ni marginal.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Octabrain le 08 juillet 2009 à 13:17. Évalué à 1.
        
        Et moi je pense - et je peux me tromper, mais depuis un moment on n'arrive même pas à s'accorder sur la nature du sujet duquel on parle, donc pour discuter le vrai contenu... - que, sur la somme des développements actuels, tous domaines confondus, et proportions gardées, fortran est marginal.
        Ces 2 liens suivants ne font que rapporter la quantité de discussion autour des langages de programmation sur internet, ce n'est pas une preuve, mais ça vaut un peu quand même : http://langpop.com/ et http://www.tiobe.com/index.php/content/paperinfo/tpci/index.(...)
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par lasher le 09 juillet 2009 à 02:06. Évalué à 1.
        
        Petit problème : Fortran est très souvent utilisé [1] pour faire de gros calculs, sur de grosses machines, très souvent coupées d'Internet. Des machins militaires quoi. Du coup les gens qui bossent sur ce genre de codes ont tendance à ne pas trop trop la ramener sur le net (entre autres parce que de toute manière, au boulot ils ont un accès ultra-limité au net le plus souvent).
        
        Sinon, pour tout ce qui est simulation numérique, on a des tonnes d'applications industrielles et académiques : simulation de combustion en 3D dans des fourneaux industriels, simulation de moulage de pièces métalliques à destination de divers moteurs de voitures/bus/etc, influence de l'air sur un avion en marche, prévisions météo, simulation des mouvements des plaques tectoniques, et modélisation de phénomènes naturels en règle générale, et j'en ai encore quelques uns en réserve si tu veux.
        
        De par ses origines, Fortran est principalement utilisé par des physiciens de formation. Mais j'ai eu sous la main des codes parlant souvent de machins incompréhensibles pour moi en mécanique des fluides, de résolution de Navier-Stoke ou Newton-Raphson qui font mal à la tête rien que pour piger les équations qui aident à résoudre des problèmes par la simulation là où avant il fallait aligner prototype après prototype jusqu'à obtenir le bon. On fait désormais une grande partie de simulation, ce qui fait gagner beaucoup de temps aux industriels. Bref, le Fortran a encore de très beaux jours devant lui. Simplement, ce n'est pas un langage « sexy » ou à la mode. Par contre il est diablement efficace dans ce pour quoi il a été conçu : l'analyse numérique. Et il est utilisé par beaucoup de gens, mais ce ne sont pas des informaticiens, donc du coup, tu en vois peu venir troller sur linuxfr...
        
        [1] Fortran = FORmula TRANslator, tout ça ...
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par suJeSelS le 08 juillet 2009 à 12:06. Évalué à 2.
        
        Ceci est vrai pour la plupart des langages, qu'on ne me dise pas que le C# plus un framework énorme soit utile par exemple pour développer un applet de bureau Gnome. En général le développeur prend le/les langage(s) qu'il connait le mieux parce qu'il se sent plus performant avec, donc on se trouvera toujours dans le libre avec des langages pas forcement adaptés à ce qu'on veut faire (je suis moi même victime de ce syndrome).
      - [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 07 juillet 2009 à 16:11. Évalué à 5.
        
        Sauf que pour beaucoup d'applications, ce que cherche un développeur c'est pas la peformance, c'est le meilleur compromis entre performance et pleins d'autres trucs :
        - simplicité
        - sécurité
        - compatibilité
        - popularité
        - support
        - fun
        - etc.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 07 juillet 2009 à 21:02. Évalué à 2.
        
        - Ne pas se faire engueuler par la hiérarchie
        - prendre le moins de risque
        - Parce que la démos brille plus
        - Parce que le chef a dit
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par lasher le 08 juillet 2009 à 02:44. Évalué à 5.
        
        - Parce que le chef a dit
        Tiens, comme Fortran dans le cas d'applications scientifiques, ou bien C++ (toujours dans le même cas), où tout a été tellement surchargé qu'au final on se retrouve à faire des machins horribles de type tab(i) plutôt que tab[i].
        
        Honnêtement, j'adore le C, je tripatouille l'asm toute la journée, mais les gens ne voient pas à quel point MS a été intelligent avec .Net.
        
        On a C#, certes, mais aussi VB (pour les masochistes), et F# (pour les adeptes de Caml), IronPython, IronRuby (bon OK pour ces derniers, les implémentations restent du domaine de l'expérimental), et tout se retrouve dans une seule et même VM. C'est ça le gros intérêt de .Net. Rien n'empêche ensuite de passer à du JIT (ah ben tiens, la VM le fait déjà), et même de demander une génération directement en binaire si vraiment on en a besoin -- mais souvent les justifications sont fumeuses, car pour continuer à bénéficier de la sûreté des types et autres joyeusetés, on se retrouve à devoir générer les garde-fous qui vont bien et les insérer dans le binaire résultat, et au final on ne va pas spécialement plus vite que VM+compilation JIT.
        
        De plus, là où en embarqué les ressources sont extrêmement rares/limitées (le problème est similaire dans le calcul haute-performance), dans le cas de l'informatique "généraliste", c'est rarement le cas. C'est en faisant entre autres ce constat que des compilateurs très intéressants tels que LLVM sont arrivés, avec un mode "VM-qui-se-spécialise" (et aussi tout le côté "je génère du code pseudo-asm bas-niveau mais avec des références aux CFG/DDG de la représentation intermédiaire) pour ceux qui peuvent attendre, et un mode "compilé-comme-les-grands" pour ceux qui veulent un résultat tout de suite, potentiellement moins bon que s'ils avaient accepté d'avoir une appli un peu plus lente au départ (mais bon, après tout dépend des impératifs).
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 14:03. Évalué à 2.
        
        bon OK pour ces derniers, les implémentations restent du domaine de l'expérimental
        IronPython est stable depuis un moment et déployé par Microsoft dans les outils de dev de Silverlight en association avec le DLR.
        
        mais souvent les justifications sont fumeuses
        Ben c'est quand même pratique pour des plateformes comme iPhone qui interdisent de faire du JIT.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par lasher le 09 juillet 2009 à 02:09. Évalué à 2.
        
        « Ben c'est quand même pratique pour des plateformes comme iPhone qui interdisent de faire du JIT. »
        
        Bien sûr, mais c'est pour ça que je parle de « souvent » et pas « toujours ». :-)
  - [^] # Re: Pourquoi Mono ?
    
    Posté par TImaniac (site web personnel) le 07 juillet 2009 à 14:01. Évalué à 10.
    
    Faire abstraction de la machine, c'est aussi fournir des services qui ne sont pas offerts en natif : introspection, gestionnaire de mémoire, protection contre les débordements, contrôle fin des droits d'exécution (sandboxing & co), interopérabilité entre les langages de programmation, gestion des exceptions.
    Une VM facilite aussi la création de nouveaux langages en proposant de base tous ces outils.
    C'est aussi faire abstraction des incompatibilités de la machine qui peut casser mon soft en C recompilé : 32 vs 64 bits, litle-big endian, etc.
    C'est aussi faire abstraction des incompatibilités de l'OS : gestion des threads notamment.
    C'est aussi utile dans des situations ou recompiler n'est pas une option : déployer une applet web par exemple ou bêtement exécuter du javascript sans utiliser d'interpréteur.
    
    Le coup du "c'est nécessaire pour le proprio qui cache les sources" est un mauvais argument, bien au contraire : ce type de VM a une sémantique bien plus proche du langage utilisé dans le code source : un coup de décompilateur permet de retrouver le code source dans un format proche de l'original (sans les commentaires forcement).
    - [^] # Re: Pourquoi Mono ?
      
      Posté par Nicolas Boulay (site web personnel) le 07 juillet 2009 à 14:41. Évalué à 5.
      
      Une VM facilite aussi la création de nouveaux langages en proposant de base tous ces outils.
      
      Pas plus qu'un backend de compilateur avec un langage inteermédiaire (llvm ?)
      
      C'est aussi faire abstraction des incompatibilités de la machine qui peut casser mon soft en C recompilé : 32 vs 64 bits, litle-big endian, etc.
      
      endian/big endian ne pose problème qu'avec les layout de fichier. Il suffit d'utiliser la bonne class de gestion du soucis dans le langage en question, ce n'est pas la VM qui fournis ça !
      
      C'est aussi faire abstraction des incompatibilités de l'OS : gestion des threads notamment.
      
      Si tes threads n'étaient géré que par la VM tu aurais de gros soucis de perf....
      "La première sécurité est la liberté"
      - [^] # Re: Pourquoi Mono ?
        
        Posté par Octabrain le 07 juillet 2009 à 15:18. Évalué à 0.
        
        Il suffit d'utiliser la bonne class de gestion du soucis dans le langage en question
        En français ça donne quoi ?
        Ah, et sinon, tu ne réponds pas à toutes ces interrogations.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 07 juillet 2009 à 20:29. Évalué à 2.
        
        En française ça donne : c'est un problème de lib pas de VM ou de langage.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Octabrain le 08 juillet 2009 à 11:52. Évalué à 2.
        
        Ah oui, "yaka utiliser une lib"... Non, ça devrait être géré de base dans un langage pas préhistorique.
        Il n'y a pas de convention entre les libs de smart pointers, les libs d'introspection, les libs de protection de débordements, etc. Cela impose d'apprendre chacune des libs que tu viendras à rencontrer (et qui pourtant auraient le même rôle, entre 2 libs de smart pointers par ex). Et tu risques vite de te retrouver à utiliser plusieurs de ces libs équivalentes à la fois dans un même programme (par exemple ton prog utilise libsmartfoo, et tu utilises libtoto qui n'a rien à voir, mais qui elle utilise libsmartbar), bonjour l'intégration, la cohérence, et la simplicité (bonjour les bugs aussi)...
        Devoir passer par des libs impose aussi que tu n'oublies jamais de l'utiliser en permanence (pour chacun de tes pointeurs pour une lib de smart pointers).
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 12:47. Évalué à 0.
        
        En général, ce genre de lib s'appelle la "standard lib". En C, il n'y en a pas vraiment de mieux que celle d'origine. En c++, il y a boost.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Octabrain le 08 juillet 2009 à 13:22. Évalué à 1.
        
        Boost n'est pas la standard lib malheuresement. Wikipedia dit qu'une partie en fera peut-être partie dans C++0x, ce sera donc peut-être en partie le cas un jour.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 07 juillet 2009 à 20:34. Évalué à 2.
        
        Ah, et sinon, tu ne réponds pas à toutes ces interrogations.
        
        En effet, je n'ai pris qu'un exemple puisque la réponse est toujours la même : La VM n'apporte rien la dessus. C'est pas le programme qui décide du layout mémoire, fichier ou réseau mais les spec, et tout cela peut se simplifier par une bonne gestion par lib.
        
        Concernant les autre point comme le 64 bits, cela se règle par recompilation.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 14:09. Évalué à 1.
        
        Concernant les autre point comme le 64 bits, cela se règle par recompilation.
        Je recompile et tout marche comme par magie. La taille des pointeurs et la taille d'un int qui change, ca perturbe aucun programme en C, c'est bien connu. Y'a aucune règle à respecter pour ne pas avoir de problème c'est bien connu.
        
        Tu réponds pas à tout le reste :
        - introspection
        - sandboxing
        - gestion des exceptions (le C++ doit intégrer un morceau de runtime pour ca)
        - protection contre les débordements (on parle de garantie, une lib n'offre pas de garantie)
        - gestion mémoire (on parle de garantie, pas de l'utilisation parfaite et sans erreur d'une lib)
        - déployer une applet web (recompiler dans le navigateur n'est pas une option).
        - proposer pleins de langages interopérables
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Zenitram (site web personnel) le 08 juillet 2009 à 15:00. Évalué à 2.
        
        La taille des pointeurs et la taille d'un int qui change, ca perturbe aucun programme en C
        
        Ca ne perturbe pas un programme bien écrit.
        Après, le passage en 64 bits peut montrer des bugs venant du programmeur.
        
        * int reste 32 bits, donc ça ne change pas.
        * void*, size_t passent en 64 bits, ce sont des pointeurs, si passer en 64 bits fait des problèmes, c'est que ta version 32 bits couvent un bug/crash, à corriger.
        
        - gestion mémoire (on parle de garantie, pas de l'utilisation parfaite et sans erreur d'une lib)
        
        La seule garantie d'une VM c'est de libérer la mémoire à la fin, comme en C. La VM garantie qu'elle fera à un moment donné (elle décide de ce moment) du vide, mais c'est tout, ça peut faire monter le besoin en RAM rapidement (oups : ça le fait).
        Oui, j'ai jamais compris le truc génial de la gestion laissée à la VM, je suis sans doute vieux jeu.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TortuXm le 08 juillet 2009 à 15:44. Évalué à 1.
        
        Les VM garantissent effectivement comme en C qu'à la fin de ton programme, il n'y aura pas eu de perte de mémoire. Mais elles garantissent surtout, et contrairement au C, que la mémoire utilisée puis devenue inutile puisse être libérée ou réutilisée avant la fin du programme. En C si on a un memleak, on le garde jusqu'à la fin du programme. Pas terrible pour une appli serveur... Elles empêchent aussi que les erreurs de débordement classiques sont évitées : on a des exceptions au lieu d'un core dump.
        
        Avant de bosser en entreprise je ne comprenais pas l'intérêt de laisser la gestion de la mémoire à une VM. Les perfs étaient en général moins bonnes que si on gère la mémoire soi même, et ça me paraissait plus relever de la flemme de gérer la mémoire que d'un besoin réel.
        
        Depuis que je bosse, je m'aperçois que certains concepts de base échappent totalement aux développeurs qui bossent avec moi.
        
        Je fais actuellement du J2EE et je ne connais personne qui soit capable ici de gérer la mémoire. Par exemple j'ai aidé à déboguer une lib JNI qui a été codée par des devs Java ne connaissaient pas le C++. Un exemple bien classique de ce que j'ai trouvé :
        
        char *code = new char[2]; fonction_de_remplissage_qui_vient_de_la_dll(code); // cette fonction définissait, entre autres, les valeurs de char[0] et char[1] conversion_char*_en_StringUTF8_pour_java(code);
        
        Ici personne ne comprenait pourquoi ça plantait. Pour eux, on réservait un espace de 2 caractères, point. Ils passaient totalement outre le fait que la doc mentionnait que code devait être une "null terminated string". Sous MSVC en mode debug, évidemment ça fonctionnait, avec des caractères genre ÿ aléatoires avant la fin de la chaîne.
        
        Ce genre de problème ne peut pas arriver dans une VM type Java parce que la mémoire n'est pas gérée par les développeurs.
        
        Je vois plutôt ça comme un aveu d'impuissance : on pense que les développeurs basiques feront des erreurs. On n'a pas assez d'énergie pour rendre les développeurs meilleurs, donc on leur masque la complexité et on trouve un langage dans lequel ils ne peuvent pas faire ces erreurs.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 16:22. Évalué à 2.
        
        Mais elles garantissent surtout, et contrairement au C, que la mémoire utilisée puis devenue inutile puisse être libérée ou réutilisée avant la fin du programme.
        
        ça c'est la théorie.
        
        En pratique, des bouts de mémoire peuvent y échapper selon le type d'algo utilisé (cf la discussion sur le sujet dans la news sur le nouveau langage).
        
        Une des VM les plus utilisé, arrête le code en cas de pénurie de mémoire, et fait une recopie total de la mémoire utilisée puis libère la 1er partie, cela double les besoin mémoires, et cela freeze le code pour un temps certain si il y a beaucoup de mémoire !
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TortuXm le 08 juillet 2009 à 16:40. Évalué à 2.
        
        Le cas général c'est quand même que la mémoire est libérée. Je veux bien qu'en pratique, ça ne marche pas toujours... Mais honnêtement, ça doit arriver bien moins souvent qu'un free oublié en C, ou qu'un delete qui manque en C++ ? Surtout qu'il arrive parfois qu'on ne sache pas quand exactement libérer la ressource, sauf à compter les références manuellement.
        
        Si on part du principe que les développeurs sont des tanches, la VM rajoute une sécurité au prix d'une occupation mémoire et CPU plus importante.
        
        Si on n'arrive pas à avoir des garanties quant à la qualité des dévs, c'est un moindre mal.
        
        Ça n'empêche pas qu'en dehors du boulot, j'utilise des langages un peu plus bas niveau, parce que je préfère gérer la mémoire moi-même, et que je ne vais pas travailler avec des développeurs qui ne savent pas gérer ces problématiques.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 17:04. Évalué à 2.
        
        Mais honnêtement, ça doit arriver bien moins souvent qu'un free oublié en C, ou qu'un delete qui manque en C++ ?
        
        oui mais aujourd'hui, il y a valgrind, et cela change tout.
        
        Surtout qu'il arrive parfois qu'on ne sache pas quand exactement libérer la ressource, sauf à compter les références manuellement.
        
        C'est souvent le problème d'une mauvaise encapsulation, non ?
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par lasher le 09 juillet 2009 à 02:19. Évalué à 2.
        
        « oui mais aujourd'hui, il y a valgrind, et cela change tout. »
        Tu supposes que tu as affaire à de bons programmeurs, capables de piger ce que sort valgrind. Honnêtement, c'est loin d'être toujours le cas ...
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 09 juillet 2009 à 11:50. Évalué à 2.
        
        L'effort n'est pas délirant par rapport à trouver le problème à la main. (genre le code plante parce qu'une fonction à coté fait un débordement de buffer sur une variable global...)
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par thedude le 09 juillet 2009 à 11:59. Évalué à 2.
        
        c'est du grand delire serieux.
        
        J'aimerais bien que tu m'expliques les situations dans lesquelles le GC de la jvm, par exemple, rate des blocks liberables.
        Pour autant que je sache, il marche, et plutot bien.
        C'est sur que si tu pense au reference counting de flash < 8, oui, les references circulaires ne sont pas liberees (et tres probablement d'autres trucs), mais on parle de technos contemporaines la, pas de ce qui se faisait ya 5 ans.
        
        Quand a repondre "valgrind" quand on te fait remarquer que le gc est plus fiable qu'une gestion manuelle, c'est du plus grand comique.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 09 juillet 2009 à 12:04. Évalué à 3.
        
        A ma connaissance, il y a peu de GC qui soit parfait.
        
        Il y a le reference counting qui a un gros cout d'execution à faire tourner des counter partout auquelle il faut rajouter ensuite un parcours pour attraper les cycles (et en cas de graphe ?).
        
        Il y a les systèmes de recopie par suivi des pointeurs, il y a la recopie en estimant que toute données est un pointeur.
        
        Les techniques de GC ne sont pas parfaite non plus. Ce n'est pas encore un moyen d'avoir un binaire qui tourne 10 ans sans problème.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par thedude le 09 juillet 2009 à 12:42. Évalué à 0.
        
        Les techniques de GC ne sont pas parfaite non plus. Ce n'est pas encore un moyen d'avoir un binaire qui tourne 10 ans sans problème.
        
        T'as craque ou quoi?
        Le nombre de serveurs critiques J2EE en prod, c'est quoi alors? Ils les redemarrent toutes les semaines pour liberer la memoire?
        
        Un bon gc est fiable. Oui, c'est couteux, l'astuce consiste donc a scheduler le GC de facon intelligente.
        Mais c'est surement plus fiable qu'une gestion manuelle (aussi bien pour les leaks que les core dumps).
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par briaeros007 le 09 juillet 2009 à 15:11. Évalué à 2.
        
        tu serais étonné de connaitre le nombre de serveurs de prods (et pas seulement windows) qui ont des redemarrage programmé et régulier.
        (et a contrario, une machine qui a un uptime trop important n'est pas bien.
        Chez un client, ils ont une machine qui a un uptime de 1400 jours (unix bien sur ;)) . Petit problème, il y a un arrêt électrique de prévu, et ils espèrent qu'elle va bien redemarrer XD )
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Octabrain le 09 juillet 2009 à 15:17. Évalué à 1.
        
        Les GCs dont tu parles sont des GCs dépassés, on a fait légèrement mieux depuis...
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 09 juillet 2009 à 16:45. Évalué à 2.
        
        Tu as des liens ?
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Gniarf le 09 juillet 2009 à 12:20. Évalué à 1.
        
        ouais enfin quelque part je ne vois pas l'interet de se pignoler 10 ans à choisir le BON langage sur la BONNE plateforme avec le BON matériel si c'est pour s'emmerder avec des MAUVAIS programmeurs...
        
        parce que bon au final c'est la recette pour une MAUVAISE solution
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Thomas Douillard le 09 juillet 2009 à 12:35. Évalué à 1.
        
        C'est parce que les programmeurs font partie de l'équation ?
        
        Pourquoi s'emmerder avec valgrind sur un projet ou ça sert à rien ?
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 15:47. Évalué à 2.
        
        Ca ne perturbe pas un programme bien écrit.
        Bref, ca n'offre aucune garantie.
        
        * int reste 32 bits, donc ça ne change pas.
        jor. la norme ne défini strictement rien.
        
        c'est que ta version 32 bits couvent un bug/crash, à corriger.
        Non, juste que le langage C n'offre aucune garantie de comportement d'une implémentation à l'autre.
        Sans parler du fait que tu es obligé d'avoir 2 binaires (voir n si tu as n architecture).
        
        La seule garantie d'une VM c'est de libérer la mémoire à la fin, comme en C.
        Non non et non. En C je peux très bien me balader n'importe où avec mes pointeurs dans mon espace mémoire et aller faire tout un tas de conneries qui vont influencer (négativement) l'exécution de mon programme et ajouter pleins de bugs.
        je te laisse imaginer tous les problèmes de sécu potentiels, à commencer par les célèbres débordement de tampon. Y'a des techniques pour limiter la casse au niveau OS (comme c'est le cas dans le dernier noyau linux), mais il n'y a aucune garantie offerte.
        Une VM garantie tous les accès mémoires, garantie qu'il y a bien un objet au bout et que tu es bien autorisé à y accéder.
        Une VM peut gérer des droits d'exécution sur un code tiers au sein du même processus grâce à ce cloisonnement et cette maîtrise du bytecode exécuté, un programme en C peut faire à peu prêt tout et n'importe quoi dans son espace utilisateur. C'est pas pour rien que toutes les applets web utilisent un modèle de VM (Java flash, etc.)
        
        Oui, j'ai jamais compris le truc génial de la gestion laissée à la VM, je suis sans doute vieux jeu.
        Certains disent que la gestion mémoire est tellement importante qu'il faut mieux la laisser au développeur.
        D'autres disent que la gestion mémoire est tellement importante qu'il faut mieux laisser ce travail à une machine.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 16:27. Évalué à 2.
        
        la norme ne défini strictement rien.
        
        Non mais en pratique, c'est le cas.
        
        Non, juste que le langage C n'offre aucune garantie de comportement d'une implémentation à l'autre.
        
        Il ne faut pas exagérer non plus. Le C est proche du cpu mais tout de même.
        
        Sans parler du fait que tu es obligé d'avoir 2 binaires (voir n si tu as n architecture).
        
        Exacte mais est-ce tellement génant ?
        
        Y'a des techniques pour limiter la casse au niveau OS (comme c'est le cas dans le dernier noyau linux), mais il n'y a aucune garantie offerte.
        
        Il y a aussi des techniques de compilation pour protéger les débordements de buffer. Mais il faut voir que ce n'est qu'une partie du problème, et que cela ne couvre rien des problèmes de haut niveau comme les "SQL injection", le X-site-scritping, et autre.
        
        Une VM garantie tous les accès mémoires, garantie qu'il y a bien un objet au bout et que tu es bien autorisé à y accéder.
        
        Sauf que tu compares C et une VM, cette propriété existe aussi dans d'autre langage compilé comme ocaml, haskel et autre. Enfin, tout les langage formels quoi :)
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Buf (Mastodon) le 08 juillet 2009 à 16:36. Évalué à 2.
        
        Non mais en pratique, c'est le cas.
        
        Ouais, tout comme il y a quelques années, en pratique, on avait sizeof(int *) == sizeof(int)
        
        Vaut mieux éviter de construire du code sur ce genre de suppositions.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 17:05. Évalué à 2.
        
        Cela dépend ou. Sur les micro 16 bits, les pointeurs pouvaient déjà être plus grand que int.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 17:10. Évalué à 2.
        
        Cela dépend ou.
        Là est tout le problème. CQFD.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Zenitram (site web personnel) le 08 juillet 2009 à 17:18. Évalué à 2.
        
        Là est tout le problème. CQFD.
        
        Euh... Mais il est où le problème???
        void*, size_t pour les pointeurs.
        int pour des entiers.
        
        Qu'ils soient différents ou pareil ne devrait rien changer au programme.
        
        Après, si le développeur a mis des int dans des pointeurs ou vice-versa, c'est le développeur qu'il faut changer!
        
        C/C++ permettent des bidouilles, c'est pas une raison pour le faire quand on a envie, juste quand on a besoin.
        J'attend la démonstration avec un exemple qui fait qu'un programme correctement codé se chie sur les tailles des entiers qui changent et qui sont différent des pointeurs avant de te laisser balancer des affirmations de ce type.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 17:22. Évalué à 2.
        
        Qu'ils soient différents ou pareil ne devrait rien changer au programme.
        T'as pensé au débordement ? Style je code sur une machine 64bits, je déploie sur 32bits après avoir fait bien gaffe à ne pas mélanger pointeur et valeur entière... et là paf erreur de calcul ! pourquoi ? Parcqu'à l'exécution mon algo a vite débordé les 32 bits, limitation que je ne voyais pas sur ma machine 64 bits.
        Aucun ingénieur n'est à l'abri d'une erreur comme celle là.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Zenitram (site web personnel) le 08 juillet 2009 à 17:34. Évalué à 3.
        
        T'as pensé au débordement ?
        
        Genre?
        
        Style je code sur une machine 64bits, je déploie sur 32bits
        
        int est de 32 bits dans les 2 cas, le test échouera ou réussira de la même manière.
        Certes, int n'est pas garanti à 32 bits, il peut faire 64 bits sur une machine 64 bits et 32 sur une machine 32 bits (en pratique : jamais vu).
        
        Quand on joue avec des grands chiffres, on le dit, on met "long long int " (ou plus standard int64_t, qui date de 1999!)
        
        Après si tu joues avec des size_t et les débordements, c'est toi qui l'a voulu.
        
        Pourquoi vouloir changer complètement de langage alors qu'il suffit de dire ce que tu veux (et donc mettre int64_t quand tu joue avec des chiffres qui peuvent faire un débordement)?
        
        Aucun ingénieur n'est à l'abri d'une erreur comme celle là.
        
        Si : il utilise les types qui correspondent à son besoin, ce n'est pas parce que le langage a 20 ans qu'il ne faut pas utiliser ses évolutions.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 17:38. Évalué à 2.
        
        Certes, int n'est pas garanti à 32 bits, il peut faire 64 bits sur une machine 64 bits et 32 sur une machine 32 bits (en pratique : jamais vu).
        Suffit d'utiliser les options -m32 et -m64 de GCC pour s'en persuader.
        
        ou plus standard int64_t, qui date de 1999!
        Le programmeur n'est pas parfait et ne connais pas tout.
        
        et donc mettre int64_t quand tu joue avec des chiffres qui peuvent faire un débordement
        Je suis un programmeur débutant, tu comprends j'ai écrits int dans mon programme et ca marchait très bien jusqu'à ce que je change de machine et que ca déborde.
        
        Si : il utilise les types qui correspondent à son besoin
        Personne n'est parfait et sait choisir pertinemment le type dont il a besoin. Si les programmeurs étaient parfaits et prenaient toujours les bonnes décisions, on se poserait pas toutes ces questions.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 17:45. Évalué à 3.
        
        L'incompétence n'est pas une excuse.
        
        tu peux trouver aussi des subtilités dans C#, je suis quasiement sûr que gérer proprement les exceptions ne doit pas être simple.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Gniarf le 08 juillet 2009 à 18:23. Évalué à 5.
        
        tu ne comprends pas, C## c'est comme PHP, même les cons peuvent programmer, sans chemise sans pantalon, sans jamais faire attention à rien, par exemple plus besoin de surveiller la consommation mémoire vu que 1) il y a un garbage collector qui fait tout tout seul comme un grand sauf coucher avec toi (mais Miguel de Icaza y travaille, on bénéficiera de l'épisode Bonobo) et 2) à 10 euros le giga de RAM qu'est ce que tu nous emmerdes sale pauvre lololol.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Zenitram (site web personnel) le 08 juillet 2009 à 18:09. Évalué à 2.
        
        Suffit d'utiliser les options -m32 et -m64 de GCC pour s'en persuader.
        
        Euh...
        Generate code for a 32-bit or 64-bit environment. The 32-bit environment sets int, long and pointer to 32 bits. The 64-bit environment sets int to 32 bits and long and pointer to 64 bits.
        
        Un int (le plus utilisé) reste sur 32 bits.
        
        Donc que je me persuade de quoi? Que j'aurai les même problème de int partout?
        Quelqu'un qui a mis "long" doit le faire en sachant ce qu'il fait, donc il connait le problème du 32 bits où long n'est pas en 64 bits (sinon il utilise int).
        
        Le programmeur n'est pas parfait et ne connais pas tout.
        
        Donc puisque le programmeur ne connait pas tout, vaut mieux le apprendre un langage nouveau plutôt que de lui apprendre int64_t? Gloups.
        
        OK, je comprend un peu ta réaction : tu reproches au C/C++ d'etre compatible avec l'existant. int est pour l'existant. Si tu apprends, tu apprends int64_t (10 ans déja!), donc pour un nouveau, ça ne change pas grand chose entre le 64 bits de C# ou celui du C... c'est int partout. Juste qu'il peut mal programmer si besoin (ou si envie) avec des long.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 18:19. Évalué à 2.
        
        Un int (le plus utilisé) reste sur 32 bits.
        Ok autant pour moi. M'enfin le problème est bien réel pour le long.
        
        Quelqu'un qui a mis "long" doit le faire en sachant ce qu'il fait
        Oué je développe sous un OS 64 bits et je constate qu'un long me permet d'avoir un algo fonctionnel. Par contre je ne pensais pas que mon programme aurait un comportement différent parcque je change d'OS. Désolé de ne pas lire les petites lignes et de faire cette grossière erreur de débutant.
        
        Si tu apprends, tu apprends int64_t
        mais tu peux aussi te retrouver à compiler un code écrit par une tierce personne, y'a 5 ou 10 ans, personne qui ne connaissais même pas d'architecture 64 bits, et tu te retrouves à dépatouiller un bug de merde qui est passé à travers les mailles du débuggueur.
        Et encore, c'est vraiment la merde parcque ton client t'as remonté le soucis, mais tu le reproduits pas sur ta machine (t'as une machine 32 bits et tu soupçonnes pas un instant que ton client utilise autre chose).
        Tu perds du temps, quand tu commences à comprendre tu es obligé de te taper une analyse fine du code, tu commences à demander au client que compilo il utilise, sur quel OS, tu tentes de reproduire, et tu te dis que le monde est vraiment pourri de perdre du temps sur ce genre de connerie.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Zenitram (site web personnel) le 08 juillet 2009 à 18:36. Évalué à 2.
        
        Ok autant pour moi. M'enfin le problème est bien réel pour le long.
        
        Pourquoi est-ce une problème?
        c'est voulu.
        Je ne comprend pas comment une fonctionnalité se transforme en défaut pour toi.
        
        Tu te raccroches aux branches car tu vois que ton int argumenté ne tient pas la route, et va sur long dont l'offre est faite pour ce qu'il fait (dépendant de la plate-forme), hum...
        
        Oué je développe sous un OS 64 bits et je constate qu'un long me permet d'avoir un algo fonctionnel.
        
        Quand une personne demande expressément que son entier soit de taille différente suivant la plate-forme, j'ai du mal à admettre qu'elle demande un type qui soit identique quelque soit la personne. C'est la personne qui ne sait pas communiquer, si je dis A quand je pense B, personne ne peut savoir que je pense B.
        
        mais tu peux aussi te retrouver à compiler un code écrit par une tierce personne, y'a 5 ou 10 ans,
        
        L'avantage avec C# est évident : tu ne peux pas.
        En fait, tu reproches au C des choses qui viennent avec des fonctionnalités qui n'existent pas avec C#, c'est débile comme argumentation!
        
        Désolé, mais non : tu donnes des exemples qui ont pour résultat :
        - C : on a des problème car ça a mal été codé.
        - C# : on doit tout recoder.
        
        Tu y vois un avantage à C#, j'en vois un inconvénient.
        Question de point de vue.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 19:02. Évalué à 3.
        
        Je ne comprend pas comment une fonctionnalité se transforme en défaut pour toi.
        C'est pas une fonctionnalité qui se transforme en défaut. C'est comme toute fonctionnalité : ca a des avantages et des inconvénients. L'avantage est d'avoir un type de donnée proche de la machine pour avoir de meilleur performance, l'inconvénient c'est la portabilité.
        
        Tu te raccroches aux branches car tu vois que ton int argumenté ne tient pas la route, et va sur long dont l'offre est faite pour ce qu'il fait (dépendant de la plate-forme), hum...
        Juste que j'ai pas choisi la bonne option du bon compilateur.
        Les int tenaient sur 16 bits à une époque. Un programme conçu à cette époque et recompilé sur un 32 bits peut donc avoir des souçis si le programmeur n'as pas pensé à l'avenir.
        
        Quand une personne demande expressément que son entier soit de taille différente suivant la plate-forme,
        Il n'en ai pas forcement conscient. Moi le premier je me suis fait avoir.
        
        C'est la personne qui ne sait pas communiquer, si je dis A quand je pense B, personne ne peut savoir que je pense B.
        On doit traduire un algo que l'on a dans la tête dans le langage de la machine (en tout cas un langage qui sera traduit pour la machine). Il y a forcement des erreurs de traductions dans l'interface chaise/clavier que veux-tu.
        
        L'avantage avec C# est évident : tu ne peux pas.
        C# a maintenant 8 ans :)
        
        Désolé, mais non : tu donnes des exemples qui ont pour résultat :
        - C : on a des problème car ça a mal été codé.
        - C# : on doit tout recoder.
        ???
        Si mon programme C# a 8 ans, je fais quoi en C ? je recode tout. Je comprends rien à ton argument foireux.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Zenitram (site web personnel) le 08 juillet 2009 à 19:14. Évalué à 2.
        
        Si mon programme C# a 8 ans, je fais quoi en C ? je recode tout. Je comprends rien à ton argument foireux.
        
        Il y a 8 ans :
        - Tu pouvais coder en C# sans pb avec les int
        - Tu pouvais coder en C sans pb avec les int.
        
        Ex-aequo.
        
        Tu a parlé de vieux code en C. Donc supérieur à 8 ans (sinon int=32 bits partout, et tu as int64_t pour le 64-bits et même int32_t pour être sur du 32-bits).
        Donc tu ne pouvais pas avoir la même chose en C# (qui n'existait pas à l'époque!), donc tu dois tout recoder en C#.
        CQFD.
        
        Tu inventes des problèmes qui n'existent pas et apporte des solutions impossibles (chronologiquement tout ça...)
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 19:16. Évalué à 2.
        
        Le problème que t'as aujourd'hui avec les long tu l'avais hier avec les int, c'est tout.
        L'âge n'y es pour rien.
        
        Tu inventes des problèmes qui n'existent pas et apporte des solutions impossibles
        Vrai problème rencontré dans la vraie vie.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par lasher le 09 juillet 2009 à 02:29. Évalué à 1.
        
        « En fait, tu reproches au C des choses qui viennent avec des fonctionnalités qui n'existent pas avec C#, c'est débile comme argumentation! »
        
        It's not a bug, it's a feature ? :-) Plus sérieusement, le problème de la taille des types (genre sizeof(char) == 1 d'après la norme, mais en fait, un char fait 16 bits à cause de contraintes d'alignement), ça existe depuis suffisamment longtemps pour que stdint.h ait été rajouté à C99, avec tous les types de taille fixe garantis qui vont bien. Ce n'est pas pour rien.
        
        Plus ça va, et plus je finis par admettre que le C n'est qu'un assembleur portable. Et pourtant, je fais de gros efforts pour être conforme avec C99, mais c'est vraiment *dur*, à cause de tous les comportement indéfinis que comporte ce langage.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 16:39. Évalué à 2.
        
        Non mais en pratique, c'est le cas.
        Jor. A quoi sert le sizeof ?
        A quoi servent les options -m32 and -m64 de GCC ? Pourquoi quand je change d'option mon sizeof me rend pas la même chose ? 4 et 8 dans l'autre ?
        
        Exacte mais est-ce tellement génant ?
        Oui, celà demande beaucoup de ressources supplémentaires :
        - des développeurs qui s'assurent que le code est "plateforme agnostic" et "compilateur agnostic"
        - des packageurs qui doivent prévoir autant de packages
        - de l'espace disque pour stocker toutes ces variantes (regarde Debian)
        - des ressources machines pour compiler tout ça.
        Sans parler du fait que certains ne 's'enmerde' pas à faire tout ce boulot (pas de temps ou soft pas assez populaire pour qu'un mec le fasse à ta place) et tu te retrouves à devoir faire le travail toi même, parfois t'es un simple utilisateur et t'as autre chose à foutre.
        Oui c'est génant je crois.
        
        et que cela ne couvre rien des problèmes de haut niveau comme les "SQL injection", le X-site-scritping, et autre.
        Effectivement, ca ne protège pas non plus ta grand mère au carrefour quand elle traverse. Mais ce que tu dis n'est pas faux.
        
        Enfin, tout les langage formels quoi :)
        Qui définissent tous une VM :) C'est parcqu'il y a production direct de code machine qu'il n'y a pas de VM. Une VM est une abstraction par nature virtuelle, in fine c'est toujours du code machine qui s'exécute.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 17:08. Évalué à 3.
        
        Qui définissent tous une VM :) C'est parcqu'il y a production direct de code machine qu'il n'y a pas de VM. Une VM est une abstraction par nature virtuelle, in fine c'est toujours du code machine qui s'exécute.
        
        C'est faux et archi faux. Tu as tous les LISP, tous les *ML, Scade sont compilé et n'ont pas de VM et te garantisse que jamais un pointeur ira se balader n'importe où. C'est le compilo qui fait ça.
        
        Je te dirais même que cette propriété à la con, est une pure expérience du C.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 17:14. Évalué à 2.
        
        C'est faux et archi faux. Tu as tous les LISP, tous les *ML, Scade sont compilé et n'ont pas de VM
        On a pas la même définition d'une VM c'est tout.
        C'est pas parcque tu produis du code natif que tu n'as pas de vu abstraite de la machine du point de vue du programmeur.
        
        est une pure expérience du C.
        Une pure expérience du code machine, dont les instructions manipulent des tailles de données différentes sur x86 et sur x64, ce qui conduit un langage qui définit une très faible abstraction comme le C a exposé ces différences dans les types primitifs.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 17:22. Évalué à 2.
        
        C'est pas parcque tu produis du code natif que tu n'as pas de vu abstraite de la machine du point de vue du programmeur.
        
        Abstraire la machine est le role des OS et des langages par rapport à m'asm pur et dur. Linux tourne bien sur plein d'archi différentes mais les logiciels C tournent tous dessus.
        
        une VM ce n'est pas que ça. C'est aussi un jeu d'instruction particuliers.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 17:26. Évalué à 2.
        
        C'est aussi un jeu d'instruction particuliers.
        Tout à fait.
        throw et typeid sont des instructions C++ qui sont tout ce qu'il y a de plus virtuelles (pas directement mappé sur des instructions machines) et participent ainsi à la définition d'une VM.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 17:28. Évalué à 3.
        
        C'est une construction du langage comme if, while ou goto qui générer ensuite des instructions machines.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 17:31. Évalué à 2.
        
        non, typeid suppose la présence d'information et de code complémentaire à l'exécution.
        Ce n'est pas directement mappable sur un sous-ensemble d'instruction machine.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 17:31. Évalué à 2.
        
        donc en C à cause des fonction comme longjump, setjump, c'est aussi une VM ?
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 17:42. Évalué à 1.
        
        Tout est une question de niveau d'abstraction. Y'a pas de limite rigide.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 17:46. Évalué à 2.
        
        Si, le jeu d'instruction. Soit c'est un bytecode, soit c'est du x86/x86-64/ppc/arm/mips...
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 17:54. Évalué à 2.
        
        Soit c'est un bytecode, soit c'est du x86/x86-64/ppc/arm/mips...
        Puisque je me tue à expliquer qu'on peut compiler du code C# en x86, c'est bien que la différence est ailleur.
        dans machine virtuelle, il y a virtuel. Que concrêtement le support de déploiement soit du bytecode, même si ca suppose un certain niveau d'abstraction, c'est un autre problème.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 18:08. Évalué à 2.
        
        Puisque je me tue à expliquer qu'on peut compiler du code C# en x86, c'est bien que la différence est ailleur.
        
        Si tu compiles en natif, il n'y a plus de VM. Un langage de haut niveau n'a pas forcément besoin d'une VM, c'est ça que tu ne veux pas comprendre.
        
        dans machine virtuelle, il y a virtuel. Que concrêtement le support de déploiement soit du bytecode, même si ca suppose un certain niveau d'abstraction, c'est un autre problème.
        
        Ben non. VM !=abstraction.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 18:22. Évalué à 2.
        
        Ok, donc toi ta définition de VM, c'est VM = JIT.
        Admettons. Donc le monde est parfait, y'a pas de soucis, C# n'utilise pas de VM du moment que t'utilises la bonne option sur ta machine de dev.
        Bizzare, ca change quasiment rien à l'exécution mais ca vaut un débat de 500 commentaires.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 18:27. Évalué à 2.
        
        Ok, donc toi ta définition de VM, c'est VM = JIT.
        
        non, les premières VM n'étaient pas JIT. JIT implique une compilation en code natif à la volé, cela ne couvre pas les interprétations directs du bytecode.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 18:32. Évalué à 2.
        
        Donc pour toi VM = JIT ou interpréteur.
        donc C# n'a toujours pas de VM quand il est utilisé avec la bonne option.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 18:39. Évalué à 2.
        
        Bah oui.
        
        La technologie pour faire exécuter un code, n'est pas lié au langage lui-même mais aux choix fait pour l'exécuter. Cf par exemple l'utilisation de tcc pour transformer du C en script shell en utilisant une sorte de JIT.
        
        C'est plus ou moins simple selon les cas. ocaml par exemple peut être compiler ou interprété.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par lasher le 09 juillet 2009 à 02:36. Évalué à 2.
        
        Euh. LISP a fait l'expérience des premiers ramasse-miettes et autres bidules qu'on trouve désormais dans les VM. Alors certes en tant que tel le langage n'a jamais eu besoin de VM, mais en pratique, on en était déjà vraiment pas très loin (je me souviens de mon prof d'IA qui racontait avec émoi ses lundi matin, où il lançait le garbage collector sur la machine, puis passait les 3h suivantes à siroter son café et préparer son prochain programme ...)
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 17:10. Évalué à 2.
        
        A quoi servent les options -m32 and -m64 de GCC ?
        
        Euh... il faut bien lui dire si tu veux compiler pour x86 ou x86-64...
        
        Pourquoi quand je change d'option mon sizeof me rend pas la même chose ? 4 et 8 dans l'autre ?
        
        Pour mettre sizeof() et non 4, dans ton code.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 17:12. Évalué à 2.
        
        Pour mettre sizeof() et non 4, dans ton code.
        Sauf que tu peux mettre 4. Le langage n'offre aucune garantie et le programmeur peut se louper. L'erreur est humaine.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 17:17. Évalué à 2.
        
        En C# tu peux aussi demander à ton code d'effacer ton disque dure, rien n'empêchera de faire ce genre de bêtise.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 17:29. Évalué à 3.
        
        A mon bon monsieur, pourquoi interdire le port d'arme à feu ? C'est vrai, malgré cette loi t'auras toujours un con pour se tuer avec un sac en plastique.
        
        C'est pas parcqu'il est impossible d'atteindre le risque 0 qu'il ne faut pas chercher à réduire les risques d'erreur.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Zenitram (site web personnel) le 08 juillet 2009 à 17:20. Évalué à 3.
        
        L'erreur est humaine
        
        Ah OK. Si le programmer fait une connerie et dit ce qu'il ne veut pas faire, c'est la faute du langage.
        Hum.
        
        Bon, les VM peuvent aider les mauvais développeurs, mais c'est limité.
        Si tu dis que tu veux effacer un fichier alors que tu pensais l'ouvrir, la VM ne corrigera pas la bêtise.
        
        Le mieux est de changer de programmeur.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 17:24. Évalué à 3.
        
        Personne n'est un dieu comme toi et ne code sans erreur (d'ailleur tu dois coder en assembleur suis-je bête, tu te fais pas chier avec les services offerts par la syntaxe C qui t'offre des garanties à la compilation).
        Les pauvres gens comme moi sommes imparfait tu comprends, on a le droit de travailler quand même où on doit changer de métier parcqu'il y a heuresement beaucoup de dieu comme toi ?
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par lasher le 09 juillet 2009 à 02:39. Évalué à 2.
        
        Bah il faut bien avouer que le C est limité. Comment je fais pour récupérer le bit d'overflow qui apparaît de temps en temps quand je fais de la crypto, moi, hein ? :-)
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par nicoastro le 09 juillet 2009 à 09:11. Évalué à 2.
        
        Avec une opération élémentaire sur les bits de poids fort ?
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par lasher le 09 juillet 2009 à 02:19. Évalué à 3.
        
        « int reste 32 bits, donc ça ne change pas. »
        Sur un système POSIX. En C ISO/ANSI, la seule garantie à ma connaissance, c'est la relation d'ordre : char <= short <= int <= long et si je ne me trompe pas, POSIX impose que la taille d'un int soit de 32 bits au minimum, sizeof(long) == sizeof(void *) == taille d'un registre (logique), etc.
        
        Et dans tous les cas, un long change de taille en passant de 32 à 64 bits. Les bons programmeurs C qui en plus connaissent bien les différentes normes sont quand même pas si nombreux que ça. Enfin si, quand c'est leur métier depuis des années. Sinon, en sortant d'école/fac, la plupart (moi le premier) ne savent que ce qu'on a bien voulu leur apprendre en cours (c'est-à-dire très souvent pas grand chose en terme de conformité avec la norme).
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Gniarf le 08 juillet 2009 à 16:08. Évalué à 3.
        
        > Tu réponds pas à tout le reste :
        > introspection
        RTTI. certes incomplet, lourdingue, pièce rajoutée, etc etc
        > gestion des exceptions (le C++ doit intégrer un morceau de runtime pour ca)
        euh, et ? c'est surtout que contrairement à Java (au pif) les exceptions ne remplacent pas une gestion d'erreurs rigoureuse et qu'elles ne devraient jamais arriver, et que quand une arrive, en général ton programme ne peut plus faire grand chose d'utile
        
        une exception dans le constructeur du 5ème Toto d'un tableau de 10, on fait quoi ? on ne sait pas forcément dans quel état il est, les autres non plus, souvent on ne sait meme pas lequel a planté. la vie est belle...
        
        > sandboxing
        yapa
        > protection contre les débordements (on parle de garantie, une lib n'offre pas de garantie)
        a[i] rapide au lieu de sûr
        > gestion mémoire (on parle de garantie, pas de l'utilisation parfaite et sans erreur d'une lib)
        idem
        
        donc bref, pas fait pour, héritage du passé ou choix de conception, ca se recouvre un peu.
        
        tout ça c'est se plaindre qu'un marteau ca fait mal quand on se tape sur les doigts avec. c'est... fait pour.
        
        ah, et qu'on ne me parle pas de garantie quand les VM plantent sans raison ni explication. c'est comme un cheque de banque garanti alors que la banque n'est pas sûre, ou carrément est en faillite : cette garantie ne vaut rien.
        
        > déployer une applet web (recompiler dans le navigateur n'est pas une option).
        les applets font bien souvent du JiT et c'est plantogène, Adobe comme Sun passent leur temps à corriger des problèmes de sécurité sur leurs VM, on a gagné quoi exactement ?
        
        > proposer pleins de langages interopérables
        
        ça n'a pas grand sens de comparer un langage avec une VM pouvant faire tourner divers langages via son interpréteur de bytecode. parce que l'OS qui fait marcher le langage il peut faire marcher d'autres langages aussi, et il y a, de fait, diverses possibilités d'interopérabilités.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 16:18. Évalué à 2.
        
        qu'elles ne devraient jamais arriver,
        D'où leur nom : exception :)
        
        Adobe comme Sun passent leur temps à corriger des problèmes de sécurité sur leurs VM, on a gagné quoi exactement ?
        Une nette amélioration par rapport aux ActiveX :)
        
        et il y a, de fait, diverses possibilités d'interopérabilités.
        Et à peu prêt autant d'impossibilité.
        Je te parle d'interopérabilité outofthebox, de langages qui définissent et échange de la même manière leurs classes pour les rendre utilisables directement.
        Quand je code en C# je dois pas me coltiner de bindings pour exposer mes classes aux développeurs VB.NET IronPython, Boo, C++/CLI. Ca marche, point. Une réelle interopérabilité.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Gniarf le 08 juillet 2009 à 16:53. Évalué à 4.
        
        > > qu'elles ne devraient jamais arriver,
        > D'où leur nom : exception :)
        
        dans certains langages, ça se passe tellement mieux qu'il faut bien en conclure que ça n'a pas le même sens partout, ni la même qualité d'implémentation, la même utilisabilité - utilité - en fait. un peu comme avec l'héritage multiple, Eiffel fait ça très bien.
        
        > > Adobe comme Sun passent leur temps à corriger des problèmes de sécurité sur leurs VM, on a gagné quoi exactement ?
        > Une nette amélioration par rapport aux ActiveX :)
        
        non :( c'est malheureusement complètement illusoire.
        
        en fait c'est même pire, on passe d'une situation où je ne suis pas concerné du tout par des ActiveX vérolés parce que j'utilise pas IE, à des situations avec des fichiers swf ou jar ou .class tout plombés (ou PDF, tiens), et Adobe qui prend son temps pour boucher les trous de son Flash Player. du coup il faut rendre son navigateur autiste et désactiver tout ces plug-ins...
        
        > Quand je code en C# je dois pas me coltiner de bindings pour exposer mes classes aux développeurs VB.NET IronPython, Boo, C++/CLI. Ca marche, point
        > Une réelle interopérabilité.
        
        de la poudre verte. les entrées/sorties standard, les pipes et autres named pipe... et des shells, des utilitaires et autres langages de script à foison...
        
        ca marche, point. une réelle interopérabilité. outofthebox. et c'est standard
        
        on ne vous a pas attendu, les lapins.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 17:00. Évalué à 2.
        
        du coup il faut rendre son navigateur autiste et désactiver tout ces plug-ins...
        On est d'accord, mais le problème vient plus de la multiplicité de code exposé. Y'a beaucoup trop de code "non fiable" qui se retrouve à tourner dans nos navigateurs.
        
        de la poudre verte.
        C'est mon quotidien cette poudre.
        
        les entrées/sorties standard, les pipes et autres named pipe... et des shells, des utilitaires et autres langages de script à foison...
        Gni ? Rapport ?
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Étienne le 09 juillet 2009 à 19:37. Évalué à 2.
        
        euh, et ? c'est surtout que contrairement à Java (au pif) les exceptions ne remplacent pas une gestion d'erreurs rigoureuse et qu'elles ne devraient jamais arriver, et que quand une arrive, en général ton programme ne peut plus faire grand chose d'utile
        
        une exception dans le constructeur du 5ème Toto d'un tableau de 10, on fait quoi ? on ne sait pas forcément dans quel état il est, les autres non plus, souvent on ne sait meme pas lequel a planté. la vie est belle...
        
        On sait très bien ce qu'on fait parce que la norme garantie que tout objet totalement construit voit son destructeur appelé. Donc dans l'exemple que tu donne, le destructeur des 4 Toto totalement construit seront appelés ainsi que le destructeur des membres du 5ème Toto. Le destructeur du 5ème Toto ne sera pas appelé en revanche. Le tableau ne sera de toute façon pas accessible car pas totalement construit.
        
        La seule chose à laquelle il faut faire attention c'est à la façon d'écrire le constructeur des classes qui véritablement font la gestion des ressources (smart pointer, classes RAII, handle de ressource, ...).
        
        Je serai curieux de savoir ce que Java (ou C#) apporte comme garantie supplémentaire à ce niveau là. L'impression que j'ai c'est que là où je me repose sur le finally en Java ou C#, je m'appuie sur l'appel du destructeur en C++.
        D'autre part, en C#, dans le cas de l'utilisation du using(), que se passe-t-il si une exception est levée dans le constructeur ? Et est-ce que la méthode finalize() est appelée (en C# ou en Java) lorsque le constructeur a levé une exception ?
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 09 juillet 2009 à 19:52. Évalué à 2.
        
        En C# le destructeur est appelé, mais pas le Dispose (ce qu'est censé appelé le using). Le destructeur est appelé quand le GC passe, plus tard donc.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 16:31. Évalué à 2.
        
        Si tu veux jouer...
        
        - introspection
        
        En quoi cela demande une VM ? GTK en fournis il me semble ?
        
        - sandboxing C'est pas simple à faire dans le même process, mais avec 2 process, cela commence à être plus simple.
        
        - gestion des exceptions (le C++ doit intégrer un morceau de runtime pour ca) Oui et alors ? C++ ne tourne pas sur une VM et dispose de la gestion d'exception en quoi faut-il une VM pour ça ?
        
        - protection contre les débordements (on parle de garantie, une lib n'offre pas de garantie) C c'est vrai, c'est faux en ocaml, en lustre, et tout les langages formels. On peut aussi parler des langages de scripts mais certain fonctionnent avec une VM, il pourrait faire sans.
        
        - gestion mémoire (on parle de garantie, pas de l'utilisation parfaite et sans erreur d'une lib) idem, tu penses au C,C++.
        
        - déployer une applet web (recompiler dans le navigateur n'est pas une option). comme le javascript ?
        
        - proposer pleins de langages interopérables Dans une certaine limite, je crois qu'il avait essayé de faire tourner du Fortran dans .NET et ils ont vite laisser tomber. Sinon, les autres langages passe par les API C, mais c'est vrai que c'est lourd.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 16:51. Évalué à 1.
        
        GTK en fournis il me semble ?
        A condition que tu respectes strictement les conventions de codage imposée par glib. A défaut d'avoir un langage qui offre la fonctionnalité, ils fournissent une lib en partant du principe que le programmeur va respecter les conventions que le compilateur est incapable de vérifier car ce n'est pas dans sa sémantique.
        
        Oui et alors ? C++ ne tourne pas sur une VM et dispose de la gestion d'exception en quoi faut-il une VM pour ça ?
        Ben si, en définissant les exception et typeid, C++ défini une VM. De base le code machine ne te propose pas ce genre de mécanisme, le compilateur est obligé d'ajouter du code et le langage de fournir une abstraction pour gérer celà, bref une VM.
        
        tout les langages formels.
        qui définissent tous une VM.
        
        comme le javascript ?
        javascript fourni au développeur un environnement virtuel d'exécution qui n'a rien à voir avec du code machine, bref une VM.
        
        Dans une certaine limite, je crois qu'il avait essayé de faire tourner du Fortran dans .NET et ils ont vite laisser tomber.
        Ca existe toujours.
        
        Sinon, les autres langages passe par les API C, mais c'est vrai que c'est lourd.
        Et encore, c'est qu'une convention qu'heureusement la plupart respecte... Mais tu retrouves d'autre problème comme le format des bibliothèques qui diffèrent d'un OS à l'autre par exemple.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TortuXm le 08 juillet 2009 à 16:55. Évalué à 4.
        
        Je ne vois pas pourquoi le fait de rajouter des métadonnées fait d'un code compilé une VM.
        
        C'est toujours pas du bytecode derrière, c'est vraiment du code compilé binaire et tout... Il y a quelques infos qui pourraient s'apparenter à des informations de débogage, mais je vois pas en quoi on peut qualifier ça de VM. Il n'y a aucun intermédiaire entre le code et la machine, contrairement à une VM.
        
        Après on a peut-être une définition des machines virtuelles un peu différente, vu ton affirmation.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 17:12. Évalué à 2.
        
        Je ne vois pas pourquoi le fait de rajouter des métadonnées fait d'un code compilé une VM.
        
        Bientot, C avec ses info de debug va être qualifier de tourner en VM :)
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 17:19. Évalué à 2.
        
        Je ne vois pas pourquoi le fait de rajouter des métadonnées fait d'un code compilé une VM.
        Ben le langage expose une sémantique qui n'existe par réellement : il propose une vue virtuelle au programmeur pour lui offrir un service.
        La conséquence peut être l'ajout d'information supplémentaire (le code compilé n'étant pas suffisant) pour rendre ce service à l'exécution.
        
        Il n'y a aucun intermédiaire entre le code et la machine, contrairement à une VM.
        GCC passe par une représentation intermédiaire, un truc de même niveau que le bytecode.
        Ce que fait un compilateur C : compilation => représentation intermédiaire => code machine exécutable.
        
        Ce que fait un compilateur C# compilation => représentation intermédiaire. Et le runtime : représentation intermédiaire => code machine exécutable.
        Sachant qu'il est également possible de faire exactement comme en C, à savoir tout avant l'exécution, il ne faut pas voir dans la compilation la définition de VM.
        
        Après on a peut-être une définition des machines virtuelles un peu différente, vu ton affirmation.
        Très certainement.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par lasher le 09 juillet 2009 à 02:50. Évalué à 2.
        
        « Ben le langage expose une sémantique qui n'existe par réellement : il propose une vue virtuelle au programmeur pour lui offrir un service.
        La conséquence peut être l'ajout d'information supplémentaire (le code compilé n'étant pas suffisant) pour rendre ce service à l'exécution. »
        
        Autant sur ce troll je suis globalement avec toi, autant ta définition de machine virtuelle est selon moi totalement erronée. Tu insistes beaucoup sur le « virtuel » dans « machine virtuelle », mais tu fais totalement l'impasse sur « machine ». C'est pourtant le mot le plus important, vu qu'il s'agit du nom (et pas de l'épithète qui lui est accolé). :-) Une machine virtuelle suppose nécessairement un jeu d'instructions intermédiaire. Le C, le C++, etc., n'en proposent pas, et ne sont donc pas des langages utilisant des VM. Le fait qu'un runtime plus ou moins léger soit rajouté à un langage n'en fait pas une VM. Sinon, que penser de machins comme OpenMP, qui permet de faire du parallélisme « facile » ? Il y a des directives/pragmas de compilation, une bibliothèque proposant tout un tas de fonctions utilitaires, ainsi qu'un runtime qui réagit entre autres à la topologie de ta machine, à l'existence et la valeur de certaines variables d'environnement, etc.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 09 juillet 2009 à 11:44. Évalué à 2.
        
        Désolé, mais pour moi la limite est vraiment trop flou pour pouvoir dire "tel langage utilise une VM", "tel autre non".
        Tu peux compiler du C# en natif (c'est prévu dès le départ)
        Tu peux compiler du C++ en natif
        Tu peux compiler du C# en bytecode .NET
        Tu peux utiliser un backend .NET pour GCC
        Un compilateur comme GCC utilise une représentation intermédiaire avant de transformer en code natif
        Un compilateur comme mcs utilise une représentation intermédiaire avant que mono transforme en code natif.
        
        Je préfères ma définition : une machine virtuelle est définie par un ensemble de jeu d'instruction différent du jeu d'instruction réel sur lequel s'exécute le programme.
        En étant relativement portable, un langage comme C s'appui implicitement sur une certaine abstraction du code machine.
        Dans tous les cas les processus d'exécution sont au final très proche, et ce qui change, c'est essentiellement la sémantique du langage (et donc l'ens
        emble des optimisations que peut réaliser le compilateur) et l'ensemble des services sur lesquels se base le langage (et des langages comme C++ montre que même à "bas-niveau" il y en a).
        
        Ta définition de VM (code intermédiaire nécessaire) me paraît trop réducteur. Je suis convaincu que l'on peut faire un compilateur C# qui génère directement du code machine.
        
        Si le bytecode est une réalité et que le compilateur C# cible un bytecode, c'est d'abord une question de déploiement : il est plus simple de déployer du bytecode que 15 versions de ton exécutable pour les 15 plateformes que tu veux supporter.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par totof2000 le 09 juillet 2009 à 12:38. Évalué à 3.
        
        Si on admet ta définition de la VM, tous les langages compilés utilisent une VM car ils passent tous par un niveau intermédiaire .....
        
        Ca n'a pas de sens.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TortuXm le 09 juillet 2009 à 11:34. Évalué à 2.
        
        Ben le langage expose une sémantique qui n'existe par réellement : il propose une vue virtuelle au programmeur pour lui offrir un service.
        
        Je peux dire la même chose d'une architecture en classes, ou même des structures du C ou de certains assembleurs. Les structures/classes sont des abstractions de la mémoire de l'ordinateur, elles permettent d'écrire du code plus portable (compare *(p+4) et p->variable par exemple). Ça n'en fait pas des VM.
        
        GCC passe par une représentation intermédiaire, un truc de même niveau que le bytecode.
        
        Et il le jette à la poubelle une fois le code machine généré,et c'est exactement ça la différence, à mon sens, entre une VM et un code natif. On pourrait faire une VM qui exécute le pseudo-langage généré par gcc.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 09 juillet 2009 à 11:48. Évalué à 2.
        
        Les structures/classes sont des abstractions de la mémoire de l'ordinateur,
        Enfin en C ce n'est pas vraiment une abstraction, plutôt une organisation.
        
        Mais oui, la limite est flou. Comme je le dis plus haut, en étant relativement portable (et donc relativement indépendant du jeu d'instruction machine), on peut définir une VM (un jeu d'instruction) qui serait l'ensemble nécessaire pour le langage C.
        
        Et il le jette à la poubelle une fois le code machine généré,et c'est exactement ça la différence, à mon sens, entre une VM et un code natif.
        Bah tu peux compiler du C# en code natif et ne garder que les métadonnées nécessaires à l'introspection (ce que propose mono). Exactement comme le fait C++ pour rendre son service d'introspection.
        
        La limite est vraiment flou, et tout est une question de niveau d'abstraction.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 09 juillet 2009 à 12:01. Évalué à 3.
        
        Mais non la limite n'est pas flou du tout.
        
        Elle est même évidente quand tu regarde l'exécution d'un programme sous VM et un binaire natif.
        
        Dans le cas du binaire, tu as le loader qui map le fichier en mémoire, puis la libc va chercher les libs dynamique qui vont bien, puis le program counter est mis sur le _main().
        
        Dans le cas d'une VM, (comme pour les shell), un programme est démarrer, la VM, qui ensuite lit le code sous forme de bytecode qui est une donné pour lui, et ensuite il le transforme pour soit l'interpréter, soit le compiler (JIT).
        
        La différence est flagrante !
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 09 juillet 2009 à 12:17. Évalué à 2.
        
        Tu sais très bien qu'on a pas la même définition, pour toi VM = interpréteur ou JIT.
        Cette définition n'a aucun intérêt dans le cas de C# où l'on peut se passer de ces 2 modes d'exécution et produire un binaire natif.
        Moi j'appelle un interpréteur un interpréteur, et un JIT un JIT.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 09 juillet 2009 à 12:45. Évalué à 2.
        
        Évidement que cela un intérêt.
        
        Si C# peut utiliser les 2 modes tant mieux. Mais cela ne rend pas le concept de VM comme flou.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 09 juillet 2009 à 13:07. Évalué à 2.
        
        Ok donc sachant qu'il n'y a pas de grosses différences à l'exécution entre une pré-compilation en code natif et la technique JIT en ce qui concerne le C#, on en déduit très logiquement que la VM n'a quasiment aucun impact.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 09 juillet 2009 à 13:09. Évalué à 2.
        
        Ou que le compilateur natif est mauvais.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 09 juillet 2009 à 13:17. Évalué à 2.
        
        Ca reste à démontrer: montre moi un compilateur plus rapide pour le même langage (sans toucher à la sémantique du langage, cad en offrant exactement les mêmes services).
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 09 juillet 2009 à 13:30. Évalué à 2.
        
        ocaml ? lisp ? Java avec gcj ? Mais je ne connais pas assez.
        
        En général, on développe un langage pour un usage avec un runtime. Faire 2 runtime est difficile et surtout a un intérêt pratique faible.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 09 juillet 2009 à 13:42. Évalué à 2.
        
        Pour démontrer que le compilateur est mauvais, je te demande juste de montre ce qui ne va pas dans le compilateur ou à défaut de me présenter un compilateur alternatif.
        Toi tu me proposes un compilateur qui fait autre chose (qui traduit un autre langage), c'est vrai que pour comparer c'est pratique.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 09 juillet 2009 à 13:52. Évalué à 2.
        
        Tu veux que je te trouve un compilo C# autre que celui de MS ? C'est une blague ?
        
        Je t'ai trouvé des exemples de langages ayant les 2 technologies. En OCaml, je crois que la version native est plus rapide que la VM.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 09 juillet 2009 à 13:57. Évalué à 2.
        
        C'est une blague ?
        Ben je connais au moins 3 implémentations différentes, mais bon forcement aucune ne démontre ce que tu avances.
        
        Je t'ai trouvé des exemples de langages ayant les 2 technologies.
        Super, mais tu changes plusieurs paramètres, donc tu démontres rien du tout. Peut être que c'est le traducteur JIT de OCaml qui est mauvais, va savoir.
        Ou peut être que le principal facteur c'est pas les outils mais la sémantique et les services qu'il y a derrière le langage... Le truc que j'appelle VM.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 09 juillet 2009 à 14:00. Évalué à 2.
        
        Ou peut être que le principal facteur c'est pas les outils mais la sémantique et les services qu'il y a derrière le langage... Le truc que j'appelle VM.
        
        je dirais plutôt leur capacité à être optimiser en statique, ce qui rend les langage comme perl et pyhton incapable d'être compiler correctement.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 09 juillet 2009 à 14:03. Évalué à 2.
        
        Oui tout à fait, le langage impose des règles que le compilateur doit respecter et intrinsèquement cela limite ses possibilités d'optimisation.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par lasher le 09 juillet 2009 à 14:53. Évalué à 2.
        
        Mmmh, les programmes générés par gcj ne sont au final pas plus rapides que ceux utilisant déjà une bonne JVM.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 09 juillet 2009 à 16:48. Évalué à 3.
        
        Dans des tests fait par qui ? Sun ?
        
        J'aurais tendance à dire qu'une VM doit pouvoir faire du code plus rapide que du natif dans certain cas et beaucoup plus lent dans d'autres.
        
        Par exemple, une bonne grosse boucle de traitement numérique avec la moitier des data étant constant pendant cette boucle (un gros filtre numérique sur une image par exemple); La VM peut te faire de la constante propagation et te simplifier de beaucoup le code avant d'en faire du code natif (pour un JIT).
        
        Par contre dans une grosse application métier, avec tout plein de code dans tous les sens, sans vraiment de grosses boucles de calcul, le jit ne fait pas vraiment effet car il y a trop de code en jeu et dans ce cas, le natif serait plus rapide.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 09 juillet 2009 à 17:02. Évalué à 2.
        
        Dans des tests fait par qui ? Sun ?
        http://shootout.alioth.debian.org/gp4/benchmark.php?test=all(...)
        
        Euh, une VM Java comme HotSpot compile (JIT) en code natif une ligne de code à la première exécution. Et c'est gardé en cache. Si tu repasses dans le même code tu repasses pas par du JIT.
        Bref y'a un temps de chauffe et après c'est principalement du code natif qui tourne.
        
        Franchement la compilation AOT, ca sert pas à grand chose, quelques cas tout de même :
        - réduire le temps de démarrage (pour un serveur on s'en tape le coquillard)
        - support des plateformes qui interdisent le JIT (iPhone coucou)
        - quelques améliorations de perfs qui demandent un algo d'optimisation long et pas faisable par JIT en live.
        - une moindre consommation mémoire.
        
        Cependant :
        - l'AOT peut être plus lent : le code binaire prend plus de place et doit être chargé entièrement au démarrage de l'application : le démarrage peut être plus lent, ce qui contrebalance nettement l'avantage précédement : des fois c'est plus rapide, des fois c'est plus lent.
        
        Pour 95% des applications, l'AOT n'apporte pas grand chose, au final c'est ce que fait le JIT en maintenant un cache.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 09 juillet 2009 à 17:18. Évalué à 2.
        
        En gros, tu accèptes de perdre du temps au début le temps que le JIT compile et ensuite, tu dépasses la vitesse du natif.
        
        En gros, tu dit aussi que le cache n'est pas petit et peut contenir une application complète.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 09 juillet 2009 à 17:59. Évalué à 2.
        
        En gros tu interprètes mal ce que je dis :)
        
        Je dis que la lenteur au démarrage du JIT (démarrage à froid) est partiellement compensé par le fait que l'AOT a également d'autres raisons d'être plus lent au démarrage. Bref au final, c'est du cas par cas.
        
        Dans tous les cas, pour la majorité des applications, les avantages du JIT sont ailleurs : fournir un bytecode indépendant de la machine.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 09 juillet 2009 à 18:08. Évalué à 2.
        
        Comment le code natif peut être plus lent que le code bytecode ?
        
        Tu considères la VM comme préchargé avec toutes les bonnes lib ?
        
        Tu considères par défaut qu'un bytecode est plus compacte que du code natif, donc que la copie mémoire est plus longue ? (ce qui est faux en passant, difficile de faire plus compact que du x86)
        
        Pour moi, la VM a un dilemme entre travailler le code pour le rendre ensuite plus rapide et l'interpréter au plus vite pour ne pas avoir une trop grosse latence.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 09 juillet 2009 à 18:30. Évalué à 2.
        
        Comment le code natif peut être plus lent que le code bytecode ?
        tu lis où tu reposes la question pour le fun ?
        J'ai tenté d'expliquer qu'il y a des différences liées aux nombre d'I/O au démarrage.
        J'ai jamais dis qu'en cours d'exécution le code natif était plus lent.
        
        (ce qui est faux en passant, difficile de faire plus compact que du x86)
        J'adore tes affirmations gratuites théoriques qui ne se vérifient pas en pratique.
        Tu peux concevoir qu'une instruction écrite dans un bytecode de plus haut niveau corresponde à un paquet d'instructions en code machine ?
        
        Pour moi, la VM a un dilemme entre travailler le code pour le rendre ensuite plus rapide et l'interpréter au plus vite pour ne pas avoir une trop grosse latence.
        Ca c'est le dilemme des VM Java effectivement.
        Le bytecode .NET a été conçu dès le départ pour être compilé en code natif. C'est une différence fondamentale qui fait que .NET ou Mono n'interprête jamais le bytecode .NET (mono a un interprêteur pour d'autres raisons) alors que la VM HotSpot pour Java travaille comme tu l'indiques.
        
        Dans tous les cas, ca ne change rien à ce que je disais au départ : même s'il y a un léger écart au niveau perf, il est la plupart du temps minime.
        C'est donc pas la présence d'un compilateur JIT qui fait qu'un programme écrit en C# ou Java est plus lent qu'un programme écrit en C.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 09 juillet 2009 à 19:00. Évalué à 2.
        
        tu lis où tu reposes la question pour le fun ?
        
        je pensais au démarrage.
        
        Tu peux concevoir qu'une instruction écrite dans un bytecode de plus haut niveau corresponde à un paquet d'instructions en code machine ?
        
        Et est-ce que tu peux aussi imaginer l'inverse ?
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 09 juillet 2009 à 19:11. Évalué à 2.
        
        Et est-ce que tu peux aussi imaginer l'inverse ?
        Je peux l'imaginer, c'est juste toi qui a du mal à imaginer la réalité :)
        Tu devrais pratiquer un peu plus, la pratique répond à beaucoup de questions :)
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 09 juillet 2009 à 19:20. Évalué à 2.
        
        Pratiquer du mono ? :(
        
        Disons que j'avais déjà vu cette légende urbaine concernant la taille des binaires (java à l'époque). Tout ça était venu de la taille des instructions limitées à 1 octets, une instruction étant forcément plus petites que les 16 bits ou plus d'un cpu classique.
        
        Sauf que l'on parle de jeu d'instruction à pile, ce qui signifie "plein" d'instructions à pile pour émuler une seul instruction à registre.
        
        Donc, je voulais savoir si tu avais des arguments autre que des argument d'autorité.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 09 juillet 2009 à 19:47. Évalué à 2.
        
        Répertoire de c:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089
        
        12/08/2008 10:28 4 546 560 mscorlib.dll
        1 fichier(s) 4 546 560 octets
        
        Répertoire de C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\mscorlib\9adb89fa22fd5b4ce433b5aca7fb1b07
        
        12/08/2008 11:20 11 485 184 mscorlib.ni.dll
        1 fichier(s) 11 485 184 octets
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 09 juillet 2009 à 19:55. Évalué à 2.
        
        le 1er est compressé non ?
        
        si tu zip les 2, la taille restent en proportion ?
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 09 juillet 2009 à 20:03. Évalué à 2.
        
        09/07/2009 18:00 1 732 915 mscorlib.zip
        12/08/2008 10:28 4 546 560 mscorlib.dll
        09/07/2009 18:00 4 861 833 mscorlib.ni.dll.zip
        12/08/2008 11:20 11 485 184 mscorlib.ni.dll
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 09 juillet 2009 à 20:05. Évalué à 2.
        
        Et au niveau des lib de C#, elles sont embarqués avec le binaire lors d'une compilation native ? Parce que la différence me parait pas mal importante.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 09 juillet 2009 à 20:25. Évalué à 2.
        
        Aucune idée. A priori le code natif a besoin des metadonnées mais pas des instructions .NET en soit. Après va savoir ce que fait ngen, je suis sous Windows et je maîtrise mal cet outil :)
        Dans tous les cas, l'avantage est au bytecode puisque l'image native fait plus du double.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 09 juillet 2009 à 22:54. Évalué à 2.
        
        Avec Mono, j'ai des résultats comparables :
        2214400 2009-07-09 20:36 System.Web.dll
        4503320 2009-07-09 20:41 System.Web.dll.so
        330944 2009-07-09 20:41 System.Web.dll.metadatas
        
        J'ai généré uniquement les meta-datas (qui sont également présentent dans System.Web.dll et System.Web.dll.so) pour avoir une idée de leur taille, ces informations étant indispensable, que ce soit pour le code natif ou le bytecode.
        On peut en déduire la taille du bytecode pour cet assembly :
        2214400 - 330944 = 1883456
        
        Si on suppose que System.Web.dll.so contient meta + bytecode (pour quoi faire, je sais pas) et code natif, ca donne un code natif 21% plus gros que le bytecode.
        Si on suppose que System.Web.dll.so contient meta + code natif mais sans bytecode (ce qui semble logique), ca donne un code natif 121% plus gros que le bytecode.
      - [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 07 juillet 2009 à 15:49. Évalué à 2.
        
        Pas plus qu'un backend de compilateur avec un langage inteermédiaire (llvm ?)
        Forcement, c'est une VM.
        
        endian/big endian ne pose problème qu'avec les layout de fichier.
        Oui, c'est un problème. http://www.ibm.com/developerworks/aix/library/au-endianc/ind(...)
        
        Si tes threads n'étaient géré que par la VM tu aurais de gros soucis de perf....
        Et ? Je parle d'abstraction, dessous y'a du code natif et les threads de l'OS, c'est bien le but.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 07 juillet 2009 à 20:32. Évalué à 1.
        
        Oui, c'est un problème.
        il faudrait lire les liens que tu donnes...
        
        Why is endianness so important? Suppose you are storing integer values to a file, and you send the file to a machine that uses the opposite endianness as it reads in the value. This causes problems because of endianness; you'll read in reversed values that won't make sense.
        
        Donc, 1) cela se règle en lib 2) si tu décides d'écrire du big endian et que relis en little tu aura des soucis VM ou pas VM.
        
        Et ? Je parle d'abstraction, dessous y'a du code natif et les threads de l'OS, c'est bien le but.
        
        Et en quoi une lib ne fournit pas d''abstraction ?
        "La première sécurité est la liberté"
    - [^] # Re: Pourquoi Mono ?
      
      Posté par meumeu1402 le 07 juillet 2009 à 15:32. Évalué à 0.
      
      "gestionnaire de mémoire, protection contre les débordements, contrôle fin des droits d'exécution (sandboxing & co), interopérabilité entre les langages de programmation, gestion des exceptions."
      
      Ca permet donc de palier au faille de l'OS et des mauvais programmeurs ? Je préfère avoir du code bien écrit, vérifié par plein de monde et un OS qui gère ça d'origine plutot que d'avoir encore une couche supplémentaire qui permet de cacher tous ces problèmes ...
      Ça me fait penser aux antivirus ...
      Et si on faisait tourner un daemon pour vérifier la vm, on sait jamais ... de toute manière on à de gros cpu, disque dur et plein de ram à disposition ... et les utilisateurs ils s'en fouttent, ils ont qu'a racheté une machine si c'est trop lent
      - [^] # Re: Pourquoi Mono ?
        
        Posté par Buf (Mastodon) le 07 juillet 2009 à 15:46. Évalué à 1.
        
        Même avec du code bien écrit, tu auras beaucoup de mal à implémenter du sandboxing sans VM, alors que c'est très simple à faire en Java (et sans doute aussi en .Net)
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par briaeros007 le 07 juillet 2009 à 19:08. Évalué à 2.
        
        tu veux sans doute parler des chroot, jail, grsecurity etr autre zones ?
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Buf (Mastodon) le 07 juillet 2009 à 19:27. Évalué à 2.
        
        Non, je parle de vrai sandboxing, où on pourra donner des privilièges différents suivant l'origine du code au sein du même processus.
        
        L'exemple type, c'est une applet Java : même si la VM qui la fait tourner a tous les privilèges de l'utilisateur courant, l'applet ne pourra pas accéder aux fichiers du disque, ni établir de connexions réseaux avec d'autres serveurs que celui d'où vient le code.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par briaeros007 le 07 juillet 2009 à 19:44. Évalué à 2.
        
        Non, je parle de vrai sandboxing, où on pourra donner des privilièges différents suivant l'origine du code au sein du même processus.
        Très simple a faire en "java" ou en ".net" ?
        
        Tu m'explique déjà comment tu donnes des privilèges différent au sein du _même_ processus, que ce processus soit géré par le noyau ou la vm ?
        
        Ah moins que tu ne considère que la vm est "le processus", et que le code executé (applet ou autre) ne sont pas constituf d'un processus (dans la vm).
        
        Dans ce cas ca veut dire que tu exécute un code dans un conteneur, non/faiblement audité avec des droits extrêmement étendu par rapport à ce que fait le code.
        
        même si la VM qui la fait tourner a tous les privilèges de l'utilisateur courant, l'applet ne pourra pas accéder aux fichiers du disque, ni établir de connexions réseaux avec d'autres serveurs que celui d'où vient le code.
        Même chose si tu lance ton applet avec ou les bonnes règles selinux et/ou setuid=nobody
        Ta vm fait juste tourner un processus, et gère ce processus.
        
        Attention, je ne dis pas que la vm est forcément un mauvais choix, mais il faut savoir l'utiliser avec recul et ne pas reposer la sécurité sur la vm. la vm est un _ajout_, ni plus ni moins. Et en plus c'est du code bien lourd, et peu audité (comparé au noyau)
        Bref croire que parce que c'est dans une vm c'est plus sécure qu'un système bien configuré, c'est faux.
        
        Une vm a un intérêt : reposer la sécurité sur des composants utilisateurs et non pas systèmes. Elle est aussi souvent plus simple a gérer car ne gère qu'un seul type particulier d'interaction itou.
        
        Les deux sont utiles, les deux ont des buts différents, mais intrinsèquement, la sécurité finale doit toujours être assuré par le système.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Buf (Mastodon) le 07 juillet 2009 à 19:57. Évalué à 3.
        
        Tu m'explique déjà comment tu donnes des privilèges différent au sein du _même_ processus, que ce processus soit géré par le noyau ou la vm ?
        
        En Java, la VM est capable d'analyser la pile d'appel et de déterminer l'origine du code qui tente d'effectuer une opération privilégiée (comme l'accès à un fichier) À coté de ça, elle pourra avoir un fichier de politique de sécurité, indiquant quel code possède quelles permissions. Si du code "non-trusted" (du code télécharger sur Internet, par exemple) tente d'effectuer une opération sans y être explicitement autorisé, il y aura une exception. Mais à côté de ça, le code "trusted" (fourni par l'application) pourra avoir des permissions plus souples.
        
        Par défaut, ce mécanisme est désactivé (n'importe quel code peut faire n'importe quoi), mais ça s'active et s'utilise très facilement.
        
        Même chose si tu lance ton applet avec ou les bonnes règles selinux et/ou setuid=nobody
        
        Non, parce que l'environnement d'exécution pourra avoir besoin d'accéder à des fichiers locaux (un fichier de préférences, par exemple), mais on voudra quand même empêcher l'applet de lire quoi que ce soit sur le disque local. C'est possible parce qu'on peut donner des permissions différentes aux classes de base et à celles téléchargées.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par briaeros007 le 07 juillet 2009 à 23:49. Évalué à 3.
        
        À coté de ça, elle pourra avoir un fichier de politique de sécurité, indiquant quel code possède quelles permissions.
        J'en reviens donc a ma question :
        Comment tu définis tu différencie tes codes ?
        
        Si pour toi "code" c'est une execution d'un .class ou une connerie comme ça, oublie tout de suite, tu parle juste de processus (à l'intérieur de ta vm).
        
        Et les règles de sécu d'un processus dans une vm java, on peut lui donner les mêmes, voir bien plus, avec un processus noyau.
        
        Ensuite c'est la difficulté a implémenté cette solution, mais intrinsèquement la vm n'apporte pas un "plus de sécurité", elle apporte bien un "plus de sécurité" car elle gère plus facilement la sécurité (c'est au niveau de l'administration que la sécurité s'effectue, et pas au niveau du processus en réalité).
        
        Je te met un contexte non_trusted* en level non_trusted* et catégorie non_trusted* sur le code par défaut, ben ton appli elle va s'amuser a faire quoi que ce soit.
        
        * catégorie, level, contexte non standard, mais rien n'interdit de les créer ;)
        
        mais ça s'active et s'utilise très facilement.
        Et c'est la la _seule_ différence a mes yeux : ca s'utilise très facilement (soyons franc, selinux est plutot assez compliqué a utiliser et a configurer. Mais très très très puissant).
        
        Non, parce que l'environnement d'exécution pourra avoir besoin d'accéder à des fichiers locaux (un fichier de préférences, par exemple), mais on voudra quand même empêcher l'applet de lire quoi que ce soit sur le disque local.
        C'est pas l'applet qui lis mais la vm, la nuance est de taille.
        En gros tu viens de montrer un changement de contexte lors d'un exec.
        
        Bref, ca reste possible d'un point de vue noyau, mais encore une fois je suis bien conscient que l'administration est sans commune mesure.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Buf (Mastodon) le 08 juillet 2009 à 00:42. Évalué à 2.
        
        Comment tu définis tu différencie tes codes ?
        
        Admettons que ton code essaie d'ouvrir un fichier. La méthode d'ouverture de fichier va appeler un SecurityManager (c'est l'objet responsable de l'application de la politique de sécurité) qui va examiner la pile d'appels de méthodes, ce qui va lui indiquer la provenance du code qui essaie d'accéder au fichier (en général, la politique se définit au niveau des fichiers JAR, donc le SecurityManager saura de quel JAR vient le code qui essaie d'ouvrir le fichier)
        
        À partir de ça, il va simplement regarder ses règles de sécurité, qui vont dire par exemple "x.jar peut accéder sans limites au système de fichier, y.jar peut seulement lire les fichiers dans /tmp, et z.jar n'a pas la permission d'accéder au fs", et va soit autoriser l'opération, soit envoyer une exception.
        
        Là où la VM apporte un plus, c'est justement qu'elle donne la possibilité de fixer les permissions jar par jar, et pas juste une permission au niveau du processus complet.
        
        Je te met un contexte non_trusted* en level non_trusted* et catégorie non_trusted* sur le code par défaut, ben ton appli elle va s'amuser a faire quoi que ce soit.
        
        Ben justement, on peut avoir dans la même VM du code "trusted" et du code "non-trusted", et on voudra que le code "trusted" puisse faire ce qu'il a besoin de faire, sans que le code "non-trusted" puisse faire n'importe quoi. C'est impossible à faire si la sécurité est gérée uniquement par l'OS, parce que les permissions sont au niveau process. Là, on veut quelque chose de plus fin. En plus de ça, les permissions qu'on peut régler ne concernent pas que l'accès au système de fichiers, on peut aussi autoriser/interdire :
        - les connexions réseau
        - le chargement de classes supplémentaires
        - l'appel à System.exit() (termine la VM)
        - la génération de byte code
        - l'accès aux membres privés ou protégés des classes
        - et surement plein de choses que j'oublie
        
        Bien évidemment, chacune des permissions est complètement paramétrable, on peut par exemple autoriser les connexions sur un port précis d'un serveur précis et refuser tout le reste.
        
        Ensuite c'est la difficulté a implémenté cette solution, mais intrinsèquement la vm n'apporte pas un "plus de sécurité", elle apporte bien un "plus de sécurité" car elle gère plus facilement la sécurité
        
        Le but n'est pas de remplacer l'OS. Le but, c'est de fournir un environnement limité qui servira à exécuter du code dans lequel on n'a pas forcément confiance. Ça permet par exemple d'avoir une application qui pourra être étendue par des plugins tiers qui ne pourront pas faire n'importe quoi.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par briaeros007 le 08 juillet 2009 à 01:09. Évalué à 2.
        
        Là où la VM apporte un plus, c'est justement qu'elle donne la possibilité de fixer les permissions jar par jar, et pas juste une permission au niveau du processus complet.
        Cela me pose quand même de gros problème, tu vas me dire que je suis parano mais
        1°) vu que c'est le même espace mémoire tu ouvre quand même une grosse boite de pandore (suffit d'une faille dans un jar "autorisé", ou un code volontairement malicieux (si c'est possible), et tout le système s'écroule, sachant que tu as accés à la mémoire du jar autorisé vu que tu es dans le même processus (vm?)).
        
        2°) et il gère comment les sécurité lors de la compilation et de l'execution du code binaire ? Les optimisation ne risquent elles pas de gener la VM ? Et les tranpolines , comment il retrouve ses petits ?
        
        3°) est il possible de révoquer les permissions sans redemarrer les process ? (le système de base de linux ne le permet pas, mais selinux si).
        
        Ben justement, on peut avoir dans la même VM du code "trusted" et du code "non-trusted"
        Voir ma remarque au dessus. Pour moi, c'est quand même sacrément jouer avec le feu.
        
        En plus de ça, les permissions qu'on peut régler ne concernent pas que l'accès au système de fichiers, on peut aussi autoriser/interdire :
        - les connexions réseau
        - le chargement de classes supplémentaires
        - l'appel à System.exit() (termine la VM)
        - la génération de byte code
        - l'accès aux membres privés ou protégés des classes
        - et surement plein de choses que j'oublie
        En ce qui concerne le spécifique a java, bien entendu que l'os ne peut rien faire (os java sinon), mais pour les connexions réseaux etc... t'inquiète que selinux sait faire (d'ailleurs ca peut poser des problèmes quand on teste des policy non adapté. Ben pourquoi mon interface monte plus ?? XD )
        
        Ça permet par exemple d'avoir une application qui pourra être étendue par des plugins tiers qui ne pourront pas faire n'importe quoi.
        Je vais me répeter, mais pour moi cette architecture c'est sacrément jouer avec le feu.
        
        Je reconnais l'intérêt technique, mais étant d'un naturel prudent, je persiste a penser qu'il serait plus sache de modifier l'architecture du programme pour que ce soit executé de façon séparé si on a pas confiance dans le code.
        
        D'autant plus que l'on peut pas vraiment dire que la vm et le process de sécurité d'une vm, aussi utilisé soit elle, a été aussi audité que les procédures de sécu du noyau.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par thedude le 08 juillet 2009 à 01:26. Évalué à 2.
        
        3°) est il possible de révoquer les permissions sans redemarrer les process ? (le système de base de linux ne le permet pas, mais selinux si).
        Meme si n'etant pas sur et certain, n'ayant jamais joue avec ca professionellement parlant, je pense que oui en Java, le SecurityManager etant un objet comme les autres, a verifier dans la doc.
        Apres, par experience, je pourrais pas etre categorique. Oui, je sais, ma reponse est une reponse de normand.
        
        Vu comment .Net a l'air bien pense, j'ai envie de dire "oui bien sur", mais ca reste un feeling, je laisse timaniac repondre a la question de facon sur et certaine.
        
        Voir ma remarque au dessus. Pour moi, c'est quand même sacrément jouer avec le feu.
        Pas forcement, non.
        Regarde Firefox par exemple, ou les plugin sont un de ses gros atouts.
        Ca m'emballe pas forcement de savoir que tous les plugins peuvent avoir acces a mes infos personnelles, ou qu'inversement aucun ne peut avoir acces a des infos perso parce que ca limite l'interet des plugins.
        Avec un tel systeme tu peux mettre en place un systeme de plugin truste par la mofo, et ainsi en tirer un reelle gain.
        
        1°) vu que c'est le même espace mémoire tu ouvre quand même une grosse boite de pandore (suffit d'une faille dans un jar "autorisé", ou un code volontairement malicieux (si c'est possible), et tout le système s'écroule, sachant que tu as accés à la mémoire du jar autorisé vu que tu es dans le même processus (vm?)).
        J'ai du mal a comprendre la question tu peux preciser un peu?
        
        Je reconnais l'intérêt technique, mais étant d'un naturel prudent, je persiste a penser qu'il serait plus sache de modifier l'architecture du programme pour que ce soit executé de façon séparé si on a pas confiance dans le code.
        C'est un point de vue, il se tient tout a fait.
        On pourrait argumenter qu'il est plus fiable d'avoir une base solide fournissant ce mecanisme plutot que de devoir le reimplementer soit meme, avec des failles potentielles, mais ton point de vue est plus que comprehensible (entendre par la technique et pas purement politique comme 99% des conneries qui se disent ici contre mono).
        
        D'autant plus que l'on peut pas vraiment dire que la vm et le process de sécurité d'une vm, aussi utilisé soit elle, a été aussi audité que les procédures de sécu du noyau.
        Je dirais pas que l'un est plus audite que l'autre, sincerement.
        Les VM Java et .Net sont des produits tres critiques pour Sun/oracle et MS, tres utilisees sur les serveurs, utilisees par des gens qui ont des besoins critiques en secu, le degre de confiance accordable aux deux process secu est, je pense, le meme.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par briaeros007 le 08 juillet 2009 à 01:55. Évalué à 2.
        
        Regarde Firefox par exemple, ou les plugin sont un de ses gros atouts.
        Je parlait de la sécurité.
        Chrome ou IE8 sont plus secure que fx tant qu'ils n'auront pas fait du process tabing et les autres conneries du même style. (voui voui tu m'as bien lu, j'ai bien dis qu'IE8 était supérieur à fx sur au moins un domaine ;))
        Et d'après defcon , je suis pas sur que les "plugins" de fx soient considéré comme une bonne chose niveau sécu
        http://www.defcon.org/html/defcon-17/dc-17-speakers.html#Liv(...)
        (enfin je dis ça, je dois bien avoir 3 ou 4 plugins sur mon iceweasel moi)
        
        J'ai du mal a comprendre la question tu peux preciser un peu?
        Grosso modo, dans le même espace mémoire, tu as du code sur et du code non sur. Serait il possible qu'un attaquant, a partir de son code "non sur" arrive a phagocyter le code dis "sur" ? (création dynamique de classe héritant du contexte de classes autorisées, buffer overflow sur _son_ code , trampoline... Enfin je suis pas un expert dedans, mais il doit exister un certain nombre de vecteur d'attaques possibles quand on permet a une classe de s'executer dans le même espace qu'une autre classe)
        
        Les VM Java et .Net sont des produits tres critiques pour Sun/oracle et MS, tres utilisees sur les serveurs, utilisees par des gens qui ont des besoins critiques en secu, le degre de confiance accordable aux deux process secu est, je pense, le meme.
        Le problème (enfin de mon point de vue) est que le noyau est utilisé par tout le monde, soumis a des attaques incessantes (il y a certainement encore des 0-day ), etc...
        Bref, l'os, étant une base commune, risque de concentrer plus de monde compétent, du fait qu'il touche plus de monde.
        Ensuite le but de l'os est de gerer les ressources, et donc la sécurité de celles ci.
        Quand bien même l'os est passablement complexe, la sécurité reste un des but primaires de l'os.
        
        De l'autre coté, la VM n'a pas pour but primaire d'assurer la sécu, mais d'executer les classes. Ceci peut rendre le code plus complexe, car devant effectuer plus de choses, et souvent utilisant des techniques plus haut niveau.
        Les techniques haut niveau réduisant d'autant le code et la complexité de celui ci, aidant donc à l'audit et à une bonne fiabilité. Mais il introduit aussi d'autres sources potentiels de bugs (bugs isses des libs haut niveau utilisés, etc...)
        
        Bref, l'un dans l'autre, j'ai moins confiance dans une vm java (seulement récemment libéré), en une vm .net (celle ms, peu, vu qu'elle n'est pas libre, celle mono, pas des masses, car bien que n'étant pas libre, n'est pas vraiment sur une position "critique" sur le système, donc souvent moins regardé).
        
        Ensuite c'est peut être un simple préjugé de ma part ;)
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 16:14. Évalué à 2.
        
        Serait il possible qu'un attaquant, a partir de son code "non sur" arrive a phagocyter le code dis "sur" ?
        Non, c'est "by design" qu'une VM comme Java ou .NET empêche celà.
        C'est "by design" que du code natif laisse faire tout et n'importe quoi.
        C'est pas pour rien qu'un OS est obligé pour contourner le problème de s'appuyer sur les rings matériels offerts par le processeur pour cloisonner les processus et donc gérer les droits utilisateurs.
        
        Bref, l'os, étant une base commune, risque de concentrer plus de monde compétent, du fait qu'il touche plus de monde.
        L'OS contient surtout une quantité hallucinante de code tournant dans un même espace mémoire. Une VM a un code extrêmement réduit, et la gestion de sécu, là où passe tout le code utilisateur et donc est la seule "véritable" faille de la VM, est une partie insignifiante de ce que représente tout le joli monde que l'on trouve dans le kernel.
        
        De l'autre coté, la VM n'a pas pour but primaire d'assurer la sécu, mais d'executer les classes.
        Un des buts d'une VM est d'abstraire le code machine qui n'offre de base aucune sécurité, pour justement proposer un modèle de machine (VM) entièrement contrôlable par l'environnement d'exécution. Bref, by design encore une fois, une VM est conçu pour avoir une maîtrise complète du code exécuté.
        Un OS n'a que vaguement la main à travers les appels systèmes et s'appui sur le hardware in fine.
        
        Suffit de voir des projets de recherche sur les OS comme Singularity qui propose un modèle de sécurité entièrement logiciel, uniquement possible parcque s'appuyant sur une VM qui défini un jeu d'instruction entièrement contrôlable par l'OS.
        http://en.wikipedia.org/wiki/Singularity_%28operating_system(...)
        
        La plus grosse faille de sécu de ces VM, c'est là où elle appel du code natif. En dehors du coeur (JIT et runtime en soit), la gros trou est au niveau des bindings vers des libs natives (IHM ou autre).
        C'est là que la VM n'a plus la main sur le code exécuté, et c'est là que ca peut devenir dangereux.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 16:52. Évalué à 3.
        
        Non, c'est "by design" qu'une VM comme Java ou .NET empêche celà.
        C'est "by design" que du code natif laisse faire tout et n'importe quoi.
        C'est pas pour rien qu'un OS est obligé pour contourner le problème de s'appuyer sur les rings matériels offerts par le processeur pour cloisonner les processus et donc gérer les droits utilisateurs.
        
        L'OS ne contourne ne rien du tout. Il utilise une protection hardware parfaitement et totalement étanche : la gestion de la mémoire virtuelle. Quand une VM fait cela, elle s'expose à un bug, tu peux aussi exposer des bugs sur le hardware mais c'est plus rare... (et beaucoup plus facile à vérifier).
        C'est la différence entre une garantie donné par une barrière comme le hardware, et une "gestion" qui est _censé_ être bien faite.
        
        Un des buts d'une VM est d'abstraire le code machine qui n'offre de base aucune sécurité, pour justement proposer un modèle de machine (VM) entièrement contrôlable par l'environnement d'exécution. Bref, by design encore une fois, une VM est conçu pour avoir une maîtrise complète du code exécuté.
        Un OS n'a que vaguement la main à travers les appels systèmes et s'appui sur le hardware in fine.
        
        Ce que tu décris, cela s'appelle de la gestion de processus, c'est la raison première de l'existence des OS. Pourquoi encore rajouter une couche ?!
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 16:57. Évalué à 2.
        
        Il utilise une protection hardware parfaitement et totalement étanche
        Et surtout totalement propriétaire pour une architecture matérielle donnée. L'OS tout seul ne peut rien faire.
        C'est une protection hardware, pas software, l'OS ne fait qu'exposer cette protection.
        Une VM peut faire cette protection de manière software indépendamment de l'hardware parcqu'elle propose justement une autre vu que le code machine.
        
        C'est la différence entre une garantie donné par une barrière comme le hardware, et une "gestion" qui est _censé_ être bien faite.
        En pratique, les 2 sont complémentaires, et la gestion hardware est beaucoup trop rigide et pas assez précise (granularité : processus).
        
        Et puis quand tu veux faire du portable (style applet), ben t'as pas le choix d'utiliser une abstraction.
        
        Ce que tu décris, cela s'appelle de la gestion de processus
        Non, ca s'appel la gestion de processus au niveau OS parcque c'est le seul cloisonnement que l'OS sait offrir.
        Ca s'appel pas comme ca au niveau VM parcque ca se gère pas au niveau processus mais au niveau instruction (chaque instruction est contrôlable et contrôlée).
        Là est toute la différence.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 17:14. Évalué à 2.
        
        Tu as tellement de code de plugin que tu est obliger de tout coller dans des espaces différents?
        
        En quoi gérer des processus seraient moins bien ? (comme Chrome en fait ?)
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Buf (Mastodon) le 08 juillet 2009 à 17:21. Évalué à 2.
        
        En quoi gérer des processus seraient moins bien ? (comme Chrome en fait ?)
        
        Créer des processus, à la base, ça ne fait que créer des espaces d'adressage séparés. Si on veut utiliser ça pour réduire les privilèges d'une partie du code, on doit passer par des constructions qui ne sont pas forcément disponibles sur tous les OS, et dans tous les cas, non portables.
        
        À côté de ça, ça nécessite aussi la mise en place d'un protocole de communication, qui a un cout important en performance.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Buf (Mastodon) le 08 juillet 2009 à 01:34. Évalué à 3.
        
        Tu es parano ;)
        
        1°) vu que c'est le même espace mémoire tu ouvre quand même une grosse boite de pandore (suffit d'une faille dans un jar "autorisé", ou un code volontairement malicieux (si c'est possible), et tout le système s'écroule, sachant que tu as accés à la mémoire du jar autorisé vu que tu es dans le même processus (vm?)).
        
        Oui, c'est sûr que ça n'a rien de magique, une faille dans une lib privilégiée peut mettre à terre tout le système. Ça n'empêche pas que ça offre quand même des possibilités intéressantes qui seraient très difficiles à faire autrement, et impossibles à faire de façon portable. Quant à l'"accès à la mémoire", oublie pas qu'on est dans une VM, même le code "trusted" n'a pas accès à la mémoire autrement que par les objets dont il possède des références. Un scan de la mémoire pour aller y chercher des infos sensibles est exclu dans tous les cas.
        
        2°) et il gère comment les sécurité lors de la compilation et de l'execution du code binaire ? Les optimisation ne risquent elles pas de gener la VM ? Et les tranpolines , comment il retrouve ses petits ?
        
        Je sais pas exactement comment c'est géré en interne, mais la VM est toujours capable de fournir la pile d'appel, même dans du code qui a été compilé, optimisé, voire inliné. Donc ça ne doit pas poser de problème.
        
        est il possible de révoquer les permissions sans redemarrer les process ? (le système de base de linux ne le permet pas, mais selinux si).
        
        Avec l'implémentation standard, je suis pas sûr, mais le SecurityManager est un objet parfaitement normal, on peut sans problème en créer une sous-classe capable de changer les permissions à chaud si besoin.
        
        Pour moi, c'est quand même sacrément jouer avec le feu.
        
        Comme je l'ai dit avant, le but n'est pas de remplacer les sécurités de l'OS, mais de fournir un moyen pratique et surtout portable d'avoir certaines garanties au niveau sécurité. Si vraiment on a besoin d'une sécurité absolue, il faudra envisager autre chose, mais ça sera forcément beaucoup plus lourd, et risque de nécessiter pas mal de boulot de config au niveau de l'OS : créer des contextes d'exécution séparés, régler les permissions, prévoir un système de communication inter-processus qui pourra passer les barrières mises en place, etc. Et au final, on pourra aussi très facilement oublier un détail qui va complètement détruire tout l'édifice ;)
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par briaeros007 le 08 juillet 2009 à 02:06. Évalué à 2.
        
        Quant à l'"accès à la mémoire", oublie pas qu'on est dans une VM, même le code "trusted" n'a pas accès à la mémoire autrement que par les objets dont il possède des références. Un scan de la mémoire pour aller y chercher des infos sensibles est exclu dans tous les cas.
        Je suis pas du tout un expert en attaque, mais j'ai vu des vecteurs d'attaques vraiment intelligent en manipulant des tas de données de façon experte.
        Par exemple, serait il possible de créer une classe de façon dynamique (donc dans aucun ".jar" ou autre), héritant d'une classe privilégié ?
        Si oui, comment se comporte le l'utilisation des super classes ? toujours priviligiée normalement (elles appartiennent au .jar autorisé) ? Il serait peut etre possible, non pas de réimplémenter la méthode que l'on veut "attaquer", mais une méthode qu'utilise la méthode que l'on souhaite attaquer. ainsi, en appelant la super classe, il va utiliser notre méthode (je sais plus quel type d'héritage il faut pour que ça marche), qui provoquera soit ce que l'on veut, soit une exception en esperant que lors d'une exception il conserve les droits (enfin voir comment marche la sécurité sur la vm, etc...)
        
        Bref, ne pas forcément dépendre d'une faille (bien qu'une faille dans une lib soit forcément plus probable qu'une faille dans une vm, vu que la taille de code est plus importante), mais des comportement fortement tarabsicoté qui outrepasse les procédures de sécuritées etc...
        
        mais la VM est toujours capable de fournir la pile d'appel, même dans du code qui a été compilé, optimisé, voire inliné. Donc ça ne doit pas poser de problème.
        et peut on avoir des classes qui font un "trampoline" dans les lgg utilisant une vm ? (grosso modo implémenter une autre vm dans la vm. En essayant peut etre de faire comme la faille du double chroot).
        
        Avec l'implémentation standard, je suis pas sûr, mais le SecurityManager est un objet parfaitement normal, on peut sans problème en créer une sous-classe capable de changer les permissions à chaud si besoin.
        Gérer les permissions a chaud demande a ce que CHAQUE accés soit vérifié. il n'est donc pas aisé de le rajouter après coup si il n'y a pas déjà les hooks associées.
        
        mais ça sera forcément beaucoup plus lourd, et risque de nécessiter pas mal de boulot de config au niveau de l'OS
        Ca je suis tout a fait d'accord ;)
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par pasBill pasGates le 08 juillet 2009 à 02:54. Évalué à 2.
        
        Si oui, comment se comporte le l'utilisation des super classes ? toujours priviligiée normalement (elles appartiennent au .jar autorisé) ? Il serait peut etre possible, non pas de réimplémenter la méthode que l'on veut "attaquer", mais une méthode qu'utilise la méthode que l'on souhaite attaquer. ainsi, en appelant la super classe, il va utiliser notre méthode (je sais plus quel type d'héritage il faut pour que ça marche), qui provoquera soit ce que l'on veut, soit une exception en esperant que lors d'une exception il conserve les droits (enfin voir comment marche la sécurité sur la vm, etc...)
        
        Une faille dans le systeme de securite de la VM est toujours possible, tout comme une faille dans le systeme de securite de l'OS, au final c'est le meme topo : l'editeur de la VM sortira un patch de securite, et la faille sera bouchee.
        
        Le fait qu'il tourne dans le meme espace memoire n'est pas du tout un probleme, car le design meme du langage empeche le bytecode de controler le runtime, tu peux pas choper un pointeur sur des structures du runtime, ecrire dans l'espace memoire ou bon te semble, etc... Le runtime execute du bytecode, et aucune instruction du bytecode ne le permet, si le parser voit un bytecode inconnu, il va le rejeter simplement, le bytecode accede a des registres et addresses virtuels, pas aux registres et espace memoire du CPU.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par briaeros007 le 08 juillet 2009 à 11:25. Évalué à 2.
        
        mon point était plus au niveau de ce qui était autorisé plutôt qu'au niveau de la VM. Je suis bien conscient que si il y a une faille dans la vm, c'est byzance. Mais je m'intéresse plutôt aux effets de bords (comme l'exemple décris ci dessus où une des classes est autorisés, et on essaie de la modifier de façon a faire ce que l'on veut).
        
        car le design meme du langage empeche le bytecode de controler le runtime,
        si je regarde un peu plus bas je vois
        .NET/Mono est un environnement conçu pour la programmation avec plusieurs langages.
        Donc tous les langages ont exactement les mêmes protections, sont pareillement audité sur les problèmes de sécu , etc... ?
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 11:41. Évalué à 2.
        
        Donc tous les langages ont exactement les mêmes protections, sont pareillement audité sur les problèmes de sécu , etc... ?
        C'est là qu'un modèle de VM comme .NET est intéressant : le runtime s'occupe du bytecode, la sécurité est gérée au niveau du bytecode. Tu peux concevoir ton langage comme une loutre avec un compilo foireux dans ton coin, tant que tu ponds du bytecode valide, ca sera pas moins sécure qu'un compilo C# rodé par Microsoft pendant 10 ans.
        Je parles de sécurité au sens attaque malveillante & co, pas sécurité au sens je me bouffe une castexception par le runtime parcque mon langage bidon à un typage foireux.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 12:48. Évalué à 2.
        
        Et ce genre de Vm permet d'éviter les attaques de "haut niveau" de code codé comme une loutre ? J'ai comme un doute.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 13:05. Évalué à 2.
        
        Comprends rien à ta phrase.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 07 juillet 2009 à 20:00. Évalué à 3.
        
        Dans ce cas ca veut dire que tu exécute un code dans un conteneur, non/faiblement audité avec des droits extrêmement étendu par rapport à ce que fait le code.
        Tout à fait.
        C'est le principe de fonctionnement des VM comme Java ou .NET, c'est pas pour rien qu'on parle de runtime : le code est entièrement contrôlé par l'environnement d'exécution, ce dernier a donc la possibilité de gérer ce que le code a le droit de faire ou non, et de manière beaucoup plus fine que l'OS (granularité jusqu'à la méthode).
        
        Même chose si tu lance ton applet avec ou les bonnes règles selinux et/ou setuid=nobody
        C'est gentil mais c'est pas portable.
        Et puis je veux pouvoir le faire au niveau de mon application où je gère des plugins tierce-partie qui tourne dans le même processus que mon application.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par briaeros007 le 07 juillet 2009 à 23:51. Évalué à 2.
        
        C'est gentil mais c'est pas portable.
        Se faire entendre ca par une techno poussé par une boite qui supporte pas posix ...
        
        Et puis je veux pouvoir le faire au niveau de mon application où je gère des plugins tierce-partie qui tourne dans le même processus que mon application.
        Niveau cracra on commence a atteindre le fond là.
        Si tu n'a pas conscience dans les plugins, tu les executent pas dans les mêmes processus, c'est un peu la base normalement...
        (séparation toussa).
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 00:32. Évalué à 2.
        
        Se faire entendre ca par une techno poussé par une boite qui supporte pas posix ...
        y dit qui voit pas le rapport.
        
        En fait, ce que t'es en train de faire, c'est de refuser qu'on puisse faire avec une VM de manière portable ce que toi tu fais avec un OS et des outils bien spécifiques. Si un OS peut le faire, une VM peut le faire, y'a rien de crade à ça.
        Imagine toi le monde réel :
        je dois coder une application pour un site web qui demande un certain nombre de droits pour s'exécuter sur la machine : accès webcam et un peu d'espace disque.
        Tu choisis quelle techno ? t'embarque chroot dans un activeX ? Non sérieusement...
        
        tu les executent pas dans les mêmes processus, c'est un peu la base normalement...
        Ben quand tu tournes dans un espace totalement contrôlé comme un environnement d'exécution .NET ou Java, tu peux revoir tes bases et te dire qu'on peut se passer de la lourdeur des processus. Non parcque niveau perf, j'espère que tes plugins doivent pas trop fonctionner ensemble...
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par briaeros007 le 08 juillet 2009 à 01:20. Évalué à 2.
        
        y dit qui voit pas le rapport.
        Oh je sais pas, raler parce que une solution n'est pas interoperable, alors que la solution que tu propose est
        1°) poussé par une boite essayant de tout faire pour lutter contre l'interopérabilité
        2°) n'a absolument pas fait en sorte que leur système soit interopérable (c'est pas ms qui a codé une vm interoperable).
        
        En fait, ce que t'es en train de faire, c'est de refuser qu'on puisse faire avec une VM de manière portable ce que toi tu fais avec un OS et des outils bien spécifiques. Si un OS peut le faire, une VM peut le faire, y'a rien de crade à ça.
        Oula non.
        1°) comme je l'ai dis : pour moi une vm n'apporte pas un "plus" de sécurité. Ca n'empeche pas de le faire, ni d'apporter une aide bienvenue dans l'administration (qui elle peut apporter un "plus" dans la sécurité, mais grace à l'administration).
        2°) les arguments techniques interessant et que je ne connaissais ont été developpé (sécu sur la méthode ou sur le .jar/.class/.bidule), toutefois je trouve que même si ca apporte un plus par rapport à une application qui n'a pas ça, ca pose des problèmes
        - quid de l'accés à la mémoire ? le suivi de la sécurité ? Comment ca a été audité ?
        - le principe de base d'autoriser ou non du code, alors que ca appartient aux mêmes segments mémoire etc... me semble quand même passablement risqué. C'est une question de risque, pas d'exploitation réelle là. Et puis je ne suis pas un expert, c'est pour ça que je dis "me semble" ;)
        3°) repose sur des couches qui ont été moins audité, et donc peut être moins sur (bien entendu, cela dépend du code, de la portée , etc...)
        
        Pour toute ces raisons je pense qu'il faut mieux revoir l'architecture d'un programme pour qu'il execute le code non sur dans des process ou autre séparé, plutot que de reposer aveuglement sur les protections apportées sur les VM.
        
        t'embarque chroot dans un activeX ?
        Tu parlais de portabilité y'a quelques lignes non ?
        
        Ben quand tu tournes dans un espace totalement contrôlé comme un environnement d'exécution .NET ou Java
        J'ai déjà lu le code mono. J'ai déjà trouvé des races conditions dedans.
        Voila ma confiance dans le code de mono. Alors certes tu va me dire ca fait longtemps, et qu'un code comme ça a forcément des bugs, et que les races conditions sont très compliqué a débuggé (la preuve, pour corriger la deuxieme j'ai fait un gros hack immonde), mais désolé, cela a quand même entamé ma confiance dans mono, surtout sachant que c'est pas la plateforme officiel, donc sans doute moins audité.
        
        te dire qu'on peut se passer de la lourdeur des processus. Non parcque niveau perf, j'espère que tes plugins doivent pas trop fonctionner ensemble...
        Ensuite faut savoir si tu veux faire de la sécurité, ou du developemment dans un délai X avec un objectif Y.
        Les deux ne sont pas forcément possibles de façon optimale.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 11:38. Évalué à 2.
        
        quid de l'accés à la mémoire ?
        Ben c'est un des fondements de ce type de VM : la mémoire est intégralement gérée par la VM, la VM a le contrôle total sur l'ensemble des accès mémoire.
        
        le principe de base d'autoriser ou non du code, alors que ca appartient aux mêmes segments mémoire etc... me semble quand même passablement risqué.
        Ca reste le seul modèle réellement mis en place pour faire tourner des applet : .NET, Java ou encore Flash. Parcque de base on va pas s'amuser à lancer un processus pour chaque composant flash de la page web !
        
        repose sur des couches qui ont été moins audité, et donc peut être moins sur
        Pas convaincu que le coeur du CLR .NET soit moins audité que le kernel Linux, proportionnellement à la surface de code exposée j'entend. Le kernel, c'est un gros bousin monolithique ou tout et n'importe quoi tourne avec les droits admin. C'est pas tout à fait la même quantité de code (et donc de code risqué) mis en oeuvre.
        
        t'embarque chroot dans un activeX ?
        Tu parlais de portabilité y'a quelques lignes non ?
        Justement, je lancçais une boutade, mais la question reste valable, comment fais-tu pour proposer un environnement d'exécution sécure pour des applets web, ce qui reste à l'heure actuel la principal source de code à la provenance inconnue qui s'exécute sur ton ordinateur.
        
        Voila ma confiance dans le code de mono.
        Certes, j'ai à peu prêt le même niveau de confiance que toi. Pour faire tourner des applis Gnome ca me gène absolument pas, pour faire tourner des applets web (style moonlight) je suis tout de suite plus parano. Mais en même temps c'est à peu prêt le même niveau de confiance que j'accorde à Gnash par exemple pour faire tourner du flash.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par briaeros007 le 08 juillet 2009 à 17:35. Évalué à 2.
        
        Parcque de base on va pas s'amuser à lancer un processus pour chaque composant flash de la page web !
        Pourquoi pas ? Parce que tu crois que ton code flash prend moins de ressource quand il n'est pas dans un process a part ?
        Déjà quand on utilise du flash, on s'en tape complètement des ressources (niveau lgg ressourcivore pour rien, on a pas fait mieux depuis longtemps).
        
        ce qui reste à l'heure actuel la principal source de code à la provenance inconnue qui s'exécute sur ton ordinateur.
        Pas sur le mien, désolé :P
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Octabrain le 08 juillet 2009 à 11:54. Évalué à 1.
        
        SELinux c'est POSIX ? Non, alors ne donne pas de leçons de portabilité...
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 12:50. Évalué à 2.
        
        "Tu as pendu ton chien, vient pas m'embêter quand je trucide le mien"
        
        Franchement, les arguments du style "tu fais pire que moi", à part ridiculiser leur auteur, je ne vois pas leur utilité.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Octabrain le 08 juillet 2009 à 13:25. Évalué à 0.
        
        Je résume la situation :
        "- Les VMs apportent une sécurité"
        "- Yaka utiliser SELinux pour la sécurité"
        "- Sauf que SELinux c'est pas portable"
        "- Windows c'est pas POSIX"
        Cherchez l'intrus...
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par briaeros007 le 08 juillet 2009 à 17:36. Évalué à 2.
        
        tu résume la parce que c'est pas du tout ce que j'ai dis.
        Essaie encore, peut etre que tu arrivera à lire cette fois ci
      - [^] # Re: Pourquoi Mono ?
        
        Posté par pasBill pasGates le 07 juillet 2009 à 15:46. Évalué à -1.
        
        Ca permet donc de palier au faille de l'OS et des mauvais programmeurs ? Je préfère avoir du code bien écrit, vérifié par plein de monde et un OS qui gère ça d'origine plutot que d'avoir encore une couche supplémentaire qui permet de cacher tous ces problèmes ...
        Ça me fait penser aux antivirus ...
        
        Tres bonne idee.
        
        Tu vas passer de Linux a quel OS alors ? Parce que Linux ne repond a aucun des criteres que tu as cites, et je connais pas d'OS grand public qui y reponde d'ailleurs.
    - [^] # Re: Pourquoi Mono ?
      
      Posté par benoar le 07 juillet 2009 à 17:26. Évalué à 1.
      
      En ce qui concerne ton dernier argument, sache que dans la recherche en ce moment j'ai entendu parler d'obfuscation de bytecode et que ça a l'air assez à la mode et intéresse pas mal d'entreprises ... Bon ok, pour être crédible il faudrait que je trouve des sources.
      - [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 07 juillet 2009 à 17:30. Évalué à 3.
        
        Dans la "recherche" ?
        Ils cherchent où ? sur google ?
        
        http://www.google.fr/search?hl=fr&q=.net+obfuscator&(...)
        
        http://www.google.fr/search?hl=fr&q=java+obfuscator&(...)
        
        Ca existe depuis des années.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par benoar le 07 juillet 2009 à 18:11. Évalué à 1.
        
        C'est ça que je comprend pas avec des gens comme toi, c'est comment fonctionne ta logique ... La rhétorique de toi et tes potes est très forte : tu disais plus haut que le bytecode n'aidait pas ceux qui voulaient "cacher" leurs sources, bien au contraire. Et là tu me dis qu'en fait, on sait déjà "cacher" le bytecode depuis longtemps. Quelle est la logique dans ton argumentation ?
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 07 juillet 2009 à 18:22. Évalué à 2.
        
        Ben la logique est simple : le bytecode ne va pas dans le sens de "cacher" du code propriétaire, au contraire (ce que j'essai de montrer). La preuve, les softs d'obfusction ont dû débarqués pour colmater en partie la brèche.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par benoar le 07 juillet 2009 à 18:47. Évalué à 1.
        
        Il existait déjà des soft d'obfuscation pour l'assembleur, hein. Pour moi, montrer que des obfuscateurs existent n'est pas une preuve que le bytecode est facilement lisible.
        
        L'argument de départ était qu'une VM c'est pratique, parce qu'on est facilement multiplateforme tout en ayant une forme de code assez bas niveau. Ce qui permet de "cacher" les sources. Toi, tu dis que ce n'est pas vraiment cacher car on peut "facilement" le comprendre. Moi je te dis qu'en plus on peut l'obfusquer.
        
        Entre obfusquer des sources pour les cacher et être multiplateforme, et faire pareil pour le bytecode, la deuxième solution est quand même vachement plus simple et efficace.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 07 juillet 2009 à 19:01. Évalué à 2.
        
        L'argument de départ était qu'une VM c'est pratique, parce qu'on est facilement multiplateforme tout en ayant une forme de code assez bas niveau. Ce qui permet de "cacher" les sources.
        Non, l'argument est de dire qu'une VM a pour principal objectif de faciliter le déploiement de binaire, problématique lié au proprio avec son besoin de distribuer des binaires; et dire que le libre n'a donc pas besoin de VM puisqu'on distribue des sources.
        
        Moi je montre 2 choses :
        - le bytecode permet de retrouver une bonne partie du code source, ce qui enmerde certains industriels, d'où le succès des obfuscateurs de bytecode.
        Avant un distributeur de soft proporio proposait plusieurs binaires si plusieurs architectures en gardant le code source caché, maintenant il n'en déploie plus qu'un, au prix d'un code source moins caché (bytecode), à moins d'utiliser un soft pour le rendre plus obscure.
        - la problématique de déploiement de binaire est également présente dans le libre, c'est la forme la plus généralement utilisée par les grandes distributions linux. Techniquement, ce qui est intéressant pour le proprio l'est aussi pour le libre, ce sont des atouts "techniques", pas politiques.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par thedude le 07 juillet 2009 à 21:35. Évalué à 1.
        
        - le bytecode permet de retrouver une bonne partie du code source, ce qui enmerde certains industriels, d'où le succès des obfuscateurs de bytecode.
        
        Qu'on m'arrete si je dit une connerie, mais bon.
        Je n'ai JAMAIS considere ces "obfuscateurs de code" comme de vrais obfuscateurs, en Java tout du moins, j'ai jamais touche a .net.
        A partir du moment ou tu distribues du bytecode, tu dis au revoir au secret de ton code.
        
        N'importe quel gus rompu au reverse engineering te pond un code acceptable simplement, a partir du bytecode. Ca lui prendra pas 2 minutes, mais c'est clairement pas une solution fiable.
        
        La je glisse sur le domaine du fantasme, mais il me semble meme qu'il existe des "desobfuscateurs", qui, a defaut de retablire les noms de variables, enlevent les cochonneries style "goto machin" generes par les obfuscateurs.
        Un bon ide pour le renommage des classes/methodes/variables, et paf le reverse.
        
        Par contre, ca permet de diminuer enormement la taille du jar, et ca c'est cool (surtout quand tu fais du MIDP1 et que tu vises des telephones de merde qui se vautrent sur des jar de plus de 62ko).
        
        Bref, les obfuscateurs, ils sont plus utilises pour des effets de bords que comme obfuscateurs.
    - [^] # Commentaire supprimé
      
      Posté par Anonyme le 08 juillet 2009 à 15:25. Évalué à 1.
      
      Ce commentaire a été supprimé par l’équipe de modération.
      - [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 16:02. Évalué à 2.
        
        ça, un paquet de langages compilé natif le font
        Les langages qui font ca sont obligés d'insérer des métadonnées dans l'exécutable, bref de définir un modèle d'information de plus haut niveau, une VM. C'est ce que fait C++, c'est ce que fait n'importe quelle VM qui propose l'introspection.
        Si tu parles uniquement de code natif pur, la seule introspection possible concerne par définition le jeu d'instruction du processeur.
        Si tu veux plus d'information, tu introduis une abstraction virtuelle.
        
        Tous les OSes et les langages, que je connnais, fournissent ça.
        Tu vois très bien ce que je veux dire.
        
        les protected de c++ en sont un des nombreux exemples)
        \o/ J'espère que tu coderas jamais une application C++ qui expose des données sensibles à l'extérieur.
        Comme si le mot clé protected t'offrais une quelconque sécurité. Tu prends un pointeur et tu vas te balader n'importe où dans ton objet, le mot clé n'est qu'une vision du compilateur, à l'exécution il n'y a aucun contrôle.
        
        Je ne connais pas un seul langage mainstream qui ne fournit pas cette compatibilité.
        Quand je te dis compatibilité, c'est la possibilité de définir des classes réutilisables sans se soucier du langage qui va l'utiliser.
        La seule convention qui existe, c'est les API plates à la C.
        2 compilos C++ sont même pas foutus de se mettre d'accord sur une compatibilité alors tu me fais bien rire avec cette compatibilité entre les langages.
        
        Est-ce que je peux réutiliser en C mes classes C++ sans me coltiner un outil ou une couche de glue avec laquelle je vais devoir faire gaffe ? non.
        
        Est ce que je peux réutiliser en C mes objets ObjectiveC ou Python sans me coltiner une couche intermédiaire ? non.
        
        Est ce que je peux réutiliser mes objets C# en IronPython ou en VB.NET sans me soucier de la façon dont ca va se passer ? oui.
        
        Ada fait abstraction des threads OSes et est pourtant compilé.
        ADA propose au sein de son langage une abstraction des threads, il défini une VM.
        La question n'est pas de savoir si c'est compilé ou non (c'est un faux débat puisqu'un programme C# peut être compilé en code natif).
        La question est de savoir si le langage s'appui directement sur les instructions machines où s'il forme un sur-ensemble constituant une machine virtuelle et permettant de partir du postulat que des services supplémentaires sont offerts.
        
        Pas beaucoups plus que pour une machine réelle, les phases d'optimisations sont très rarement réversibles
        Non non et non.
        Le bytecode .NET ou Java défini une VM avec la notion de classe, de méthode, de paramètres, d'héritage, de types énumérés, etc.
        Quand tu décompiles, tu retrouves tout ça, optimisation ou pas.
        En C, tu te retrouves avec un binaire et des instructions machines. Tout ce que tu obtiens à la décompilation, c'est des instructions assembleur. Tu perds toutes tes classes ou autre information de plus haut niveau.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 16:58. Évalué à 3.
        
        Les langages qui font ca sont obligés d'insérer des métadonnées dans l'exécutable, bref de définir un modèle d'information de plus haut niveau, une VM.
        
        Le C définit depuis toujours des symbole pour le link, le link dynamique, et le debug. Cela n'a rien à voir avec une VM qui traduit du bytes code !
        
        Comme si le mot clé protected t'offrais une quelconque sécurité. Tu prends un pointeur et tu vas te balader n'importe où dans ton objet, le mot clé n'est qu'une vision du compilateur, à l'exécution il n'y a aucun contrôle.
        
        Utilise 2 processus, c'est fait pour. En plus aujourd'hui, il y a mini 2 coeurs à disposition.
        
        ADA propose au sein de son langage une abstraction des threads, il défini une VM.
        
        n'importe quoi. C'est pas parce que l'on te trouve plein de contre exemple qu'il tout appelé VM ! Ada comme toutes les langages t'offre une abstraction statique, qui est traduit par le compilateur. Une VM le fera en plus à la volé.
        
        La question est de savoir si le langage s'appui directement sur les instructions machines où s'il forme un sur-ensemble constituant une machine virtuelle et permettant de partir du postulat que des services supplémentaires sont offerts.
        
        C'est évident et Ada pond du code machine ! (essaye gnat)
        
        Le bytecode .NET ou Java défini une VM avec la notion de classe, de méthode, de paramètres, d'héritage, de types énumérés, etc.
        Quand tu décompiles, tu retrouves tout ça, optimisation ou pas.
        
        si c'est vrai cela veut dire que le compilo qui génère du bytecode n'optimise rien, ce qui serait surprenant.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TortuXm le 08 juillet 2009 à 17:04. Évalué à 2.
        
        si c'est vrai cela veut dire que le compilo qui génère du bytecode n'optimise rien, ce qui serait surprenant.
        
        Pour avoir décompilé des .class java, je confirme que le code retrouvé ressemble énormément au code de base, à part quelques goto dans des boucles.
        
        Il me semble que l'optimisation se fait en runtime, quand la VM exécute un certain nombre de fois une méthode, elle décide de compiler ladite méthode en code natif pour aller plus vite. Et là, le code généré est optimisé, pas avant.
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 08 juillet 2009 à 17:50. Évalué à 2.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 17:57. Évalué à 2.
        
        une VM comme Java ou .NET impose une sémantique dans le bytecode qui limite les optimisations et facilite la décompilation. C'est un fait.
        Un programme C++ compilé directement en code machine ne pourra être relu qu'en assembleur. Ton compilateur java aura beaucoup faire toute la tambouille que tu veux avec ton code, tu verras toujours tes classes, tes méthodes, tes interfaces, tes appels de méthodes, etc.
        Ca sera toujours plus lisible.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 18:09. Évalué à 3.
        
        En C++, tu as le mangling des méthodes qui permet de retrouver aussi les types des paramètres et les interfaces.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 18:31. Évalué à 2.
        
        Technique non standardisée dont chaque compilateur a sa version. Mais certes c'est un niveau d'information supplémentaire. Bien loin de ce que propose la décompilation d'un bytecode C# ou Java.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 18:40. Évalué à 2.
        
        Oui et non.
        
        C'est censé être standard, mais c'est hyper complexe. De plus, l'information existe et peut donc être utilisé.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Buf (Mastodon) le 08 juillet 2009 à 17:05. Évalué à 2.
        
        si c'est vrai cela veut dire que le compilo qui génère du bytecode n'optimise rien, ce qui serait surprenant.
        
        C'est pourtant souvent le cas, les optimisations faites pendant la compilation code source vers bytecode sont très faibles (ça va s'arrêter à des trucs genre précalculer les expressions mathématiques constantes)
        
        Tout le boulot d'optimisation est faite par le compilateur JIT.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 17:07. Évalué à 1.
        
        Cela n'a rien à voir avec une VM qui traduit du bytes code !
        Ca c'est ta définition réductrice de VM. Pour moi une VM est tout ce qui constitue une abstraction de la machine. Quand tu proposes un peu d'introspection comme le fait C++, c'est quelque part une VM. Beaucoup plus light qu'une VM de type .NET ou Java parcqu'offrant beaucoup moins de services, on est d'accord.
        
        En plus aujourd'hui, il y a mini 2 coeurs à disposition.
        Les perfs sont bien meilleurs avec 2 threads qu'avec 2 processus, à plus forte raison avec 2 vrais coeurs.
        
        M ! Ada comme toutes les langages t'offre une abstraction statique, qui est traduit par le compilateur. Une VM le fera en plus à la volé.
        Tu vois moi aussi je peux le dire : n'importe quoi.
        mono me permet de compiler directement en code natif mon code C# comme le fait ton compilateur ADA.
        Un compilateur comme OCaml permet de faire également les 2.
        compilé et VM sont 2 notions différentes.
        
        C'est évident et Ada pond du code machine ! (essaye gnat)
        mono et .NET aussi dit donc.
        
        si c'est vrai cela veut dire que le compilo qui génère du bytecode n'optimise rien, ce qui serait surprenant.
        Il optimise au sein d'une méthode mais il va sûrement pas casser la sémantique des classes/méthodes/héritage, ce qui rendrait toute interopérabilité et l'introspection impossible.
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 08 juillet 2009 à 17:19. Évalué à 3.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 18:02. Évalué à 2.
        
        C'est ta "vision" qui est fausse
        C'est marrant ces gens qui voudraient imposer leur vision. C'est une question de point de vue, je suis le premier à le reconnaître.
        
        Une machine virtuelle est juste la simulation d'une machine.
        une machine virtuelle c'est juste une machine qui n'existe pas.
        que ce soit un sous-ensemble d'un jeu d'instruction d'une machine réelle, un sur-ensemble, une abstraction partielle ou complète, dans tous les cas c'est une nouvelle machine qui est virtuelle.
        
        L'introspection c'est la capacité d'un programme à consulter son propre état.
        Pas son état mais sa représentation. Si je veux connaître le type d'un objet à l'exécution, il faut que cette information soit disponible à l'exécution. En C# ou en C++ c'est exactement fait de la même façon : une donnée (qui n'est pas l'instruction machine) représentant le type (on l'appel métadonnée) et un morceau de code (runtime) se charge de simuler ce que la machine n'offre pas (l'accès à cette information).
        Le langage m'expose une instruction virtuelle qui n'est pas directement mappée sur une instruction machine.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Gniarf le 08 juillet 2009 à 17:10. Évalué à 3.
        
        > > Pas beaucoups plus que pour une machine réelle, les phases d'optimisations sont très rarement réversibles
        
        > Non non et non.
        > Le bytecode .NET ou Java défini une VM avec la notion de classe, de méthode, de paramètres, d'héritage, de types énumérés, etc.
        > Quand tu décompiles, tu retrouves tout ça, optimisation ou pas.
        
        bof, uniquement ce qui était exposé (public), le reste ne te regarde pas et ça peut même se retrouver renommé ou enlevé si inutilisé (stripped)
        
        > En C, tu te retrouves avec un binaire et des instructions machines.
        > Tout ce que tu obtiens à la décompilation, c'est des instructions assembleur. Tu perds toutes tes classes ou autre information de plus haut niveau.
        
        mais c'est fait EXPRES, mortecouille, on n'en veut PLUS. il y a plusieurs options pour garder les symboles et autres informations tant qu'on veut debugger le gourbis
        
        ah, et sinon les infos pertinentes sont dans des fichiers .h :)
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 17:15. Évalué à 1.
        
        ah, et sinon les infos pertinentes sont dans des fichiers .h :)
        C'est à ça que sert l'introspection, à enterrer 6 pieds sous terre ces foutus .h :)
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Gniarf le 08 juillet 2009 à 17:32. Évalué à 4.
        
        c'est de la doc pour le développeur comme pour le compilateur.
        
        tu veux la supprimer ? bel esprit.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 17:35. Évalué à 2.
        
        Tu crois que les développeurs Java ou .NET n'ont pas les moyens de fournir d'information aux développeurs et aux compilateurs ?
        Si, et pourtant ils n'utilisent pas ces foutus .h qui sont à baffer.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Gniarf le 08 juillet 2009 à 19:24. Évalué à 2.
        
        oh je suis au courant depuis 1997 au moins, concernant Java. et 1994 pour C++ via les RTTI. je ne parlerai même pas de Smalltalk, parce que je suis un gars bien (tm).
        
        et ce "à baffer" ? intolérance detected
        
        surtout que comme son nom l'indique, ce n'est jamais que de l'inclusion de texte, par un bête préprocesseur qui fait aussi de l'extension de macros
        
        s'en prendre juste à ça est particulièrement tarte, car cpp (par exemple) sert également pour l'assembleur... ou pour n'importe quel langage, Java ou C# inclus. tant pis si ça fait hurler les puristes, je m'en suis servi des années, certaines macros rendaient bien moins verbeux mon code Java et Java avait beau ne pas supporter les macros, je n'allais pas me laisser emmerder pour si peu.
        
        donc en fait c'est que des gens utilisent un langage sans possibilité d'introspection de type qui te fait hurler ? si eux n'en ont pas besoin, comment dire, euh... non, en fait tu veux leur enlever ce choix.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 19:31. Évalué à 2.
        
        Ce qui me fait hurler, c'est les .h, et uniquement les .h.
        Cette possibilité qu'il y a à mettre du code dans un .h avec toutes les merdes que cela entraîne.
        Qui ne sait jamais fais avoir parcqu'il a ajouté un champs private dans sa classe (dans le .h forcement) et qui se retrouve avec une application compilé avant qui saute parcqu'elle fait une allocation de ton objet mais qui a changé de taille dans ton implémentation ?
        Qui ne s'est jamais résolu à cantonner la section private à un pointeur vers une structure pour éviter ce problème (la taille de la classe ne bougeant alors plus, seule la structure évolue) ?
        Qui ne s'est jamais pris la tête avec un #pragma ou autre connerie pas fermée dans un .h et qui te fou la grouille pas possible dans ton programme parcque t'as inversé 2 #includes ?
        Qui ne sait jamais dis : mais pourquoi les templates sont déclarés dans les .h ??
        
        C'est pas uniquement parcque l'introspection n'est pas présente en C++, c'est surtout parcque on peut tout et n'importe quoi dans un .h. Il aurait fallu définir clairement son contenu et le cantonner à du déclaratif uniquement, surtout pas de code ou d'exposition de données privées (champs private).
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 19:42. Évalué à 2.
        
        Tu aurais été embêté pour faire de la compilation séparée sans les .h.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 19:45. Évalué à 2.
        
        J'ai proposé à la fin des améliorations possible en gardant le principe.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 09 juillet 2009 à 11:54. Évalué à 2.
        
        Si tu n'as pas de données privées dans les déclarations de class comment le compilo peut connaitre la taille de l'objet ?
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 09 juillet 2009 à 12:13. Évalué à 2.
        
        Je propose des pistes, effectivement y'a le problème de la taille de l'objet, ce qui peut difficilement être réglé sans changer la sémantique du new (on pourrait imaginer que c'est la classe qui fait concrêtement la réservation mémoire).
        Enfin déjà interdire la présence du moindre code pour éviter qu'il soit compilé différemment dans la lib et par celui qui l'utilise ca serait bien.
        Ca suppose que le code des templates notamment puisse être mis ailleurs (me semble que ca va être le cas dans la prochaine version).
        Enfin bref, c'est trop tard, je dis juste que ca a été très mal conçu ce système de .h et que c'est une vraie plaie à l'utilisation : y'a intérêt d'avoir des conventions et d'être très rigoureux. Et surtout que tout le monde fasse comme toi dans le même projet sinon c'est la merde.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 09 juillet 2009 à 12:58. Évalué à 2.
        
        on pourrait imaginer que c'est la classe qui fait concrètement la réservation mémoire
        
        Et comment tu fais les allocations dans la pile pour les objets automatique ?
        
        Enfin déjà interdire la présence du moindre code pour éviter qu'il soit compilé différemment dans la lib et par celui qui l'utilise ca serait bien.
        
        Dans ce cas tu te prives de beaucoup de possibilités d'optimisation, typiquement les accesseurs devraient être dans le .h pour être inline.
        
        Ca suppose que le code des templates notamment puisse être mis ailleurs (me semble que ca va être le cas dans la prochaine version).
        
        Il doivent être compiler, donc cela parait difficile.
        
        Enfin bref, c'est trop tard, je dis juste que ca a été très mal conçu ce système de .h et que c'est une vraie plaie à l'utilisation : y'a intérêt d'avoir des conventions et d'être très rigoureux. Et surtout que tout le monde fasse comme toi dans le même projet sinon c'est la merde.
        
        Chaque élément de compile doit avoir toutes les infos. Et les infos partagées sont dans le .h. La seul étape qui reste est le link (long car il concerne l'ensemble du projet).
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 09 juillet 2009 à 13:05. Évalué à 2.
        
        Et comment tu fais les allocations dans la pile pour les objets automatique ?
        Effectivement.
        
        Dans ce cas tu te prives de beaucoup de possibilités d'optimisation,
        Des fois je préfères moins d'optimisation :)
        
        Il doivent être compiler, donc cela parait difficile.
        Pré-compilé.
        Mais bon c'est tout le concept des templates que je trouve foireux.
        
        Chaque élément de compile doit avoir toutes les infos.
        Le problème, c'est quand les étapes de compilation ne se font pas en même temps par le même compilateur, c'est là que c'est le bordel : tu diffuse une lib, tu regénères qu'une partie, t'utilises un compilateur ou une plateforme différente, etc. Les risques de désynchro ou d'incompatibilité entre les modules est trop forte.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 09 juillet 2009 à 13:09. Évalué à 2.
        
        Des fois je préfères moins d'optimisation :)
        
        tu imagines ne pas inliner l'équivalent de tab[i] ?
        
        Mais bon c'est tout le concept des templates que je trouve foireux.
        
        Moi aussi. Mais c'est en même temps la force de C++ qui lui permet d'être encore très utilisé maintenant.
        
        Le problème, c'est quand les étapes de compilation ne se font pas en même temps par le même compilateur, c'est là que c'est le bordel : tu diffuse une lib, tu regénères qu'une partie, t'utilises un compilateur ou une plateforme différente, etc. Les risques de désynchro ou d'incompatibilité entre les modules est trop forte.
        
        Cela a toujours été vrai. Ce qui tourne sous .NET à peu de chance de tourner correctement sous Mono (sauf à y faire des tests spécifiques).
        En plus, l'ABI C++ de gcc 3.* changeait beaucoup.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 09 juillet 2009 à 13:19. Évalué à 2.
        
        Ce qui tourne sous .NET à peu de chance de tourner correctement sous Mono
        Gni ? Tu confonds pas tout là ? on parle de quoi ? Du langage ? Du compilateur ? Du runtime ou des bibliothèques ?
        
        En plus, l'ABI C++ de gcc 3.* changeait beaucoup.
        Encore un truc que je supporte pas dans ce langage, l'absence de spécification pour l'ABI du code produit.
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 09 juillet 2009 à 13:31. Évalué à 2.
        
        Gni ? Tu confonds pas tout là ? on parle de quoi ? Du langage ? Du compilateur ? Du runtime ou des bibliothèques ?
        
        Je parle des framework MS et ceux de Novell.
        
        Encore un truc que je supporte pas dans ce langage, l'absence de spécification pour l'ABI du code produit.
        
        Il faut voir la taille du bousin.
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 09 juillet 2009 à 13:43. Évalué à 1.
        
        Je parle des framework MS et ceux de Novell.
        Oué oué oué, en gros tu veux parler des libs, c'est là qu'il y a des incompatibilité.
        Rien d'anormal, ce sont 2 frameworks différents, avec une partie en commun et chacun des spécificités. Où veux-tu en venir ?
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Nicolas Boulay (site web personnel) le 09 juillet 2009 à 13:53. Évalué à 2.
        
        Et cela se passe comme une fleur avec la partie commune ?
        
        Tu me dira mono doit faire des testes de conformité avec l'implémentation de MS.
        
        Il n'y a guère que le C/C++ qui a autant de fournisseur de compilateur C.
        
        D'ailleurs, une question à part: est-ce que mono tourne sous d'autre cible que le x86 ?
        "La première sécurité est la liberté"
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par TImaniac (site web personnel) le 09 juillet 2009 à 14:02. Évalué à 3.
        
        Et cela se passe comme une fleur avec la partie commune ?
        Ben c'est comme tout, ca dépend des parties dont tu parles évidemment.
        Pour ce qui concerne les libs standards, je n'ai jamais eu de problème de compatibilité.
        
        Tu me dira mono doit faire des testes de conformité avec l'implémentation de MS.
        Y'a une batterie impressionnante de tests unitaires pour valider la conformité avec les libs MS.
        
        D'ailleurs, une question à part: est-ce que mono tourne sous d'autre cible que le x86 ?
        Ben : http://www.mono-project.com/Supported_Platforms
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Étienne le 09 juillet 2009 à 19:52. Évalué à 2.
        
        Ca suppose que le code des templates notamment puisse être mis ailleurs (me semble que ca va être le cas dans la prochaine version).
        
        C'est déjà le cas via la directive export qui n'est malheureusement implémentée pas quasiment aucun compilateur.
        
        Sinon pour le fait de ne mettre que des déclarations dans les .h je suis assez d'accord, le problème du C++ c'est de devoir faire pas mal de compromis vis à vis de la compatibilité avec le C.
        
        Étienne
        
        [^] # Re: Pourquoi Mono ?
        
        Posté par Littleboy le 11 juillet 2009 à 13:40. Évalué à 2.
        
        En meme temps, il y a tellement de limitations avec export (et peu de gens savent exactement ce que ca fait), que l'interet de l'implementer n'est pas tres grand.
        
        Et IIRC y a pas vraiment de fabricants de compilateur qui ont prevu de le rajouter. Implementer TR1 est quand meme beaucoup plus interessant et utile que de se faire chier avec tous les corner cases de export.
  - [^] # Re: Pourquoi Mono ?
    
    Posté par téthis le 07 juillet 2009 à 14:06. Évalué à 2.
    
    > Quel est vraiment l'intérêt d'avoir ces lourdes machines virtuelles qui exécutent du bytecode sur différentes archis ?
    
    Parce que la VM est capable d'optimiser le code natif en fonctions des spécificités de la machine réelle. C'est en théorie la possibilité d'avoir la modularité d'une distribution source avec une distribution binaire.
    
    > Dans le libre on prend le source et on le compile directement c'est tout.
    
    Il y a plein de VM dans le libre, Python, Perl, Lua(JIT)... Principalement des langages de scripting. Le but de la VM n'est pas que de faire abstraction de l'architecture, c'est aussi un moyen d'offrir une architecture similaire afin de fournir un socle commun à un ensemble d'outils. Là, on prend la lorgnette par l'autre bout et on voit pourquoi le monde .net se voit peuplé d'un bon nombre de langages.
    The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein
  - [^] # Re: Pourquoi Mono ?
    
    Posté par IsNotGood le 07 juillet 2009 à 15:42. Évalué à 6.
    
    > Quel est vraiment l'intérêt d'avoir ces lourdes machines virtuelles qui exécutent du bytecode sur différentes archis ?
    
    Dans mon soucis avec Mono (et C# en général), j'en ai un peu rien à foutre que Mono soit une marchine virtuelle etc.
    Cette technologie a des intérêts. D'un point de vu technique, Java est fort correct.
    
    Mon soucis est que C# est une techno MS, dirigée par MS, pour Windows. L'écosystème de C#, c'est MS. L'écosystème de Java, c'est ... java (Sun, Oracle, IBM, Red Hat, etc).
    
    L'implémentation de référence de C# est, et restera, celle de MS, n'est pas libre et ne le sera pas avant des lustres.
    L'implémentation de référence de Java est celle de Sun/Oracle, évidemment, mais avec la participation d'autres acteurs (notablement IBM et Red Hat et j'en oublie beaucoup). Cette implémentation de référence est déjà libre et sous GPL v3 ce qui écarte tout problème de brevet. Beaucoup d'élément périphérique à Java sont libres et sans problème de brevet (hors les problèmes que tout programme peut avoir).
    
    Bref, je ne veux pas de C#, aussi méritante soit cette technologie.
    - [^] # Re: Pourquoi Mono ?
      
      Posté par patrick_g (site web personnel) le 07 juillet 2009 à 16:58. Évalué à 5.
      
      >>> Mon soucis est que C# est une techno MS, dirigée par MS, pour Windows.
      
      Ouais c'est vrai que ce point là est aussi très important. C'est MS qui dicte les changements à apporter et Mono ne fait que réimplémenter ces changements sans jamais participer aux décisions.
      - [^] # Re: Pourquoi Mono ?
        
        Posté par Littleboy le 07 juillet 2009 à 19:25. Évalué à 2.
        
        Sauf que:
        1. ils participent au niveau de la standardisation et ont donc un peu leur mot a dire
        2. ils ont pas attendu MS pour rajouter plein de trucs qui ne sont pas dispo du tout dans la version MS. Des trucs genre scripting, manipulation vectorielle, possibilite de compiler en "statique" et donc de distribuer sur iPhone par exemple.
  - [^] # Re: Pourquoi Mono ?
    
    Posté par IsNotGood le 07 juillet 2009 à 15:47. Évalué à 3.
    
    Mais pour les firmes qui vivent dans le monde propriétaire cette solution n'est pas envisageable...donc création de Java et .NET.
    
    Tu égares un peu. On peut faire du proprio avec des sources.
    Je prend du C, je compile, je ne distribue que le binaire.
    On peut le faire avec python, php, etc.
    Il n'y a que la licence des sources qui compte.
- [^] # Re: Pourquoi Mono ?
  
  Posté par Camille_B le 07 juillet 2009 à 13:47. Évalué à 2.
  
  «Au début de la news j'ai eu une grosse frayeur : j'ai cru que patrick_g était un Mono fan ...»
  
  Ne pas dire du mal de Mono c'est être un "Mono fan"...
  
  «Je ne comprend pas Miguel non plus ! C'est un type extrêmement brillant techniquement. J'imagine qu'il s'éclate sur Mono, mais pourquoi ne pas faire avancer Gnome et le libre en générale qui a besoin d'inventer le futur, plus que de porter les technologies des autres !»
  
  Faut-il rappeler encore et encore, y compris à un patrick_g qui sait pourtant rudement bien se documenter quand il s'agit du noyau linux, que Mono n'est pas qu'un port de .NET mais intègre des bibliothèques qui lui sont spécifiques ?
  - [^] # Re: Pourquoi Mono ?
    
    Posté par briaeros007 le 07 juillet 2009 à 19:15. Évalué à 2.
    
    mais intègre des bibliothèques qui lui sont spécifiques ?
    Soyons franc, mono est utilisé comme plateforme de compatibilité avec .net, pas comme plateforme de développement dédié.
    - [^] # Re: Pourquoi Mono ?
      
      Posté par zebra3 le 07 juillet 2009 à 19:29. Évalué à 2.
      
      C'est vrai qu'aucun logiciel spécifique Mono n'a encore été écrit, et que GTK# existe juste pour le fun...
      
      (Tiens, ce matin, j'ai voulu essayer Tomboy sous Windows, hé bien il m'a fallu télécharger l'installeur GTK# pour Windows avant, c'est dire).
      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
    - [^] # Re: Pourquoi Mono ?
      
      Posté par TImaniac (site web personnel) le 07 juillet 2009 à 19:31. Évalué à 2.
      
      D'ailleur on est sur LinuxFR, et F-Spot, Tomboy, GnomeDo, Banshee & co ont été codés avec mono uniquement à cause de la compatibilité avec .NET, tous ces logiciels tournant outofthebox sous Windows et n'ayant aucune dépendance à Gnome.
      - [^] # Re: Pourquoi Mono ?
        
        Posté par briaeros007 le 07 juillet 2009 à 19:46. Évalué à 2.
        
        ok, génial, donc les librairies mono ont servi a faire 4 logiciels.
        Trop top.
- [^] # Re: Pourquoi Mono ?
  
  Posté par Axioplase ıɥs∀ (site web personnel) le 08 juillet 2009 à 06:29. Évalué à 5.
  
  >> j'ai eu une grosse frayeur : j'ai cru que patrick_g était un Mono fan ...
  
  J'espère que tu ne fais pas partie de ces gens qui oublient tout dès qu'une opinion sur un problème n'est plus en accord avec toi (ce qui est le cas ici, vu que pbpg se tape souvent les notes négatives "par principe" on dirait…)
  
  >> Ouf ! Lui aussi n'est pas convaincu par l'absolue nécessité de Mono !
  
  Et ? Encore une fois, ses (très bons) dépêches et journaux n'en font pas parole d'évangile pour autant.
  Moi je ne suis pas convaincu par l'absolue nécessité de KDE, de Java et du web 2.0.
  Je ne vois l'intérêt à *aucun* de ces trois trucs, dans *aucun* cas, serveur ou non.
  Pas de quoi échapper un "ouf" pour autant, sauf tu si tu voues un culte aveugle à la personne.
  
  >> Franchement C# c'est sympa à utiliser (j'ai bossé 6 mois avec dans de l'embarqué sur PDA). Mais l'est-ce plus que Java ? Pas de façon notable. Est-ce plus performant que le C++ ou le C ? Clairement non.
  >> Alors pourquoi ? Pourquoi Mono ?
  
  Là, on est d'accord. Common Lisp pour tout le monde, histoire d'être cohérent, d'avoir un langage objet efficace et très sympa, portable, facile à utiliser, avec une norme, des implantations libres.
  Mais pourquoi donc vouloir utiliser C, Java, Ruby, Python alors qu'il y a CL. Vraiment, y a des gens déraisonnés ici !
  
  >> Je ne comprend pas Miguel non plus ! C'est un type extrêmement brillant techniquement. J'imagine qu'il s'éclate sur Mono, mais pourquoi ne pas faire avancer Gnome et le libre en générale qui a besoin d'inventer le futur, plus que de porter les technologies des autres !
  
  Moi je comprend pas Stallman. Au lieu de travailler sur Emacs, il ferait mieux de faire avancer firefox et faire avancer le le libre en général auprès de la famille Michu au lieu de réinventer la roue et de porter les technologies des autres dans son bloatware.
  Tu vois, c'est subjectif l'apport au libre, le goût du code et le choix du langage…
# Techniquement, pourquoi Mono

Posté par Guillaum (site web personnel) le 07 juillet 2009 à 13:44. Évalué à 5.

J'avais posé ma question lors du dernier troll

http://linuxfr.org/comments/1044941.html#1044941

et elle reste d'actualité. En oubliant le coté marketing, le coté ".Net c'est cool sur un CV" et différents autre aspects subjectifs, pourquoi MONO pour une personne qui ne s'intéresse qu'au technique. Lorsque l'on a le choix et que l'on cherche la meilleur solution technique, en quoi mono est intéressant ?

J'aimerais juste un avis technique de "Mono fans" qui essayerait de me convertir, que vous apporte Mono (et son environnement) par rapport a d'autres solutions (je pense a python/GTK ou python/QT parce que c'est ce que je connais très bien, mais il existe pleins d'autres environnements libres, ayant une quantité impressionnante de bibliothèques, des langages avec pléthore de syntaxe plus ou moins sympathiques...

Bref, techniquement, qu'apporte Mono au libre (et c'est une vrai question !), pourquoi devrait-je contribuer à mono et pas a un autre projet ? Quel est l'intérêt de consacrer des ressources au développement de Mono qui jusqu'à présent n'a pas apporté grand chose de concret au libre et à gnome (encore une fois, cela est subjectif, mais hormis fspot, banshee, tomboy et gnome-do je serais incapable de citer une application écrite en mono, et pour la plupart j'ai vraiment l'impression qu'il s'est agit d'une perte de temps lorsque la contribution aurait pu aller sur un logiciel équivalent (rhythmbox, note applet, deskbar applet, eog).
- [^] # Re: Techniquement, pourquoi Mono
  
  Posté par Camille_B le 07 juillet 2009 à 13:56. Évalué à 2.
  
  Comme vous le dites vous-même «il existe pleins d'autres environnements libres, ayant une quantité impressionnante de bibliothèques, des langages avec pléthore de syntaxe plus ou moins sympathiques».
  
  Ne vous êtes-vous jamais demandé pourquoi cette "quantité impressionnantes de bibliothèques, de langages" ?
  
  Après tout pourquoi Python, il y a Perl ? Pourquoi Perl, il y a le C ?
  
  Sortez deux secondes de Mono, prenez deux ou trois langages et/ou framework de votre choix, et posez à nouveau cette question.
  
  J'espère que vous obtiendrez de vous-même la réponse.
  - [^] # Re: Techniquement, pourquoi Mono
    
    Posté par Guillaum (site web personnel) le 07 juillet 2009 à 16:18. Évalué à 2.
    
    Je saurais dire pourquoi Perl sur le C, langage interprété, orienté script administration et traitement de chaîne. Je saurais dire pourquoi python, syntaxe plus explicite, se voulant plus clair, J'ai toujours considéré perl comme la boite à outil du programme d'admin vite fait bien fait qui répond au besoin du moment, mais je n'envisagerais jamais un gros développement en Perl, là où python fait plus propre (ici encore c'est une affaire subjective qui résulte de préférences personnelles). Je saurais aussi dire pourquoi je fais du C de temps en temps, principalement le contrôle que cela m'apporte sur mon code, les performances aussi, lorsque c'est vraiment nécessaire (ce qui arrive bien moins souvent que ce que la plupart des gens pensent)
    
    Mais vraiment, qu'apporte Mono, c'est une vrai question ?
    
    Personnellement, pour avoir fait du C# lors d'un projet il y a 3 ans, j'y ai vu un langage avec une syntaxe que je n'apprécie pas, plutôt complexe. Des fois la complexité apporte de la fonctionnalité, ici je n'ai vu aucune fonctionnalité dans le langage que je puisse qualifier de "killer feature" et qui justifie la complexité de la syntaxe.
    
    Après, certaines personne défendent les performances de mono qui surpassent celle de python par exemple. C'est vrai. Je m'en cogne. Pourquoi ?
    
    <attention>Dans la suite du texte, 99.9% représente une valeur fortement élevée et proche de 100%</attention>
    
    Dans 99.9% des cas, les besoins en performances sont une vaste blague, F-spot a besoin de performance ? Banshee aussi ? Tomboy ? Presque tous le temps de calcul est passé dans GTK, gstreamer ou X. Ici le langage fait plutôt office de colle glu entre ces différents composants et la seule performance ayant de l'importance tient dans le temps de chargement de la VM. Ici 16ms pour python, 100ms pour le chargement d'une petite application GTK, qui va sûrement rester affichée plusieurs minutes. Mono démarre plus vite, franchement, c'est une bonne nouvelle, cela change quoi ?
    
    Lorsque l'on a besoin de performance dans une application, soit toute l'application se doit d'être performante (et la on écrira le code en C car de toute manière Mono est trop lent), soit il s'agit (comme dans 99.9% des cas) d'un petit bout de l'application, qu'il est facile de réécrire en C pour que toute l'application en profite (pareil, si cette partie avait été écrite en Mono, il aurait fallu la réécrire)
    
    Le pire c'est que bien souvent le problème de performance vient d'un algorithme mal pensé ou d'une mauvaise libraire, ou d'entrées sorties. Et cela, j'ai du mal à croire que Mono s'en sorte mieux sur les entrée sortie qu'un autre langage, puisque de la même manière, tous le temps est passé dans le même traitement au sein du kernel et du hardware.
    
    Maintenant vient l'argument de la probabilité et de l'interoperabilité que Mono apporte avec les technologie .Net. Je n'y crois presque pas. A partir du moment ou il y a deux implementations différentes, la portabilité ne peut pas être aisée. Il y a qu'à voir Java sur téléphones portables, C sur les différents compilateurs ou aussi les différentes implementations de python (Cpython, Jpython, IronPython, Stackless, Pypy...). A mon sens Mono est un environnement de développement portable, mais il n'assure pas la portabilité des applis écrites pour .Net sur d'autres plates-formes. (c'est du vécu, application très simple écrite pour Mono qui m'a demandé des heures de boulot pour faire tourner dans Visual Studio)
    
    Peut être que je me plante complètement, mais si c'est le cas, 1) dites le moi (en argumentant) et 2) donnez moi des avantages à utiliser Mono. Sérieusement, j'en veux !
    
    On en revient donc à la question ultime, sachant le danger "potentiel" autour de Mono (existe il vraiment ?), sachant que le fait de pousser Mono pousse les technologies Microsoft (est ce que c'est grave ?) et sachant que Mono est techniquement (jusqu'à preuve du contraire) équivalent à d'autre technologies déjà existantes, quel est l'intérêt pour moi, développeur, d'utiliser Mono. Quel est l'intérêt pour moi, ingénieur, "chef de projet", de pousser mono dans mon équipe ? Quel est l'intérêt pour moi, de faire de la pub pour Mono au réunions ? Quel est l'intérêt pour moi, qui contribue au logiciel libre, à gnome, d'utiliser Mono. Et quel est l'intérêt pour le monde (et principalement celui du logiciel libre) ?
    - [^] # Re: Techniquement, pourquoi Mono
      
      Posté par Camille_B le 07 juillet 2009 à 16:31. Évalué à 3.
      
      Franchement, n'ayant jamais programmé avec Mono, je ne suis pas la personne la mieux placée pour répondre précisément à cette question. Il y a déjà eu des réponses, il y en a sur le web.
      
      Je vois personnellement plusieurs choses
      
      1) Mono et .NET ne sont pas que C#. .NET/Mono est un environnement conçu pour la programmation avec plusieurs langages. N'importe quelle VM peut théoriquement le faire (Scala, Clojure sur Java etc.). Mais on sait très bien que lorsque c'est conçu pour, ça fonctionne généralement mieux.
      
      2) Ça permet d'attirer des programmeurs n'ayant jamais touchés qu'à .NET à venir plus facilement vers le libre. Et ça, on pourra dire ce que l'on veut, ça n'est pas rien.
      
      3) Mono est, je crois très objectivement, l'environnement de développement le plus abouti et le plus agréable pour GNOME. L'arrivée de Vala, les améliorations apportées à Anjuta peuvent progressivement changer la donne, mais en l'état actuel...
      
      4) Il y a sans doute plein de fonctionnalités techniques qui justifient dans tels et tels cas l'utilisation de Mono plutôt que X ou Y, mais je ne connais pas suffisamment la chose pour m'avancer dans ce domaine.
      
      Au sujet de 1) : Parrot est une réponse. Et personnellement, c'est une réponse que j'apprécie. Je n'aime pas les gros framework, les gros IDE etc. question de gout.
      
      Au sujet de 2) : seul Mono peut y répondre.
      
      Au sujet de 3) : tout dépend de l'avenir de Vala, des outils de devs Python/Gnome mais aussi Java/Gnome (ne l'oublions pas !).
      - [^] # Re: Techniquement, pourquoi Mono
        
        Posté par Guillaum (site web personnel) le 07 juillet 2009 à 16:47. Évalué à 1.
        
        Enfin des arguments, et plutot interessants en plus ;)
        
        1) oui, je suis parfaitement d'accord, j'aimerais bien voir ce que ce genre de concepts peut donner. Le probleme qui se pose ici c'est que (cf un de mes postes précedents), je doute de la capacité de ce genre d'outil à fonctionner correctement, implementation differente, fonctionnement different. De plus, chaque langage a ces specificités et j'ai vraiment du mal à imaginer une VM tellement generique qu'elle peut couvrir efficacement plusieurs langages (j'avoue que à ce niveau je n'y connais pas grand chose).
        
        2) oui.
        
        3) Personellement je ne trouve pas. Hormis le fait que Mono possede un IDE tres sympa, je trouve que python/Gnome est vraiment exceptionel. Mais bon, ici on est dans le subjectif ;)
        
        4) J'attends ces X ou Y.
        
        [^] # Re: Techniquement, pourquoi Mono
        
        Posté par Camille_B le 07 juillet 2009 à 16:55. Évalué à 2.
        
        1) Il semble pourtant que ça fonctionne ;) Là ou je suis également dubitatif c'est l'argument du "chacun développe dans son langage de prédilection au sein d'une équipe". Dit comme ça c'est beau, mais dans les faits se doit être ingérable.
        
        Je vois cependant deux intérêts majeurs : utiliser le langage de son choix et profiter d'un framework que l'on connait ; redonner vie à des langages moribonds (ex : Clojure, un lisp pour Java).
        
        3) Oui, Pytho/Gnome est excellent. Mais je pensais moins aux bibliothèques disponibles qu'à l'outillage. Monodevelop c'est un peu le Visual Studio, l'Eclipse de GNOME. Et il est le seul. Anjuta n'étant, il me semble, pas vraiment au point. Je ne suis pas fan de ces outils, mais beaucoup aiment, et ça compte. Reste la solution Java/Gnome/Eclipse, mais elle est malheureusement bien trop marginale.
        
        4) À bon entendeur !
  - [^] # Re: Techniquement, pourquoi Mono
    
    Posté par Gniarf le 07 juillet 2009 à 17:47. Évalué à 2.
    
    et revenez dans 5-10 ans quand le moindre processeur sera un quad-core mais surtout que les "PCs" d'aujourd'hui seront au format boite d'allumettes (les petites), qu'ils ne couteront plus que 20 euros et que vous en aurez au bas mot une douzaine ou deux dans votre appart, et que ça communiquera joyeusement dans tous les sens.
    
    est-ce que des applis Mono marcheront toujours ? oui, même si c'est plus du x86. est-ce que ça sera la plateforme la plus adaptée ? ce qui est sûr, c'est qu'elle se fera cracher dessus parce que ça ne sera plus celle à la mode
    - [^] # Re: Techniquement, pourquoi Mono
      
      Posté par yellowiscool le 07 juillet 2009 à 21:50. Évalué à 1.
      
      Dans 10 ans, les pc feront des choses tellement plus lourdes qu'une application mono ramera toujours par rapport à la même en C++.
      Envoyé depuis mon lapin.
- [^] # Re: Techniquement, pourquoi Mono
  
  Posté par Ririsoft le 07 juillet 2009 à 14:24. Évalué à 4.
  
  Je me pose la même question plus haut !
  
  En ce qui concerne Gnome (Qyoto, le binding Mono pour QT/KDE étant peu avancé/utilisé) je suis d'autant plus dubitatif que Mono ne se contente que de faire des bindings pour toutes les technologies Gnome : gtk#, gstreamer#, ...
  
  Je ne vois rien de ces fameuses librairies 'en plus' de .NET contenues dans Mono qui soient utiles aux applications Gnome développées sous Mono. La preuve en ait la facilité de portage de Tomboy vers C++ : visiblement rien n'a manqué pour faire un Tomboy clone en C++ ...
  
  Par contre je vois des trucs qui me gênent : Par exemple F-Spot a introduit un Widget GTK pour naviguer dans l'historique des photos (la barre horizontale chronologique). Et bien le widget n'a pas été porté pendant longtemps (peut-être ne l'est-il pas encore aujourd'hui) sous GTK/C, enfreignant ainsi un des principes mêmes de Gnome : avoir la base en C et fournir des bindings pour le plus large panel de languages possibles. Résultat seuls les développeurs Mono/GTK# peuvent utiliser ce widget. C'est bof ...
  - [^] # Re: Techniquement, pourquoi Mono
    
    Posté par zebra3 le 07 juillet 2009 à 15:02. Évalué à 2.
    
    Par contre je vois des trucs qui me gênent : Par exemple F-Spot a introduit un Widget GTK pour naviguer dans l'historique des photos (la barre horizontale chronologique). Et bien le widget n'a pas été porté pendant longtemps (peut-être ne l'est-il pas encore aujourd'hui) sous GTK/C, enfreignant ainsi un des principes mêmes de Gnome : avoir la base en C et fournir des bindings pour le plus large panel de languages possibles. Résultat seuls les développeurs Mono/GTK# peuvent utiliser ce widget. C'est bof ...
    
    Ça tombe bien, F-Spot ne fait pas officiellement partie de GNOME.
    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
- [^] # Re: Techniquement, pourquoi Mono
  
  Posté par Badeu le 07 juillet 2009 à 21:02. Évalué à 1.
  
  Bon je savais pas où poser ma question dans tout ce troll mais je me lance ici. Sachant que je ne suis pas familier des mécanismes des VM type java/mono et que mon travail concerne l'informatique robuste à bas niveau donc très loin des .net & co et proche des descriptions HDL et de l'assembleur (ce qui va influencer à fond la question qui suivra)
  
  Sachant qu'aujourd'hui on s'oriente vers des architectures matérielles extrèmement complexes, le risque d'accumuler des erreurs transitoires lors du fonctionnement n'est plus négligeable, bien qu'on dispose de méthode pour abaisser ce risque et bien qu'on ne soit pas en environnement hostile.
  
  si je fais un a = 5; en C qui sera traduit par le compilo en "li Rd, 5" (attention pseudo asm pour illustrer l'idée), l'opération est effectuée en un cycle. La probabilité qu'une erreur se produise pendant cette opération est donc faible.
  
  si je fais un a = 5; en C# qui sera traduit en bytecode qui sera exécuté sur une VM qui va charger le 5 dans un "registre virtuel" de la machine virtuelle, qui va faire intervenir tout plein d'étapes supplémentaires pour finalement finir en mémoire car le fonctionnement de la machine implique un nombre d'aller-retours cache <-> registres plus nombreux que si on était en code natif.
  
  Là l'opération prend beaucoup plus de cycles pour s'exécuter, et même si la différence de performance semble négligeable à l'échelle humaine, j'y vois surtout un risque d'erreur largement multiplié pouvant ne pas faire aboutir la simple opération a = 5, ou pire rendre l'exécution du programme dangereuse.
  
  Alors n'y a t'il pas un risque d'avoir plus d'erreurs incontrôlables/indétectables à ajouter une énième couche d'abstraction, surtout aussi éloignée, pour l'exécution d'un programme ?
  
  Si c'est pour l'aspect pédagogique de .net, éventuellement, je comprend qu'on puisse le défendre si ça permet à des gens d'apprendre à coder.
  Mais, quand c'est pour faire des logiciels qui seront utilisés, parfois des applis critiques, à cause d'un simili-lobby d'ingénieurs qui veulent du "modernisme" là je trouve qu'il y a un soucis. Plus on s'éloigne du bas niveau, plus on augmente le risque d'erreur, risque d'erreur qui continue d'augmenter par le simple fait des évolutions techniques du matériel. Donc une croissance exponentielle du risque d'erreur.
  - [^] # Re: Techniquement, pourquoi Mono
    
    Posté par pasBill pasGates le 08 juillet 2009 à 03:03. Évalué à 2.
    
    Au total sur un journee le nombre d'instructions executee par une app standard sous une VM au total sera probablement plus faible que le nombre d'instructions executees par l'OS vu que l'OS il tourne non-stop du matin au soir, bref il y a plus de chance que ton erreur se produise lorsque l'OS execute du code plutot que la VM.
    
    Si ton OS se plante a cause de problemes de ce genre, on va dire qu'un probleme dans la VM sera le moindre de tes soucis...
    - [^] # Re: Techniquement, pourquoi Mono
      
      Posté par Badeu le 08 juillet 2009 à 04:28. Évalué à 1.
      
      Oui mais sachant qu'on parle d'un type d'erreur indépendant du programme en cours d'éxécution avec une probabilité de se produire constante au cours du temps.
      Et, sachant qu'en plus les conséquences peuvent être identiques (plantage de la machine ou résultat innatendu mais indétectable) et cela que l'erreur se produise lorsque l'OS a la main ou lorsque c'est un programme utilisateur.
      
      Bien entendu que la probabilité qu'une erreur se produise dans le programme qui a le plus souvent la main est plus grande et justement c'est la toute la problématique, car la question que je posais est une comparaison entre programme à service rendu équivalent : un programme éxécuté dans une VM recquierant plus de cycles qu'un programme natif, sa probabilité d'erreur augmente, est-ce que le jeu en vaut la chandelle ?
      
      Le principe des VM étant, techniquement, plus sensible aux erreurs que le natif, pourquoi lorsque cela est possible, préférer un développement sur VM plutôt qu'en natif ?
      
      Si la réponse est la portabilité multi-plateforme, on entre dans une logique de coût.
      Si la réponse est la facilité de développement qu'offre ces environnement, on entre dans une logique de coût à nouveau.
      Si la réponse est la pédagogie, on sort du champs d'actions des applications destinée utilisateur final.
      
      Est-ce que la logique de coût est une motivation essentielle dans le libre ?
      Est-ce que la logique de coût est prépondérante sur la sécurité ? (ouais, certes je connais hélàs la réponse...)
      - [^] # Re: Techniquement, pourquoi Mono
        
        Posté par pasBill pasGates le 08 juillet 2009 à 04:56. Évalué à 1.
        
        Tant que l'OS a plus de chance de planter qu'une application quelconque, et c'est le cas pour la plupart des apps tournant sous VM sur un desktop, vu que l'OS va executer bcp plus d'instructions, le fait que cette app ait plus de chances de planter qu'une app native est sans interet, si ton OS plante tous les jours, tu te fiches totalement de savoir si ton app va planter aussi en plus, ca sera inutilisable.
        
        Alors oui, selon cette mesure une app sous VM pourrait etre plus a risque q'une app native, mais vu qu'elle est de toute facon moins a risque que l'OS dans la plupart des cas pratiques, on s'en fiche vu que sans OS, pas d'app.
        
        [^] # Re: Techniquement, pourquoi Mono
        
        Posté par Badeu le 08 juillet 2009 à 06:38. Évalué à 1.
        
        Pour faire une même chose une VM est moins fiable qu'un exe natif . CQFD
        
        Ça n'implique pas que tu as tort sur ton point de vue concernant la fiabilité des OS que je partage largement, mais le propos était de comparer VM vs. natif.
        Même si l'OS est un paramètre important dans la vraie vie, c'est un paramètre à négliger pour comparer deux méthodes d'implémentation d'une même application.
        
        [^] # Re: Techniquement, pourquoi Mono
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 13:00. Évalué à 1.
        
        Sachant qu'une VM n'est qu'une abstraction et que le bytecode peut être pré-compilé en code natif avant exécution (sans JIT donc), ca fou pas un peu en l'air tout ton raisonnement ?
        
        Sachant qu'à code natif exécuté identique, le bytecode équivalent est plus court, le fichier support est donc plus petit et prends moins d'espace disque, n'y a-t-il pas moins de risque d'erreur lors des entrées/sorties disques à la lecture du bytecode par rapport à un binaire qui contient la même chose en natif ?
        
        Quel est le plus probable ? Un problème d'entrée/sortie disque ou un problème bas niveau au moment de l'exécution par le processeur ?
        
        Sachant qu'on peut faire un processeur qui exécute directement du bytecode sans passer par une couche intermédiaire, l'avantage apparent du code natif ne peut-il pas être contourné ?
        
        Quel est le plus probable : un bug dans l'application où dans le processus d'exécution sous-jacent ?
        Partant de là, faut-il mieux fournir un environnement d'exécution sécurisé quitte à ajouter une couche supplémentaire ou faire du natif pour limiter les risques liées à l'exécution des instructions ?
        
        Comme toujours, il faut prioriser les risques et voir lesquels sont les plus pertinents à limiter en premier.
        
        [^] # Re: Techniquement, pourquoi Mono
        
        Posté par Badeu le 08 juillet 2009 à 22:53. Évalué à 1.
        
        Sachant qu'une VM n'est qu'une abstraction et que le bytecode peut être pré-compilé en code natif avant exécution (sans JIT donc), ca fou pas un peu en l'air tout ton raisonnement ?
        Sachant qu'on peut faire un processeur qui exécute directement du bytecode sans passer par une couche intermédiaire, l'avantage apparent du code natif ne peut-il pas être contourné ?
        
        Si on sort du champs d'action de la VM, tout a fait que ça fout mon raisonnement en l'air, vu qu'il repose sur l'utilisation d'une VM.
        
        Quel est le plus probable ? Un problème d'entrée/sortie disque ou un problème bas niveau au moment de l'exécution par le processeur ?
        Sachant qu'on peut faire un processeur qui exécute directement du bytecode sans passer par une couche intermédiaire, l'avantage apparent du code natif ne peut-il pas être contourné ?
        
        cf. réponse à pbpg sur les erreurs liées à l'OS
        
        Quel est le plus probable : un bug dans l'application où dans le processus d'exécution sous-jacent ?
        Partant de là, faut-il mieux fournir un environnement d'exécution sécurisé quitte à ajouter une couche supplémentaire ou faire du natif pour limiter les risques liées à l'exécution des instructions ?
        
        On pourrait parler d'équi-probabilité même si expérimentalement cela ne serait pas démontré. Le meilleur remède aux erreurs de ce type, qui trouvent leur origine dans des causes extérieures au programme exécuté, reste d'essayer de faire des programmes les plus performant possible en notion de nombre d'instructions exécutées. Et donc d'éviter les VM.
        
        Au final, je parlais de ça car avec les process de fabrication et la densité des portes qu'on trouve dans les puces aujourd'hui et les évolutions en cours, il n'est pas impossible que ce type d'erreur deviennent un futur casse-tête, même pour quelqu'un qui fait du développement d'application desktop.
        
        [^] # Re: Techniquement, pourquoi Mono
        
        Posté par pasBill pasGates le 08 juillet 2009 à 16:50. Évalué à 1.
        
        Pour faire une même chose une VM est moins fiable qu'un exe natif . CQFD
        
        Tout a fait, on peut dire qu'une VM est moins fiable qu'un exe natif, et que les deux sont beaucoup plus fiable qu'un OS dans le meme environnement.
        
        Comparer VM vs. natif sans tenir compte de ce dont ils ont besoin pour tourner n'a pas de sens. Aucun des 2 ne fonctionnera vu que l'OS tombera avant.
        
        [^] # Re: Techniquement, pourquoi Mono
        
        Posté par Badeu le 08 juillet 2009 à 22:43. Évalué à 2.
        
        Purement statistique, une erreur de type SEU (Single Event Upset) étant liée à une cause indépendante du programme qui s'exécute.
        
        (Analogie foireuse) Ça revient à dire pourquoi prévoir des éléments de sécurité en voitures qui tiennent le choc à 130 vu que statistiquement, on aura plus de chance d'avoir un accident en rejoignant l'autoroute et donc à moins de 130.
        
        [^] # Re: Techniquement, pourquoi Mono
        
        Posté par pasBill pasGates le 09 juillet 2009 à 02:45. Évalué à 3.
        
        Oui c'est purement statistique, mais c'est important.
        
        (Analogie foireuse) Ça revient à dire pourquoi prévoir des éléments de sécurité en voitures qui tiennent le choc à 130 vu que statistiquement, on aura plus de chance d'avoir un accident en rejoignant l'autoroute et donc à moins de 130.
        
        Non, ca revient a dire : Pourquoi mettre un gilet pare-balle pour te proteger d'un lance-roquette, parce que lorsque l'erreur se produit, si c'est pas la VM qui casque, ca sera l'OS, ce qui revient a perdre le systeme entier dand bcp de cas...
        
        Dans le meme genre, tu peux aussi decider de ne rien faire tourner sur ton systeme, comme ca tu prends encore moins de risque...
        
        Essayer d'executer le moins d'instructions possible pour se premunir d'un probleme HW, desole, mais c'est pas vraiment une solution, un PC ca sert a etre utilise...
  - [^] # Re: Techniquement, pourquoi Mono
    
    Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 12:36. Évalué à 2.
    
    Tu parles d'un monde qui veut de l'absolu sécurité. Dans ce monde là, on ne veut pas de couche à la con, on veut tout maitriser, même le reuse est suspect (syndrome Ariane V).
    
    C'est le monde sans OS, ou alors avec vxWorks ou QNX.
    
    On est très loin des standards de fiabilité d'informatique d'entreprise ou un écran bleu n'est pas "grave".
    "La première sécurité est la liberté"
    - [^] # Re: Techniquement, pourquoi Mono
      
      Posté par Badeu le 08 juillet 2009 à 16:10. Évalué à 0.
      
      j'avais prévenu que je serais absolument pas objectif :D
- [^] # Re: Techniquement, pourquoi Mono
  
  Posté par thedude le 07 juillet 2009 à 21:48. Évalué à 1.
  
  Pourquoi mono plutot que python/GTK/QT?
  
  La comme ca, sans connaitre les 2 environnements en detail, et des trucs tres generaux qui s'appliquent a priori a tous les projets:
  - Compilation/Typage fort
  - Indentation libre
  - Pas de GIL
  - Performance (au niveau de la VM notamment)
  - Langage plus expressif.
  
  On peut parfaitement preferer l'un a l'autre, mais faut etre sacrement borne pour ne pas voir les avantages
  
  Pourquoi Mono plutot que Java, sur le poste client?
  - Parce que Swing est un merdier sans nom a developper
  - Parce que Swing, meme s'il s'est ameliore, donne toujours cette sensation de lenteur a l'utilisateur.
  - Parce que SWT est lourdingue a declarer final les 3/4 de ses classes (ca a peut etre change cela dit, ca fait un bail que j'y ai pas touche)
  - Parce que SWT necessite un package par archi/plateforme, et dans le monde java, ca fait chier, serieux.
  - Parce que Sun s'est toujours ramasse en beaute sur le poste client
  - Parce que c'est plus simple de faire telecharger un binaire pour une lib graphique sous windows que d'envoyer l'utliisateur sur le site de sun, chercher la bonne JVM parmi les 150 a disposition.
  
  J'aime beaucoup java, il me fait bouffer depuis 5 ans, mais c'est loin d'etre une reussite sur le poste client.
# Beaucoup de remplaçants, en fait.

Posté par Thierry le 07 juillet 2009 à 13:53. Évalué à 1.

avec Qt/C++ et ses bidings ou avec GTK+/C et ses bidings (plus Vala) ou encore avec Java

On peut aussi rajouter le vénérable Tk avec Perl ou Python, deux langages munis d'une impressionnante collection de bibliothèques de fonctions couvrant une foultitude de domaines...
- [^] # Re: Beaucoup de remplaçants, en fait.
  
  Posté par pixels le 07 juillet 2009 à 14:01. Évalué à 5.
  
  Est-ce que c'est de l'ironie ?
- [^] # Re: Beaucoup de remplaçants, en fait.
  
  Posté par Octabrain le 07 juillet 2009 à 14:01. Évalué à 3.
  
  Le seul avantage de Tk, c'est qu'il est dans la lib standard de Python. Ses inconvénients : bibliothèque très limitée, façon de programmer les interfaces très "années 90", laideur innommable à faire mourir un yéti.
- [^] # Re: Beaucoup de remplaçants, en fait.
  
  Posté par godzom le 07 juillet 2009 à 17:15. Évalué à 1.
  
  le vénérable Tk ? Tu ne dois pas parler du Tk que je connais, ou alors tu fais de l'humour et là tu es très fort parce que j'ai bien failli réveiller mes collègues en riant trop fort.
# les promesses

Posté par Christophe Raoux le 07 juillet 2009 à 14:16. Évalué à -3.

Les promesses n'engagent que ceux qui y croient.

Pourquoi MS se priverait-il d'attaquer quelqu'un qui lui ferait de l'ombre....

Pas mal d'autres alternatives à mono son disponibles, alors pourquoi accepter cette intrusion de MS dans le libre, en connaissant ses pratiques juridiques?

Et puis entre nous MS qui fait de l'opensource c'est comme Sarko qui fait du social, c'est à se taper le cul parterre !
# Drôle

Posté par Jb Evain (site web personnel) le 07 juillet 2009 à 16:08. Évalué à 6.

C'est rigolo. Après des années à expliquer que Mono n'était pas forcément plus en danger qu'un autre logiciel, à expliquer pourquoi c'est une solution technique viable, les gens admettent enfin leur raison du refus de Mono.

«Ça vient de Microsoft, et en utilisant Mono, on utilise du Microsoft».

Après des années à s'entendre dire, «mais non, on crache pas dessus parce que ça vient de Microsoft», l'ironie de tout ça me fait rire.
- [^] # Re: Drôle
  
  Posté par Camille_B le 07 juillet 2009 à 16:15. Évalué à 1.
  
  Oui c'est tout à fais juste.
  
  De nombreuses personnes continuent de donner des raisons de croire que Mono est toujours un danger (et il faut les entendre), mais il faut reconnaître que les trois quart des arguments sur ce billet (et sur d'autres blogs) sont du type :
  
  - De toute manière c'est du Microsoft, on ne peut pas soutenir une technique d'un vilain méchant qui n'aime pas le libre
  
  Et l'argument de ceux qui n'ont plus rien à dire mais ne veulent pas reconnaître que dans le fond seule leur haine anti-micrisoftienne primaire les animes :
  
  - Ça sert à quoi Mono ? On a déjà Python et QT.
  
  Quelle classe.
  - [^] # Re: Drôle
    
    Posté par Guillaum (site web personnel) le 07 juillet 2009 à 16:37. Évalué à 2.
    
    Le but n'est pas de ne pas soutenir une technologie d'un vilain méchant qui n'aime pas le libre. Le but est de faire de la discrimination positive. Si une technologie libre venant du libre est au moins aussi bonne que Mono, il faut la privilegier. Quand tu as un choix à faire qui ne se fait pas sur des questions technique (puisque ici l'on parle bien de technique finalement, Mono peut il répondre a mon besoin de devellopeur mieux qu'une autre solution ?), et bien tu fais un choix suivant tes convictions. C'est la même chose dans la vie, quand tu as un choix à faire et que des arguments valables ne sont pas presents pour faire la difference, et bien tu choisis sur des arguments subjectifs. Et ce que j'attend depuis le debut de cette discussion c'est quelqu'un qui pourra me donner des arguments valables sur la superiorité de Mono vis à vis de certains de ces concurents. De ce que j'en vois, Mono est une technologie moins bonne que celle que j'utilise actuellement, donc j'ai toutes les raisons de penser que c'est une betise de gaspiller des ressources dessus. Montrez moi que j'ai tord.
    
    Example d'argument dans un débat equivalent. Je n'aime pas Java, je trouve que c'est un langage moche avec une syntaxe proche de C# (;)) vraiment lourde et qu'il n'apporte rien pour mon plaisir ou ma productivité. Mais par contre il est vrai que Java est present sur tous les téléphones portables du marché, c'est un aventage certain pour deployer des applications mobiles. Donc Java possede un avantage vis à vis de ces concurents.
    
    Depuis le debut de ce debat les gens qui sont en faveur de Mono n'ont aucun argument, si ce n'est dire "regardez, ils font du racisme contre microsoft, bouh, les vilains !". On se croirait en politique...
    
    Et pour la question "Ça sert à quoi Mono ? On a déjà Python et QT.", je t'invites à repondre a une question un tout petit peut differentes. J'ai python, j'ai QT (ou gtk), pourquoi devrais-je utiliser Mono ? Cela m'apportera il quelque chose ? (tu notes la difference, ici je ne crache pas sur Mono, je demande juste les aventages que cela m'apporterais).
    
    Parce que si techniquement cela n'apporte rien, mais pourquoi on s'embete et on perd du temps à develloper cela ? Et si cela apporte quelque chose, mais pourquoi personne n'est capable de dire ce que cela apporte de bien, techniquement ?
    - [^] # Re: Drôle
      
      Posté par Camille_B le 07 juillet 2009 à 16:47. Évalué à 2.
      
      Moi moi moi en somme.
      
      Premièrement les seules personnes qui "perdent du temps" avec Mono sont celles qui travaillent avec et le développent. Et quelque chose me dit que s'ils l'utilisent, c'est qu'ils ont des raisons. Au moins une : ils aiment ça.
      
      Vous le dites vous-même : Java est moche et n'apporte rien à votre plaisir et votre productivité.
      
      Il y a des gens qui pensent la même chose de Perl, d'autres de Python etc.
      
      Quand à connaitre les qualités de Mono, ce qu'il peut vous apporter, rendez-vous sur le site officiel.
      
      Votre argument pour java est bien limité, quoiqu'existant. Dans le même genre je peux vous répondre que .NET est dans tous les IUT de France et que ça n'est pas un mal de pouvoir recycler les compétences. C'est pas l'argument ultime, mais c'est un argument très réel et très objectif.
      - [^] # Re: Drôle
        
        Posté par Guillaum (site web personnel) le 07 juillet 2009 à 17:29. Évalué à 0.
        
        L'insistance sur le moi était une "figure de style" pour insister sur le fait que j'aimerais (moi) etre convaincu.
        
        Pour la perte de temps, j'avoue que si ils aiment ca, je n'ai rien à dire (sauf peut etre si il s'agit de non assistance a personne en danger, mais je m'egare ;) On va en revenir à ce que disait stallman, concretement je n'ai rien contre Mono et contre les gens qui font du Mono, je voudrais juste qu'il reste dans leur coin. Actuellement je ne vois pas l'interet de cet environnement pour Gnome et pour le libre et je trouve qu'il est dommage de "perdre du temps" à coder des applications en Mono alors qu'elles existaient deja avant dans d'autres technologie et ne demandaient qu'a etre ameliorer. Je trouve qu'il est dommage de disperser les efforts de la comunauté pour faire deux applications qui font la meme chose dans deux langage different. Apres il est vrai qu'en pratique, ces gens contribue au libre et que il ne le font pas sur le temps ou je les paye, donc je n'ai peu etre pas mon mot à dire, si ce n'est que je pense que c'est dommage.
        
        Pour l'argument sur Java il s'agissait d'un example simple d'argument pour lancer la machine. Et finalement cela marche bien, CF le poste de TImaniac qui suis ou la reponse que vous me faites plus haut dans la discussion.
    - [^] # Re: Drôle
      
      Posté par TImaniac (site web personnel) le 07 juillet 2009 à 16:51. Évalué à 1.
      
      J'ai python, j'ai QT (ou gtk), pourquoi devrais-je utiliser Mono ? Cela m'apportera il quelque chose ?
      Apprend à lire, c'est argumenté plus haut.
      
      Je veux un langage relativement performant parcque mon application fait un minimum de traitement : C# est plus rapide que Python.
      
      Je veux une documentation complète : C# est mieux documenté que Python.
      
      Je veux un langage dont la pérénité est assurée : du code C# 1 est toujours compatible avec C# 3, le langage est standardisé.
      
      Je veux un langage "sûr" avec typage statique qui me permette de faire du refactoring sans devoir prier pour que mes hypothétiques tests unitaires couvrent bien l'ensemble du fonctionnel : C# est bien meilleur que Python.
      
      Je veux un langage avec des fonctionnalités évoluées de requête parcque je manipule beaucoup de données, je prends C# 3 parcqu'il a LINQ que Python n'a pas.
      
      Je veux un langage qui me permette à l'occasion d'avoir de bonnes performances sans me taper du code natif : je prends C# parcque je pourrais ponctuellement utiliser les pointeurs.
      
      Je veux un langage qui me permette d'étendre des types sans utiliser tout en gardant les avantages du typage statique : je prends C# avec les méthodes d'extensions.
      
      Je veux un langage qui me produit des binaires compatibles avec d'autres langages simplement : je prends C# qui me permet de produire des composants réutilisables en VB.NET, en C++/CLI, en IronPython, en Boo.
      - [^] # Re: Drôle
        
        Posté par Jb Evain (site web personnel) le 07 juillet 2009 à 17:01. Évalué à 1.
        
        Ajoutons aussi que le gros avantage de C# et de la CLI est le méchanisme de PInvoke, pour ré-utiliser du code natif existant à partir de C# directement.
        
        Plus facile que de faire des extensions Python en C, et encore plus facile que de faire du JNI.
        
        C'est une des raisons pour laquelle il a été si facile de faire des bindings Mono vers toute la pile native GNOME. Alors que java-gnome a été refait deux ou trois fois entre temps.
      - [^] # Re: Drôle
        
        Posté par Guillaum (site web personnel) le 07 juillet 2009 à 17:50. Évalué à 1.
        
```Je veux un langage relativement performant parcque mon application fait un minimum de traitement : C# est plus rapide que Python.```

Je serais presque d'accord avec cela. Tres souvent j'aimerais un peu plus de vitesse en python, et puis finalement je me rend compte qu'une utilisation plus inteligente de ma librairie (scipy par example), un petit bout de cython (qui n'est autre que du code python statiquement typé), ou un chargement rapide d'un bout de C avec ctypes et tout est reglé. Le plus crade c'est ctypes, et j'avoue que c'est une solution peu elegante. Mais cython cela revient exactement à ecrire du code python statiquement typé, et c'est rapide, tout en restant du python.

Pour la documentation complète, Ok. Je n'ai jamais eu de problème avec la doc python et j'ai toujours galeré dans la doc microsoft pour trouver ce dont j'avais besoin, mais c'est surement subjectif.

Pour la pérenité et la standardisation, rien à dire, cet argument est tres recevable (mais par contre il ne s'applique qu'à .net et pas à mono, et rien ne garantie que cela durera)

Pour le langage sur. Si tu veux du typage statique, fait du cython et le probleme est "presque reglé". D'experience personel (et encore ici, c'est subjectif), je ne pense pas que le passage de l'etape de "compilation/check des types" soit une securité. Un code qui n'a pas un minimum de couverture (et je ne parle meme pas de tests unitaire) ne peut pas fonctioner correctement.

Pour LINQ, c'est encore subjectif, mais en pratique c'est quelque chose qui se reecrit en python pur en peu de temps grace au generateurs et autres. Cela fournit les memes fonctionalitées sans complexifier le langage. C'est subjectif, mais je n'aime pas les langages avec une syntaxe complexe et plein de mot-clés.

Pour les methodes d'extension, je trouve le concept genial, mais j'aime pas, ce n'est pas explicite et c'est trop magique (par contre c'est faisable en ruby, en python et certainement dans d'autres langage. J'avoue, pour python on ne peut pas le faire avec les types de bases)

Et pour les Pinvoke que l'on site deux lignes plus bas, cela existe aussi en python et certainement dans pleins d'autres langages. Mais j'avoue, cela ne fait pas partie de la syntaxe du langage, mais d'une librairie.

Merci pour tes arguments, maintenant je vois ce qui peut plaire.

[^] # Re: Drôle

Posté par TImaniac (site web personnel) le 07 juillet 2009 à 19:28. Évalué à 2.

un petit bout de cython
C'est pas du Python, c'est un autre langage, même si la syntaxe est la même. Pérénité sur le long terme inconnue, portabilité limitée.

fait du cython et le probleme est "presque reglé".
Avec généricité & co ? Et tous les avantages que procurent le typage statique aux outils de développement (y'a pas que le compilateur : IDE, refactoring & co) ?

je ne pense pas que le passage de l'etape de "compilation/check des types" soit une securité.
c'est une sécurité. Certainement pas suffisante, mais ca en est une.
Les tests unitaires en sont une autre, les 2 sont complémentaires et l'un ne remplace sûrement pas l'autre.

Pour LINQ, c'est encore subjectif, mais en pratique c'est quelque chose qui se reecrit en python pur en peu de temps grace au generateurs et autres.
Tu comprends pas. LINQ, c'est de combiner tous les avantages d'un langage de requêtage comme SQL avec les avantages d'un langage typé statiquement.
En C# si j'écris :
var artists = from album in database.GetAlbums()
where album.Name.StartWith("The")
orderby album.Name
select album.Artist;
foreach(var artist in artists)
Console.WriteLine(artist.toto); //erreur, la propriété toto n'existe pas !

le compilateur fait de l'inférence de type et ma variable ids est une suite d'objets du même type que Artist. Le typage est conservé et si je manipule cette liste, le compilateur peut me renvoyer une belle erreur à la compilation, et pas durant l'exécution d'un hypothétique test unitaire.
De plus ca permet à mon IDE de me proposer instantanément la liste des propriétés de mon objet artist quand je tapes "artist.".

T'auras beau reproduire l'API en Python, comme tu peux le faire en C# ou Java d'ailleur, tu n'auras pas l'intérêt principal qui est l'intégration dans le système de typage.

ce n'est pas explicite et c'est trop magique
Quand t'as la complétion, c'est explicite. LINQ est intégralement codé en méthode d'extensions et tout le monde est content de pouvoir utiliser LINQ sur ses listes d'objets traditionnelles.

par contre c'est faisable en ruby, en python
Là encore, les méthodes d'extensions permettent avant tout de conserver le typage statique, ce qui n'est pas le cas en Ruby ou en Python.

cela existe aussi en python
Non, le service peut être rendu à l'aide d'autres outils ou langages comme cython ou JNI, mais ce n'est pas proposé par Python.

Ce qui fait la force de C#, c'est son côté tout terrain, qui fait qu'il n'est sûrement pas le meilleur dans un domaine, mais cela en fait souvent un bon compromis.

[^] # Re: Drôle

Posté par Guillaum (site web personnel) le 07 juillet 2009 à 20:35. Évalué à 2.

Le pire dans ce débat c'est qu'il y a des gens avec des vrais arguments (enfin). Merci beaucoup.

Au final je comprend les 3/4 de tes arguments et je ne peux rien y dire, c'est plus un débat typage statique/dynamique et la il est clair que c'est affaire de préferences personelles. Je n'aime pas cela (le typage statique), mais je comprend tout à fait les arguments en sa faveur.

Au final, je ferais peut etre du c# le jour ou le typage statique me convaicra ;)

Simple question, pour les PInvoke, j'ai l'impression que c'est juste la capacité de charger une librairie dynamique à la volée et d'appeler les fonctions qui se trouvent dedans. Si c'est cela, c'est tout à fait faisable en python via la lib ctypes. Si ce n'est pas le cas et que j'ai mal compris, merci de m'eclairé un peu plus ;)

[^] # Re: Drôle

Posté par TImaniac (site web personnel) le 07 juillet 2009 à 21:03. Évalué à 2.

Les PInvoke permettent de définir statiquement la signature d'une fonction native. Ca suppose un minimum de support dans le langage natif : métadonnées (pour préciser l'alignement et autres subtilité des structures C), pointeurs. C'est aussi toute l'infrastructure qu'il y a derrière pour réaliser concrètement l'appel.
Bref encore une fois ca apporte le côté typage (déclaration statique) que Python n'offre pas.

[^] # Re: Drôle

Posté par Guillaum (site web personnel) le 07 juillet 2009 à 22:14. Évalué à 2.

Ok. Alors python permet exactement cela avec la lib ctypes

>>> import ctypes
>>> lib = ctypes.CDLL('libm.so')
>>> lib.pow.restype = ctypes.c_double
>>> lib.pow.argtypes = [ctypes.c_double,ctypes.c_double]
>>> lib.pow(5.2,2)
27.040000000000003

C'est un exemple simple, mais il est possible de spécifier des alignements, des structs et pleins de choses joyeuses.

Le binding python opengl a été intégralement réalisé avec cela. Par contre il est vrai que tout est au runtime et non pas lors de la "compilation", d'où des perfs pas forcement géniales.

[^] # Re: Drôle

Posté par TImaniac (site web personnel) le 08 juillet 2009 à 00:36. Évalué à 2.

perfs pas génial, et surtout si l'utilisateur se vautre dans son appel, ca peut faire exploser son application comme une loutre.
Bref, c'est pas du tout pareil :)
- [^] # Re: Drôle
  
  Posté par Alice (site web personnel) le 07 juillet 2009 à 16:43. Évalué à 8.
  
  De toute manière c'est du Microsoft, on ne peut pas soutenir une technique d'un vilain méchant qui n'aime pas le libre
  
  Ca ne me choque pas. On a le droit de pas aimer Microsoft, et de ne pas vouloir aider à renforcer le standard logiciel d'une entreprise à la politique commerciale pourrie en situation de monopole, alors qu'il existe des technologies aussi performantes par ailleurs.
  
  Les éditeurs propriétaires ont tout intérêt à ce que la communauté du libre adopte leurs produits et leurs outils soumis à des brevets et des trucs 'on sait pas sic'est légal', afin d'essayer de la contrôler par la suite, à la manière d'un cheval de troie.
  - [^] # Re: Drôle
    
    Posté par Camille_B le 07 juillet 2009 à 17:00. Évalué à 4.
    
    Je vous invites à ne plus utiliser XMLHttpRequest qui est initialement un objet ActiveX pour développer pour IE5.
    
    C'est vrai quoi, on ne sais jamais ce qui peut nous arriver avec des trucs sortis de chez Microsoft.
  - [^] # Re: Drôle
    
    Posté par patrick_g (site web personnel) le 07 juillet 2009 à 17:05. Évalué à 3.
    
    Et ajoutons que le développement de Python, de Java, etc est un développement qui n'est pas sous le contrôle d'une seule société.
    
    Dans le cas de C# on a une seule entité qui décide de tout et on a la communauté qui ne décide de rien et qui a juste le droit de réimplémenter les changements dans Mono si elle veut garder la compatibilité.
    
    Quand on ajoute que cette entité qui décide de tout est en plus l'acteur monopolistique du marché et donc potentiellement l'adversaire des "nouveaux entrants" tels Linux je pense que ça fait un bon argument pour ne pas utiliser cette techno.
    - [^] # Re: Drôle
      
      Posté par pasBill pasGates le 07 juillet 2009 à 17:11. Évalué à 1.
      
      C# est un standard ISO et ECMA, n'importe quelle societe peut joindre ECMA, avoir son mot a dire, voter, ... Tous les pays peuvent voter a l'ISO, demander des changements, ...
      
      OOXML a ete developpe par une seule societe, les societes a l'ECMA ont amene pas mal de changements, l'ISO a force un nombre de changements enormes a la spec, comme quoi c'est tout a fait faisable.
      
      [^] # Re: Drôle
      
      Posté par Alice (site web personnel) le 07 juillet 2009 à 17:29. Évalué à 2.
      
      En même temps on comprend pas pourquoi Microsoft a tout fait pour normaliser à tout prix ( http://www.zdnet.fr/actualites/informatique/0,39040745,39380(...) ) son format bureautique alors qu'il en existait déjà un reconnu en la matière d'OpenDocument.
      
      [^] # Re: Drôle
      
      Posté par pasBill pasGates le 07 juillet 2009 à 17:32. Évalué à 0.
      
      OpenDocument est surtout reconnu pour etre totalement incomplet et inutilisable comme format d'interop(pas de formules, definition de l'encryption batarde et incomplete, definition du change tracking incomplete, ...) et totalement controle par des societes opposes a MS qui ont refuse toutes les propositions de changement que ce dernier a faite depuis qu'il a rejoint le comite il y a plusieurs mois...
      
      [^] # Re: Drôle
      
      Posté par Alice (site web personnel) le 07 juillet 2009 à 18:13. Évalué à 2.
      
      Oh, le pauvre Microsoft victime du complot ;-(
      
      Et pourquoi Microsoft n'a pas participé dès le début à l'élaboration du format, alors qu'Adobe Systems, Corel, IBM, Google, Sun (évidemment) l'ont fait ? Et si les propositions de changement proposées par Microsoft n'étaient pas pertinentes, humm ?
      
      En tous cas, au final, grâce à Microsoft, on a deux formats concurrents pour faire la même chose, ce qui est dommage pour l'intéropérabilité. Sans compter, que l'OpenDocument Format Alliance a dénoncé de sérieuses carences dans le support d'ODF par Microsoft, ce qui nuit à l'intéropérabilité, encore une fois.
      
      [^] # Re: Drôle
      
      Posté par pasBill pasGates le 07 juillet 2009 à 18:32. Évalué à 1.
      
      Et pourquoi Microsoft n'a pas participé dès le début à l'élaboration du format, alors qu'Adobe Systems, Corel, IBM, Google, Sun (évidemment) l'ont fait ? Et si les propositions de changement proposées par Microsoft n'étaient pas pertinentes, humm ?
      
      Quelle belle liste... tous les gros concurrents de MS... c'etait surement une coincidence hein... Quand aux changements, on va vite oublier que MS a genre 2x plus d'experience dans le developpement de suites Office que tous les autres concurrents reunis...
      
      Sans compter, que l'OpenDocument Format Alliance a dénoncé de sérieuses carences dans le support d'ODF par Microsoft, ce qui nuit à l'intéropérabilité, encore une fois.
      
      Faut arreter de lire la propagande mon cher, quand tu creuses ce que l'ODF Alliance dit, tu vois vite qu'ils racontent n'importe quoi. Ce que MS a fait pour les formules est totalement conforme, le manque d'interop est du aux defficiences enormes d'ODF, idem pour le change tracking et l'encryption
      
      [^] # Re: Drôle
      
      Posté par Alice (site web personnel) le 07 juillet 2009 à 18:48. Évalué à 3.
      
      Quelle belle liste... tous les gros concurrents de MS... c'etait surement une coincidence hein...
      
      C'est simplement tous les ténors du marché, qui sont d'ailleurs des concurrents entre eux.
      
      Seul Microsoft n'a pas voulu participer, a proposé un format concurrent, et quand il s'est aperçu que l'ODF dominait, il s'est empressé de faire du FUD dessus et une implémentation foireuse dans son coin. Et par dessus le marché, Microsoft est une victime des autres qui veulent pas travailler avec lui. C'est un peu gros, non?
      
      [^] # Re: Drôle
      
      Posté par pasBill pasGates le 07 juillet 2009 à 19:07. Évalué à -1.
      
      C'est simplement tous les ténors du marché, qui sont d'ailleurs des concurrents entre eux.
      
      Ah oui ?
      
      Adobe ne fait pas de suite office, IBM et Sun font la meme suite office (un derive d'OOo), et il y a Corel. Tu les mets ensemble et tu arrives a quoi, 5-7% du marche ?
      
      Tous ces gens la ont un seul concurrent, c'est MS Office, tu sais, les 90-95% restants...
      
      Seul Microsoft n'a pas voulu participer, a proposé un format concurrent, et quand il s'est aperçu que l'ODF dominait, il s'est empressé de faire du FUD dessus et une implémentation foireuse dans son coin. Et par dessus le marché, Microsoft est une victime des autres qui veulent pas travailler avec lui. C'est un peu gros, non?
      
      a) ODF ne domine rien du tout, il y a probablement aujourd'hui bcp plus de documents .docx et .xlsx que de documents ODF, par le simple fait qu'en 2 ans Office 2007 a atteint jusqu'a 30% de parts de marche ce qui est largement plus que toutes les suites supportant ODF reunies.
      
      b) L'implementation de MS est tres loin d'etre foireuse, je te mets au defi de prouver le contraire, indice : tout ce que l'ODF Alliance a pondu comme anerie je peux te le demonter avec elements de la spec ODF a l'appui
      
      c) MS est tres loin d'etre le seul a dire que Sun et IBM controlent ODF, il y a des devs de GNUmeric notamment ainsi que certains membres fondateurs du comite ODF a OASIS qui se sont barres depuis
      
      [^] # Re: Drôle
      
      Posté par briaeros007 le 07 juillet 2009 à 19:13. Évalué à 2.
      
      a) ODF ne domine rien du tout, il y a probablement aujourd'hui bcp plus de documents .docx et .xlsx que de documents ODF, par le simple fait qu'en 2 ans Office 2007 a atteint jusqu'a 30% de parts de marche ce qui est largement plus que toutes les suites supportant ODF reunies.
      Euh les docx personnes les utilisent. Veux pas etre méchant mais c'est pas utilisé en entreprise (80-95% de l'utilisation d'office) a cause des problèmes avec les anciennes suites et la rétro compatibilité demandé.
      
      Et pour les particulier, les gens savent pas ces quoi et stockent encore en .doc pour pouvoir les envoyer par mail.
      
      Si il y a 10% des suites offices 2007 qui écrivent régulièrement des docx , c'est le bout du monde.
      
      [^] # Re: Drôle
      
      Posté par zebra3 le 07 juillet 2009 à 18:49. Évalué à 5.
      
      MS a genre 2x plus d'experience dans le developpement de suites Office que tous les autres concurrents reunis...
      
      Ça se mesure comment ? J'ai assez peu confiance en la parts de marché, surtout quand je vois que IE6 est plus utilisé que Chrome.
      
      Et s'il faut le mesurer en années, rappelons que le premier Lotus Symphony date de 1984, et le premier 1-2-3 de 1983, ce qui en fait des contemporains des premiers Word et Multiplan.
      Lotus (donc IBM) a autant d'expérience que MS dans ce domaine.
      
      Notons aussi que StarOffice 1.0 date également de 1984.
      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
      
      [^] # Re: Drôle
      
      Posté par pasBill pasGates le 07 juillet 2009 à 19:29. Évalué à 1.
      
      Ben le fait que MS a amene la grande majorite des innovations dans ce domaine ces 10 dernieres annees(ribbon, smart tags, correction automatique de certains mots, meme le change tracking il me semble, ... ) alors que les autres suites se contentaient d'essayer de suivre et de copier, ainsi que le fait qu'ils aient de tres tres loin la base d'utilisateurs la plus large, ce qui leur donne une idee des besoins et problemes de tout le marche, on peut pas en dire autant des autres suites.
      
      Lotus Symphony lui est mort avec le DOS, ils ont repris le nom pour ce derive d'OOo, mais entre les 2 il n'y a rien eu. Resultat, peu d'experience dans le domaine, Symphony c'est 95% OOo.
      
      StarOffice/OOo n'a pas fait grand-chose d'autre que suivre Office et le copier, il y a qqe petits trucs nouveau ici ou la, mais rien de franchement important. Leur vraie specificite c'etait d'etre une suite existant sur bcp de plateformes.
    - [^] # Re: Drôle
      
      Posté par Zenitram (site web personnel) le 07 juillet 2009 à 18:34. Évalué à 2.
      
      Et ajoutons que le développement de Python, de Java, etc est un développement qui n'est pas sous le contrôle d'une seule société.
      
      Bon, admettons pour Python, c'est une fondation qui s'en occupe, je ne sais pas quel est le degré de liberté laissé aux proposeurs (j'ai quand même du mal à croire qu'il n'y a pas un "gentil dictateur", vu le temps que les organismes W3C, C ou C++ mettent pour mettre tout le monde d'accord quand il y a une démocratie bien affichée...)
      
      Par contre pour Java je tique : à ma connaissance si tu n'es pas d'accord avec SUN, ce sera SUN qui aura le dernier mot. Java est sous le contrôle de SUN autant que C# est sous le contrôle de Microsoft.
      
      [^] # Re: Drôle
      
      Posté par TImaniac (site web personnel) le 07 juillet 2009 à 18:39. Évalué à 3.
      
      j'ai quand même du mal à croire qu'il n'y a pas un "gentil dictateur"
      Python a son gentil dictateur : http://en.wikipedia.org/wiki/Benevolent_Dictator_For_Life
      
      [^] # Re: Drôle
      
      Posté par Zenitram (site web personnel) le 07 juillet 2009 à 18:46. Évalué à 3.
      
      Python a son gentil dictateur : http://en.wikipedia.org/wiki/Benevolent_Dictator_For_Life
      
      Merci pour l'info.
      Donc pour paraphraser patrick_g, dans le cas de Python on a une seule personne (c'est mieux qu'une entité?) qui décide de tout et on a la communauté qui ne décide de rien et qui a juste le droit de proposer des choses sans être sûre que ce sera pris en compte (si le gentil dictateur fait la tête, quelques soit tes arguments et la popularité de ta demande, elle peut être rejetée sans avoir à fournir de raison.)
      
      Mouais, finalement Java ou Python, ce n'est pas beaucoup mieux que C# de ce côté... Pas un argument contre C#.
      
      [^] # Re: Drôle
      
      Posté par patrick_g (site web personnel) le 07 juillet 2009 à 19:28. Évalué à 2.
      
      >>> dans le cas de Python on a une seule personne (c'est mieux qu'une entité?) qui décide de tout
      
      Tu est sûr de toi là ? Y'a pas de votes dans le monde de Python ?
      Va voir ici : http://www.python.org/dev/process/
      
      Certes Guido a formellement le droit de décider mais en pratique il suit les votes de la communauté.
      
      [^] # Re: Drôle
      
      Posté par Zenitram (site web personnel) le 07 juillet 2009 à 19:53. Évalué à 2.
      
      Certes Guido a formellement le droit de décider mais en pratique il suit les votes de la communauté.
      
      La démocratie, le vote démocratique, est un vote qui ne peut être rejeté si le "gentil dictateur" peut décider que le vote ne va pas dans la bonne direction.
      
      Tant qu'un dictateur, aussi gentil soit-il aujourd'hui (ce qui ne garanti pas qu'il le sera demain), peut poser un veto sans qu'il y ai un recours possible [1], le vote reste qu'une proposition, pas une obligation, et le langage est alors contrôlé par une personne.
      Car c'est au moment ou on voudra aller à l'encontre du gentil dictateur qu'on s'apercevra qu'il n'est pas si gentil que ça.
      
      Donc OK, je met Java en dehors de tout ça, si j'ai bien compris SUN ne peut plus poser de Veto, mais pour Python, désolé tu ne m'a pas convaincu : Microsoft écoute les développeurs et fait évoluer le language en fonction de la demande, ça revient en pratique et en théorie exactement au même que pour Python, la mise en form "comité" pour faire joli en moins pour MS. Tant que Python sera une démocratie sous condition, ce ne sera pas une démocratie, ce sera un langage contrôlé par une personne.
      
      Ce qui, en théorie est encore plus dangereux que le cas Microsoft : On ne peut changer le dictateur de Python, mais on peut changer Microsoft (on peut acheter 50% + 1 actions de MS, ou convaincre les actionnaires qu'il faut changer de direction).
      Plus j'y réfléchis, et plus je vois Python comme plus directif que C# au niveau du "management"... (reste alors à forker, mais c'est aussi faisable pour C#....)
      
      Le "méchant" n'est pas forcement celui auquel on croit en premier.
      
      [1] ça me fait penser à la Belgique dont si je me souviens bien le parlement a mis le roi "dans l'incapacité de signer" pendant quelques jours pour faire passer une loi sur l'homosexualité qui demandait une signature du roi pour être valide mais que le roi ne souhaitait pas signer, bref il y a moyen de contourner ;-) Corrigez-moi si je me trompe.
      
      [^] # Re: Drôle
      
      Posté par allcolor (site web personnel) le 07 juillet 2009 à 20:49. Évalué à 2.
      
      [1] ça me fait penser à la Belgique dont si je me souviens bien le parlement a mis le roi "dans l'incapacité de signer" pendant quelques jours pour faire passer une loi sur l'homosexualité
      
      Sur l'avortement... http://fr.wikipedia.org/wiki/Baudouin_de_Belgique#Roi_cathol(...)
      
      [^] # Re: Drôle
      
      Posté par nicoastro le 07 juillet 2009 à 22:24. Évalué à 3.
      
      Le truc c’est qu’avec le libre il y a un recours possible : le fork. Ça change tout. C’est d’ailleurs le sens du l’expression du « dictateur bienveillant », il a une épée de Damoclès en permanence sur lui qui le force à lâcher du lest, contrairement code propriétaire.
      
      Enfin là je ne fais qu’enfoncer des portes ouvertes…
      
      [^] # Re: Drôle
      
      Posté par Thomas Douillard le 07 juillet 2009 à 22:39. Évalué à 1.
      
      C'est pas du tout le sens de dictateur bienveillant. Le dictateur bienveillant c'est celui qui prend des décisions pour le peuple, bref, utiliser son pouvoir à bon escient.
      
      Par opposition au dictateur qui est là pour opprimer son peuple et faire taire les opposants, abuser de son pouvoir.
      
      [^] # Re: Drôle
      
      Posté par Zenitram (site web personnel) le 07 juillet 2009 à 23:44. Évalué à 2.
      
      e dictateur bienveillant c'est celui qui prend des décisions pour le peuple, bref, utiliser son pouvoir à bon escient.
      
      Si le peuple n'arrive pas à se décider tout seul, et que le dictateur bienveillant décide, ne crois-tu pas qu'il y aura au minimum 50% des gens qui se sentiront trahis?
      
      Par opposition au dictateur qui est là pour opprimer son peuple et faire taire les opposants, abuser de son pouvoir.
      
      Pour les 50% mini des gens contre une décision du dictateur bienveillant, ce sera exactement ce qu'il pensent du dictateur bienveillant.
      
      Un dictateur bienveillant fait moins de dégât qu'un dictateur pays dirigeant d'un pays juste parce que :
      - Il ne dirige pas d'armée
      - pour l'open-source, il est à la merci d'un Fork.
      - les gens peuvent quitter le "pays" sans problème
      
      Sinon, l'idée du dictateur bienveillant est exactement la même qu'un dictateur normal... Il décide à la place des autres ce qui l'arrange lui (ce qui lui plait), en faisant taire les opposants ("on est parti sur xxx, la solution concurrente n'a plus à être discutée").
      
      Dans le logiciel, il en faut, sinon on a du mal à avancer rapidement, mais ça n'enlève pas le fait que c'est une dictature... L'avenir de Python peut être décidé par un seul homme qui n'a pas de contre-pouvoir (exemple : une "loi" qui dit que si x% de la communauté vote contre une solution proposée par le gentil dictateur, le gentil dictateur ne peut pas imposer) gravé dans le marbre (l'intérêt étant de connaitre les limites démocratiques avant de les atteindre...)
      
      [^] # Re: Drôle
      
      Posté par Thomas Douillard le 08 juillet 2009 à 01:18. Évalué à 2.
      
      T'emballes pas, c'est un concept, et il n'a rien de spécifique au logiciel libre. cf. en:Benevolent_dictatorship
      
      Le dictateur bienveillant sait prendre les bonnes décisions pour le peuple, y compris malgré lui.
      
      [^] # Re: Drôle
      
      Posté par Zenitram (site web personnel) le 07 juillet 2009 à 23:58. Évalué à 2.
      
      Le dictateur bienveillant c'est celui qui prend des décisions pour le peuple, bref, utiliser son pouvoir à bon escient.
      
      Je vais te donner un exemple de subjectivité : pour beaucoup de monde, MS est un gentil dictateur car il a fait sortir l'informatique de sa niche de geek en faisant un OS adapté au grand public.
      Il a en plus fait C#, qui est génial pour faciliter le développement, il répond au besoin des développeur, il écoute les développeurs, et en plus il met le framework en installation forcée (très aidée) lors des Windows Update. Pour les développeurs, que du bonheur.
      
      Toi, tu n'es pas d'accord, et tu trouves C# dangereux, qu'il ne faut pas l'utiliser pour raison x ou y.
      Mais... Je n'ai fait que remplacer Python par C# et le gentil dictateur par MS, pas plus, juste que tu n'es pas du bon côté, que tu n'aime pas ce que fais le "gentil dictateur"... Mais c'est la seule différence : ton gout.
      
      --> Un "gentil dictateur" reste un dictateur, qui ne sera pas gentil pour certaines personnes. Des fois tu as de la chance ça va dans ton sens, des fois non.
      
      [^] # Re: Drôle
      
      Posté par nicoastro le 08 juillet 2009 à 00:49. Évalué à 2.
      
      Bon, je vais me répéter un peu.
      
      Pour Python le fork garantit aux personnes qui ne trouvent pas les choix du « dictateur » à leur goût de pouvoir librement reprendre le projet là où il en est, et de le poursuivre, ensuite les utilisateurs et les compétences qui iront vers l’un ou l’autre départageront les choix faits.
      
      Pour Windows, c’est le client qui décide, pondéré par le poids de son porte-monnaie. Si les intérêts de certains ne s’accordent pas, il n’ont aucun moyen de changer le cours des choses. MS, on aime ou on se casse ! Si chez Python on fait de la merde, les programmeurs forkeront (les exemples ne manquent pas dans le libre). Si chez Microsoft on fait de la merde… on sait tous ce qui se passe. ;)
      
      Pour finir, rien à voir avec le libre mais plutôt en réponse au commentaire plus haut. J’estime que parler de « dictateur bienveillant » est une vaste fumisterie, un pouvoir sans contre-pouvoir est a fortiori dangereux et donc à bannir. Ce que j’essaie d’expliquer dans le cas particulier du libre n’est que ce point de vue appliqué au sujet.
      
      Après tout ça si vous ne voyez toujours pas la différence je ne peux plus rien faire.
      
      [^] # Re: Drôle
      
      Posté par Zenitram (site web personnel) le 08 juillet 2009 à 02:02. Évalué à 2.
      
      Pour Python (...) Pour Windows
      
      Comment dévier la conversation sur le "monopole" de Microsoft...
      On parlait langage, donc Python vs C#.
      On est autant libre de quitter C# que Python, ex-aequo.
      Bon, pour forker, c'est peut-être plus dur à cause de la propriété intellectuelle certes, mais bon j'ai d'un côté une personne+fork possible, de l'autre une entreprise (plusieurs personnes qui décident) + fork moins facilement possible, bof bof... Non, désolé, je ne vois pas trop la différence.
      
      un pouvoir sans contre-pouvoir est a fortiori dangereux et donc à bannir.
      
      Sur ça, on est d'accord :).
      Oui, le libre apporte un contre-pouvoir plus costaud (fork plus facile), mais il amène aussi son lot de "leaders" un peu chiants et obtus (cas de XFree...), ce n'est pas toujours bon.
      Et dans le cas spécifique de Python vs C#, ça reste quand même une différence très petite entre chaque mode de gouvernance...
      
      [^] # Re: Drôle
      
      Posté par patrick_g (site web personnel) le 08 juillet 2009 à 09:56. Évalué à 2.
      
      >>> Oui, le libre apporte un contre-pouvoir plus costaud (fork plus facile), mais il amène aussi son lot de "leaders" un peu chiants et obtus (cas de XFree...)
      
      Super exemple. Tu a XFree sur ta machine ? Non tu a Xorg justement parce que le libre permet ce fork si le décideur en place se révèle être un gros con borné. On le laisse sur place et on continue dans une autre direction avec le code.
      Ce n'est pas possible avec C# car l'objet même de Mono c'est de faire une implémentation compatible avec .NET donc il seront toujours à la traine et à la remorque des décisions de Microsoft.
      
      [^] # Re: Drôle
      
      Posté par Zenitram (site web personnel) le 08 juillet 2009 à 10:26. Évalué à 2.
      
      il seront toujours à la traine et à la remorque des décisions de Microsoft.
      
      le "comité de décision" de Mono est Microsoft, qui comme je te l'ai montré est plus démocratique que le "comité de décision" de Python.
      Donc il est plus facile de modifier C# que Python quand notre proposition va à l'encontre d'un choix, je te l'ai déjà démontré.
      
      Tu veux absolument voir en Microsoft le mal, et en conclu que comme Mono est un vassal de MS tu n'as pas de pouvoir.
      Tu détournes l'argumentation en supposant que MS est pire que Python dans le processus de décision, et part sur cette supposition pour faire tes conclusion.
      Comme la base de ton raisonnement est faux, la conclusion est fausse...
      
      Arrête de voir Microsoft comme le mal par défaut, et regarde le processus de décision quand tu veux changer changer quelque chose au langage contraire à ce qui se fait :
      - Python : seul moyen est de forker (blocage possible par le dictateur bienveillant), ce qui est très lourd (un fork n'est pas simple! Et il faut tout gérer)
      - C#/Mono : acheter des parts de MS, ou convaincre les détenteurs de parts (pas gratuit certes, mais les détenteurs de parts sont nombreux et aiment l'argent donc avoir des utilisateurs donc c'est plus facile)
      Désolé, mais bon, c'est un peu kif-kif comme difficulté.
      
      Alors, si tu contre-argumentais sur le principe de la dictature de Python, ça serait plus dans la discussion, je constate que tu évite soigneusement ce passage... Et je t'ai déja démontré que beaucoup de monde voit en Microsoft un dictateur bienveillant comme tu aime chez Python, question de point de vue donc...
      
      Tu n'aimes pas Microsoft, donc tu le considères comme dictateur non bienveillant.
      Tu aimes le dictateur de Python, donc tu le considères comme dictateur bienveillant.
      Mais au final, ça reste des dictateurs, la seule différence entre les deux étant ton point de vue sur leurs actions.
      Le dictateur de Python n'est pas mieux que Microsoft quand on compare Python vs C#.
      
      Ou prouve moi le contraire, mais pas en disant "ça vient de Microsoft donc c'est nul", ce n'est pas un argument. Pas non plus "ça va dans mon sens donc c'est bien", ce n'est pas un argument non plus (tous les dictateurs ont une base de fans solide pour pouvoir rester en place...)
      
      [^] # Re: Drôle
      
      Posté par pititjo le 08 juillet 2009 à 11:48. Évalué à 2.
      
      Je suis globalement d'accord avec le fait qu'un dictateur reste un dictateur qui qu'il soit et que tu soit d'accord avec ou non.
      
      Par contre, tu m'a bien fait rire avec le « si t'es pas d'accord avec microsoft tu peux racheter microsoft ».
      
      Après, j'espère que ce ne sont pas les actionnaire qui dicte les choix techniques parce que bon, parmi eux il y en a quand même pas mal qui ne savent même pas ce qu'est un ordinateur...
      
      [^] # Re: Drôle
      
      Posté par patrick_g (site web personnel) le 08 juillet 2009 à 12:36. Évalué à 3.
      
      >>> Tu veux absolument voir en Microsoft le mal
      
      Je vois juste en Microsoft l'acteur monopolistique du marché de l'informatique donc l'acteur ayant le plus à perdre à l'irruption d'un concurrent.
      Ma position n'est donc pas (que) philosophique.
      C'est une position qui est parfaitement rationnelle sur le plan économique : Le principal adversaire de Linux c'est Microsoft parce que c'est Microsoft qui a 90% du marché et c'est donc Microsoft qui va lutter pour garder son monopole.
      
      [^] # Re: Drôle
      
      Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 12:41. Évalué à 2.
      
      Sauf que python doit satisfaire ses utilisateurs pour survivre, alors que MS doit satisfaire ses actionnaires...
      
      En informatique, on sait très bien que leur intérêt sont opposés (lock in, cout de migration, migration forcé, Embrace, extend and extinguish, non interopérabilité, etc...).
      
      Évidement les techniques suscitées fonctionnent beaucoup mieux en situation de monopole.
      "La première sécurité est la liberté"
      
      [^] # Re: Drôle
      
      Posté par Buf (Mastodon) le 07 juillet 2009 à 18:51. Évalué à 1.
      
      L'évolution de Java passe par le Java_Community_Process, dont Sun est membre, mais ils ne sont pas seuls. Il y a aussi des représentation du logiciel libre là-dedans (fondation Apache en particulier)
      
      [^] # Re: Drôle
      
      Posté par Littleboy le 07 juillet 2009 à 19:32. Évalué à 4.
      
      Et vu tous les problemes avec Java 7, ca fait quand meme doucement rigoler. Sun a l'IP sur tout une partie de Java et s'en sert pour decider tout seul, le JCP ils s'assoient dessus quand ca les arrange.
      
      [^] # Re: Drôle
      
      Posté par patrick_g (site web personnel) le 07 juillet 2009 à 19:11. Évalué à 0.
      
      >>> Par contre pour Java je tique : à ma connaissance si tu n'es pas d'accord avec SUN, ce sera SUN qui aura le dernier mot. Java est sous le contrôle de SUN
      
      Je ne crois pas.
      C'est le Java Community Process qui décide et pas Sun.
      
      http://jcp.org/en/introduction/overview
- [^] # Re: Drôle
  
  Posté par alice le 07 juillet 2009 à 19:42. Évalué à 2.
  
  C'est rigolo, après des années à expliquer que Mono n'était pas forcément plus en danger qu'un autre logiciel, les mono-fanboys vont devoir nous expliquer pourquoi il faut une promesse pour ne plus craindre un danger qui n'existait pas de toute façon.
  - [^] # Re: Drôle
    
    Posté par Jb Evain (site web personnel) le 07 juillet 2009 à 20:15. Évalué à 1.
    
    Je n'ai jamais dis qu'il n'y avait aucun danger. Et je salue bien bas cette initiative qui au final protège Mono.
    
    Par contre, considérant le danger ambient due à la situation des brevets logiciels, je maintiens que je ne vois pas en quoi Mono posait plus de problèmes de d'autres logiciels de cette envergure.
  - [^] # Re: Drôle
    
    Posté par fcartegnie le 08 juillet 2009 à 00:54. Évalué à 0.
    
    http://www.theinquirer.net/inquirer/opinion/1432968/microsof(...)
    Difficile de faire une analyse plus concise:
    Everything about Microsoft - its founding philosophy, its history right up to the present day, and its behaviour with respect to C#, .NET and Mono - show that it can't be trusted. Microsoft's single-minded objective with respect to free software is to co-opt, constrain and enslave it, and to kill whatever parts of the free software community it cannot conquer.
    - [^] # Re: Drôle
      
      Posté par pasBill pasGates le 08 juillet 2009 à 03:09. Évalué à 2.
      
      Difficile de faire un torchon pire que cela oui, allez au hasard :
      
      We believe this means, in effect, that free software developers will have to write applications that will run on Microsoft operating systems, if they use any of the Vole's patented software development technologies.
      
      C'est d'une stupidite qui depasse l'entendement, il y a des gens qui visiblement ont besoin d'une greffe de neurones des qu'il s'agit de MS.
      - [^] # Re: Drôle
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 12:42. Évalué à 9.
        
        C'est sûr que le comportement de MS avec tomtom encourage à leur faire confiance.
        "La première sécurité est la liberté"
        
        [^] # Re: Drôle
        
        Posté par pasBill pasGates le 08 juillet 2009 à 16:40. Évalué à 2.
        
        Ils avaient fait une promesse vis a vis des brevets qu'ils disaient presents dans le noyau ? Non, ils avaient dit depuis le debut que c'etait un probleme.
        
        Bref, au contraire, visiblement ils tiennent parole.
        
        [^] # Re: Drôle
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 17:15. Évalué à 2.
        
        Ils tiennent parole pour attaquer Linux. Pourquoi donc leur faire confiance ensuite ?
        "La première sécurité est la liberté"
        
        [^] # Re: Drôle
        
        Posté par pasBill pasGates le 08 juillet 2009 à 17:33. Évalué à 1.
        
        Ils font ce qu'ils disent. Ils promettent qu'ils ne vont pas attaquer Mono sur les brevets portant sur C# et CLI, il y a toutes les raisons de les croire (surtout vu que c'est legalement valide).
        
        [^] # Re: Drôle
        
        Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 17:37. Évalué à 2.
        
        En gros, il sous-entende qu'il pourrait attaquer avec les autres brevets de l'api, la belle affaire.
        "La première sécurité est la liberté"
        
        [^] # Re: Drôle
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 17:40. Évalué à 2.
        
        Tu parles de quels brevets ? Les brevets sur les API web-services détenus par Novell ? Le libre a les moyens de se défendre.
        
        [^] # Re: Drôle
        
        Posté par alice le 08 juillet 2009 à 20:07. Évalué à 1.
        
        Et le libre a les moyens de se défendre contre Novell?
# Promesses ? C'est nouveau dans l'industrie ?

Posté par fcartegnie le 07 juillet 2009 à 16:56. Évalué à 3.

Ils font la promesse irrévocable de ne pas faire de procès pour violation de brevets aux diverses implémentations de ces standards.

"Irrévocable"? Le document est enregistré légalement où ? A part sur le site *modifiable* du proprio, je vois pas. Microsoft a plus d'argent pour payer ses avocats et signer des accords avec une réelle valeur légale entre parties ?

pour violation de brevets aux diverses implémentations de ces standards

Formidable, ceux qui fourniront les outils ne seront pas poursuivis. Seuls ceux qui vendront des produits les utilisant.
- [^] # Re: Promesses ? C'est nouveau dans l'industrie ?
  
  Posté par pasBill pasGates le 07 juillet 2009 à 17:07. Évalué à 3.
  
  Il n'y a pas besoin de l'enregistrer legalement ou que ce soit, il y a largement assez de references et de copies pour le prouver.
  
  pour violation de brevets aux diverses implémentations de ces standards
  
  Formidable, ceux qui fourniront les outils ne seront pas poursuivis. Seuls ceux qui vendront des produits les utilisant.
  
  Pas de bol, c'est couvert aussi par l'OSP, frustrant non ? Va falloir trouver autre chose pour se plaindre de MS.
  - [^] # Re: Promesses ? C'est nouveau dans l'industrie ?
    
    Posté par tiot (site web personnel) le 07 juillet 2009 à 17:34. Évalué à 4.
    
    Il n'y a pas besoin de l'enregistrer legalement ou que ce soit, il y a largement assez de references et de copies pour le prouver.
    
    Mon professeur de droit nous disait : « le droit commercial n'est pas fait pour protéger les idiots ». Alors tu peux croire ce que te dis microsof, mais tant qu'il n'y a pas un écrit légal ça ne vaut rien du tout.
    - [^] # Re: Promesses ? C'est nouveau dans l'industrie ?
      
      Posté par pasBill pasGates le 07 juillet 2009 à 17:41. Évalué à 1.
      
      C'est quoi un ecrit legal ? Tu veux un joli petit papier avec plein de tampons partout ?
      
      Je te suggeres de regarder le droit US, ca t'expliqueras en quoi les terms & conditions, licences d'utilisation de site, ... qui sont sur le web directement sont valables. Un simple contrat oral est valide hein dans ce pays.
      - [^] # Re: Promesses ? C'est nouveau dans l'industrie ?
        
        Posté par Nicolas Évrard (site web personnel) le 07 juillet 2009 à 18:15. Évalué à 1.
        
        Un simple contrat oral est valide hein dans ce pays
        
        En Belgique (et probablement en France) aussi.
        
        Par contre pour faire valoir tes droits devant un tribunal si d'aventure tout ne se passe pas selon les termes du contrat, tu as intérêt à sortir des trucs écrits et ce que soit ici ou aux USA.
        
        [^] # Re: Promesses ? C'est nouveau dans l'industrie ?
        
        Posté par Buf (Mastodon) le 07 juillet 2009 à 18:20. Évalué à 2.
        
        Pas forcément.
        
        Le but, c'est d'arriver à prouver l'existence du contrat et son contenu. Avec un document publié sur Internet, ça me semble relativement facile à faire, grâce aux caches des moteurs de recherche.
        
        [^] # Re: Promesses ? C'est nouveau dans l'industrie ?
        
        Posté par fcartegnie le 07 juillet 2009 à 19:48. Évalué à 2.
        
        Avec un document publié sur Internet, ça me semble relativement facile à faire, grâce aux caches des moteurs de recherche.
        Tu crois vraiment que les huissiers spécialisés/constats de l'app c'est pour faire joli ? ~~> legalis.net
        
        [^] # Re: Promesses ? C'est nouveau dans l'industrie ?
        
        Posté par pasBill pasGates le 07 juillet 2009 à 19:55. Évalué à 0.
        
        Le truc etant que cela n'a rien a voir avec l'app vu qu'il s'agit de brevets logiciels.
      - [^] # Re: Promesses ? C'est nouveau dans l'industrie ?
        
        Posté par Earered le 08 juillet 2009 à 02:24. Évalué à 0.
        
        Euh... Il y a un seul exemple ou ces 'terms & conditions" ou licences d'utilisations de sites ont été affirmés à la faveur de leur émetteur sur quelque chose qui allait au delà du droit commun ?
# Un autre bonne raison de ne pas utiliser Mono

Posté par Benoit le 08 juillet 2009 à 11:54. Évalué à 2.

Moi, j’ai une autre bonne raison de ne pas utiliser Mono : la CLI et le Framework .Net sont mal pensés (le language C# est lui vraiment pas mal).

Programmer en .Net n’est pas des plus simple pour plusieurs raisons, la principale étant l’utilisation du garbage collector. Son fonctionnement a été tellement mal pensé que l’on passe son temps à faire le travail du garbage collector à sa place (interface IDisposable) ou bien de l’empêcher de faire son travail de façon abusive (interface ISponsor en remoting .Net).

Concernant l’interface IDisposable ( http://msdn.microsoft.com/fr-fr/library/fs2xkftw.aspx ), MS n’a pas voulu appeler le destructeur des objets lorsque leur compte de référence tombe à 0 et le fait dans le garbage collector (qui ne devrait être là que pour éviter la fragmentation de la mémoire).
Résultat, il est nécessaire d’appeler manuellement le destructeur des objets (c.à.d. la méthode Dispose de l’interface IDisposable), le “vrai” destructeur des objets ne sert à rien et l’on perd tout l’intérêt de la libération automatique des objets, car :
1) il est impossible de libérer certaines ressources dans le destructeur (il est exécuter dans le contexte du garbage collector, ce qui empêche par exemple la libération les domaines d’application),
2) le garbage collector se déclenche tellement rarement que l’on peut provoquer des pénuries de ressources non managées.
3) ...

Je trouve le développement en .Net extrêmement technique comparé au développement Java, Perl ou Python et préfère encore développer en C ou C++ avec de bonnes bibliothèques comme la glib ou Qt.
- [^] # Re: Un autre bonne raison de ne pas utiliser Mono
  
  Posté par TImaniac (site web personnel) le 08 juillet 2009 à 12:23. Évalué à 1.
  
  Résultat, il est nécessaire d’appeler manuellement le destructeur des objets
  Non. Tu as besoin de le faire uniquement quand tu veux libéré instantanément la ressource. Dans les 3/4 des cas tu n'as pas besoin de le faire, sans parler du fait que la grande majorité des objets .NET n''implémentent pas IDisposable parcqu'ils n'ont pas besoin de le faire.
  
  MS n’a pas voulu appeler le destructeur des objets lorsque leur compte de référence tombe à 0 et le fait dans le garbage collector
  En même temps c'est le garbage collector qui compte les références donc bon...
  
  MS a fait le choix de faire s'exécuter le garbage collector à des moments propices (moment où la machine est moins sollicité ou à des moments critiques : besoin d'espace mémoire), c'est un choix différent de qui se fait dans d'autres VM par exemple mais c'est je trouve relativement pertinent puisque celà limite l'impact sur les performances de l'application.
  
  il est exécuter dans le contexte du garbage collector, ce qui empêche par exemple la libération les domaines d’application
  Non,c'est un autre problème le CLR n'autorise pas de libérer de domaines d'application tout court, un manque fonctionnel. D'ailleur .NET 4 évolue et propose cette fonctionnalité.
  
  Enfin l'interface IDisposable est là pour libérer des ressources qui ne sont pas gérées par le garbage collector mais des ressources natives ou des fichiers par exemple : bref c'est loin d'être le cas général pour les objets .NET.
  
  Et franchement c'est loin d'être "technique" et compliqué de faire un :
  using(var file = File.OpenText("/home/machin/truc.txt"))
  {
  utilisation
  } // appel automatique de IDisposable
  
  Tu verras aussi qu'en C++/CLI le problème n'est pas présent, et pourtant c'est le même CLR "mal conçu" :
  http://msdn.microsoft.com/fr-fr/library/ms177197.aspx
  
  Je trouve le développement en .Net extrêmement technique comparé au développement Java
  Alors que le problème est identique en Java... Explique moi le plus simple, le moins technique :
  
  C++/CLI :
  String^ ReadFirstLineFromFile( String^ path ) {
  StreamReader r(path);
  return r.ReadLine();
  }
  
  C# :
  String ReadFirstLineFromFile( String path ) {
  using ( StreamReader r = new StreamReader(path) ) {
  return r.ReadLine();
  }
  }
  
  Java :
  String ReadFirstLineFromFile( String path ) {
  StreamReader r = null;
  String s = null;
  try {
  r = new StreamReader(path);
  s = r.ReadLine();
  } finally {
  if ( r != null ) r.Dispose();
  }
  return s;
  }
  
  En Python, il me semble qu'il n'y a aucune garantie que le destructeur soit appelé quand l'interpréteur s'arrête, tu trouves ca mieux ?
  
  En C++ tu trouves ca simple et pas technique ces méthodes virtuelles appelées dans un destructeur si on fait pas attention ?
  - [^] # Re: Un autre bonne raison de ne pas utiliser Mono
    
    Posté par yellowiscool le 08 juillet 2009 à 12:54. Évalué à 2.
    
    Pourquoi il n'y a que dans ton exemple en java que tu en capsule tout ça dans un traitement des exceptions ?
    Envoyé depuis mon lapin.
    - [^] # Re: Un autre bonne raison de ne pas utiliser Mono
      
      Posté par Nicolas Boulay (site web personnel) le 08 juillet 2009 à 12:57. Évalué à 1.
      
      Pourquoi tu poses cette question ? C'est pour faire plus gros, plus sale , moins propre, plus effrayant et incompréhensible que les versions proposées avant ?
      
      Je ne vois pas d'autres explications.
      "La première sécurité est la liberté"
      - [^] # Re: Un autre bonne raison de ne pas utiliser Mono
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 13:06. Évalué à 2.
        
        Plutôt que de chercher une explication, propose une autre syntaxe, j'ai beau cherché en java, je vois pas.
        
        [^] # Re: Un autre bonne raison de ne pas utiliser Mono
        
        Posté par Buf (Mastodon) le 08 juillet 2009 à 13:10. Évalué à 3.
        
        Tu peux gagner 2 lignes en écrivant directement "return r.ReadLine()", sans passer par une variable intermédiaire, mais effectivement, le try {} finally {} est inévitable.
        
        [^] # Re: Un autre bonne raison de ne pas utiliser Mono
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 13:15. Évalué à 2.
        
        T'en gagnes une seule, t'es bien obligé de laisser un return à la fin en cas d'exception. Ca change pas fondamentalement la lourdeur de la syntaxe exigée par Java. Sans parler du fait qu'elle est souvent oubliée et/ou mal écrite.
        Imagine si tu dois utiliser 2 ressources, l'imbrication de try catch qu'il faut faire sans se louper...
        
        [^] # Re: Un autre bonne raison de ne pas utiliser Mono
        
        Posté par Buf (Mastodon) le 08 juillet 2009 à 13:20. Évalué à 2.
        
        Non, t'es pas obligé de laisser un return à la fin. En cas d'exception, le flux normal est interrompu, et il n'y a plus besoin de return vu qu'aucune valeur ne pourra être retournée.
        
        Sinon, complètement d'accord avec toi sur la lourdeur de la syntaxe en Java, ce genre de code est vraiment pénible à écrire, et c'est très facile de faire une erreur et de se retrouver avec des ressources qui ne sont pas correctement libérées. C'est lourd et casse-gueule, alors qu'effectivement, la syntaxe de C# est assez sympathique.
        
        [^] # Re: Un autre bonne raison de ne pas utiliser Mono
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 13:31. Évalué à 2.
        
        Ah oué exact, y'a pas de catch donc l'exception est forcement propagée.
    - [^] # Re: Un autre bonne raison de ne pas utiliser Mono
      
      Posté par Buf (Mastodon) le 08 juillet 2009 à 13:03. Évalué à 2.
      
      Simplement parce que c'est nécessaire si on veut garder la même sémantique, c'est-à-dire une méthode Dispose() appelée dans tous les cas, même en cas d'exception.
      
      Sans le try {..} finally {...}, si une exception se produit avant l'appel à Dispose(), la méthode ne sera pas appelée, le block finally donne la garantie qu'il sera exécuté dans tous les cas.
    - [^] # Re: Un autre bonne raison de ne pas utiliser Mono
      
      Posté par TImaniac (site web personnel) le 08 juillet 2009 à 13:10. Évalué à 2.
      
      Parcque le compilateur C# génère a peu prêt la même chose que ce que tu écris en Java (try catch dispose finally), mais le programmeur le voit pas.
  - [^] # Re: Un autre bonne raison de ne pas utiliser Mono
    
    Posté par Octabrain le 08 juillet 2009 à 13:34. Évalué à 1.
    
    Dans tes codes C++ et C#, que se passe-t-il en cas d'erreur ?
    - [^] # Re: Un autre bonne raison de ne pas utiliser Mono
      
      Posté par Buf (Mastodon) le 08 juillet 2009 à 13:38. Évalué à 2.
      
      Même chose qu'en Java : une exception est levée, mais la méthode Dispose() est appelée avant.
  - [^] # Re: Un autre bonne raison de ne pas utiliser Mono
    
    Posté par Benoit le 08 juillet 2009 à 14:03. Évalué à 1.
    
    Résultat, il est nécessaire d’appeler manuellement le destructeur des objets Non. Tu as besoin de le faire uniquement quand tu veux libéré instantanément la ressource. Dans les 3/4 des cas tu n'as pas besoin de le faire, sans parler du fait que la grande majorité des objets .NET n''implémentent pas IDisposable parcqu'ils n'ont pas besoin de le faire.
    Enfin l'interface IDisposable est là pour libérer des ressources qui ne sont pas gérées par le garbage collector mais des ressources natives ou des fichiers par exemple : bref c'est loin d'être le cas général pour les objets .NET.
    L'interface IDisposable est utilisée par de très (trop) nombreuses classes (IHM, parseur XML, ...)
    
    MS n’a pas voulu appeler le destructeur des objets lorsque leur compte de référence tombe à 0 et le fait dans le garbage collector En même temps c'est le garbage collector qui compte les références donc bon...
    On voit bien la limite de ce choix avec la gestion ubuesque du Dispose, un garbage collector pourrait se limiter à empêcher la fragmentation de la mémoire.
    
    Et franchement c'est loin d'être "technique" et compliqué de faire un :
    Sur un exemple simple non, mais lorsque tu as de multiples références sur ta classe, tu fini par ajouter des AddRef et des Release sur tes classes pour gérer ton propre compteur de référence, sa tombé à 0 appelant la méthode Dispose (pour éviter un pénurie de ressource non-managées).
    
    En C++ tu trouves ca simple et pas technique ces méthodes virtuelles appelées dans un destructeur si on fait pas attention ?
    Si, mais là tu as les mêmes règles pour tout les objets (alors quand .Net : Dispose ou pas, destructeur appelé n’importe quand, …) et donc des réflexes systématiques évitant toute erreur.
    
    il est exécuter dans le contexte du garbage collector, ce qui empêche par exemple la libération les domaines d’application Non,c'est un autre problème le CLR n'autorise pas de libérer de domaines d'application tout court, un manque fonctionnel. D'ailleur .NET 4 évolue et propose cette fonctionnalité.
    Ah, AppDomain::Unload :
    http://msdn.microsoft.com/fr-fr/library/system.appdomain.unl(...)
    avec la super phrase :
    Dans certains cas, l'appel à Unload provoque une exception CannotUnloadAppDomainException immédiate, par exemple si l'appel est effectué dans un finaliseur.
    
    Tu verras aussi qu'en C++/CLI le problème n'est pas présent, et pourtant c'est le même CLR "mal conçu" : http://msdn.microsoft.com/fr-fr/library/ms177197.aspx
    Tu as lu la page, c'est complètement ubuesque, on rajoute une couche de complexité. J'aime bien le passage:
    If your type has a destructor, the compiler will generate a Dispose method that implements IDisposable. If a type authored in Visual C++ with a destructor is consumed from another language, calling IDisposable::Dispose on that type will cause the type's destructor to be called. When consumed from a Visual C++ client, you cannot directly call Dispose; call the destructor instead using the delete operator.
    If your type has a finalizer, the compiler will generate a Finalize(void) method that overrides Finalize.
    - [^] # Re: Un autre bonne raison de ne pas utiliser Mono
      
      Posté par TImaniac (site web personnel) le 08 juillet 2009 à 18:12. Évalué à 2.
      
      'interface IDisposable est utilisée par de très (trop) nombreuses classes
      Mais t'as généralement pas besoin de les appeler.
      A part dans des situations où tu fais de très nombreuses allocation d'objet auquel cas tu veux rendre très rapidement la mémoire, je vois pas l'intérêt. Tu fais pas de foreach(var i = 0;i++;i<1000000) new Form() si ?
      
      Sur 50 classes que je développe, je dois implémenter IDisposable 1 fois.
      
      Sur un exemple simple non, mais lorsque tu as de multiples références sur ta classe, tu fini par ajouter des AddRef et des Release sur tes classes pour gérer ton propre compteur de référence, sa tombé à 0 appelant la méthode Dispose (pour éviter un pénurie de ressource non-managées).
      Je connais personne qui ai eu besoin de faire ça, mais admettons que tu es ce besoin. Expliques moi en quoi c'est différent en Java ou en Python, en quoi c'est moins technique vis-à-vis de ce problème.
      
      Ah, AppDomain::Unload :
      On est d'accord, dans .NET 2.0, le système t'offre aucune garantie. Donc en gros tu n'utilises jamais.
      
      Tu as lu la page, c'est complètement ubuesque, on rajoute une couche de complexité.
      On s'en fou c'est caché. Pour le développeur c'est toujours moins complexe que de gérer la mémoire à la main.
      - [^] # Re: Un autre bonne raison de ne pas utiliser Mono
        
        Posté par Benoit le 08 juillet 2009 à 18:53. Évalué à 1.
        
        'interface IDisposable est utilisée par de très (trop) nombreuses classes Mais t'as généralement pas besoin de les appeler. A part dans des situations où tu fais de très nombreuses allocation d'objet auquel cas tu veux rendre très rapidement la mémoire, je vois pas l'intérêt. Tu fais pas de foreach(var i = 0;i++;i<1000000) new Form() si ? Sur 50 classes que je développe, je dois implémenter IDisposable 1 fois.
        Cas vécu d’un conteneur d’objet chargeant de très nombreux objets se désérialisant eux même depuis un flux XML ; un des types d’objet utilisés n’appelait pas le Dispose (du parseur XML et d’autres objets du Framework .Net), résultat : explosion au chargement.
        Sur 50 classes que je développe, 90% expose l’interface IDisposable, car on ne sait jamais comment sera utilisée notre classe ; donc, si l’un des objets membres présente l’interface IDisposable, il faut faire de même.
        
        Sur un exemple simple non, mais lorsque tu as de multiples références sur ta classe, tu fini par ajouter des AddRef et des Release sur tes classes pour gérer ton propre compteur de référence, sa tombé à 0 appelant la méthode Dispose (pour éviter un pénurie de ressource non-managées). Je connais personne qui ai eu besoin de f1aire ça, mais admettons que tu es ce besoin. Expliques moi en quoi c'est différent en Java ou en Python, en quoi c'est moins technique vis-à-vis de ce problème.
        Même conteneur d’objets gérant une arborescence d’objets qui peuvent se référencer l’un l’autre, au déchargement d’une partie de l’arborescence, le Dispose doit être appelé lorsque la dernière référence sur un objet est perdue. Si l’on attend le déclenchement du garbage collector (sans appelé Dispose), au chargement d’une autre partie de l’arborescence ça explose.
        En Java, le garbage collector est beaucoup plus prompt à se déclencher, il y donc moins de problème ; en python, je ne sais pas, car je n’ai jamais construit de très grosse application en Python.
        Et puis, ce n’est pas parce que le petit copain à des défauts, qu’il faut avoir les mêmes.
        
        Tu as lu la page, c'est complètement ubuesque, on rajoute une couche de complexité. On s'en fou c'est caché. Pour le développeur c'est toujours moins complexe que de gérer la mémoire à la main.
        En C++ managé, le destructeur est quasiment l’équivalent du Dispose à l’exception prés qu’il appelle automatiquement le destructeur de la classe mère et qu’il ne s’appelle pas Dispose (mais vu d’autre langage comme C#, il s’appelle Dispose).
        Donc lorsque l’on passe du C++ managé au C# et inversement, il faut faire super gaffe, ça n’apporte rien, mais ça complique encore un peu plus un truc déjà inutilisable.
        Et pour certaines classes critiques (classes de base très utilisés), il est parfois fortement conseillé de gérer la mémoire et les ressources non-managé à la main en créant un objet mixte (C++ managé et C++ non-managé), si l’on veut avoir de très bonne performance. Ce n’est donc pas forcément masqué.
        
        [^] # Re: Un autre bonne raison de ne pas utiliser Mono
        
        Posté par TImaniac (site web personnel) le 08 juillet 2009 à 19:10. Évalué à 2.
        
        donc, si l’un des objets membres présente l’interface IDisposable, il faut faire de même.
        Je suis d'accord.
        Mais désolé on code pas le même type d'appli, mes objets métiers sont pour la plupart indépendant de quelconques objets exposant IDisposable :)
        
        En Java, le garbage collector est beaucoup plus prompt à se déclencher,
        C'est très subjectif ce que tu dis. Dans tous les cas me dis pas que c'est techniquement plus facile de coder en Java parcque le garbage collector passe un peu plus souvent, c'est un peu abhérent.
        
        ; en python, je ne sais pas, car je n’ai jamais construit de très grosse application en Python.
        Bah alors conclu pas que c'est plus facile en Python pour ce problème spécifique.
        
        en créant un objet mixte (C++ managé et C++ non-managé), si l’on veut avoir de très bonne performance.
        Ca c'est dangereux, tu peux te retrouver avec des problèmes de perf liée marshaling, mais là on déborde du problème de la VM pure, c'est pas forcement plus évident de travailler avec JNI en Java et t'as d'autres types de problèmes bien plus enmerdant que le C++ mixé.
# Le point de vue de la FSF

Posté par alice le 21 juillet 2009 à 15:47. Évalué à 2.

http://www.fsf.org/news/2009-07-mscp-mono

Suivre le flux des commentaires

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