La voiture allergique à la glace à la vanille, et autres bugs

83
5
juin
2021
Humour

Une liste de bugs étonnants. Pour certains, il y a suffisamment d’informations pour remonter à la source et on peut s’assurer qu’il s’agit de vrais bugs. Pour d’autres, différentes versions circulent, les origines se perdent trop loin dans le passé, et on s’approche plus de la légende urbaine que de l’histoire vraie. L’histoire de la voiture allergique à la glace à la vanille, quant à elle, n’est pas à proprement parler un bug informatique, mais elle est intéressante.

Ce qu’il faut néanmoins retenir de l’ensemble de ces histoires, vraies ou fausses, c’est qu’une corrélation, même douteuse, même étonnante, est un indice qu’il convient d’examiner avant de le rejeter, et peut-être aussi, que le problème ne vient pas systématiquement de l’interface entre la chaise et le clavier (ou de son chat).

Elles sont tirées en partie du site en anglais, Software Folklore, et, plutôt que de les traduire intégralement, on a pensé que vous en résumer quelques-unes pouvait être plus intéressant en permettant de vous donner un échantillon assez varié (bon, soyons tout à fait honnêtes, personne n’était motivé pour se lancer dans des traductions complètes et ça épargne certaines longueurs des textes originaux).

Sommaire

La réponse d’Andreas Zwinkau à la demande de palm123 de traduire ces histoires :

I'm not the author and in most cases the author is unknown. So feel free to translate them.
Be careful with the external links though. There you need to ask the original author.

Je ne suis pas l’auteur et, dans la plupart des cas, l’auteur est inconnu. N’hésitez donc pas à les traduire. Cela dit, faites attention aux liens externes, là vous aurez besoin de demander la permission à l’auteur.

La piste du plantage de la Xbox

Lors de la conception de l’un des tous premiers jeux de la console de jeux Xbox, lors des tests, qui se déroulaient automatiquement la nuit, inévitablement une Xbox sur les trois plantait. Le jeu, évidemment, fonctionnait sans problème sur la machine de l’ingénieur. Une intense recherche de chasse au bogue n’avait abouti à rien : le code était tout à fait propre et sans bavure.

Serait-ce le matériel ? Les câbles électriques étaient impeccables donc hors de cause, idem pour les contrôleurs. Décision fût prise d’essayer autre chose : mélanger machines et câbles, et, au matin, replantage d’une machine.

En désespoir de cause : le concepteur décide de passer la nuit avec les machines ! Bingo, au matin un rayon du soleil levant tapant sur une des machines qui plante illico. C’était un problème de carte graphique qui tombait en panne au-delà d’une certaine température.

Affaire résolue.

Version originale.

Une histoire étrangement similaire est racontée, près de 20 ans plus tôt, dans la lettre de BeOS, sous le titre A testing fairy tale (un conte de fées de test). Il est probable que la version ci-dessus est une variante modernisée de cette histoire.

Cette fois-ci, il s’agit de tests sur un lecteur de disquettes. Tout semble bien fonctionner pour les développeurs, mais dans le labo de test, il y a toutes les nuits un échec au bout d’un certain temps sur des tests d’écriture sur les disquettes. Le responsable des tests ne parvient jamais à reproduire le problème en journée, et un seul lecteur de disquettes semble poser problème. Mais, impossible de trouver une piste sur ce qui pouvait causer le dysfonctionnement.

L’un des ingénieurs travaillant sur ce lecteur de disquettes finit par rester toute la nuit (avec des expressos plutôt que des boissons énergisantes, cette fois-ci) pour observer le problème et tenter de le comprendre. Les tests fonctionnent sans problème pendant toute la nuit, et le soleil finit par se lever. Un rayon de soleil éclaire le lecteur de disquettes, et, soudain, le problème se reproduit !

Le lecteur en question n’était pas mis dans un boîtier, et le capteur servant à détecter si la disquette est protégée en écriture était un capteur optique (avec normalement une DEL éclairant ce dernier à travers un trou dans la disquette, le trou n’étant ouvert que pour les disquettes protégées).

Le rayon de soleil éclairant le capteur indiquait au lecteur de disquettes que la disquette était soudainement devenue protégée en écriture, provocant le problème.

Les vrais programmeurs écrivent en Fortran (en fait non)

Cette histoire remonte à l’époque où chaque machine était programmée avec son propre code, pas en assembleur, ni en Fortran mais directement dans un langage binaire qui lui était propre et ne pouvait être utilisé pour une autre machine. À l’époque, les machines étaient un système à tambour avec des tubes à vides (voir l’interview hommage de France Allen en complément).

Dans cette histoire, on a affaire à un programmeur « à l’ancienne » qui n’aimait pas les compilateurs et avait écrit en hexadécimal le programme d’ordinateur le plus populaire du constructeur d’ordinateurs chez qui il travaillait. Il devait donc réécrire le programme du jeu de « blackjack » pour une nouvelle machine, la RPC-4000. À l’époque, chaque instruction était suivie d’un « GOTO » ! Le code devait localiser les instructions sur le tambour, et quand une était finie, il fallait arriver à la « tête de lecture » suivante. On avait mis en place un assembleur d’optimisation que ledit programmeur refusait d’utiliser au motif qu’on ne savait pas trop où il allait intervenir. Il expliquait qu’il fallait utiliser des constantes séparées. En fait, il écrivait la valeur numérique de chaque opération et lui attribuait une adresse fixe sur le tambour. C’était efficace et rapide, mais pas facile à modifier pour quelqu’un d’autre.

Donc il termine le programme « blackjack ». Sauf que, le département des ventes de l’entreprise lui demande de le modifier. En effet, ils voulaient qu’il y ait un commutateur de façon à pouvoir modifier les cotes pour que les clients gagnent (le programme utilisait un générateur de nombres aléatoires). Le programmeur refuse, arguant d’une atteinte à son intégrité. Il fait finalement le travail mais, quand le commutateur est actionné, la machine gagne à chaque fois.

Son successeur regarde le code, trouve une boucle qui n’avait pas de test, aucun. Sans doute une boucle fermée. Le code tirait l’instruction du registre de la machine et en ajoutait une qui avait sa propre adresse, puis il la rangeait. La boucle avait pour objet de prendre en compte le temps supplémentaire pris par l’opération puis de placer la suivante juste sous la tête de lecture du tambour. Ce que le programmeur précédent avait fait, c’était de localiser les emplacements les plus importants sur lesquels les instructions arrivaient. Arrivé à la dernière, il se passait un débordement (overflow), du coup la série d’instructions suivante devenait « jump » et, en toute logique, l’instruction suivante était à l’adresse zéro.

Version originale.

OpenOffice n’imprime pas le mardi

Dans une ancienne version d’OpenOffice, l’impression pouvait échouer. Il ne semblait pas y avoir de logique, le problème arrivait de temps en temps puis disparaissait de lui-même sans raison apparente. Jusqu’à que l’épouse d’un informaticien remarque quelque chose : le problème se produit tous les mardi (Tuesday) et jamais les autres jours. Pourquoi le mardi ?

On imagine le dialogue, l’époux qui demande à sa femme si on peut tester, elle qui lui répond « non parce qu’on est mercredi » et l’impression à partir d’OpenOffice fonctionne sans problème le mercredi. Passé un moment d’incrédulité et après quelques essais, il faut bien se rendre à l’évidence : OpenOffice n’imprime pas le mardi.

Cela venait d’un programme appelé « file » (fichier), un utilitaire UNIX qui utilise des motifs pour détecter les types de fichiers. Cet outil utilise une liste de motifs à comparer avec certains octets dans le fichier à analyser. Ainsi si un fichier commence par « % » suivi par « PS-Adobe », il s’agit d’un fichier Postscript. Il semble qu’OpenOffice ajoutait la date au fichier et donc, le mardi cela prenait cette forme « % Datedecréation: » soit TUE MMM D hh: mm:…

Une erreur dans l’écriture du motif pour reconnaître les fichiers Erlang JAM faisait que « Tue » dans le fichier Postscript était, du coup, reconnu comme un fichier Erlang JAM et, de fait, pas envoyé à l’impression.

Le modèle de fichier Erlang JAM était le suivant :

4 string Tue Jan 22 14:32:44 MET 1991 Erlang JAM file – version 4.2

Alors qu’il aurait dû être :

4 string Tue\ Jan\ 22\ 14:32:44\ MET\ 1991 Erlang JAM file – version 4.2

Autrement dit, tous les fichiers commençant par les caractères « Tue » étaient reconnus comme étant de type Jan 22 14:32:44 MET 1991 Erlang JAM file – version 4.2. Alors que le comportement attendu est que tous les fichiers commençant par Tue Jan 22 14:32:44 MET 1991 soient reconnus comme étant de type Erlang JAM file – version 4.2.

Le Raspberry Pi qui redémarre quand on le prend en photo

Un utilisateur du Raspberry Pi avait remarqué que l’ordinateur plantait lorsqu’il le prenait en photo. Phénomène qui semble difficile à expliquer a priori. Les ordinateurs ne sont normalement pas timides à ce point ?

L’explication est liée à la présence dans le circuit d’alimentation du Raspberry Pi 2 d’un composant sensible à la lumière. Un flash d’appareil photo ou un pointeur laser peuvent donc provoquer des perturbations sur l’alimentation électrique, faisant planter ou redémarrer le système.

Il s’agit d’un composant sans package (plastique ou céramique), ou le substrat de silicium est exposé à l’air libre. Ce type de composant est habituellement utilisé dans des smartphones, où il n’y a pas de place à perdre avec un tel emballage, et où la coque du smartphone offre une protection suffisante. Mais ce n’est pas le cas sur le Raspberry Pi, qui est vendu sans boîtier.

Le serveur mail qui refuse d’envoyer les mails plus loin que 500 miles (environ 805 km)

L’administrateur système d’une université reçut un jour ce rapport de bug surprenant venant du département de statistiques de ladite université : « depuis quelques semaines, nous n’arrivons plus à envoyer des courriels à des destinataires distants de plus de 805 km ».

Réaction initiale : « impossible, le courriel ne fonctionne pas comme ça ». Pourtant, les données sont claires (on parle du département de statistiques, qui a pris le temps de collecter les données et de les analyser pour identifier le motif entre les échecs et réussites d’envois de courriel). Quelques essais avec différents serveurs situés plus ou moins loin confirment ce comportement.

Après analyse, lors d’une mise à jour du serveur de courriel, le démon d’envoi de messages a été remplacé par une version plus ancienne et un fichier de configuration n’a pas été adapté en conséquence. Un timeout pour l’ouverture de connexions TCP était laissé non configuré, et la valeur par défaut dans le logiciel était de 0. Résultat : l’ouverture de connexions n’était possible que si la réponse arrivait très rapidement entre l’exécution de deux lignes de code. Un calcul rapide mettant en rapport la vitesse du processeur du serveur et la vitesse de la lumière dans les fibres optiques permit de confirmer que cela donnait une limite d’environ 805 km.

Un chat assis sur le clavier fait planter LightDM

La description du premier bug est la suivante :

Ubuntu 14.04, écran verrouillé je pars déjeuner, au retour de mon déjeuner mon chat était assis sur le clavier, l’écran de connexion était bloqué et ne répondait pas

Pour reproduire : dans Unity, appuyer sur ctrl-alt-l, mettre le clavier sur la chaise. S’assoir sur le clavier.

Une autre réponse :

Bizarrement, j’ai eu aussi le même problème la nuit dernière. Aussi causé par un chat.

Description d’un autre rapport bug, ouvert six mois plus tard :

Étapes pour reproduire :

  1. laisse l’ordinateur sans surveillance dans une salle froide avec un chat chaud ;
  2. le chat va s’assoir sur le clavier de l’ordinateur ;
  3. attendre une heure ;
  4. Lightdm va se bloquer.

Finalement, le problème était, tout simplement, dû au fait que cela remplissait le champ de mot de passe de tellement de caractères que le système devenait terriblement lent (peut-être le rendu des puces dans le champ de texte ?) et bloquait presque tout le reste… Le champ a finalement été limité à 200 caractères.

La voiture allergique à la glace à la vanille

Où le nouveau propriétaire d’une Pontiac constate que sa voiture ne démarre pas quand il achète de la glace à la vanille le soir et seulement quand il s’agit de glace à ce parfum1. La deuxième plainte de l’automobiliste finit par décider la firme à envoyer un ingénieur pour constater de la réalité des faits. Lequel, mène l’enquête, compile les données de toute nature (durée du trajet, heure, type de carburant, etc.) et fait la même constatation après l’achat de glace à la vanille dans le même magasin pour le même modèle de voiture.

Allons bon ! Comment une voiture pouvait être allergique à un parfum de glace. En fait, il se trouve que dans le magasin en question, ce parfum de glace étant le plus vendu, on se le procurait à un comptoir dédié, plus près de la sortie et que la voiture n’avait pas eu assez de temps pour refroidir : il y avait vaporisation du carburant dans le circuit d’alimentation, ce qui empêchait la voiture de démarrer.

Version originale.


  1. Et où cette histoire semble assez peu crédible pour des critères européens. Mais elle reste, tout de même instructive. 

Aller plus loin

  • # Attaques hardware

    Posté par  (site Web personnel) . Évalué à 10.

    Pour l'exemple du Rapsberry Pi, c'est quelque chose qu'on connait bien dans l'industrie de la carte à puce, qu'on appelle simplement les attaques "flash". C'est utilisé depuis des années. L'intérêt est que pendant le flash et pendant quelque micro-secondes après, le processeur effectue des NOP au lieu d'instructions valides, mais il incrémente quand même le compteur d'instruction. Ca permet donc de sauter quelques instructions assembleur.

    L'attaque est très peu coûteuse en matériel, il faut un appareil photo en gros, gratter un peu la puce pour que la lumière pénètre et un bon système de synchronisation pour déclencher le flash au bon moment.

    Il suffit de déclencher à la fin du IF qui vérifie que ton code PIN est faux et se termine par un return pour arriver dans le ELSE où ton code PIN est censé être juste. C'est déclinable selon plein de variantes et les labos de tests de sécurité s'amusent beaucoup avec ça. Inutile de préciser que c'est dévastateur en terme de cassage de cartes/algo/sécurité.

    Pas cher en matériel et dévastateur en sécurité, autant dire qu'on a pas intérêt à laisser passer de près ou de loin ce genre de truc.

    Du coup, on déploie plein de contre-mesures, qui vérifient qu'on est bien arrivé dans un bout de code pour une bonne raison. Ces contre-mesures n'ayant aucune validité si on analyse le flot de code logique, elles se font parfois virer lors de la compilation ou à l'édition de lien des compilos performants. Ou bien ça marche une fois et la version mineure suivante du compilo va elle virer la contre-mesure. Donc on s'amuse à auditer une partie du code assembleur pour vérifier que le compilo a pas tout sagouiner notre code. Bref, on s'amuse bien par chez nous.

    L'un dans l'autre, on se prend dans les 10% de code en plus rien que pour cette attaque. Et les labos de tests un peu sournois commencent à nous balancer des doubles ou triples attaques flash, où ils vont nous nicker le code principal dans un premier temps, puis la contre-mesure. Là, ça peut vraiment faire mal et être pénible à protéger.

    • [^] # Re: Attaques hardware

      Posté par  . Évalué à 5.

      J'ai du mal à suivre. Autour de 2008, on avait acheter un LSM pour faire exactement ça. Des attaque ciblé pour ajouter un '1' a un endroit de la puce. Le truc était d'éviter des détecteurs qui bloquait la puce.

      Tu semble dire que le flash qui arrose la puce, ne semble pas activer ce genre de protection hardware ?

      "La première sécurité est la liberté"

    • [^] # Re: Attaques hardware

      Posté par  . Évalué à 2.

      C'est intéressant, mais ça me fait me poser une question.

      Je suis très mauvais en correspondance code/assembleur, il ne faut pas voir mon commentaire comme une explication de comment faire, mais comme une discussion.

      Les langages qui remplacent les if/then/else par des types fantôme + du polymorphisme ne sont pas moins sensibles à ces problèmes ?

      À ce moment là ton compilateur peut prouver que tu es où tu es pour de bonnes raisons, mais peut être que cette caractéristique n'est pas garantie dans le binaire généré ? Outre le fait qu'il n'existe peut être pas de langage permettant cela et pouvant cibler une carte à puce…

      • [^] # Re: Attaques hardware

        Posté par  (site Web personnel) . Évalué à 4.

        Tu as un peu pressenti la réponse: on utilise que trois langages dans la carte à puce. Le C, l'assembleur et le javacard. On pourrait dire quatre langages puisqu'une boite à succès utiliser une machine virtuelle avec du Forth et a sorti pas mal d'applications certifiées avec (sauf que c'était limite plus pénible à programmer que de l'assembleur à la main).

        En tout cas, très clairement, un langage trop éloigné de l'assembleur qui réorganise le code en fonction des informations qu'il a pourrait poser problème. Cela dit, si on passait à un langage plus haut niveau, j'espère qu'on pourrait intégrer la notion de sécurité par une approche haut-niveau dans le code, genre un sorte de "secured if" sous forme de fonction.

        Dans le cas de Javacard, on peut intégrer des sécurités dans cet esprit au niveau de la VM Java, ce qui est parfois pratique.

        • [^] # Re: Attaques hardware

          Posté par  (site Web personnel) . Évalué à 6.

          J'avais un jour assisté à une conférence sur ces questions de sureté de code. Dans un environnement "hostile" (je ne sais plus trop le contexte : nucléaire, ou ce genre de truc), une solution avait été de compiler le programme deux fois, avec deux compilateurs différents. Les deux programmes s'exécutaient en parallèle, et des points de contrôles avaient été mis en place dans lesquel chaque programme attendait que l'autre produise le même résultat avant d'embrayer sur la suite.

          Comme le source était le même, il était attendu que le résultat soit identique, mais l'utilisation de deux compilateurs faisaient qu'un incident survenant sur l'exécution d'un programme n'avait pas le même impact sur l'autre, ce qui protégeait la solution.

          • [^] # Re: Attaques hardware

            Posté par  . Évalué à 3.

            des points de contrôles avaient été mis en place dans lesquel chaque programme attendait que l'autre produise le même résultat avant d'embrayer sur la suite.

            Et il se passait quoi si l'autre n'avait pas le même résultat (ou plantait par exemple) ?

            • [^] # Re: Attaques hardware

              Posté par  (site Web personnel) . Évalué à 4.

              Les deux process étaient relancés à partir du point de contrôle précédent tout simplement. Il faut garder à l'esprit que dans ce contexte, c'était la sureté de l'exécution qui était mise en avant, au détriment de la vitesse, et cela a à la fois des impacts sur le fil d'exécution du programme, mais sur le hardware mis en place autour.

              De mémoire, il y avait peut-être un contrôleur d'exécution, qui s'assure que les deux programmes s'exécutent correctement, qui se trouvait dans une "chambre forte" protégée de tout environnement (radiation, ionisation etc). Au final cela revenait moins cher de mettre seulement ce dernier élément en confinement, et laisser les processeurs/microcontroleurs subir les attaques de l'environnement plutôt que créer une brique complète qui protège l'ensemble du système. (je ne sais plus trop si les programmes s'autocontrôlaient ou si cela était fait en extérieur — l'idée étant là, on peut imaginer les deux)

          • [^] # Re: Attaques hardware

            Posté par  . Évalué à 4.

            Il doit etre possible de faire 2x les operations par le compilo qui vérifie lui même le resultat et recommence en cas de différence.

            Cela serait utile en carte a puce et dans le spatial.

            "La première sécurité est la liberté"

            • [^] # Re: Attaques hardware

              Posté par  (site Web personnel) . Évalué à 3.

              Ça se fait effectivement pour la sécurité, y'a des travaux autour de ça au CEA par exemple.

              Pour la sûreté dans le spatial, je ne crois pas qu'on arrive à se passer de redondance matérielle : les fautes matérielles liées au rayonnement ont tendance à se propager et à faire sauter plusieurs choses d'un coup. Mais l'étude des interactions entre les mécanismes de tolérance aux pannes hard et le soft est un sujet de recherche intéressant et actif par contre.

              • [^] # Re: Attaques hardware

                Posté par  . Évalué à 5.

                Les protections hard dans le spatial, c'est juste de la triplication des registres. Ainsi, en cas d'erreur entre 2 registres, c'est corrigé. Je n'ai jamais entendu parler de puce de carte à puce fait ainsi.

                Ce genre de hard spécifique est couteux. Un compilo spécial serait réutilisable. En fait, l'idéal est la triplication. Il faut tripliquer les mémoires, les exécutions, et sans doute le code objet aussi. Entre 2 calculs, il faut vérifier les 3 résultats, si l'un est différent, il faut y recopier la valeur des 2 autres. Il faut un traitement spécial des IOs, par contre, pour ne pas faire 3 printf identiques de suite.

                Je n'en jamais entendu parlé de ce genre de truc. Pourtant, cela serai utile dans pas mal de cas.

                "La première sécurité est la liberté"

        • [^] # Re: Attaques hardware

          Posté par  . Évalué à 4.

          Cela dit, si on passait à un langage plus haut niveau, j'espère qu'on pourrait intégrer la notion de sécurité par une approche haut-niveau dans le code, genre un sorte de "secured if" sous forme de fonction.

          C'est ce à quoi je pensais avec les phantoms types. Très très grosso modo au lieu d'avoir un if, le code qui doit être exécuté en cas de sucés est une fonction dont l'argument n'est pas une string, mais un "pin valid" (c'est son type) et la seule manière d'obtenir une variable de ce type c'est de passer par la fonction qui vérifie le pin. Il me semble que ça peut protéger plus naturellement des problèmes dont tu parle, mais

          • si les compilateurs ne pensent pas à ce problème peut être qu'ils ne vont pas propager cette garantie dans le code généré, comme ils sont en mesure de vérifier statiquement tout ça en principe ils pourraient bien faire ce qu'ils veulent
          • s'ils le font mais pas tout le temps, tu ne peux pas (ou difficilement) reprendre la main sur le code généré pour corriger le problème (avoir un bout de code C ou assembleur)

          C'est dommage je suis sûr qu'un compilateur pourrait implémenter cette sécurité :(

      • [^] # Re: Attaques hardware

        Posté par  . Évalué à 2. Dernière modification le 04/07/21 à 20:27.

        Il y a au moins eu aussi la BasicCard de ZeitControl. De mémoire, une des premières implémentations de la carte GPG ciblait ces cartes. Il me semble aussi que MultOS supporte Visual Basic.

        Edit: En relisant le site de BasicCard, je ne suis pas sûr que ces cartes ne soient pas uniquement des cartes MCU (c'est à dire sans protection hardware)

    • [^] # Re: Attaques hardware

      Posté par  . Évalué à 5.

      Ces contre-mesures n'ayant aucune validité si on analyse le flot de code logique, elles se font parfois virer lors de la compilation ou à l'édition de lien des compilos performants. Ou bien ça marche une fois et la version mineure suivante du compilo va elle virer la contre-mesure. Donc on s'amuse à auditer une partie du code assembleur pour vérifier que le compilo a pas tout sagouiner notre code. Bref, on s'amuse bien par chez nous.

      Dans un ancien job, lorsque je codais encore avant de me mettre au pipeautron, j'avais eu un problème similaire.

      Les instructions qu'on utilisaient pour timer précisément les temps des fonction sur nos machines étaient très spécifiques (on faisait pas mal de choses avec des outils liés au parallélisme). Puis un jour, nos chiffres ont commencé à être un peu anormaux. Mais pas complètement faux, juste un peu faux. Genre comme si certains traitements avaient gagnés en vitesse par rapport à nos temps de référence. Quelqu'un s'en est rendu compte sur un gros coup de bol.

      Après pas mal de cheveux en moins (et de laborieux changements de version de tous les outils). J'ai fini par tomber sur le problème : la nouvelle version du compilateur s'amusait à déplacer une des instructions de timing qui faisait un "top" de "quelques" instructions. Forcément, ça toppait plus au bon moment, et certains traitement coûteux se retrouvaient non-comptabilisés.

      C'était la seule fois où j'ai du débugger au niveau machine de ma vie. C'était drôle.

  • # lien brisé

    Posté par  (site Web personnel) . Évalué à 5.

    Pour « les vrais programmeurs », il y a deux urls sous Version originale.

    ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: lien brisé

      Posté par  . Évalué à 3.

      Corrigé, merci.

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # Abba

    Posté par  . Évalué à 9. Dernière modification le 06/06/21 à 10:17.

    L'histoire du mail qui ne dépasse pas une certaine distance est géniale.

    J'aime beaucoup aussi l'histoire de l’œuf de Pâques dans la commande man qui fait (faisait) planter des tests d'intégration continue entre minuit et 1h du matin, pour le plaisir de faire une blague liée à une chanson de Abba.

    • [^] # Re: Abba

      Posté par  . Évalué à 3.

      Plutôt qu'une blague je le vois comme une fonctionnalité cachée ;-D

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

  • # Gimme gimme gimme! (a man after midnight)

    Posté par  . Évalué à 10.

    Des tests nocturnes qui parsaient en autre le manpath obtenu avec man -w, échouaient toutes les nuits. En effet, près minuit la commande man sans nom de page écrivait « Gimme gimme gimme! » sur stderr, un Easter egg en référence à la chanson d'Abba, retiré depuis. Source en anglais.

    Cette signature est publiée sous licence WTFPL

    • [^] # Re: Gimme gimme gimme! (a man after midnight)

      Posté par  . Évalué à 3.

      bah il faut que les tests incluent un argument sinon ça a moins de sens et pour aller dans ce sens il faudrait que les tests vérifient l'heure.

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

  • # mot manquant

    Posté par  . Évalué à 3.

    et quand une était finie

    instruction ?

    • [^] # Re: mot manquant

      Posté par  (site Web personnel) . Évalué à 10.

      Le mot est implicite ici (Le code devait localiser les instructions sur le tambour, et quand une était finie,), la tournure ne me semble pas incorrecte.

      • [^] # Re: mot manquant

        Posté par  . Évalué à 8.

        Bien vu. On aurait pu écrire « quand l'une d'elles était finie…"

  • # Cela me rappelle un bug ...

    Posté par  . Évalué à 10.

    Cela me rappelle un bug qui m'a pris la tête pendant au moins une semaine. Mon histoire n'est pas aussi intéressante car au final il ne s'agissait que d'un banal dépassement de tableau.
    Je développais un compilateur et un jour je constate plusieurs plantages sur un serveur de tests. Des joli segfaults bien propres. J'essaye sur ma machine et surprise … cela fonctionne. Idem sur les autres serveurs à ma disposition. Le bug ne se produit que sur 1 seul serveur. C'est inhabituel car cet outil est sensé être parfaitement déterministe.

    Pour ne rien arranger, le bug disparaît quand je recompile en mode debug et Valgrind ne me dit rien d'intéressant. Les serveurs sont identiques avec les même processeurs, les mêmes DRAMs, le même OS (debian) et les mêmes bibliothèques. Je m'assure que la randomization d'adresses est désactivée, que tout les fichiers concernés (data, libs, exécutable, …) ont les mêmes checksums, que les horloges sont bien synchronisées, que le kernel linux est identique, … etc etc etc
    Tout est pareil mais ce fichu test continue à planter sur un unique serveur. C'est la 5ieme dimension ce truc. Est ce que le bug serait dans le hardware? C'est rare mais cela m'est déjà arrivé. Après plusieurs jours, je commence à sérieusement douter de mes capacités. Peut être ne saurais je jamais pourquoi notre compilateur plante sur zorglub-test mais pas sur paglop-test ou iznogoud-test?
    WTF … wait a second … "zorglub-test" fait 12 caractères de long alors que les 2 autres en font respectivement 11 et 13. Cela ne peut pas être aussi simple:

    # ./run-buggy-test
    segfault
    # export HOSTNAME=123456-test
    # ./run-buggy-test
     => Success

    Et si! Le système de logs du compilateur initialisait une chaîne de caractères contenant le HOSTNAME dans un tableau trop petit de 1 caractère. Classique! Moins de 12 caractères, pas de problèmes. Plus de 12 caractères, dépassement de tableau mais pas de crash. Exactement 12 caractères et le \0 de fin passe la variable immédiatement après le tableau de vrai (1) à faux (0) et beaucoup plus tard … BOOM.

    • [^] # Re: Cela me rappelle un bug ...

      Posté par  (site Web personnel) . Évalué à 1.

      Pas mal !

      Aux experts du C, quels sont les bons outils pour repérer automatiquement ce genre de bogue ? Je suppose qu'il y en a pas mal du genre qui traînent…

      • [^] # Re: Cela me rappelle un bug ...

        Posté par  (site Web personnel) . Évalué à 3.

        Il y a des outils d'analyse statique. Quelques uns en vrac (pas tous libres): clang-tidy, cppcheck, clint, coverity, codesonar, pvs studio, …

        L'idée est d'analyser le code lors de la compilation et de détecter ce genre de problèmes.

        On peut aussi activer certaines protection à l'exécution dans les compilateurs modernes: ubsan (détecte le code exploitant des comportements laissés indéfinis par les spécification du C ou du C++), asan (détecte les accès à de la mémoire non allouée ou déjà libérée). Ça a un coût en terme de performances. S'il y a ce genre de besoins il est peut-être pertinent de regarder si un autre langage offrant plus de garanties ne serait pas un meilleur choix

        • [^] # Re: Cela me rappelle un bug ...

          Posté par  (site Web personnel) . Évalué à 1. Dernière modification le 08/07/21 à 16:05.

          "S'il y a ce genre de besoins" est-ce qu'il n'y a pas toujours besoin d'éviter les bogues ?

          Je comprends qu'en C on n'a pas de mécanisme de protection, mais je demande quels seraient les outils à toujours utiliser aujourd'hui pour éviter 99% de ce type de problème (s'ils existent).

  • # "blocage dû à la vapeur"

    Posté par  . Évalué à 6.

    J'ai eu bien du mal à comprendre alors si cela peut aider d'autres lecteurs dans ce cas : "vapor lock" (en v.o.) fait référence à la vaporisation du carburant dans le circuit d'alimentation du moteur, cause des soucis au redémarrage.

    • [^] # Re: "blocage dû à la vapeur"

      Posté par  (site Web personnel) . Évalué à 3.

      Donc si je remplaçais le blocage par "vaporisation du carburant" ça le fait ? Laquelle vaporisation si je comprends bien fait que le carburant n'arrivait pas sous une forme utilisable au moteur.

      « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

      • [^] # Re: "blocage dû à la vapeur"

        Posté par  . Évalué à 5.

        Dans le moteur, l'état utilisable du carburant c'est liquide, tu as bien compris ;-). Voici donc une proposition de reformulation : "il y avait vaporisation du carburant dans le circuit d'alimentation, ce qui empêchait la voiture de démarrer." Cela me semble plus clair, même si je n'y connais pas grand chose.

        • [^] # Re: "blocage dû à la vapeur"

          Posté par  (site Web personnel) . Évalué à 4.

          Vendu :-) ! Et corrigé, merci, c'est mieux comme ça.

          « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

        • [^] # Re: "blocage dû à la vapeur"

          Posté par  (site Web personnel) . Évalué à 3. Dernière modification le 07/06/21 à 06:26.

          Ne serait-ce pas plutôt dans le circuit d’alimentation que l’état du carburant doit être impérativement liquide ? Dans le cylindre, s’il est sous forme de vapeur, cela ne ferait qu’améliorer la combustion. Dans les conduites en revanche, à même débit volumique, cela réduirait drastiquement le débit molaire…

          « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

          • [^] # Re: "blocage dû à la vapeur"

            Posté par  (site Web personnel) . Évalué à 3.

            Ben c'est ce qui est dit non ? On ne parle pas du tout de cylindre là.

            « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

            • [^] # Re: "blocage dû à la vapeur"

              Posté par  (site Web personnel) . Évalué à 4. Dernière modification le 07/06/21 à 10:08.

              En effet, ma réponse est sans doute mal placée. C'est l'ambiguïté des formulations suivantes qu'il me semblait approprié de relever :

              « […] le carburant n'arrivait pas sous une forme utilisable au moteur. »

              « Dans le moteur, l'état utilisable du carburant c'est liquide […] »

              « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

  • # Salle de réunion avec application web manquante

    Posté par  (site Web personnel) . Évalué à 8.

    Il m’est déjà arrivé une histoire du même niveau : Une salle de réunion dans la quelle une web application interne ne fonctionne pas.

    Un utilisateur me contacte pour un problème d’accès sur cette application interne depuis une salle de réunion. Le contact se fait par la messagerie d’entreprise, depuis la salle de réunion, donc il as du réseau.
    Un panel d’autres applications fonctionnent.

    Je me déplace, j’essaye … fonctionne pas …
    Mais le tout fonctionne dans plusieurs autres salles du bâtiment.

    Comment peux on perdre UN site intranet dans UNE salle de réunion ?

    Après un ensemble de test et de vérification nous avons trouvé le coupable : Mauvais VLan configuré sur les prises réseau de la salle de réunion.
    Ce dernier filtrant la zone spécifiques aux serveurs de l’application incriminé.

    Pour moi qui ai, à priori, dit à l’utilisateur «Mais c’est pas possible que tu n’ai pas accès qu’à UNE application web», c’était finalement vrai.

  • # Une autre histoire

    Posté par  (site Web personnel) . Évalué à 10.

    Je viens de lire l'histoire de l'imprimante qui ne fonctionne que quand la porte de da pièce est ouverte:

    https://twitter.com/ASeemueller/status/1351137587960930304?s=20

  • # Mon histoire perso: failli mourir à cause d'un DRM

    Posté par  (site Web personnel) . Évalué à 10. Dernière modification le 07/06/21 à 10:00.

    Adolescent, j'aimais beaucoup un jeu qui s'appelait The Nomad Soul. Le jeu bénéficiait d'une bande son écrite par David Bowie, bande son qui devait être protégée par un DRM. Quand je jouais, j'avais remarqué que le lecteur CD, un lecteur où l'on insère le CD (slut-in) s'emportait et se mettait à tourner très vite. Un jour, alors que je jouais, j'entends le lecteur CD qui s'emballe, tourne de plus en plus vite, et d'un coup: "Scratch, boum.", le CD explose dans le lecteur, des morceaux (de CD, pas de musique) fusent dans tous les sens. Un notamment se plante littéralement dans mon siège en cuir, à la hauteur de mon cou.

    Le lecteur était évidemment mort, le jeu plus utilisable car il manquait un CD et j'avais eu une belle frayeur. Après avoir consulté les forums sur Internet à l'époque, j'avais vu que d'autres personnes avaient eu le même problème notamment avec des lecteurs slut-in et qu'une action s'organisait aux États-Unis. Ce problème semblait lié au DRM, car il requerrait une lecture rapide du CD.

    J'ai essayé de retrouver des traces sur Internet des discussions liées à ce problème aujourd'hui, mais les messages semblent avoir été emportés dans les limbes d'Internet.

    • [^] # Lapsus ?

      Posté par  . Évalué à 6.

      J'avoue, j'ai ri !
      Pas à cause de ton histoire qui a failli tourner au tragique mais bel et bien à cause de ton lecteur de CD de type "Slut-In".
      Chez moi, on appelait ça un lecteur "Slot-In".
      Les anglophones apprécieront la nuance ;-D

  • # Le plantage horaire

    Posté par  . Évalué à 7. Dernière modification le 07/06/21 à 10:29.

    Dans le genre "plantage à certaines heures et pas à d'autres", je vous propose le problème suivant :

    J'ai un outil qui permet de lancer et/ou planifier le lancement de tests sur un banc de test (de satellite, mais peut importe) La façon la plus classique de l'utiliser, c'est de l'ouvrir, choisir mon test, et de le lancer. Je peux aussi choisir de le lancer plus tard, mais par défaut, il est mis dans la file de test à l'heure du lancement. Il y a donc un champ "heure" et un champ "minute" (pas de secondes) qui afficherait 10 et 20 respectivement si je lançais le test à cette heure ci (il est 10h20 quand j'écris)

    L'outil se charge ensuite de lancer le test à l'heure dite (donc tout de suite, si le banc est dispo et qu'il n'y a pas de test en cours, sinon il s'arrange pour le mettre en file d'attente, on a la possibilité d'ajouter des priorités, etc)

    Le problème : Parfois, ça ne marche pas.

    Je vais maintenant vous donner les premiers éléments que l'on a rassemblés, puis je vous donnerai dans la partie 2 des éléments plus précis, mais que je n'avais pas avant de comprendre le bug, donc si vous aimez le défi, ne lisez pas la partie 2.

    Partie 1 :

    Pendant la journée, ça marche la plupart du temps, mais une fois de temps en temps, ça ne marche pas. Sauf le matin, où quand j'utilise l'outil relativement tôt dans ma journée, ça plante régulièrement. Je n'arrive pas forcément très tôt au boulot (disons entre 8h30 et 9h), mais je lance rarement un test dès que j'arrive, ça prend un peu de temps. (généralement je préfère finir le test le jour avant et le lancer la nuit, comme ça je n'ai pas besoin d'attendre le temps du test/la disponibilité du banc)

    Quand je demande à décaler le test, ça marche à chaque coup, même si je ne décale que d'une minute. Donc quand je rentre l'heure à la main, ça marche.

    Partie 2 :

    • La fréquence des plantages pendant la journée est de un plantage sur 30 exécutions, en moyenne.

    • Les test qui plantent le matin, sont ceux qui sont lancés avant 10h. Sauf pour un collègue qui arrive tôt au boulot, qui lui me dit que quand il lance un test très tôt, ça ne plante pas. Il arrive vers 7h au boulot.

    J'écoute vos suggestions, quelqu'un a-t-il une idée ? (ce n'est pas pour vous faire bosser à notre place, le bug est résolu depuis plus de 10 ans)

    Heureusement le satellite en lui même est plus robuste que le banc…

    Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

    • [^] # Re: Le plantage horaire

      Posté par  (site Web personnel) . Évalué à 4.

      Je pense que je vois le problème mais je ne veux pas donner la réponse tout de suite pour laisser les autres lecteurs chercher un peu :)

    • [^] # Re: Le plantage horaire

      Posté par  (site Web personnel) . Évalué à 5.

      J'essaie de trouve des indices de cause dans ce que tu écris.

      Voyons, est-ce que lié à des décalages horaires ?

      « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

      • [^] # Re: Le plantage horaire

        Posté par  . Évalué à 5.

        Non, pas de décalage horaires.

        Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

      • [^] # Re: Le plantage horaire

        Posté par  . Évalué à 2.

        Par décalage horaire, j'imagine qu'il faut comprendre la synchronisation des horloges (NTP). Une mauvaise synchro, peut causer des problème bizarre par exemple avec les systèmes de fichier en réseau. Par exemple, Make peut se mettre à ignorer certains fichiers récents car ils ont une date dans le futur.

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 4.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Le plantage horaire

        Posté par  . Évalué à 4.

        Un test dure entre moins d'une minute et plusieurs heures, et on était plusieurs (moins d'une dizaine) à utiliser le banc. Mais en fait ça n'a pas d'influence sur le bug ;-)

        Lle problème arrivait au moment de l'insertion du test dans la file d'attente, donc pas au lancement, et ce n'était pas un problème d'insertion concurrent par plusieurs personnes.

        Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 10.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Le plantage horaire

        Posté par  . Évalué à 10.

        C'était ça. Effectivement, quand l'heure était rentrée automatiquement, elle était en deux chiffres (alors que si on rentre l'heure à la main, on rentrait "9" "42" par exemple, donc pas de 0 devant) Et derrière ce champ était interprété pour le transformer d'une chaine de caractère à un nombre, et ça plantait car 08 et 09 n'existent pas en octal, et tout le reste marchait comme attendu.

        Donc la journée, on avait une "chance" sur trente de tomber sur le bug, et le matin, entre 08:00 et 09:59 on tombait sur le bug à tous les coups. Et le collègue qui commençait plus tôt lançait ses test à 07:XX dont ça passait.

        Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 4.

          Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Le plantage horaire

          Posté par  . Évalué à 3.

          Dans le même genre que l'octal il y a les problèmes liés aux locales. C'est bien connu pour les dates (1/4/21 = 1er avril en FR = 4 janvier en US) mais aussi pour les formats de nombres (19.5 en US = 19,5 en FR).

          (bash) export LC_ALL=C
          (bash) printf "%f\n" "4.5"
          4.5
          (bash) export LC_ALL=fr_FR.utf8 
          (bash) printf "%f\n" "4.5"
          bash: printf: 4.5: invalid number
          4,000000
  • # Mon père automaticien me raconte souvent un histoire du même genre...

    Posté par  . Évalué à 4.

    C'était à une époque ou il bossait encore comme electro-mécanicien dans une société de production.

    Tous les jours vers 16h, il y avait une machine qui tombait en panne.
    Les conducteurs & manutentionnaires trouvaient çà sympa car c'est l'occasion d'une pose clope.

    Le plus bizarre ,c'est que genre 15min après la machine redémarré sans réel action corrective répétable.

    Mon père commençait se demander si les gars ne la mettaient pas en panne pour prendre une pose.

    Après quelques recherches, il comprit le problème. Vers 16h, un rayon de soleil venait éclairer un capteur optique qui se trouvait alors en défaut.

    • [^] # Re: Mon père automaticien me raconte souvent un histoire du même genre...

      Posté par  . Évalué à 10.

      Ça me laisse dubitatif toutes ces histoires de rayon de soleil qui tape tous les jours à la même heure. Car l'inclinaison de la terre et sa rotation autour du soleil fait que tous les jours à la même heure, le soleil n'est pas orienté de la même façon. Il faut donc que ce soit une panne qui se décale tous les jours dans le temps. Il faut également qu'il fasse beau tous les jours, car si une lumière diffuse était suffisante pour causer le problème, il surviendrait à n'importe quel moment de la journée.
      Ou alors ce sont des pannes qui ont été résolues suffisamment rapidement, pour que l'on ne se rende pas compte du décalage temporel !?

      • [^] # Re: Mon père automaticien me raconte souvent un histoire du même genre...

        Posté par  . Évalué à 2.

        Dans mon cas, je peux te certifier que c'est un cas réel vu que c'est mon père qu'il l'a traité ;-)

        Je lui demanderai combien de temps ce problème avait persisté.

        • [^] # Re: Mon père automaticien me raconte souvent un histoire du même genre...

          Posté par  . Évalué à 5.

          Alors, je viens de l'appeler pour lui demander des précision.

          Plus exactement, c'était entre 11h et 12h et il ne se rappelle plus exactement combien de temps cela avait durée mais à priori longtemps. Il lui a fallu plus d'un an pour comprendre la panne. Cela ne le faisait pas tous les jours.

          C'était un genre de cellule infra-rouge sur une bascule.

          Et à priori, il a eu le même type de panne sur d'autres machines après.

          Donc je pense que cela ne doit pas être le seul electro-mécanicien /automaticien qui a rencontré ce type de panne :-).

      • [^] # Re: Mon père automaticien me raconte souvent un histoire du même genre...

        Posté par  . Évalué à 7.

        Durant une saison donnée le soleil reste bas/rasant pendant une certaine durée. Et ensuite quand il s'agit de probleme thermique ça prend aussi un peu de temps. Mais c'est suffisant pour dire "autour de telle heure" même si on n'est pas à la minute près.

      • [^] # Re: Mon père automaticien me raconte souvent un histoire du même genre...

        Posté par  (site Web personnel) . Évalué à 8.

        C'est amusant, parce que moi, j'ai vu l'inverse.

        Durant la nuit en hiver, mais pas toutes les nuits, on recevait une alerte sur la bascule d'un lien réseau entre 2 bâtiments. La liaison entre le bâtiment principal et une maison un peu plus loin basculait sans raison sur le lien radio de secours. Et c'était toujours vers 4h/5h du matin. On a bien cherché du coté des updates, des opérations, etc, sans grand succès. On était pas motivé au point de rester debout à 4h du mat pour voir ça, mais bon.

        Ça a duré quelque semaines avant que finalement, quelqu'un se souvienne que si on avait mis un lien radio, c'était parce qu'on pouvais pas mettre de câble. Et donc que le lien primaire, c'était une liaison laser entre les 2 bâtiments qu'on avais mis en place avant, je suppose pendant l'été.

        Et en hiver, à 4/5h du mat, il y a parfois de la brume et ça marche un chouia moins bien à cause de la réfraction.

      • [^] # Re: Mon père automaticien me raconte souvent un histoire du même genre...

        Posté par  (site Web personnel) . Évalué à 6.

        Pour les deux qui sont listées dans la dépêche, au moins, la trame de l'histoire est vraiment trop proche (si on lit les versions originales en anglais). Mon avis est que quelqu'un a raconté la même histoire en la modernisant, en remplaçant le lecteur de disquettes par une XBox.

        D'où l'ajout du paragraphe sur les légendes urbaines en introduction (pas seulement pour cette raison, en fait: l'histoire de la glace à la vanille, a priori, c'est aussi du flan).

        Pour cette histore de rayon de soleil mal placé, j'ai cherché un peu, mais je n'ai pas trouvé de sources plus anciennes que la newsletter de BeOS. Celle-ci présente déjà l'histoire comme un "conte de fées" et ne prétend donc pas être très sérieuse. Mais j'avoue m'être souvenu de cette histoire comme si c'était réellement arrivé directement au responsable des tests de BeOS, avant de retrouver et de relire ce numéro de la newsletter et de me rendre compte que j'avais donc fait partie de la propagation de la légende urbaine.

        Finalement c'est peut être l'aspect le plus intéressant de ces histoires: mener l'enquête pour trouver d'où elles viennent, comment elles se propagent, et comment elles évoluent au cours du temps.

  • # Une autre histoire de chasse

    Posté par  (site Web personnel) . Évalué à 4. Dernière modification le 07/06/21 à 14:26.

    C’est lié à l’informatique, mais ça n’en est pas.

    Dans une asso où j’étais bénévole, il y a un paquet d’années vu qu’il s’agit d’une connexion internet d’avant l’ADSL. L’ordinateur de l’asso n’arrivait pas à se connecter à internet. La bénévole informaticienne1 avait tout essayé (ou presque), rien n’y faisait. Cela durait depuis quelques semaines. Jusqu’à ce que j’aille au local.

    Ayant déjà changé plusieurs fois de FAI à l’époque, je savais me dépatouiller des configurations internet. Donc, puisque j’étais là, je me propose de jeter un coup d’œil au cas où. On me répond : « oui, mais ça ne sert à rien, Choséphine2 a regardé plus d’une fois et essayé des tas de trucs, ça ne marche pas, ça doit être l’ordinateur. »

    Okaydaccord, les réglages sont bons, l’ordinateur et le modem fonctionnent correctement. Et j’avise un tas de câbles3 qui traînent dans un coin. Je change le câble (il y en avait heureusement, ce qui est rare dans un tas de câbles qui traîne, un avec les bons connecteurs). Je relance, tout, l’ordinateur se connecte à internet sans renâcler.


    1. Après ça, ma cote, qui n’était déjà pas très bonne, est carrément tombée au plus bas de la fosse des Mariannes, je crois bien que je venais de commettre un crime de lèse-majesté informaticienne. 

    2. Le prénom a été changé, pour reprendre une formule consacrée. 

    3. Les tas de câbles qui traînent sont consubstantiels à l’informatique et se reproduisent naturellement, je ne vois que ça comme explication rationnelle à cet état de chose. 

    « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

  • # En Union soviétique, c'est la glace qui est allergique à la voiture

    Posté par  (site Web personnel) . Évalué à 9.

    Je suis à peu près sûr d'être tombé sur cette histoire via Linuxfr, donc pardonnez mon repost, et par ailleurs il se peut que ce soit un récit apocryphe, mais il s'inscrit à merveille dans cette liste : "Le débogage derrière le rideau de fer". Je ne vous en dis pas davantage pour ne pas vous gâcher la chute.

  • # GitLab

    Posté par  (site Web personnel) . Évalué à 9.

    J'en ai eu un autre assez joli : un utilisateur n'arrive pas à se connecter à GitLab, erreur HTTP plus ou moins incompréhensible si on essaye de charger la page de login. Ça marche depuis un autre PC, mais même erreur quelle que soit le browser et la connexion internet.

    Problème résolu en remettant le PC à l'heure.

    L'explication est que le serveur envoyait un cookie avec date d'expiration très proche dans le futur, en se basant sur l'heure du serveur. Si le client avait une horloge mal réglée, le cookie arrivait avec une date d'expiration passée de point de vue du client, et paf.

  • # le pc qui ne supporte pas l'altitude

    Posté par  . Évalué à 6.

    Au début de ma carrière quand je faisais du support desktop j'ai vu le cas d'un pc qui un matin n'a plus démarré chez une utilisatrice du dernier étage d'un bâtiment (je crois 8 ou 9ème?). Arrivé à mon bureau au sous-sol il fonctionnait. Je le remonte il ne fonctionne plus. J'inverse les câbles avec celui de la collègue, toujours le même pc qui ne démarre pas. Je le redescend il démarre sans broncher.

    Au final après l'avoir ouvert et nettoyé à l'air comprimé il a finalement pu reprendre service au dernier étage mais je n'ai jamais compris pourquoi si c'était un problème de contact avec une quelconque poussière il ne fonctionne pas seulement dans certains bureau, je ne pense pas que la différence de pression atmosphérique entre le 1er sous-sol et le 8-9ème étage soit une explication suffisante!

    • [^] # Re: le pc qui ne supporte pas l'altitude

      Posté par  (site Web personnel) . Évalué à 3.

      Neuf étages c'est pas l'Everest en effet.

      « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

    • [^] # Re: le pc qui ne supporte pas l'altitude

      Posté par  . Évalué à 3.

      C'est pas la prise de courant qui déco-connait?

      • [^] # Re: le pc qui ne supporte pas l'altitude

        Posté par  . Évalué à 5. Dernière modification le 08/06/21 à 10:16.

        Quand je dis que j'avais inversé le cablage du pc de la collègue je l'avais donc branché sur la même prise.

        Et au final le problème a quand même été résolu par le soufflage à air comprimé.

        • [^] # Plutôt la température

          Posté par  . Évalué à 4.

          Dans les étages, il fait plus chaud qu’au sous‐sol.

          J’ai eu ce genre de problèmes. C’est difficile d’obtenir la réparation d’un PC garanti avec retour atelier quand il ne plante pas dans l’atelier (dans mon bureau au rez de chaussée non plus, mais si on ne peut pas l’utiliser au 3ᵉ, c’est quand même un souci).

          Bon, manifestement, pour celui dont tu parles, c’était un problème de poussière. Dans notre cas, c’était une série de cartes mères qui vieillissait mal.

          Guerres, déréglement climatique, effondrement de la biodiversité, épuisement des ressources, pandémie, montée du fascisme, de l’intégrisme et du complotisme… On vit une époque formidable…

          • [^] # Re: Plutôt la température

            Posté par  (site Web personnel) . Évalué à 4.

            Quand j'étais étudiant (ya bientôt 20 ans), un de mes collocs a dû pendant quelques mois « préchauffer » sa tour au seche-cheveux pour qu'elle daigne booter. Bon à la fin ça s'est fini par un remplacement de carte mère.

            Adhérer à l'April, ça vous tente ?

    • [^] # Re: le pc qui ne supporte pas l'altitude

      Posté par  (site Web personnel) . Évalué à 7.

      Le titre est juste mais pour les imprimantes …

      Dans les années 90 les imprimantes laser HP coutaient assez cher mais bon pour un usage pro cela passe.

      Un client de Tignes en veut une, pas de problème …
      Livraison dans l'est lyonnais, test … ok … écriture de quelques "drivers" (spooler unix) bref nickel je l'envoie

      Quelques jours plus tard … probleme elle ne fonctionne pas … on essaye quelques trucs mais bon rien … renvoyez la je verrais avec le constructeur.

      Une fois déballé, nickel tout marche sans problème … bizarre …

      Je vous passe les détails car l'imprimante est repartie puis revenu car La haut elle ne fonctionnait pas .

      Et par hasard en lisant les caractéristiques techniques sur la doc :

      altitude maximale : 1800 m

      Tignes : 2100m … dommage

      Pendant quelques années ce client s'est passé d'imprimante Laser …

      • [^] # Re: le pc qui ne supporte pas l'altitude

        Posté par  . Évalué à 3. Dernière modification le 05/07/21 à 18:04.

        De mémoire les écrans plasma étaient aussi calibrés pour une altitude particulière. Dans un chalet à 2000m on peur avoir du bruit parasite.

      • [^] # Re: le pc qui ne supporte pas l'altitude

        Posté par  . Évalué à 3.

        Je n'ai pas d'anecdote amusante à raconter, mais tu viens de répondre à une question que je me suis posée il y a quelques années.
        On reçoit de nouvelles imprimantes laser au boulot. J'en déballe une, et je passe en revue les paramètres qui sont disponibles. Je tombe sur un paramètre qui s'appelle Altitude. Je rentre dedans en me demandant si l'imprimante va m'afficher l'altitude ou si je dois lui donner l'altitude, mais rien, je peux seulement activer ou désactiver cette option. Intrigué, je cherche des info. dans la doc., mais celle-ci dit juste qu'il faut activer ce paramètre si l'on se trouve au dessus de 2000m. Je me suis demandé si cette option avait vraiment un intérêt, visiblement oui. Je ne sais pas sur quoi ça agit, mais ton client en aurait eu besoin.

        • [^] # Re: le pc qui ne supporte pas l'altitude

          Posté par  (site Web personnel) . Évalué à 2.

          La pression atmosphérique n'est pas la même en montagne

          Cela joue sur plein de choses … les imprimantes les voitures et certainement d'autres choses

          C'est l'intérêt de ce genre de dépeche/journal : l'échange d'expérience et en plus dans certain cas c'est marrant.

  • # Installation de Windows qui plante toujours au même moment

    Posté par  . Évalué à 9.

    Durant l'été 2001 je devais installer MS-Windows (95 je suppose) sur un PC pour mon travail. Rien de bien palpitant à première vue mais: le logiciel d'installation démarre du CD, pose les questions habituelles puis finalement commence la partie lourde: reconnaissance du matériel, configuration des drivers et copie de fichiers (tiercé non gagnant :-) ). Dans moins d'une heure je pourrais commencer à travailler… mais au beau milieu de la procédure, la machine plante et s'arrête. Comme il s'agit d'un PC assemblé avec des pièces de provenance pas forcément très noble, je penche sur un problème de compatibilité entre le logiciel et le matériel. Je fais un reset du BIOS et recommence… au bout d'une belle demi-heure sensiblement au même point la machine s'arrête. Dans la journée je multiplie les tentatives infructueuses, puis finalement prépare un support d'installation Debian avec un autre ordinateur pour lancer l'install… qui va elle aussi planter. Le lendemain je décide d'ouvrir la machine et de retirer tout ce qui n'est pas nécessaire (lecteur de disquettes) ou de retirer-remonter ce qui l'est (RAM) … et découvre un amas effrayant de poussière coincé dans le CPU qui l'empêchait carrément de tourner! Pour se protéger de la surchauffe le CPU s'éteignait (ou plantait, je ne sais pas trop) le temps dont il avait besoin pour arriver à cet état faisait planter mon installation presque toujours au même moment… mais n'avait rien à voir avec ce que faisait réellement la machine! :-)

  • # Commentaire supprimé

    Posté par  . Évalué à 10.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Les claviers qui bloquent tout

      Posté par  (site Web personnel) . Évalué à 2.

      Certains périphériques s'annoncent comme support de stockage avec auto-execution pour le chargement automatique du driver. Comme c'est "transparent" pour l'utilisateur…

      Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

  • # Un village perd la télé tout les matins à 7h pendant 18 mois

    Posté par  . Évalué à 7. Dernière modification le 08/06/21 à 16:13.

    Cela se passait assez récemment dans un petit village du Pays de Gales.

    Tout les matins à 7h, les 400 habitants perdait temporairement leur signal TV.

    Au final, il s'est avéré que le problème venait d'un vieux poste que son propriétaire allumait probablement pour regarder les infos en prenant son petit déjeuner.

    https://www.bbc.com/news/uk-wales-54239180

  • # D'autres

    Posté par  (site Web personnel) . Évalué à 7.

    Mais le plus improbable que j'ai connu reste : LinuxFr.org avec une horloge qui cyclait sur 4s.

  • # Petit bug pas totalement identifié

    Posté par  . Évalué à 5.

    J'ai un petit bug actuellement avec certains jeux (notamment Descenders et Counter-Strike: GO sur Steam).

    Je dispose de deux manettes : une manette officielle Gamecube branchée avec un adaptateur Gamecube/usb non-officiel et un Steam Controller sans fil.

    Ma manette Gamecube ne fonctionne pas nativement avec la totalité des jeux Steam. C'est normal. Je pourrai la faire fonctionner avec un fichier xbox360cemu.ini mais la paresse m'en empêche.

    Cependant, si elle est branchée, elle fera systématiquement planter certains jeux au démarrage. Avant de m'en rendre compte, j'ai essayé de réinstaller le driver graphique, de revenir sur un kernel vanilla, de revenir sur des versions antérieures kernel et driver… Sans résultat. Les logs étant peu loquaces, difficile de voir d'où venait le problème.

    Un beau jour, alors que je revenais de chez un ami chez qui j'avais apporté ma manette Gamecube (donc débranchée de mon PC), je lance un jeu dont je sais qu'il ne démarre plus… Et là il démarre !

    N'ayant rien changé sur mon système à part l'adapteur et la manette Gamecube débranchés, le problème était devenu évident. D'ailleurs si je branche la manette Gamecube sur un de ces jeux déjà démarré, il crashera automatiquement.

    Ce bug est toujours présent et continue de m'embêter de temps en temps. La résolution est simple mais il serait intéressant que je fouille plus en profondeur la raison de ces crashs.

    La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.

  • # J'ai eu la même que celle de la Xbox !

    Posté par  . Évalué à 7.

    Ou presque !

    Je travaillais sur des box TV, qui pouvaient être mises en veille et rallumées via une télécommande IR.

    La mise en veille se passait au travers de Lirc sous Linux, et déclenchait (en gros) un suspend du kernel Linux.
    Le réveil, lui, était géré par le microcontrolleur IR, qui déclenchait une interruption sur le CPU principal, ce qui réveillait le kernel.

    Lors de mes tests, aléatoirement, des box sortaient de leur veille sur mon bureau. Mais seulement celles tournées vers la fenêtre.

    Il s'est avéré que le pattern dans le microcontrolleur IR, permettant de déclencher l'interruption de réveil du CPU principal, était trop court, et que le soleil passant derrière les nuages à travers la fenêtre parvenait de temps en temps à reproduire ;)

    Après avoir rallongé le pattern suivant le signal du bouton power de la télécommande, le bug a totalement disparu !

  • # Quelques anecdotes sur le même sujet

    Posté par  (site Web personnel) . Évalué à 10. Dernière modification le 04/07/21 à 12:50.

    Merci pour cette publication non seulement drôle, mais aussi instructive.

    Et je vais même apporter quelques anecdotes à l'édifice :

    En gros tout cela date d'une époque ou les cables n'était pas aussi bien protégé et blindé que maintenant, l'USB n'existait pas, le RJ45 pas encore répandu et le RS232 et le port paralelle régnait en maître sur les liaisons.

    La première je la tiens d'un tech de chez HP, l'histoire s'étale sur plusieurs mois.
    Une machine se plantait régulièrement, de manière aléatoire. De nombreux composant ont été changé et le réseau électrique vérifié … mais les problèmes continuaient.

    Jusqu'au jour ou une personne en lisant le carnet d'incident a émis une hypothèse bizarre en constatant que les incidents ne se déclenchaient qu'à marée basse …

    Après quelques recherches plus poussées, le batiment, assez proche de l'océan, avait la "terre" relié dans un puits qui n'était pas inondé à marée basse et ne faisait plus office de prise de terre.

    Les anecdotes suivantes, je les ai vécues et sont un peu du même style :

    Le terminal d'un client devenait dingue de temps en temps, se bloquait ou affichait des caractères ésotériques. Après quelques semaines on c'est aperçu que cela n'intervenait que entre 9h30 et 10h30 et particulièrement certains jours.
    En fait de l'autre coté du mur se trouvait le labo ou se cuisinait des centaines de repas tout les jours et le terminal était juste trop proche de l'éplucheur à patates industriel, pourvu d'un énorme moteur électrique et qui à chaque utilisation pertubait le terminal, en déplaçant le bureau et le terminal le problème a été réglé.
    Mais le syndrome de l'éplucheur à patate nous fait rire pendant longtemps …

    Un autre client, dans une station de ski, donnait au veilleur de nuit de quoi s'occuper et il devait effectuer quelques saisies sur un terminal.
    Très vite il s'est plaint comme quoi ce terminal était inexploitable car l'écran faisait des zig zags.
    En journée, ce poste servait pour l'accueil des skieurs et fonctionnait depuis longtemps, plusieurs années même, sans aucun problème.
    Il a fallu se déplacer et attendre avec le veilleur de nuit pour constater le phénomène et la surprise vers 23h l'écran faisait bien des zig zags et était inutilisable.
    de manière assez impressionante, un peu comme quand on réglait une télé cathodique sur le bon canal.
    En fait le chauffage au sol se déclenchait à 23h et perturbait le fonctionnement du poste pendant sa mise en chauffe.
    Vu que personne ne bossait à cette heure personne n'avait remarqué le problème.

    Le gag suivant, je l'ai résolu tout à fait par hasard, une imprimante matricielle choisit spécialement pour de grosses éditions ( stats, facturation mensuelles …) qui pouvait durer plusieurs heures.

    Celle ci de temps en temps éditait des caractères ésotériques de manière totalement aléatoire, parfois même en plein milieu d'une grosse édition.

    Changement de cable, vérification diverses etc … sur place je n'arrivais pas a reproduire le problème et je me revois provoquer des arrêts (fin de papier, imprimante offline etc … ), mais non tout fonctionnait parfaitement, la liaisons paralèlle communiquait bien avec le serveur. et tout était bien géré.

    Cela venait d'ailleurs mais d'ou ?

    Jusqu'au jour ou par hasard j'ai eu besoin d'un stylo ou de papier pour l'imprimante et l'on m'a ouvert la pièce ou se trouvait le stock de fourniture qui se trouvait juste en face de l'autre coté du couloir ou se trouvait le serveur et l'imprimante.
    Et la le néon, certainement ancien, mettait plusieurs minutes à se stabiliser et clignotait de manière assez pénible.

    De retour dans la salle serveur : les caractères ésotériques étaient présent et je venais de les provoquer. En changeant le néon le problème a été résolu.

    J'ai gardé cette anecdote pour la fin car la aussi le problème ne venait pas du matériel.

    Une salle avec plusieurs postes ou s'effectuait de la saisie des commandes à un rythme assez intense, les utilisatrices (désolé mais il n'y avait vraiment que des femmes dans cette salle) avait une connaissance quasi parfaite du matériel (DEC vt220 je crois ..) et saisissait plus vite que ne pouvait gérer le serveur.

    En gros elles étaient capables de saisir plusieurs commandes dans le buffer clavier et après, pendant 1 à 2 minutes elles regardaient le terminal remplir les zones et valider les commandes. Impressionant.

    D'ailleurs la séquence d'arrêt logicielle historiquement était le 'Q' majuscule et parfois celui ci était interprété comme un arrêt du traitement et génait cette saisie intensive.
    J'avais re paramètré le logiciel pour que l'arrêt soit pris en compte avec le '#' très peu utilisé à l'époque, sauf par les devs, et il fallait faire ALT+3 pour l'obtenir.

    Mais malgré cette modification, une personne se plaignait que parfois elle avait droit à une interruption qui virait toute sa saisie.

    La encore j'ai du me rendre sur place pour comprendre ce qu'il se passait, en fait j'ai compris que les interruption logicielles venait du téléphone et que parfois quand cette utilisatrice prenait le téléphone cela déclenchait un arrêt logiciel.

    Mais le problème n'était pas d'origine électrique…

    Car le problème venait de la physionomie de la personne, pourvu d'une poitrine assez imposante et chaque fois qu'elle prenait le téléphone, sa poitrine touchait le clavier et dans certains cas déclenchait la séquence de touche pour l'arrêt logiciel.

    Restait à trouver une manière diplomatique pour évoquer et résoudre ce problème.

    Je me voyais mal en parler directement avec la personne et donc je suis allé trouver son responsable pour lui expliquer le problème, et qu'il suffisait de déplacer le téléphone pour le résoudre.
    Il a esquissé un sourire et m'a dit qu'il se chargeait de la "résolution". ouf

    Comme quoi l'informatique n'est pas toujours un long fleuve tranquille …

    • [^] # Re: Quelques anecdotes sur le même sujet

      Posté par  (site Web personnel) . Évalué à 5.

      Merci pour cette publication non seulement drôle, mais aussi instructive.

      Et dire que cette dépêche a failli être abandonnée ! En soi, non seulement elle est intéressante, mais les anecdotes qui sont rajoutées dans les commentaires ajoutent des éléments tout aussi drôles et instructifs. Merci pour les tiennes.

      « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

      • [^] # Re: Quelques anecdotes sur le même sujet

        Posté par  (site Web personnel) . Évalué à 2. Dernière modification le 04/07/21 à 14:27.

        Oh de rien, d'ailleurs je les avais déjà raconté sur ce site, mais la il y a l'occasion de centraliser plein d'histoires …

        Le problème c'est que je m'aperçois que mes anecdotes datent du précédent siècle, ça rajeunis pas.

        cela aurait été dommage d'abandonner une dépèche pareille, elle m'a beaucoup fait rire.

        Et puis c'est formateur n'oubliez jamais la devise shadok :

        s'il n' y a pas de solution c'est qu'il n'y a pas de problème

    • [^] # Re: Quelques anecdotes sur le même sujet

      Posté par  . Évalué à 5.

      Il a esquissé un sourire et m'a dit qu'il se chargeait de la "résolution". ouf

      C'est ce jour-là que le poste de "teneur de poitrine d'opératrice au-dessus du clavier lors d'utilisation de téléphone" a été ouvert.

      Beaucoup de candidats peu d'élus.

      *splash!*

    • [^] # Re: Quelques anecdotes sur le même sujet

      Posté par  . Évalué à 10.

      Bon, je me demandais où poster ça, mais c'est bien sous ton message que ça a le plus sa place.

      À l'époque où j'étais encore étudiant, quelques copains de ma "bande" de geeks avaient trouvé le bon filon pour gagner un peu d'argent en conservant du temps pour les études. On était au début des années 2000, et l'ADSL, s'il n'était pas tout neuf, se démocratisait enfin pour de vrai, et les fournisseurs d'accès avaient besoin de gens qui comprenaient un peu ce qu'il se passait à l'autre bout des mulots pour offrir un support "niveau 2" correct aux consommateurs relativement peu avisés.

      C'était l'époque pas vraiment bénite de la fameuse "raie manta", le modem ADSL qui a permis de drastiquement réduire les coûts initiaux d'installation. Son principal défaut, qui en a fait un cauchemar: il tirait fort sur les 500mA autorisés à l'époque par l'USB. Si fort que beaucoup de contrôleurs USB finissaient par lui couper le jus. Heureusement, à l'époque, les MMORPG n'était pas encore trop en vogue. En revanche, en tant que technicien de support, répéter à longueur de journée à ses clients désespérés qu'on ne peut pas aller plus loin dans le dépannage aujourd'hui parce qu'il faut qu'ils achètent une carte contrôleur USB sur bus PCI, ou qu'ils peuvent éventuellement essayer un hub USB alimenté sur secteur, c'est lourd. Il avait pas beaucoup de partisans dans la hotline, ce modem, face à son prédécesseur (l'Alcatel 1000, un humble machin noir qui prenait beaucoup de place mais qui juste marchait). Et on va voir qu'il avait un autre défaut moins prégnant, mais qui nous avait quand même un peu occupé.

      En effet, un client équipé de cette malfaisante sélacienne appelle un jour la hotline. Le niveau 1 passe rapidement l'appel au niveau supérieur en expliquant qu'il n'y a rien dans les scripts qui leur sont fournis pour mener des exorcismes. Le technicien qui prend l'appel se retrouve face (façon de parler, évidemment, la visio à l'époque, c'était NetMeeting dans des résolutions qui te permettaient pas de savoir si ton interlocuteur avait bel et bien une face, on faisait donc tout par téléphone) à un pauvre hère tout à fait affable mais désolé de nous informer que, depuis quelques semaines, tous les soirs après le journal télévisé, son accès Internet qui fonctionnait parfaitement jusqu'alors cessait de fonctionner jusqu'au lendemain. Le technicien fait tous les diagnostics qu'il parvient à caser dans les 30 minutes gentiment imparties par France Télécom à l'époque pour les numéros surtaxés, sans succès, mais par la force de l'habitude, il avait largement eu le temps de dire au monsieur de rappeler le lendemain au moment de la coupure de son accès, s'ils ne trouvaient aucune solution ensemble avant le bip final ce jour là. Le client a rappelé plusieurs soirs comme ça, changeant souvent d'interlocuteur au jeu de la roulette du PABX, avant que son cas ne devienne un sujet de discussion dans les couloirs et n'éveille l'intérêt d'un collègue dont j'ai oublié le nom, mais que j'appellerai simplement "Gourou" dans ces lignes.

      Je choisis Gourou parce que c'était un peu beaucoup notre gourou à nous, simples quidams hébétés du "niveau 2". Officiellement, comme tous les FAI, le support ne s'occupait que des configurations standards et n'avait rien à offrir aux subversifs qui s'amusaient à accéder à Internet avec des machines sous Linux, avec des Palm d'avant la 2G greffés d'un modem, avec de luxueux Psion, des BSD ou autres aberrations électroniques de ce genre. Mais en vrai de vrai, on faisait ce qu'on pouvait pour aider tous ceux qui nous appelaient avec autre chose que des injures (ben ouais, une hotline, c'est souvent chaud, rapport au fait que les clients satisfaits appellent peu). Et quand on tombait sur un numéro exotique, ou quand on avait un type qui perdait sa connexion tous les soirs à 20h pour une raison mystérieuse, par exemple, on allait taper sur l'épaule de Gourou, il faisait redémarrer son PC à son client pour avoir un prétexte à une mise en attente de quelques secondes, il écoutait nos débuts d'explication comme un mélomane écoute les premières notes d'un grand classique et il nous donnait la solution. Commencer ce métier avec un type comme ça juste à côté de soi, c'est aussi confortable que des charentaises.

      Bref, notre client finit par tomber sur Gourou qui sait déjà tout ce qu'il y a a savoir de son cas, et qui prend comme nous tous en pitié les usagers qui, en dépit du problème qui semble leur tomber dessus comme une injuste fatalité sans cause identifiable, savent garder tout leur calme et leur avenant. Immédiatement, il fait la seule chose qui nous était véritablement demandée à l'embauche: il suit une démarche inductive. Il demande au type de refaire le film de sa routine vespérale, du dernier moment où il peut consulter ses mails à celui où il constate que… ben… ypeupu. Là, c'est un moment un peu chiant dans le métier du technicien de support niveau 2, tu vois, avec les gens qui te racontent TOUT, parce que tu le leur as demandé, parce que à chaque bout du fil chacun est conscient que ce qui pourrait paraître insignifiant au client est potentiellement crucial pour le technicien. C'est là qu'en réside l'horreur: le bon client, c'est celui qui va jusqu'à te raconter le moment où il caresse Molosse, qui s'appelle Molosse parce que c'est un gros toutou, mais qu'il est doux et mignon comme tout, surtout quand il va poser sa grosse tête sur le modem parce que c'est tout chaud. Tu aimerais t'en cogner, de Molosse, mais tu peux pas.

      Mais bon, dans notre cas, le client, il avait pas de chien, hein. Rêvons pas. En revanche, donc, il raconte: je ferme Outlook Express, je vais dans la cuisine me servir un verre et prendre quelques cahouètes, je m'installe dans mon canapé, je pose le verre et les cahouètes sur la table basse en verre, j'allume la télé, ça me fait mal aux yeux alors je me relève pour allumer le lampadaire, je me rassieds, je mets la 2, parce que le journal vient de commencer, je me d- STOP !

      Là, c'est le coup de génie de Gourou, qui, une fois de plus, sans cape, sans slip rouge enfilé à la Dagobert, sans même avoir préserver son anonymat en retirant sa paire de lunettes qui corrige pourtant pas grand chose, sauve un quidam de la fracture numérique. Il va poser une question, mais il a déjà compris que c'est là qu'est l'os, Gourou. Tu es prêt, simple collègue qui comme les autres a pris ta pause dès que tu as su que cet appel était en cours, pour être là pour cet événement qui allait évidemment rester dans la mémoire collective du service, cet événement annoncé par les astres… es-tu prêt, donc, à arrêter de mâcher bruyamment ton jambon-beurre, parce qu'il faut bien se sustenter, tout de même… bon, t'es prêt à la voir, oui ou merde, cette lumière divine émise par la logique implacable du mec qui dispose à la fois d'un cerveau qui marche et des connaissances sur les limites technologiques inhérentes à chaque rouage de la machine ?

      Gourou, après avoir interrompu le client de manière un peu cavalière, donc, pose la question qui compte, dans cette histoire: le lampadaire, il est près de l'ordinateur ?

      Ben ouais, c'était ça, la solution. Parce qu'à l'époque, chez les gens, la vaste majorité des lampadaires, c'était encore des halogènes avec des transfos pourraves. Et que l'autre défaut de la rayonnante raie vis-à-vis du bon vieil Alcatel 1000, c'est qu'elle était pas blindée (le fer à 10 sous, l'était trop cher). Et donc, notre pauvre client, quand il allumait sa lumière, il se coupait la raie :-(

      Mais rassurez-vous: c'est aussi l'époque où Free à sorti la première Freebox, qui a fait rire nos commerciaux pendant 2 semaines, avant qu'ils paniquent au point de nous pondre un argumentaire ultra-bidon en mode FUD pour essayer de retenir les clients (mais bon, nous, c'était pas notre job de leur mentir pour les faire rester, c'est le rôle du service fidélisation, ça). Je suis sûr que le client a finit par avoir un vrai modem qui marchait du coup. Et malheureusement, le FAI qui m'employait n'a pas survécu à ce raz-de-marée engagé par Free sur l'ADSL, comme tous les petits. Je ne sais pas ce qu'est devenu Gourou, mais s'il se reconnait dans ces lignes, je lui passe un bonjour ému. Tu m'as marqué tant par ton expertise que par ta gentillesse bourrue, Monsieur ! C'était le bon temps :-)

      • [^] # Re: Quelques anecdotes sur le même sujet

        Posté par  (site Web personnel) . Évalué à 3.

        Pas mal fallait y penser à l'halogène …

        Je profite de l'occasion pour écrire cette histoire que l'on m'a raconté et qui d'après mes souvenirs date un peu. Par contre je ne sais pas si cela est véridique.

        On est encore au temps ou France télécom existe encore et n'est pas devenu Orange.

        Service des réclamations : une dame se plaint de son installation récente du téléphone et trouve que le cable mural est beaucoup trop court, et qu'il faudrait le rallonger.

        L'employé de FT (ou peut être un renfort d'été) a une idée de génie et lui dit … s'il vous plaît madame je vous prie de bien vouloir patienter …
        Il prévient ses camarades et avec un ton super sérieux répond à la dame :

        • Madame, je suis désolé nous n'avons pas de technicien disponible de suite, par contre j'ai prévenu le central pour qu'il vous donne un peu plus de marge et si vous tirez assez fort d'un grand coup sec sur le cable cela devrait le faire …

        Et la après quelques secondes on a pu entendre le "toooouuuut tooouuut" classique d'une coupure de ligne … Hilarité générale dans le service.

        le lendemain le chef du "bureau d'en haut" réunit le service et bien qu'il ait apprécié la touche humoristique, cela ne devait absolument pas se reproduire et qu'il permettrait ce genre de chose une seule et unique fois …

        A l'époque cela m'avait fait bien rigoler.

  • # Les enquêtes de l'ANFR

    Posté par  . Évalué à 6.

    Dans le même style que toutes ces anecdotes, quoique plus orientées radio-fréquences, vous pouvez jeter un œil sur les enquêtes que publie l'ANFR (Agence Nationale des Fréquences) sur son site, juste .
    Y'en a qui valent leur pesant de cahouètes.

  • # Le Thinkpad allergique au TGV entre Le Mans et Paris

    Posté par  (site Web personnel) . Évalué à 5.

    Allez, j'y vais de mon anecdote.

    J'ai effectué pendant quelques années des A/R réguliers Rennes/Paris en TGV. J'avais un Thinkpad qui fonctionnait parfaitement sauf quand j'étais à bord du TGV… et à grande vitesse, uniquement. En gros, je pouvais travailler jusqu'au Mans, j'allais prendre mon petit déjeuner ensuite :)
    Il se bloquait régulièrement pendant environ 10sec, le rendant à peu près inutilisable. Aucun autre moyen de transport n'impactait mon outil de travail.

    Résultat ?

    Ce Thinkpad était équippé d'un disque IBM avec protection contre les chutes: un accéléromètre était censé détecter les chutes et provoquer le rangement des têtes de lecture.

    Un soft était censé recevoir les infos de l'accéléromètre et envoyer une commande au disque dur en cas d'accélération trop forte. Le seuil d'accélération était paramétrable.

    J'ai finalement trouvé que le seuil d'accélération réglé par défaut dans le paquet Debian correspondait à peu près aux vibrations du TGV à grande vitesse. Un réglage différent de ce seuil a réglé le problème…

    "Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.