Stephane Marchesin a écrit 254 commentaires

On modifie pas les regles d'un fichier .in, vu qu'ils sont generes par automake
C'est vrai s'il s'agit d'un makefile.in, mais on peut (doit) modifier parfois les .in , ne serait-ce que pour modifier configure.in.

Et puis on peut faire des choses sympatiques comme un fichier "monprog.spec.in", puis ajouter "monprog.spec" dans la liste des fichiers à générer par configure. Ca permet d'obtenir un specfile pour les rpm qui a un numero de version du package défini par configure, et donc ca m'évite de mettre à jour le no de version à la main (oui, je suis un fainéant).

- tu compiles avec -g -pg
- tu exécutes ton code (essaye de trouver un cas typique)
- tu trouveras normalement un gmon.out dans le répertoire courant

J'ai essayé de faire un free des variables malloquées quand c'était possible, mais à part ça :
J'appuie fortement ce que dit kadreg, note quand même que faire des free n'accelerera pas la vitesse d'exécution (à moins que tu ne fasse swapper ton ordi à force de ne rien libérer ;).

- A quoi faut-il faire spécialement attention ?
Aux nombre d'appels des constructeurs/destructeurs, surtout si ils font tous des new/delete
A bien inliner les fonctions qui valent le coup
A passer par référence les paramètres qui sont des structures, même si tu n'as pas l'utilité d'un passage par référence

- quelle est la commande pour mesurer le temps d'exécution d'une partie particulière du programme ?
gprof. Tu compiles avec "g++ -g -pg" puis tu tapes "gprof gmon.out". Tu obtiendras les temps passés dans chaque fonction et le nombre d'appel, etc... (man gprof pour plus de détails). Note que gprof ne voit pas les fonctions qui one été inlinées.
Sinon si tu veux une bonne précision (ie au cycle d'horloge près) tu peux utiliser les time stamp counters des cpus x86 pentium et supérieurs, mais il faudra mettre un peu les mains dans le cambouis pour les lire, ou bien trouver une lib qui le fait.

- quels sont les trucs à savoir ?
Les options de g++ à utiliser (par exemple, comment casser le respect de la norme ieee sur les flottants au profit de la vitesse d'exécution, à savoir avec g++ -ffast-math -mno-ieee-fp, ou comment optimiser pour ton architecture : -march=i686 pour les pentium pro, -msse voire -msse2 pour générer du code flottant qui utilise le SSE au lieu du 387)
Aux problèmes de cache : si tu as des données assez importantes, il faut surveiller l'utilisation de ton cache, et en particulier à quelle vitesse les infos qu'il contient sont remplacées (cache trashing).
Ne pas se tromper de niveau d'optimisation : si ton algo est en o(n^3), cherches en plutôt un avec une complexité inférieure avant de te lancer dans des optimisations à tout va.
Ne pas se tromper de structures de données : de la même manière précédemment, tu peux dans certains algos baisser la complexité et donc accélérer l'exécution avec des choses simples comme les listes triées par exemple.

Justement je n'aime pas ça. Je n'ai pas envie de faire un choix entre "informatif", "caustique" ou "humoristique". Les trois m'intéressent, ce classement m'est inutile. Par contre pouvoir filtrer sur la "qualité" des messages est plus utile, vu la longueur des threads en général (d'ailleurs ce serait bien de pouvoir à nouveau régler le seuil de visualisation des messages, même si j'imagine que ça fait de la charge machine en plus, car plus de fichiers dans le cache). Le système slashdot est bien plus fin que ca. Prenons un poste slashdot au pif : http://yro.slashdot.org/comments.pl?sid=62223&cid=5823196 On a bien le détail des modérations, mais en même temps on a un total qui permet de filtrer ce que tu apelles la "qualité" justement. Une fois que tu as un compte, tu peux avoir des "amis" et "ennemis" qui ont, dans ta vision des pages, des bonus/malus automatiques. Par exemple si tu sais que tel ou tel personne dit souvent des choses intelligentes, tu peux lui mettre un bonus énorme de base, naviguer à +5 et avoir les commentaires globalement intéressants et ceux de cette personne. Après, il y a encore mieux avec les amis des amis, les ennemis des amis etc... Et la qualité d'un message n'a rien à voir avec son style : un post humoristique peut être très marrant ou totalement naze, un post caustique osciller entre le grommellement de vieux radoteur et le pamphlet fin et incisif. Jusetment, étant donné le nombre de modérateurs, un post moyenement drole n'atteindra pas une note de 5. En plus, le système de slashdot a à mon avis un avantage supplémentaire : on peut être loggué, mais poster en anonyme : ca permet justement à ceux qui se font régulièrement moinser sur leur id de se protéger.

cf http://lists.debian.org/debian-testing/2001/debian-testing-200102/m(...)

Par contre, et c'est ca qui m'intrigue plus, tu compiles un noyau i386 pour un palm, dont le cpu est un dragonball (à moins que je n'aie rien compris à ta question) ?

- La date limite est la 17. Attention, le cachet de la poste ne fait pas foi, il y a donc une inégalité entre ceux qui habitent à Paris/RP et peuvent aller déposer le CD direct au ministère (comme Nekeme --> nous) ou ceux qui doivent l'envoyer.

Il y a pire comme inégalité pour ceux qui n'habitent pas Paris :

[extrait du réglement]
Les candidats seront invités à présenter au jury et au public leur production le 22 mars 2003 à Paris pendant la fête de l’internet. Cette présentation, sauf exception, s’effectuera sur le matériel du candidat, qui recevra au titre d’une participation à ses frais de transport et déplacement une somme forfaitaire (50 euros pour les résidents d’Ile-de-france et 80 euros pour les résidents d’autres régions).

Donc pour se présenter au concours il faut se rendre à Paris le 22 avec sa machine. C'est pas ce qu'il y a de plus pratique ni de plus équitable.

Je trouve pas ça normal qu'ils fassent leur blé sur le dos des serveurs qui se font slashdotter. Et c'est pas en instaurant ce système qu'ils auront intérêt à ca que ca change. Un truc intelligent serait plutôt un "cache slashdot" (payant ou non), mais bon...

Bah moi j'avais essayé mosix (quand c'etait encore libre).

Il y avait les problèmes suivants :

- un processus migre en entier (avec toutes ses pages mémoire) ou rien du tout.
- 10 Mbps, c'est effectivement pas beaucoup, je suis passé en 100 c'etait largement mieux (tes machines ralentissent de manière conséquente pendant la migration d'un processus, autant que ca soit court).
- les processus qui font beaucoup d'I/O, ou qui ont ouvert un périph local (ca inclut de l'opengl accéléré, par exemple) ne peuvent pas être déportés
- les processus utilisant les threads ne peuvent pas migrer non plus. Donc on perd beaucoup de la transparence (puisque la plupart des progs paralleles sont faits avec des threads pour le smp)
- il faut compiler un noyau avec smp, même sur des machines mono processeur
- ca oblige à avoir une version bien précise du noyau
- c'est en utilisant mosix que j'ai planté linux, jamais autrement (pricipalement si la machine fait du X en même temps).
- si une machine du cluster tombe, les autres machines qui avaient des processus migrés sur cette machine ne pourront plus s'éteindre (ça bloque au moment où il envoie kill à tous les processus).
- en utilisation "normale" du pc, le seul processus qui migrait était xfs. Les autres rien du tout.

Dans les bont côtés
- c'est vrai que c'est sympa de voir migrer les processus sans se fatiguer: si tu as écrit un programme en mpi et que tu veux pas t'embêter à coder la répartition de charge, tu en lances en gros 2* le nombre de cpu et tu les laisse se répartir ;)
- c'est sympa aussi de pouvoir ajouter/enlever dynamiquement des machines au cluster
- on peut controler la migration de processus à la main
- il y a le "mfs", mosix file system, qui permet de voir les fs des autres machines, sans faire de nfs ;)
- enfin c'est pratique pour frimer avec mtop genre "j'ai plein de cpu" ;)

Maintenant, tout ca ne s'applique peut-être plus à openmosix, mais je sais que la plupart des inconvénients sont toujours là.

A la fin, je m'en servais plus que pour compiler du code (mais maintenant avec distcc j'ai laissé tomber !).

Oui, je viens de lire le code de la bête, et effectivement dès que le ver arrive, il se réenvoie en continu à des adresses ip aléatoires. Donc :
- un paquet de liens tournent à fond
- comme les ips sont aléatoires, ces paquets doivent souvent traverser pas mal de routeurs pour aller à l'autre bout du monde donc ça a un effet sur le trafic global (qui est en général plutôt un trafic de proximité).

Les requêtes ça fait du trafic, non ? Donc moins de requêtes = moins de trafic.

Par contre c'est vrai que j'avoue avoir du mal à comprendre comment les root-servers peuvent être impactés à ce point-là. L'explication que je vois est que les routeurs sont saturés, ce qui empêche d'atteindre les root-servers. Mais pour saturer ça avec des paquets udp de 376 octets il faut quand même en mettre pas mal (il y a tellement de serveurs ms sql ouverts à tous vents sur le net ?).

PS : heureusement que les root-servers n'utilisent pas ms sql ;)

Bah tu as l'air de dire que tu as mis explicitement les root-servers dans la liste des dns que tu utilisais.

Moi, je demande tout à wanadoo qui cache les résultats (à wanadoo je demande qui gère google.com etc...), et si tout le monde fait pareil ça réduit la pression sur les root-servers. Si les dns wanadoo tombent, j'ai un ou deux dns de secours hors wanadoo.

cf http://www.sciencedaily.com/releases/2003/01/030124074245.htm(...) si les requêtes inutiles n'avaient pas lieu (grâce à l'utilisation de caches), les root-servers tiendraient peut-être mieux les dos comme aujourd'hui.

Tu utilises les root-servers pour résoudre tes requêtes ? Alors il ne faut pas s'étonner d'avoir des problèmes :
- d'après la rfc, seuls les dns secondaires devraient interroger les root-servers
- en cas d'attaque, les root-servers seront forcément visés les premiers

Par contre, un dns doit normalement répondre aux requêtes venant de n'importe qui (pas de filtrage sur l'ip) donc tu peux ajouter les dns d'autres providers dans ton pdnsd.conf si tu veux être tranquille.

Et wanadoo a plus que 2 dns, puisqu'il y a ns1 à ns6.wanadoo.fr (merci au passage à la tribune qui m'avait appris ça il y quelques temps...).

Bon. Lisons ensemble le lien que tu nous fournis : Pour sa part, Jean-Pierre Bemba, le chef du MLC, a annoncé qu'un de ses commandants et sept hommes de rang comparaîtront cette semaine devant une cour martiale rebelle pour répondre de ces atrocités. Accusés de viols, meurtres et pillage, ils encourent la peine de mort. "Il n'y aura pas d'impunité", a-t-il assuré en affirmant cependant qu'une enquête interne n'avait pas trouvé trace de cannibalisme. On y apprend que les auteurs présumés de ces actes vont être jugés. On y apprend aussi qu'il n'y a pas de preuves des accusations de cannibalisme. Faisons un petit comparatif des civilisations si tu y tiens tellement : que penses-tu d'une France incapable de juger Papon plus de 50 ans après ce qu'il a fait, par opposition à ces gens qui, eux ,seront jugés. Et dis moi lesquels sont les plus "civilisés" ? Ceux qui laissent les coupables en liberté sûrement.

vu les conneries de la RATP, FT

Les conneries de FT, je suis pas d'accord. FT a rapporté un max de fric à l'état pendant quelques années, simplement ils se sont endettés jusqu'au cou pour payer la licence UMTS (qui d'ailleurs est maintenant bradée à une fraction dérisoire de son prix d'origine) à l'état! Et c'est l'état qui a obligé FT à acheter cette licence, puisque FT a une obligation de service public. En plus il en a profité pour se désengager un peu plus du capital de FT.

C'est sûr que maintenant il faut privatiser FT, vu qu'il coûte du fric à l'état. Bref tout ça sent à plein nez le gros calcul pour faire passer la privatisation complète de FT auprès du grand public.

Bref pour les "conneries de FT", tu repasseras, hein...

D'autant plus que la dernière fois qu'ils se sont fait hacker c'était le 30 décembre (cf http://www.boycott-riaa.com/(...) ), alors s'il devait y avoir une nouvelle à chaque fois...

En plus, on dirait qu'il y a des restes qu'ils ont pas fini de nettoyer : http://www.riaa.org/PR_story.cfm?id=597(...)

Le port 4662 c'est edonkey. Pour peu que tu aies une ip dynamique et que son précédent utilisateur l'ai envoyé dans le réseau, tu auras plein de tentatives de connection.

Pour les problèmes d'attaque sur le port 80, j'en ai aussi plein (un peu toujours les mêmes, c'est-à-dire des trucs automatisés, j'ai l'impression que c'est pas mal de nessus), je suis en train de mettre en place une solution avec iptables et le patch "recent" que trouveras ici :
http://www.netfilter.org/documentation/pomlist/pom-extra.html#recen(...)

Une des utilisations de ce patch est de permettre de limiter le nombre de connections à un port, du genre pas plus de 5 connections par minute par ip, ce qui devrait suffire à calmer les petits hackerz.

Je n'ai pas essayé mais ce n'est pas possible. En effet, valgrind ne supporte pas un tas de choses vitales pour faire tourner un système linux, dont l'appel système clone(), ni les instructions MMX/SSE/3dnow/ (ça c'est pas vital mais c'est un des problèmes que j'ai eus)
Il y a toute une liste de limitations ici :
http://developer.kde.org/~sewardj/docs/manual.html#limits(...)

En fait valgrind ne fait que se substituer aux librairies (libpthread, glibc...), donc utiliser valgrind pour tous les progs équivaudrait à tourner des glibc et libpthread modifiées.

Cette vieille légende du triple sync ne viendrait-elle pas de nfs à qui on doit demander trois fois sync avant que les données ne soient renvoyées au serveur ?

Comme je l'ai dit, je n'ai pas eu de problèmes. D'ailleurs gcc 3.2 est très bien (par rapport au reste des 3.x). J'ai juste dû recompiler quelques truc comme mplayer que j'avais compilé à la main sous la 8.2 ou le module noyau nvidia, mais pour mon serveur, je n'ai rien eu à faire d'autre que l'upgrade.

Pour le kernel je sais pas trop, vu que je le recompile le mien donc j'utilise pas celui de mandrake. Mais je crois que le 2.4.19 livré dans la 9.0 est produit par gcc 3.2 (donc il est préférable de faire les modules avec ce même compilateur).

A propos de la glibc comme il n'y a pas eu de changement majeur je ne vois pas de raison pour qu'il y ait un problème, donc je n'y avais même pas pensé. En général je m'inquiète plutôt de savoir si j'aurai assez de place sur le disque pour charger tous les rpm.

J'ai fais l'upgrade depuis les CD que j'avais auparavant téléchargé (le 1 et 2). Je n'aime pas faire d'upgrade *complet* via Internet car si ma connexion plante j'ai peur du résultat (mais certains l'ont fait).

Oui.
J'ai upgradé trois machines de la 8.2 vers la 9 comme ça, dont mon serveur/routeur/firewall avec connection au net (avec un "urpmi --auto --auto-select") sans problèmes. Pour ma machine perso la connection au net a coupé (comme toutes les 24h voire plus si affinités), il a dit un truc du genre "impossible de charger les packages" et s'est arrêté. Quand je l'ai relancé comme les packages étaient déjà dans /var/cache ça a été assez vite (comme quand il ne reste "plus" que 300Mo ;).

Un bon conseil : choisir un miroir fiable. Il y en a qui ne tiennent pas trop la charge, surtout dans la semaine suivant une nouvelle version de mandrake.

Enfin, la plupart des gens ont pas trop envie que rpm aille foutre la merde dans leur fs (en particulier dans /etc).

rpm ne fout pas la merde dans /etc, puisqu'il fait des fichiers .rpmnew :

> ls /etc/*.rpmnew
/etc/inittab.rpmnew /etc/sysctl.conf.rpmnew

Et il te fait un petit avertissement du genre (si je me souviens bien) warning : toto created as toto.rpmnew lors de l'installation du package.

nous sommes au moins 5 à te dire que nous n'avons pas de problèmes.

6 :)
Et pourtant, je développe de l'opengl, j'utilise le dga pour lire les vidéos, et je switche régulièrement entre 2 sessions X (pour info j'ai une tnt2).

Bof, on ne perd pas grand chose en ne voyant pas le code des démos. Souvent difficile à réutiliser, pas très bien écrit (en deux jours à une compo) et pas portable (optimisé pour tourner dans quelques cas bien précis). L'intérêt d'une démo est de présenter des choses nouvelles, c'est-à-dire avoir une idée, après la réaliser c'est secondaire. En plus, je crois que les demomakers qui partagent leurs sources ce sont ceux qui ont les sources les mieux écrites, sinon ils les garderaient pour eux...

C'est vrai que ça peut aussi être vu comme une forme d'art, je n'y avais pas pensé mais ça se tient.

Si tu commences à lancer ton vi
Vim, s'il-te plaît ;)

Contrairement à une idée reçue colportée par beaucoup d'ignorants, le développement de jeu vidéo est surement la chose la plus difficile à faire en développement informatique, justement parce qu'il regroupe l'ensemble des créateurs informatiques et qu'il demande donc une *excellente* organisation.

Ici, mon poblème c'est que j'ai commencé plus ou moins tout seul, donc pas d'organisation nécessaire. En plus, je ne suis absolument pas compétent pour proposer un design de jeu, donc j'ai préféré laisser tout ça de côté. De toute manière, si je n'avais eu qu'un vague projet, personne ne serait venu m'aider, donc je crois que la solution que j'ai choisie fonctionne mieux (tu connais beaucoup de gens qui commenceraient à bosser sur un projet si ils n'ont que des promesses de code ?).

PS : je cherche un gentil organisateur, n'hésite pas à proposer tes compétences ;)

J'essaye de faire un jeu open source, ce qui pose quelques problèmes. J'ai donc quelques remarques/questions à vous soumettre :

D'abord, il faut trouver des graphistes/artistes 3d, ce qui est quelque chose de pas évident dans le monde linux. Dans mon cas ils ont commencé à s'intéresser à mon projet quand une version windows a fonctionné (merci SDL et OpenGL). J'en tire une première conclusion : il y a des gens motivés pour bosser sur des projets gratuits, mais ils ne sont pas tous sous linux (je pense qu'un portage MacOSX aiderait aussi, il m'a d'ailleurs été demandé). J'en déduis qu'il faut trouver un moyen pour les attirer sous linux, comme par exemple en leur proposant un soft de modélisation 3d qui déchire tout (ce point sera bientôt réglé, à mon sens l'ouverture des sources de blender et leur amélioration devrait permettre plus que simplement avoir un modeleur libre, à savoir montrer aux artistes qu'il y a un bon modeleur open source, qui en plus va être sûrement livré par défaut dans les prochaines distribs. Et ça c'est très important, un linux tout prêt à faire de la modélisation, on peut espérer attirer pas mal d'artistes comme ça).

Ensuite vient le problème de la licence à appliquer aux fichiers de données. Et là, il faudrait expliquer aux artistes les problèmes de licence (façon gpl, ce qui est très compliqué si on a déjà du mal avec toutes les subtilités des licences logicielles). Bref, on est content d'avoir des datas et on ne demande pas plus que d'avoir le droit de les distribuer gratuitement. Mais alors (première question) a-t-on le droit de les mettre dans le cvs sur savannah par exemple ? Je pense que non (dans le doute je m'abstiens) mais ce n'est spécifié nulle part (ou alors c'est bien caché ;).

Après se pose le problème de "dirriger" une équipe. Je trouve très difficile de donner à la fois une bonne motivation à ce projet, et en même temps de le faire tendre vers un but précis : je n'ai pas d'idée, même vague du design ou du gameplay, en bon informaticien que je suis je me contente en général de développer du code. Ma deuxième question est donc : quelqu'un sait-il comment s'y prendre ? Rédiger un genre de cahier des charges ? Il s'agit là non plus de contact entre développeurs (j'ai lu quelques écrits à ce sujet, ça ne m'a pas beaucoup aidé dans ce cas), mais d'un échange entre artistes et développeurs, ce qui est nettement moins évident. De plus, il me manque un concept original (c'est sûrement la chose qui manque aux jeux libres, puisqu'on voit beaucoup de refontes d'anciens jeux). D'ailleurs le manque d'originalité a l'air de s'étendre à tous les jeux ces derniers temps, les jeux libres pourraient donc se démarquer en proposant des concepts totalement nouveaux (cf ceci par exemple : http://www.ufoot.org/liquidwar/(...) ) .

Sinon, comme je l'ai déjà dit, je ne suis pas pour l'écriture d'un moteur 3d de plus sans données (principalement parce que c'est déjà fait). Mon but n'est pas du tout de refaire du déjà fait. Je pense néanmoins qu'il n'y a pas de moteur 3d totalement polyvalent avec lequel on peut faire tous les types de jeux, simplement parce qu'on peut toujours optimiser le rendu pour le type de jeu en question, et que des jeux différents demandent des caractéristique de rendu différentes, et visent un matériel différent.

Une idée à propos des sites de développement de jeux (du genre http://www.gamasutra.com/(...) , http://www.gamedev.net/(...) ou http://www.flipcode.net/(...)) : on y trouve souvent des artistes, mais peu de linuxiens, il faudrait peut-être que ceux-ci les fréquentent un peu plus, histoire d'attirer les artistes vers le monde libre. Si on leur montre que sous linux on développe aussi dex jeux, je pense que ça pourrait en intéresser certains (certes pas tous vu la tendance business de certains des sites en question). A ce propos, une bonne idée pour ceux qui cherchent des personnes motivées pour faire des modèles 3d pour des projets libres : les forums de http://www.elysiun.com/(...) , site sur la modélisation sous blender).

Encore une chose : le site de référence des jeux sous linux est à mon avis http://happypenguin.org/(...) plutôt que http://www.linuxgames.com(...) , puisqu'il présente l'avantage de parler de tous les jeux et pas uniquement des gros titres. Ca permet à un anonyme qui développe son truc dans son coin de passer en première page et ainsi d'avoir un peu de pub pour un projet qui démarre, ce qui m'a l'air plus dans l'esprit du libre, et qui ne l'empêche pas d'avoir aussi des infos sur les derniers gros hits commerciaux.