TImaniac a écrit 6420 commentaires

un mécanisme ressemblant à un JIT, qui s'appelle Psyco
Ah non ! Psycho c'est du AOT, et on perd la portabilité. D'ailleur ca tourne que sur x86.
Enfin l'existence de ce projet montre clairement qu'il y a une grosse différence entre mode compilé et mode exécuté ;-)

Tu te contredis. Si c'était mieux d'optimiser à la compilation, alors Java et Mono n'utiliseraient pas un JIT
c'est juste qu'il y a pleins de sortes d'optimisation, dont certaines sont dépendantes de la machine cible, d'où l'idée de garder un bytecode optimisé (pour le typage par exemple, mais aussi tout ce qui concerne les optimisations sur la logique du programme, déroulement de boucle, élimination de variables inutiles, résolution de méthode virtuelles, etc.), et d'effectuer les dernières optimisations à l'exécution (ou juste avant, quand on connait la machine cible).

Donc le JIT est utile (suffit de comparer les perfs avec et sans).

Il ne fait pas de doute que l'implémentation actuelle de Python soit souvent plus lente que celles de Mono/Java, mais les caractéristiques du langage (et notamment son caractère soi-disant "interprété") ne sont pas le facteur limitant.
Ce qui esst clairement limitant c'est sont côté trop dynamique. Reste que si tu fais quelques hypothèses et qut tu attaques plus tôt les optimisations tu gagneras en perfs, c'est ce qui se passe avec Psycho ou IronPython.

Enfin à part la question de perf, un langage avec typage statique est plus sûr qu'une langage sans typage statique, qui permet des choses vraiment douteuses d'un point de vu méthodologique, comme la modification en "live" d'interface.

Java et .Net aussi utilisent un bytecode. Quelle est la différence alors ?
Ben y'en a qui le compile, d'autre qui l'interprête. Question de perf.

si le type n'accepte pas la méthode que tu lui demandes tu as droit à un traceback.
C'est vrai le client il va adorer ce genre de truc. Enfin si tu fais payer très cher la maintenance ca peut être un bon moyen d'avoir des rentrées d'argent régulières :)

Oui, c'est rigolo. Exactement comme une VM Java ou C#.
rataiii
En ce qui concerne la VM de Mono/C#, elle commence par compiler en code natif le bytecode (mécanisme JIT et AOT)
Mono est d'ailleur livré avec un interprêteur et un compilateur, le premier ayant l'avantage de tourner sur plus de plateformes, le 2ème étant beaucoup plus rapide mais limité à certaines plateformes matérielles.
A ce compte-là, ton processeur interprète aussi les instructions qu'on lui envoie
Dans tous les cas il y a une grosse différence entre l'interprété et la compilation du bytecode, dans un cas le mécanisme d'interprétation se situe au niveau de la VM, c'est du logiciel qui interprête, dans l'autre cas c'est le proc, du matos qui interprête si tu veux : et y'a d'énormes différences de perfs. Donc ce n'est pas un troll du tout.

N'importe quoi. Les vérifications et optimisations peuvent être faites lors de l'exécution, il n'y a pas que la compilation dans la vie.
Tu comprends rien à ce que je veux dire. Evidemment que ca peut être fait à l'exécution, mais question perf c'est toujours mieux d'optimiser AVANT l'exécution, et c'est toujours beaucoup mieux d'avoir une vérification statique à la compile qu'à la compile, parcque en général c'est pas le même qui développe et qui exécute.
La VM a bien assez à faire pour compiler en code natif et optimiser pour le proc en dessous, si en plus faut qu'elle se farcisse une vérification de type à tout bout de champ tout en cherchant à optimiser en conséquence, voilà quoi.

Faut chercher à faire le maximum de chose en amont, pour se bouffer moins d'erreur à l'exécution, et pour laisser faire à la VM les optimisations qui ne peuvent être faites qu'à l'exécution.

Qui te parle de traduction ?
Moi. Tu as forcement dû traduire pour ton article des propos en anglais. Je dis pas que tu as fourni des traductions mais toi comme moi avons dû procédé à l'interprétation de textes anglais, donc je ne vois pas en quoi le fait que ton article soit en français soit plus pertinent que mon interprétation des propos de MDI par exemple.

Parce que je ne paye pas des développeurs à implémenter une version open source de .NET, parce que je ne cherche pas à augmenter mes parts de marché avec ma distribution linux, etc.
Et moi je paie des gens ? Je cherche à augmenter mes parts de marché ?
Ok j'ai un parti pris, mais je ne vois pas en quoi tes propos pourront faire taire le débat, ils peuvent sûrement nourrir le débat et y apporter un point de vue bien argumenté avec une analyse clair, mais si le débat pouvait être clos les juristes l'aurait fait depuis longtemps.

Ce qu'il y a de formidables avec toi, c'est qu'en plus de raconter n'importe quoi dans une "discussion" (et ceci sans aucun argument)
C'est quoi ce n'importe quoi ?

tu es même capable d'attaquer quelqu'un que tu ne connais pas sur la pertinence d'un texte que tu n'as pas lu.
A AUCUN moment je n'ai mis en cause le contenu de ton article, j'ai juste voulu minimiser l'affirmation qui tentait de dire que ton article ferait taire le débat.

En termes plus clairs, tu est un imbécile et je ne débattrai donc pas avec toi.
D'après le maigre résumé que j'ai lu plus haut de ton article, tu conclus que les technos Java et Mono c'est à éviter tous les 2. Je suis en tout cas beaucoup plus d'accord avec toi qu'avec certains : pour moi Java et Mono c'est kif kif bourriquot légalement.

??? C'est compilé dynamiquement en byte-code (sauvé dans un fichier .pyc pour Python) puis exécuté par une VM.
Et la VM elle fait quoi ? Ah ben elle interprête le bytecode comme c'est rigolo :)

Tu confonds typage fort et typage statique.
Reste que le typage fort pert tout son intérêt lorsqu'il est dynamique, puisque son principal intérêt est d'effectuer des vérifications et optimisations à la compilation

J'ai pas dis que ton article avait moins de valeur, je répondais juste à la phrase qui indiquait que ton article mettrait fin au débat, comme si ton article arriverait comme la voix de dieu parmis nous.
Cela dit tout est parti d'un mal entendu, j'ai mal lu la phrase initiale, et on m'a donné à plusieurs reprises un lien vers le journal parlant de ton article comme "argument", ce que je trouves passablement énervant quand le dit journal ne reprend aucun argument de ton article, et est donc parfaitement inutile (le lien, pas ton article).

Oué enfin on peut toujours branché la sortie vidéo sur une carte d'acquisition, ca sera toujorus moins crade qu'un camescope qui tangue :)

En fait en bas de chaque commentaire y'a la possibilité de voter pour un commentaire, et bien entendu plus t'as d'XP et plus t'as de votes à distribuer...
C'est ce système de vote qui donne la moyenne de tes commentaires, sachant que les notes vont de -10 à +10.

Dans le menu à gauche tu dois avoir une ligne Avis X/X
c'est le nombre d'avis que tu peux donner sur les commentaires dans la journée.
Par exemple 5/8 signifies qu'il te restent 3 avis à donner (t'es pas obligé de les épuiser) sur les 8 que tu as par jour.

Non pas n'importe quoi :)
Ce que tu dis ne contredis pas mes propos.
Ils peuvent s'amuser à "étendre" la norme en rajoutant des trucs, mais question interopérabilité ils sont obligé de garder une compatibilité avec l'existant (pour faire tourner les vieux sites).
Mais bon là ils partent sur des bases plus saines puisqu'ils utilisent des standards bien définis et propres grammaticalement. (Parcque bon les premières normes HTML étaient beaucoup trop laxistes et pas assez contraingnantes).

Bah moi je dis que non :)
Lorsqu'ils auront conquérit 99% du marché ils ne pourront plus se permettre de casser l'interopérabilité, comme c'est le cas pour IE ou le support du win32.

c'est pas la licence de la doc, c'est la licence des specs, ca m'étonnerait que gcj fasse du reverse engeneering :)
Enfin reste que le texte dit clairement que Sun a des brevets sur les technos liées à Java, que tu lises ou pas, c'est un fait.

Enfin arrêtons de nous disputer, je trouves de toute façon que c'est quelque chose de bien qu'on est enfin des plateformes de développement modernes et relativement performantes soutenues par l'industrie sous Linux. Le C/C++ ca commencait un peu à lourder.

bah oui c'est bien ce que je dis, ils peuvent potentiellement se faire enmerder par Sun parcqu'ils n'implémente pas tout.

Ah oui encore une chose, MS et Sun ont tous 2 intérêt à ce que leurs standards soient respecter, chacun ayant choisi sa méthode (JCP et ECMA), mais chacun se gardant bien quelques petits "+" (brevets) pour enmerder celui qui sort de la norme : MS ne cède de licence que pour faire un CLR (donc qui respecte la norme de l'ECMA) et Sun idem.

Aaaaah :)
Donc Mono n'est pas plus dangereux pour MS que ne l'ai gcj pour SUN actuellement, et Sun peut très bien faire chier gcj pour non respect de la licence du jdk le jour où ils deviennent enmerdant (à lire c'est pas très long et compréhensible pour une licence), comme MS peut faire chier Novell... il y a quand même de nombreux points communs ! D'ailleur dans la licence du jdk il est clairement dit qu'on est obligé de respecter la norme de A à Z, au risque de s'attirer les foudres de Sun, donc si gcj n'implémente pas tout et devient donc incompatible... enfin ca reste des supposition, et perso je crois pas qu'il y aura de problème pour gcj comme je ne le crois pas pour Mono.

J'ai même parlé d'un fork à part entière.
On parle de fork quand il y a reprise du code. La c'est juste une autre implémentation des "normes" de Sun(JCP&Co)

Ah oui aussi, Sun se fait le plus gros de son blé avec Java sous Windows, pour l'instant gcj est aussi dangereux pour Sun que l'est Mono pour MS...

Il y a des brevets qui ont été introduits par une boîte qui possède le brevet et là mis sous GPL. Pour le mettre dans un source GPL, ça implique qu'il accèpte la licence.
hors la licence dis clairement qu'elle n'est pas compatible avec les brevets, quelle que soit la licence du brevet...

Il y a les brevets, qui comme pour mono peuvent être implémenté mais ne peuvent pas être utilisé. Typiquement, Red Hat livre les sources de ntfs mais le module n'est pas compilé.
Ce qui est complètement idiot puisque la licence d'implémentation d'un brevet ne se borne pas au binaire.

(mais IBM autorise l'utilisation de ses brevets dans le noyau Linux).
idem, celà reste incompatible avec la GPL quand même...

Dans ce cas, je suis persuadé que Linux et plus particulièrement Red Hat (en ne compilant pas ntfs par exemple) a très peu de problème de brevet. Genre un dizaine. Vu la taille du projet, c'est remarquable.
Peut être mais n'empêche que c'est dangereux... surtout dans un produit GPL.

Donc les 283 brevets il convient de bien les modérer car la majorité des brevets ont été introduits par les propriétaires des brevets.
Et les 27 de Microsoft ?

Quand je parlais de paternariat entre IBM et MS c'est pas des accords de licence, mais des partenariats de développement de produits en communs, par exemple IBM développe Rational XDE pour Visual Studio et MS les encourage vivement. MS a confié à IBM le soin de fabriquer le proc de leur prochaine console.

Donc si Sun avait une oportunité d'attaquer Red Hat, Sun ne s'en priverait pas.
Sun pourrait attaquer Red Hat parcque l'implémentation de gcj et classpath ne sera complète, comme Sun l'a fait pour MS non ?
Mais je suis pas persuadé comme toi que Sun est un quelconque intérêt à attaquer Red Hat, Sun a besoin d'allié pour supporter sa techno.

Ce n'est pas ce que fait mono. Mono implémente les trucs à problèmes et serre les fesses.
DotGNU fait pareil. Mais comme je me tues à te le répéter, Novell n'a aucun intérêt à se prendre un missile de MS entre les fesses, je suppose qu'ils ont largement mesurer les risques de ces fameux brevets.

Enfin n'empêche il suffirait que les brevets logiciels ne soit pas ratifier pour résoudre le problème, enfin pour nous, les américains vivent leur vie de leur côté, et je m'en fou. Dommage que Red Hat soit trop "américanisé" dans sa vision des choses : il pourrait entretenir un fedora extra rest-of-the-world.

Autant pour moi j'avais mal lu ta phrase.

Non je ne racontes pas n'importe quoi.
Si je n'annonce pas que je fais une JVM Java (TM) personne ne peut m'obliger à suivre la norme, elle n'a aucun caractère obligatoire SI Sun n'a qu'un TM.
Si j'y suis obligé c'est bien que Sun a d'autres droits de propriété intellectuelles sur les technos Java. Ce que je voulais démontrer.

"Sun also grants you a perpetual, non-exclusive, worldwide,
fully paid-up, royalty free, limited license (without the
right to sublicense) under any applicable copyrights or
patent rights it may have in the Specification to create
and/or distribute an Independent Implementation of the
Specification that: (i) fully implements the Spec(s)
including all its required interfaces and functionality;"

Sun préviens clairement qu'on est obligé de respecter la norme non pas parcqu'ils ont le TM, mais parqu'ils ont des droits de copyright et brevets dessus.

En gros : vous respecter les règles, c'est à nous. Même si vous n'utilisez pas le TM Java.

Parce qu'il n'y a pas de problème dans l'implémentation de java qu'utilise Red Hat. Si Sun pouvait attaquer Red Hat, il le ferait et vite. Red Hat (et biensur la communauté GNU/Linux) est en train de ruiner Sun.
Là je suis pas concaincu, Sun a grand intérêt à ce que sa plateforme soit adopté, cela ne peut être que positif pour Sun, sachant que Sun gardera toujours une longueur d'avance sur Red Hat, parcque Sun implémentera toujours en premier les specs du JCP.
En gros c un peu la même position que MS vis à vis de Mono.

Puis voit la politique de Red Hat qui vise à pique des clients Solaris :
Faut pas tout confondre, Sun peut pas blairer MS mais ils passent des accords, IBM peut pas blairer MS, et ils sont de gros partenaires.

Par contre ils n'auront jamais toutes les fonctionnalités de Java fournit par Sun. Tant pis, on ferait avec. gcj/classpath ne sera probablement jamais parfaitement compatible avec les specs de Sun. C'est un fork à part entière.
Bah au pire ca sera pareil pour mono : on laisse tomber ce qui pose problème et on garde le reste, en particulier tous les APIs spécifiques à Gnome.

Red Hat à l'heure actuelle est une menace pour Sun qui fond comme neige au soleil.
Meuh non, Sun est bourré de pognon, y'a qu'à voir tout ce que MS a filé à Sun :)

Tiens, régale toi :
"Patent issues are not new for the linux kernel. Redhat patented Ingo Molnar's work, and the SELinux project faced patent claims from the company hired to do most of the coding. Now patent concerns are plauging the VM"
( http://kerneltrap.org/node/388(...) )

Linux VM hackers are engaged in ongoing discussions on both large page support (covered last week) and improving the performance of the new reverse mapping mechanism. That conversation slowed down, however, when Alan Cox pointed out that a number of the techniques being discussed are covered by SGI patents. In fact, a closer look by Daniel Phillips shows that a number of existing Linux technologies, including reverse mapping in general and the buddy allocator, are covered by these patents. This is a problem, he said, that we can't ignore.
( http://lwn.net/Articles/7632/(...) )

"Linux ally IBM turned out to own the largest number of patents uncovered in Ravicher's research. Big Blue held 60 patents that could conceivably threaten the Linux kernel. Hewlett-Packard, Intel and Novell also held some of the patents in question, Ravicher said."
( http://www.nwfusion.com/news/2004/0802linuxstu.html(...) )

ah oui dans la liste y'en a aussi 27 de MS, plus que ceux de MS sur .NET.

ca te suffit comme justificatif pour dire que Linux en viole un bon paquet ?
et personne ne le nie sauf toi.

ais c'est évident. Il est beaucoup moins dangereux d'utiliser des technologies MS avec plein de brevet que de chercher à ne pas utiliser de brevet.
Linux utilise des technos MS puisque MS a menacé d'attaquer Linux.

Pour tous les autres utilisation il faut l'accord de MS et selon les conditions de MS. CQFD.
On est d'accord. Et quand on utilise Mono on utilise pas les brevets de MS, il n'y a que Mono qui les utilise. CQFD.

Trouves moi un texte qui le dit.
Trouve moi un texte qui me montre qu'il y a un lien, avec s'il te plait un cas concrêt de licence accordé sans restriction sur la distribution comme c'est le cas de la licence accordé par MS.

- pourquoi MS n'a pas dit que l'utilisation est libre et c'est limité à dire que seul l'implémentation gratuite est autorisé ?
Parcqu'ils veulent garder des droits sur leurs brevets s'ils sont utilisés pour faire une cafetière.

Si ntfs n'est pas activé, c'est pour faire chier qui ?
S'il n'y a pas de mp3, c'est pour faire chier qui ?
S'il n'y a pas ffmpeg, c'est pour faire chier qui ?
S'il n'y a pas wine, c'est pour faire chier qui ?
Ben ces licences indique clairement que l'implémenteur doit répondre à des contraintes sur la redistribution de son implémentation. Donc Red Hat ne peux redistribuer sans donner de royalties. Dans le cas de la licence concernant Mono et MS, il n'y a pas de contraintes (obligation de royalties etc.)
Wine c'est différent, y'a pas vraiment de licence.

Tu inventes encore et tu n'as jamais avancé de preuve.
Si si je t'ai filé 2 liens plus haut mon coco.

Si c'est si "simple", pourquoi le logiciel libre n'arrive pas a faire un codec mpeg4 sans utiliser les brevets ?
Parcque les codecs sont essentiellement constitué d'un format d'encodage qui correspond exactement à un algorithme d'encodage et/ou de décodage : bref y'a pas moy d'échapper dans ce cas précis aux algo brevetés, d'où la nécessité d'avoir une licence.

Mono n'est pas un codec, et pour implémenter une lib (bref une interface constitué de méthode), il y a un peu plus de possibilités tout de même.

À se demander pourquoi MS déposent des brevets si c'est si simple de les contourner.
Houlà j'ai pas dis que c'était simple. Je constate juste que DotGNU et MDI ont clairement dit qu'ils tentaient d'éviter les techniques brevetés.
et si c dangereux les brevets c qu'ils peuvent être trop généraliste ou contraignant, comme pour les codecs.

ncore des conneries monstrueuses et dans ta prétention absolue tu croire que le seul fait que tu les dises les rendent vrai.
Je répète ce que dis Novell et l'avocat que j'ai rencontré. J'invente rien.

C'est juste qu'on arrête pas de me filer le lien vers ce journal, comme si c'était un argument. Vu que l'article est pas en ligne je ne peux pas lire les soit disant arguments, c'est un peu pas crédible. Donc je veux bien discuter de quelque chose si on veut bien me le montrer, pas que je sois obligé de l'achter.

Allai, je suis sympa et vu que tu dis toujours que j'ai pas de sources :
http://news.com.com/Sun+settles+with+Microsoft,+announces+layoffs/2(...)
the software company will pay Sun $700 million to resolve antitrust issues and $900 million to resolve patent issues,

Ayé t'as compris ? Sun a autre chose qu'un simple Java(TM).

Alors maintenant explique moi pourquoi Red Hat ne considère pas Java comme Mono. Sachant que Mono est lié à MS et que Sun l'est aussi fortement.

J'attend toujours que quelqu'un m'envoi ce numéro par la poste.