neologix a écrit 346 commentaires

Je crois qu'en France avec notre système de grande école on reste dans une vision très méritocratique scolaire, autrement dit être très bon à 20 ans en math est synonyme d'être bon tout court ce qui n'est évidemment pas vrai.

Tu pars du postulat que l'on cherche des "bons", mais je pense que le problème est bien pire. Dans les grandes entreprises françaises, comme en politique, personne n'est nommé pour ses compétences, mais bien par copinage et cooptation. C'est pour cela que nos entreprises, à l'image de notre gouvernement, sont gérées par des branquignols.

Par exemple ici :
http://secunia.com/advisories/product/21625/?task=statistics

Ce qui donne :
- IE 8 : 43
- Firefox 3.0.x : 161
- Firefox 3.5.x : 66
- Firefox 3.5.x : 16

Après, IE a des failles non patchées contrairement à Firefox, donc chacun est libre d'en penser ce qu'il veut.
Personnellement, j'ai l'impression qu'à part Chrome/Chromium qui sort du lot, tous les autres se valent à peu près (j'utilise konqueror).

Comme ça ce qui devait prendre 13h en natif prendra 24h dans ta VM, et tu n'auras plus de questions à te poser.

Je suis curieux de voir un exemple d'utilisation légitime de ce que tu décris ("plein de connexions..."). Même s'il en existe, 99% des gens qui utilisent fail2ban ne sont pas concernés, ils veulent juste se protéger contre une attaque brute force. Enfin, les avantages d'iptables:
- ça marche
- cela permet de réduire la charge réseau/CPU (les connexions ne sont pas établies, contrairement à fail2ban)
- cela protège contre les attaques très courtes (je suppose que fail2ban est lancé périodiquement, et de toute façon les tentatives de connexion ne sont pas écrites immédiatement dans les logs, sinon bonjour le remplissage et l'activité disque)

Donc je maintiens que dans 99% des cas, iptables doit être préféré à fail2ban...

Je ne me suis jamais penché sur fail2ban, mais d'après ce que je comprends c'est un hack ignoble qui parse les logs pour bannir des IP, alors qu'iptables est fait pour ça:
iptables -I INPUT -m hashlimit -m tcp -p tcp --dport 22 --hashlimit 1/min --hashlimit-mode srcip --hashlimit-name ssh -m state --state NEW -j ACCEPT

Maintenant je peux me tromper...

Pour les modérateurs : je ne sais pas si cela s'est déjà fait, mais est-il prévu des formes de sanction contre les auteurs de journaux post-it, publicitaires, etc ? Sans aller jusqu'au bannissement, une interdiction de posts/journaux pour X jours/semaines/mois pourrait peut-être en calmer certains...

On voit des drops, c'est donc que ça arrive jusqu'au driver...
Tu pourrais faire un "ethtool eth0" ?
Est-ce que tu pourrais aussi faire un "# modprobe -r r8169; modprobe r8169" et voir si ça fonctionne ?

Une carte réseau pcmcia coûte 15€.
Pour ton problème, il faudrait plus d'informations :
"ifconfig eth0", "ethtool -S eth0", "ethtool -d eth0", "tc qdisc ls dev eth0", "lspci -vx" pour le device ethernet, et les entrées intéressantes de /var/log/messages. Est-ce que les LEDs de la carte clignotent lorsque tu lances le client dhcp ?

Un wrapper tout simple pour lire/écrire directement dans une zone mémoire :
http://free-electrons.com/pub/mirror/devmem2.c

Pour plus d'informations sur MMIO/PIO, tu as ça :
http://free-electrons.com/doc/embedded_linux_kernel_and_driv(...)
section I/O memory and ports

On dirait qu'il oops dans le code chargé d'envoyer un neighbor discovery.
Si ça t'intéresse, voici comment voir exactement où il plante : http://kerneltrap.org/node/3648
La fonction n'est pas bien longue, il n'y a pas d'inline, ça devrait être relativement facile. Par contre après il faut remonter...

En fait, ça dépend de ce que tu veux faire. Le changement de priorité peut avoir du bon si tu ne veux pas qu'un thread ait la main trop souvent (oui, on peut aussi *baisser* la priorité d'un thread !)
Tu peux mettre la priorité que tu veux, à partir du moment où tu lui donnes une "policy" real-time, il aura toujours une priorité plus haute qu'un process normal (SCHED_OTHER).

Ensuite, pour éviter qu'un thread ne garde le processeur pour lui tout seul, il existe des mécanismes.
Certes, mais tout le monde n'a pas un shell lancé avec une priorité real-time sur sa machine...

De façon plus générale, du real-time pour une application graphique, c'est quand même bizarre. Son impression de latence de l'interface graphique est peut-être due justement au fait qu'il n'y a qu'un seul thread qui s'occupe de l'affichage et des calculs, et donc lorsqu'il mouline, l'interface n'est pas réactive.

Comme ça, si l'application boucle (ce qui arrive souvent avec les applications graphiques :-), tu es bon pour redémarrer la machine...

Il vaut mieux utiliser fchmod, en lui passant le file descriptor derrière le stream (man fileno). Parce que si tu fermes le fichier et changes les droits, il y a une race, surtout que le fichier est rendu exécutable (et probablement exécuté peu de temps après)...

Tu n'as pas de réponse parce que, comme ça, ça paraît vraiment étrange.
Pourrais-tu faire un "netstat -pa | grep python" lorsque tu lances ton script, pour voir si les données sont dans la recv-q du socket ?
Quelle taille font les données que tu envoies ? Parce que si elles sont supérieures à la taille de ton socket buffer, elles peuvent être droppées.
Que renvoie "sysctl -a | egrep 'wmem|rmem'" ?

Je profite de ce sujet pour poser une question qui me taraude depuis que j'ai vu UML à l'école : dans quel type de projet ces générateurs de code à partir d'UML sont-ils utilisés ? Pour quelqu'un qui, comme moi, utilise vim/gdb/valgrind comme environnement de développement, c'est assez mystérieux.

- le taux de chômage des femmes reste plus important
Certes. Comme les jeunes, les vieux, les malades...

- les femmes cadres sont payés 23% de moins que leurs collègues masculins.
Quel est l'importance des temps partiels dans ce chiffre ?

En moyenne, ramené au taux horaire, une femme gagnera 7% de moins qu'un homme, à poste et qualification égales.
Lorsqu'une femme est à temps partiel ou s'absente un an pour élever son enfant, il ne faut pas qu'elle s'attende à avoir la même progression qu'un homme. Ce n'est pas un reproche, c'est juste un fait. Cela s'applique aussi aux syndicalistes...

- seulement 20% des dirigeants d'entreprises sont des femmes
Plus de 70% des étudiants en médecine sont des femmes. Plus de 90% des dirigeants d'entreprise sortent de grandes écoles. Plus de 90% des sages-femmes sont des femmes.

- une femme avec enfants aura toujours plus de mal à trouver un travail qu'un homme
Encore une fois, c'est normal. Tout simplement parce que les deux sont difficiles à concilier. Le problème n'est pas la discrimination à l'embauche, mais la répartition des rôles au sein du couple.

- les jeunes filles ne sont pas orientées et/ou ne s'orientent pas vers les études d'informatique (seulement 10% des futures informaticiens belges sont des filles), pourquoi ?
Peut-être parce qu'elles ne sont pas intéressées ? Qui se plaint que l'écrasante majorité des étudiants en école de commerce/vétérinaire/médecine/psychologie soient des femmes ? Pourquoi la majorité des bodybuilders sont des hommes ?

- les pubs pour jeux vidéos, logiciels de développement montrent encore souvent des filles très court vêtues. (Il faudra m'expliquer en quoi ça joue sur la qualité du logiciel)
Tout à fait d'accord, c'est dégradant.

Il est fait pour ça.

C'est bien ça :
CONFIG_GRKERNSEC_PROC=y
CONFIG_GRKERNSEC_PROC_USER=y

Visiblement, ces options sont dues à grsecurity...
C'est Ubuntu qui installe ça par défaut, ou tu as choisi une installation "hardened" ?
Il y a peut-être moyen de le désactiver sans recompiler son noyau, google est ton ami :-)

Pour ce qui est du grep PROC /boot/config* je n'ai pas de répertoire config dans /boot, j'ai peut-être mal compris.

C'est pour voir la configuration du noyau qui tourne. Je pense qu'une option est activée qui fait que les accès à /proc/ sont restreints.
Tu n'as pas de fichier /boot/config* ?
Bon, je vois dans ton /proc que tu as config.gz, essaie donc un
zcat /proc/config.gz | grep PROC

OK, donc c'est le noyal qui restreint les entrées de /proc à l'uid du process. Je ne savais pas que ça existait...
Je vois que tu as apparmor, ça ne viendrait pas de là ? Que donne un grep PROC /boot/config* ?

Et en root ?
Que donnent un /bin/ps -eaf et ls /proc/ ?
Je vois que tu es connecté en ssh, c'est un serveur ? Connecté à internet ? Une VM ?

Comme le dit patrick_g, il y a des fois où on _doit_ avoir des pages contiguës en mémoire physique, par exemple lorsque tu communiques avec des périphériques/DMA (qui eux n'ont pas ce système de MMU/mémoire virtuelle ils attaquent directement le bus).
Ensuite, si tu regardes les sources du noyau, tu verras qu'on demande bien plus souvent des pages contiguës en mémoire physique qu'en mémoire virtuelle (kmalloc() vs kvmalloc()).
La raison est la même que pour le disque : contrairement à ce que tu pourrais croire, les accès mémoire ne sont pas gratuits, et il vaut mieux avoir des pages contiguës pour éviter des modifications de la table des pages et aussi pour profiter au mieux des caches offerts par le processeur (TLB). C'est toujours pareil, un accès séquentiel est toujours plus rapide qu'un acccès "aléatoire".
Voilà pourquoi on a besoin, et on préfère, des pages contiguës en mémoire (physique). C'est aussi pour cela qu'on préfère des allocations d'ordre pas trop gros, et que par exemple des stacks de 4K en kernel mode seraient sympa, car bien plus rapides et faciles à trouver (parce que pour le coup il faut qu'elles soient contiguës).

Et on peut voir çà dans /proc/buddyinfo:
Node 0, zone DMA 5 6 2 2 3 1 1 1 1 1 2
Node 0, zone Normal 298 237 32 3 7 3 0 0 0 1 1
Node 0, zone HighMem 0 716 6466 3866 1196 188 76 17 26 54 469

On voit le nombre de pages libres, par ordre (puissance de 2), dans les différentes zones de mémoire: DMA (<16M), NORMAL (<4G), HIGHMEM (>4G).

Tu as regardé si les longueurs de tes dépêches sont proportionnelles aux nombres de commits ? ;-)

Alors, si vous avez quelque chose de simple à me proposer pour avoir une courbe en ~30 secondes à partir d'un fichier texte ou .csv, je suis preneur.

Matlab (çapuecépalibre), ou Octave ( http://www.gnu.org/software/octave/ ).