Krunch a écrit 3860 commentaires

Ben ++ c'est un opérateur valide en C. En fait avec un char, ça va "overflower" seulement à 129 dans le pire des cas donc ça laisse de la marge. Et s'il ne faut pas de nombre négatif, un unsigned char ça peut aller aussi bien en allant jusqu'à 256. Normalement les opérations arithmétiques ne devraient pas poser problème. http://ccs.ucsd.edu/c/types.html#Basic%20Integer%20Types(...) Par ailleurs

The First Rule of Program Optimization:
        Don't do it.

The Second Rule of Program Optimization (for experts only!):
        Don't do it yet.
                -- Michael Jackson

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Effectivement: http://ccs.ucsd.edu/c/types.html#Enumerations(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Et donc celui qui prendra le moins de place est un char, pas un short int.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Je crois que le monsieur a envie de passer à LFS :)

Je suppose qu'un truc genre "urpmi bison" devrait lui sauver la vie.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Je dois être complétement à la bourre moi ;)

Je vois pas bien comment tu as pu faire pour supprimer tout ton /lib/modules/2.6.7/ accidentellement mais pour le repeupler le plus simple est probablement de réinstaller le package Debian qui les contient (tu gères tes noyaux avec make-kpkg pas vrai ?) ou des les copier "manuellement" (dpkg -x), sinon t'es bon pour recompiler tes modules.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Apparement personne n'en a parlé mais pour la visualisation d'images, moi j'aime bien PornView.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Je crois qu'ils ont un peu abandonné l'idée: http://www.theregister.co.uk/2003/03/03/microsoft_quits_opengl_boar(...)
http://developers.slashdot.org/comments.pl?sid=103472&cid=88163(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

L'utilisation des GPU pour autre chose que du graphisme a déjà été discuté plusieurs fois sur Slashdot, voici les deux premiers articles que j'ai retrouvé:
http://developers.slashdot.org/article.pl?sid=03/12/21/169200(...)
http://developers.slashdot.org/article.pl?sid=04/05/09/039204(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Et après je me demande pourquoi les jeux les plus "simples" s'affichent incorrectement sur ma S3...

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Ca faisait un moment que je l'attendais celui là. C'est juste dommage qu'apparement la syntaxe du programme ne suive pas celle de gzip et bzip2 (pareil pour rar d'ailleurs): un maximum d'option commune entre ces programmes serait quand même bien pratique (d'un autre côté suffit d'écrire un petit wrapper).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Ca dépend, on peut aussi considérer que des nouvelles météorites sont "crées" régulièrement et que le nombre total de météorites "disponibles" reste ~constant.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Dans le même genre:

FREEDOM OF SXXXCH

http://alive.atari.org/alive1/contest.html(...) (presque tout en bas)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

d'ici fin 2005 ou 2006 IBM ne vendra plus de MS

Et la marmotte...

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Je sais pas si c'est une bonne idée d'intégrer le meta serveur et le serveur dans le même programme. Tu pourrais faire en sorte que les meta serveurs soient juste des serveurs IRC appartenant au même réseau et sur lequel tu connectes les bots (un par meta serveur). De cette manière, qqun qui veut juste faire serveur n'a pas besoin de faire méta serveur et inversément. Sans compter que ça peut marcher sur un réseau IRC existant (si les conditions d'utilisation du réseau le permettent) et ceux qui veulent faire méta serveur peuvent utiliser n'importe quel ircd, il leur faut juste le bot qui va avec.

Je voudrais savoir s'il me serait possible de créer un chan connu de tous mes serveurs, comme cela personne ne perdra de bande passante et ça me permettrait de retrouver mes serveurs de manière décentralisée...

Ben oui c'est le principe des chans IRC en général.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Pour modifier un grand nombre d'images rapidement, il y a ImageMagick. Doit bien y avoir une option pour régler la compression de l'image aussi.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

W^X (et d'autres truc du même style) est implémenté dans OpenBSD et ce même pour les i386 ne supportant pas le bit NX si j'ai bien compris. Je ne sais pas où ça en est pour Linux.

http://cvs.openbsd.org/papers/bsdcan04/(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

http://linuxfr.org/~Ayrton/14943.html(...)
http://linuxfr.org/~Acetik/14946.html(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Si ton tableau est vraiment gros, le binaire risque d'être aussi assez gros. Il vaut peut-être mieux allouer la mêmoire dynamiquement au début du programme. Avec memset(3) ou memcpy(3) ça devrait être assez rapide. S'il n'est pas si gros que ça, tu peux le taper à la main (ou avec un petit coup de shell).

Sinon tu dois pouvoir faire ça avec un macro directement généré par le shell genre:

gcc -DBIG_TABLE=`for (( i=0; i < 1000 ; i++)) ; do echo -n '42, ' ; done` foo.c

et dans foo.c:

static int *big_table = { BIG_TABLE };

Ca doit aussi marcher dans un Makefile. Pour que quelques éléments soient initialisés différement, ben tu t'amuses à rajouter des if dans ton script shell. C'est pas très propre mais ça devrait marcher.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Pour l'éditeur, ce sera Emacs, donc aucun problème.

Oui mais non, pas besoin d'imposer un éditeur aux traducteurs. Si qqun veut te traduire ton programme, pas besoin de lui faire installer Emacs et ses 50Mo de dépendances (j'exagère à peine: apt me dit que si j'installe emacs ça va me prendre 42,4Mo en plus sur le disque).

Et je pensais à un fichier par traduction (mais peut-être que toi aussi).

Je connais pas gettext mais ça a quand même l'air d'être la solution la plus standard. Mais si c'est trop lourd à mettre en place, c'est vrai que c'est pas la peine non plus.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Plutôt que de mettre ces textes dans le code, il pourrait être plus pratique de les mettre dans un fichier séparé: un message par ligne et utilisation du fichier avec Tie::File (en standard dans Perl depuis 5.8.0). Suffit de faire correspondre le code d'erreur et le numéro de ligne. Je pense que c'est plus simple pour les non programmeurs qui auront à traduire les messages. Il faut juste avoir un éditeur de texte qui gère l'UTF-8 et affiche les numéros de ligne.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Surtout que si on utilise /dev/null avec un seul ">", le fichier ne risque pas de grossir en fait.

Hors sujet, moi ?

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Je pense que si tu fais ça comme ça il y a un risque que les IP des serveurs qui n'existent plus ne soient jamais effacés, ou que ça prenne beaucoup de temps pour que ça soit le cas. Il faudrait aussi que les serveurs (et les clients) vérifient chacunes des nouvelles adresses qu'ils reçoivent, ce qui peut prendre relativement beaucoup de temps, surtout si la liste est "bien" faite (longue et avec des IP qui ne vont pas répondre et donc besoin d'attendre le timeout à chaque fois par exemple). Tu peux évidemment ne vérifier que quelques adresses de manière aléatoire ou refuser de télécharger plus de X adresses à la fois mais alors ta liste est moins rapidement à jours.

Pour l'idée du serial comme pour les DNS, ça impliquerait qu'il y ai un serveur maitre unique pour qu'on ne se retrouve pas avec le même serial pour deux listes différentes. Pas vraiment une bonne idée à mon avis.

Quand j'y pense je me dis qu'un réseau IRC c'est encore la moins mauvaise solution si tu veux une liste fiable et à jour:
Le client télécharge une liste de meta serveurs IRC (ça peut se faire en une seule requète DNS) et se connecte à l'un d'eux aléatoirement puis rejoint un chan prédéfini. Un bot lui donne la liste des serveurs de jeux connus à son arrivée sur le chan. Quand un client se connecte à un serveur, il quitte le chan (et éventuellement le serveur). Quand un serveur est crée, il se connecte aussi au réseau IRC, rejoint un autre chan et signale aux bots des meta serveurs qu'il est un serveur. Un des meta serveurs vérifie qu'il y a bien un serveur à son adresse. Si c'est pas le cas, il kick le serveur du réseau. Si c'est le cas, il l'annonce sur le chan des joueurs, tout le monde met sa liste à jour et le serveur rejoint le chan des joueurs. Quand un serveur se déconnecte, tout le monde le retire de sa liste. Si un client n'arrive pas à se connecter à un des serveurs, il l'annonce sur un troisième chan et si ça n'a pas été fait depuis X secondes, un des bots vérifie l'état du serveur (réponse au client uniquement si le serveur existe, kick du serveur sinon).

Je crois que c'est la meilleure manière d'avoir une liste fiable vraiment à jours en consommant un minimum de bande passante pour tout le monde sans s'amuser à réecrire un protocole complet (je veux dire en utilisant directement TCP ou UDP). Enfin je ne connais pas vraiment le protocol IRC non plus donc il y a peut-être quelque chose qui m'échappe qui rende mon idée totalement inefficace.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Je pense que l'utilisation d'IRC n'est pas une mauvaise idée en soit: ça doit permettre notamment de répartir la charge "naturellement" puisqu'IRC permet l'utilisation de plusieurs serveurs et par rapport à un serveur web ça permet de mettre la liste des serveurs à jour sans avoir à établir une nouvelle connexion à chaque fois. Suffit de mettre la liste des meta serveurs (IRC) sur un meta meta serveur (HTTP) et d'en choisir un au hasard, de là on peut récupérer la liste des serveurs/joueurs avec les màj en continu. Je pense qu'un tel réseau serait plus solide qu'avec un serveur web centralisé unique.

Evidemment c'est clair qu'il vaut mieux que les admins du réseau IRC concerné soient d'accords mais pourquoi ne pas monter son propre réseau IRC dédié à cela plutôt que de s'amuser à réinventer un nouveau protocol ?

Au fait, c'est moi ou ya jamais personne sur le meta serveur netPanzer ? :)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Et quelques mois plus tard tu vas remarquer que ton /dev/null prend 3 Go sur le disque.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Je crois que c'est plutôt le total cumulé pour chaque événement. Genre 10000 personnes pour l'ouverture + 5000 pour les 200m cloche-pied + 6000 pour la pétanque +... = 4 milliard.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.