Krunch a écrit 3953 commentaires

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.

Et je pense que la màj du logiciel proprement dit doit plutôt se faire au niveau de l'OS (cf apt, urpmi,...) plutôt que par application mais c'est totalement hors sujet.

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

Et la màj il va la chercher où ? Sur un serveur central...ça revient au même.

Pourquoi ne pas utiliser un DNS qui peut changer facilement, genre DynDNS, No-IP ou FreeDNS (je suppose qu'il y a moyen de se passer d'eux pour ça mais c'est probablement le plus facile) ? Tu gardes un serveur central mais son adresse IP peut changer facilement sans problème. Une autre idée est d'utiliser un chan IRC sur un serveur publique comme le fait netPanzer. Evidemment faut pas changer de chan ni de réseau IRC (comme l'a fait netPanzer aussi)...

Si tu veux vraiment décentraliser, doit y avoir moyen aussi. Essai de voir comment fonctionnent les réseaux P2P et d'appliquer...

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

Un gamer c'est un joueur dans le sens général, un player c'est plutôt un joueur précis. Par exemple "il nous manque un player pour le match de ce soir" mais "celui là avec son 5GHz et sa nVidia Radeon 1337 c'est un gamer". Enfin peut-être pas selon le dictionnaire mais je pense que c'est l'usage général sur l'internet des gamers.

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

C'est dur de choisir sa préférée. Dans le genre les plus courtes sont les meilleurs, j'aime bien celles-ci:

Recursion; n. see 'Recursion'

et

echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlb xq |dc

Par ailleurs ce sondage m'a donné envie de remettre ma page de fortunes à jour.

http://krunch.servebeer.com/~krunch/?pg=fortune(...)

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

Je suppose que ça doit être loggué quelque part dans /var/log/.

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

C'est passé dans un journal récemment.

http://www.punbb.org/(...)
http://linuxfr.org/~akauffmann/14864.html(...)

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

J'avais trouvé ça dans un article que j'ai du lire pour un cour d'économie politique:

la finalité réelle de l'entreprise [...] est non pas de distribuer les
bénéfices les plus élevés, mais d'innover, de créer des richesses,
d'offrir les produits et des services dont la société a besoin: le
profit est le moyen, non la fin de l'entreprise.
                -- Gilles Lipovetsky,
                "Le Débat", n°67, novembre-décembre 1991

Je pense pas que la recherche uniquement du profit puisse faire progresser grand chose.

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