Sommaire
Voilà, Y'a 2 jours, je me faisais un poil chié, et j'ai regardé un vieux projet FAIM et mis un commentaire qui m'a amené après moultes circonvolutions à me dire que je tenais du code qui marchait, qui prouvait absolument pas ce que j'avais démarré mais un rêve de gamin en informatique de faire un control center à la hacker (qui permet de piloter en grappe des instances piratées autonomes) et de là je suis paumé sur la suite à donner à cette réalisation.
Plusieurs options rationnelles s'offrent à moi :
- faire projet qui dépend des deux autres ;
- FORKER à la porcasse en incluant les 2 anciens projets qui sont que tchi ;
- m'intégrer à l'existant dans un des deux projets ;
- fusionner les projets …
Bref, c'est un casse tête qui mérite un journal -un vrai- où l'on raconte comment c'est arrivé.
Le premier chapitre : FAIM !
FAIM est un vieux projet, moitié sérieux, moitié pas sérieux, de golfer en bash pour l'art du troll envers mes collègues qui ne juraient uniquement QUE pas python, de m'amuser un peu à dire simplement ce python faisait difficillement : lancer des process, et rediriger les entrées/sorties standard.
Ne me faîtes pas dire que j'aime pas python : en ligne de code, c'est le language que j'utilise le plus. Mais j'utilise aussi perl, sed, awk, cut, javascript, html, tcl, bash …
Le fun pour moi : c'est pas le langage ; mais la programmation.
Et comme le petit harcelé du fond de la classe, c'est bash, alors j'écris souvent mes preuves de concepts en bash.
Pour résumer, c'est un petit nagios dont les agents sont repompés (licence incluses quand même je suis pas un pirate) de munin. Qui a un process par hôte qui broadcast en UDP sur une adresse en broadcast ce qui permet sans broker de messages de pouvoir récupérer les mesures avec du code qui transcrit les messages UDP en csv idoines, pour ensuite être consommés par un truc qui génère la page web avec gnuplot toutes les 90 secondes.
Bref, au niveau fonctionnalités, c'est pas une merveille, mais en rusant un peu, autodocumentation (repiquée à une idée de munin) plus tard, j'étais content d'avoir un dépôt qui avait de la gueule et qui rendait hommage à mon idée d'UNIX : peu de choses qui font les choses bien en interactions les unes avec les autres.
Pour info, j'ai fait du bash avancé pour trapper des SIGUSR parce que je trouvais fun de faire du bash asyncrhone.
Y'a 2 jours …
Je m'ai dit le truc que je déteste sur le projet : c'est le broadcast UDP en clair, c'est même la cause du I de FAIM (insécurisé).
Et je voulais le remplacer, quitte à introduire un broker par un truc bashable…
Et la solution évidente était … MQTT. Par contre c'est plus très évident de comment c'est devenu l'évidence.
Alors, j'ai installé Mosquitto un broker MQTT.
J'ai expérimenté mais en python parce que bien que j'étais en train d'utiliser **mosquitto_pub* et sub depuis une heure*, je ne trouvais toujours pas de client mqtt sastifaisant.
Oui, des fois, je suis tellement obnubilé que j'avais pas vu que j'avais les commandes sous le nez.
J'ai testé curl, mais le protocole est mal supporté, surtout le mqtts.
Bref, je programmais donc la suite en python quand m'est venue un idée con en lisant la description de mqtt et découvrant sa vocation première à être un bus pour les IoTs (trucs de l'internet). J'ai pensé à un vieux protocole qu'on utilisait en labo de physique qui faisait un peu pensé à SCSI avec ses boutons poussoirs pour choisir les adresses sur le bus : GPIB un protocole (dinosaure?) de physique pour les instruments de mesure qui avait la particularité à l'époque (avant 2000) de tenir coté client sur un FGPA est d'être adoré autant des techniciens qui programmaient les FGPAs que des utilisateurs.
Et si tu regardes, entre un instrument de mesure et un IoT y'a pas grande différence.
M'est donc venue, l'idée farfelue d'impleménter GPIB over MQTT.
Mais, je suis pas bon en micro électronique, alors m'est venue l'idée de faire une logique de BUS, et sur le fil … d'envoyer du FORTH.
Pourquoi du FORTH, parce qu'étant un langage analysable de gauche à droite, ça fait tenir un interpréteur sur un FGPA les doigts dans le nez, et que comme par hasard, j'ai un écrit un FORTH que je rêvais d'étendre.
Et en exactement 100 lignes (ma limite psychologique pour une brique d'une preuve de concept) : j'ai obtenu ceci qui ne peut pas se comprendre sans ce commit.
Hui, où vais-je, dans quel état j'erre ?
Et je faisais joujou avec mon client à publier des commandes sur le bus quand la révélation est arrivée : j'ai les bases d'un central command center d'un hacker russe pour piloter des machines à distances.
Je peux allumer/éteindre l'agent/le faire se Remettre à Zéro, changer les temps de mesures … déboguer…
C'est un sentiment étrange qui s'est offert à moi : j'ai trouvé un truc rigolo, mais comment le structurer sans que ça se barre dans tous les sens ?
Fork, fusion, intégration à un des existants, création d'un nouveau projet ?
Et évidemment si nouveau projet, se pose le problème du nom. SkyNetv01 (pour me différencier des 1000 autres skynet) ?
En fait, ça existe peut-être déjà un bus de contrôle au-dessus de MQTT, et je fais un truc inutile ? Jeter est toujours une possibilité.
# lapin
Posté par steph1978 . Évalué à 3 (+1/-0).
Journal intéressant. J'ai juste pas compris le rapport entre GPIB et MQTT et comment le second peu encapsulé le premier et surtout l’intérêt de GPIB quand on a MQTT.
[^] # Re: lapin
Posté par Jul (site web personnel) . Évalué à 1 (+1/-1).
Je voulais émuler GPIB au dessus de MQTT.
Puis je me suis aperçu que c'était trop compliqué au vu de mes capacités.
Je me suis limité par la suite à envoyer du forth sur un bus de commande et à simplement obtenir les trucs amusants comme arrêter, relancer une mesure, remettre à zéro le bot, … pinger …. Bref, je réimplémente un C&C en python + forth maison.
Mais, je me dis que le truc étant agnostique sur l'origine du message, ça pourrait être tout aussi bien être un IPC avec passage de forth sur le fil au lieu de passer juste des données.
J'ai trop d'idées, mais l'une d'entre elle est de faire un ansible pour IoT où comme tu peux paramétrer tes commandes cotées client, tu implémentes (ou pas) les commandes à exécuter, la sécurité reposant sur les ACLs MQTT sur les canaux. De la bonne, vraie, injection de commande par conception dans un forth qui se veut confiné en ressource et fonctionnalités pour éviter des problèmes triviaux (comme le halting problème).
Une autre, c'est de muscler le langage pour permettre de faire tout ce que fait le démonstrateur en python afin de créer une sorte d'objective forth où par défaut toute fonction est un agent indépendant qui communique par MQTT en s'envoyant du forth comme message sur un bus.
# C&C
Posté par steph1978 . Évalué à 4 (+2/-0).
Historiquement les C&C étaient implémenté sur IRC.
Si je devais en écrire un en tant que béotien, je pense que j'utiliserai du websocket car cela passerait un peu plus inaperçu de nos jours où tout est "over http(s)".
[^] # Re: C&C
Posté par Jul (site web personnel) . Évalué à 2 (+1/-0).
Le serveur MQTT est configurable en serveur websocket qui est supportée par certains clients (malheureusement non disponibles en cli). :D
Donc, j'ai les websockets si je veux \o/
Ça ressemble bien à un C&C, on est d'accord ?
[^] # Re: C&C
Posté par steph1978 . Évalué à 3 (+1/-0).
Je n'en ai jamais mis en œuvre, mais je dirai oui.
Cependant, je ne suis pas sûr que pour ce cas d'usage, MQTT apporte plus qu'un
socket.iopar exemple.# Commentaire de merde
Posté par Marotte ⛧ . Évalué à 1 (+1/-3).
Un « poil chié » c’est quand un poil pubien du pourtour anal est épilé par un étron particulièrement collant lors de l’éjection de ce dernier ? Ce serait pas moins emmerdant d’utiliser de la cire ? À moins que ce soit pour la beauté de geste peut-être ? _o_
# Don’t bash Bash, it’s awesome … sometimes!
Posté par Marotte ⛧ . Évalué à 4 (+1/-0).
J’apprécie Bash aussi pour ça. L’autre raison c’est, qu’en tant que shell presque omniprésent de nos jours il est imbattable en terme de facilité de déploiement, de compatibilité (ascendante et descendante) et d’interopérabilité. Alors oui, c’est une sorte de troll verruqueux menaçant la stabilité mentale de quiconque l’emploie, surtout en comparaison de la canonicité soyeuse et bienveillante d’un Python (3, je précise, parce que le 2 avait quelques monstruosités repoussantes même si l’idée était là), mais pour un tas de trucs, comme « glue » pour le devops, ou, comme tu l’évoques, prototypage de back-ends divers, c’est le premier choix.
Ce serait assez loufoque et passablement masochiste de l’utiliser pour développer une suite bureautique WYSIWYG ou un FPS mais pour tout outil élémentaire qui réclame de l’asynchronicité ou du parallélisme, il est bien plus ergonomique que Python. Et bien plus amusant à écrire !
Et pourquoi pas “Earthnet”, quitte à donner dans le différentialisme ! ^^
[^] # Re: Don’t bash Bash, it’s awesome … sometimes!
Posté par Jul (site web personnel) . Évalué à 2 (+1/-0).
Grace à la communauté, j'ai fait une petite PoC (preuve de concept) du bousin un peu suringéniée car un simple parseur LR en regexp aurait pu faire l'affaire.
Néanmoins, j'en suis arrivé à l'idée, qu'un forth dédié IPC/IoT avec une « inversion de contrôle » pour certaine commande (à définir du coté de l'interprété avec des callbacks dynamiques) était sinon utile au moins : RIGOLO.
J'envisage un ansible pour IoT basé sur du forth avec mqtt comme couche de transport aussi bien qu'un usage en orchestration de « process distribués ».
Ça continue à bouillir dans ma tête ^ mais je sens un truc fun, et utile émerger du brouillard.
Parce qu'il y a un hébergeur qui s'appelle earthnet ?
Dans ma tête son petit nom temporaire est « forth based C&C »
[^] # Re: Don’t bash Bash, it’s awesome … sometimes!
Posté par Marotte ⛧ . Évalué à 3 (+0/-0). Dernière modification le 07 février 2026 à 22:00.
Tu me l’apprends.
C’est pas forcément un problème d’utiliser un nom déjà existant à partir du moment où c’est pour un produit d’un domaine différent. M’enfin attention, je dis pas que c’est un nom qui pète (déjà du fait qu’il est pas très évidemment prononçable pour des non anglophones), je parle juste pour ne rien dire comme à mon habitude.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.