neologix a écrit 346 commentaires

A ta place, je douterais plus de mon code que de l'ordonnanceur du noyau...

Je me pose une question : est-ce que ce ne serait pas le début d'un abandon de Python par Google ?
Ils estiment peut-être que les performances de Python ne sont pas suffisantes étant donnés leurs besoins et la montée en charge de leurs plate-formes.
Mais du coup quid de Unladen Swallow ?

Comme le C qui est traduit en assembleur.

Question stupide, mais qu'y a-t-il dans les répertoire ?
Le répertoire hs n'aurait pas de nombreux fichiers, une taille importante, un truc spécial ?

--malloc-fill=
Fills blocks allocated by malloc, new, etc, but not by calloc, with the specified byte. This can be useful when trying to shake out obscure memory corruption problems. The allocated area is still regarded by Memcheck as undefined -- this option only affects its contents.

--free-fill=
Fills blocks freed by free, delete, etc, with the specified byte value. This can be useful when trying to shake out obscure memory corruption problems. The freed area is still regarded by Memcheck as not valid for access -- this option only affects its contents.

Ces options peuvent-être utile dans ce genre de cas...

Alors que les Mac sont annoncés à 4 ou 5%, personnellement, je connais plus de Linuxiens que de Maceux.

Ca c'est un échantillion significatif :-)
Peut-être que si tu tournais sous Mac, tu connaîtrais plus de Maceux, non ?
Un médecin connaît plus de médecins, un enseignant connaît plus d'enseignants, etc.
Sans parler de la loi des grands nombres...

Source ?
Et je parle d'éxecution de code, pas de DoS ("remote holes")...
Il faut comparer ce qui est comparable : si tu compiles un noyau Linux avec juste le support de TCP/IP (pas d'IPv6, pas de bluetooth, pas de protocoles spéciaux), il ne doit pas y en avoir beaucoup, mais je peux me tromper.

J'attends toujours...
Il y a du monde pour crier au troll, mais plus personne pour argumenter, et donner une comparaison des vulnérabilités distantes des noyaux OpenBSD et Linux.
Je ne nie pas qu'OpenBSD fait énormément de boulot pour la sécurisation de leur système, mais je dis que leur accroche "Only two remote holes in the default install, in a heck of a long time!" est du pur marketing, parce qu'à périmètre égal, de nombreux autres systèmes peuvent en dire (presque) autant : j'ai l'impression que la plupart de ceux qui crient au troll et ont moinssé mon commentaire ne font pas la distinction entre vulnérabilité locale et distante, DoS et exécution de code.
A moins que quelqu'un ne me prouve que j'ai tort...

Source ?
Et je parle d'éxecution de code, pas de DoS ("remote holes")...
Il faut comparer ce qui est comparable : si tu compiles un noyau Linux avec juste le support de TCP/IP (pas d'IPv6, pas de bluetooth, pas de protocoles spéciaux), il ne doit pas y en avoir beaucoup, mais je peux me tromper.

Précisons aussi que l'installation par défaut ne démarre qu'OpenSSH...

On pourrait se baser sur kmemcheck :-) http://lwn.net/Articles/260068/

Classique :-)
Tu peux sauvegarder tes données, et changer ton dique...

Si les indicateurs qui posent problème sont de type pre-fail, et que les valeurs sont sous le seuil, c'est qu'il y a un problème. La colonne "when-failed" est faite pour cela.
Est-ce que tu as des alertes "pending sectors" ou des plaintes du noyau dans /var/log/messages ?
De toute façon, si ton Raw_Read_Error_Rate continue à augmenter comme ça, sauvegarde vite tes données...

C'est pour cela que dieu a créé la "make menuconfig" :
HZ, CONFIG_PREEMPT, HIGHMEM, 4KSTACKS...

J'avoue que qualifier le fonctionnement de SELinux de « maladroit » me laisse dubitatif, sachant que ce dernier a été conçu par la NSA, la plus grande concentration de mathématiciens au monde et dont le budget est supérieur à celui de la CIA.

Le problème de SELinux, c'est justement qu'il faudrait bosser à la NSA pour arriver à pondre une configuration correcte. Pour le commun des mortels, c'est impossible à gérer.

Ensuite, pour ce qui est du budget et de la concentration de génies à la CIA et à la NSA, il suffit de se renseigner sur les événements précédant 9/11 pour se rendre compte de leur incompétence...

C'est radical.

On dirait bien que c'est le disque.
Il faut surveiller les read error rate pour voir l'évolution, pour le moment ce n'est pas trop catastrophique. La seule chose à faire, c'est de sauvegarder tes données et attendre...

Il faudrait le résultat d'un "smartctl -a /dev/hdc" pour discriminer les causes d'erreur.

Il faudrait le résultat d'un "smartctl -a /dev/hdc" pour discriminer les causes possibles.

Il est possible que ton disque donne des signes de faiblesse...
As-tu jeté un oeil aux logs noyau ?
Lancé un check SMART ?

Une recette de cuisine c'est un genre d'algorithme non mathématique si je puis dire...
Z = 1/2X + 2/3Y...

Ah, comment traduis-tu "battre les blancs en neige" en termes mathématiques ?

Non, ce n'est pas la fin du monde.
Comme le départ de Con Kolivas...

Quelqu'un qui développe un ensemble de patchs sécuritaires qui dénigre les modèles de sécurité adoptés par tous les systèmes d'exploitation grand public
Etonnant, vraiment...

et ça tombe bien : le vélo c'est bon pour la santé...

Pas seulement, c'est aussi le moyen de transport avec le rendement mécanique le plus élevé. Il suffit de regarder le Tour de France.
...
On me dit dans mon oreillette qu'ils ne carburent pas qu'aux pâtes :-)

Contrairement à ce que tu pourrais penser, lorsque tu fais un free(), la mémoire n'est pas forcément libérée (i.e. retournée à l'OS, par exemple avec brk()).
La plupart des implémentations se contentent de marquer les blocs libérés comme disponibles pour d'autres malloc().
Exemple
$ cat test.c
#include <stdlib.h>
#include <stdio.h>

#define NB_CHUNKS 10024


int main(int argc, char *argv[])
{
int i;
void *tab[NB_CHUNKS];
char line[BUFSIZ];

puts("Before malloc");
fgets(line, sizeof(line), stdin);

for (i = 0; i < NB_CHUNKS; i++) {
tab[i] = malloc(1024);
}

puts("After malloc");
fgets(line, sizeof(line), stdin);

for (i = 0; i < NB_CHUNKS; i++) {
free(tab[i]);
}

puts("After free");
fgets(line, sizeof(line), stdin);

return 0;
}

Donne:
$ cat /proc/3130/maps | grep heap (avant malloc())
$ cat /proc/3130/maps | grep heap (après malloc(), avant free()
08557000-08f44000 rw-p 08557000 00:00 0 [heap]
$ cat /proc/3130/maps | grep heap (après free())
08557000-08578000 rw-p 08557000 00:00 0 [heap]

On voit que après malloc(), on a un tas de 08557000-08f44000 = 10407936 (grosso modo 10024*1024 plus deux/trois trucs).
Après free(), 08557000-08578000 = 135168

Justement, il peut le savoir, puisque le programmeur compare explicitement le pointeur à NULL !
C'est la toute la différence...