Since audio code is mp safe, establish isa(4) and pci(4) audio interrupts with the IPL_MPSAFE flag, so interrupt handlers don't need to wait for global kernel_lock.
Donc il y a visiblement un moyen de synchronisation plus fin que le verrou global du noyau.
il me semble que Theo de Raadt refusait l'abandon du Giant Lock car cela rendrait le code moins sur et plus difficile a auditer
{{référence nécessaire}}
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
J'ai pas trop cherché à savoir si cette histoire de badBIOS est « vraie » mais les techniques décrites semblent plausibles et toute personne intéressée ayant un peu de temps peut s'amuser à tenter de les reproduire. Assembler le tout en un logiciel cohérent n'est pas trivial mais c'est loin d'être de la science fiction.
D'un autre côté, Slenderman c'est des photos truquées et une belle histoire invérifiable. Pour le coup, je préfère http://www.scp-wiki.net/
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Bien souvent, quand awk est trop lent, Perl permet de résoudre le problème. Si tu veux juste tester en vitesse, il y a même a2p qui te permet de convertir un script awk en Perl. Après, si l'idée c'est d'apprendre awk ça ne t'avance pas beaucoup.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Je connais des gens très bien qui ont cette approche et dans certains cas ça a du sens. Si tu dois concevoir un système « entier » relativement monolithique qui n'a pas vraiment à s'intégrer avec autre chose, ça me semble pas une mauvaise idée de tout faire from scratch. Cependant, dès que tu dois avoir un minimum de compatibilité ou intégration, il est souvent préférable de repartir de quelque chose d'existant.
Il semble effectivement que beaucoup de développeurs préfèrent écrire du nouveau code plutôt que de maintenir/modifier du code existant mais je pense que c'est généralement parce que la vaste majorité du code existant est passablement pourri. Du coup, écrire encore plus de code pourri n'aide pas vraiment non plus.
Je pense que lire du code tiers est assez important pour se faire une idée de ce qu'est du code {in,}{maintenable,compréhensible} et apprendre des {erreurs,succès} des autres. Mais effectivement, c'est souvent plus difficile que d'écrire un truc from scratch.
Il existe plusieurs systèmes d'analyse de log qui permettent ce genre de chose mais typiquement ils se lancent à intervalle fixe (toutes les heures par exemple). Le premier qui me vient à l'esprit est logwatch mais il y en a d'autres.
Pour réagir en « temps réel » tu peux soit le faire toi même avec tail | grep par exemple. Alternativement il doit exister des trucs tout fait pour ça mais sans chercher je vois pas.
Une autre méthode pour remonter ces erreurs en temps réel est d'intercepter directement l'appel système qui pose problème soit via auditd (mais ça ne résoud pas le problème d'effectuer une action une fois que c'est remonté dans les logs), soit via SystemTap qui permet d'effectuer des actions arbitraires lorsqu'un événement spécifique (qui, du coup, n'est pas forcément un appel système) se produit.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Il existe plusieurs organisations qui effectuent des tests automatisés sur le noyau Linux. Le plus simple est d'utiliser des machines virtuelles. Évidemment cela ne permet pas de tout tester mais même pour les drivers de matériel, il suffit que l'hyperviseur sous-jacent supporte le {USB,PCI,VGA,…} passthrough pour que ça marche.
Après, automatiser les tests sur du baremetal, ça se fait aussi (je me suis occupé un moment d'une ferme d'une vingtaine de machines qui ne faisaient que ça, même si ce qu'on testait était plutôt un système complet incluant le noyau) mais je doute qu'il y ait une seule organisation qui s'occupe de tester tous les drivers.
Après, tu peux faire tous les tests automatisés que tu veux, ça vaut quand même la peine de faire des tests manuels en plus.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Premièrement, tu peux faire ton for sur une seule ligne :
$ for f in *.jpg ; do frob $f ; done
Deuxièmement, tu peux faire des commandes de plusieurs lignes dans le shell interactif :
$ for f in *.jpg
> do
> frob $f
> done
Troisièmement, le *.jpg va pauser des problèmes si tu as vraiment beaucoup d'images. Tu peux résoudre le problème en utilisant find comme mentionné ci-dessus.
Quatrièmement, tu peux diminuer significativement le temps d'exécution en consommant plus de CPU en parallélisant le tout :
$ find . -name '*.jpg' -print0 | xargs -0 -P 42 -I F -n 1 frob F
Quand « ça marche pas », en général il y a un fichier de log quelque part qui donne des indices. Bien souvent OpenSSH est configuré pour logguer ce qu'il fait dans un ou plusieurs fichiers. Tu peux aussi le lancer en mode de debug où il va tout afficher sur la sortie standard.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
quels sont les pièges à éviter; comment fait-on pour enseigner linux le plus simplement possible ? etc.
Tu cherches à enseigner l'informatique (Linux et Windows n'ont rien à voir) ? À former des sysadmins (qui vont devoir comprendre un minimum Linux) ? À évangéliser l'idéologie du Libre (les aspects techniques ou pratiques de Linux n'ont rien à voir) ? À enseigner des logiciels libres spécifiques (commencer par un noyau ou une distribution complète ne me semble pas le plus évident) ? À enseigner comment accéder au web avec une distribution GNU/Linux ?
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
il n'y a pas de références en C. Il n'y a que des pointeurs
Un pointeur étant une référence, si. On peut même faire des référence qui ne sont pas des pointeurs en C (genre un offset de struct ou un index de tableau).
Ceci peut probablement clarifier certaines choses : http://www.linuxatemyram.com/
Après, si tu penses qu'il y a quelque chose d'anormal, un sysrq-m ou les données équivalentes extraites depuis /proc devraient aider à diagnostiquer.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
J'ai forcé un fsck au reboot mais ça n'a rien changé.
Et il a dit quoi fsck exactement ? Parce que c'est bien le genre de truc qu'il est censé réparer. Après si tu veux le faire toi même, c'est debugfs (en admettant qu'on parle d'ext2/3/4).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Giant Lock
Posté par Krunch (site web personnel) . En réponse à la dépêche OpenBSD 5.4. Évalué à 2.
Quand on lit la release note on voit ceci :
Donc il y a visiblement un moyen de synchronisation plus fin que le verrou global du noyau.
{{référence nécessaire}}
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Un nouveau slenderman ?
Posté par Krunch (site web personnel) . En réponse au journal Rencontrez badbios le virus plus puissant que Stuxnet. Évalué à 2.
J'ai pas trop cherché à savoir si cette histoire de badBIOS est « vraie » mais les techniques décrites semblent plausibles et toute personne intéressée ayant un peu de temps peut s'amuser à tenter de les reproduire. Assembler le tout en un logiciel cohérent n'est pas trivial mais c'est loin d'être de la science fiction.
D'un autre côté, Slenderman c'est des photos truquées et une belle histoire invérifiable. Pour le coup, je préfère http://www.scp-wiki.net/
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Fake
Posté par Krunch (site web personnel) . En réponse au journal Rencontrez badbios le virus plus puissant que Stuxnet. Évalué à 10.
Le bouton qui est contrôlé par le firware du portable ?
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Well listen, let the police do the job, be sure I'll give you answer as soon as possible okay?
Posté par Krunch (site web personnel) . En réponse au journal Rencontrez badbios le virus plus puissant que Stuxnet. Évalué à 6.
Suffit d'aller se mettre dans un autre firmware plus difficile d'accès et de recontaminer le BIOS au moment opportun. Voire par exemple https://www.sstic.org/2011/presentation/sticky_fingers_and_kbc_custom_shop/
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Perl
Posté par Krunch (site web personnel) . En réponse au message Extraction de données avec AWK. Évalué à 3.
J'ai pas tout suivi non plus mais.
Bien souvent, quand awk est trop lent, Perl permet de résoudre le problème. Si tu veux juste tester en vitesse, il y a même a2p qui te permet de convertir un script awk en Perl. Après, si l'idée c'est d'apprendre awk ça ne t'avance pas beaucoup.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# ça dépend
Posté par Krunch (site web personnel) . En réponse au message Rôle du développeur et son "cœur de métier". Évalué à 4.
Je connais des gens très bien qui ont cette approche et dans certains cas ça a du sens. Si tu dois concevoir un système « entier » relativement monolithique qui n'a pas vraiment à s'intégrer avec autre chose, ça me semble pas une mauvaise idée de tout faire from scratch. Cependant, dès que tu dois avoir un minimum de compatibilité ou intégration, il est souvent préférable de repartir de quelque chose d'existant.
Il semble effectivement que beaucoup de développeurs préfèrent écrire du nouveau code plutôt que de maintenir/modifier du code existant mais je pense que c'est généralement parce que la vaste majorité du code existant est passablement pourri. Du coup, écrire encore plus de code pourri n'aide pas vraiment non plus.
Je pense que lire du code tiers est assez important pour se faire une idée de ce qu'est du code {in,}{maintenable,compréhensible} et apprendre des {erreurs,succès} des autres. Mais effectivement, c'est souvent plus difficile que d'écrire un truc from scratch.
Voire aussi : http://en.wikipedia.org/wiki/Code_smell
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# logwatch, tail|grep ou SystemTap
Posté par Krunch (site web personnel) . En réponse au message Apache : exécuter un script après qu'une erreur ait été enregistrée dans error.log. Évalué à 3.
Il existe plusieurs systèmes d'analyse de log qui permettent ce genre de chose mais typiquement ils se lancent à intervalle fixe (toutes les heures par exemple). Le premier qui me vient à l'esprit est logwatch mais il y en a d'autres.
Pour réagir en « temps réel » tu peux soit le faire toi même avec tail | grep par exemple. Alternativement il doit exister des trucs tout fait pour ça mais sans chercher je vois pas.
Une autre méthode pour remonter ces erreurs en temps réel est d'intercepter directement l'appel système qui pose problème soit via auditd (mais ça ne résoud pas le problème d'effectuer une action une fois que c'est remonté dans les logs), soit via SystemTap qui permet d'effectuer des actions arbitraires lorsqu'un événement spécifique (qui, du coup, n'est pas forcément un appel système) se produit.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# virt
Posté par Krunch (site web personnel) . En réponse au message Le kernel linux il est testé à la main ?. Évalué à 7.
Il existe plusieurs organisations qui effectuent des tests automatisés sur le noyau Linux. Le plus simple est d'utiliser des machines virtuelles. Évidemment cela ne permet pas de tout tester mais même pour les drivers de matériel, il suffit que l'hyperviseur sous-jacent supporte le {USB,PCI,VGA,…} passthrough pour que ça marche.
Après, automatiser les tests sur du baremetal, ça se fait aussi (je me suis occupé un moment d'une ferme d'une vingtaine de machines qui ne faisaient que ça, même si ce qu'on testait était plutôt un système complet incluant le noyau) mais je doute qu'il y ait une seule organisation qui s'occupe de tester tous les drivers.
Après, tu peux faire tous les tests automatisés que tu veux, ça vaut quand même la peine de faire des tests manuels en plus.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # logic for dummies
Posté par Krunch (site web personnel) . En réponse au message Éviter les boucles avec des syntaxes de gourou. Évalué à 2.
!((a -> b) -> (b -> a))
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# sh 101
Posté par Krunch (site web personnel) . En réponse au message Éviter les boucles avec des syntaxes de gourou. Évalué à 7.
Premièrement, tu peux faire ton for sur une seule ligne :
Deuxièmement, tu peux faire des commandes de plusieurs lignes dans le shell interactif :
Troisièmement, le *.jpg va pauser des problèmes si tu as vraiment beaucoup d'images. Tu peux résoudre le problème en utilisant find comme mentionné ci-dessus.
Quatrièmement, tu peux diminuer significativement le temps d'exécution en consommant plus de CPU en parallélisant le tout :
Il y a aussi GNU Parallel qui peut être utile mais tout ce que j'en connais vient de dépèches DLFP : http://www.gnu.org/software/parallel/
Tous ces exemples supposent l'utilisation de Bash, GNU coreutils et GNU find.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# \n
Posté par Krunch (site web personnel) . En réponse au message CryptoJS, PyCrypto et OpenSSL sont dans un bateau…. Évalué à 2.
C'est pas encore ça mais bon.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# diagnostiquer
Posté par Krunch (site web personnel) . En réponse au message Serveur web : sftp. Évalué à 2.
Quand « ça marche pas », en général il y a un fichier de log quelque part qui donne des indices. Bien souvent OpenSSH est configuré pour logguer ce qu'il fait dans un ou plusieurs fichiers. Tu peux aussi le lancer en mode de debug où il va tout afficher sur la sortie standard.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# de rien
Posté par Krunch (site web personnel) . En réponse au message Cherche gestionnaire de paquets . Évalué à 4.
http://en.wikipedia.org/wiki/List_of_software_package_management_systems
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# peut-être
Posté par Krunch (site web personnel) . En réponse au message Eteindre logiciellement un disque dur. Évalué à 10.
man hdparm
Par ailleurs, considérer un disque défectueux comme périphérique de sauvegarde me semble passablement foireux.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# nazisme
Posté par Krunch (site web personnel) . En réponse à la dépêche Entretien avec François Tigeot, développeur DragonFly BSD. Évalué à 5.
Il manque une espace insécable avant le troisième et quatrième deux-points de la deuxième question.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# c'est beau l'enthousiasme
Posté par Krunch (site web personnel) . En réponse au journal Comment apprend-on Linux à des néophytes.. Évalué à 7.
Il y a les gens de Framasoft qui maintiennent un annuaire des logiciels libres : http://www.framasoft.net/rubrique2.html
Tu cherches à enseigner l'informatique (Linux et Windows n'ont rien à voir) ? À former des sysadmins (qui vont devoir comprendre un minimum Linux) ? À évangéliser l'idéologie du Libre (les aspects techniques ou pratiques de Linux n'ont rien à voir) ? À enseigner des logiciels libres spécifiques (commencer par un noyau ou une distribution complète ne me semble pas le plus évident) ? À enseigner comment accéder au web avec une distribution GNU/Linux ?
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: référence
Posté par Krunch (site web personnel) . En réponse au message Passage par référence. Évalué à 2.
Un pointeur étant une référence, si. On peut même faire des référence qui ne sont pas des pointeurs en C (genre un offset de struct ou un index de tableau).
http://en.wikipedia.org/wiki/Reference_(computer_science)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# get data
Posté par Krunch (site web personnel) . En réponse au message Performance NFS. Évalué à 2.
http://bl0rg.krunch.be/nfs-perfs.html
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# pom
Posté par Krunch (site web personnel) . En réponse au message Script d'extraction de données d'un .pcap. Évalué à 2.
http://packet-o-matic.org/
http://wiki.packet-o-matic.org/pom-ng/getting_started
Sinon tu peux aussi t'amuser avec tshark|awk ou quoi.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# rootkit != exploit
Posté par Krunch (site web personnel) . En réponse au journal Bash tactic: un nouveau 0day linux. Phear!!!. Évalué à 2.
Si tu trouves cet article stupide, ces liens vont aussi te paraître idiots.
http://www.insomniasec.com/downloads/publications/shellgame.pdf
http://stapbofh.krunch.be/
Mais moi j'aime bien.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Cachez ce sein que je ne saurait voir
Posté par Krunch (site web personnel) . En réponse à la dépêche Le programme de Google pour améliorer la sécurité des logiciels libres. Évalué à 3.
Comme ça ? https://linuxfr.org/users/mildred/journaux/surveillance-globale-une-realite-une-puce-3g-embarquee-dans-les-processeurs-intel#comment-1489169
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# oui mais non
Posté par Krunch (site web personnel) . En réponse au message Saturation mémoire. Évalué à 2.
Ceci peut probablement clarifier certaines choses : http://www.linuxatemyram.com/
Après, si tu penses qu'il y a quelque chose d'anormal, un sysrq-m ou les données équivalentes extraites depuis /proc devraient aider à diagnostiquer.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Ben voyons
Posté par Krunch (site web personnel) . En réponse à la dépêche GNU Make 4.0 extensible. Évalué à 7.
Les gens qui utilisent un éditeur de texte correct n'ont pas ce problème.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: quelle carte wifi?
Posté par Krunch (site web personnel) . En réponse au message Connexion wifi pas très stable. Évalué à 2.
Et au moins le dmesg correspondant à la déconnexion.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# fsck
Posté par Krunch (site web personnel) . En réponse au message corriger un filsystem. Évalué à 2.
Et il a dit quoi fsck exactement ? Parce que c'est bien le genre de truc qu'il est censé réparer. Après si tu veux le faire toi même, c'est debugfs (en admettant qu'on parle d'ext2/3/4).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.