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.
Pas forcément. Tu peux garder un compter par thread et les sommer à la fin. Du coup tu n'as aucun accès concurrent à ces compteurs et pas contention à ce niveau.
Au début je pensais utilisé une regex pour commencer à saisir à partir du slash et finir au point d'interrogation mais il a commencé au premier slash et non au 3ième comme je l'aurai voulu.
Ça dépend de comment tu écris ta regexp :
$ echo"'nom d'une variable'='//'lieu où se trouve ma bdd'/'nom de ma bdd'?options supplémentaires" | sed -r 's,^.+/(.+)\?.*$,\1,''nom de ma bdd'
Les quantificateurs sont gourmands et utilisés de gauche à droite. Avec certaines saveurs d'expressions rationnelles, il existe cependant des versions non gourmandes des quantificateurs. Voir par exemple perlre(1).
Les mots clefs sont "quantifier" et "greedy".
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
seule une authentification en HTTP est possible (qui est parfois utilisée au travers du grand Ternet), négligence des concepteurs ou incapacité à implémenter une pile SSL valide sur leur matériel spécifique ?
Présenter une interface HTTPS ne se résume pas à installer {Open,ya,Polar}SSL ou même à écrire une pile SSL/TLS valide. Il faut aussi un certificat qui corresponde au nom d'hôte via lequel l'interface est exposé. Ce qui signifie qu'il faut une intégration spécifique du côté de l'exploitant qui n'a pas forcément une infrastructure de clef publique en place.
Bon après, je sais pas si c'est la raison principale pour laquelle ces composants n'authentifient pas leur flux réseaux mais personnellement je préfère du HTTP en clair que du HTTPS mal fait qui donne une fausse impression de sécurité.
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.
[^] # Re: Les auteurs
Posté par Krunch (site web personnel) . En réponse à la dépêche QubesOS 1.0. Évalué à 3.
Donc en fait tu critique les qualités d'orateur (il y a un féminin pour « orateur ») de Johanna Wojtczuk ?
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Partitions, RAID, etc.
Posté par Krunch (site web personnel) . En réponse au message Manque de place sur /. Évalué à 2.
Super amusant quand /home est monté noexec,nosuid,nodev et que tu essai de mettre des morceaux de /usr/{bin,lib} ou autre dedans.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# sinon
Posté par Krunch (site web personnel) . En réponse au message Outil pour identifier processus utilisant le disque dur?. Évalué à 3.
$ ps xa | awk '$3~/D/'
Moins précis mais bien souvent c'est suffisant et ça marche sans avoir à installer un truc en plus.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Merci beaucoup !
Posté par Krunch (site web personnel) . En réponse au message Comment effectuer une tache le plus rapidement possible ? threads / fork() ... ?. Évalué à 2.
Pas forcément. Tu peux garder un compter par thread et les sommer à la fin. Du coup tu n'as aucun accès concurrent à ces compteurs et pas contention à ce niveau.
Plein de trucs à lire sur l'écriture de code concurrent performant : http://kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# sprintf et arithmétique de pointeurs
Posté par Krunch (site web personnel) . En réponse au journal realloc. Évalué à 7.
Moi c'est surtout cette ligne là qui me fait dresser les poils de la barbe :
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# NEW!
Posté par Krunch (site web personnel) . En réponse au journal Ubuntu, un mot pour désigner.... Évalué à 6.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Sain & Sauf
Posté par Krunch (site web personnel) . En réponse au journal Java ça pue c'est trop libre.. Évalué à 3.
J'ai lu quelque part que certains navigateurs désactivaient le plugin s'il n'a pas été utilisé depuis plus de N jours. Ça me semble un bon compromis.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Un 0-day de 2 jours?
Posté par Krunch (site web personnel) . En réponse au journal Java ça pue c'est trop libre.. Évalué à 4.
Plutôt un 4-months: http://www.techworld.com.au/article/print/435007/oracle_knew_about_currently_exploited_java_vulnerabilities_months_researcher_says/
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# bien gérer sa gourmandise
Posté par Krunch (site web personnel) . En réponse au message Récupération d'une chaine dans un fichier. Évalué à 3.
Ça dépend de comment tu écris ta regexp :
Les quantificateurs sont gourmands et utilisés de gauche à droite. Avec certaines saveurs d'expressions rationnelles, il existe cependant des versions non gourmandes des quantificateurs. Voir par exemple perlre(1).
Les mots clefs sont "quantifier" et "greedy".
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# tarte de Chernobyl
Posté par Krunch (site web personnel) . En réponse à la dépêche Des boissons et des recettes libres. Évalué à 3.
https://linuxfr.org/users/krunch/journaux/joyeux-26-avril
Les photos ont été migrées vers http://fruli.krunch.be/~krunch/pics/tchernobyl07/
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# OpenGL sous Linux plus rapide que Direct3D sous Windows
Posté par Krunch (site web personnel) . En réponse à la dépêche Quoi de neuf du côté d'OpenGL et Linux ?. Évalué à 3.
http://blogs.valvesoftware.com/linux/faster-zombies/
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# TL;DR
Posté par Krunch (site web personnel) . En réponse au journal Conseils aux libristes, 2ème partie: résister à la tentation de la réécriture à partir de zéro. Évalué à 5.
http://www.jwz.org/doc/cadt.html
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: A mi chemin ?
Posté par Krunch (site web personnel) . En réponse à la dépêche OCaml 4.00.0 est sorti. Évalué à 2.
Je préfère les nazis du typage aux nazis de l'indentation :
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# SSL
Posté par Krunch (site web personnel) . En réponse à la dépêche État des lieux de la sécurité industrielle. Évalué à 3.
Présenter une interface HTTPS ne se résume pas à installer {Open,ya,Polar}SSL ou même à écrire une pile SSL/TLS valide. Il faut aussi un certificat qui corresponde au nom d'hôte via lequel l'interface est exposé. Ce qui signifie qu'il faut une intégration spécifique du côté de l'exploitant qui n'a pas forcément une infrastructure de clef publique en place.
Bon après, je sais pas si c'est la raison principale pour laquelle ces composants n'authentifient pas leur flux réseaux mais personnellement je préfère du HTTP en clair que du HTTPS mal fait qui donne une fausse impression de sécurité.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# not fixed yet
Posté par Krunch (site web personnel) . En réponse au journal B16B00B5 : Sexisme dans le source du Kernel. Évalué à 5.
Non.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/hv/hyperv_vmbus.h;hb=HEAD#l414
Le patch actuellement en cours de considération : http://article.gmane.org/gmane.linux.kernel/1331362
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# find
Posté par Krunch (site web personnel) . En réponse au message commande ls amélioré. Évalué à 10.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.