Il me semble que d'après leurs tests, il vaut mieux avoir 2 cores à 50% que 1 à 100%. Les dev rust sortent des benches de temps à autres, mais la gestion de l'energie est primordiale pour eux, puisque l'une des cibles est les mobiles de dernières (et futures) générations avec >4 coeurs.
D'autre part, concernant le rendu parallèle de pages web, j'ai lu dans un article ou une conf (je ne retrouve pas la ref…) qu'ils sont "state of the art", au sens où aucun autre moteur n'est capable de gérer du rendu parallèle + avec les garanties offertes par le language.
Chez moi, pour un log de 170.000 lignes (25 Mo), ça met 3s avec journalctl, sur de l'ext4 sur un SSD, mais de toutes façons c'est côté CPU que ça pèche.
Au taff, je manipules des logs de plusieurs centaines de Mo, voir plusieurs Go avec cat, grep, sed… et tout est quasi instantanné.
Cependant, normalement, même quand le RAID est HS, le FS est toujours disponible (c'est le but du RAID). Ou alors les 2 disques sont HS
Pour voir tous les FS (donc ceux en read-only) :
mount Tu peux essayer de voir pourquoi il est passé en read-only dans dmesg ou /var/log/messages :
dmesg | grep -10 read-only
grep -10 read-only /var/log/messages*
Tu oublies le filesystem cache. Ajoutes ça au début de ta boucle :
echo 3 > /proc/sys/vm/drop_caches
De plus je ne vois pas où est utilisé ta variable "j" (ou alors c'est pour faire plusieurs essais ?). Tu ne voulais pas faire un "make -j 1", "make -j 2"… ? Comme dit plus bas, il faudrait remplir la queue, en utilisant un grand nombre de compilations parallèles, mais du coup, tu risques d'être limité par le CPU. Un bon gros "make -j 64" devrait suffire !
Dans le dernier cours de crypto que j'ai suivi, j'ai appris que justement c'est une faille assez sérieuse (si mes souvenirs sont bons…)
Au final c'est assez simple de "forcer" quelqu'un à déchiffrer/chiffrer un message précis (ou avec certains octets précis). Par exemple : je t'envoie un mail, je te force donc à déchiffrer l'intégralité de mon mail. Avec un peu de chance, tu vas me répondre, et je saurai que ton message contient "RCPT TO…" entre autres.
D'après mes tests c'est pareil en Java ou C : si tu écrit beaucoup de lignes, tu n'as aucune garantie d'écriture, il faut un OEL ou un flush pour être sûr que c'est écrit.
Le 2ème routeur n'est pas forcément en IP privée, les étoiles montrent juste qu'il ne répond pas au ping.
Dans tous les cas, il me semble pas que ce soit normal qu'il y ai une IP privée qui se balade comme ça.
Extrait de wikipedia :
"IP packets addressed by them cannot be transmitted onto the public Internet."
Sous Ubuntu, bash est installé par défaut.
Par contre, si je regarde ton "cat" je vois qu'une ligne est sautée au début du fichier. Est-ce que la ligne #!/bin/bash est bien la PREMIÈRE ligne du fichier ?
Si oui, tu dois pouvoir exécuter ton script avec ./mon_script : bash sera appelé automatiquement.
[^] # Re: Remarque à la c...
Posté par tatrefthekiller . En réponse à la dépêche Servo fin 2015 : où en est-on ?. Évalué à 2.
Il me semble que d'après leurs tests, il vaut mieux avoir 2 cores à 50% que 1 à 100%. Les dev rust sortent des benches de temps à autres, mais la gestion de l'energie est primordiale pour eux, puisque l'une des cibles est les mobiles de dernières (et futures) générations avec >4 coeurs.
http://blog.servo.org/2015/09/11/timing-energy/
D'autre part, concernant le rendu parallèle de pages web, j'ai lu dans un article ou une conf (je ne retrouve pas la ref…) qu'ils sont "state of the art", au sens où aucun autre moteur n'est capable de gérer du rendu parallèle + avec les garanties offertes par le language.
[^] # Re: Mais systemd le fait mal
Posté par tatrefthekiller . En réponse au journal Vivent les journaux binaires !. Évalué à 7. Dernière modification le 08 mai 2015 à 02:51.
Je trouve ça ridicule aussi :-)
Chez moi, pour un log de 170.000 lignes (25 Mo), ça met 3s avec journalctl, sur de l'ext4 sur un SSD, mais de toutes façons c'est côté CPU que ça pèche.
Au taff, je manipules des logs de plusieurs centaines de Mo, voir plusieurs Go avec cat, grep, sed… et tout est quasi instantanné.
[^] # Re: Suite
Posté par tatrefthekiller . En réponse au message Je ne peux plus executer de commande. Évalué à 1.
Cependant, normalement, même quand le RAID est HS, le FS est toujours disponible (c'est le but du RAID). Ou alors les 2 disques sont HS
Pour voir tous les FS (donc ceux en read-only) :
Tu peux essayer de voir pourquoi il est passé en read-only dans dmesg ou /var/log/messages :mount
dmesg | grep -10 read-only
grep -10 read-only /var/log/messages*
[^] # Re: Méthode de mesure.
Posté par tatrefthekiller . En réponse au journal Quand Pythran fait tourner du Python plus vite que du C++, c'est que.... Évalué à 2.
"time" permet de récupérer le temps CPU user, donc à priori assez indépendant vis-à-vis de l'exécution d'autres programmes sur la machine, non ?
[^] # Re: Une analyse du bug.
Posté par tatrefthekiller . En réponse à la dépêche Nouvelle vulnérabilité dans l’implémentation OpenSSL. Évalué à -2.
Je pense qu'il voulait dire : dépendre de la disposition des données dans la mémoire.
[^] # Re: noatime et deadline
Posté par tatrefthekiller . En réponse au journal Migrer vers un SSD simplement avec lvm. Évalué à 1.
Tu oublies le filesystem cache. Ajoutes ça au début de ta boucle :
echo 3 > /proc/sys/vm/drop_caches
De plus je ne vois pas où est utilisé ta variable "j" (ou alors c'est pour faire plusieurs essais ?). Tu ne voulais pas faire un "make -j 1", "make -j 2"… ? Comme dit plus bas, il faudrait remplir la queue, en utilisant un grand nombre de compilations parallèles, mais du coup, tu risques d'être limité par le CPU. Un bon gros "make -j 64" devrait suffire !
[^] # Re: Données forgées pour
Posté par tatrefthekiller . En réponse au journal Extraire une clé privée RSA par le son. Évalué à 3.
Arf oui, je raconte n'importe quoi.
Par contre pour la partie déchiffrement, la partie RCPT TO est effectivement chiffrée : http://en.wikipedia.org/wiki/SMTP-AUTH
Je ne voulais pas spécialement parler des mails, mon exemple était juste pour illustrer le fait de forger des données.
[^] # Re: Données forgées pour
Posté par tatrefthekiller . En réponse au journal Extraire une clé privée RSA par le son. Évalué à 4.
Dans le dernier cours de crypto que j'ai suivi, j'ai appris que justement c'est une faille assez sérieuse (si mes souvenirs sont bons…)
Au final c'est assez simple de "forcer" quelqu'un à déchiffrer/chiffrer un message précis (ou avec certains octets précis). Par exemple : je t'envoie un mail, je te force donc à déchiffrer l'intégralité de mon mail. Avec un peu de chance, tu vas me répondre, et je saurai que ton message contient "RCPT TO…" entre autres.
http://en.wikipedia.org/wiki/Chosen-plaintext_attack
[^] # Re: Je n'appelerais pas cela une piste...
Posté par tatrefthekiller . En réponse au message Commande su très très lente. Évalué à 1.
Il faut chercher quelques lignes plus haut un descripteur de fichier (fd) égal à 4. Sachant que sous Linux ça peut être aussi du réseau par ex :
Moi je parie sur un timeout DNS :-)
[^] # Re: Flush du buffer?
Posté par tatrefthekiller . En réponse au message sys.stdout.write() avec python3 : pas d'écriture tant que pas EOL ?. Évalué à 1.
D'après mes tests c'est pareil en Java ou C : si tu écrit beaucoup de lignes, tu n'as aucune garantie d'écriture, il faut un OEL ou un flush pour être sûr que c'est écrit.
[^] # Re: Shell que j'aime
Posté par tatrefthekiller . En réponse au message Executer un script ou un binaire à partir d'un CD/DVD. Évalué à 1.
[^] # Re: chez toi, chez eux, moitié/moitié ?
Posté par tatrefthekiller . En réponse au message Orange et les standards. Évalué à 0.
Dans tous les cas, il me semble pas que ce soit normal qu'il y ai une IP privée qui se balade comme ça.
Extrait de wikipedia :
"IP packets addressed by them cannot be transmitted onto the public Internet."
http://en.wikipedia.org/wiki/Private_network
[^] # Re: Ca existe déjà....
Posté par tatrefthekiller . En réponse au message Extraire les photos d'un scan. Évalué à 5.
http://www.gimptalk.com/forum/viewtopic.php?f=9&t=36438
[^] # Re: Ce n'est pas bash
Posté par tatrefthekiller . En réponse au message script bash , OK sous ubuntu 7.10 mais KO sous ubuntu 8.04. Évalué à 1.
Par contre, si je regarde ton "cat" je vois qu'une ligne est sautée au début du fichier. Est-ce que la ligne #!/bin/bash est bien la PREMIÈRE ligne du fichier ?
Si oui, tu dois pouvoir exécuter ton script avec ./mon_script : bash sera appelé automatiquement.