J'ai des nœuds au cerveau, je ne sais pas comment continuer

Sommaire

Le premier chapitre : FAIM !
Y'a 2 jours …
Hui, où vais-je, dans quel état j'erre ?

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é.