Krunch a écrit 4025 commentaires

T'as lu le journal ?

Le journal qui a duré le plus longtemps l'a été grâce à une panne de DLFP mais le deuxième, visiblement pas. Pour le reste, j'ai pas tenté de tenir compte de cet effet (information un peu pénible à récolter et à intégrer dans l'analyse) mais vu que, comme tu le signales, c'est pas courant, ça ne devrait pas avoir un impact très significatif.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

$ awk '{print $2 " " $4}' journals-top-time.txt > journalcomments-top-time.txt
$ echo 'cor(read.table("journals-comments-top-time.txt"), use="pairwise.complete.obs")' | R --vanilla --quiet
> cor(read.table("journals-comments-top-time.txt"), use="pairwise.complete.obs")
          V1        V2
V1 1.0000000 0.2441202
V2 0.2441202 1.0000000
>

D'autres questions ?

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Apparemment, même dans le film, ils racontent la fin au début :

The second decision I made was to give that information about the surprise at the end from the start. In my script we know who Mazer Rackham really is and we know what is at stake as Ender plays his games. But Ender doesn't know, so I think the suspense is actually increased because the audience knows we're about the business of saving the world and that everything depends on this child not understanding that. We care all the more about whether he wins – and we worry that he might not want to. As we watch the adults struggle to get control of Ender, we pity him because of what's happening to him, but we want the adults to succeed. I think it makes for a much more complex and fascinating film than it would have been if I had tried to keep secrets."

http://en.wikipedia.org/wiki/Ender's_Game_(film)#Development

Par ailleurs je propose de lancer un fil de 200 commentaires sur l'homophobie reconnue de l'auteur et le boycott du film par divers groupes.

http://en.wikipedia.org/wiki/Orson_Scott_Card#Views_about_homosexuality
http://en.wikipedia.org/wiki/Ender's_Game_(film)#Controversy

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Je viens de retomber sur mes graphes de détection de cyborgs. Ça date un peu mais bon :

http://fruli.krunch.be/~krunch/pics/dlfpborgs/

Dans mon souvenir il y en avait au moins un qui était relativement plat mais soit je me souviens mal, soit j'ai perdu ce graph spécifique.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Il n'y a pas vraiment de corrélation entre le temps passé en tête d'affiche et le nombre de commentaires. Ce journal est dans le top 250 de ceux qui sont restés en tête d'affiche le plus longtemps.

https://linuxfr.org/users/krunch/journaux/dlfp-journalyser-2-1-rester-au-top

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Je crois en l'interconnexion fondamentale de tout. Le mercredi est un critère déterminant, comme tout le reste.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Vous ne comprenez décidemment rien. Il s'agit d'un <i>teaser</i> pour mon journal de mercredi qui va dénoncer grave.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Ouioui, j'ai bien compris que t'es une feignasse qui attend que j'écrive le script pour toi. Peut-être un autre jour. Là je m'intéressais juste à savoir quand poster mon prochain journal.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Les heures des journaux les plus commentés semblent ressembler à ceci (par ordre croissant) :

16
22
9
18
0
10
13
2
20
12

Mais mon script fait des trucs bizarres et j'ai 4 Orvals dans le buffet donc je vais pas y mettre ma main à couper. Cela dit, ça me semble relativement peu intéressant.

Par contre tu me rappelles que j'ai toujours pas publié le script que j'avais écrit pour étudier l'heure d'activité des utilisateurs DLFP (le but étant de détecter les cyborgs qui sont actifs 24h/24 ; riez pas, il y en a).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Tout ce que dit FHS c'est que ça devrait sans doute être dans /srv : http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM

Pour le reste, tu fais comme tu veux. Personnellement j'aurais tendance à créer un répertoire par site, même s'il n'y en a qu'un seul. Ça permet d'étendre à plusieurs sites par la suite plus facilement.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

http://justdelete.me/

Bon, c'est juste les liens utiles mais il pourrait être intéressant de compléter ce site en référençant ce genre de scripts aussi.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

En ce qui concerne les futures nouveautés des prochaines versions du noyau on peut se tourner vers la page spécifique de la Fondation Linux. https://wiki.linuxfoundation.org/en/Linux_Weather_Forecast

Page sur laquelle on apprend que la version actuelle du noyau est la 2.6.28 qui est sortie le 24 décembre 2008.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Tu confonds pas avec la 3G des CPUs ?
https://linuxfr.org/users/mildred/journaux/surveillance-globale-une-realite-une-puce-3g-embarquee-dans-les-processeurs-intel

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Bah le micro tout pourri de mon laptop il capte jusque ~20kHZ d'après Audacity. J'aimerais pas transférer du pr0n comme ça mais pour faire passer des commandes prédéfinies ça devrait pas être un problème.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Et bientôt tu vas dire qu'il n'existe pas de code informatique malveillant. Personnellement, j'y crois pas.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Quand on lit la release note on voit ceci :

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.

Le bouton qui est contrôlé par le firware du portable ?

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Résister au reflashage du bios, je vois pas comment c'est possible.

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.

J'ai pas tout suivi non plus mais.

fonctionnelle, mais très (très) lente

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.

Voire aussi : http://en.wikipedia.org/wiki/Code_smell

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

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.

!((a -> b) -> (b -> a))

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

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.