Le bidouilleurs et leur capacité à détourner littéralement n’importe quoi pour y faire tourner DOOM, perso j’adore ! Et là, Aaron Christophel vient de franchir un nouveau cap en transformant une station de charge Anker Prime (lien affilié) en console de jeu. Oui, vous allez pouvoir joueur sur votre chargeur entre deux sessions de recharge.

L’histoire commence par une découverte intéressante… En bon hacker, Christophel analyse la station Anker Prime qu’il vient d’acheter et réalise que le hardware embarqué est bien plus costaud que prévu. Sous le capot, on trouve un ESP32-C3 pour le Bluetooth, mais surtout un microcontrôleur ARM Synwit SWM341RET7 cadencé à 150 MHz, accompagné de 16 Mo de flash et 8 Mo de RAM. Pour un simple chargeur, c’est du luxe !

Et puis il y a l’écran ! Et quel écran puisqu’il fait 200×480 pixels. C’est pas énorme, c’est vrai mais LARGEMENT suffisant pour afficher les couloirs de la base Martienne et les affreux démons pixelisés. Et le meilleur dans tout ça c’est qu’A’aucune modification hardware n’est nécessaire. Christophel a simplement chargé son code et hop, DOOM tourne.

Mais comment on joue sur un chargeur, me direz-vous ? Eh bien, c’est tout l’art de cette prouesse. Pour cela, le développeur utilise la molette rotative de la station comme contrôleur principal. On pousse pour avancer, on tourne pour se diriger, et on appuie pour tirer. C’est pas le summum de l’ergonomie, mais ça fonctionne ! Les contrôles sont surprenamment jouables, même si naviguer dans les niveaux demande un certain temps d’adaptation.

Techniquement, le jeu tourne de manière fluide, mais Christophel a dû faire quelques compromis. Le mode plein écran s’avère trop gourmand pour le processeur, et globalement l’expérience reste “un peu bancale” selon ses propres mots. Mais franchement, quand on voit DOOM tourner sur une station de charge, on va pas chipoter sur la fluidité.

Bref, un appareil de plus dans la longue liste des portages de DOOM sur des bidoules improbables. Christophel n’en est d’ailleurs pas à son coup d’essai puisqu’il avait déjà fait tourner le jeu sur une brosse à dents électrique. Entre les calculatrices, les réfrigérateurs connectés, les PDF et maintenant les chargeurs, on se demande s’il existe encore un appareil électronique incapable de faire tourner ce chef-d’œuvre de 1993.

Et ce qu’on découvre aussi c’est que cette station Anker n’est pas qu’un bête chargeur… c’est un petit ordinateur déguisé, avec suffisamment de ressources pour faire tourner des applications complexes. Christophel l’explique d’ailleurs très bien sur Mastodon : “Le MCU interne SWM34S est juste excellent ! 8 Mo de RAM + 16 Mo de flash directement mappés en mémoire, ça déchire.”

Alors si un simple chargeur peut faire tourner DOOM, qu’est-ce qui nous empêche d’imaginer des fonctionnalités plus poussées ? Par exemple, un chargeur qui affiche vos mails, votre météo, qui sert de hub domotique ? Ou qui se fait infecter par un virus dont l’objectif est de le faire exploser ?

Une fois encore, la seule limite des hackers c’est l’imagination. Et visiblement, Aaron Christophel n’en manque pas. Maintenant, reste à savoir quel sera le prochain appareil à rejoindre la grande famille des supports DOOM ???

Source

Hier soir, j’ai découvert un outil qui m’aurait évité des dizaines de commits “fix CI”, “fix CI again”, “please work this time” sur GitHub. J’sais pas si vous aussi vous connaissez cette galère ? Vous modifiez votre workflow GitHub Actions, vous poussez, ça plante, vous corrigez, vous repoussez, ça replante… Bref, votre historique Git ressemble à un journal de débugging en temps réel.

Et heureusement, wrkflw vient mettre fin à ce cauchemar.

Ce petit outil codé en Rust vous permet en fait de valider et d’exécuter vos GitHub Actions directement sur votre machine, sans avoir besoin de pusher quoi que ce soit. L’outil vient d’être annoncé sur le forum Rust et ça va bien aider tout le monde je pense.

Grâce à lui, au lieu de tester vos workflows dans le cloud GitHub (et potentiellement faire planter votre CI/CD devant toute l’équipe… La te-hon…), vous les exécutez localement. Wrkflw parse alors votre fichier YAML, résout les dépendances entre jobs, et lance tout ça soit dans Docker/Podman pour matcher l’environnement GitHub, soit en mode émulation si vous n’avez pas de runtime container sous la main.

Ce qui rend wrkflw vraiment pratique, c’est son interface TUI (Terminal User Interface) qui vous permet de visualiser l’exécution en temps réel. Un simple wrkflw tui et vous avez un dashboard interactif où vous pouvez suivre vos jobs, voir les logs, et comprendre ce qui foire sans avoir à jongler entre 15 onglets GitHub.

L’installation se fait en deux secondes si vous avez Rust :

cargo install wrkflw

Le package est aussi dispo sur crates.io et une fois installé, vous pouvez valider un workflow avec la commande :

wrkflw validate .github/workflows/rust.yml

ou le lancer directement avec

wrkflw run .github/workflows/ci.yml

L’outil détectera automatiquement tous vos workflows et les chargera dans l’interface.

Ce qui est fort avec wrkflow, c’est surtout le support quasi-complet des fonctionnalités de GitHub Actions. Les Matrix builds ? Ça passe ! Les Container actions ? Bah ouais, pas de problème ! Tout ce qui est JavaScript actions ? Check ! Même chose pour les Composite actions et les workflows réutilisables et même les fichiers d’environnement GitHub sont supportés. Bon, il y a quelques limitations évidemment. Vous ne pouvez pas par exemple mettre de secrets GitHub (ce qui est logique), et y’a pas de support Windows/macOS runners, ni pas d’upload/download d’artifacts. Mais pour 90% des cas d’usage, c’est largement suffisant.

Wrkflw s’inscrit dans une tendance plus large d’outils qui cherchent à remplacer Make et ses Makefiles cryptiques. Je pense par exemple à Task (Taskfile) qui est un autre exemple populaire, écrit en Go avec une syntaxe YAML plus moderne ou encore à Act, un autre outil open source qui fait à peu près pareil. Les développeurs cherchent clairement des alternatives plus lisibles et maintenables et wrkflw va encore plus loin en se spécialisant sur GitHub Actions.

Le mode Docker/Podman de wrkflw permet par exemple de créer des containers qui matchent au plus près l’environnement des runners GitHub. Et si jamais vous interrompez l’exécution avec Ctrl+C, pas de panique, puisque l’outil nettoie automatiquement tous les containers créés. Comme ça, y’aura plus de containers zombies qui traînent après vos tests.

Et pour tous ceux qui bossent en mode émulation sécurisée (sans Docker), wrkflw exécute les actions dans un environnement sandboxé. C’est moins fidèle à l’environnement GitHub mais au moins ça permet de tester rapidement sans avoir besoin d’installer Docker. Pratique sur des machines de dev légères ou des environnements restrictifs.

Le workflow de test devient donc le suivant : 1/ Vous modifiez votre YAML. 2/ Vous lancez wrkflw run . 3/ Vus voyez immédiatement si ça marche. 4/ Vous corrigez si besoin. 5/ Et c’est seulement ensuite que vous poussez sur GitHub. Plus de commits de debug, plus de CI cassée, plus de collègues qui râlent parce que la pipeline est tout rouge ^^.

L’outil est encore jeune bien sûr mais déjà très prometteur. Les prochaines versions devraient ajouter le support des secrets locaux, une meilleure intégration avec GitLab CI, et peut-être même le support des runners Windows/macOS.

Bref, si vous gérez des workflows GitHub Actions complexes, wrkflw va rapidement devenir indispensable à votre life.

A découvrir ici !

Vous savez ce qui m’a toujours ennuyé avec git blame ? C’est qu’à chaque refactoring, chaque reformatage de code, chaque déplacement de fichier, tous les noms disparaissent pour être remplacés par celui de la personne qui a fait ces modifications. Du coup, impossible de savoir qui a vraiment écrit le code original. Heureusement, un développeur nommé Sinclair Target vient de sortir un outil qui résout ce problème.

git-who (c’est son nom) fait donc exactement ce que git blame aurait dû faire depuis le début à savoir analyser qui a vraiment contribué à votre codebase, et pas juste qui a touché les lignes en dernier. Au lieu de se contenter d’une analyse ligne par ligne comme git blame, git-who analyse les patterns de contribution sur des fichiers entiers, des dossiers, voire des composants complets.

L’installation est simple comme bonjour. Si vous êtes sur Mac avec Homebrew, un petit brew install git-who et c’est réglé. Pour les autres, vous pouvez passer par Go avec go install github.com/sinclairtarget/git-who@latest ou compiler depuis les sources si vous aimez les défis. Docker est aussi supporté pour ceux qui préfèrent…

Ce qui rend git-who vraiment intéressant, c’est ses trois modes d’analyse. Le mode table (par défaut) vous donne un tableau récapitulatif des contributions par auteur, triable par nombre de commits, lignes de code, fichiers touchés ou date de modification. C’est pratique pour identifier rapidement qui sont les principaux contributeurs d’un projet. Le mode tree affiche l’arborescence du projet avec le contributeur principal annoté pour chaque fichier et dossier. Et le mode hist génère une timeline de l’activité des commits avec le top contributeur par période.

Pour vous donner une idée concrète, Sinclair Target a fait une démo sur le projet Vim pour analyser les patterns de maintenance après le décès de Bram Moolenaar. L’outil a permis d’identifier rapidement qui avait pris le relais sur différentes parties du code. C’est quelque chose qu’il aurait été impossible à voir clairement avec un git blame classique.

La différence fondamentale donc avec git blame, c’est que git-who “comprend” le contexte. Si quelqu’un déplace un fichier ou fait un reformatage massif, git blame lui attribuera toutes les lignes alors git-who, lui, va chercher plus loin dans l’historique pour identifier les véritables auteurs du code. Il respecte même les fichiers .mailmap pour consolider les identités multiples d’un même développeur et prend en compte le fichier .git-blame-ignore-revs pour ignorer certains commits de maintenance.

Pour utiliser git-who, il suffit de faire un git who à la racine de votre projet afin d’obtenir l’analyse de base. Vous pouvez filtrer par chemin avec git who Parser/ pour analyser seulement un dossier spécifique. Le tri est customisable avec des options comme -l pour trier par lignes de code ou -m pour la date de dernière modification. Et pour une vue historique entre deux versions, git who hist v3.10.9..v3.11.9 fait le job.

Bien sûr, git-who n’est pas le seul dans sa catégorie. GitLens pour VS Code reste l’extension la plus populaire, offrant une intégration visuelle directement dans l’éditeur. Git Quick Stats est aussi une autre alternative en ligne de commande qui propose des statistiques détaillées sur les repositories. Mais aucun ne va aussi loin que git-who dans l’analyse de la véritable propriété du code.

Qui maintient réellement cette partie critique du code ? Quelle équipe a le plus contribué à ce module ? Comment les contributions ont évolué au fil du temps ? Git-who vous aide à répondre à ces questions essentielles sur la gestion de votre projet, les audits de code ou simplement pour comprendre l’histoire d’un projet open source.

Bref, j’ai trouvé ça cool… Et qui sait, peut-être qu’un jour git-who sera intégré directement dans Git ?

C’est toujours marrant de voir des outils ultra populaires mettre des années à intégrer une fonctionnalité que tout le monde bricole depuis une éternité. Et aujourd’hui, c’est au tour de NGINX qui vient enfin de franchir le pas avec l’intégration native du protocole ACME !

Pour ceux qui ne seraient pas familiers avec cet acronyme, ACME (Automated Certificate Management Environment) c’est le protocole magique qui permet d’automatiser toute la gestion des certificats SSL/TLS. Développé à l’origine par l’Internet Security Research Group pour Let’s Encrypt, c’est donc lui qui vous évite de devoir renouveler manuellement vos certificats tous les 90 jours comme un moine copiste du Moyen Âge.

Le truc vraiment cool, c’est que NGINX a décidé de faire les choses en grand car plutôt que de bricoler une solution rapide, ils ont carrément développé un nouveau module baptisé ngx_http_acme_module qui s’appuie sur leur SDK Rust. Hé oui y’a du Rust dans NGINX ! Cette approche leur permet ainsi d’avoir un module dynamique disponible aussi bien pour la version open source que pour leur solution commerciale NGINX Plus.

Du coup, fini les scripts à la con avec Certbot qui tournent en cron et qui plantent au pire moment. Maintenant, vous configurez tout directement dans votre fichier NGINX comme ceci :

acme_issuer letsencrypt {
 uri https://acme-v02.api.letsencrypt.org/directory;
 state_path /var/cache/nginx/acme-letsencrypt;
 accept_terms_of_service;
}

server {
 listen 443 ssl;
 server_name .example.com;
 acme_certificate letsencrypt;
 ssl_certificate $acme_certificate;
 ssl_certificate_key $acme_certificate_key;
}

Simple, efficace, intégré, plus besoin de jongler entre différents outils, car tout se passe dans la configuration NGINX. Ensuite, les certificats se renouvellent automatiquement, s’installent tout seuls, et vous pouvez enfin dormir tranquille.

Mais attention, selon les discussions sur LWN.net, tout n’est pas rose au pays des bisounours… La communauté a quelques réserves, et pas des moindres. Leur plus gros point de friction c’est que NGINX a décidé de lancer cette première version avec uniquement le support du challenge HTTP-01. Pour les non-initiés, ça veut dire que votre serveur doit être accessible publiquement sur le port 80 pour prouver qu’il contrôle bien le domaine.

Les développeurs frustrés pointent aussi du doigt l’absence du challenge DNS-01. Et je trouve qu’ils ont raison d’être énervés car sans DNS-01, impossible de générer des certificats wildcard (*.example.com), et impossible de sécuriser des services internes qui ne sont pas exposés sur Internet. Donc pour tous ceux qui ont des homelabs ou des infrastructures privées, c’est relou.

Surtout que Caddy, le concurrent direct de NGINX, gère ça depuis des années sans problème. Bref, l’équipe NGINX promet que les challenges TLS-ALPN et DNS-01 arriveront dans le futur, mais pour l’instant, c’est motus et bouche cousue sur les délais.

Pour ceux qui veulent tester, sachez que le code est disponible sur GitHub et des packages précompilés sont déjà disponibles. La documentation officielle explique également bien le processus d’installation et de configuration. Notez que le module utilise une zone de mémoire partagée pour coordonner les renouvellements entre les différents workers NGINX, ce qui est plutôt malin pour éviter les conflits.

Au niveau technique, le workflow est assez classique… vous configurez votre serveur ACME (Let’s Encrypt ou autre), vous allouez la mémoire partagée nécessaire, vous configurez les challenges, et le module s’occupe du reste. Les variables $acme_certificate et $acme_certificate_key sont automatiquement remplies avec les chemins vers vos certificats.

Tout ceci permet de réduire également la surface d’attaque car vous n’avez plus besoin d’avoir Certbot et toutes ses dépendances Python qui traînent sur votre serveur ou plus de scripts externes qui doivent recharger NGINX. Tout est natif, et donc c’est forcément plus sécurisé.

Perso, je trouve que c’est un pas dans la bonne direction, même si l’implémentation actuelle est limitée. Et le faut qu’ils aient codé ça en Rust montre bien que NGINX prend au sérieux la modernisation de sa base de code. Du coup, pour ceux qui ont des besoins simples avec des domaines publics, foncez tester cette nouveauté. Plus d’excuses pour avoir des certificats expirés !

Source

Source

Comme moi vous utilisez Ycast pour profiter des radios gratuitement sur votre ampli de salon Yamaha (et pas que). J'utilise ycast en tant que service sur mon Raspberry Pi (Debian 11).

https://twitter.com/xhark/status/1774092225330266202

Problème : quand mon Raspberry Pi démarre le service Ycast est bien lancé mais ne fonctionne pas si je ne relance pas le service (ycast).

Voyons comment régler le problème.

La cause du problème

J'ai un peu galéré à comprendre pourquoi ce fichu service ycast démarrait sans pour autant avoir de démon en écoute. Jusqu'à ce que je me rende compte que le service démarre avant la stack réseau. Donc le script python n'arrive pas à ouvrir le port qui permettra à l'ampli de s'y connecter.

J'ai testé plusieurs pistes : la modification du fichier ycast.service pour ajouter une condition de démarrage (réseau), ça ne marchait pas. J'ai essayé d'ajouter un sleep de plusieurs secondes pour temporiser le lancement du service : pareil (et ce n'est pas propre).

Finalement je me suis tourné vers le code Python. Ne connaissant pas trop python je me suis aidé de ChatGPT et j'ai réussi à quelque chose de fonctionnel.

J'ai trouvé un fix

Pour vérifier que la connexion réseau fonctionne bien j'ai ajouté un ping vers un serveur DNS de Google (8.8.8.8).

C'est un choix discutable et je l'ai fait pour 2 raisons :

• cette adresse répond rapidement au ping de partout (tant que Google le permet)
• si internet ne fonctionne pas alors les webradios non plus

En bref dans mon cas ça fait le job.

Ce n'est pas l'idéal, et vous pouvez mettre l'IP interne de votre routeur/box/passerelle si c'est plus judicieux pour vous. Par exemple si vous souhaitez que ycast démarre même si vous avez une coupure de connexion internet au moment ou il se lance.

La solution

Sans plus tarder voici le fichier ycast/server.py.

De mon côté ce fichier est stocké dans :

/usr/local/lib/python3.9/dist-packages/ycast/server.py

Ce chemin varie suivant la version de Python installée sur votre machine, à vous d'adapter.

Attention : si vous faites une mise à jour ycast à l'aide de pip3 il faudra remettre le patch car il est conçu pour la version 1.1.0 de ycast. Oui bon, je n'allais pas créer un module python forké... et l'auteur ne semble pas hyper ouvert aux PR.

Conclusion

Depuis que j'ai corrigé ce petit bug je n'ai plus été embêté par les reboots de mon RPI. Le service Ycast démarre bien

Je me suis rendu compte d'un autre souci de démarrage : le service nginx sur mon routeur Tomato. J'ai également trouvé et publié la solution dans le post original (cherchez "màj 06.2024). Mais c'est un bug propre à Tomato, si vous utilisez autre chose vous n'êtes pas concerné.

A vous la musique

abonnez-vous par email

Article original écrit par Mr Xhark publié sur Blogmotion le 12/06/2024 | Pas de commentaire |
Attention : l'intégralité de ce billet est protégée par la licence Creative Commons