tene a écrit 407 commentaires

Parce que ça ne change rien au problème:
- soit ton appel au callback est mis dans une file jusqu'à ce que ton app veuille bien s'en occuper [ce qui revient à un message].
- soit tu risques de foutre en l'air tes données... (tu es en train de calculer quoi afficher, hop en plein milieu on te coupe et on te demande d'afficher...). [note: cela revient à un thread éventuellement non interruptible!].

La solution utilisée en général (sous Win32, je suppose que c'est pareil sous X, si qq peut confirmer?) est de faire "à la main" un double buffering: lors du paint on ne fait que blitter sa surface, lors du calcul on crée cette surface... ça pose un problème à gérer: l'intervalle de temps entre la mise à jour de la surface (on vire l'ancienne, on la remplace par la nouvelle, à ce moment précis, un paint peut foirer). Il faut donc, le protéger grâce au mécanismes de synchro qui vont bien... Autre solution: puisque ce mécanisme est nécessaire, que son algo est très général... pourquoi ne pas l'intégrer dans l'"OS" (X, Win32, ...)? et par la même occasion profiter des 128Mo de mémoire que l'on trouve sur certaines cartes graphiques...? Et même pourquoi pas du dernier effet de la mort qui tue présent sur la GeForce Radeon FX 9800?

Déjà quand je vois ce que la transparence ralentit les systèmes ... pour moi une interface graphique doit offrir une réactivité élevée et je trouve que ça disparaît de plus en plus. Regarde l'occupation CPU des vidéos, c'est ça le point important, c'est ça une démo technologique! Il est évident qu'intégrer des fenêtres en train de tourner est ridicule, et ne fait que rendre l'application encore plus inutilisable... Par contre c'est le fait de pouvoir intégrer ce genre d'effet dans Windows en profitant des cartes 3D.... Vous ne trouvez pas qu'on est à un stade un peu ridicule: un desktop 2D, relativement lent et limité, tournant grâce à une carte 3D de plus en plus rapide et avancée? Vouloir prendre une partie de la puissance de la carte 3D pour le desktop, c'est amha une bonne chose. Cependant, les applications réelles de ce truc risquent d'être peu visible: on va pouvoir penser une GUI différement, sans tenir compte des limites actuelles (promener une fenêtre sur l'écran ne sera plus aussi coûteux: déplacer un peu une fenêtre sur votre bureau, avec quelques applications: boum l'occupation CPU grimpe: avec un système de composition ça ne devrait plus être le cas...) mais ça ne va pas amha, révolutionner immédiatement la façon dont seront dessiner les GUI. On pourra juste "faire plus avec moins"... ps: si seulement j'avais les connaissances, les capacités et le temps de me lancer dans Fresco, ça me ferait trop plaisir que "Linux" soit largement en avance sur Windows sur ce point ;)

Pour installer XP: dossier DEPLOY sur le cd d'install, quelques petits outils sympathique pour automatiser complètement l'installation de windows et de ses drivers. (en gros, niveau particulier, ça donne: je me fais ma disquette, je tape le cd dedans, j'allume, je vais faire un tour/boire un café/etc... je reviens c'est installé). L'install m'a pri 22 minutes, la préparation (une fois pour toutes les install), 15 minutes. Ceci dit, une fois qu'on a RIEN à fournir durant l'install, que ça prenne 20 minutes de plus ou de moins est moins crucial... si par contre toutes les 4 minutes on doit cliquer sur suivant...

En cherchant plus loin, avec les installation Windows Installer (MSI) et certaines autre y'a moyen d'automatiser toutes l'install, mais pour ça il faut reconnaitre que le temps de configuration et de préparation (et de lecture de doc) est trop important pour que ce soit réellement intérresssant pour une machine.

Ceci dit, le problème est de savoir quoi installer, Office? Visual Studio? MSDN? Photoshop? encore d'autre produit? combien de petit utilitaire? etc... parce que là on peut ajouter entre 20 minutes sans reboot et des jours avec plein de reboot...

Ceci dit, un XP/2000 ou même un NT ne se réinstalle pas comme un 9x, on peut presque toujours s'en sortir sans réinstallation. (Personnellement je n'ai installé XP que 2 fois: le passage de la rc3 à la RTM, et il y'a quelques temps quand j'ai changé de machine). Attention! je sais que c'est également le cas de Linux (on peut même le réinstaller moins souvent, ne pas réinstaller en cas de changements de machine peut être tenter).

Concernant les kazaa (enfin les merdes installé par kazaa), adaware s'en occupe pas mal, il y'a également souvent moyen de s'en sortir en créant un nouveau compte à côté du sien.

Euh, c'est moi ou ça ne veut rien dire ta phrase?...

Un truc qui ne tourne que sur un système payant ne peut en aucun cas être considéré comme réellement gratuit ...

C'est profond ce que tu dis... tu le paies pas ton PC?

[-1]

Et alors ? Le fait est que les JVM Java performantes ont un JIT, je ne vois pas l'intérêt de cet argument foireux.

Simplement si tu sais que ton code est destiné à être optimisé par un JIT, selon la plate-forme, tu ne ponds pas la même chose... tu trouves cela si compliqué et foireux à comprendre? Tu vas par exemple t'arranger pour qu'il prenne moins de place, au prix d'une éventuelle lenteur (tu connais le trade off classique vitesse/taille dans les compilos C/C++, bah c'est le même genre...). L'optique n'est donc pas la même, par exemple java sera plus adapté si tu n'as pas le temps ou la mémoire pour compiler ton code...

Je te rappelle que le point de départ est simplement de comprendre que .NET et java, c'est pas exactement la même chose... le fait que .NET soit déstiné à un JIT ne le rend pas absoluement meilleurs, personne n'a dit cela...

D'autre part, si on veut parler de .NET lui même, effectivement, on peut programmer en .NET dans d'autres langages que le C#, mais on reste dans le monde .NET. Avec J2EE, on parle CORBA, RMI et web services, ce qui permet d'être interopérable avec d'autres plate-formes. Tant qu'à faire à comparer tout et n'importe quoi, autant y aller fort !

Tout d'abord, dis moi ce que tu veux prouver... ensuite te rends tu compte que t'es en train de dire que java c'est mieux parce qu'il est interropérable, et qu'à ce niveau, grâce au support du natif (.NET ne tourne pas sur une machine virtuelle au sens strict) dans .NET il est largement devant java... (tu as non seulement COM/COM+ mais également et directement, l'appel de fonction externe, le fait que tu puisses créer des attributes personnalisé te permet même d'ajouter le support de virtuellement tout ce que tu veux? corba par exemple...).
As-tu déjà jouer avec .NET ou alors le seul truc que tu connais est l'url que tu m'as donné (l'url foire, mais bon)? Tu as déjà regarder comment développer un webservice en C#? Pour ma part, j'ai programmé, et je programme encore en java (swing, corba, web application) et je suis en train de découvrir .NET (via le C# essentiellement, si tu veux voir à quoi ressemble mes test: www.myoe.org)... avant cela, je développais essentiellement en C++.

Concernant les delegates: non le concept d'interface et de classe anonyme ne le remplace pas totalement, ou en tous cas pas directement, tu pourrais implémenter un équivalent en java (ça a peut être déjà été fait, perso, je me suis intéressé au implémentation C++), mais le fonctionnement de la sorte est avantageux... tu as joué avec swing? avec winforms? tu ne trouvais pas des avantages à l'approche de .NET?... Enfin si tu t'intéresses au C# (tu me parles bien du langage java), ce qui est surtout pratique, c'est le sucre syntaxique associé... (j'ai 10 boutons sur une fenêtre, faisant 10 actions différentes, ces actions doivent être également faisable depuis n'importe quel endroit de mon code, et même si l'IHM n'est pas visible... comment tu fais avec des interfaces, et comment tu fais avec des delegates... tu as une classe POPConnection allant chercher des mails sur un serveur, dans différents endroits de ton IHM tu veux afficher une info de progression, tu fais comment le tout en java, en C#, lequel est le plus direct?).

Et enfin, ton argument c'est quoi? me dire que .NET/C# c'est la même chose que java, parce que dans l'avenir java va ajouter les choses que j'ai cité à son langage? tu te sens pas un peu ridicule? MultiDeskOS c'est mieux que Linux parce que dans l'avenir va y'avoir plein de truc dans MultiDeskOS... ;)

Ourch, comme argument leger celui la il se pose en maitre.

Relis ma phrase.

L'assembleur java, par exemple, est un veritable regal avec ses 255 registres.

Et moi qui croyais que la JVM était basé (tout comme .NET) sur une pile... (http://www.javaworld.com/javaworld/jw-06-1996/jw-06-vm-p2.html(...) )

je ne suis pas vraiment sur que l'on puisse en donner uen vainqueur aussi facilement.

Un vainqueur? qui a parlé de vainqueur? nous n'avons même pas parler de besoin...

C'est le même langage ! Les différences entre C# et Java sont plus que minimies, je dirais même pas 10%. Qualifier C# de plus agréable est grotesque.

Properties, delegates, surcharges des opérateurs et surtout attributes, tu es sur d'avoir fait du C#?... [note: j'oublie surement quelques détails, mais ce sont les principaux je pense...]

Pourquoi, il n'y a pas de JIT dans les JVM Java ?

Java a été conçu pour tourner avec ou sans JIT, .NET ne fonctionne qu'avec un JIT...

Formidable. Il y a littéralement des centaines de langages qui tournent sur la JVM Java.

Le bytecode java... s'appelle le bytecode java... ça te donne une idée? sérieusement, le bytecode java a été pensé pour java, pas pour permettre à plusieurs langage de l'utiliser... .NET n'a pas été conçu de la sorte, c'est même parfois légèrement pénalisant pour le C#.

Tu te rends comptes que t'es en train, entre autre divagation (mozilla n'est pas un clone, java n'est pas utilisé, tous les langages sont très mauvais, IIS/ASP n'existera bientôt plus, ...) de comparer .NET à QT/GTK?... compare à la limite winforms à Qt/GTK, pas à tous .NET...

plus complexe je dirais pas, différent oui, mais bon vouloir garder tous ses réflexes du C++ dans un environnement totalement différent, faut pas rêver...

Je croyais que tu avais des points particulier à reprocher au C++ managé, par rapport aux autres langages .NET...

Tu n'as pas compris de traviole, tu peux faire tourner du code .NET sans le recompiler sous ms.net ou mono.net... mais comme j'essaie de le dire, .NET permet d'utiliser facilement des composant "non managé", et ça c'est absolument pas portable... (un racourci à la hache: winforms est un wrapper pour le toolkit windows...) en bref, quand tu développeras, ce sera "un peu comme en C", tu peux faire du portable, mais faudra alors s'arranger pour n'utiliser que des composants portables... (ceci dit, le prob se pose même en java...). Donc dans le meilleurs des cas, on a .NET tous portable, ou on l'a pas, et alors, on se retrouve avec: "on aura le même langage, les mêmes classes de bases, les mêmes réflexes, la possibilité de faire une application riche et portable si nécessaire (avec Gtk# par exemple), ". Ceci dit, pour plus d'informations, je te conseille la poubelle microsoft (http://msdn.microsoft.com) ou le site de mono (http://go-mono.com).

Quand au portage eventuel, c'est niet etant donné qu'il n'y a aucune ouverture du code envisagé ! http://msdn.microsoft.com/msdnmag/issues/02/07/SharedSourceCLI/default.aspx sans spec détaillée de l'ensemble des élements ! http://msdn.microsoft.com/library cherche, tu vas trouver...

Que reproches-tu au managed C++?

Pas vraiment. En .NET tu développes en C#, rien d'autre.

???

Tu as de base: J# (un simili java), C#, C++ et VB.NET il offre tous les mêmes possibilité, attention cependant le C++ n'est pas du C++ "pur", ils ont du ajouté quelques fonctionnalité, et modifier certains comportement du au Garbage Collector.

Tu as aussi d'autre langage Eiffel.NET par exemple, bientôt Delphi.NET... et même une tentative de python.NET...

Le fait que la spec de .Net appartienne entièrement à Microsoft est déjà un gros problème pour Mono car lorsque de nouvelles version sortiront, la plate-forme de Microsoft implémentera déjà la spec alors que Mono devra l'implémenter.

Les spec .NET 1.1 sont là depuis un moment, .NET 1.1 est sorti y'a 2 quelques semaines...

L'amélioration des iterator est déjà présente dans Mono, microsoft compte ajouter cette fonctionnalité en 2004/2005...

J'ai l'impression que la réalité contredis tes craintes, que je trouve des craintes justifiées, mais d'un autre côté:
- tant que mono n'est pas équivalent (ou supérieur) à .NET, ms a plutôt intéret à ne rien empêcher: ce n'est pas un concurrent dangereux, mais ça fait parler de .NET.
- .NET est un produit commercial, déjà en production sur certains sites, ms n'a donc plus la possibilité de changer du tout au tout... regarde l'évolution de l'API Win32: des choses ont étés ajoutées, mais pratiquement, peu de développeurs les utilisent: faut que ça reste compatible avec tous les windows... à terme, y'aura je pense le même effet sur .NET...
- Même si ms modifie toutes les semaines ses classes, comme il doit aussi rester compatible avec l'existant, tu feras tourner une appli mono.NET sur ms.NET... faudra comme toujours (même en java), ne pas utiliser de fonctionnalité spécifique.

Lorsque je lis ça je me demande à quel point Mono sera efficace sous Linux et si l'on ne cherche pas la compatibilité avec .Net pourquoi ne pas sortir un framework inspiré de .Net mais qui ne reprenne pas ce qui est clairement trop lié à Windows.

En fait, je vois cela d'une façon un peu différente: il y'a portabilité et possibilité de portabilité... visiblement mono tente de calquer sur ms pour ce qui va bien, ce qui permet d'être portable, même leur but n'est pas d'exécuter des programmes ms.NET (ce n'est pas wine!). Ce qui je trouve est une attitude intelligente: on aura le même langage, les mêmes classes de bases, les mêmes réflexes, la possibilité de faire une application riche et portable si nécessaire (avec Gtk# par exemple), la facilité d'interraction avec des assembly non portable (ce que java ne propose pas vraiment, utiliser du natif n'est pas trivial), tous cela sans être contraint dans un moule type vm java.

Niveau perf, je n'en sais pas plus, je suis déjà en train de ramer pour évaluer les perfs de ms.NET, pour celle de mono, j'attendrai un peu ;-)

Si je te suis bien, le manque d'ouverture du code par MS indique qu'ils n'ont pas pensé leur truc en termes de portabilité.

Non je n'ai pas voulu faire un tel lien entre les deux (parce que source ne veut pas dire portable... spec non plus d'ailleurs, mais c'est souvent plus simple avec...).

Quand je parle de ne pas vouloir en faire un truc portable, je pars de mon expérience personnelle (je suis en train de tester C#/.NET sous windows): MSDN (la doc http://msdn.microsoft.com(...)) parle très peu de portabilité, rotor contient peu de code (ce qui empêche d'affirmer que .NET est portable, ça ne veut pas dire que c'est impossible!), mais surout, en regardant la série de classe de .NET. Un programmer Win32 s'y retrouve très vite parce qu'il y retrouve un gout de Win32, plus dans certaines parties que dans d'autre:
- les thread sont géré "à la windows", c'est d'ailleurs un gros problème que mono a rencontré, ce n'est pas apparent, mais ça a du être chaud! (ainsi que tous les objets systèmes).
- winforms est mappé sur Win32, boucle de message, owner draw, style, etc... on y retrouve tout, alors que X utilise un modèle relativement différent!
- tous le remoting est basé sur COM+.
- ...

Ca permet à .NET d'être plus "rapide" que java, ils ne sont pas parti des mêms bases et avec les mêms contraintes: ms a pris le plus petit dénominateur commun de ses propres OS (et encore en droppant Windows 95) par contre il a voulu conservé l'existant et supporté plusieurs langages, Sun a du jouer avec son OS ainsi que tous les autres mais a pu se concentrer sur un seul nouveau langage... je crois que .NET est bien pour un programmeur Win32 et que Java reste l'une des seules solutions pour faire un truc portable... si .NET existe sous linux, même sans être 100% portable (ceci dit, rien n'est 100% portable, même en java, il faut programmer "correctement" si on veut de la portabilité, et certaines choses posent toujours des prob...) il peut amha offrir une nouvelle façon de programmer au développeur linux (certains aimeront, d'autre pas, ça donne plus de choix!).

L'Api de M$ ne poura pas être porter vers GNU/Linux.

http://www.go-mono.com/class-status.html(...)

Certaine partie pose problème, d'autre fonctionne déjà très bien... (ASP.NET est pas mal avancé parait il...).

(Manipulation de droits sur les fichiers qui dépendent du type de partition

Le problème se pose sous Win32: pas joué avec les droits sur du fat, etc... ensuite, faire un outil d'administration de système de fichier portable, y'a comme un truc qui m'échape ;-)

, Manipulation de la base de registre,

Ne fait pas partie du framework.

Fonctionnement graphique comme la systray, etc... )

Visiblement c'est en cours, ceci dit, dans ce genre de truc la question n'est pas si ça va fonctionner ou pas, mais comment représenter une fonctionnalité analogue (et si c'est utile), sous Win32 la systray (qui officiellement s'appelle zone de notification) est très souvent mal utilisé, en principe elle n'existe que pour prévenir d'un évenement (connexion d'un périphérique USB, connexion à internet, déconnexion, etc...), sous gnome et kde (et bcp d'autre, mais ce sont les premiers qui me viennent à l'esprit quand on parle linux et desktop) tu peux avoir une fonctionnalité équivalente... et c'est là que ça peut devenir intéressant: permettre de faire qqch en tenant compte du système utilisé...

Enfin, avis perso, même si .NET n'est jamais compatible entre mono et microsoft, si mono fourni une implémentation performante de .NET, ça restera sympathique, même pour faire des programmes absoluement non portable (non portable sous windows s'entend!).

Sans jouer sur les APIs il serait très facile à Microsoft de modifier l'implémentation de sa plate-forme .Net pour dégrader les performances lorsqu'elle dialogue avec un système non Microsoft (en utilisant un protocole de communication non-standard par exemple). Ainsi il serait très très facile à un commercial de démontrer la supériorité d'une solution tout Microsoft (vous voyez, il a suffit de remplacer votre serveur Linux par un NT2003 pour que les clients ne rament plus).

??? t'es en train de nous expliquer que si ms (ou n'importe qui) fait un truc fermé sans spécification, ça communiquera pas facilement avec l'extérieur... tu le sais, je le sais, on le sait tous... mais euh... rapport?

On parle d'implémentation une API (une API est par définition une interface), ce que ms peut faire c'est rajouter quelques classes et quelques méthodes qui vont bien dans son framework histoire de l'avantager par rapport au reste... (ce que Mono fait déjà, leur implémentation du framework contient certaines améliorations par rapport à celui de ms ... ainsi qu'une implémentation des itérateurs en avance sur le planning ms...).

Personnellement je vois .NET comme une façon pour microsoft de nettoyer son bordel, de le rendre plus cohérent, effiace et facile d'emploi... le C# contient quelques concepts intéressant (delegates, attributes, foreach) bien que peu novateurs, .NET apporte certaines choses sympathique dans son framework et dans ses idées... Mono tente d'avoir tous cela en libre, que vouloir de plus? si c'est mauvais, on l'utilise pas, si c'est bon, ça fait un moyen de plus de développer...

Concernant la portabilité, ms en parle très peu, et c'tait pas vraiment le concept de base de .NET... ils n'ont visiblement pas tout fait pour que ce ne soit pas portable, mais ils ne font pas grand chose pour... il y a bien rotor l'implémentation "shared source" du CLI, mais les parties réellement "intéressantes" n'y sont pas (winforms, ASP.NET, ADO.NET, ...).

Ben si. Si le moteur physique ou l'IA ne suivent pas, les FPS tombent à la ramasse. Les jeux ne s'amusent pas à faire tourner les différentes tâches de façon asynchrone et parallèle :

Disons plutôt que de toute façon avec un CPU, tu auras une seule des taches à la fois... par contre, rien n'empêche ton moteur de ne faire une passe IA/réseau/whatever qu'une fois toutes les n frames...

les différents calculs sont menés les uns après les autres et toujours dans le même ordre. Si les CPUs sont testés avec les mêmes cartes graphiques, et que les résultats sont différents, c'est bien que la différence a une signification.

La question est plutôt: parmis ces différences qu'est ce qui est du à:
- la carte graphique
- le cpu
- le cache
- la mémoire
- la carte mère
- ...

Si tu testes un pentium 4 à différente fréquences, on est d'accord, si tu testes le truc face à un AMD, ça devient plus tordu... le problème est comme toujours de savoir ce que l'on teste...

C'est toujours le cas. Ils ont plus mais ils veulent faire plus. Un moteur d'IA ou de physique, c'est pas automatiquement rapide sur les machines actuelles.

Je n'ai pas dit cela... mais regarde combien de jeux utilises les pixel et vertex shader de ta carte, combien de jeux sont optimisés pour un cpu particulier (MMX, SSE, SSE2, 3DNow, etc...). Je ne suis pas en train de dire: bouh les mauvais, sont nuls... mais juste que la tendance a changer et que donc, je n'utiliserais pas cela comme bench pour un CPU...

Un autre fait: la plupart des jeux utilises D3D ou OpenGL, ce qui a un coup (qui se veut le plus léger possible) sur les perfs... ça ne chagrine personne, on augmente le système de requis, on joue avec ça, et hop!

Tu rigoles ? Sur un jeu moderne (type Unreal Tournament), le CPU est aussi important que la carte vidéo : calculs 3D (la carte ne fait que de la "fausse 3D", ou 2D avec correction de profondeur), moteur physique, IA, réseau, gestion du jeu.... Un jeu, ce n'est pas une démo qui envoie des triangles précalculés sur le bus AGP... ;)

100% d'accord, MAIS je te parle de faire un benchmark basé sur un jeu 3D (je te rappelle qu'il utilise le FPS pour cela...) pour évaluer le CPU. La carte 3D faisant de plus en plus, en ce qui concerne le graphisme, je ne trouve pas que cela soit une mesure convaincante, ton cpu passe une partie de plus en plus importante sur l'IA, le réseau, le moteur physique, etc... ce qui a une influence moins directe sur le FPS, pendant que la carte graphique fait de plus son boulot presque "en parallèle" au CPU... Tu n'es pas convaincu? regarde le simple bon que tu observes en changeant les drivers de ta carte écran de version en version...

Et enfin je persiste, en dehors de quelques rares jeux, les développeurs optimise de moins en moins leur jeux, il y'a quelques années les développeurs étaient "en avance" sur le hardware, ils devaient faire ce qu'ils pouvaient avec ce qu'ils avaient... maintenant la tendance s'inverse (qui connait un jeu utilisant vraiment les pixel et vertex shader? genre pas pour rajouter un effet flote en fin de développement...?).

J'ajoute, parce que sauf erreur de ma part, on en pas encore parlé, qu'un facteur peut-être important est le bruit! Avec un Athlon, tu te retrouves vite à foutre un gros ventilo rapide, ainsi qu'une boite plus ventilée... Et si tu vas dans le silencieux, faut vite payer "cher" (relativement cher, tu paies ton CPU 70 euros, et tu dois débourser quelques dizaines d'euros en plus pour le refroidir correctement).

Avec le P4, le ventilo vient avec, il chauffe moins, et pour la boite, tu peux en trouver une très silencieuse pour à peine plus cher... (cette boite est évidemment valable pour les Athlon, mais avoir une boite silencieuse avec un "cpu qui fait du bruit", pas top).

Niveau perf cependant, les débats sont je trouve souvent biaisés: on va comparer les CPU sur un 3DMark (qui teste plus la carte 3D qu'autre chose), ou sur des jeux utilisant la 3D, mais tenant de moins en moins compte du CPU... (fini le temps des optimisations).

Est-ce qu'une solution ne serait pas plutôt, comme c'tait le cas avec dacode de permettre l'affichage des commentaires avec votes négatifs?...

Perso, j'ai toujours trouvé le système de vote assez mal foutu (pas sur linuxfr, sur tous les sites proposant ce genre de chose), on poste un commentaire idiot/troll/faux/controversé/ininterressant/... on se tape un score négatif, normal, ça nettoie, c'est bien... le suivant poste un commentaire dessus pour expliquer pq c'est idiot/troll/faux/controversé/ininterressant/... il se tape des [+] (logique aussi), résultat: on a un thread avec des trous, toujours aussi emmerdant à lire, difficile à comprendre... amha, une solution serait, dans un premier temps: un commentaire posté négativement n'apparait pas *ainsi que tous ses enfants* (on pourrait éventuellement fixé que si son score est supérieur à k>0, alors il est visible...). Ca a amha deux avantages: plus propre, si le thread dévie de sujet, on aura tendance à en commencer un nouveau à côté, on aura donc plus facilement une relation "un thread == un sujet de discussion".

Mais comme l'on dit certains, je crois que le mieux serait de pouvoir voter et classer les commentaires (troll, off-topic, etc...) un peu à la façon slashdot, et absolument (sinon ça n'a aucun intéret!) pouvoir les filtrer (sur le score et la catégorie).

Enfin tant que je suis dans les suggestions: je développe un client mail/news (GPL, mais sous Windows, linux a assez, je trouve, de bon client mail/news) et j'en suis arrivé à la conclusion qu'un affichage pratique pour les newsgroup était:
- n'afficher que les thread avec des messages non lus (avec évidemment une option pour afficher le tout).
- raccourci la longueur des threads ne contenant que les derniers fils non lu (avec un "..." à la racine un click fait réapparaitre les parents).

Peut-être serait-il bien d'envisager quelque chose du genre?

Personnellement, mais je me rend compte que ça peut poser problème à certain utilisateur utilisant des browser ne supportant pas le javascript/DHTML, je serait pour faire un truc plus "dynamique" par exemple cliquer sur le [+] n'ouvrirait pas une nouvelle fenêtre avec le message scoré négativement, mais le "déroulerait directement". Ca impose de charger tous les messages, mais j'ai l'impression que finalement peu de message sont scorés négativement (ça part souvent d'une racine négative, suivi d'un paquet de réponse positive avec parfois quelques commentaires du posteurs initial scorés de façon négative). Par contre ce serait bcp plus rapide et clair à utiliser... on pourrait rapidement éliminer un thread qui ne nous concerne pas, etc...

Et est-ce que j'ose? allez oui, je m'étonne en fait qu'un site web parlant de logiciel libre, d'ouverture d'esprit, de respect de la vie privée, etc... enfin bref, de nos libertés aie une structure aussi fermée... pourquoi ne pas faire un système de vote (poll)?

Voilà, c'tait un message, histoire d'être sûr de pouvoir scoré négativement pour les deux prochaines semaines tous ceux qui ose prétendre que l'Amiga n'est pas la meilleure machine de l'univers! ;)

ps: certaines personnes parelent d'envoyer un patch, je suis à la fois d'accord (y'a pas de raison que les admins du site doivent toujours tout faire!) et pas d'accord, je m'explique... s'il s'agit de corriger un truc sans en changer le comportement (le fait qu'un . final dans une url soit repris dedans par exemple), le patch marche très bien! si par contre il s'agit de changer le comportement du site (vote, XP, affichage, etc...), ça ne marche plus comme ça, il faut avoir amha, un plan de développement, un minimum d'organisation: ce que linuxfr veut avoir, ce qu'il faut développer, est-ce que qq s'en charge, etc... personnellement, je ne me sens pas assez motivé pour commencer à coder une fonctionnalité si je n'ai pas une certaine garantie sur le fait que cette fonctionnalité intéresse quelqu'un et sur le fait que le fruit de mon développement sera intégré au site...

Il ne faut jamais oublier une chose : le multimedia c'est LA CLEF pour investir le desktop !!

Il ne faut pas oublier, le multimédia ça veut tout et rien dire à la fois... (y'a quelques années, c'tait mutlimedia, puis convivial, un chtit passage par "internet", maintenant c'est un peu plus dispersé il me semble, XML/WebService/Savon, user experience, etc...).

Enfin...

Bon je résiste pas, vous me faites tous marrer, lisez vos contrats d'assurance, vos contrats de logements, n'importe quoi, même le mode d'emploi de votre shampoing... avec vos connaissances en droits, vous allez vite en arrivez à la parano extrème...

Cette clause permet de faire fonctionner la product activation de windows... ce qui si tu es dans un cadre légal ne pose pas de problème... ça fait partie d'un des nombreux trucs qu'on rajoute dans un contrat, non pas pour s'attribuer des droits (ça ne marche pas comme cela), mais pour se protéger... [la raison est simple: l'utilisateur est censé lire son contrat avant d'installer, ce que personne ne fait, il doit donc être au courant, que ms va vouloir activer son produit...]

Relisez un peu les textes sur les droits des contrats, ça doit pas être si différent que cela en France... se taper un délire sur billou venant fouillez votre pc quand vous êtes en plein petit-déjeuner, d'accord c'est marrant... mais c'est du n'importe quoi.

Enfin Erwan, sache que si tu pirates, microsoft ou pas, cluf t'interdisant (d'après une interpretation aussi hasardeuse que celles de ce threads) de posséder des nounours en peluche rose ou pas, tu es en tort et donc condamnable... Ca c'est la loi de ton pays, indépendant d'un quelconque autre contrat de licence... et la loi de ton pays dit aussi qu'un contrat ne peut passer outre tes lois...

NOTE: la licence de lecture de ce post m'autorise à ponctionner 50 euros par mois sur votre compte en banque, ainsi que fouiller votre frigo à la recherche de bouffe à n'importe quel heure de la nuit. En lisant ce post vous acceptez cette licence ;-).

Nous sommes d'accord, mais je ne voudrais que les gens fassent l'amalgame XML=lisible=utilisable (par tout le monde).
Je changerai juste l'expression du 'vrai' XML en XML comme il faudrait qu'il soit

Le prob, c'est que c'est quoi... du "XML comme il faudrait" qu'il soit? un truc respectant une spécification pré-établie (avant même l'existance de l'application...), et donc ne s'adaptant pas du tout avec l'application qu'il utilise? (un peu comme le HTML, on fait les spécifs, les browsers doivent s'adapter après, le format n'est pas mauvais en soit, en lecture c'est même pas mauvais, mais il n'existe pas d'éditeur réellement performant avec... il s'en tire plus ou moins bien, pondent de l'HTML plus ou moins bon... mais se ramasse tous plus ou moins la gueule quand il s'agit de l'importer pour édition... il perde de l'info, ou foutent en l'air certaines choses... ce qui n'est pas admissible pour un traitement de texte). Ou alors un format pratiquement directement mappé sur les structures de données internes, ce qui permet plus de vitesse, un développement plus rapide.... mais donne aussi un format plus crasse... Rajoute à cela les problèmes d'extensibilité, de version, de langue, tout ce qui rend un rendu identique sur plusieurs support difficile (les polices, la façon de traiter tel ou tel périphérique, etc...), et je crois que là, on commence à voir le début du problème...

Le format d'OO.org (ou d'autre) est-il meilleurs? faudra voir à l'utilisation! mais en apprenant qu'il n'existe pas de visionneur et que ce n'est pas simple à faire, on peut déjà se dire que ce n'est pas le format idéal... (et au vu de ce que pond Word, ce n'est pas non plus idéal...).

Ca fait d'ailleurs partie des éternels tradeoff en informatique: simplicité/souplesse/fonctionnalité/puissance/rapidité/...

ps: rapport avec trusted?... là je crois qu'on s'approche de l'amalgame DRM/TCPA/PALLADIUM/... et qu'on s'éloigne du sujet...