TImaniac a écrit 6420 commentaires

MS a des "petits" monopoles sur la plateforme .Net.
Bah parcque c'est MS qui a tout conçu et que c'est MS qui l'a utilisé en premier : mais celà paraît relativement logique. Au début des schémas XML c'est pareil, y'avait que MS qui les utilisait, pareil si le format texte de OOo devient un standard, c'est OOo qui l'a utilisé en premier parcque conçu en premier. Mais je ne vois pas trop où est le problème à vrai dire.

Alors très bien. Un employé Red Hat dit :
- il faut pouvoir programmer en C# et Java avec Gnome.

Ou tu vois le problème ?

Bof, on utilise Mono et on est content : c'est sous GPL/LPGL/X11 et celà respecte des standards reconnus à l'ECMA (donc pas de royalties sur les brevets) et à l'ISO. LEs brevets sont dans une partie de la plateforme .NET : visiblement chez fedora celà leur pète peut être les couilles de vraiment réfléchir ou même se renseigner : Mono a une grosse partie qui ne viole aucun brevet ? On n'est même pas obligé d'installer la partie dépendante des brevets de MS (même s'ils ont eu l'accord d'utilisation) ? Bof on s'en fou ca vient de MS, on va pas non plus se mettre à réfléchir.

Je ne cherchais pas à t'insulter de telletubies, je voulais juste dire "au royaume des bisounours", bref "dans le meilleur des mondes". Désolé si l'expression t'as blessé.

via quelques brevets et quelles autres subtilités que je n'ai pas en tête
Voilà, tout comme la plupart des acteurs du libre : ils ne savent pas donc se méfient. Alors que pourtant tout à a été 10000 fois rabaché.

Une implémentation libre de Java ne pose pas de problème.
C'est encore plus stupide : Sun a de nombreux brevets sur son langage et sur sa plateforme, et en choisissant LEUR système de normalisation, ils se garantissent aussi de maîtriser leurs brevets. Bref, celà pose autant de problème voir plus de problèmes au libre : rien que le mot "Java" ne peut être utilisé sans l'accord de Sun. Yahoo.

en gros une large majorité des représentants reconnus du libre...
Reste Icaza qui reste quand même quelqu'un qui a décidé de développer Gnome parcque KDE posait des problèmes de part sa licence.

S : c'est toi qui a parlé en premier de w3c.
J'ai fait une comparaison, j'ai aussi parler de système de freinage de voiture, tu en conviendras que celà n'a également rien à voir avec la choucroute.

Et ?

Effectivement les pointeurs en C# ne sont pas du tout là pour apporter quelque chose au design objet.
Faut juste que se dire que MS n'a pas voulu que le C# soit un simple langage de haut niveau, mais également un langage de "moyen niveau", avec lequel on peut utiliser des notions plus proches du système lorsque c'est nécessaire (si celà s'appelle C# c'est aussi parcqu'il reprend certains concepts du langage C). Les structures s'inscrivent également dans la même lignée : aucun apport au niveau design, mais question perfs c'est sympa.
Ah si y'a quand même une sorte de pointeurs qui peuvent améliorer le design en C# : les délégués, qui ne sont rien d'autre que des pointeurs de fonction typés. Il y a de nombreuses applications, comme par exemple la gestion des événements : c'est contournable en Java mais c'est nettement plus lourd.
Il paraît par exemple fort dommage dans une application qui manipule des images de devoir se coltiner JNI pour aller bidouiller un champ de bit par soucis de rapidité : celà nuit clairement à la portabilité, à la lisibilité, et peut avoir beaucoup plus de conséquences "négatives" qu'avec des pointeurs comme en C# (ces pointeurs on un minimum de protection tout de même).
Bref, on va dire que C# ratisse un peu plus large que Java au niveau du domaine d'applications possibles.
Pour la comparaison avec Python, ben je connais pas très bien ce langage, mais je vois pas trop en quoi il en est plus proche :)

Pour ma part, je suis convaincu que les optimisations de code dans les langages sans compilation ciblée sur une plateforme de type C# et Java (Eiffel, Smalltalk, Python, Ruby, Perl ...) doivent être réalisées par le compilateur/machine virtuelle (JIT).
Tout à fait d'accord, mais le fait est que parfois le compilateur ne fait pas tout, quand par exemple tu lui demandes d'allouer quelque chose sur le heap, il ne peut pas de lui-même décider d'allouer cet objet sur la pile si celà l'amuse (encore heuresement)

n'importe quoi. Tu peux utiliser des pointeurs et avoir du code portable : par exemple manipulation d'image. C'est comme si je te dis que les classes en Java ca empêche la portabilité parcque je peux accéder à des éléments natifs à travers JNI. Bah là c'est pareil, il y a pleins d'utilisation des pointeurs. Quant aux structures elles sont 100% portables et n'ont encore rien à voir avec la choucroute. Tu parles de trucs que tu ne connais pas et tu te permets de juger. Marrant.

Que .net soit sur w3c.
Tu m'explique ce que viendrai foutre le w3c là-dedans ? C'est quoi le rapport avec la choucroute ? Tu vas souvent demander au w3c de normaliser les systèmes de freinages de voiture ?

C'est en rapport avec du propriétaire, c'est en rapport avec une techno dirigée par une boite. Donc ça pu.
Voilà donc MS utilise le SVG, le XML, etc. Donc toutes ses technos pu car en rapport avec du proprio. Tes arguments sont pitoyables.
.NET en entier est dirigé par MS, mais le langage C# et la plateforme de base (bref, ce dont on parle actuellement) est tout aussi indépendant de MS que le sont les autres normes, même celles du w3c. Y'a que chez les telletubies que les normes du w3c sont libres et influencées par aucune boîte.

Tu t'ai jamais dis que celà pouvait être utile de réutiliser l'existant ?
De wrapper un lib native qui est portable ?
Que dans certains cas la portabilité on s'en balance ?
De toute façon JNI c'est pareil : portabilité = 0.
Franchement arrête ta mauvaise foi à 2 balles.

Alors ca c'est un argument qui tue :)
Sinon ce n'est pas une cochonnerie : il y a certains cas où les optimisations engendrées sont très intéressantes (par exemple aller attaquer directement une image au bit près, chose impossible en Java, ce qui donne un gain de vitesse de 50x). De plus il faut bien voir que la possibilité d'utiliser des objets natifs en appelant un chat un chat est beaucoup plus élégant que cette cochennerie contortionniste de JNI.

Le libre, la plateforme Gnome, n'a pas à voir ses spécifications dictées par C# (MS, beurk) ou Java (Sun, moins pire).
Houlala... J'espère que tu n'utilises jamais les schema XML du W3C ? Nan parcque à la base c'est une proposition de Microsoft. Faut arrêter les arguments "oué mais y'a un rapport avec MS, donc ca pu"

Moi je crois que tu n'y connais strictement rien au C#.
Expliques moi comment en Java je peux attaquer une structure avec un pointeur ou bêtement allouer de la mémoire sur la pile.

C'est faux !
Puisque je te le dis !
S'il y avait eu par exemple des manipulations d'objets natifs avec des pointeurs, ce qui est une spécificité de C#, ben en Java on n'aurait tout simplement pas pu le faire.

Le "gars" n'a fait *aucun* bench et tu lui fais dire des choses qu'il n'a jamais dit !
Effectivement, j'aurai du employer le mot "comparaison"

Ils ont pris un exemple de programme qui a été codé en C# sans tenir compte des spécificités de C# : Moi je peux vous faire en 3 minutes un programme qui marche très bien en C# et qui ira beaucoup moins vite en Java : j'utilise des pointeurs, ou moins agressif j'utilise la notion de structure et de pile : merde on peut même pas en Java. Ah ben oui c'est vrai ce sont des différences triviales ça. D'ailleur si on regarde bien, le C et le Java c'est pareil non ? D'ailleur je peux vous trouver un programme en C qui se code très bien en Java.

Ou alors plus récemment, j'utilise bêtement une collection générique paramètrée par un entier et je fait la somme des éléments qui sont dedans : là encore les perfs vont être catastrophique sur l'un et pas sur l'autre. Mais là encore ce sont des choix de conception "triviaux".

Et puis il n'y a pas que les perfs dans un langage, il y a aussi la facilité d'expression, la puissance d'expression, etc. Même si celà peut d'apparenter à du sucre syntaxique, celà contribue largement au succès d'un langage.

Je rajouterai finalement qu'il faut également tenir compte de la philosophie du langage et de la plateforme : GTK# fait partie de la philosophie C#/.NET parcque .NET a été conçu dans cet esprit de pouvoir réutiliser facilement l'existant sans forcement être portable. Java par contre prône avant tout la portabilité et donc des toolkits comme Swing : gnome-java est un espèce de "monstre" dans le monde java et ne s'intègre pas dans sa philosophie (rappelez-vous le slogant de Sun).

Enfin tout ça pour dire que ce gars a cru faire son malin en ayant trouvé la solution de comparer ces 2 langages/plateformes, et manque de pot il est tombé dans les travers de ce qu'il conteste : aucun bench n'est équitable, et on leur fait dire ce qu'on veut.

(Au fait, dans les 2 camps celà fait longtemps qu'ils ont arrêté de se battre : ils bossent de chaque côté à s'intégrer avec l'autre, à faciliter les communications tout en tenant compte des différences)

Moi je me pose quand même la question de l'intérêt de développer une couche d'abstraction au dessus de GStreamer pour pouvoir utiliser "plusieurs moteurs". GStreamer est déjà en soit une couche d'abstraction, celà ne fera qu'allourdir l'ensemble je trouve.

Il faut bien voir qu'il ne parle pas de licence mais de détendeur du copyright : tu peux à tout moment changer la licence d'un morceau de ton code (et le virer s'il n'est plus compatible avec la licence du projet auquel tu contribues).

Tu bosses dans le spatial et tu dis que les normes sont cotons... Rassures moi vous êtes fier de ce qui est arrivé à Ariane 5 ? Nan parcque bon voilà quoi :)
A mon avis les normes dans les transports aéronotiques sont beaucoup plus sévère que dans le spatial : dans un cas c'est une exigence extérieure des organismes de contrôle, dans l'autre ce n'est qu'un critère interne, même si c'est pour satisfaire le client qui paie des milliards, vous êtes toujours tenus par les impératifs financiers de temps et non de vie humaine.

Redescent toi aussi sur terre : la ligne meteor à Paris a été codé comme ça, et l'ESA c'est pas le nucléaire.

En tout cas, ça n'empêche pas Doom 3 d'avoir le meilleur moteur 3D existant à l'heure actuelle et ce moteur, il est écrit en OpenGL. Alors où est le problème ? On peut faire mieux avec Direct3D ? Je serais ravi de lire ta démonstration à ce sujet...
J'ai jamais dis qu'on pouvait faire mieux en Direct3D, j'ai dis que c'est plus simple à faire avec Direct3D : Carmack est un génie, et il n'y a aucun obstacle pour lui, s'il faut qu'il attaque directement les extensions proprio ou même direct en assembleur, il va pas se géner, mais pas tout le monde peut se permettre de passer un grand nombre d'années à paufiner son moteur 3D : ID Software peut se le permettre, ils sont à peu près sûr de vendre. Les autres boîtes veulent du sûr, et rapidement : la durée de développement d'un jeu étant en gros de 2 ou 3 ans et la durée de vie de 1 ou 2 ans, tu comprend bien que même un petit peu de retard (je le répète, moi j'ai dis que 1 an au début, + 1 an parcque MS implémente pour les développeurs 1 an avant la sortie officielle), c'est énorme face à la concurrence, et il y a le risque de se retrouver avec un moteur vieillot. De toute façon le marché du jeu vidéo semble confirmer ce que je dis : ils en ont rien à pété de la compatibilté inter-OS (parcque c'est une niche commerciale tellement infîme), ils veulent pouvoir utiliser RAPIDEMENT les nouvelles technos, sur la plus large gamme de matos.

C'est n'importe quoi là, l'ARB standardise les extensions en fonction de leurs propres idées et de ce que proposent les différents constructeurs (ATI, NVIDIA, 3DLabs, etc.), pas en fonction de ce que propose Microsoft. Je me demande vraiment où tu es allé pêcher ça...
Euh, sauf que ATI/NVidia travaille main dans la main avec MS, donc quand ATI/NVidia travaille ensuite avec le groupe OpenGL, ben indirectement c'est la même chose qui en sort. T'as lu mon extrait que j'ai cité du emc de chez NVidia ?

Je vois vraiment pas où est le problème là, c'est simplement une question d'approche avec des avantages et des inconvénients dans les deux cas.
En informatique, et encore plus dans les jeux vidéos, un standard n'a d'intérêt que s'il est à la pointe et qu'il résume l'état de l'art au moment où il sort.

ALors je le répète : Doom3 est une démonstration technologique faite par une équipe qui en a les moyens, et dirigé par un génie. Mais quand tu regarde le temps qu'ils ont mis à développer leur jeu, tu te demandes si ca valait vraiment le coup (pour eux oui parcqu'ils vendent plus le moteur plus que le jeu) : FarCry a été développé en beaucoup moins de temps, et question graphismes c'est un bien meilleur rapport Homme/Année/Qualité.

Tu déduis mal, depuis 2 ans 1/2 il implémentait les fonctionnalités qu'on allait trouver dans OpenGL 2.0. Relativement facile puisque les spécifications préliminaires postées sur le site OpenGL étaient publiques.
Nan mais il a implémenté les foncitnnalités de OpenGL 1.5, pas du 2.0 : il manque en gros un petit détail : un langage de shader.

Et puis, contrairement à Direct3D, avec OpenGL il ne faut pas s'arrêter aux numéros de version. Ce qui compte, c'est les fonctionnalités implémentées, et pour ça il faut regarder les extensions, qu'elles soient ARB, NVIDIA ou ATI...
Je suis pas bête, je compare pas les numéros de version genre "c'est moi qui est le plus gros numéro", je compare effectivement les fonctionnalités implémentées, et justement, les technos DirectX sont implémentées en gros au moment ou OpenGL sort seulement les premières spécifs de travail de fonctionnalités équivalentes (faut bien qu'il trouve l'inspiration quelque part)... bref là où y'a encore rien de concrêt et de décidé.

Mais alors me dire qu'il faut regarder les extensions propriétaires de chaque constructeur pour vraiment comparer c'est du n'importe quoi : OpenGL n'a pour seul intérêt que d'être multi-plateforme et "standard". Ces extensions ne rentrent pas du tout dans ce contexte, et DirectX a pou ça l'avantage de standardiser sa plateforme vis-à-vis du matos en essayant d'ingurgiter les nouveautés le plus vite possible avant que chacun fasse sa petite extension personnelle : en tout cas pour les développeurs c'est nettement plus imoprtant d'avoir une abstraction matérielle des principaux acteurs que d'avoir une abstraction d'OS, sachant ce que réprésente les alternatives dans le domaine comme part de marché et aussi comme stabilité/standardisation (des distributions nux, etc).

Le travail que tu soulignes de Carmack qui a du se cogner plusieurs modes de rendu est la parfaite démonstration de l'incohérence de la situation : OpenGL qui a un objectif de standardisation a beaucoup trop de retard. Mais bon c'est Carmack, il aime ça et puis il a un don pour faire des miracle même avec des vieux pots.

J'en rajouterai une couche en disant qu'il n'y a pas que Direct3D à comparer, MS propose une plateforme complète (Bref, tout directX), et OpenGL tout seul ne suffit pas.

(PS : je disais 1 an de retard, + 1 an de retard quand à la mise à disposition aux développeurs, Carmack ayant développé son jeu avec OpenGL 1.5, j'en déduis qu'il n'a même pas eu le droit au dernier 2.0 avant l'heure, ce qui fait que le retard total est peut être même encore plus grand entre l'arrivée de DirectX chez les développeur et l'arrivé de OpenGL "équivalent")

euh :
OpenGL version 2.0, released on September 7, 2004
DirectX 9 : decembre 2002
Alors désolé, mais ceux qui font tout le taf, c'est pas les gars de chez SGI, c'est ceux de Redmond avec ses amis ATI/NVidia.

Allez j'en rajoute une couche, puisque OpenGL 2.0 vient de sortir dans l'indifférence général :
"En revanche, aucun jeu OpenGL 2.0 n'a été annoncé. L'industrie du divertissement lui préfère de plus en plus DirectX, le langage concurrent de Microsoft. « Certains effets permis par OpenGL 2.0 sont implémentés dans DirectX depuis deux ans », rappelle ironiquement Julien Merceron. « Les jeux d'action, comme Far Cry et le très attendu Half-Life 2, s'appuient sur DirectX 9.0, la dernière version de DirectX », observe Stéphane Quentin, responsable des relations presse et produits chez nVidia. Seule exception notable, Doom III , sorti à la mi-août, a été programmé à partir d'OpenGL 1.5"
(http://www.01net.com/article/250932.html(...))

Alors oui, Carmack est un génie, mais sans le soutien de ID Software je sais pas ce qu'il resterait d'OpenGL dans les jeux...

C'est en cours pour la version 9 chez WineHQ...
Faut qu'ils se dépêche, parcque le SDK du prochain DirectX arrive l'année prochaine chez les développeurs.

Je suppose que si Apple propose cet écran c'est qu'il doit bien y avoir une ATI aussi qui supporte ces cadences :) (vu qu'en général les macs sont livrés avec une ATI)

Vi enfin il fallait mieux que SuSE se fasse bouffer amicalement par une boîte qui semble aimer le LL, plutôt que d'attendre et de se faire bouffer moins amicalement par un concurrent.

Je vois ca d'ici :
- Bonjour, je suis l'ingénieur de Transgaming, je dois vous aider à faire un jeu natif pour Linux
- cool, tiens vlà les sources de notre moteur pour DirectX
- ...
- quoi ?
- ben faut tout réécrire en OpenGL et...
- Hein ? Qu'on demande à notre fournisseur de moteur de nous le réécrire ? Faut qu'on jette tout ce qu'on a fait ? De toute façon OpenGL ne supportera nos techniques que dans 2 ans (comprendre 1 an de retard pour OpenGL, mais en plus là on est 1 an avant la sortie du prochain DirectX, mais ils ont déjà le SDK) !
- ben euh...
- bon bah z'avez qu'à recoder DirectX sous Linux !
- bah c'est ce qu'on va retourner faire, @+

Bon alors je crois qu'on a vu le même avocat :)
Une conférence sur le droit en informatique sur Rennes non ?
Enfin moi je me suis posé les mêmes questions que toi :
http://linuxfr.org/~TImaniac/15587.html(...)
Tout le monde dit un peut tout et le contraire.
A vrai dire l'avocat nous disait qu'un auteur a toujours la possibilité d'utiliser son droit de retrait et de repentir (il y a une loi qui l'interdit, mais l'avocat nous a dit que celà ne s'applique que dans le cas d'une collaboration entre un employé et son employeur, bref je passe les détails) , et donc changer après éventuellement de licence, les utilisateurs n'ayant alors plus la possibilité de diffuser le code souce par exemple, la précédente licence n'étant plus valable (si si, même plus possible de forker).
Le truc c'est que les utilisateurs peuvent demander des dommages et intérêt pour le préjudice subit, ce qui est tout à fait son droit : bref ca va coûter très cher à l'auteur qui doit payer les dommages (non pas qu'il soit en tord) et donc celà ne devrait jamais se produire dans la pratique (because les 2 parties seraient perdants).
Enfin c'est ce que m'a dit Fabien Penso qui a demandé à des personnes haut placé dans le monde du LL après l'intervention de cet avocat :)
Bref il semble que dans la théorie il est raison, mais que dans la pratique celà ne marchera jamais :)

Je te parles des logiciels critiques sécuritaire, il y a pleins de logiciels au dessus, qui font plutôt parti de la "logistique", qui utilisent les composants sécuritaire mais où le plantage a des conséquences beaucoup moins grave (une panne d'électricité, même sur tout un pays pendant plusieurs jours, c'est toujours moins grave que de faire péter le coeur de la centrale ou de faire se crasher un airbus)

Oui je le crois. Le mouvement des logiciels a montré qu'ils étaient capables de faire des logiciels de tous les jours, mais désolé je n'ai vu aucun logiciel de centrale nucléaire sous GPL. Les petites mains comme tu dis sont pour la plupart incompétent en matière de sécurité informatique (la vrai, je parle pas de savoir éviter les débordement de tampon dans un serveur) : le noya Linux n'est pas mieux que le reste, c'est un vrai gruyère à bugs comme la pluparts des logiciels, propriétaires ou non. Ils sont suffisament "sûr" pour qu'on leur accorde une certaine confiance pour gérer un serveur, une base de données, voir des informations bancaires (quoique ils se posent des questions), mais il y a toujours un risque, et dans des secteurs critiques comme le nucléaire ou les transports (pas la voiture évidemment qui a beaucoup moins de conséquences) ont rigole pas du to avec ça : ils utilisent des experts en méthodes formelles, développent des "petits" logiciels sur lesquels ils peuvent avoir une confiance presque "absolue" (il y aura toujours des failles : mauvaises spécif, matos non prouvable) : seulement voilà ca coûte extrêment cher en homme/année, car on code pas 140 lignes en 10 minutes. Ce coût me fait dire que les LL seront pendant encore longtemps à "l'écart" de ce genre de pratique, parcqu'il ne suffit plus d'avoir une grappe de geek et de testeurs qui savent tapoter sur irc et rentrer une valeur dans bugzilla.