Krunch a écrit 3990 commentaires

Tu peux tenter de jouer avec les diverses options d'affichage plutôt que de t'obstiner sur l'ACPI qui n'a pas forcément de rapport. La première chose que je ferais serait de tenter de booter avec vga=ask puis de grepper kernel-parameters.txt pour video|FB|[Vv][Gg][Aa].

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

Si tu commences à bloquer par IP tout client qui envoit des requètes « bizarres » ça devient fort facile de faire bannir le site depuis toute bibliothèque, bureau ou autre endroit derrière du NAT. S'il n'y a pas une bonne raison pour faire ce genre de filtrage (« ça fait plein de lignes bizarres dans mes logs » n'est pas une bonne raison), ça ne me semble pas une super idée.

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

En lisant dmesg.c et associés, je suppute que le problème n'apparait pas quand tu passes -L=never ou que tu utilises une version de dmesg suffisamment ancienne pour ne pas avoir le support des couleurs.

La raison la plus évident pour que color_fdisable() segfault serait que stdout soit invalide mais je ne vois pas vraiment comment ça peut arriver dans dmesg.

Un strace (est-ce qu'il y a un close(1) avant le segfault ?) et le message exact quand le segfault a lieu hors de gdb (est-ce que ça crash sur une tentative de lecture de 0x0 ou de quelque chose de plus exotique) pourraient aider. Mais un core associé à l'exécutable avec symboles de debug serait sans doute le plus utile.

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

Tu peux toujours commencer par remonter le problème à ta distribution. Si tu arrives à reproduire le problème avec la dernière version upstream fraichement compilée sans patch tiers, il peut être utile de remonter le problème chez eux aussi mais le mainteneur du paquet dans ta distro devrait le faire de toute façon.

Ta distro dispose sans doute d'instructions expliquant quelles informations remonter quand tu ouvres un bug. La documentation du paquet lui même dispose peut-être aussi de ce genre d'instructions. J'ai cherché aucune des ces instructions, ce qui suit vient juste d'idées qui m'ont traversées l'esprit en lisant ton message.

$ uname -a
$ dmesg --version
$ env # surtout $TERM en fait

Vois si tu arrives à contourner le problème en utilisant diverses combinaisons des options de dmesg et en variant certains paramètres de l'environement (au sens général, pas au sens variables d'env). Que tu y arrives ou pas, l'information peut être utile à mettre dans le rapport de bug. Par exemple, est-ce que --clear fonctionne et est-ce que le problème persiste après ? Est-ce que le problème persiste après un reboot ? Est-ce que tu peux reproduire le problème avec différents shells, émulateurs de terminal et kernels ? Si c'était du x86 je suggèrerais de reproduire le problème avec Valgrind ou ElectricFence. Il existe sans doute des équivalents pour ARM que tu peux essayer.

Si ta distribution fourni les symboles de debug (debuginfo) pour le paquet correspondant, essaie de relancer gdb après les avoir installés.

Si ta distribution ne fourni pas les symboles de debug, tu peux recompiler le paquet avec CFLAGS+=-ggdb et ainsi récupérer un backtrace ou core plus informatif.

Si le problème est lié au contenu du ring buffer, tu peux tenter de le récupérer indépendamment avec un debugger noyau (crash(8) a une commande "dmesg" interne mais je suis sûr qu'il y en a d'autres).

Si les symboles de debugs ne sont pas disponibles et que recompiler n'est pas pratique, tu peux désassembler la fonction qui merde ("disass" dans gdb ou just objdump -D sur le binaire) et tenter de comprendre le problème comme ça. Avoir le code source correspondant sous les yeux aide beaucoup.

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

Ou au 31C3 en décembre https://events.ccc.de/congress/2014/wiki/Main_Page

Personnellement j'ai fait l'impasse sur les conférences cette années mais j'espère bien revoir plein de moules^WDLFPistes en février pour le FOSDEM et l'été prochain pour le Chaos Communication Camp (pas encore de dates annoncées ?).

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

Au final, vos PC sont destinés à être hacké et vous ne pouvez pas faire grand chose pour contrer cela.

C'est un peu le problème des conférences de sécurité. Ça a tendance à faire perdre espoir.

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

Cela donnerait envie de s'installer au Luxembourg ;-)

Pour deux jours par an ça me semble un petit peu excessif.

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

Note que si tu as apprécié la zone du dehors, je te suggère de jeter un oeil à {Red,Green,Blue} Mars de Kim Stanley Robinson. Personnellement j'ai abandonné au début du 3ème livre (et j'aurais pas ouvert le 2ème si on me l'avait pas prêté « de force »).

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

J'ai lu la zone du dehors et j'ai trouvé ça chiant. La horde du contrevent était dans ma liste pour après mais du coup je l'ai retiré.

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

Pour gérer les caractères multi-octets en C, on utiliser wprintf() et autre fonctions en w*() : http://pubs.opengroup.org/onlinepubs/009695399/functions/fwprintf.html

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

Je ne veux pas taper sur un auteur français, il n’y en a pas tant que ça, mais c’est lui que je lis en ce moment.

Personnellement j'ai pas trouvé d'auteur de science-fiction fran{çaise,cophone} dont j'ai eu envie de lire un deuxième livre.

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

Si l'idée c'est juste de sauver de l'espace, peut-être que tu pourrais considérer un système de fichiers qui supporte la déduplication. Selon ton système d'exploitation ça a l'air d'être implémenté dans Fossil, ZFS, NTFS, VxFS et Btrfs.

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

D'un autre côté, je sais pas si utiliser un domaine commun avec ton nom+prénom soit une très bonne idée, surtout si tu te retrouves à devoir le modifier subtilement. Je connais un Jean Dupont qui a pris jean.dupont@gmail.com et qui reçoit plein de mails adressé à un homonyme qui a en fait jean.dupon@gmail.com. Autant prendre directement jean@dupont.fr ou jean.dupont2014@gmail.com histoire que ça soit clairement distinguable.

Personnellement mon histoire avec gmail est décrite sur https://linuxfr.org/users/krunch/journaux/comment-je-ne-vais-pas-quitter-gmail
Au final mon adresse e-mail est de la forme prenom@nom.foobar et personne ne m'a jamais fait de remarque à ce sujet dans un cadre professionel ou autre (à part que certaines personnes ont un peu du mal avec le .foobar mais bon).

Pour ce qui est de l'avis des recruteurs, je pense que se différencier de la masse tout en restant « approprié » (ce qui varie beaucoup d'une boîte/personne à l'autre) est généralement une bonne idée. Idéalement, tu as une adresse très particulière qui a une connotation positive pour le recruteur. D'un autre côté, si tu en es à utiliser ce genre de trucs pour trouver un job, tu dois être assez désepéré :/

N.B. : Le Jean Dupont que je connais ne s'appelle évidemment pas Jean Dupont. Mon TLD n'est évidemment pas .foobar mais c'est un truc relativement obscure pour pas mal de gens.

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

Et comme conseil je dirais, quand tu postules essaies d'être plus spécifique que « je suis ouvert à toute proposition ». Les recruteurs aiment bien avoir affaire à des gens qui donnent l'impression de savoir où ils vont (même si c'est pas vrai).

Sinon j'aime bien les astuces listées ici même si je n'approuve pas forcément tout inconditionnellement : http://www.asktheheadhunter.com/crocs.htm

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

Tu te limites à une zone géographique particulière ou bien ?

Quelques trucs qui semblent coller :
https://www.google.com/about/careers/search#j=phd+statistics

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

Et sans rien d'autre que bash :

declare -A M ; while read k v ; do test -z ${M[$k]} && M[$k]=0  ; M[$k]=$((${M[$k]} + $v)) ; done < /tmp/y.txt ; for k in ${!M[@]} ; do echo $k ${M[$k]} ; done

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

Toujours sans cat :

cut -d' ' -f1 /tmp/y.txt | sort -u | xargs -n1 -IK awk '$1=="K"{s+=$2}END{print "K " s}' /tmp/y.txt

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

il doit y avoir des gens fortement mécontentés de cette situation chez Apple en ce moment

Surtout si certains de ces gens étaient ceux qui collectionnaient les dites photos. https://twitter.com/SwiftOnSecurity/status/506343548044578816

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

La nature de /dev/u?random est system-wide. Comment est-ce que tu imaginerais un système qui permettrait d'avoir un write_wakeup_treshold par processus ?

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

L'intérêt que je vois de faire ça au niveau noyau serait surtout de pouvoir éviter le polling de /proc/sys/kernel/random/entropy_avail. Tu pourrait t'arranger pour rajouter de l'entropie directement au fur et a mesure qu'elle est consommée et éviter ou grandement réduire les trous dans ton graph sans avoir a poller sans arret.

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

Est-ce que ce type de projet n'aurait pas plutôt sa place en tant que driver kernel ?

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

J'ai pas lu cette itération mais aller se mettre dans le firmware pour éviter la détection par l'OS c'est pas nouveau. Un papier sympa sur le sujet : https://www.sstic.org/2011/presentation/sticky_fingers_and_kbc_custom_shop/

À une époque c'était dans firewire qu'on a découvert une magnifique fai^{Wfonctionnalité.}

Je suis sûr qu'il y a eu d'autres proof of concept bien avant.

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

À noter que GNU sleep supporte les fractions de secondes. C'est plus discret de faire ralentir d'un dixième de secondes à la fois que d'une seconde.

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

Je suis assez fan de mod_autoindex et Make. Une petit peu de Bash et Markdown quand il faut vraiment.

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

Google c'est une entreprise. Linus Torvalds a inventé Android puis a fondé Google pour le commercialiser. C'est toi le noob.

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