A mon avis il n'est pas nécéssaire de connaitre les détails du protocol TCP pour utiliser les api socket...
Ou pour garder ta métaphore, il n'est pas nécéssaire de connaître le chinois pour pouvoir utiliser le traducteur Français/Chinois et communiquer avec un Chinois.
Et là je parle en connaissance de cause, j'ai passé deux heures a discuter avec une amie coréene de mon ex, je ne connais absolument pas le coréen et elle ne connaissait pas le français, mais avec babelfish on a pus communiquer (malgrer la pietre qualitée des traduction et le fait que mon anglais avait du mal à être digéré par le traducteur...)
l'interet ici est de ne pas refaire un dump complet, mais juste des modifications depuis le dernier dump, et (à ma connaissance en tout cas) l'outil dump de ext3 ne le fait pas, pour la simple et bonne raison qu'il ne connait que la version courante.
L'idée globale c'est que le BIOS n'accepte de lancer que un bootloader certifié. Ce même bootloader, pour avoir la certification, n'a le droit a son tour que de booter un OS certifié. Un l'OS ne peux être certifié que si il ne lance que des applications certifiées.
Et une application certifiée , par exemple ne lit un dvd en haute qualitée que si toute la chaine jusqu'a l'ecran est certifiée.
Quand à l'EFI, je ne connais pas tous les détails, mais je suppose que ca doit faciliter la mise en place de ce genre de systèmes. Mais bon j'ai pas encore eu le temps d'aller vraiment me reseigner dessus, donc je laisse la parole a ceux qui connaissent.
Il y a beaucoup de bot basé sur GnuGo qui trainent sur KGS. Tous ne sont pas classé, et ceux qui le sont, n'ont pas tous le même classement.
Le classement dépend de la version utilisée, la dernière stable de GnuGo, la 3.6, date quand même de fin 2004. Donc beaucoup de joueur qui mettent en place des bots utilisent une version de dévelopement. Mais comme c'est du developement et que chacun ne récupère pas la même révision, il y a pas mal de différences.
Ensuite il y a la configuration qui influe énormément sur le niveau de jeu. Il y a plein de paramètres à tuner pour obtenir le meilleur de GnuGo. Les paramètres par défaut ne sont pas forcément les meilleurs, mais surtout des petits changements dans les paramètres peuvent influer sur la manière globale de jouer de GnuGo, et donc perturber un adversaire qui chercherait à exploiter les faiblesse classique. Mais en modifiant trop certains paramètres on obtient l'éffet inverse, GnuGo est capable de devenir une vrai merde si on lui demande gentillement...
Bref tout ça pour dire que le niveau de GnuGo varie énormément d'un bot à l'autre sur KGS et que c'est parfaitement normal. Les meilleurs bots utilisant le moteur de GnuGo sont actuellement 7-8kyu c'est une constatation.
Alors comment expliquer qu'un joueur 13kyu batte régulièrement un bot 7-8kyu :
- 1ère possibilité, tu utilise une version plus vielle de GnuGo, qui à énormément évolué depuis,
- 2ème possibilité, tu connais les faiblesses de GnuGo, ce qui n'est pas le cas de la majoritée des joueurs qui jouent avec lui sur KGS, donc sont niveau KGS ne reflète pas sont niveau face à joueur qui le connait bien,
- 3ème possibilité, tu était 13kyu avant fin septembre 2006 date à laquelle l'échelle des niveau de KGS à été modifiée. Avec cette modification les joueurs 13kyu on gagner en gros 4kyu, donc tu te serrai retrouver 9kyu. Cette modification à été fait pour compenser la dérive de l'échelle de KGS et pour rapprocher l'échelle de KGS des échelles nationale.
En combinant les trois on arrive a une victoire faicle de ta pars contre GnuGo...
D'après ses résultats sur kgs,il semblerait que gnugo soit plus proches de 7-8kyu actuellement.
Le problème est que les classement des différents serveurs et échelles nationnales ne sont pas vraiment comparables.
Qu'oi qu'il en soit je suis actuellement 2dan amateur sur kgs, et je donne sans problèmes 13 pierres d'avance à gnugo. La partie deviens sérée a 17 pierres, mais j'ai l'avantage sur gnugo que je connais ses faiblesses et je peux provoquer des situations ou je sais qu'il va se planter.
Pour la petite histoire, un ami à voulut une fois tester gnugo à l'aveugle et sans que je le sache ma fait jouer plusieurs parties à handicap contre lui. Il a créé un compte humain et jouait les coups que gnugo lui indiquait.
Les deux premières parties ont étée beaucoup plus sérée que mes parties habituelles de l'époque contre gnugo, mais à la troisième j'ai finit par repérer le style de gnugo et l'écraser.
Preuve que l'écart de niveau viens aussi de l'exploitation des grosse faiblesses de ces programme.
Ces pour quoi, à mon avis il y a deux choses à amméliorer dans les programmes actuels, ils doivent continuer leurs progrès, ce qui est la voie actuelle. Mais il est aussi nécéssaire de comprendre leurs faiblesses et de les corriger.
La deuxième voie est plus ingrate puisqu'il y a peu de progès visible imédiatement, mais permet d'obtenir un niveau plus stable sur le long terme.
Si mes souvenirs sont bon, lorsque les premiers programmes d'échec on commencé à battre les meilleurs humains, ils ne le faisait que sur les premières parties. Sur un nombre plus importants de parties l'humain sortait victorieux.
Je fais de la photo et ce qui me gène le plus dans le rendu photréaliste c'est que justement on fait souvent facilement la différence avec une photo car le rendu est trop parfait...
Il n'y a jamais (ou presque) le moindre détail qui cloche au sens photographique du terme. Pas la moindre poussière qui traine, les objets sont parfaitement alignés, tout est super propre et brillant.
Pour faire des images qui ressemble à de vrai photos, à mon avis, c'est la dessus qu'il va falloir travailler.
Je ne dis pas que c'est image sont moches, bien au contraire je les trouve magnifique. Je suis un grand fan des images de Gilles Trans, mais je suis toujours un peu déçu quand je vois une image un peu trop parfaite qui aurrait pus ressembler à une photo si elle l'avait étée un peu moins.
nombre de fichiers partagés sur les serveurs x nombres d'utilisateur connectés sur les serveurs x prix moyen d'un contenu = perte minimum (il faut compter les échanges hors p2p)
A mon avis le principal problème est que sa petite boite, quand elle va arriver à l'étape de production de cartes bonnes pour la vente, elle ne pourra raisonnablement faire qu'une petite quantitée de cartes et les vendre comme elle pourra.
Les geeks fan de linux et de libre vont les acheter sur le net, ce qui va redonner un peu de sous à sa boite qui va donc pouvoir rembourser une partie du developement et produire une nouvelle série un peu plus grosse de cartes, et donc viser des marchés un peu plus étendus. Et ce cycle va se répéter jusqu'à ce qu'elle puisse raisonnablement produire des grosses séries de cartes donc avec un coût beaucoup plus faible puisque le prix à l'unitée baisse avec la quantitée et que les investissement auront été remboursés.
Et donc à ce moment là, la carte deviendra interressante au niveau du rapport qualitée/prix, c'est à dire une carte sans grosses prétentions mais à pas cher et avec la philosophie du libre en bonus.
Maintenant si le messieur il libère tout. Les gros fondeurs taiwanais vons pouvoir produire sa carte sans avoir à ammortir les couts de développement ni le prix d'une licence. Ce qui réduit le prix de la carte pour eux.
En plus, ils disposent déjà des usines toutes équipées pour ce genre de production, ils n'ont pas à passer par un intermédiaire, ce qui veux dire que les cartes sont encore moins chères.
Ils ont aussi un compte en banque qui leur permet de produire des grosse séries dès le début donc coûts minimum dès le début.
Et cerise sur le gateaux, mais à mon avis le plus important, ils sont déjà très présents sur le marché et ont donc tous les atoux en mains pour placer cette carte chez les gros acheteurs potentiels.
Donc si cette carte à un potentiel à grande échelle, pendant qu'avec sa petite sociétée il commencera à éssayer de vendre sa carte a un prix élevé (tout est relatif bien sur), à un publique très spécialisé de manière quasiment anonyme en éssayant tant bien que mal de rentrer dans ses frais, avec l'espoir de gagner suffisament d'argent pour produire la prochaine génération de carte.
Les taiwanais, eux, produirons la carte à grande échelle et la vendront en grosse quantitée, par exemple à des assembleurs de PC à bas prix.
Le seul marché sur lequels ils pourra rester dominant est celui des geeks libriste qui lui acheteront la sienne plus chère par solidaritée et conviction.
Le bilan c'est que si sa carte à un réel avenir et qu'il l'ouvre en totalitée, il mettra 20ans à réunir l'argent pour développer la génération suivante.
"le coût d'un logiciel est nul ou négligeable" En fait, ici ce qui est important c'est le cout de reproduction d'un logiciel qui est quasiment nul (en tout cas négligeable...) contrairement à son coût de développement qui peut être énorme, mais une fois développé, en faire 1000, 10000 ou 10000000 copies ne coute quasiment rien et est à la portée de quasiment tout le monde.
Pour un projet hardware tel que OGC, le cout de production de chaque exemplaire est éxorbitant au début et se réduit progressivement dans le temps. Et surtout ce coût de production n'est pas le même pour une petite boite qui sort son premier produit et une énorme boite qui est déjà entièrement équipée et qui à les relations pour vendre le produit en masse.
Remarques :
- j'ai volontairement éxagéré les deux scénarios, mais je ne pense trop me tromper si ça carte à un réel potentiel.
- je conditionne tout ceci sur le fait que la carte ait un réel potentiel, c'est-à-dire qu'il y ai réellement un public non-négligeable interresser par cette carte, c'est-à-dire suffisament important pour que les grosse boite investissent dedans.
Perdu, le système X-Black (et non pas X-Bright) de sony est bien un éclairage à base de led. Elle permet une excelente qualitée d'affichage, mais surtout une consomation beaucoup plus faible que les techniques classiques.
La meilleure preuve est que les premières version de cette techno avait un gros défault, un halo lumineux sur le bas de l'écran. En effet les led sont située en bas de l'écran et un système diffuse la diffuse ensuite sur toute la surface, et sur les premier model c'était pas encore particulièrement au point...
Personnelement j'ai un tx3xp et je peux t'assurer que l'écran est particulièrement confortable et le rendu des couleurs est excellent. Mais il est vrai que le revettement brillant est génant avec des source lumineuse intense, mais la techno de sony est quand même largement devant les écrans brillant classiques. Avec la luminositée au max sur un contenu classique il faut vraiment une source intense pour que cela devienne génant. Par contre sur des contenus très sombre, il n'y a pas de miracles. (ma grande question est : que donne la techno led avec des écrans mat ?)
L'autre avantage des led est que la luminositée de l'écran se controle bien mieux et permet de faire encore plus baisser la consomation. Sous linux le tx3 peut monter à plus de 9h d'autonomies en optimisant bien la consomation.
Par contre coté support linux, sony c'est de la merde... Pour le lecteur d'empreinte digitale j'ai le même problème de firmware modifié, il y a un projet pour la version normale qui marche (thinkfinger) j'ai commencer à éssayer de le modifier pour le faire fonctionner sur le tx3 mais j'ai virer le windows donc impossible de sniffer l'usb donc ça avance pas beaucoup.
Pareil pour les fonctions avancée commandable par l'acpi, en dehors de couper l'alim du graveur dvd, gérer les boutons media, et le controle de la luminositée, il y a pas grand chose qui marche pour l'économie d'énergie (coupage du firewire et du bluetooth experimentaux). J'avance doucement mais je manque de temps libre.
Le bon point c'est que le suspen-to-ram et le suspend-to-disk marchent parfaitement.
WiFi et Bluetooth aussi mais avec un gros blob propriétaire pour le premier... (ipw3945...)
Les lecteurs de cartes: j'ai pus faire fonctionner le lecteur SD mais je n'ai pas essayer les memory stick puisque je n'en ai pas à disposition.
Vraiment bravo, et dire que j'ai failli passer à côté. Je jette un coup d'oeuil sur linuxfr, lis quelques journaux, et me prépare à me remettre à bosser quand je vois un nom bizarre.
Je me suis dit encore un journal qui parle d'un nouveau logiciel libre qui est destiné à un domaine particulier et ne me concernant pas, ou bien la nouvelle version de ce même logiciel.
Bref j'ai faillit passer mon chemin, mais mon inconscient qui soit avait mieux lus que moi et repéré le mot musical, ou bien qui avait un petit accès de faineantite aigue à réussit à me convaincre d'y jetter un coup d'oeuil.
Donc je me motive et je lit le journal, et là déjà je suis séduit par le projet. Mais bon je me dit "on ne s'emballe pas, on écouterra ça plus tard, faut que tu bosse".
Mais mon inconscient qui est quand même plus intelligent que moi, me souffle à l'oreille que écouter un peu de musique et bosser ne sont pas deux chose incompatibles. La suite m'a prouvé que si...
J'ai téléchargé les deux morceaux de démos et passé 1h à écouter ce magnifique mélange de styles, j'en ai même perturbé mes collèges qui sont venus faire de même. Un ptit mail à deux potes qui ont les même gouts musicaux que moi, et j'ai pourris leur travail aussi..
En bref, c'est vraiment bon, on y trouve un peu de tout, mais le mélange est admirablement fait. D'un point de vu technique l'enregistrement est très bon.
PS: enfin sauf pour l'insulte, non il ne pleut pas en Bretagne, c'est une légende.
PPS: un peu de mauvaise fois ne fait de mal à personne
PPPS: en lpus c'est vrai, il ne pleut pas autant que certains veulent le faire croire
Si tu n'oses pas choisir, donnes les toutes, par ce que là, sans aucune sources on peux se demander si tu ne pipote pas...
Il vaux mieux donner trop de source que pas assez.
Je viens d'aller faire un ptit tour sur le site, histoire de voir le style de chaines proposées, et j'ai vu des chaines diffusant notament les dernières séries à la mode. Question : est-ce bien légal ? Je ne pense pas que les producteur de 24h chrono accepte que l'on diffuse gratuitement leurs productions et je ne vois pas comment ce genre de webTV peux générer suffisament de revenus pour acheter ce genre de séries.
Et deuxième question, pour les éventuels amateurs de GO (le jeux) sur linuxfr. Est-ce que vous connaisser des chaine diffusant des parties ou des commentaires (si possible gratuit ou en tout cas pas trop cher.
Il y avait baduktv qui les diffusait sur son site il y a quelques temps, mais cela ne semble plus le cas.
Il y a aussi la NHK-cup qui est diffusée, mais je ne sais pas de qu'elle manière on peux avoir cette chaine en france.
Donc si vous avez des liens je suis interressé.
Là j'ai la réponse (en tout cas pour les miennes...)
C'est à cause de mon chat, (celui qui est en train de m'emerder à vouloir taper ce commentaire à ma place) quand je met ma lessive à sécher sur l'étendoire, ce con arrête pas de jouer avec, et les coup de griffes sur les chaussetes ça leurs fais pas du bien...
Le truc c'est que je n'ai pas franchement la place pour mettre le linge et le chat dans deux pièces différentes et que la plus part du temps mon linge séche quand je suis au boulot, et que donc je ne peux pas surveiller mon chat.
Bref voilà ma vie, mais surtout une réponse à la grande question des chaussettes trouées.
Juste une petite question, quel avantage y a-t-il à lancer fetchmail periodiquement via cron, plustôt que de l'utiliser en mode daemon ?
Tu économise un peu de mémoire quand il ne tourne pas, mais il prend plus de ressources processeur au moment ou il est lancé.
Une première chose, les deux textes que tu cite sont différents, l'un n'est pas la traduction de l'autre. (c'est juste pour que cela soi bien clair)
Ensuite, la citation du site est en effet plus nuancée, mais si tu regarde la liste qui est donnée juste après dans la page que tu donne, tu peux voir apparaître "latency hidding" et "threaded application". Or, nombreuse sont les application graphiques qui utilisent les threads, mais surtout les problèmes de latence sont commun à tous les programme qui utilisent la Xlib.
Bien sûr pour beaucoup cette latence est à peine perceptible, mais elle est toujours là. La faire disparaître contribuerait à rendre nos bureau plus réactifs.
Il faut aussi noter que même dans le pire des cas, en théorie XCB ne ralentit pas une application. (en theorie, puisque en pratique cela depend de la manière dont son codés chaques versions) En effet la Xlib envoie des requètes via le protocole X, éxactement ce que permet de faire XCB, mais d'une manière différente.
Mais dans la majoritée des cas la Xlib attend la réponse à la requète avant d'envoyer la suivante, là ou XCB te permet de traiter la reponse au moment ou tu en a rééllement besoin.
Un bon exemple est donné dans le tutoriel du wiki, il consiste à créer 500 atomes X. La version Xlib envoie une requète pour créer un atom attend la réponse et passe au suivant 500 fois de suite. La version XCB envoie 500 requète de création d'atom puis attend les réponses, donc pendant que les première requète et leurs réponses ce baladent sur le réseau, les suivantes sont envoyées.
Et même en local les performance sont meilleures, sur le PC de la personne qui à écrit le tutoriel la version XCB est environ 25 fois plus rapide. J'obtient à peu près le même ordre de grandeur sur le miens.
Bien sur cet exemple est un cas extrème et le boost de performance ne sera jamais aussi élevé, mais il y a quand même à gagner si les applications (et donc principalement les toolkit) sont migrés vers XCB.
Ce n'est pas pour rien que dans la plus parts des toolkit, il y a une utilisation des fameux roundtrips, la latence est un vrai problème que résoud XCB.
Bien sur tout n'est pas rose, notament XCB est plus bas niveau que la Xlib, et certaines choses simple à faire avec cette dernière deviennent tout de suite plus complexe. C'est pourquoi il y a aussi à écrire des bibliothèques de fonctions spécialisée et optimisée pour la XCB tout comme cela fut fait pour la Xlib.
PS: Je ne sais pas si tu as bien compris la phrase "ce qui accélérerait un maximum d'applications rapidement.". Le maximum fait référence au nombre d'application et le rapidement au temps nécéssaire pour obtenir ce gain de performance, il n'y a aucun ordre de grandeur donné. Le gain ne sera surement pas x10.
La cohabitation se passe très bien. Les deux lib parlent le même protocole avec le serveur, mais celui ci n'est pas "raciste" il accepte de parler aux deux. Tu peux donc installer XCB en parralèle sans problèmes, et utiliser en même temps des applis Xlib classique, des applis XCB pure, et des applis Xlib/XCB.
Le lancement du serveur ne change absolument pas, XCB et Xlib sont utilisés uniquement par le client pour parler au serveur, le protocole étant le même dans tous les cas le serveur n'a même pas besoin d'être au courrant du changement.
Pour les applis, en fait elles sont toutes opérationelle avec la version Xlib qui utilise XCB comme couche de transport. Pas mal de personnes utilisent déjà un système qui ne possède que XCB et cette version de la Xlib sans problème. Par contre ses application ne profitent que peut des avantages de XCB. Mais on peux éspérer une migration progressive de ces applications puisque il est possible de mélanger les appels Xlib et XCB au seins d'une même application.
Il n'est pas nécéssaire de recompiler les applis si tu passe par la Xlib/XCB, par contre si tu veux passer à du XCB pure il est nécéssaire de modifier le code, parfois assez profondément pour pouvoir profiter notament de l'aspect asynchrone. Il y a aussi des différence assées importantes notament au niveau de la gestions des évenements.
Pour ce qui est du choix entre les deux API, actuellement XCB se présente quand même comme l'avenir. Il est quasiment certains que cette API va s'imposer, mais la Xlib restera toujour présente à des fin de compatibilitée. Une fois la version 1.0 finale sortie, on verra probablement la Xlib standard remplacée par le couple XCB/Xlib.
Le choix est donc entre les mains des développeurs, mais à mon avis, un developpeur qui bosse à ce niveau devrait serieusement envisager d'utiliser XCB. Ce qu'il faut bien voir, comme rappelé dans un commentaire plus bas, c'est que dans la majoritée des cas, les developpeurs bossent à un niveau plus élevé et utilisent des toolkit tel que GTK, il ne voient donc jamais les appels à la Xlib. La programation au niveau du protocole X est généralement limitée aux toolkit, au window manager, ou à des petites applications telle que les dockapps de window maker.
Le principal objectif est donc de convertir ces systèmes d'abstraction pour que un maximum d'application bénéficies de XCB. Un gros boulot à déjà été fait pour evas, il me semble qu'il y a aussi eu du travail de fait pour cairo (mais je n'est pas trop suivi ça), une vieille version de GTK avait aussi étée portée mais le travail n'a pas été poursuivit. Bref, c'est possible, maintenant il va falloir du temps pour que ça ce fasse, mais il semble à peu près inévitable que l'on y viennent à l'avenir.
Je ne suis pas excusable pour autant de fautes, je le sais. Si je veux écrire un texte avec le moins de fautes possible, je dois me relire attentivement plusieurs fois, hors l'écriture de ce journal m'a déjà pris plus d'une heure (sans compter le temps que je vais passer à aller voir régulièrement les commentaires) et je ne peux pas y consacrer plus de temps.
Dans ce cas pourquoi ne pas laisser quelqu'un d'autre écrire un journal de meilleur qualitée ? Tout simplement par ce que XCB est un projet assé discret, même si il est d'une grande importance pour le future de nos bureau. J'ai donc fait le choix d'un journal complet mais avec une plus faible qualitée orthographique, même si j'aurais préféré avoir le temps de le rendre encore mieux et d'en faire une dépèche.
Pour une fois que je voulais faire un journal publique, je me plante avec la checkbox...
Par contre, j'ai oublié de précisé que si quelqu'un veux faire une dépéche, qu'il n'hésite pas, comme je l'ai dit je n'ai pas suffisament de temps en ce moment pour la faire (peut-être pour la version 1.0) mais il serait dommage que cette nouvelle disparaise rapidement.
Les langages haut niveau ne font pas tout, et il suffit de constater que quasiment toutes les applications destinées a un usage quotidien et rédigées en haut niveau n'ont que très peu de succès ... pas par hasard : lent, gouffre a mémoire.
Va le dire au développeurs ut utilisateurs de MLDonkey par exemple... (Ok, tu as dit "quasiment", mais tu as surtout mit "toutes" en gras) et il y en a pas d'autres.
Le problème c'est qu'il faut savoir ou utiliser chaque langages. L'assembleur n'est utile que dans des cas bien précis ou le compilateur n'est pas capable de générer du code optimal et ou les performances sont critiques. Cela inclut par exemple les boucle interne de décodage de flux video quand des instruction SIMD complexes sont disponibles.
Mais les compilateurs font d'énormes progrès et il y a de moins en moins de code pour lesquels une version assembleur apporte un gain vraiment interessant. Et c'est pour cela que les langage haut niveau ratrapent progressivement les langages bas niveau. Parce que pour pouvoir faire des optimisations aussi complexes, il faut disposer d'informations sémantiques qu'il est impossible de fournir au compilateur en C.
[^] # Re: Faut apprendre a lire
Posté par beagf (site web personnel) . En réponse au journal Ms ce sont des rigolos. Évalué à 1.
Ou pour garder ta métaphore, il n'est pas nécéssaire de connaître le chinois pour pouvoir utiliser le traducteur Français/Chinois et communiquer avec un Chinois.
Et là je parle en connaissance de cause, j'ai passé deux heures a discuter avec une amie coréene de mon ex, je ne connais absolument pas le coréen et elle ne connaissait pas le français, mais avec babelfish on a pus communiquer (malgrer la pietre qualitée des traduction et le fait que mon anglais avait du mal à être digéré par le traducteur...)
[^] # Re: Backups, toussa toussa
Posté par beagf (site web personnel) . En réponse au journal Journalisation de fichier. Évalué à -1.
[^] # Re: les DRMs n'ont qu'à bien se tenir
Posté par beagf (site web personnel) . En réponse à la dépêche Première carte mère équipée d'un BIOS libre. Évalué à 3.
Et une application certifiée , par exemple ne lit un dvd en haute qualitée que si toute la chaine jusqu'a l'ecran est certifiée.
Quand à l'EFI, je ne connais pas tous les détails, mais je suppose que ca doit faciliter la mise en place de ce genre de systèmes. Mais bon j'ai pas encore eu le temps d'aller vraiment me reseigner dessus, donc je laisse la parole a ceux qui connaissent.
[^] # Re: Le niveau moyen...
Posté par beagf (site web personnel) . En réponse au journal Le Go et les ordinateurs. Évalué à 3.
Le classement dépend de la version utilisée, la dernière stable de GnuGo, la 3.6, date quand même de fin 2004. Donc beaucoup de joueur qui mettent en place des bots utilisent une version de dévelopement. Mais comme c'est du developement et que chacun ne récupère pas la même révision, il y a pas mal de différences.
Ensuite il y a la configuration qui influe énormément sur le niveau de jeu. Il y a plein de paramètres à tuner pour obtenir le meilleur de GnuGo. Les paramètres par défaut ne sont pas forcément les meilleurs, mais surtout des petits changements dans les paramètres peuvent influer sur la manière globale de jouer de GnuGo, et donc perturber un adversaire qui chercherait à exploiter les faiblesse classique. Mais en modifiant trop certains paramètres on obtient l'éffet inverse, GnuGo est capable de devenir une vrai merde si on lui demande gentillement...
Bref tout ça pour dire que le niveau de GnuGo varie énormément d'un bot à l'autre sur KGS et que c'est parfaitement normal. Les meilleurs bots utilisant le moteur de GnuGo sont actuellement 7-8kyu c'est une constatation.
Alors comment expliquer qu'un joueur 13kyu batte régulièrement un bot 7-8kyu :
- 1ère possibilité, tu utilise une version plus vielle de GnuGo, qui à énormément évolué depuis,
- 2ème possibilité, tu connais les faiblesses de GnuGo, ce qui n'est pas le cas de la majoritée des joueurs qui jouent avec lui sur KGS, donc sont niveau KGS ne reflète pas sont niveau face à joueur qui le connait bien,
- 3ème possibilité, tu était 13kyu avant fin septembre 2006 date à laquelle l'échelle des niveau de KGS à été modifiée. Avec cette modification les joueurs 13kyu on gagner en gros 4kyu, donc tu te serrai retrouver 9kyu. Cette modification à été fait pour compenser la dérive de l'échelle de KGS et pour rapprocher l'échelle de KGS des échelles nationale.
En combinant les trois on arrive a une victoire faicle de ta pars contre GnuGo...
[^] # Re: Le niveau moyen...
Posté par beagf (site web personnel) . En réponse au journal Le Go et les ordinateurs. Évalué à 7.
Le problème est que les classement des différents serveurs et échelles nationnales ne sont pas vraiment comparables.
Qu'oi qu'il en soit je suis actuellement 2dan amateur sur kgs, et je donne sans problèmes 13 pierres d'avance à gnugo. La partie deviens sérée a 17 pierres, mais j'ai l'avantage sur gnugo que je connais ses faiblesses et je peux provoquer des situations ou je sais qu'il va se planter.
Pour la petite histoire, un ami à voulut une fois tester gnugo à l'aveugle et sans que je le sache ma fait jouer plusieurs parties à handicap contre lui. Il a créé un compte humain et jouait les coups que gnugo lui indiquait.
Les deux premières parties ont étée beaucoup plus sérée que mes parties habituelles de l'époque contre gnugo, mais à la troisième j'ai finit par repérer le style de gnugo et l'écraser.
Preuve que l'écart de niveau viens aussi de l'exploitation des grosse faiblesses de ces programme.
Ces pour quoi, à mon avis il y a deux choses à amméliorer dans les programmes actuels, ils doivent continuer leurs progrès, ce qui est la voie actuelle. Mais il est aussi nécéssaire de comprendre leurs faiblesses et de les corriger.
La deuxième voie est plus ingrate puisqu'il y a peu de progès visible imédiatement, mais permet d'obtenir un niveau plus stable sur le long terme.
Si mes souvenirs sont bon, lorsque les premiers programmes d'échec on commencé à battre les meilleurs humains, ils ne le faisait que sur les premières parties. Sur un nombre plus importants de parties l'humain sortait victorieux.
# Le problème du rendu réaliste
Posté par beagf (site web personnel) . En réponse au journal Sortie de Sunflow 0.07.1. Évalué à 2.
Il n'y a jamais (ou presque) le moindre détail qui cloche au sens photographique du terme. Pas la moindre poussière qui traine, les objets sont parfaitement alignés, tout est super propre et brillant.
Pour faire des images qui ressemble à de vrai photos, à mon avis, c'est la dessus qu'il va falloir travailler.
Je ne dis pas que c'est image sont moches, bien au contraire je les trouve magnifique. Je suis un grand fan des images de Gilles Trans, mais je suis toujours un peu déçu quand je vois une image un peu trop parfaite qui aurrait pus ressembler à une photo si elle l'avait étée un peu moins.
[^] # Re: Quand même ...
Posté par beagf (site web personnel) . En réponse au journal CNR: L'installation de logiciels en un click pour toutes les distributions.. Évalué à 3.
CNR est open source
[^] # Re: re
Posté par beagf (site web personnel) . En réponse au journal Preuve de piratage. Évalué à -1.
nombre de fichiers partagés sur les serveurs x nombres d'utilisateur connectés sur les serveurs x prix moyen d'un contenu = perte minimum (il faut compter les échanges hors p2p)
[^] # Re: Pas vraiment libre
Posté par beagf (site web personnel) . En réponse à la dépêche Projet Open Graphics : 1ère étape terminée. Évalué à 7.
Les geeks fan de linux et de libre vont les acheter sur le net, ce qui va redonner un peu de sous à sa boite qui va donc pouvoir rembourser une partie du developement et produire une nouvelle série un peu plus grosse de cartes, et donc viser des marchés un peu plus étendus. Et ce cycle va se répéter jusqu'à ce qu'elle puisse raisonnablement produire des grosses séries de cartes donc avec un coût beaucoup plus faible puisque le prix à l'unitée baisse avec la quantitée et que les investissement auront été remboursés.
Et donc à ce moment là, la carte deviendra interressante au niveau du rapport qualitée/prix, c'est à dire une carte sans grosses prétentions mais à pas cher et avec la philosophie du libre en bonus.
Maintenant si le messieur il libère tout. Les gros fondeurs taiwanais vons pouvoir produire sa carte sans avoir à ammortir les couts de développement ni le prix d'une licence. Ce qui réduit le prix de la carte pour eux.
En plus, ils disposent déjà des usines toutes équipées pour ce genre de production, ils n'ont pas à passer par un intermédiaire, ce qui veux dire que les cartes sont encore moins chères.
Ils ont aussi un compte en banque qui leur permet de produire des grosse séries dès le début donc coûts minimum dès le début.
Et cerise sur le gateaux, mais à mon avis le plus important, ils sont déjà très présents sur le marché et ont donc tous les atoux en mains pour placer cette carte chez les gros acheteurs potentiels.
Donc si cette carte à un potentiel à grande échelle, pendant qu'avec sa petite sociétée il commencera à éssayer de vendre sa carte a un prix élevé (tout est relatif bien sur), à un publique très spécialisé de manière quasiment anonyme en éssayant tant bien que mal de rentrer dans ses frais, avec l'espoir de gagner suffisament d'argent pour produire la prochaine génération de carte.
Les taiwanais, eux, produirons la carte à grande échelle et la vendront en grosse quantitée, par exemple à des assembleurs de PC à bas prix.
Le seul marché sur lequels ils pourra rester dominant est celui des geeks libriste qui lui acheteront la sienne plus chère par solidaritée et conviction.
Le bilan c'est que si sa carte à un réel avenir et qu'il l'ouvre en totalitée, il mettra 20ans à réunir l'argent pour développer la génération suivante.
"le coût d'un logiciel est nul ou négligeable" En fait, ici ce qui est important c'est le cout de reproduction d'un logiciel qui est quasiment nul (en tout cas négligeable...) contrairement à son coût de développement qui peut être énorme, mais une fois développé, en faire 1000, 10000 ou 10000000 copies ne coute quasiment rien et est à la portée de quasiment tout le monde.
Pour un projet hardware tel que OGC, le cout de production de chaque exemplaire est éxorbitant au début et se réduit progressivement dans le temps. Et surtout ce coût de production n'est pas le même pour une petite boite qui sort son premier produit et une énorme boite qui est déjà entièrement équipée et qui à les relations pour vendre le produit en masse.
Remarques :
- j'ai volontairement éxagéré les deux scénarios, mais je ne pense trop me tromper si ça carte à un réel potentiel.
- je conditionne tout ceci sur le fait que la carte ait un réel potentiel, c'est-à-dire qu'il y ai réellement un public non-négligeable interresser par cette carte, c'est-à-dire suffisament important pour que les grosse boite investissent dedans.
# Peut-être que...
Posté par beagf (site web personnel) . En réponse au journal Greve un soir de Noël...?. Évalué à -9.
Ils en ont peut-être le droit eux aussi ?
[^] # Re: C'est moche
Posté par beagf (site web personnel) . En réponse à la dépêche Projet Looking Glass : version 1.0. Évalué à -2.
[^] # Re: tuxmobil et linux-laptop
Posté par beagf (site web personnel) . En réponse au journal Sony Vaio VS linux/libre. Évalué à 2.
La meilleure preuve est que les premières version de cette techno avait un gros défault, un halo lumineux sur le bas de l'écran. En effet les led sont située en bas de l'écran et un système diffuse la diffuse ensuite sur toute la surface, et sur les premier model c'était pas encore particulièrement au point...
Personnelement j'ai un tx3xp et je peux t'assurer que l'écran est particulièrement confortable et le rendu des couleurs est excellent. Mais il est vrai que le revettement brillant est génant avec des source lumineuse intense, mais la techno de sony est quand même largement devant les écrans brillant classiques. Avec la luminositée au max sur un contenu classique il faut vraiment une source intense pour que cela devienne génant. Par contre sur des contenus très sombre, il n'y a pas de miracles. (ma grande question est : que donne la techno led avec des écrans mat ?)
L'autre avantage des led est que la luminositée de l'écran se controle bien mieux et permet de faire encore plus baisser la consomation. Sous linux le tx3 peut monter à plus de 9h d'autonomies en optimisant bien la consomation.
Par contre coté support linux, sony c'est de la merde... Pour le lecteur d'empreinte digitale j'ai le même problème de firmware modifié, il y a un projet pour la version normale qui marche (thinkfinger) j'ai commencer à éssayer de le modifier pour le faire fonctionner sur le tx3 mais j'ai virer le windows donc impossible de sniffer l'usb donc ça avance pas beaucoup.
Pareil pour les fonctions avancée commandable par l'acpi, en dehors de couper l'alim du graveur dvd, gérer les boutons media, et le controle de la luminositée, il y a pas grand chose qui marche pour l'économie d'énergie (coupage du firewire et du bluetooth experimentaux). J'avance doucement mais je manque de temps libre.
Le bon point c'est que le suspen-to-ram et le suspend-to-disk marchent parfaitement.
WiFi et Bluetooth aussi mais avec un gros blob propriétaire pour le premier... (ipw3945...)
Les lecteurs de cartes: j'ai pus faire fonctionner le lecteur SD mais je n'ai pas essayer les memory stick puisque je n'en ai pas à disposition.
# Ouah !
Posté par beagf (site web personnel) . En réponse au journal Lessazo projet musical libre. Évalué à 2.
Vraiment bravo, et dire que j'ai failli passer à côté. Je jette un coup d'oeuil sur linuxfr, lis quelques journaux, et me prépare à me remettre à bosser quand je vois un nom bizarre.
Je me suis dit encore un journal qui parle d'un nouveau logiciel libre qui est destiné à un domaine particulier et ne me concernant pas, ou bien la nouvelle version de ce même logiciel.
Bref j'ai faillit passer mon chemin, mais mon inconscient qui soit avait mieux lus que moi et repéré le mot musical, ou bien qui avait un petit accès de faineantite aigue à réussit à me convaincre d'y jetter un coup d'oeuil.
Donc je me motive et je lit le journal, et là déjà je suis séduit par le projet. Mais bon je me dit "on ne s'emballe pas, on écouterra ça plus tard, faut que tu bosse".
Mais mon inconscient qui est quand même plus intelligent que moi, me souffle à l'oreille que écouter un peu de musique et bosser ne sont pas deux chose incompatibles. La suite m'a prouvé que si...
J'ai téléchargé les deux morceaux de démos et passé 1h à écouter ce magnifique mélange de styles, j'en ai même perturbé mes collèges qui sont venus faire de même. Un ptit mail à deux potes qui ont les même gouts musicaux que moi, et j'ai pourris leur travail aussi..
En bref, c'est vraiment bon, on y trouve un peu de tout, mais le mélange est admirablement fait. D'un point de vu technique l'enregistrement est très bon.
Donc, bravo.
[^] # Re: Et une éolienne géante tournant à 700m d'altitude vous en pensez quo
Posté par beagf (site web personnel) . En réponse au journal L'éolien ça craint ?. Évalué à 1.
PS: enfin sauf pour l'insulte, non il ne pleut pas en Bretagne, c'est une légende.
PPS: un peu de mauvaise fois ne fait de mal à personne
PPPS: en lpus c'est vrai, il ne pleut pas autant que certains veulent le faire croire
[^] # Re: Et une éolienne géante tournant à 700m d'altitude vous en pensez quo
Posté par beagf (site web personnel) . En réponse au journal L'éolien ça craint ?. Évalué à 2.
Il vaux mieux donner trop de source que pas assez.
# Deux petites questions
Posté par beagf (site web personnel) . En réponse à la dépêche PeerTV pour Linux. Évalué à 1.
Et deuxième question, pour les éventuels amateurs de GO (le jeux) sur linuxfr. Est-ce que vous connaisser des chaine diffusant des parties ou des commentaires (si possible gratuit ou en tout cas pas trop cher.
Il y avait baduktv qui les diffusait sur son site il y a quelques temps, mais cela ne semble plus le cas.
Il y a aussi la NHK-cup qui est diffusée, mais je ne sais pas de qu'elle manière on peux avoir cette chaine en france.
Donc si vous avez des liens je suis interressé.
[^] # Re: mouaih
Posté par beagf (site web personnel) . En réponse au journal Itiz ze Trolledeille !. Évalué à 3.
C'est à cause de mon chat, (celui qui est en train de m'emerder à vouloir taper ce commentaire à ma place) quand je met ma lessive à sécher sur l'étendoire, ce con arrête pas de jouer avec, et les coup de griffes sur les chaussetes ça leurs fais pas du bien...
Le truc c'est que je n'ai pas franchement la place pour mettre le linge et le chat dans deux pièces différentes et que la plus part du temps mon linge séche quand je suis au boulot, et que donc je ne peux pas surveiller mon chat.
Bref voilà ma vie, mais surtout une réponse à la grande question des chaussettes trouées.
[^] # Re: Killer quiz
Posté par beagf (site web personnel) . En réponse au journal Hans Reiser arrêté. Évalué à 2.
[^] # Re: Conjonction de coordination
Posté par beagf (site web personnel) . En réponse à la dépêche Release Candidate 1 de XCB. Évalué à 1.
En théorie c'est le rôle que devrait remplir le lien "inutile", mais entre la théorie et la pratique...
[^] # Re: à propos du spam
Posté par beagf (site web personnel) . En réponse à la dépêche Sylpheed-Claws 2.5.0 est sorti !. Évalué à 2.
Tu économise un peu de mémoire quand il ne tourne pas, mais il prend plus de ressources processeur au moment ou il est lancé.
[^] # Re: Gros titres à sensations
Posté par beagf (site web personnel) . En réponse à la dépêche Release Candidate 1 de XCB. Évalué à 10.
Ensuite, la citation du site est en effet plus nuancée, mais si tu regarde la liste qui est donnée juste après dans la page que tu donne, tu peux voir apparaître "latency hidding" et "threaded application". Or, nombreuse sont les application graphiques qui utilisent les threads, mais surtout les problèmes de latence sont commun à tous les programme qui utilisent la Xlib.
Bien sûr pour beaucoup cette latence est à peine perceptible, mais elle est toujours là. La faire disparaître contribuerait à rendre nos bureau plus réactifs.
Il faut aussi noter que même dans le pire des cas, en théorie XCB ne ralentit pas une application. (en theorie, puisque en pratique cela depend de la manière dont son codés chaques versions) En effet la Xlib envoie des requètes via le protocole X, éxactement ce que permet de faire XCB, mais d'une manière différente.
Mais dans la majoritée des cas la Xlib attend la réponse à la requète avant d'envoyer la suivante, là ou XCB te permet de traiter la reponse au moment ou tu en a rééllement besoin.
Un bon exemple est donné dans le tutoriel du wiki, il consiste à créer 500 atomes X. La version Xlib envoie une requète pour créer un atom attend la réponse et passe au suivant 500 fois de suite. La version XCB envoie 500 requète de création d'atom puis attend les réponses, donc pendant que les première requète et leurs réponses ce baladent sur le réseau, les suivantes sont envoyées.
Et même en local les performance sont meilleures, sur le PC de la personne qui à écrit le tutoriel la version XCB est environ 25 fois plus rapide. J'obtient à peu près le même ordre de grandeur sur le miens.
Bien sur cet exemple est un cas extrème et le boost de performance ne sera jamais aussi élevé, mais il y a quand même à gagner si les applications (et donc principalement les toolkit) sont migrés vers XCB.
Ce n'est pas pour rien que dans la plus parts des toolkit, il y a une utilisation des fameux roundtrips, la latence est un vrai problème que résoud XCB.
Bien sur tout n'est pas rose, notament XCB est plus bas niveau que la Xlib, et certaines choses simple à faire avec cette dernière deviennent tout de suite plus complexe. C'est pourquoi il y a aussi à écrire des bibliothèques de fonctions spécialisée et optimisée pour la XCB tout comme cela fut fait pour la Xlib.
PS: Je ne sais pas si tu as bien compris la phrase "ce qui accélérerait un maximum d'applications rapidement.". Le maximum fait référence au nombre d'application et le rapidement au temps nécéssaire pour obtenir ce gain de performance, il n'y a aucun ordre de grandeur donné. Le gain ne sera surement pas x10.
[^] # Re: Pourquoi ?
Posté par beagf (site web personnel) . En réponse au journal XCB en version 1.0-RC1, le futur en marche.... Évalué à 4.
Le lancement du serveur ne change absolument pas, XCB et Xlib sont utilisés uniquement par le client pour parler au serveur, le protocole étant le même dans tous les cas le serveur n'a même pas besoin d'être au courrant du changement.
Pour les applis, en fait elles sont toutes opérationelle avec la version Xlib qui utilise XCB comme couche de transport. Pas mal de personnes utilisent déjà un système qui ne possède que XCB et cette version de la Xlib sans problème. Par contre ses application ne profitent que peut des avantages de XCB. Mais on peux éspérer une migration progressive de ces applications puisque il est possible de mélanger les appels Xlib et XCB au seins d'une même application.
Il n'est pas nécéssaire de recompiler les applis si tu passe par la Xlib/XCB, par contre si tu veux passer à du XCB pure il est nécéssaire de modifier le code, parfois assez profondément pour pouvoir profiter notament de l'aspect asynchrone. Il y a aussi des différence assées importantes notament au niveau de la gestions des évenements.
Pour ce qui est du choix entre les deux API, actuellement XCB se présente quand même comme l'avenir. Il est quasiment certains que cette API va s'imposer, mais la Xlib restera toujour présente à des fin de compatibilitée. Une fois la version 1.0 finale sortie, on verra probablement la Xlib standard remplacée par le couple XCB/Xlib.
Le choix est donc entre les mains des développeurs, mais à mon avis, un developpeur qui bosse à ce niveau devrait serieusement envisager d'utiliser XCB. Ce qu'il faut bien voir, comme rappelé dans un commentaire plus bas, c'est que dans la majoritée des cas, les developpeurs bossent à un niveau plus élevé et utilisent des toolkit tel que GTK, il ne voient donc jamais les appels à la Xlib. La programation au niveau du protocole X est généralement limitée aux toolkit, au window manager, ou à des petites applications telle que les dockapps de window maker.
Le principal objectif est donc de convertir ces systèmes d'abstraction pour que un maximum d'application bénéficies de XCB. Un gros boulot à déjà été fait pour evas, il me semble qu'il y a aussi eu du travail de fait pour cairo (mais je n'est pas trop suivi ça), une vieille version de GTK avait aussi étée portée mais le travail n'a pas été poursuivit. Bref, c'est possible, maintenant il va falloir du temps pour que ça ce fasse, mais il semble à peu près inévitable que l'on y viennent à l'avenir.
[^] # Re: Pourquoi ?
Posté par beagf (site web personnel) . En réponse au journal XCB en version 1.0-RC1, le futur en marche.... Évalué à 10.
Dans ce cas pourquoi ne pas laisser quelqu'un d'autre écrire un journal de meilleur qualitée ? Tout simplement par ce que XCB est un projet assé discret, même si il est d'une grande importance pour le future de nos bureau. J'ai donc fait le choix d'un journal complet mais avec une plus faible qualitée orthographique, même si j'aurais préféré avoir le temps de le rendre encore mieux et d'en faire une dépèche.
# Dommage...
Posté par beagf (site web personnel) . En réponse au journal XCB en version 1.0-RC1, le futur en marche.... Évalué à 4.
Par contre, j'ai oublié de précisé que si quelqu'un veux faire une dépéche, qu'il n'hésite pas, comme je l'ai dit je n'ai pas suffisament de temps en ce moment pour la faire (peut-être pour la version 1.0) mais il serait dommage que cette nouvelle disparaise rapidement.
[^] # Re: Heisenbug
Posté par beagf (site web personnel) . En réponse au journal printf debugging considered harmful. Évalué à 2.
Va le dire au développeurs ut utilisateurs de MLDonkey par exemple... (Ok, tu as dit "quasiment", mais tu as surtout mit "toutes" en gras) et il y en a pas d'autres.
Le problème c'est qu'il faut savoir ou utiliser chaque langages. L'assembleur n'est utile que dans des cas bien précis ou le compilateur n'est pas capable de générer du code optimal et ou les performances sont critiques. Cela inclut par exemple les boucle interne de décodage de flux video quand des instruction SIMD complexes sont disponibles.
Mais les compilateurs font d'énormes progrès et il y a de moins en moins de code pour lesquels une version assembleur apporte un gain vraiment interessant. Et c'est pour cela que les langage haut niveau ratrapent progressivement les langages bas niveau. Parce que pour pouvoir faire des optimisations aussi complexes, il faut disposer d'informations sémantiques qu'il est impossible de fournir au compilateur en C.