Arf. :/
Elle sent quand-même mauvais le bug cette histoire-là…
Faudrait voir en 4.7 puis en current.

C'est prévu, je suis en train d'installer un snapshot de -current

Hé ben, l'option sticky-address est purement et simplement ignorée maintenant...

Argh. :/
T'as plus qu'à relancer sur openbsd-misc. J'espère que t'auras plus de chance ce coup-ci…

Yep, on verra bien. Merci à ceux qui ont essayé

Désolé Dargor, je n'ai pas eu beaucoup de temps (et je n'étais pas trop en état, lendemain de repas de famille oblige) pour réfléchir à ta question.

godrik : irc.deblan.fr est dans les choux, où c'est juste le ssl qui m'envoie balader ?

le server irc est dans les choux et les protocoles MSn semblent avoir changer. Je suis donc sans IM avec le monde civilise

dargor, c'est un plaisir.

mmm, on dirait que je vais devoir passer ma distribution en 64 bits pour pouvoir bosser. Salaud de physiciens qui m'envoient des logs de 2Go. Une fois que j'ai charge le probleme en memoire, il n'y a plus d'addresse virtuelle pour les structures de donnees de mon algo!

Heu… les noyaux -highmem c'est pas fait pour les chiens.

Sinon, commencer par minimiser la taille des logs conduira sans doute à de nombreuses corrections de bogues.

en fait le log, c'est un tableau de 2Go de float... et comme on va appliquer des algos pas lineaire dessus, il le faut vraiment en memoire...

Il me semble que meme avec un noyau highmem la section data du programme ne peut pas etre de plus de 2Go, isn't it ?

Aucune idée. Mais si une telle limitation existe, c'est pas clair que ce soit mieux avec un système 64 bits.

de toute facon j'ai beson de maintenir un tableau de meme taille. Donc si j'ai 2Go de float, j'aurais 2Go de structure de donnes et ca, ca fait 4Go, la taille de la memoire virtuelle. Donc je ne vais pas avoir trop le choix que de faire du 64bits. A moins d'utiliser plusieurs process et de streamer les donnees de l'un a l'autre. Mais ca ne va pas etre rigolo...

Je sais quelle est le moto à propos du 64 bits par ici, mais je dois m'inscrire en faux.

Alors, effectivement, ça ne sert peut-être à rien pour l'utilisateur standard. Par contre, ça fonctionne maintenant tout à fait aussi bien (par exemple, je n'ai pas du tout plus de problème avec flash, qui est souvent cité, en 64 bits qu'en 32 bits pour la même distrib). Mais dans des cas comme celui de godrik, c'est évite d'avoir à changer de noyau pour résoudre un problème qui aurait pu ne pas exister. Sans compter que s'il y a un cas où un noyau 64 bits apporte un gain de performance, c'est bien pour le calcul numérique (vu que le nombre de registres accessibles pouvant stocker des double est bien plus grand).

"Salaud de physiciens qui m'envoient des logs de 2Go."

En même temps, c'est à ça que servent les physiciens : à pousser les frontières de l'informatique. Souvenez-vous du web...

Il y a des problemes de drivers wifi qui ne sont distribue par les constructeur qu'en 32 bits.

J'ai installe ma machine en 32 bits a la base a cause de notre license pour pgi qui est 32 bits.

" "Salaud de physiciens qui m'envoient des logs de 2Go."

En même temps, c'est à ça que servent les physiciens : à pousser les frontières de l'informatique. Souvenez-vous du web... "

Je sais bien. C'etait ironique ! En vrai le log fait 500Go, mais je peux le traiter par batch de 2Go.

« Souvenez-vous du web... » tu confonds pas l'armée avec les physiciens là ?

Sinon, entre changer de noyau (2 minutes d'installation et un reboot) et réinstaller tout le système (plusieurs jours), mon choix est vite fait.

Enfin, le gain en performance, il reste à prouver, même sur du code numérique (rappelons que celui-là vient de physiciens, pas d'experts en micro-architecture).

Sortie de Slackware 13.1 http://linuxfr.org/2010/05/25/26892.html

Slackware *pincement au coeur et montée de nostalgie*

Attends la sortie de Zenwalk 6.4

Et Fedora 13 est sortie hier.

http://www.clubic.com/antivirus-securite-informatique/virus-hacker-piratage/phishing-hameconnage/actualite-342638-fini-phishing-place-tabjacking.html