boubou a écrit 1384 commentaires

Oui, tout à fait, c'est un modèle qui semble en cours d'adoption par certains acteurs. Mais vu le succès des Middlewares (moteurs 3D, moteurs physiques, et même d'IA), on peut se demander si c'est vraiment viable pour l'instant.

Il y a quand même deux gros problèmes pour les jeux : 1) le gros marché, c'est les consoles et là, vu les problèmes de royalties, pas d'open source 2) un vieux jeu est un jeu mort, or l'open source capitalise à fond sur l'accumulation...

A mon avis, le principal problème des jeux open sources, ce n'est pas la triche, mais plutôt leur développement. Pour réaliser un jeu moderne, il faut des programmeurs, pas de problème pour en trouver, mais aussi et surtout des designers au sens large (game designer, graphismes et musiciens, au minimum), et là, c'est une autre paire de manches. Excepté les jeux déjà amortis (comme Quake), je ne connais pas (mais je me trompe peut être) de jeu open source qui soit du niveau de la production moderne. Il y a bien des moteurs (par exemple celui de Arx Fatalis, sauf erreur de ma part) open source, mais le contenu graphique et sonore n'est pas open source. J'ai participé au projet freecraft (un clone de warcraft II) et la difficulté principale, ça a été (et c'est encore) de trouver des graphistes. De même, freeciv a du attendre des années avant d'avoir un graphisme acceptable. Et je ne parle pas du gameplay qui est ouvertement pompé comme dans freeciv et freecraft. Bref, je trouve que ce n'est pas la joie, mais bon, je suis peut être très négatif

En effet... Entre le message de Kilobug, celui de Ufoot et le tien, il y a comme qui dirait un groupe d'indices qui pourrait laisser croire que j'ai dit de grosses conneries... Et en fait, en y réflechissant bien, j'ai bien peur que ce soit le cas. Je crois que je vais aller poster n'importe quoi dans la news Mozilla/IE, ça se vera moins.

Damned j'avais oublié cette close de merde. Cependant, je ne serais pas aussi catégorique que toi. Ca limite la liberté des développeurs Linux qui utilisent BK (donc par exemple de Linus), mais rien n'empêche le noyau Linux d'implanter une fonctionnalité concurrente de BK à partir du moment où les développeurs qui ajoutent ces fonctions n'utilisent pas eux-même BK. Bon, ok il reste le problème du merge dans les sources de Linus. En gros, il faudrait un patch externe. Ouaip, ça pue, donc du point de vue pratique, j'ai bien peur que tu ais parfaitement raison.

Ouai, sauf que le fait que Linus utilise BitKeeper ne remet absolument pas en cause l'esprit libre de Linux (avec un x). On peut critiquer la décision de Linus (à mon avis, c'était une mauvaise idée du point de vue politique), il n'empêche que beaucoup de gens disent que Linux avance beaucoup plus vite depuis de Linus utilise BitKeeper. D'autre part la licence de Linux n'a pas changé (!) et les développeurs qui ne veulent pas utiliser BitKeeper peuvent travailler comme avant avec Linus.

Pour le 1), tu oublies ton mantra "va lire la doc L4 http://www.l4ka.org/(...) ".

Sans racune...

Ouai, mais bon, il existe quand même des choses moins contestables que les autres. Par exemple les travaux que tu peux trouver là : http://www.cs.rice.edu/CS/Systems/DynaServer/(...)

En fait, il y a tout un courant de recherche en évaluation de performances, mais c'est clair qu'ils ont moins pignon sur rue que les boites de merde comme TMC.

Le meme niveau égocentrique et puéril des gens sur ce forum : XML c 'est 'à la mode', c'est donc commercial, c'est de la merde ! Et le meme DESERT l'année derniere au forum XML coté défenseurs du libre qui ont bien laissé la
place à Microsoft ou autres de ses valets.

T'es un malade mental, c'est ça ? Il me semble que les meilleurs outils XML sont justement open source (xerces, xalan, saxon, cocoon, fop, batik, etc.). Certains sont mêmes des inventions remarquables de la communauté du libre (par exemple ant, un outil génial).

Une autre remarque au passage. Le fait que J2EE soit plus ou moins rapide que .Net n'a pas beaucoup de rapport avec Java lui-même. Les JVMs ont maintenant des performances excellentes (par exemple pour le calcul numérique, cf http://tilde-hoschek.home.cern.ch/~hoschek/colt/(...) ). Par contre, J2EE est relativement jeune et certains éléments comme CMP sont assez merdiques en terme de performances. Une mauvaise conception d'une appli ne remet pas en cause le langage support.

universitaires tout justes bon à discourir, et à théoriser mais
incapables (çà va avec la fonction remarquez) de 'penser' que l'informatique c'est aussi du développement
professionnel dont le but est la rentabilité.

Regarde (un exemple parmi des dizaines d'autres) http://apiacoa.org/studies/index.html(...) et tu veras que tes propos poujadistes dignes du café du commerce ne tiennent pas la route une seconde.

Java propriétaire, c'est aussi du FUD.

N'importe quoi CF http://www.w3.org/TR/REC-CSS1#acknowledgments(...)

Il a aussi cliqué une fois de trop...

Oui, je sais, -

Depuis quand COM est un standard ? C'est un produit de Microsoft que d'autres entreprises ont implanté sur des OS non Microsoft, mais ça reste un produit Microsoft...

Sinon, les astuces sur DOM sont débiles car non portables. DOM n'est ni alambiqué, ni compliqué. C'est juste un peu balourd et verbeux.

Si, il y a un standard (un dialecte XML), ça s'appelle XBEL (http://pyxml.sourceforge.net/topics/xbel/(...) ). C'est utilisé par Galeon et Konqueror !

Ne doit-il pas avoir 2 points ?

Mon commentaire n'est en aucun cas une contre-argumentation, comme je le disais d'ailleurs. Je pense simplement qu'il est toujours dommage de polluer un discours (peut être intéressant) par des analogies, comparaisons ou métaphores mal venues. Tu peux toujours penser que Hilter est un adjectif, ce n'est pas mon point de vue et sans vouloir tomber dans le politiquement correct (je conseille la lecture de No Logo à ceux qui pensent que le politiquement correct est 100% mauvais), je pense qu'il est préférable, par exemple par respect envers les victimes, d'éviter de l'utiliser comme tel. Je pense aussi qu'il est dangereux de profiter (manipulation ?) d'un commentaire pour nier toute vérité historique en mettant explicitement sur le même plan Hilter et Lénine.

Sans me prononcer sur le fond de ton commentaire, sur la forme je pense que tout le monde sera d'accord avec moi pour dire qu'une comparaison même "humoristique" de Microsoft (et d'ailleurs de beaucoup d'autres) avec Hitler ou Lénine n'est pas très pertinente, voire très mal venue. J'espère qu'il est inutile que je détaille pourquoi. D'autre part, même si cette fois ci, l'unanimité sera sûrement moins évidente, la comparaison entre Hilter et Lénine me choque presque qu'autant que celle de Microsoft avec Hilter. Hilter et Staline, en première approximation, je suis d'accord (c'est quand même plus compliqué que ça). Mais Hilter et Léniné ??

C'est du foutage de gueulle. Le dossier, c'est une requête sur le gros système de merde qui gère ton compte, et hop, on retire l'argent et hop M. le directeur te signe le chèque. Bref, c'est du grand n'importe quoi, mais c'est la spécialité des banques et des assureurs.

Avoir un compte en banque est obligatoire dans les faits car tu n'a pas le droit de payer en espèces au dessus d'une certaine somme (je n'ai pas le chiffre en tête). De même qu'il est obligatoire de prendre 20 heures de cours de conduite avant de passer le permis. Tout ça n'est pas très moral, à mon avis.

Ouaip, et il y a longtemps qu'ils ne sont plus trop différents des autres banques...

Maintenant, mais ils ont commencé avec du retard vis-a-vis de IE.

Non, vis à vis de la merde sans nom qui tenait lieu de support XSLT dans IE 5.x. Donc en fait, sans retard. Le vrai gros défaut de microsoft est de souvent mal implanter des standards (à cause d'une "interprétation" maison) et d'installer de facto un nouveau standard foireux...

Petite précision, par espace de noms de l'élément, je veux dire espace de noms propre à l'élément, pas espace de noms auquel le nom de l'élément appartient (cette distinction est d'ailleurs à la base de toute la confusion qui tourne autour des namespaces).

Putain, mais lis donc la spec !!!!!!!!!!!!!!!

Tu n'a jamais remarqué qu'on utilise presque jamais d'espace de noms pour les attributs dans XSLT, RELAX NG, les Schémas W3C, etc ? C'est parce que les processeurs reconnaissent les éléments (en se basant sur l'URI associé au namespace) puis ils traitent les attributs qui sont dans l'espace noms DE L'ELEMENT. Par exemple, tu écrits <xsl:template match="bla">, tu n'écris jamais <xsl:template xsl:match="bla"> (même si c'est correct). Donc, la réalité est exactement le contraire de ce que tu dis, à savoir 90% des attributs sont dans l'espace de noms propre à l'élément et pas dans le même espace de noms que l'élément (STP, lis bien ma phrase avant de répondre).A part Xlink et Xpointer, je ne vois d'ailleurs pas beaucoup d'utilisation d'attributs dans un élément avec un espace de noms qui n'est pas celui propre à l'élément.

Ok, donc non seulement tu ne lis pas les articles avant de les critiquer, mais en plus soit tu es idiot, soit tu ne sais pas parler français (les deux est une bonne réponse).

Histoire de préciser les choses, ton premier post dit clairement que l'article n'a surement aucun intérêt car il doit comporter l'argument contre XSLT qui est qu'on pourrait distribuer directement du XSL:FO et donc se passer d'XSLT. Or, l'auteur de l'article dit exactement le contraire, à savoir que le défaut de XSLT est justement de permettre et même d'inciter à distribuer directement du XSL:FO, c'est-à-dire un contenu qui n'a d'XML que la syntaxe et le nom, mais qui a perdu l'essentiel, à savoir la sémantique.

Ton dialogue à la Didier Deschamps résume effectivement notre dialogue. Ce qui est incroyable, c'est que tu ne te rendes pas compte que tu racontes n'importe quoi.

Je me demande pourquoi je continue à te répondre.