Je ne connais pas php, mais j'ai l'impression que tu parses le fichier en entier pour chaque expression régulière/substitution: ce serait bien plus efficace de le lire ligne par ligne.
Peut-être parce qu'un process lancé par le Gnome fait des accès disque, ce qui empêche a mise en veille.
Pour trouver le coupable: /etc/init.d/klogd stop
echo 1 > /proc/sys/vm/block_dump
La seconde ligne permet de voir quel process accède au disque. La première sert à désactiver klogd, pour éviter que l'écriture du buffer sur le disque ne soit lui-même loggé, sinon ça part en boucle.
Les traces sont visibles avec 'dmesg'.
Faux.
La norme n'est pas floue, elle dit spécifiquement que ces cas sont "undefined", ce qui signifie que l'implémentation est libre de faire ce qu'elle veut.
En d'autres termes int a = 41;
a = a++;
printf("%d\n", a);
Peut aussi bien sortir "42" que "quarante deux". Ces expressions sont incorrectes.
il y a aussi la facilité de développement, la maintenabilité et le débugage.
A votre avis, qu'est-ce qui est le plus simple à coder et à débuger ?
Un noyau que l'on doit recompiler et relinker à chaque modification, ou alors des serveurs qui tournent en userland ?
Sous Linux, pour modifier la pile TCP/IP, on doit recompiler le noyal, redémarrer, et prier pour que la machine ne crashe pas. Si elle crashe, bonjour pour débugger.
Sous un micro-noyau, hop, on compile un serveur qui tourne en espace utilisateur, et que l'on peut débugger comme n'importe quelle application (gdb), et c'est parti. Pareil pour les modules : même si on peut les compiler et les charger à la volée, et bien ils peuvent toujours planter tout le système, et le débuggage n'a rien d'évident.
Avec la complexité croissante des architectures et pilotes modernes, je préfère avoir des centaines de milliers de lignes de code qui tournent en espace utilisateur qu'en mode noyau : on peut retourner le problème dans tous les sens, mais personne ne me fera trouver acceptable qu'un bug dans le pilote de ma webcam puisse planter ma machine ou flinguer le contenu de mon disque dur.
Et puis bon, pour soutenir ma thèse sur la facilité de développement, j'ai deux exemples de grand succès : Hurd et Minix :-)
Parce que dans un mutex c'est le même thread qui fait le lock/unlock alors que ce n'est pas le cas avec les sémaphore.
C'est vrai que c'est vachement intéressant un méchanisme de synchronisation dans le cas où les sections critiques ne peuvent être exécutées que par un seul thread...
Une application codée avec les pieds?
Si un programme a des problèmes de synchronisation, la lier à un CPU est un moyen rapide et simple de corriger le problème.
Je sais, c'est laid, mais Amarok a par exemple déjà utilisé ça (c'est une option de l'ordonnanceur, "CPU affinity") pour corriger des problèmes de race condition avec l'HT. cf. http://osdir.com/ml/kde.amarok.bugs/2005-10/msg00686.html
Je ne connais pas Scilab, mais j'ai toujours utilisé Octave, qui est un équivalent à Matlab, compatible avec sa syntaxe/scripts, et qui marche très bien. On peut faire des trucs marrants, comme fft, ondelettes, et plein d'autres trucs en utilisant les plugins octave-forge. Le seul truc qui manquait, la dernière fois que j'ai jeté un oeil, c'était une interface graphique (utile lorsqu'on a des figures).
A comparer à Scilab.
Les performances des micros noyaux?
Il faut arrêter, on n'est plus au temps de Minix 1...
Il y a eu _beaucoup_ de progrès, la diminution de performance est négligeable.
En ce qui concerne les ressources partagées, cela me rappele un poste de Linus, qui casse le mythe de la simplicité d'un micro-noyau par rapport à un noyau monolithique:
The fundamental result of access space separation is that
you can't share data structures. That means that you can't
share locking, it means that you must copy any shared data,
and that in turn means that you have a much harder time
handling coherency. All your algorithms basically end up
being distributed algorithms.
And anybody who tells you that distributed algorithms
are "simpler" is just so full of sh*t that it's not even
funny.
Microkernels are much harder to write and maintain
exactly because of this issue. You can do simple
things easily - and in particular, you can do things where
the information only passes in one direction quite easily,
but anythign else is much much harder, because there is
no "shared state" (by design). And in the absense of shared
state, you have a hell of a lot of problems trying to make
any decision that spans more than one entity in the
system.
Sinon, il y a tout plein de méchanisme de synchronisation granulaires dans le noyau : spinlock_t, spinlock_bh, rw_lock_t, ...
Le problème c'est qu'on ne peut pas employer n'importe quoi n'importe où (interruption, softirq, etc).
/proc/sys/vm/swappiness
C'est une valeur comprise entre 0 et 100, qui détermine l'utilisation de la swap : en gros, plus la valeur est élevée, plus le noyau aura tendance à swapper pour faire du cache (swappiness est utilisé dans le calcul de swap_tendancy). A 0, c'est l'inverse, tu swappes beaucoup moins.
L'inconvénient d'une swappiness élevée, c'est que si te regardes un dvd par exemple, ou que tu laisses tourner une appli un certain temps, le noyau va swapper pas mal de programme sur le disque. Résultat, lorsque tu redémarres une appli, il faut qu'il libère des pages en mémoire et charge de nouveau l'appli. Donc firefox met 15 sec. à démarrer.
A noter qu'il existait un patch de Con Kolivas swap-prefetch qui allait automatiquement rappatrier les pages swappées lorsque la mémoire se libérait.
Mais la mafia Linuxienne a refusé l'inclusion...
Donc, si tu veux éviter de swapper, tu mets une swappiness à 0, si tu veux maximiser les cache, tu la mets à 100.
ASLR n'est pas très utile.
Déjà, contrairement à ce qui est écrit, il ne rend aléatoire que les adresses dans la pile, et pas le tas (ils ont dû confondre avec les adresses renovoyées pa mmap() quisont, elles, aléatoires). On le voit dans l'article:
Lors d'un second lancement du même processus, nous constatons que l'adresse de la pile a effectivement changé et se trouve désormais entre 0xBF865000 et BxBF87B000 :
L'adresse de la pile a changé, pas celle du tas. On peut aussi le vérifier avec un programme du style:
/* test.c */
#include <stdlib.h>
#include <stdio.h>
int main(void)
{
int i;
int *p;
p = malloc(10 * sizeof(int));
/* pile */
printf("Dans la pile: %p\n", (void *)&i);
/* tas */
printf("Dans le tas: %p\n", (void *)p);
free(p);
return 0;
}
renvoie:
$ for i in `seq 1 10`; do ./test; done
Dans la pile: 0xbfe185cc
Dans le tas: 0x804a008
Dans la pile: 0xbf99c95c
Dans le tas: 0x804a008
Dans la pile: 0xbfd0d4cc
Dans le tas: 0x804a008
Dans la pile: 0xbf80afcc
Dans le tas: 0x804a008
Dans la pile: 0xbfe485fc
Dans le tas: 0x804a008
Dans la pile: 0xbfbf83ac
Dans le tas: 0x804a008
Dans la pile: 0xbff256dc
Dans le tas: 0x804a008
Dans la pile: 0xbff4df0c
Dans le tas: 0x804a008
Dans la pile: 0xbfa9824c
Dans le tas: 0x804a008
Dans la pile: 0xbfd4dd0c
Dans le tas: 0x804a008
Ensuite, "aléatoire" est un grand mot.
L'une des critiques quand il a été introduit est la suivante:
One of the biggest complaints that has been raised is that the amount of randomization is insufficient. The patches, as posted, vary the stack base within a 64KB area and the mmap() base within a 1MB range. Alignment requirements prevent just any address from being used with the result that only a relatively small number of possible base addresses exists. So a determined attacker could repeatedly run a hardcoded exploit with some assurance that, within a reasonable amount of time, the stack would land at the right place and the exploit would work. Placing a long series of no-op instructions at the beginning of the payload can also make an exploit more robust when faced with randomization.
En gros, la plage de valeur possible n'est pas très étendue, et quand on enlève les adressesquivontpas (alignement toussa...), et bien on se dit qu'il suffit de lancer l'exploit en boucle et au bout de peu de temps on va tomber sur une adresse qui correspond à celle codée dans l'exploit.
Voilà. Après, je ne pense pas qu'il y ait un inpact visible sur les performances. De toute façon, avec la rapidité des machines actuelles, j'en ai rien à foutre de perdre 10% de performances si j'ai un OS fiable et sûr. Une machine à laver marche 24/7, il devrait en être de même d'un ordinateur...
j'ai reçu la carte aujourd'hui.
Il m'a fallu 30 minutes pour l'installer:
1 minute pour la brancher, entrer le essid et la clé.
29 minutes pour m'apercevoir que je m'étais trompé dans la clé...
Donc c'est vraiment du plug and play, sauf si, comme moi, vous ne savez pas lire...
J'ai opté pour une MSI CB54G2 , qui fait partie des modèles recommandés par la FSF.
Pas de firmware à uploader, pas de programme userspace non plus.
Le pilot rt2500 ne fait pas encore partie du kernel vanilla, mais rt2x00 devrait être inclus dans le 2.6.25.
Tu as raison, ça mérite développement. Voici un de mes posts, consécutif au post d'un fanatique d'Ubuntu, une espèce qui prolifère plus vite que le chiendent.
Bon, je vais me faire moisser, mais là faut que ça sorte.
Ubuntu c'est de la merde.
J'en ai marre de voir tous ces clowns qui viennent pourrir les dépêches sur Debian/Mandriva/Fedora pour dire que Ubuntucestlameilleuredistro TM.
Elle est terriblement mauvaise.
Putain, c'est quoi cette idée d'installer sudo par défaut, et sans limitation? Un simple utilisateur peut planter tout le système, il n'y a plus de distinction user/root.
Ah, elle m'a bien fait rire aussi celle là: http://linuxfr.org/2006/03/13/20494.html
petit rappel: cette superbe distro mémorisait le mot de passe du premier utilisateur créé en clair dans les logs, lisible par tout le monde. Et comme je l'ai souligné, avec cette merde de sudo, ça revient à être root.
Ils ont dû bien se marrer chez Microsoft.
Ensuite: je l'ai fait essayer une fois à un ami, ça a été très drôle. Ces cons n'avaient pas mis la ligne "auto ethx" dans /etc/network/interfaces: résultat, pas d'internet. J'ai eu l'air malin quand j'a essayé d'expliquer qu'Ubuntu c'était l'une des distros les plus user-friendly.
C'est instable. Ouais, je suis désolé, ils incluent des paquets tellements récents que c'en est ridicule. Faut vraiment être dingue pour installer ça en production, j'ai plus confiance en une Debian experimentale.
C'est moche. Ouais je suis désolé, ce thème Benetton tout marron, c'est vraiment gerbant. C'est vrai, rien qu'à voir les screenshots je n'ai pas envie de la télécharger tellement c'est hideux, j'ai peur que mon graveur de cd me recrache la galette.
La philosophie est douteuse: c'est quoi l'histoire, Ubuntu c'est un moyen de promouvoir l'amitié entre les peuples? C'est une distro anti-apartheid? Sérieux, faut arrêter de déconner, c'est pas parce qu'on est libriste qu'on est baba-anarcho-communiste-pré-pubère.
Enfin, c'est néfaste pour le logiciel libre.
Bah ouais, qui va utiliser Mandriva et Fedora, hein? Ou même Debian, qui s'est fait pomper des développeurs, parce que c'est cool, chez Ubuntu y'a le père Noël Shuttleworth qui sponsorise tout ça. Les améliorations ne profitent quasiment pas à Debian, et pas à grand monde en fait.
Au lieu de lacher $10M pour une énième distro qui n'apporte rien, il aurait pu payer des développeurs du noyau, ou de gcc, ou de kde.
En plus, ils font tout pour simplifier l'installation de logiciels non-libres, ainsi que firmwares et pilotes.
Le 2.6.20 a résolu tous les problèmes que j'avais (carte son reconnue aléatoirement, usb qui déconnait une fois sur 5, pilote wifi instable). Maintenant, tout marche impec'. Pour moi, le 2.6.20 est le meilleur de la branche 2.6.
Malheureusement avec le kernel 2.6.20 (celui livré avec Ubuntu 7.04 "Feisty fawn" en tout cas)
Voilà ton problème. C'est aux distributeurs de faire correctement leur boulot d'intégration. Tu n'as qu'à utiliser une vraie distribution, et pas cette merde d'Ubuntu.
Un avertissement est souvent un bug potentiel. Un comparaison nombre entier naturel et nombre entier relatif peut être une source de bug (integer overflow). => gcc -Wall -Wextra. Je trouve ça complètement débile que "-Wall" n'affiche pas ALL (tous) les avertissements... (avec gcc < 4 : -Wall -W). Pour les fanatiques : -Werror bloque la compilation à chaque avertissement.
Moi aussi.
Mais la logique de la gcc team c'est qu'ils considèrent qu'un programme peut parfaitement être correct même s'il se mange des warnings avec les options qui ne sont pas activées par -Wall.
En gros, si tu as des warnings avec -Wall, tu sais (a priori) que tu as un problème. Avec ls autres options, il y a des chances que ça te fasse perdre ton temps. Ca dépend de ton degré d'extrêmisme...
Voilà.
Sachant que dès que tu as fini de jouer avec ton mot de passe, il faut l'écraser avec des 0 du genre memset(pass, 0, sizeof(pass)), pour éviter qu'il soit (en clair ou non) en mémoire, parce qu'un coredump par exemple c'est vite arrivé...
et j'en suis très satisfait.
Pour peu que l'on soit sous KDE, il requiert peu de dépendances, et est très rapide.
L'interface est claire, jolie, bien pensée. Quant aux fonctionnalités, il me permet de faire tout ce dont j'ai besoin, mais c'est vrai que je suis loin d'en faire une utilisation intensive.
En résumé, à essayer!
Bon, je ne connais pas le C++, mais je connais le C, alors pardon si je dis des conneries:
Un char fait huit bits de large
En C, c'est faux. Le standard te dit qu'il fait au moins 8 bits de large (pour stocker jusqu'à 2^7-1). Mais il peut faire plus.
Ensuite, tu peux également utiliser une tableau "unsigned char tableau [2];" et déposer tes valeurs directement dedans avec tableau[0] et et tableau[1]. Au moins tu es sûr que tes valeurs sont concaténées en mémoire, et dans le bon ordre. Sachant cela, tu n'as plus qu'à les lire comme s'il s'agissait d'un short, en utilisant un transtypage (cast) :
short result = *(short *)tableau;
Mauvaise idée...
Rien ne te dit comment les données sont alignées en mémoire. Pour la plupart des processeurs, les données doivent être alignées à une adresse spécifique (multiple de 2, ou 4 par exemple pour un long). Lorsque tu fais un cast comme ça, tu peux lui demander d'aller chercher un short à une adresse qu'il n'aime pas, et provoquer une erreur de segmentation.
C'est comme lorsque tu essaies de dépaqueter une structure:
cf: http://c-faq.com/strangeprob/ptralign.html
Les types ont une (bonne) raison d'exister: il ne faut pas utiliser un cast pour "prétendre que telle donnée est de tel type", ou pour demander au compilo de la fermer...
Je suis d'accord, c'est une connerie, surtout quand on touche à quelque chose d'aussi critique que netfilter. En plus, ça fait quand même quelques fois que je recompile mon noyau, je sais où se trouvent les différentes options, etc. C'est quand même dingue que je ne sois pas foutu de trouver ce qui cloche.
Généralement, j'évite d'adopter un noyau aussi récent, mais là c'est le meilleur depuis un long moment en ce qui me concerne (correction de bugs qui trainaient depuis un moment, amélioration du pilote wifi, etc). C'est dommage que ce soit gâché par ça...
# IRQ
Posté par neologix . En réponse au message 2.6.29-2 + CPU0 + mplayer = pas bonne idée ?. Évalué à 4.
Essayer avec différentes options (IRQ balancing, APIC/ACPI, etc).
Juste comme ça...
# complexité
Posté par neologix . En réponse au message Nettoyer un code HTML sale. Évalué à 1.
[^] # Re: Indices
Posté par neologix . En réponse au message Sortie de veille non désirée. Évalué à 2.
Pour trouver le coupable:
/etc/init.d/klogd stopecho 1 > /proc/sys/vm/block_dump
La seconde ligne permet de voir quel process accède au disque. La première sert à désactiver klogd, pour éviter que l'écriture du buffer sur le disque ne soit lui-même loggé, sinon ça part en boucle.
Les traces sont visibles avec 'dmesg'.
[^] # Re: Bug !!
Posté par neologix . En réponse au journal [SSD] Mesure de la latence d'écriture aléatoire sur disque. Évalué à 2.
Ne me dis pas essaye, car tu prouves le comportement de tel compilateur.
Il y a des tas de cas ou la norme est floue :
a = 2 * b++ - --b + c --;
maFct(fonctAApellerEnPremier(b),fonctAApellerEnDeuxieme(a));
Faux.
La norme n'est pas floue, elle dit spécifiquement que ces cas sont "undefined", ce qui signifie que l'implémentation est libre de faire ce qu'elle veut.
En d'autres termes
int a = 41;a = a++;
printf("%d\n", a);
Peut aussi bien sortir "42" que "quarante deux". Ces expressions sont incorrectes.
[^] # Re: iptables hashlimit
Posté par neologix . En réponse au message Empecher l'asspiration de site. Évalué à 1.
Maintenant, j'ai donné cette valeur au hasard, à toi de faire des tests pour trouver la valeur optimale.
# iptables hashlimit
Posté par neologix . En réponse au message Empecher l'asspiration de site. Évalué à 1.
# iptables -A INPUT --protocol tcp --destination-port 80 -m hashlimit --hashlimit-above 100 --hashlimit-mode srcip --hashlimit-name toto --jump DROPLimiter par IP source la connexion à 100 paquets/s sur le port 80.
# La fiabilité n'est pas le seul avantage des micro-noyaux...
Posté par neologix . En réponse à la dépêche MINIX 3 - Google Summer of Code. Évalué à 2.
A votre avis, qu'est-ce qui est le plus simple à coder et à débuger ?
Un noyau que l'on doit recompiler et relinker à chaque modification, ou alors des serveurs qui tournent en userland ?
Sous Linux, pour modifier la pile TCP/IP, on doit recompiler le noyal, redémarrer, et prier pour que la machine ne crashe pas. Si elle crashe, bonjour pour débugger.
Sous un micro-noyau, hop, on compile un serveur qui tourne en espace utilisateur, et que l'on peut débugger comme n'importe quelle application (gdb), et c'est parti. Pareil pour les modules : même si on peut les compiler et les charger à la volée, et bien ils peuvent toujours planter tout le système, et le débuggage n'a rien d'évident.
Avec la complexité croissante des architectures et pilotes modernes, je préfère avoir des centaines de milliers de lignes de code qui tournent en espace utilisateur qu'en mode noyau : on peut retourner le problème dans tous les sens, mais personne ne me fera trouver acceptable qu'un bug dans le pilote de ma webcam puisse planter ma machine ou flinguer le contenu de mon disque dur.
Et puis bon, pour soutenir ma thèse sur la facilité de développement, j'ai deux exemples de grand succès : Hurd et Minix :-)
[^] # Re: errata
Posté par neologix . En réponse à la dépêche Sortie du noyau Linux 2.6.26. Évalué à 3.
C'est vrai que c'est vachement intéressant un méchanisme de synchronisation dans le cas où les sections critiques ne peuvent être exécutées que par un seul thread...
[^] # Re: pourrait-on m'expliquer l'intéret ...
Posté par neologix . En réponse au message Outils pour le controle bas niveau des multicores. Évalué à 1.
Si un programme a des problèmes de synchronisation, la lier à un CPU est un moyen rapide et simple de corriger le problème.
Je sais, c'est laid, mais Amarok a par exemple déjà utilisé ça (c'est une option de l'ordonnanceur, "CPU affinity") pour corriger des problèmes de race condition avec l'HT. cf. http://osdir.com/ml/kde.amarok.bugs/2005-10/msg00686.html
Pour plus de détails, http://www.linuxjournal.com/article/6799
# Octave
Posté par neologix . En réponse à la dépêche Calcul scientifique : Scilab 5 enfin libre. Évalué à 6.
A comparer à Scilab.
[^] # Re: Et les micro noyaux type HURD ?
Posté par neologix . En réponse à la dépêche La fin du verrou global dans le noyau Linux ?. Évalué à 6.
Il faut arrêter, on n'est plus au temps de Minix 1...
Il y a eu _beaucoup_ de progrès, la diminution de performance est négligeable.
En ce qui concerne les ressources partagées, cela me rappele un poste de Linus, qui casse le mythe de la simplicité d'un micro-noyau par rapport à un noyau monolithique:
The fundamental result of access space separation is that
you can't share data structures. That means that you can't
share locking, it means that you must copy any shared data,
and that in turn means that you have a much harder time
handling coherency. All your algorithms basically end up
being distributed algorithms.
And anybody who tells you that distributed algorithms
are "simpler" is just so full of sh*t that it's not even
funny.
Microkernels are much harder to write and maintain
exactly because of this issue. You can do simple
things easily - and in particular, you can do things where
the information only passes in one direction quite easily,
but anythign else is much much harder, because there is
no "shared state" (by design). And in the absense of shared
state, you have a hell of a lot of problems trying to make
any decision that spans more than one entity in the
system.
Le reste ici : http://www.realworldtech.com/forums/index.cfm?action=detail&(...)
Sinon, il y a tout plein de méchanisme de synchronisation granulaires dans le noyau : spinlock_t, spinlock_bh, rw_lock_t, ...
Le problème c'est qu'on ne peut pas employer n'importe quoi n'importe où (interruption, softirq, etc).
# swappiness...
Posté par neologix . En réponse au message Swap ou pas swap, tel est la question.. Évalué à 3.
C'est une valeur comprise entre 0 et 100, qui détermine l'utilisation de la swap : en gros, plus la valeur est élevée, plus le noyau aura tendance à swapper pour faire du cache (swappiness est utilisé dans le calcul de swap_tendancy). A 0, c'est l'inverse, tu swappes beaucoup moins.
L'inconvénient d'une swappiness élevée, c'est que si te regardes un dvd par exemple, ou que tu laisses tourner une appli un certain temps, le noyau va swapper pas mal de programme sur le disque. Résultat, lorsque tu redémarres une appli, il faut qu'il libère des pages en mémoire et charge de nouveau l'appli. Donc firefox met 15 sec. à démarrer.
A noter qu'il existait un patch de Con Kolivas swap-prefetch qui allait automatiquement rappatrier les pages swappées lorsque la mémoire se libérait.
Mais la mafia Linuxienne a refusé l'inclusion...
Donc, si tu veux éviter de swapper, tu mets une swappiness à 0, si tu veux maximiser les cache, tu la mets à 100.
[^] # Re: L'ASLR ne sert à rien
Posté par neologix . En réponse à la dépêche Dossier sur le renforcement des fonctions de sécurité du noyau sur Secuobs.com. Évalué à 1.
Déjà, contrairement à ce qui est écrit, il ne rend aléatoire que les adresses dans la pile, et pas le tas (ils ont dû confondre avec les adresses renovoyées pa mmap() quisont, elles, aléatoires). On le voit dans l'article:
L'adresse de la pile a changé, pas celle du tas. On peut aussi le vérifier avec un programme du style:
/* test.c */
#include <stdlib.h>
#include <stdio.h>
int main(void)
{
int i;
int *p;
p = malloc(10 * sizeof(int));
/* pile */
printf("Dans la pile: %p\n", (void *)&i);
/* tas */
printf("Dans le tas: %p\n", (void *)p);
free(p);
return 0;
}
renvoie:
$ for i in `seq 1 10`; do ./test; done
Dans la pile: 0xbfe185cc
Dans le tas: 0x804a008
Dans la pile: 0xbf99c95c
Dans le tas: 0x804a008
Dans la pile: 0xbfd0d4cc
Dans le tas: 0x804a008
Dans la pile: 0xbf80afcc
Dans le tas: 0x804a008
Dans la pile: 0xbfe485fc
Dans le tas: 0x804a008
Dans la pile: 0xbfbf83ac
Dans le tas: 0x804a008
Dans la pile: 0xbff256dc
Dans le tas: 0x804a008
Dans la pile: 0xbff4df0c
Dans le tas: 0x804a008
Dans la pile: 0xbfa9824c
Dans le tas: 0x804a008
Dans la pile: 0xbfd4dd0c
Dans le tas: 0x804a008
Ensuite, "aléatoire" est un grand mot.
L'une des critiques quand il a été introduit est la suivante:
En gros, la plage de valeur possible n'est pas très étendue, et quand on enlève les adressesquivontpas (alignement toussa...), et bien on se dit qu'il suffit de lancer l'exploit en boucle et au bout de peu de temps on va tomber sur une adresse qui correspond à celle codée dans l'exploit.
Voilà. Après, je ne pense pas qu'il y ait un inpact visible sur les performances. De toute façon, avec la rapidité des machines actuelles, j'en ai rien à foutre de perdre 10% de performances si j'ai un OS fiable et sûr. Une machine à laver marche 24/7, il devrait en être de même d'un ordinateur...
[^] # fin
Posté par neologix . En réponse au journal Carte wifi support2e en natif. Évalué à 1.
Il m'a fallu 30 minutes pour l'installer:
1 minute pour la brancher, entrer le essid et la clé.
29 minutes pour m'apercevoir que je m'étais trompé dans la clé...
Donc c'est vraiment du plug and play, sauf si, comme moi, vous ne savez pas lire...
[^] # Re: ralink, la désilusion
Posté par neologix . En réponse au journal Carte wifi support2e en natif. Évalué à 5.
Pas de firmware à uploader, pas de programme userspace non plus.
Le pilot rt2500 ne fait pas encore partie du kernel vanilla, mais rt2x00 devrait être inclus dans le 2.6.25.
Voilà voilà...
# Refuse le CLUF
Posté par neologix . En réponse au message La vente liée interdite : comment le prouver et quel est le tort des revendeurs. Évalué à 1.
Tu démarres, et lorsque tu arrives au CLUF, tu refuses.
Si tu refuses la licence, ils sont tenus de te rembourser.
[^] # Re: Kernel 2.6.20 AUX CHIOTTES
Posté par neologix . En réponse à la dépêche Le noyau Linux 2.6.21 est disponible. Évalué à 0.
Je suis un intégriste, intolérant, aigri, et je déteste Ubuntu: tu aurais dû deviner que je tourne sous Debian...
Quel âge as-tu?
[^] # Re: Kernel 2.6.20 AUX CHIOTTES
Posté par neologix . En réponse à la dépêche Le noyau Linux 2.6.21 est disponible. Évalué à 3.
[^] # Re: Kernel 2.6.20 AUX CHIOTTES
Posté par neologix . En réponse à la dépêche Le noyau Linux 2.6.21 est disponible. Évalué à 5.
Voilà ton problème. C'est aux distributeurs de faire correctement leur boulot d'intégration. Tu n'as qu'à utiliser une vraie distribution, et pas cette merde d'Ubuntu.
[^] # Re: Mon expérience
Posté par neologix . En réponse au journal Programmation robuste. Évalué à 1.
Moi aussi.
Mais la logique de la gcc team c'est qu'ils considèrent qu'un programme peut parfaitement être correct même s'il se mange des warnings avec les options qui ne sont pas activées par -Wall.
En gros, si tu as des warnings avec -Wall, tu sais (a priori) que tu as un problème. Avec ls autres options, il y a des chances que ça te fasse perdre ton temps. Ca dépend de ton degré d'extrêmisme...
# man getpass()
Posté par neologix . En réponse au message Masquer stdout puis réafficher.. Évalué à 3.
Sachant que dès que tu as fini de jouer avec ton mot de passe, il faut l'écraser avec des 0 du genre memset(pass, 0, sizeof(pass)), pour éviter qu'il soit (en clair ou non) en mémoire, parce qu'un coredump par exemple c'est vite arrivé...
# Je l'utilise depuis quelques temps...
Posté par neologix . En réponse à la dépêche Sortie de digikam 0.9.1. Évalué à 6.
Pour peu que l'on soit sous KDE, il requiert peu de dépendances, et est très rapide.
L'interface est claire, jolie, bien pensée. Quant aux fonctionnalités, il me permet de faire tout ce dont j'ai besoin, mais c'est vrai que je suis loin d'en faire une utilisation intensive.
En résumé, à essayer!
[^] # Re: au hasard ...
Posté par neologix . En réponse au message deux char pour faire un short. Évalué à 1.
En C, c'est faux. Le standard te dit qu'il fait au moins 8 bits de large (pour stocker jusqu'à 2^7-1). Mais il peut faire plus.
Mauvaise idée...
Rien ne te dit comment les données sont alignées en mémoire. Pour la plupart des processeurs, les données doivent être alignées à une adresse spécifique (multiple de 2, ou 4 par exemple pour un long). Lorsque tu fais un cast comme ça, tu peux lui demander d'aller chercher un short à une adresse qu'il n'aime pas, et provoquer une erreur de segmentation.
C'est comme lorsque tu essaies de dépaqueter une structure:
cf: http://c-faq.com/strangeprob/ptralign.html
Les types ont une (bonne) raison d'exister: il ne faut pas utiliser un cast pour "prétendre que telle donnée est de tel type", ou pour demander au compilo de la fermer...
[^] # Re: netfilter
Posté par neologix . En réponse à la dépêche Sortie de Linux 2.6.20. Évalué à 3.
dans mon cas, c'est le "match state" qui avait dégagé:
networking->networking options->network packet filtering framework->core netfilter configuration->nefilter Xtables support->"state" match support
Je viens de vérifier, cette option était bien activée dans mon précédent .config (2.6.19), mais a dégagé ce coup ci. Mystère...
[^] # Re: netfilter
Posté par neologix . En réponse à la dépêche Sortie de Linux 2.6.20. Évalué à 2.
Généralement, j'évite d'adopter un noyau aussi récent, mais là c'est le meilleur depuis un long moment en ce qui me concerne (correction de bugs qui trainaient depuis un moment, amélioration du pilote wifi, etc). C'est dommage que ce soit gâché par ça...