Je sais qu'il existe kdump et kexec mais je n'ai encore jamais mis en œuvre ces mécanismes.
Bah il serait temps. Il est aussi possible que tu trouves des indices dans les logs kernels s'ils ont eu le temps d'être écrit sur le disque.
D'un autre côté, s'il s'agit effectivement de bugs du driver nvidia, même si tu diagnostiques exactement le problème, ça risque de ne pas t'avancer à grand chose.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Ben, disons que c'est dans la même veine qu'écrire sur 2 membres d'une union à la suite: ça marche, mais ça laisse présumer du meilleur… ou du pire.
Je ne suis pas d'accord. Cette histoire d'union est injustifiable. Les asserts sur les valeurs de retour dans le code de test me semble tout à fait valable. On pourrait faire mieux en définissant son propre assert qui ne soit pas désactivable avec NDEBUG et qui va printfer des infos pertinentes avant de faire rater le test mais utiliser assert(3) me semble tout à fait acceptable et requiert d'écrire/maintenir le minimum de code.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
C'est dommage que le ton de l'article ne soit pas un peu plus mesuré
D'un autre côté si tu viens chercher de l'objectif modéré dans un journal DLFP taggué coup_de_geule, tu n'es pas forcément au meilleur endroit.
ZeroMQ est utilisé à grande échelle par certaines entreprises
Je réitère donc mon opinion initiale à ce sujet : hahaha.
t'es tu intéressé aux branches 3.0 et 3.1 ?
Non. Le premier paquet maintenu que j'ai trouvé était 2.1.9 et le site web recommande 3.2.
[…] 𝆺𝅥𝅯 ton univers impitoyable ♩ […]
C'est beau mais inutilisable.
J'ai bien fait de pas m'y intéresser donc.
Il y a peut-être un compromis à trouver entre trop d'ouverture et la dictature ?
Certes. Et zmq ne l'a visiblement pas trouvé.
Je te trouve quand même très vocal sur un sujet aussi épineux alors que tu reconnais ne pas l'avoir vraiment suivi.
On m'a demandé mon avis, je le donne. Il m'arrive de me documenter sur l'histoire des projets qui m'intéressent mais zmq n'est pas un projet qui m'intéresse. J'ai juste eu à travailler avec et j'espère que le message est bien passé que je trouve que c'est de la merde.
Après les gens qui ont un avis différent et plus ou moins informé peuvent le donner en commentaire, dans un autre journal ou à la terrasse de leur café préféré.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
ni Steam ni Spotify ne devraient être décrits comme "une solution de DRM".
D'accord, appelons les des solutions de vente en ligne basées sur des logiciels privateurs incluant des dispositifs numérique des restrictions promouvant un monde de surveillance orwellien et allant à l'encontre de la notion de partage. C'est un peu plus long par contre.
À titre personnel, j'aimerai savoir si tu as une bonne raison d'associer la législation allemande et la possibilité de créer des comptes sans passer par un identifiant Facebook ?
< AC> Krunch, HA HA you tried to use zmq rcs
< AC> Krunch, and you looked at the current code
< AC> Krunch, zmq 3 is doomed.
< AC> Krunch, they have a new policy for contributions
< AC> Krunch, they have people reviewing merge request and checking that they follow rules
< AC> Krunch, those rules exclude things "the code builds"
< AC> *like
< AC> Krunch, $company actually submitted a patch that didn't build by mistake, and it got in
< Krunch> AC: i look forward to your comments in that journal
< AC> Krunch, nope :)
< Krunch> ok, i'll just copy/paste what you said earlier
< AC> Krunch, please don't
< Krunch> what you said is pertinent and i don't feel like paraphrasing; write up that comment yourself or i'll anonymise+paste
< AC> Krunch, if you remove any reference to my employer or myself, feel free :)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Ça dépend de ce que tu appelles « mode optimisé ». Tu peux avoir -O4 et -UNDEBUG.
Mais dans ce cas de toute façon c'est des tests. J'espère bien qu'ils sont pas compilés avec -DNDEBUG (et de fait, ils le sont pas quand on fait un "make check" puisqu'il y en a qui abort()ent).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Si ton « fork » n'a pas pour vocation d'être intégré au projet upstream, il peut être pratique de maintenir une « patch queue ». L'idée est que tu travailles sur une copie du repo upstream sans jamais rien y committer directement. Ce que tu committes sont des patches qui sont appliqués sur le repo. Tu as donc le repo upstream et un repo qui contient des patches.
En pratique, ça se fait avec quilt (git) ou mq (Mercurial).
Si le but à court terme c'est d'intégrer tes changements au projet upstream, il est peut-être plus simple de maintenir une branche que tu merges manuellement de temps en temps.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
DNS et GSSAPI sont souvent impliqués lorsque la connexion met « longtemps » à s'établir mais si les « freezes » se produisent pendant la session, il semble peu probable que ça soit lié.
Je suppose que le client reste réactif lorsque le problème se produit ? Ce qui signifie que le problème est soit au niveau réseau soit au niveau serveur. Si le load average reste effectivement proche de 0 juste après le problème, il semble plus probable que le réseau en soit la source.
Les idées qui me viennent à l'esprit pour tenter de diagnostiquer le problème seraient :
* pinguer le serveur en continu et voir s'il y a une augmentation de la latence ou des pertes de paquets lorsque le problème se produit ;
* tcpdumper des deux côtés jusqu'à ce que le problème se produise et voir lequel des deux arrète d'emettre lorsqu'il devrait (ou bien s'ils émettent tous les deux et qu'il y a des paquets qui se perdent) ;
* laisser tourner un truc genre "while true ; do date ; sleep 1 ; done > date.log" sur le serveur et voir si la séquence est ralentie lorsque le problème se produit ;
* ajouter des -v à ta ligne de commande ssh, relancer sshd en mode debug et voir si tu as des indices qui apparaissent lorsque le problème se produit ;
* stracer sshd et voir dans quel(s) appel(s) système(s) ça coince ;
* si tu peux obtenir un accès physique de manière pratique lorsque le problème se produit, essai de voir si la console locale est elle aussi « freezée » auquel cas tu pourrais commencer par un sysrq-t.
À partir de là, si tu n'as toujours pas trouvé tu devrais au moins savoir s'il s'agit d'un problème réseau (auquel cas tu peux éliminer les éléments intermédiaires jusqu'à trouver le fautif) ou local (auquel cas il va être temps d'apprendre à comprendre ce que strace et sysrq-t racontent).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
À proximité de chez moi j'ai accès à toutes les options proposées sauf: trolleybus, tramway sur pneumatique et téléporteur. Par ailleurs la gare qui est à 10 minutes de chez moi est apparemment la plus active d'Europe en nombre de trains.
Je suis aussi à 20 minutes à pieds d'un héliport.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Si on regarde la définition de hid_reset_resume un peu plus haut on voit qu'il retourne ce que hid_post_reset retourne. hid_post_reset quant à lui peut retourner 1 dans plusieurs cas, toujours après avoir appelé dbg_hid: http://lxr.linux.no/#linux+v3.6/drivers/hid/usbhid/hid-core.c#L1404
Soit tu fais en sorte que ton programme travaille dans l'encodage du fichier, soit tu convertis le fichier avant de le donner à ton programme. Dans tous les cas il faut connaitre l'encodage du fichier original pour pouvoir le traiter correctement. Il y a des heuristiques d'autodétection d'encodage mais c'est une juste une bonne recette pour se retrouver avec des corruptions « incompréhensibles ».
Voir aussi : iconv(1), iconv(3)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Vélo+métro quand il fait pas trop pourri et que mon vélo est en état.
Train+métro quand il pleut.
Vélo quand je me lève avant l'heure de pointe et qu'il fait pas trop pourri.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# vmcore or it didn't happen
Posté par Krunch (site web personnel) . En réponse au message Comment connaître l'origine d'un Kernel Panic depuis le mode graphique ?. Évalué à 4.
Bah il serait temps. Il est aussi possible que tu trouves des indices dans les logs kernels s'ils ont eu le temps d'être écrit sur le disque.
D'un autre côté, s'il s'agit effectivement de bugs du driver nvidia, même si tu diagnostiques exactement le problème, ça risque de ne pas t'avancer à grand chose.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: assert (rc != -1)
Posté par Krunch (site web personnel) . En réponse au journal ZeroMQ et les mangoustes. Évalué à 3.
Je ne suis pas d'accord. Cette histoire d'union est injustifiable. Les asserts sur les valeurs de retour dans le code de test me semble tout à fait valable. On pourrait faire mieux en définissant son propre assert qui ne soit pas désactivable avec NDEBUG et qui va printfer des infos pertinentes avant de faire rater le test mais utiliser assert(3) me semble tout à fait acceptable et requiert d'écrire/maintenir le minimum de code.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Dommage...
Posté par Krunch (site web personnel) . En réponse au journal ZeroMQ et les mangoustes. Évalué à 4.
D'un autre côté si tu viens chercher de l'objectif modéré dans un journal DLFP taggué coup_de_geule, tu n'es pas forcément au meilleur endroit.
Je réitère donc mon opinion initiale à ce sujet : hahaha.
Non. Le premier paquet maintenu que j'ai trouvé était 2.1.9 et le site web recommande 3.2.
J'ai bien fait de pas m'y intéresser donc.
Certes. Et zmq ne l'a visiblement pas trouvé.
On m'a demandé mon avis, je le donne. Il m'arrive de me documenter sur l'histoire des projets qui m'intéressent mais zmq n'est pas un projet qui m'intéresse. J'ai juste eu à travailler avec et j'espère que le message est bien passé que je trouve que c'est de la merde.
Après les gens qui ont un avis différent et plus ou moins informé peuvent le donner en commentaire, dans un autre journal ou à la terrasse de leur café préféré.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Publication de la décision
Posté par Krunch (site web personnel) . En réponse au journal Enfin !!!!. Évalué à 3.
L'article du blog du dit avocat : http://www.cuifavocats.com/Double-condamnation-de-SAMSUNG-la
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Ça tombe sur toi par hasard, tous les trolls open source m'énervent aujourd'hui
Posté par Krunch (site web personnel) . En réponse à la dépêche Les avancées des jeux pour GNU/Linux au mois d’octobre. Évalué à 7.
D'accord, appelons les des solutions de vente en ligne basées sur des logiciels privateurs incluant des dispositifs numérique des restrictions promouvant un monde de surveillance orwellien et allant à l'encontre de la notion de partage. C'est un peu plus long par contre.
Je vais juste laisser ça ici : http://www.wired.com/wiredenterprise/2012/11/cisco-vp-vows/
N'y voyez aucun rapport.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Mr X témoigne
Posté par Krunch (site web personnel) . En réponse au journal ZeroMQ et les mangoustes. Évalué à 10.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: assert (rc != -1)
Posté par Krunch (site web personnel) . En réponse au journal ZeroMQ et les mangoustes. Évalué à 10.
Pour les tests, je vois vraiment pas le problème. Ces asserts sont dans le code des tests, pas le code du produit lui même.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: assert (rc != -1)
Posté par Krunch (site web personnel) . En réponse au journal ZeroMQ et les mangoustes. Évalué à 2.
Ça dépend de ce que tu appelles « mode optimisé ». Tu peux avoir -O4 et -UNDEBUG.
Mais dans ce cas de toute façon c'est des tests. J'espère bien qu'ils sont pas compilés avec -DNDEBUG (et de fait, ils le sont pas quand on fait un "make check" puisqu'il y en a qui abort()ent).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: M'enfin !
Posté par Krunch (site web personnel) . En réponse au journal ZeroMQ et les mangoustes. Évalué à 3.
http://www.jwz.org/doc/cadt.html
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: M'enfin !
Posté par Krunch (site web personnel) . En réponse au journal ZeroMQ et les mangoustes. Évalué à 4.
Le premier article c'est http://www.joelonsoftware.com/items/2003/10/13.html
Le second est évident pour n'importe qui ayant passé plus de 5 minutes dans les sources du noyal.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Hello World concurrentiel
Posté par Krunch (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla‐bla #45. Évalué à 4.
Un peu trop long pour un commentaire : https://linuxfr.org/users/krunch/journaux/zeromq-et-les-mangoustes
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Hello World concurrentiel
Posté par Krunch (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla‐bla #45. Évalué à 1.
Hahaha.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Hello World concurrentiel
Posté par Krunch (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla‐bla #45. Évalué à 6.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Hello World concurrentiel
Posté par Krunch (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla‐bla #45. Évalué à 10.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# One operating system to rule them all
Posté par Krunch (site web personnel) . En réponse au journal Half-life 3 sera sous linux. UNIQUEMENT SOUS LINUX !. Évalué à 4.
http://openbsd.org/lyrics.html#52
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: mon avis
Posté par Krunch (site web personnel) . En réponse au journal Dépénalisation du cannabis. Qu'en pensez-vous ?. Évalué à 3.
J'ai rien suivi mais je ne trouverais pas moral d'emprisonner quelqu'un qui n'a pas eu un procés en bonne et dûe forme.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# patch queue
Posté par Krunch (site web personnel) . En réponse au message Forker un projet et le maintenir à jour. Évalué à 3.
Si ton « fork » n'a pas pour vocation d'être intégré au projet upstream, il peut être pratique de maintenir une « patch queue ». L'idée est que tu travailles sur une copie du repo upstream sans jamais rien y committer directement. Ce que tu committes sont des patches qui sont appliqués sur le repo. Tu as donc le repo upstream et un repo qui contient des patches.
En pratique, ça se fait avec quilt (git) ou mq (Mercurial).
Si le but à court terme c'est d'intégrer tes changements au projet upstream, il est peut-être plus simple de maintenir une branche que tu merges manuellement de temps en temps.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# -vvv, ping, tcpdump, strace, sysrq-t
Posté par Krunch (site web personnel) . En réponse au message latences invite de commande en connexion ssh. Évalué à 3. Dernière modification le 15 octobre 2012 à 20:38.
DNS et GSSAPI sont souvent impliqués lorsque la connexion met « longtemps » à s'établir mais si les « freezes » se produisent pendant la session, il semble peu probable que ça soit lié.
Je suppose que le client reste réactif lorsque le problème se produit ? Ce qui signifie que le problème est soit au niveau réseau soit au niveau serveur. Si le load average reste effectivement proche de 0 juste après le problème, il semble plus probable que le réseau en soit la source.
Les idées qui me viennent à l'esprit pour tenter de diagnostiquer le problème seraient :
* pinguer le serveur en continu et voir s'il y a une augmentation de la latence ou des pertes de paquets lorsque le problème se produit ;
* tcpdumper des deux côtés jusqu'à ce que le problème se produise et voir lequel des deux arrète d'emettre lorsqu'il devrait (ou bien s'ils émettent tous les deux et qu'il y a des paquets qui se perdent) ;
* laisser tourner un truc genre "while true ; do date ; sleep 1 ; done > date.log" sur le serveur et voir si la séquence est ralentie lorsque le problème se produit ;
* ajouter des -v à ta ligne de commande ssh, relancer sshd en mode debug et voir si tu as des indices qui apparaissent lorsque le problème se produit ;
* stracer sshd et voir dans quel(s) appel(s) système(s) ça coince ;
* si tu peux obtenir un accès physique de manière pratique lorsque le problème se produit, essai de voir si la console locale est elle aussi « freezée » auquel cas tu pourrais commencer par un sysrq-t.
À partir de là, si tu n'as toujours pas trouvé tu devrais au moins savoir s'il s'agit d'un problème réseau (auquel cas tu peux éliminer les éléments intermédiaires jusqu'à trouver le fautif) ou local (auquel cas il va être temps d'apprendre à comprendre ce que strace et sysrq-t racontent).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# ma vie
Posté par Krunch (site web personnel) . En réponse au sondage Transport en commun à proximité . Évalué à 2.
À proximité de chez moi j'ai accès à toutes les options proposées sauf: trolleybus, tramway sur pneumatique et téléporteur. Par ailleurs la gare qui est à 10 minutes de chez moi est apparemment la plus active d'Europe en nombre de trains.
Je suis aussi à 20 minutes à pieds d'un héliport.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: UTSL
Posté par Krunch (site web personnel) . En réponse au message Petit bug dans le noyau?. Évalué à 3.
Bah il faut que insmod transmette l'option hid_debug=1 au chargement du module. En pratique ça dépend de ta distro.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# UTSL
Posté par Krunch (site web personnel) . En réponse au message Petit bug dans le noyau?. Évalué à 4.
Sans la version ça va être compliqué mais bon. Admettons que ce soit du 3.6. Le message vient de http://lxr.linux.no/#linux+v3.6/drivers/usb/core/driver.c#L1198
Ce qui veut dire que la méthode reset_resume du driver a retourné 1. Le driver semble être usbhid: http://lxr.linux.no/#linux+v3.6/drivers/hid/usbhid/hid-core.c#L1601
Si on regarde la définition de hid_reset_resume un peu plus haut on voit qu'il retourne ce que hid_post_reset retourne. hid_post_reset quant à lui peut retourner 1 dans plusieurs cas, toujours après avoir appelé dbg_hid: http://lxr.linux.no/#linux+v3.6/drivers/hid/usbhid/hid-core.c#L1404
En examinant la définition de dbg_hid http://lxr.linux.no/#linux+v3.6/include/linux/hid.h#L918 on voit que cela afficher quelque chose uniquement si hid_debug ne vaut pas 0. Cette variable étant une paramètre du module hid-core: http://lxr.linux.no/#linux+v3.6/drivers/hid/hid-core.c#L48
L'étape suivante serait donc d'activer les messages de debug HID et de reproduire le problème.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# convertir
Posté par Krunch (site web personnel) . En réponse au message Regex et encodage. Évalué à 4.
Soit tu fais en sorte que ton programme travaille dans l'encodage du fichier, soit tu convertis le fichier avant de le donner à ton programme. Dans tous les cas il faut connaitre l'encodage du fichier original pour pouvoir le traiter correctement. Il y a des heuristiques d'autodétection d'encodage mais c'est une juste une bonne recette pour se retrouver avec des corruptions « incompréhensibles ».
Voir aussi : iconv(1), iconv(3)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# 2008 called
Posté par Krunch (site web personnel) . En réponse au journal OVH multicast. Évalué à 2.
La plupart des ISP via le câble fournissent cette fonctionnalité depuis pas mal de temps.
http://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-martin.pdf
http://www.youtube.com/watch?v=BBtdZDah6iE
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: les nouveaux terroristes ?
Posté par Krunch (site web personnel) . En réponse au journal Linuxiens : les nouveaux terroristes!. Évalué à 2.
J'approuve Zodiac.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# comme la fibre optique
Posté par Krunch (site web personnel) . En réponse au sondage Quel moyen de transport utilisez-vous pour vous rendre sur votre lieu de travail ?. Évalué à 2.
Vélo+métro quand il fait pas trop pourri et que mon vélo est en état.
Train+métro quand il pleut.
Vélo quand je me lève avant l'heure de pointe et qu'il fait pas trop pourri.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.