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

Posté par Collectif le 05 juin 2021 à 22:23. Édité par Ysabeau 🧶, pulkomandy, teoB, Benoît Sibaud, olivierweb, Snark, palm123, Anonyme, ariasuni, gUI, Tonton Th, legranblon, BAud, Vincent-Xavier JUMEL et Christophe ---. Modéré par Xavier Teyssier. Licence CC By‑SA.

Étiquettes :

juin

2021

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 piste du plantage de la Xbox
Les vrais programmeurs écrivent en Fortran (en fait non)
OpenOffice n’imprime pas le mardi
Le Raspberry Pi qui redémarre quand on le prend en photo
Le serveur mail qui refuse d’envoyer les mails plus loin que 500 miles (environ 805 km)
Un chat assis sur le clavier fait planter LightDM
La voiture allergique à la glace à la vanille

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.

Version originale.

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.

Version originale.

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 :

laisse l’ordinateur sans surveillance dans une salle froide avec un chat chaud ;

le chat va s’assoir sur le clavier de l’ordinateur ;

attendre une heure ;

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 parfum¹. 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.

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

Software Folklore (270 clics)

# Attaques hardware

Posté par Philippe F (site web personnel) le 06 juin 2021 à 00:39. É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 Nicolas Boulay (site web personnel) le 07 juin 2021 à 09:52. É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 Philippe F (site web personnel) le 08 juin 2021 à 10:00. Évalué à 6.
    
    La technique s'est modernisée au fil des années. Les labos utilisent maintenant des laser pour cibler très précisément la zone de la puce qu'ils veulent saturer. Et donc ils bypassent tranquillement ce genre de détecteur.
    - [^] # Re: Attaques hardware
      
      Posté par nive le 08 juin 2021 à 19:26. Évalué à 5.
      
      Pour ceux qui se demande comment ça fonctionne (moi le premier), il y a eu une présentation sur le sujet. En français, simple à comprendre et didactique !
      https://sstic.org/2021/presentation/defeating_a_secure_element_with_multiple_laser_fault_injections/
    - [^] # Re: Attaques hardware
      
      Posté par Nicolas Boulay (site web personnel) le 09 juin 2021 à 09:31. Évalué à 6.
      
      Lsm, c est pour "laser scanning microscope", c était très precis.
      
      "La première sécurité est la liberté"
- [^] # Re: Attaques hardware
  
  Posté par barmic 🦦 le 07 juin 2021 à 10:52. É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…
  
  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
  - [^] # Re: Attaques hardware
    
    Posté par Philippe F (site web personnel) le 08 juin 2021 à 10:07. É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 chimrod (site web personnel) le 08 juin 2021 à 20:43. É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 Tit le 09 juin 2021 à 09:34. É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 chimrod (site web personnel) le 09 juin 2021 à 18:07. É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 Nicolas Boulay (site web personnel) le 09 juin 2021 à 09:35. É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 Matthieu Moy (site web personnel) le 09 juin 2021 à 19:06. É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 Nicolas Boulay (site web personnel) le 11 juin 2021 à 19:59. É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 barmic 🦦 le 08 juin 2021 à 23:47. É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é :(
      
      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
  - [^] # Re: Attaques hardware
    
    Posté par aiolos le 04 juillet 2021 à 20:26. Évalué à 2. Dernière modification le 04 juillet 2021 à 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 Vlobulle le 05 juillet 2021 à 18:16. É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 Thomas Debesse (site web personnel) le 06 juin 2021 à 00:44. É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 gUI (Mastodon) le 06 juin 2021 à 08:26. É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 cg le 06 juin 2021 à 10:12. Évalué à 9. Dernière modification le 06 juin 2021 à 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 Gil Cot ✔ (site web personnel, Mastodon) le 06 juin 2021 à 14:15. É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 Chuck #1 le 06 juin 2021 à 10:16. É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 Gil Cot ✔ (site web personnel, Mastodon) le 06 juin 2021 à 14:18. É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 orfenor le 06 juin 2021 à 11:44. Évalué à 3.

et quand une était finie

instruction ?
- [^] # Re: mot manquant
  
  Posté par Benoît Sibaud (site web personnel) le 06 juin 2021 à 12:04. É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 orfenor le 06 juin 2021 à 16:40. Évalué à 8.
    
    Bien vu. On aurait pu écrire « quand l'une d'elles était finie…"
# Cela me rappelle un bug ...

Posté par SChauveau le 06 juin 2021 à 19:28. É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 paulez (site web personnel) le 05 juillet 2021 à 16:10. É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 pulkomandy (site web personnel, Mastodon) le 05 juillet 2021 à 23:41. É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 paulez (site web personnel) le 08 juillet 2021 à 16:02. Évalué à 1. Dernière modification le 08 juillet 2021 à 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 OLeave le 06 juin 2021 à 19:41. É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 Ysabeau 🧶 (site web personnel, Mastodon) le 06 juin 2021 à 20:25. É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 OLeave le 06 juin 2021 à 20:47. É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 Ysabeau 🧶 (site web personnel, Mastodon) le 06 juin 2021 à 20:52. É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 ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 07 juin 2021 à 06:26. Évalué à 3. Dernière modification le 07 juin 2021 à 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 Ysabeau 🧶 (site web personnel, Mastodon) le 07 juin 2021 à 10:00. É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 ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 07 juin 2021 à 10:06. Évalué à 4. Dernière modification le 07 juin 2021 à 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 SlowBrain (site web personnel) le 06 juin 2021 à 22:53. É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 pulkomandy (site web personnel, Mastodon) le 07 juin 2021 à 08:24. É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 lejocelyn (site web personnel) le 07 juin 2021 à 09:59. Évalué à 10. Dernière modification le 07 juin 2021 à 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 cyberjunkie le 02 juillet 2021 à 21:55. É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 2PetitsVerres le 07 juin 2021 à 10:29. Évalué à 7. Dernière modification le 07 juin 2021 à 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 pulkomandy (site web personnel, Mastodon) le 07 juin 2021 à 10:56. É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 Ysabeau 🧶 (site web personnel, Mastodon) le 07 juin 2021 à 11:00. É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 2PetitsVerres le 07 juin 2021 à 11:24. É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 SChauveau le 07 juin 2021 à 14:02. É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 Anonyme le 07 juin 2021 à 11:35. Évalué à 4.
  
  Ce commentaire a été supprimé par l’équipe de modération.
  - [^] # Re: Le plantage horaire
    
    Posté par 2PetitsVerres le 07 juin 2021 à 11:41. É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 Anonyme le 07 juin 2021 à 11:45. Évalué à 10.
  
  Ce commentaire a été supprimé par l’équipe de modération.
  - [^] # Re: Le plantage horaire
    
    Posté par 2PetitsVerres le 07 juin 2021 à 11:53. É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 Anonyme le 07 juin 2021 à 11:59. Évalué à 4.
      
      Ce commentaire a été supprimé par l’équipe de modération.
    - [^] # Re: Le plantage horaire
      
      Posté par SChauveau le 07 juin 2021 à 14:19. É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
      - [^] # Re: Le plantage horaire
        
        Posté par pulkomandy (site web personnel, Mastodon) le 07 juin 2021 à 22:52. Évalué à 10.
        
        On peut mélanger les deux:
        
        Pourquoi les informaticiens confondent noël et halloween?
        
        Parce que 25 DEC = 31 OCT
# Mon père automaticien me raconte souvent un histoire du même genre...

Posté par syj le 07 juin 2021 à 11:12. É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 ElectronLibre63 le 07 juin 2021 à 16:22. É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 syj le 07 juin 2021 à 17:15. É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 syj le 08 juin 2021 à 15:43. É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 Psychofox (Mastodon) le 08 juin 2021 à 09:05. É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 Misc (site web personnel) le 08 juin 2021 à 09:16. É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 pulkomandy (site web personnel, Mastodon) le 08 juin 2021 à 12:39. É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 Ysabeau 🧶 (site web personnel, Mastodon) le 07 juin 2021 à 14:21. Évalué à 4. Dernière modification le 07 juin 2021 à 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 informaticienne¹ 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éphine² 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âbles³ 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 Laurent Pointecouteau (site web personnel, Mastodon) le 07 juin 2021 à 14:24. É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.
- [^] # Re: En Union soviétique, c'est la glace qui est allergique à la voiture
  
  Posté par SChauveau le 07 juin 2021 à 14:33. Évalué à 7.
  
  «Upon discovering this, Sergei immediately filed immigration papers with any country that would listen»
  
  Pourquoi? La réponse appropriée consistait à éloigner le serveur de quelques mètres ou à insérer une plaque de métal pour blinder la RAM.
  - [^] # Re: En Union soviétique, c'est la glace qui est allergique à la voiture
    
    Posté par cg le 07 juin 2021 à 22:32. Évalué à 5.
    
    J'ai rien compris, l'ordi était pas derrière un rideau de fer ?
    - [^] # Re: En Union soviétique, c'est la glace qui est allergique à la voiture
      
      Posté par wismerhill le 08 juin 2021 à 17:50. Évalué à 4.
      
      Un rideau de plomb aurait été plus efficace.
      - [^] # Re: En Union soviétique, c'est la glace qui est allergique à la voiture
        
        Posté par cg le 09 juin 2021 à 00:54. Évalué à 1.
        
        Du plomb, bravo ! Et l'environnement alors ? Pourquoi pas de l'uranium tant qu'on y est ?
# GitLab

Posté par Matthieu Moy (site web personnel) le 07 juin 2021 à 14:56. É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 Psychofox (Mastodon) le 08 juin 2021 à 09:27. É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 Ysabeau 🧶 (site web personnel, Mastodon) le 08 juin 2021 à 09:32. É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 Michaël (site web personnel) le 08 juin 2021 à 09:34. Évalué à 3.
  
  C'est pas la prise de courant qui déco-connait?
  - [^] # Re: le pc qui ne supporte pas l'altitude
    
    Posté par Psychofox (Mastodon) le 08 juin 2021 à 10:16. Évalué à 5. Dernière modification le 08 juin 2021 à 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 Arthur Accroc le 08 juin 2021 à 17:49. É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.
      
      « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
      - [^] # Re: Plutôt la température
        
        Posté par Pol' uX (site web personnel) le 08 juin 2021 à 21:48. É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 Christophe B. (site web personnel) le 03 juillet 2021 à 12:18. É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 Psychofox (Mastodon) le 05 juillet 2021 à 18:04. Évalué à 3. Dernière modification le 05 juillet 2021 à 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 ElectronLibre63 le 12 juillet 2021 à 16:08. É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 Christophe B. (site web personnel) le 12 juillet 2021 à 17:47. É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.
      - [^] # Re: le pc qui ne supporte pas l'altitude
        
        Posté par ElectronLibre63 le 15 juillet 2021 à 10:15. Évalué à 1.
        
        Je sais que c'est un problème de pression atmosphérique, ce que je voulais dire, c'est que je ne connais pas suffisamment le fonctionnement d'une imprimante laser pour savoir ce qui est sensible à ce point à la pression, et ce que change le paramètre pour permettre à l'imprimante de marcher au dessus de 2000m.
        Pour une voiture avec un moteur thermique, sans être mécanicien, j'imagine bien la difficulté de remplir les chambres de combustion, par contre la voiture électrique ne doit pas avoir de problème en altitude.
        
        [^] # Re: le pc qui ne supporte pas l'altitude
        
        Posté par Joël Thieffry (site web personnel) le 15 juillet 2021 à 18:31. Évalué à 5.
        
        Une imprimante laser utilise l’effet Corona https://fr.wikipedia.org/wiki/Effet_corona (rien à voir avec un quelconque virus), CF https://remy-mellet.com/wp-content/uploads/2011/04/impr_laser.pdf pour le fonctionnement général. Cet effet résulte de l’ionisation de l’air, or la permittivité diélectrique de l’air varie suivant la pression ambiante, donc de l’altitude.
        
        C’est ce qui est arrivé à Scotty Allen de la chaîne youtube Strange Parts dans sa récente vidéo https://www.youtube.com/watch?v=MIqK45nxcTo (EN) : il n’arrivait pas à faire fonctionner correctement son microscope électronique à balayage « de poche » à cause de décharges électroniques internes qui ne devraient pas normalement apparaître ; après plusieurs mois de vérifications avec le constructeur, il s’est avéré que l’appareil n’est pas prévu pour fonctionner à l’altitude de 2200 mètres où se situe l’atelier de Scotty.
        
        [^] # Re: le pc qui ne supporte pas l'altitude
        
        Posté par Christophe B. (site web personnel) le 16 juillet 2021 à 14:15. Évalué à 2.
        
        Des années que j'attends ce document … merci beaucoup ;)
        
        [^] # Re: le pc qui ne supporte pas l'altitude
        
        Posté par ElectronLibre63 le 26 juillet 2021 à 13:18. Évalué à 1.
        
        Super, merci pour l'explication.
# Installation de Windows qui plante toujours au même moment

Posté par Michaël (site web personnel) le 08 juin 2021 à 09:33. É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 Anonyme le 08 juin 2021 à 12:53. Évalué à 10.

Ce commentaire a été supprimé par l’équipe de modération.
- [^] # Re: Les claviers qui bloquent tout
  
  Posté par GG (site web personnel) le 07 juillet 2021 à 03:05. É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 SChauveau le 08 juin 2021 à 16:11. Évalué à 7. Dernière modification le 08 juin 2021 à 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 Benoît Sibaud (site web personnel) le 08 juin 2021 à 17:30. Évalué à 7.
- https://linuxfr.org/users/rootix/journaux/c-est-officiel-la-semaine-43-du-calendrier-n-existe-plus-et-a-ete-remplacee-par-la-semaine-53 "Deux fois la semaine 13. Pas de semaine 43. Et une semaine 53 pour commencer l'année."
- un samedi 41 septembre en milieu de soirée vers 22:72
- une machine à voter affichant une ouverture à 65516:65525:65502 le 64800/01/1994 (ces machines qui vont encore servir pour les élections de 2021 en France…) …
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 Nibel le 01 juillet 2021 à 17:43. É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 bluelambda le 02 juillet 2021 à 09:12. É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 Christophe B. (site web personnel) le 04 juillet 2021 à 12:49. Évalué à 10. Dernière modification le 04 juillet 2021 à 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 Ysabeau 🧶 (site web personnel, Mastodon) le 04 juillet 2021 à 14:04. É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 Christophe B. (site web personnel) le 04 juillet 2021 à 14:23. Évalué à 2. Dernière modification le 04 juillet 2021 à 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 Faya le 04 juillet 2021 à 17:20. Évalué à 5.
      
      mais la il y a l'occasion de centraliser plein d'histoires …
      
      C'est ce que fait "The Daily WTF: Curious Perversions in Information Technology" et j'ai toujours voulu avoir une version française pour montrer aux non-développeurs (ou très jeunes développeurs) à quel point il est aisé d'avoir des bugs dans un programme. Et à quel point la résolution de bugs (ou la logique de celui qui a introduit le bug) peut être tortueuse.
- [^] # Re: Quelques anecdotes sur le même sujet
  
  Posté par eingousef le 06 juillet 2021 à 19:21. É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 lesensei le 06 juillet 2021 à 20:45. É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 Christophe B. (site web personnel) le 12 juillet 2021 à 18:13. É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 cyberjunkie le 04 juillet 2021 à 15:56. É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 là.
Y'en a qui valent leur pesant de cahouètes.
# Le Thinkpad allergique au TGV entre Le Mans et Paris

Posté par Jean Parpaillon (site web personnel) le 15 juillet 2021 à 11:25. É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
- [^] # Re: Le Thinkpad allergique au TGV entre Le Mans et Paris
  
  Posté par Ysabeau 🧶 (site web personnel, Mastodon) le 15 juillet 2021 à 11:53. Évalué à 3.
  
  Tu l'avais utilisé dans d'autres TGV aussi ? Juste par curiosité.
  
  « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
  - [^] # Re: Le Thinkpad allergique au TGV entre Le Mans et Paris
    
    Posté par Jean Parpaillon (site web personnel) le 15 juillet 2021 à 13:34. Évalué à 3.
    
    Je ne me rappelle plus, cela commence à dater. Comme j'avais trouvé une solution, je n'ai pas cherché si c'était LA solution.
    
    J'ai pu reproduire le cas assez de fois pour considérer que mon hypothèse était assez bonne.
    
    "Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
    - [^] # Re: Le Thinkpad allergique au TGV entre Le Mans et Paris
      
      Posté par BAud (site web personnel) le 18 juillet 2021 à 02:47. Évalué à 2.
      
      il suffit de prendre le bus ou le RER C actuellement, c'est la formation des débutants, ils ont tendance à freiner un peu plus fort que ceux plus expérimentés ;-)

Suivre le flux des commentaires

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