Le SPARC4 du professeur était lent à cause de xroach entassé sous xterm

• Un membre du support IT du département d’informatique s’est rendu au bureau d’un professeur qui se plaignait de baisse de performances sur son Sparc4, et y a découvert xroach caché derrière une fenêtre
• En réduisant une fenêtre, le bas de l’écran est apparu comme un rectangle noir, à l’intérieur duquel des cafards se déplaçaient très lentement
• Le mouvement était d’environ 0,5 fps, et il y avait tellement de cafards xroach sous xterm qu’ils semblaient former une seule masse noire
• Le cœur du problème n’était pas tant le matériel lui-même que le fait que xroach continuait à s’afficher dans une zone que l’utilisateur ne voyait pas
• Dans les anciens environnements de bureau X11, même des programmes potaches peuvent ressembler à de vrais problèmes de performances, d’où l’importance de vérifier les fenêtres cachées et l’état en arrière-plan

---

Symptômes constatés dans le bureau du professeur

• Paco Hope raconte qu’à l’époque où il travaillait au support IT du département d’informatique, un professeur s’est plaint que son Sparc4 était lent, ce qui l’a fait appeler dans son bureau
• La première chose qu’il a faite a été de réduire une fenêtre, et un rectangle noir inattendu est alors apparu en dessous
  • Dans cette zone noire, les cafards de xroach bougeaient légèrement
  • Le mouvement était si lent qu’il semblait tourner à environ 0,5 fps

xroach entassé sous xterm

• Il y avait tellement de xroach sous xterm qu’on ne distinguait plus des cafards individuels, mais presque un rectangle noir uniforme
• Le professeur n’avait pas vu l’état de la zone située dessous avant de réduire la fenêtre, et c’est en vérifiant cet écran caché qu’ils ont trouvé la piste expliquant la baisse de performances

Bref souvenir et réactions

• Cette anecdote est un court souvenir publié par Paco Hope sur Mastodon le 25 juillet 2023
• La publication affichait 202 boosts et 389 favorites, suscitant l’adhésion d’utilisateurs nostalgiques des anciens environnements de bureau et des programmes potaches

[GN⁺]

Avis sur Hacker News

• Quand je faisais du support technique dans un hôpital local, une infirmière a appelé parce qu’une « fenêtre qui ressemblait à une prévision météo » était apparue à l’écran, et que la souris passait dessous, donc elle ne pouvait pas la fermer.
  Intrigué, je lui ai demandé de ne pas toucher à l’ordinateur et je suis arrivé après environ 10 minutes de marche ; elle m’a dit : « Ça s’est fermé tout seul il y a une minute. C’est resté ouvert 30 minutes. »
  En regardant la disposition du bureau et sa description de la fenêtre, j’ai appuyé sur les boutons du moniteur : c’était le menu OSD du moniteur, déclenché par erreur par le coin du clavier, et il affichait la luminosité à 100 % avec une icône de soleil. Pas étonnant que la souris passe dessous.
  J’ai repris mes 10 minutes de marche dans l’autre sens et j’ai attendu l’appel suivant.

  • Pour avoir fait du support technique en milieu hospitalier, je ne suis pas sûr que l’IT y apporte autant de valeur qu’il aime à le croire.
    Les infirmières sont occupées à sauver des vies et à s’occuper de personnes qui vivent la pire journée de leur vie, et en plus de ça elles doivent gérer des postes de travail mal implémentés et mal maintenus. Quand elles demandent de l’aide, il arrive que les gens qui ont créé le problème viennent les prendre de haut.
    Les infirmières ne sont ni stupides ni paresseuses : ce sont des personnes qui ont des choses plus importantes à faire que de perdre du temps sur des petits problèmes IT.
    Le matériel vraiment important pour les soins était généralement géré par des spécialistes dédiés, et les ordinateurs des appareils d’IRM pouvaient très bien ne pas être rattachés à Active Directory, ni même être sur le réseau. Le problème n’était pas transmis à la personne qui répare les imprimantes, mais à GE.
  • J’ai eu un jour un appel au support : « L’écran n’arrête pas de se déformer, je crois qu’il a un virus. » C’était à l’époque où le film The Net était encore au cinéma.
    En arrivant, j’ai trouvé un gros boom box avec deux grands haut-parleurs posé sur le moniteur CRT ; une fois retiré, le problème a disparu comme par magie.
  • On dirait une version plus évoluée de l’histoire du « porte-gobelet 4x cassé » des années 90.
    En fait, l’infirmière avait même décrit assez précisément ce qui se passait.

• En 1989, j’étais seul à gérer l’IT dans un endroit où d’anciens économistes universitaires faisaient de la modélisation économétrique sur un Digital VAX 11/750.
  Ce mini-ordinateur faisait tourner VMS, un système d’exploitation multi-utilisateur, et tous les utilisateurs avaient les droits administrateur. Chacun pensait que pousser la priorité de ses processus au maximum ferait tourner son modèle plus vite, mais cela perturbait les processus temps réel nécessaires au fonctionnement de la machine et produisait en fait l’effet inverse.
  Après avoir trouvé la cause, retiré ces droits puis redémarré le système, tout est revenu à la normale, et on m’a remercié d’avoir rendu le système plus rapide.

  • Il y avait un système administré par des étudiants, et j’étais l’un d’eux. On se faisait des blagues entre nous ; sur une station de travail DEC qui manquait de mémoire, l’un faisait tourner emacs.
    Quelqu’un d’autre a écrit un programme qui se forkait lui-même 1000 fois, baissait sa valeur nice à 19, faisait sleep(0) puis se terminait. Dès qu’il obtenait le moindre temps CPU, il finissait immédiatement, mais tant qu’emacs tournait, il n’en avait pas l’occasion. Pendant ce temps, la charge affichée par xload devenait un rectangle tout noir.
    La personne qui utilisait emacs a exécuté en root ps -ef | grep procname | xargs kill, mais traiter les kill demandait du temps CPU, ce qui prenait plus longtemps que sleep(0), et ça n’a pas eu grand effet.
    Pour la deuxième blague, le processus a été nommé ema, ce qui a aussi tué toutes les instances d’emacs.
    La troisième fois, le processus a été nommé et, et par hasard cela a aussi correspondu à /etc/initd, ce qui a brusquement redémarré la machine.
  • En 1993, le cours d’informatique de première année se faisait en Scheme, et les devoirs devaient être développés et testés sur une machine Digital partagée sous Ultrix.
    L’interpréteur Scheme était lent à démarrer, surtout quand plus de 20 personnes étaient connectées. Le chargé de TD nous avait montré comment suspendre l’interpréteur avec ctrl-z, éditer avec vi, puis revenir avec fg.
    Le problème, c’est que non pas la moitié, mais les deux tiers de la classe oubliaient fg et lançaient une nouvelle instance de Scheme après avoir édité. Je me souviens que, le soir de rendu dans la salle des terminaux, le système rampait littéralement.
    Par la suite, j’ai appris à repérer les camarades qui faisaient tourner deux instances de Scheme ou plus et à leur rappeler fg. Quant aux « solutions » au problème des 8 reines avec récursion infinie, elles n’aidaient pas du tout la charge. La vraie leçon, c’était de ne pas se connecter le soir de rendu des devoirs de CS 401.
  • En 1991, à l’université, j’ai utilisé Internet pour la première fois via ce genre de machine. J’avais trouvé une chouette vulnérabilité qui permettait de diffuser anonymement un message à tout le monde, et j’ai surpris pas mal de gens.
    Les terminaux partagés étaient tous dans la même pièce, donc c’était amusant de voir en temps réel l’effet de ce que je faisais.
  • C’est un bon exemple du principe économique de la tragédie des biens communs : https://en.m.wikipedia.org/wiki/Tragedy_of_the_commons
  • Ça me rappelle une histoire racontée par quelqu’un avec qui j’ai travaillé.
    Dans un contexte où les gens faisaient la queue, quelqu’un lui a demandé s’il pouvait s’occuper de son problème avant celui des autres. Autrement dit, il demandait à passer tout devant.
    Il a répondu : « Bien sûr ! » et, comme l’autre était surpris, il a ajouté : « Mais vous savez que je ferai pareil pour toutes les autres personnes qui me feront la même demande, n’est-ce pas ? »
    Finalement, la personne a décidé d’attendre à sa place.

• Ça me rappelle le bon vieux temps de mes années d’étudiant
  Dans mon cas, c’était au début des années 2000, et les ordinateurs des salles de TP de l’université n’étaient pas très puissants, donc les gens travaillaient souvent dans la console Linux plutôt que de lancer une lourde session X
  Vers 2001, en lisant la page de manuel console_ioctl(4), j’ai découvert qu’elle regorgeait de possibilités de farces. J’ai écrit de petits programmes qui manipulaient la police de la console pour retourner tous les caractères, inverser majuscules et minuscules, faire clignoter les motifs des LED du clavier, ou changer la palette pour faire un fondu au noir de l’écran puis le restaurer
  J’y ai ajouté un composant serveur, que je laissais tourner dans un terminal d’apparence normale, puis j’attendais qu’une victime arrive et j’activais les effets à distance depuis une autre machine de la même salle pour observer sa réaction. Heureusement, j’ai vite compris que coder était en soi plus amusant que de regarder les gens paniquer, et j’ai arrêté la seconde partie
  Une autre blague consistait à taper moi-même, à l’invite de connexion de getty, ce qui aurait ressemblé à une connexion root réussie. J’incluais même le motd, imitais les retours à la ligne avec des tabulations et des espaces sans jamais appuyer sur RET, et terminais par [root@mailhost root]#
  Certains, par curiosité, tapaient whoami puis restaient perplexes devant l’apparition d’une invite de mot de passe ; d’autres n’osaient rien toucher, reculaient effrayés et envoyaient un mail à l’administrateur système depuis un autre terminal

  • J’aurais aimé avoir un système Linux. On faisait des choses similaires sur des réseaux Windows
    Tant qu’un utilisateur était connecté, on pouvait, via le planificateur de tâches, exécuter pratiquement n’importe quel programme avec ses droits ; combiné à Active Directory, on pouvait aussi connaître les informations utilisateur. On savait qui était où, puis on ouvrait iexplorer sur un site donné, ou on affichait un document Word inoffensif. Le cas le plus malveillant était un script batch de déconnexion automatique
    Plus tard, les gens ont compris comment ça marchait et ont essayé de reproduire l’exécution distante, mais ils lançaient les programmes avec leurs propres droits plutôt qu’avec ceux de l’utilisateur cible, si bien que, quand l’admin IT arrivait, les traces indiquant qui l’avait exécuté étaient beaucoup trop évidentes
    J’ai arrêté les blagues, et je suis finalement passé par l’IT avant de devenir ingénieur logiciel. Je me demande parfois ce qui se serait passé si j’avais été sanctionné à l’époque
  • Ça a vraiment l’air amusant. C’est le genre de chose qui fait réaliser que coder est incroyablement amusant et a un vrai impact quand on agit directement sur le résultat

• Sur un mainframe IBM 370, il y avait plus de 80 programmeurs, et VM/370 créait une machine virtuelle pour chacun d’eux. J’étais l’un des deux programmeurs système disposant de droits de « superutilisateur »
  À l’intérieur d’une machine virtuelle, on lançait généralement CMS, mais on pouvait exécuter autre chose, et certaines machines faisaient tourner MVS
  Pour envoyer une commande à la machine virtuelle elle-même, il fallait préfixer la commande par un caractère spécial, # par défaut. Par exemple, #cp ... était une commande destinée à la machine virtuelle, et ce préfixe magique pouvait être remplacé par le caractère de son choix
  Un jour, par ennui, je me suis demandé s’il serait possible de faire tourner VM à nouveau à l’intérieur d’une machine virtuelle. J’ai démarré VM au « deuxième niveau », changé le préfixe en !, et j’ai pu y créer de nouvelles machines virtuelles
  Puis j’ai redémarré VM dans une machine virtuelle de « troisième niveau » et changé le préfixe en @. Au final, je suis allé jusqu’à 8 niveaux d’imbrication, confirmant que VM pouvait faire tourner VM, qui pouvait lui-même faire tourner VM, et ainsi de suite
  Quand j’ai voulu arrêter et quitter les niveaux imbriqués, j’ai tapé machinalement #cp shutdown, et c’est le vrai VM de la vraie machine qui s’est arrêté. Paniqué, j’ai couru jusqu’à la salle machines pour appuyer sur le bouton de démarrage de la console
  Évidemment, les journaux système en avaient gardé la trace, et l’autre programmeur système est venu dans mon bureau pour me dire : « ne refais jamais ça ». C’était une époque amusante

  • J’ai créé ceci pour abuser de l’exécution imbriquée de qemu de la même manière : http://git.annexia.org/?p=supernested.git;a=summary
  • Je ne comprends pas. Je pensais que # était le préfixe de la VM de niveau 1, pas celui du système d’exploitation de niveau 0, c’est-à-dire l’hôte
    S’il envoyait des commandes au niveau 0 avec #, je me demande quel était le préfixe du niveau 1
  • Ça nous ressemble, quand on travaillait sur Solaris en étant habitués à Linux. Un processus s’était bloqué, et comme on avait la flemme de chercher son PID, on a simplement lancé killall procname. La machine est morte instantanément
    Ce n’est qu’après l’arrivée de l’administrateur système qu’on a appris que, sur Solaris, killall faisait autre chose, et qu’on nous a dit de ne plus jamais l’utiliser

• Dans les universités des années 80, quand j’étais étudiant, j’avais accès à un VAX 11/750 — plus exactement à un clone Systime 8750 — pour faire mes devoirs de programmation.
  Les terminaux étudiants occupaient la moitié d’une grande salle, l’autre moitié étant utilisée par le personnel informatique de l’université. Quand il n’y avait plus de terminal libre côté administrateurs IT, un ou deux employés venaient parfois utiliser les terminaux étudiants juste de l’autre côté de la cloison.
  Un jour, en attendant la compilation d’un projet COBOL et en m’ennuyant ferme, je me suis demandé si je pourrais récupérer le nom d’utilisateur et le mot de passe de l’administrateur système. J’ai écrit un script qui imitait parfaitement, en ligne de commande, l’invite de connexion, jusqu’au bip et au message.
  Le script effaçait l’écran, attendait la saisie du nom d’utilisateur et du mot de passe, puis, une fois ceux-ci entrés, me les envoyait par mail, affichait une erreur de nom d’utilisateur/mot de passe, puis déconnectait pour passer la main au vrai processus de connexion.
  Après l’avoir testé sur quelques camarades qui n’y ont vu que du feu et fait quelques blagues anonymes, j’ai décidé de tenter le coup pour de vrai sur les administrateurs système. Je me suis connecté sur les deux terminaux qu’utilisaient habituellement les employés IT et j’y ai lancé le script ; quelques heures plus tard, à ma grande surprise et avec une légère inquiétude, j’avais obtenu le mot de passe de connexion SYSTEM.
  Pendant environ un mois, j’ai eu le contrôle complet de cette machine, et je relançais parfois le script quand le mot de passe SYSTEM changeait. Je n’en ai parlé à personne et, le dernier jour avant d’obtenir mon diplôme, je me suis connecté par précaution pour supprimer le script. À l’époque, au Royaume-Uni, les lois sur l’accès non autorisé aux ordinateurs étaient en train de se durcir.
  J’ai passé beaucoup de temps à explorer et apprendre VMS avec l’énorme documentation de cette machine, mais personne ne s’en est jamais rendu compte.

  • C’est à cause de ce genre de spoofing de connexion que, depuis Windows NT, l’utilisateur devait d’abord appuyer sur Ctrl+Alt+Del pour entrer dans un contexte sécurisé.
    https://en.wikipedia.org/wiki/Control-Alt-Delete
  • C’est aussi une sorte de rite de passage. J’ai fait la même chose sur le VAX de mon école, mais le lendemain j’ai remis tous les mots de passe collectés à l’administrateur système et je lui ai tout avoué. Il y avait même quelques comptes avec les privilèges SYSTEM.
    Ils m’ont donné mon premier emploi :-) J’avais aussi pris soin d’accorder à l’avance les droits nécessaires à un ou deux comptes peu connus, afin de pouvoir les récupérer si les privilèges SYSTEM étaient retirés au compte « officiel ».
    C’était une époque amusante, et assez naïve aussi. Je n’ai pas semé le chaos avec ces privilèges.
  • Excellent. Ça me rappelle le programme BASIC que j’avais écrit sur ma Ti-83 pour imiter la procédure de réinitialisation mémoire que le prof lançait lui-même en circulant dans la salle pendant les contrôles d’algèbre.
    Aujourd’hui, ce n’est pas très surprenant que je gagne ma vie en programmant.
  • Je trouve amusant de voir que remplacer le programme de connexion utilisateur semble avoir été assez courant chez les futurs hackers.
    Le mien était en Visual Basic 5 pour les Windows de l’école, probablement sur un réseau Novell. Il était très facile de modifier win.ini pour qu’il s’exécute avant le vrai écran de connexion.
    Il enregistrait le nom d’utilisateur et le mot de passe sur un lecteur réseau partagé ou dans un fichier local, affichait « mot de passe incorrect », puis quittait vers la vraie invite de connexion.
    Le problème est finalement venu d’un « ami » qui a utilisé la même technique pour copier les fichiers de comptes réseau des gens vers son propre compte. Je suppose que le système a alerté l’administrateur réseau quand il a rempli tout son quota. En jetant un coup d’œil, on a découvert qu’il avait même copié les fichiers de thèse d’un professeur, ce qui était vraiment un énorme tabou.
    C’est grâce à cet incident que j’ai finalement décroché mon premier emploi lié à l’informatique, comme technicien support junior / administrateur réseau.
  • Je me souviens qu’un étudiant avait fait ce genre de chose à Carnegie Mellon vers 1985 et s’était attiré de gros ennuis.

• En 1988, au lycée, avec un ami, nous avons découvert dans NetWare, déployé sur les 30 IBM PS/2 Model 30-286 de la nouvelle salle informatique, une faille permettant d’insérer un programme dans la séquence de démarrage réseau autoexec.
  Avant cela, j’avais bricolé les registres VGA, tout nouveaux à l’époque, et trouvé comment passer du mode texte 80x25 au mode graphique 320x200 en 256 couleurs sans scintillement ni artefacts, parce que les deux modes avaient un taux de rafraîchissement de 70 Hz.
  Mon ami avait écrit un TSR qui préchargeait une image numérique de visage de clown dans A000:0000, puis, au bout d’environ 4 minutes, affichait ce visage de clown pendant quelques frames avant de revenir instantanément à l’écran sur lequel travaillait l’utilisateur.
  Nous nous sommes fait prendre parce que, depuis le fond de la salle, nous n’arrivions pas à nous empêcher de rire en voyant les élèves afficher des airs confus et effrayés. Le meilleur moment a été quand un élève a appelé l’enseignant et l’a fait regarder l’écran pendant plus de trois minutes : le visage de clown a surgi pile au moment où l’enseignant se retournait.
  Mon ami s’appelait Brian, et c’était l’une des personnes les plus intelligentes que j’aie connues. Dix ans plus tard, nous avons créé mobygames.com.

  • Ma farce à moi consistait à faire parfois entendre un chant d’oiseau. En général toutes les quelques minutes, et je mélangeais plusieurs nombres aléatoires pour que le son soit différent à chaque fois.
    La fréquence du son variait en permanence, si bien qu’il n’y avait jamais une note fixe, même un instant. À l’époque, les haut-parleurs ne servaient généralement qu’à faire des bips, et je laissais ça tourner sur des machines inutilisées.

• Au début des années 90, j’étais étudiant de première année en informatique dans une université d’État. La salle informatique était remplie de Sun SPARCstation IPC sous SunOS, et il existait un système d’e-mail rudimentaire que les gens du département utilisaient pour communiquer.
  Les plus férus de technologie exploraient déjà Usenet, mais pour la plupart, l’e-mail constituait tout l’univers numérique.
  Un jour, avec des amis, on a décidé de faire une blague, inspirés par la célèbre commande fortune, qui affiche des maximes aléatoires. On a écrit un petit script shell qui choisissait une ligne au hasard dans un fichier texte rempli de phrases drôles et absurdes que nous avions rédigées, puis l’envoyait par mail à un utilisateur aléatoire du département d’informatique. On l’a enregistré comme tâche cron pour qu’il en envoie une toutes les heures.
  Au début, c’était une blague harmless. Les gens trouvaient les messages amusants et les partageaient au labo. L’origine des messages est devenue un sujet de discussion dans le département, mais personne ne savait d’où ils venaient, et nous prenions plaisir à voir camarades et professeurs spéculer sur l’expéditeur mystérieux.
  Puis l’affaire a pris de l’ampleur quand le doyen a reçu un message particulièrement absurde : « Pourquoi les informaticiens confondent-ils Noël et Halloween ? Parce que Oct 31 == Dec 25 ». Il n’a pas compris la blague et l’a prise pour un message codé ou une menace potentielle.
  L’équipe IT du campus a été chargée d’enquêter, et il s’en est suivi une semaine d’agitation pour tenter de remonter à la source des e-mails. Avec mes amis, nous regardions cela avec inquiétude, craignant d’être découverts et renvoyés.
  Finalement, après plusieurs nuits blanches, nous avons décidé de nous dénoncer. Nous sommes allés voir le doyen et avons avoué ; après un long silence, il a commencé à rire. Il s’est avéré qu’un des professeurs d’informatique lui avait expliqué la blague, et qu’il attendait de voir quand nous nous manifesterions.
  Il a pris la blague avec indulgence et a considéré notre initiative comme créative, mais il nous a aussi mis en garde contre les conséquences involontaires de ce genre de plaisanteries.
  Avec le recul, c’était une blague amusante et mémorable, qui nous a donné une précieuse leçon sur l’éthique dans l’usage de la technologie. C’est une histoire que je raconte souvent aujourd’hui à mes étudiants en informatique quand je leur enseigne l’importance d’un comportement éthique dans le monde numérique.

• Il m’est arrivé de devoir diagnostiquer le PC du directeur du département de maths, qui se comportait bizarrement.
  Il s’est avéré qu’il avait laissé Prime95 utiliser tous les cycles disponibles d’un cœur d’un Core 2 Duo pendant 10 ans, et que la machine ne démarrait qu’une fois refroidie à température ambiante.

  • Il m’a fallu beaucoup trop de temps pour me rappeler que Prime95 sert à autre chose qu’aux stress tests.
  • Des cycles inutilisés sont des cycles gaspillés /s

• Une blague qu’un ami a faite à un autre pendant mes années de master.
  Pendant que la victime avait laissé son terminal ouvert en étant connectée, l’auteur de la blague a ajouté echo sleep -1 >> .login à son fichier .login.
  Quelques jours plus tard, après l’ajout de plus de 20 instructions sleep, il est devenu évident que quelque chose n’allait vraiment pas dans la connexion de cet étudiant. Chaque jour, le délai entre le login initial et l’obtention d’un terminal actif s’allongeait, ce qui l’agaçait de plus en plus, jusqu’à ce que la blague soit finalement découverte quand c’est devenu insupportable.

  • Je suis venu ici pour me remémorer la même blague :)
    Au bout d’un moment, on a jugé qu’ajouter 1 seconde à chaque connexion était trop subtil.
    echo "echo sleep 1 >> ~/.login" >> ~/.login

• Ce qui est amusant avec pas mal de vieilles histoires, c’est qu’elles finissent par se résumer à : « ce n’était pas malveillant, c’était juste pour rire, mais je ne pensais pas que ça se multiplierait autant ni que ça consommerait autant de ressources ».
  Le Morris worm est un peu pareil. Même si cela se discute, on peut considérer qu’il avait été conçu comme un malware, et d’après ce qui se raconte du moins, l’intention n’était pas que cela devienne aussi grave.