Curieuses perversions du monde informatique - 5

La première histoire. Lettres fatales

[ Original ]

Il était une fois, George a obtenu un emploi au bureau d'Initech. La société vient de louer plusieurs étages dans un ancien immeuble de bureaux qui est récemment passé de la catégorie du déclin urbain aux élégants cafés du rez-de-chaussée et à l'odeur du cirage et du rembourrage en cuir frais pour tout le monde.

C'était un vaste espace, et George était à ce stade de sa carrière quand il était censé avoir un bureau séparé avec vue sur la voie.

Sa première tâche a été de résoudre le problème dans la version Mac du logiciel de l'entreprise. Cela avait l'air parfait sous Windows, mais des bugs de rendu des polices sont apparus sous OSX. Ce bug est difficile à trouver, mais George était probablement un détective dans une vie antérieure, il était donc prêt pour ce test.

L'indice le plus important était l'histoire du contrôle de version. Au cours des trois dernières années, cinq développeurs ont travaillé sur le produit. Il semble que chacun d'eux a été dans l'entreprise pendant environ quatre mois, puis est parti. Pendant de nombreux mois, ils sont restés sans aucun changement, puis un nouveau développeur est venu et le cycle s'est répété. Comme George l'a découvert, leurs noms sont apparus tout le temps quand il a essayé de comprendre les fonctions, le travail et les causes des bogues du produit.

Étant donné que l'application était multiplateforme, les développeurs ont implémenté leur propre chargeur et rendu de polices. C'est du moins ce qu'il pensait. La structure interne des polices est une chose dangereuse et déroutante, et cela se reflète dans le code. Cela reflétait également le fait que divers programmeurs, qui n'avaient pas préservé son intégrité, y travaillaient un par un. C'était le chaos .

Dans le code, George a vu un tas d'aspects qui étaient sans aucun doute mauvais - des appels non sécurisés à memcpy , malloc sans arithmétique de pointeur free , qui travaillaient plus sur la confiance que sur la logique. Mais apparemment, rien de tout cela n'était à l'origine du problème de police.

Frustré, George a décidé de l'approcher de l'autre côté. Sur les écrans avec des bugs de rendu, il y a toujours eu une ou deux polices spécialisées. George a téléchargé les polices dans les utilitaires de vérification des polices d'Adobe et de Microsoft et a vu des rapports sur un tas d'erreurs.

Le code de téléchargement des polices était mauvais, mais les polices elles-mêmes étaient encore pires. Ayant identifié le problème, George a dit à son patron que les polices devaient être corrigées. Le patron l'a transmis au président de l'entreprise.

Le lendemain, le patron a approché George: "Le président veut vous rencontrer, de toute urgence ."

Le bureau du président ressemblait plus à une salle de conférence, mais sans table de conférence. Une longue pièce, d'un côté une table, des fenêtres sur tout le mur et une vue sur la rivière. Un président en colère était assis à son bureau.

«Qu'est-ce qui ne va pas avec vous deux? George, vous êtes ici depuis moins de quatre mois et vous perdez déjà mon temps - gaspillez-vous mon argent sur une idée folle d'un problème de polices ? "

«Mais ça l'est. Je peux montrer . "

«Dans la version Windows, la police fonctionne bien! Le problème devrait être en enfer. Je sais combien tu es payé. Je devrais peut-être prendre une calculatrice et calculer combien l'entreprise a coûté cette chasse aux fantômes? » Il a frappé la table pour que la calculatrice à côté du clavier saute un peu.

Les accusations ont continué, mais George savait déjà ce qu'il ferait après la réunion. À la fin de la journée, il a rendu son badge et son ordinateur portable de travail avec une déclaration de démission grossière et honnête.

Après un court congé sans solde, George a obtenu un nouvel emploi. Les années ont passé et il a déjà commencé à oublier le temps passé à Initech. Mais un jour, il a vu un message concernant la publication d'un correctif critique de vulnérabilité de Microsoft Windows. Il s'est avéré que le «code de traitement des polices tiers» pouvait entraîner l'exécution de code arbitraire dans certaines bibliothèques Windows. Après quelques recherches, George a confirmé son intuition: c'est le code Initech qui a causé le problème. De plus, le dernier binaire Initech a été libéré en 2008 - un mois après avoir quitté l'entreprise.

La deuxième histoire. Travailler sur le processus, ainsi qu'en dessous et au-dessus

[ Original ]

Lorsque Kevin a obtenu un emploi à Townbank à la fin des années 1980, il s'est retrouvé dans la même situation que des milliers d'autres programmeurs nouvellement créés avant et après lui: un programmeur d'entreprise n'écrit pas seulement du code - il doit s'en tenir au processus.

Le processus ne diffère des commandements stricts des religions du monde que par le fait qu'il a pour tâche de maintenir l'intégrité du code. Gloire au processus, qu'il soit béni, le processus est bon, vous devez toujours vous y conformer et, surtout, le processus vous est utile!

Pour la plupart des développeurs, le processus n'est pas si mauvais. Vous avez juste besoin de vous y habituer. Remplissez le formulaire, obtenez l'approbation, enregistrez un plan de test, rédigez la documentation d'assemblage - tout cela est en ordre. Cependant, comme Kevin l'a vite découvert, il y avait des processus à Townbank auxquels ni les vétérans ni les débutants ne pouvaient s'adapter.

Facteur Shiva

La première tâche de Kevin a été de travailler dans un groupe impliqué dans le plus grand projet du département informatique de Townbank, à savoir une migration à grande échelle d'un ordinateur central vieillissant progressivement vers plusieurs nouveaux systèmes VAX. En théorie, le processus semblait bon - les consultants ont rencontré le client et ont découvert quels systèmes seraient transférés, il était nécessaire de rédiger des spécifications, d'assigner des tâches aux développeurs, le service de contrôle de la qualité devait confirmer que le nouveau système fonctionnait comme l'ancien, après quoi le code serait mis en production .

Lorsque les chefs de projet ont développé le processus, on s'attendait à ce que les actions imprévues ne prennent toujours qu'une petite fraction des coûts totaux ou du temps nécessaire pour mettre en œuvre la fonction, et au début c'était le cas. Cependant, le projet a continué d'évoluer et plus les environnements ont été mis en service, plus Kevin et ses collègues développeurs ont dû ajouter du temps à leurs estimations. Officiellement, les développeurs l'appelaient différemment - testant l'intégration du système, configurant les serveurs, testant la compatibilité des médias, mais entre eux, ils appelaient ces retards par leur vrai nom: «Shiva factor».

Une affaire sérieuse!

Non pas que Shiva était un administrateur système incompétent ou inexpérimenté - en tout cas. En fait, lorsque Townbank a décidé de migrer du mainframe vers VAX, le nom de Shiva était au début d'une très courte liste de personnes capables de gérer une telle migration d'infrastructure. Shiva a repris l'affaire en toute responsabilité, présentant ses propres politiques qui pourraient aider à éliminer les défauts du processus. Par exemple, tous les matins, tous les développeurs, analystes ou employés du service de contrôle, avant d’entrer mercredi, devaient littéralement signer sur le tableau noir du bureau de Shiva pour confirmer leur présence physique. De plus, estimant que le suivi des actions du développeur était implémenté avec des détails insuffisants, il a introduit une protection de contrôle de version: pour chaque changement de code et transfert entre les environnements, un mémo était nécessaire. Et toutes les modifications auraient dû être apportées par son ID utilisateur. Et depuis son terminal.

Par temps calme, un petit changement peut être effectué en une seule journée, mais les jours calmes tombent souvent les jours fériés ou les week-ends. Les développeurs agacés se sont plaints à la haute direction, arguant que ces politiques ralentissaient le projet et semblaient complètement inutiles. En réponse, la direction a haussé les épaules - Shiva a défini ses objectifs au tout début du projet - des environnements sûrs, protégés de la contamination croisée avec d'autres codes et de l'incompétence des développeurs. Au final, les serveurs VAX étaient encore nouveaux, et même de nombreux développeurs seniors ne les maîtrisaient pas encore complètement.

Les masses murmuraient et maudissaient le destin, mais au lieu de se rebeller, de renverser Shiva et de mettre fin à son règne cruel, tout le monde s'est résigné et a continué à travailler. Malgré les obstacles et les efforts de Shiva, le processus s'est poursuivi, mais il y avait une situation que Shiva semblait négliger - et s'il était lui-même inaccessible?

Petit assistant programmeur

Bien que le terminal de Kevin ait montré qu'il travaillait dans un clone d'environnement de production, les noms des clients Nosmo King et Joe Blow ont clairement indiqué qu'il avait commis une faille grave - l'application s'est connectée par erreur à la base de données de l'environnement de développement, et après le déjeuner, il a dû la tester service de contrôle qualité. Dans une situation normale, il serait plus facile de corriger l'erreur - d'apporter des modifications au fichier de configuration dans l'environnement de développement et de reprendre le travail, mais le destin aurait souhaité que Shiva soit à une longue réunion et ne devrait apparaître que le lendemain.

Espérant que Shiva pourrait revenir plus tôt, Kevin se dirigea vers son bureau, mais ne vit qu'une chaise vide. Cependant, le clavier de Shiva a attiré son attention. Les lettres A, S, V, H et moi ont été effacées plus que les autres. Kevin savait que Shiva était ivre de pouvoir, mais était-il si narcissique qu'il était prêt à imprimer son nom encore et encore? ... Ou peut-être que c'est un indice? Pour le plaisir, Kevin est allé sur la ligne de commande et a entré "shiva" comme nom d'utilisateur et mot de passe. S'attendant à ce que Shiva puisse entrer dans le bureau à tout moment, Kevin a cliqué sur «Entrer» et a été choqué d'avoir pu terminer l'entrée.

C'était incroyable. C'était génial. Kevin savait qu'il devait partager sa découverte avec quelqu'un. Il a raconté cela à l'un des anciens combattants, qui était son mentor, mais sa réaction a été une surprise pour Kevin.

Il s’est avéré que la combinaison du nom d’utilisateur et du mot de passe de Shiva était le «secret» préféré de Townbank, connu depuis que Shiva travaillait en tant qu’administrateur du mainframe.

"Pour que Shiva ne reconnaisse pas", a expliqué à Kevin un autre développeur encore plus expérimenté, "nous jouons à ce jeu chaque fois que nous le relevons."

"Soit dit en passant, pour l'avenir", a-t-il poursuivi, "si vous ne voulez pas être pris et ruiné par la vie de tout le monde, alors vous devez entrer depuis votre terminal, et NON depuis son bureau."

La troisième histoire. Parle-moi grec

[ Original ]


Il y a plusieurs décennies, avant même l'avènement des imprimantes laser, des systèmes d'exploitation graphiques et des formats d'image indépendants de l'appareil, Gus travaillait au service informatique du collège local. En tant que projet personnel pour des moments de temps d'arrêt, il a décidé de trouver comment imprimer le texte en grec. Environ une semaine plus tard, il a mis au point un programme capable d'imprimer du texte grec classique sur une imprimante.

Le patron de Gus a travaillé comme directeur informatique, mais malgré cela, il s'est avéré être un spécialiste de la philologie ancienne. Il n'a jamais eu à voir le texte grec imprimé sur une imprimante ordinaire, et il était ravi. Le patron en a parlé à ses amis, ils en ont parlé, etc. Bientôt, le monde des érudits de la Grèce classique s'est transformé en un symposium enthousiaste et bruyant.

Gus a reçu un e-mail d'un professeur d'université inconnu en Arizona. Il a entendu le chef Gus parler d'une merveilleuse émission mythique. Peut-il l'obtenir aussi?

Gus serait volontiers d'accord, mais un problème se pose. Son programme était destiné à la version précédente du système d'exploitation VAX / VMS et du compilateur Pascal, et il produisait le texte vers une imprimante VERSAMOD-200 spécifique, qui pouvait être commutée en mode matrice, et vers un pilote d'impression spécifique, qui était soigneusement corrigé avec du code binaire, afin de ne pas gâcher les images matricielles. Gus doutait que le professeur ait suffisamment de connaissances techniques pour apprécier son explication, il a donc répondu poliment et sans entrer dans les détails techniques: désolé, mais le programme ne fonctionnera tout simplement pas sur une autre machine.

Une semaine plus tard, un patron est venu à son bureau, a mentionné son ami de l'Arizona et a gentiment demandé à Gus s'il pouvait trouver un moyen de lui envoyer le programme. Les tentatives de Gus pour expliquer l'impossibilité d'exécuter du code sur n'importe quel autre ordinateur dans le monde n'ont pas été entendues.

«Tu es un génie, Gus! Je suis sûr que vous allez trouver quelque chose. Merci d'avance! ”, - satisfait de son optimisme, le patron est parti.

Gus a commencé à penser comment il pouvait répondre, ou du moins à moitié, à la demande du patron. Enfin, il a eu une idée. Il est entré dans la ligne de commande de son ordinateur: DUMP /HEX "PRINTGREEK.EXE" /LIST=VERSAMOD-200 .

Bientôt, le vidage hexadécimal de son programme a pris un aspect papier tangible. Gus rassembla un imprimé avec un sourire et entra dans le bureau du patron. «La voici! Voici le programme, comme vous l'avez demandé. »

"Oh!" Le patron semblait surpris, mais compréhensif.

"S'ils ont des problèmes avec l'installation, alors laissez-les me contacter et je vous aiderai", a déclaré Gus.

“Génial! Merci beaucoup.

Un peu plus tard, un autre de nos estimés collègues de l'informatique en Arizona a été remis et chargé d'installer ce dépotoir imprimé sur papier. Il a dû vivre un moment plutôt choquant dans la WTF, mais il a évidemment réussi. Au moins trente ans se sont écoulés depuis lors, et Gus n'a jamais entendu de questions du professeur ou d'autres membres du personnel du collège. Peut-être que quelqu'un vient de conclure un accord avec Hadès ou a demandé à Kronos de le transférer à un moment où l'impression de caractères spéciaux n'était plus un travail de Sisyphe.

La quatrième histoire. Fax d'urgence

[ Original ]


Les télécopies sont dépassées au stade actuel de développement technologique. Ils ont été inventés plus d'une douzaine d'années plus tôt que le téléphone, mais malgré les énormes progrès dans les technologies de numérisation et de messagerie, ils restent la forme de communication standard.

Lors de la transmission de données, un bégaiement aléatoire ou du bruit sur la ligne peut ruiner le fax. La plupart des télécopieurs modernes ont des fonctions rudimentaires de gestion des erreurs qui alertent l'utilisateur qu'un fax doit être renvoyé.

Cette façon de travailler avec les bogues a si bien fonctionné que personne n'a pensé à la changer. Mais un analyste d'entreprise de l'entreprise pour laquelle Tom travaillait avait une idée brillante.

"Et si l'utilisateur n'est pas assis à côté du télécopieur en attendant un message?", Pensa-t-il. "Que faire si le télécopieur de l'expéditeur ne détecte pas le problème?" Nous devons lui faxer un rapport de bug! »

Bien que l'inquiétude de l'analyste soit fondée, Tom et son groupe ont objecté que l'envoi d'un message de télécopie échoué ne rendrait pas nécessairement la vie plus facile pour tout le monde.

Ils ont dit qu'à cause de cela, la machine de l'expéditeur sera occupée et il ne pourra pas renvoyer le fax d'origine.

«C'est normal», a expliqué l'analyste, «notre logiciel peut envoyer et recevoir des télécopies en parallèle. Cette idée est la meilleure qui soit venue après l'iPod ! Elle est absolument fiable ! "

Mais le débat était inutile: aux yeux de la direction, les analystes commerciaux ont toujours raison, et cette fonction a été mise en œuvre de toute urgence. Le programme s'appelait «FaxBack» et il remplissait la fonction correspondant au nom: il renvoyait la transmission ayant échoué à l'expéditeur (identifié par l'identifiant de l'appelant) peu de temps après l'occurrence de l'échec.

Pendant longtemps, tout a fonctionné sans le moindre problème, jusqu'à ce qu'un jour deux voitures de police avec sirènes allumées s'arrêtent près du bureau de Tom. La police a déclaré avoir répondu au 911, mais il n'y a pas eu d'urgence et personne n'a admis avoir composé le 911.

Bientôt, les policiers sont partis, mais tôt le matin du lendemain, deux autres voitures de police se sont rapidement rendues au bureau. Il n'y a plus eu d'urgence et personne n'a appelé le 911, alors ils ont calmement quitté le bureau.

Mais la troisième fois, lorsque la voiture est apparue dans l'après-midi du lendemain, les policiers ont refusé de partir jusqu'à ce que la source de «l'anxiété» soit trouvée. Le service de police était sûr que l'appel provenait du numéro de l'entreprise et a exigé de comprendre ce qui se passait.

Après avoir passé le reste de la journée et une partie de la soirée à suivre les appels téléphoniques au sein de l'entreprise, Tom a découvert que les appels au 911 provenaient du centre de données, et plus précisément de FaxBack.

Les télécopieurs, comme les téléphones de bureau, devaient composer le «9» pour accéder à la ligne extérieure. Par conséquent, lorsque FaxBack a répondu à un fax en échec de New Delhi, en composant le neuf, il a été suivi du code international de l'Inde - 11, et la «règle spéciale» du système de télécommunication a fonctionné.

Celui qui a installé le système de télécommunication a eu l'idée brillante de traiter le 911 comme un cas spécial, car l'appelant n'aurait peut-être pas pensé en cas d'urgence à composer un autre neuf en premier. Une règle spéciale s'appliquait également aux lignes du pool de télécopies, même si l'appelant n'était qu'un ordinateur.