GuiGui's Show

Soit un jeu vidéo dans lequel il faut cliquer à un même endroit pour collecter un exemplaire d'un item nécessaire à la progression dans le jeu. Ou se passer de l'item en attendant 7 heures entre quelques clics (la durée du jeu tend ainsi vers l'infini :D ). Ou acheter, avec de l'argent bien réel, plusieurs exemplaires de l'item afin d'avoir la paix. En réalité, trois clics sont nécessaires : clic pour collecter, clic pour confirmer la collecte, clic sur le message de confirmation "objet ajouté à votre inventaire".

Comment faire pour automatiser cela ? Comment faire pour cliquer automatiquement à notre place ? xdotool (paquet logiciel du même nom dans Debian).

Dans mon cas : xdotool click --repeat 130000 --delay 500 1. 130 000 clics avec le bouton gauche de la souris (le « 1 » en fin de ligne), espacés de 500 millisecondes.

Procédure : il suffit de préparer la commande dans un terminal, de ranger le terminal dans un coin de l'écran, de mettre le jeu au premier plan, de positionner le pointeur de la souris sur l'endroit où il faut cliquer, alt+tab, entrée, et hop, enjoy for fun and profit!

Certes, je n'ai pas pu utiliser mon ordinateur pendant plus d'une heure. Lire un bouquin, et hop. :)

On peut utiliser xdotool pour envoyer des touches de clavier, pour cibler une fenêtre (ou un groupe de fenêtres) en particulier avant envoi d'événements, pour déplacer la souris, etc. Ça peut servir d'enchaîner tout cela dans un script.

En réalité, tout le jeu vidéo en question est un clicker / jeu incrémental (progression uniquement en cliquant). Mais les endroits où cliquer changent à chaque scène. Peut-être y-a-t-il moyen de feinter avec xdotool en déplaçant la souris + cliquer un peu partout. Je n'ai pas creusé. Mais il y a des récompenses à choisir après une majorité des scènes, et ça, ça relève d'un choix stratégique qui ne s'automatise pas avec un outil aussi simple que xdotool.

Quand on utilise le type défini Exec dans un bout de code Puppet, il est nécessaire de préciser l'attribut « path » de ce type défini ou d'indiquer le chemin absolu de la commande à exécuter.

Je veux exécuter un script qui installe un logiciel dans un environnement virtuel Python car je ne sais pas le faire directement avec Puppet et que le temps m'est trop compté pour apprendre à mal le faire dans la précipitation. Ce script utilise la version 3.7 de Python qui est installée indépendamment via miniconda (le système d'exploitation Ubuntu fourni la version 3.8.5 qui ne convient pas).

Tous mes tests avec puppet agent -t fonctionne sur la machine de test. J'envoie en production. J'attends que CRON lance l'agent puppet. Ce dernier échoue à exécuter le script : « python3.7: command not found ». Au passage, je remercie set -e + trap ERR d'avoir empêché le reste du script de se dérouler (j'explique ici comment ça fonctionne). Je lance l'agent puppet à la main : l'exécution du script se déroule très bien. Hum.

Le PATH est différent entre un agent puppet exécuté à la mano (le PATH est alors celui de l'utilisateur root, qui est modifié via /etc/profile.d pour intégrer miniconda), un agent puppet exécuté par CRON (le PATH est alors celui de CRON, /usr/bin:/bin) et un agent puppet qui s'exécute automatiquement via un service (le PATH est alors /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin).

Bref, ce qui est vrai pour une ressource Exec au sein d'un code Puppet l'est tout autant pour un script exécuté par une ressource Exec au sein de Puppet : toujours préciser le PATH.

Au fait, pourquoi utilisons-nous CRON plutôt que le service pour exécuter l'agent puppet toutes les 30 minutes ? Parce qu'on utilise Puppet sur des stations de travail. Donc, les utilisateurs peuvent interrompre Puppet à tout moment… y compris durant l'installation de paquets logiciels, ce qui détraque dpkg. Sans compter que ces machines sont souvent toutes allumés en même temps, donc elles contactent toutes le serveur Puppet en même temps… ce qui pose de problème de charge. Notre script lancé par CRON exécute un dpkg --configure -a et ajoute une temporisation environ aléatoire avant d'exécuter l'agent Puppet.

Il y a quelques années, quand le sujet était à la mode, on t'expliquait que l'infrastructure as code (lolilol, la promesse excessive), c'est le bien car le code documente ton infrastructure, ce que montre le code est la réalité, il suffit de le lire pour comprendre ce qui est en production, blablabla.

Contre-exemple : « When specifying numeric permissions for directories, Puppet sets the search permission wherever the read permission is set. » (source : documentation officielle).

Il y a donc une prise de décision indépendante de ma volonté entre mon code et la réalité. On peut débattre sur l'utilité d'un mode 644 sur un dossier. On peut aussi constater l'écart entre la promesse "le code décrit la réalité" et la réalité. J'ai peiné à comprendre pourquoi mon mode ne s'appliquait pas lors d'un puppet agent -t…

Avec les nouvelles mesures sanitaires, une partie du service informatique de mon taff est sommé d'assurer le bon fonctionnement de nos systèmes internes de visioconférence avec un nombre élevé et inhabituel d'utilisateurs. Notre directeur souhaite des indicateurs afin de montrer l'(in)utilité du renforcement de la capacité de nos systèmes. Il souhaite partager ces indicateurs sur une page web.

Je ne vais pas recracher mon topo sur l'absurdité de la société du tout-chiffré qui complète une bonne introduction au sujet par DataGueule.

J'ai un Bac Économique et Social, donc, formation oblige (je me souviens des exercices consistant à tordre les chiffres afin de leur faire dire l'inverse), je me méfie des nombres. Ils ont rien d'objectif.

• Pourquoi mesurer telle grandeur et pas telle autre ? Quels préjugés se cachent derrière un nombre ? Exemple : l'état 4001, l'indicateur phare de la délinquance ne mesure pas celle des cols blancs…
  
  
• Comment un nombre a-t-il été calculé ? Selon quelle méthodologie ? Exemples : La police marseillaise bidouillait les statistiques sans le savoir ! ; Le Canard enchaîné du 7 octobre 2020 relate que les chiffres français officiels autour du Covid ne valent pas mieux : le 22 septembre, le nombre de patients hospitalisés dans un hosto francilien chute de quasiment 1 000 car l'hosto avait oublié de déclarer les sorties durant des semaines. Quand, le 3 octobre, Santé Publique France annonce quasiment 17 000 nouveaux cas, il s'agit d'un rattrapage des jours voire semaines précédentes dû à la surcharge des labos…
  
  
• Ce nombre est-il le plus pertinent pour mesurer l'objet du débat ? Quand tu calcules le nombre idéal de rapports sexuels par mois ou du moins celui qui permettrait d'optimiser la santé (c'était un sujet d'actualité durant le confinement et suite à la publication d'une énième étude en 2019), tu ne mets pas en adéquation une question et une réponse pertinente ;
  
  
• Tout est-il mesurable ? Sans parler de la vie, l'amour, etc., les externalités positives sont, par définition, quelque chose de difficile à chiffrer. Quid des pratiques illégales ou immorales ou s'en rattachant ? Très peu de chiffres seront disponibles et souvent de source aisément contestable type sondage d'opinion ;
  
  
• Comment ce nombre est-il présenté ? Je pense aux tromperies des visualisations graphiques (échelle, proportion, ne commence pas à zéro, etc.). Je pense aussi aux journaux qui titrent sur la hausse du salaire moyen en France… alors que la médiane ne change pas, ce qui illustre l'aggravation du fossé pauvres / riches. Je rappelle que quand Bill Gates entre dans un bar, tous les gens à l'intérieur sont en moyenne milliardaires…

De même, le caractère évident d'un nombre est contestable. Exemple : je suis incapable de comprendre des indicateurs financiers genre telle marge est-elle correcte pour telle société commerciale exerçant dans tel secteur et ayant tel modèle d'affaires ? Aucune idée. Un graphe illustrant la masse salariale ou les effectifs par services de mon employeur me parlerait aussi peu : est-ce trop ? Pas assez ? Aucune idée. En revanche, j'ai un avis sur l'effectif de mon service, sur nos indicateurs techniques d'informaticiens, etc. Derrière un nombre, il doit y avoir un public à même de l'expliciter et un autre à même de le comprendre.

Dire si notre service de VoD sature, par exemple, c'est loin d'être évident : charge CPU ? Un nombre élevé de connexions peut faire tomber un serveur qui se touche. Nombre de fichiers ouverts ? Les connexions peuvent être mises en attente par le frontal pendant que l'applicatif digère. Temps de réponse de l'applicatif ? Nombre de requêtes / seconde ? Sur l'applicatif Django ou sur les fichiers statiques ? Ça ne mesure pas la même chose. Faut-il prendre en compte le chargement de la charte graphique (CSS, JS, images, etc.) ? Nombre d'adresses IP uniques / seconde ? Quid des NAPT et des reverse proxies ? Quid des usages qui chargent un serveur même avec peu de connexions simultanées ? Avec ces questions, on n'a toujours pas d'indicateur ultime sur l'utilisation réelle de notre service, et il faudra des compétences pour interpréter ceux sus-mentionnés.

Je pense qu'un nombre est utile pour trancher un débat et/ou asseoir une crédibilité quand il est échangé posément au sein d'une communauté humaine aux intérêts partagés dont chaque membre dispose des compétences pour le comprendre. Ça fait beaucoup de conditions.

Autrement dit, il est inutile dans une communauté hétérogène ou entre deux communautés aux intérêts divergents. Dans ce cas, un contradicteur contestera le chiffre, le questionnera, le déconstruira, lui opposera d'autres chiffres censés mieux mesurer l'objet du débat, chiffres qu'il enrobera dans un imaginaire, etc. Il suffit de lire les proses des gauchistes et des droiteux pour s'en rendre compte : à chacun ses chiffres sur les systèmes de redistribution et leurs apports, la pauvreté, la hausse (ou non) des inégalités, l'apport bénéfique (ou non) de ces inégalités, le calcul de la richesse d'un territoire, etc. Le but étant de remporter une bataille d'opinion afin de se faire élire, il n'y a pas d'honnêteté, donc les chiffres sont vains car bidons.

De même, un chiffre est inutile face à un supérieur hiérarchique / un élu, car le chiffre ne remplace pas une décision : si un chef veut envoyer des gens dans le mur, il enverra des gens dans le mur. Dans le cas qui m'intéresse, si jamais le redimensionnement en cours de notre installation interne de visioconférence se révèle être inutile car le nombre de conférences est largement en deçà, notre directeur pourra toujours montrer les chiffres (nombre de salles simultanées) et les graphes, ça aura aucun effet. Son supérieur rétorquera qu'il fallait sur-dimensionner "au cas-où". Pour ce chef, la question n'est pas de savoir si c'est utile ou non (ce qui se mesure), mais de prévoir un risque afin de (légitimement) se couvrir / couvrir notre organisation suite à un ordre venu d'encore plus haut. Il n'y a pas d'indicateurs pour mesurer cela. Du coup, lors d'une prochaine """"crise"""", notre directeur n'aura pas plus de poids / crédibilité. Il ne pourra pas invoquer "la dernière fois, ta demande était démesurée / disproportionnée, voilà les chiffres qui illustrent cela, donc soyons plus raisonnables cette fois-ci", car la logique sera toujours de se couvrir / de faire au mieux pour notre organisation, et le mieux, ça ne sera mesure pas vraiment, c'est très subjectif.

Dans le même genre, les non-débats sur une sortie du nucléaire dégagent des chiffres sur la part du nucléaire versus charbon, sur la fluctuation des énergies renouvelables, sur la durée de vie moyenne d'une centrale, sur la rentabilité écolo moyenne d'un panneau solaire, etc., sans jamais dégager la question décisionnelle qui me semble être clé : ne faut-il pas réduire nos besoins en énergie ? Question à laquelle aucun chiffre peut répondre.

En annexe, un point technique est intéressant. Notre supervision graphe nos métriques techniques avec RRDtool. Au-delà d'une période de temps définie (plusieurs, en vrai), il lisse les valeurs en gardant la moyenne sur un intervalle passé. Cela est perçu comme étant un problème.

D'une part, j'estime que nos graphes révèlent une tendance et que c'est elle qu'il faut prendre en compte, comme les chiffres Covid sus-cités dont la valeur d'un jour ne vaut rien. D'autre part, le lissage se compense par une sur-capacité (exemple : prévoir +20-30 %). Avec le graphe du nombre de requêtes/seconde sur nos bases de données, j'ai su dimensionner nos derniers serveurs, semble-t-il. Je saurai faire pareil avec nos annuaires LDAP. Une sur-capacité raisonnable rend une infrastructure résiliente aux chocs d'utilisation imprévus pour un sur-coût environ nul (c'est l'une des leçons de l'effet du confinement sur les réseaux informatiques, les Cassandre hurlant à leur saturation et appelant à la modération des usages ‒ sauf pour leur pomme ‒ se sont plantés).

Ensuite, dès que t'as une valeur que tu récupères une fois par tranche de cinq minutes pour ensuite produire une mesure par unité de temps (exemple : nombre de requêtes web par seconde), t'es déjà dans le faux statistique puisque tu considères qu'une valeur récupérée à un point du temps est vrai sur tout un intervalle de temps (de 5 minutes, en général). Le mieux est un compteur incrémental, comme le nombre total de bits émis/reçus sur un port d'un commutateur réseau depuis son démarrage (encore faut-il se souvenir de relever les compteurs 64 bits sinon ça produit des stats bidons) ou le nombre total de requêtes LDAP / MySQL depuis le démarrage du serveur. En cela, les trucs modernes comme Graphite, OpenTSDB, etc. ne font que stocker des points plus réguliers et les conservent plus souvent (et encore, il y a 5 ans, j'ai trouvé qu'OpenTSDB est poussif quand il doit appliquer une fonction sur un ensemble conséquent de points, d'où le choix de RRD de virer les points trop anciens n'est pas idiot). Il y a rien de magique. Je reconnais que les visualisations de Kibana sont plus dynamiques qu'un graphe RRD : en un clic, tu changes le format du graphe genre diagramme circulaire vers diagramme en barres, en un autre clic, ça prend tel intervalle de temps par défaut, en un autre clic, ça masque telles données.

On notera que RRDtool permet de choisir la fonction de consolidation (CF). Dans le cas présent, on pourrait conserver la valeur la plus élevée sur un intervalle. Cela permettrait d'illustrer le bon dimensionnement de notre système de visioconférence. Deux inconvénients : 1) on n'a toujours pas d'indicateur sur l'utilisation réelle / concrète (mais dans le cas présent, j'en vois pas trop l'intérêt…) ; 2) par le passé, j'ai passé une demi-journée à configurer notre supervision pour qu'elle crée des graphes RRD avec une CF différente… Sans succès.

Avec les nouvelles mesures sanitaires, une partie du service informatique de mon taff est sommé d'assurer le bon fonctionnement de nos systèmes internes de visioconférence avec un nombre élevé et inhabituel d'utilisateurs.

À la pause, un collègue me demande pourquoi nous n'achetons pas des licences Zoom comme le fait une organisation 10 fois plus grosse que nous. Au moins, aucun risque de décevoir (effet marque : "j'ai choisi une marque connue, c'pas ma faute si ça foire"). Au moins, pas de boulot de préparation de l'infrastructure à effectuer dans l'urgence. Au moins, on ne se ferait pas emmerder par la direction (je cite, je ne me prononce pas sur la véracité de l'affirmation).

Tout cela est vrai.

Oui, à chacun de ses besoins, l'organisation citée par mon collègue y fait correspondre une solution clé-en-main. Pas le temps, pas les effectifs, il faut raisonner sur une masse conséquente d'utilisateurs, etc.

Oui, l'externalisation est toujours la facilité. En apparence. Il faut formaliser le besoin. Il faut démarcher. Il faut comparer. Il faut contractualiser. Il faut suivre la prestation. Il faut l'intégrer à ton système d'information (aujourd'hui, on dit pudiquement « développer des connecteurs »). Il faut ouvrir des demandes d'assistance (il y a toujours au moins un truc qui foire, toujours). Relancer. Suivre. Effectuer les tests demandés. Quand ça tourne mal, l'engagement d'un contentieux est souvent peine perdu, donc l'organisation retrouve jamais ses billes. Tout cela représente une quantité de taff et de fric. Au final, des compétences sont centralisées chez peu d'acteurs (qui, du coup, se permettent toutes les mauvaises pratiques possible, joie des oligopoles), ça dévitalise les organisations de taille moyenne (donc ça centralise certains boulots dans peu de lieux géographiques, ce qui entraîne d'autres problèmes, de transport, de cadre de vie, de santé ‒ stress, pollution ‒, de coût de l'immobilier, etc.), tout ça pour ne pas être nécessairement plus rentable d'un point de vue strictement économique. Génie.

Mais, au fond du fond, il n'y a pas d'absolu, chacun voit midi à sa porte.

Au final, ce qui compte, c'est la vision que chacun a de son métier. Je n'ai pas envie d'être une personne qui passe des commandes à longueur de journée, qui ne comprend pas comment fonctionne réellement le service qu'il propose à ses utilisateurs, et qui, au moindre problème, se contente de faire une demande d'assistance au prestataire, de pondre un message d'information pour ses utilisateurs et d'attendre. Quelle vie bien triste, je trouve.

Le corollaire de ça, c'est que ça demande des gens compétents et passionnés, qu'il faut garder compétents et passionnés (environnement de taff, ambiance, thune, etc.). Ça demande du temps (donc la réaction dans l'urgence, on repassera). Ça exige de faire confiance. Du côté des grouillots de base, ça demande de se sortir les doigts (ou de convaincre que ça sert à rien d'hurler à la crise au moindre pet de mouche, parce qu'entre le terrorisme, le covid, les casseurs, etc., nous sommes très souvent en guerre si l'on écoute les trouducs d'en haut ou les voisins, collègues, etc., mais, ça, c'est peine perdue). Ça demande de prendre des risques. Ça demande d'avoir une estime de soi et de ses activités (je ne suis pas qu'un pion dans un taff sans intérêt, dans un système que je ne comprends pas). Ça demande de gérer la frustration (même en essayant de me maintenir à niveau, je galère sévèrement à appréhender et à faire évoluer le système d'information sur lequel j'interviens tous les jours). Il ne suffit pas de gueuler à la préservation de nos emplois, il faut agir (et pas qu'en mangeant des merguez sur le parking bloqué du lieu de taff ‒ c'est important, mais c'est trop tard et insuffisant ‒).

J'exige qu'on comprenne et respecte mon choix. Et ça, ce n'est pas gagné.

Ou : tar -cJf openjdk-jdk-1.8.0u265-x64.tar.xz openjdk-jdk-1.8.0u265-x64/. ^^ Mais, oui, les options de tar sont pénibles à retenir. :-

ToiTuyau (Youtube) m'a recommandé cette musique. Bonne pioche : ça me rappelle mon enfance. J'ai écouté en boucle cette chanson enregistrée sur une cassette audio bien après la fin de la série. :) En revanche, je me souvenais d'une chanson joyeuse alors qu'on est plutôt sur une chanson triste (personne qui ne trouve pas l'amour, difficulté de la vie de célébrité en dehors des plateaux) qui fait écho au Chanteur abandonné de Hallyday.

Fort logiquement, ToiTuyau (as-tu déjà essayé de traduire littéralement Hotmail en français ? ;) ) m'a aussi proposé Dans les yeux d'une fille. C'est niais, mais ça fait son effet. ^^'

J'ai regardé quelques épisodes de la série TV Hélène et les Garçons et, vache, ce que ça a mal vieilli. :O Ou alors ai-je mal vieilli ? Récemment, j'ai regardé des dessins animés que je regardais, et ça m'a fait le même effet… Suis-je un jeune-vieux con ?

L'homme, une merde.

Gros +1.
Parallèle sympa, mais pas forcément réaliste (j'attends encore d'être convaincu qu'une femme est moins conne qu'un homme en terme de destruction de la planète).

La petite commande Linux du jour : oneko !

Quand on la lance, y'a un petit chat qui apparaît sur l'écran et poursuit le curseur de la souris partout. Et quand il le rattrape, il se roule en boule et s'endort.

Indispensable ! 😂

Y'a aussi un mode pour avoir un chien, ou divers perso de manga, poursuivre des fenêtres, ....

\o/
Ça me rappelle sl, le train ASCII dans un terminal, pratique pour apprendre à ne plus taper trop vite ls. :)

Via https://mastodon.gougere.fr/@bortzmeyer

Chers collègues de la majorité, […] en réduisant votre fonction à une appartenance suprême pour en faire un petit instrument de guerre parlementaire, vous croyez marcher vers votre salut, mais vous courez vers votre servitude. […] Votre refus de faire émerger la vérité fait de vous de simples digéreurs, intestins silencieux de la bouche élyséenne.

Comment dénoncer la mise au pas constante du pouvoir législatif par l'exécutif. :D (non, je ne suis pas naïf, Chassaigne a aussi fait le jeu de la guéguerre convenue lors de l'affaire Benalla, mais ça enlève rien à son coup de gueule, même si il aurait mieux rendu sur d'autres sujets)