Podman et GUI

Je cherche encore comment créer des environnements de travail séparés afin de coder avec un peu de tout, sans polluer ma machine, et en réduisant les risques de hack (je pense principalement aux nombreux dépôts plus ou moins sûrs utilisés par les gestionnaires de paquets modernes). J'aime bien Podman, qui me semble relativement simple et léger tout en fournissant une bonne isolation, mais encore faut-il se souvenir de l'incantation nécessaire. Voici donc ce qui semble marcher, et qui permet l'affichage de clients graphiques:

Tout d'abord, créer le conteneur:

podman run -i -t -v ~/.emacs:/root/.emacs -v /home/fred/prog/python:/src -v /dev/input:/dev/input --network host --env DISPLAY --security-opt label=type:container_runtime_t --privileged -d -ti --name monprojet debian:trixie /bin/sh

Ensuite, autoriser l'affichage, et ouvrir une console:

xhost +; podman exec --privileged -ti monprojet /bin/bash

Et voilà ! À présent, il n'y a plus qu'à installer les paquets requis et on peut commencer à coder !

Un moteur de jeu écrit en Ocaml

C'est ce type qui s'est lancé dans ce projet un peu fou : créer un moteur de jeu en OCaml. Étant fan d'OCaml et de moteurs de jeu, forcément, ça me parle. Et en plus le bougre décide d'implémenter un système de composant d'entitées !

Alors, malheureusement, c'est du stream, c'est donc pas très dense et je n'ai pas très envie de me taper 10 heures de vidéo pour saisir toutes les subtilités de son approche. Mais le tout début déjà me donne un bel aperçu ce que ce c'est de travailler avec du OCaml moderne, en utilisant au maximum OPAM et Dune. Je compte bien m'y mettre en dilettante un de ces quatre et voir ce que ça donne. Ça pourrait être également l'occasion de creuser un peu les nouveautés du langage autour de la programmation concurrente via les domaines.

La première étape, ça serait de porter mon control, parce qu'avec tous ces controlleurs de jeux sur et sous mon bureau, je n'ai qu'une envie, c'est de coder avec !

No Man's Sky

Space geek devant l'éternel, j'avais suivi le drama autour du jeu No Man's Sky, la déception immense lors de sa sortie, puis sa rédemption lorsque le jeu a finalement réussi à livrer toutes ses promesses. Ayant vu qu'il était dans le Game Pass, je me suis décidé à l'installer et à le tester.

Pour ceux qui ne connaissent pas, No Man's Sky est un jeu d'exploration spatiale dans la lignée des Elite, où l'on incarne un explorateur aux commandes de son vaisseau spatial et où l'on peut se promener de planète en planète pour récolter des ressources, construire des bases, et tenter de résoudre un mystère qui sert de fil rouge tout le long du jeu.

L'on appréciera la partie création de base, très complète, et la grande quantité d'activités possibles qui, bien que classiques, sont gentiment fichues : exploration, minage, construction de bases, combat sur le sol ou dans l'espace (même si le combat n'est pas le but premier du jeu), commerce, mais aussi apprentissage des langues des diverses espèces intelligentes que l'on recontre. L'absence de transitions lorsque l'on passe de l'espace aux planètes est également appréciable, même si la partie pilotage ne pose aucun souci et garde un côté extrèmement arcade.

Il est cependant peu probable que cela devienne mon nouveau jeu préféré : il y a peu de défis liés à l'espace puisque le pilotage et la navigation sont triviaux, il y a des raccourcis de gameplay partout (il est possible d'appeler son vaisseau à n'importe quel endroit, on peut facilement installer des portails de téléportation) et le jeu n'échappe pas au grind puisqu'il faut pour avancer développer de nouvelles technologies gourmandes en ressources et qui donc nous envoient forcément explorer et récolter. J'espère avoir quand même le courage de construire une belle base sur une planète pas trop hostile.

Blender et noeuds de géométrie

Je tente doucement de rester à jour avec Blender, et en particulier avec les noeuds de géométrie. Cette fonctionnalité absolument géniale permet de construire des objets de manière procédurale avec un système de noeuds similaire aux noeuds de matériaux ou aux noeuds de composition. C'est de la programmation visuelle, et ça marche du tonnerre. La chaine BlenderDude propose toute une série de tutoriels pour utiliser les noeuds de géométrie, et j'ai commencé à m'attaquer à la modélisation d'une planète miniature.

Mais là, c'est dodo, alors je continuerai une prochaine fois. En attendant, j'ai plein d'idées pour utiliser à fond le concept !

Oeuf de canard - Retour à SDL

La bonne vieille bibliothèque SDL m'avait manqué. Tellement que j'avais raté que se préparait une version 3 ! Pas encore stable, j'ai préféré l'éviter pour le moment et me baser sur quelque chose de propre. Voici donc pour me remettre dans le bain un nouvel oeuf de canard pour réagir aux événements déclenchés par nos manettes. Signe des temps, je fournis maintenant une image Docker qui dérive d'une Debian Trixie et installe les dépendances nécéssaires. Normalement, il suffit de faire:

./refresh.sh # Créé l'image Docker et la démarre
./exec.sh # Execute un shell dans l'image Docker
cd /src 
./bootstrap.sh # Mise en place des Makefiles
make # Compilation
/buildb/bin/control # Test!

Petite surprise, je n'ai pas réussi à faire fonctionner le branchement à chaud des manettes : autant SDL détecte bien lorsque l'on débranche, l'inverse ne semble pas vrai. Je n'ai pas très envie de plonger dans le code de la SDL pour chercher si je l'utlise mal ou si c'est une limitation de l'implémentation Linux, donc tant pis, on fera sans.

Mise à jour Ubuntu

Mais c'est qu'il y a une nouvelle LTS Ubuntu, et on ne m'avait rien dit ! C'est avec pas mal d'excitation que j'ai mis à jour ma 22.04 en 24.04, et que j'ai vu tout un tas de nouvelles fonctionalités dans mes logiciels. Pour le moment, le plus marquant, c'est GnuCash, qui a maintenant un petit menu contextuel pour l'auto-complétion, ce qui est rudement pratique. J'ai l'impression que les fontes ont changé également, généralement je trouve les menus plus lisibles. On a aussi un nouvel Emacs, ce qui est toujours agréable (tiens, il faudra que je vous parle de mes dernières découvertes Emacs, en particulier le mode eglot qui a vraiment changé ma vie). Seul chose qui me reste à faire, c'est de mettre à jour mes bases Postgres, sans tout pétér (parce que y'a justement mes comptes GnuCash là dessus !). Je m'en vais faire l'exégèse de la doc pour mettre toutes les chances de mon côté.

Conférence C++ On sea

J'ai passé un vendredi à la conférence C++ On Sea, c'était très sympa, même si la météo ce jour là était particulièrement excécrable et que je me suis fait bien saucer à l'aller (et un peu au retour).

Je parle un petit peu de la technique sur Linuxfr, mais j'ai vraiment apprécié l'ambiance, le côté geek et bon enfant, le bingo du C++ où chacun avait un petit papier avec les termes à cocher quand on les entendait lors d'une présentation. Le déjeuner était plutôt pas mal, et au retour on s'est fait des amis et on s'est retrouvé avec un bon groupe avec qui causer dans le train. À refaire, même si je sens une certaine réticence du côté de mon employeur à nous laisser trop profiter de ce genre d'événement sur le temps de travail.

GTest est sympa

Je n'ai pas l'habitude d'encenser Google, mais quand ils font des trucs bien, il faut aussi savoir le dire. Je suis très impressionné par la bibliothèque GTest, qui est un cadriciel pour écrire des tests unitaires. C'est très bien pensé, et plein de bonnes idées : d'excellents comparateurs, une intégration démentielle avec CMake, mais surtout, la cerise sur le gâteau: un affichage console particulièrement pratique. Regardez donc ce programme:

#include <gtest/gtest.h>

TEST(Test, message)
{
  std::string s1("abc");
  std::string s2("def\nghi\njkl");

  ASSERT_EQ(s1, s2);
}

Quand on le fait tourner, on obtient:

gtest.cpp:9: Failure
Expected equality of these values:
  s1
    Which is: "abc"
  s2
    Which is: "def\nghi\njkl"
With diff:
@@ -1,1 +1,3 @@
-abc
+def
+ghi
+jkl

Regardez moi ça ! Il m'indique le nom des deux variables, leurs valeurs, et un diff ligne par ligne. Mais surtout, il m'affiche la valeur des variables non pas comme l'afficherait std::cout ou std::format, mais comme on devrait l'avoir dans le code source ! Et ça, c'est vraiment magique. Quand on a un résultat bien complexe, avec des caractères échappés, des retours chariots et tout et tout, juste pouvoir copier la sortie du test unitaire pour la coller telle quelle dans le source du test, quel confort ! La petite idée simple, mais il fallait y penser.

C++ : Chercher un fichier dans un répertoire - Partie 2

Et on continue à creuser ! Malheureusement, même avec une recherche récursive écrite en libc, cela prend encore trop de temps sur le système cible. En effet, il s'agit d'un système de fichiers un peu particulier, qui est censé monter en charge très fort mais dont les accès aux métadonnées sont individuellement plutôt lents. Et je ne peux pas échapper au besoin de devoir indexer un système de répertoires contenant environ 100 000 fichiers.

Le système de fichiers veut un accès concurrent ? On va lui en donner un. Malheureusement, ce n'est pas si simple ! En effet, il faut créer un algorithme à la fois récursif et parallèle, ce qui est un nid à problèmes. Pour l'instant, j'entrevois une solution qui consisterait à construire une liste des répertoires non visités, les visiter de manière parallèle pour aller chercher à chaque fois le prochain niveau, et continuer tant qu'on trouve. Le fait de gérer les tâches à partir du thread principal simpilife beaucoup de choses, mais empêche un très bon parallelisme.

Quelle tuile.

C++ : Chercher un fichier dans un répertoire

Petite séance d'optimisation aujourd'hui, où nous tentions d'améliorer une routine qui cherche des fichiers dans un répertoire.

En bon dev C++, nous sommes allés chercher ce bon vieux std::filesystem::path et ce non moins bon vieux std::filesystem::recursive_directory_iterator. Sauf que ça prend des plombes. Mais vraiment. Sur un système de fichiers distant (NFS) et un répertoire de 5000 fichiers pas accédé depuis quelques temps, cela peut monter à des dizaines de secondes. Mais que se passe-t-il ?

Avant de se lancer dans de complexes manipulations avec vtune ou encore gprof, pstack nous indique que l'on passe beaucoup de temps dans l'appel à stat. En effet, std::filesystem::recursive_directory_iterator nous donne un std::filesystem::directory_entry qui contient tout un tas d'infos tout à fait intéressantes, mais qui sont chères à récupérer...

Alors que peut-on faire ?

Eh bien, revenir aux bases, et à cette bonne vieille libc, qui contient l'appel readdir, lequel justement ne récupère pas d'informations sur le fichier autre que son type (ce qui est pratique pour explorer récursivement un répertoire). Et n'oublions pas non plus glob, lequel est justement conçu pour aller chercher un fichier efficacement à partir d'un motif.

Testons, alors. Et sur notre répertoire de 5000 fichiers, cela donne maintenant:

filesystem 40s
readdir 30ms
glob 3ms

Glob est donc plus de 10000 fois plus rapide qu'une recherche manuelle !

Conclusion : méfiance, donc ! Malgré ses qualités, std::filesystem::path peut coûter très cher, et revenir à des appels plus bas niveau est parfois salutaire.

Unity3D

Je m'initie aux joies d'Unity3D, et je trouve l'outil particulièrement bien fichu. Le fait qu'il soit aisé de trouver tout un tas de docs et de tutoriels vidéos aide aussi, bien sûr. Histoire de tenter de comprendre le bousin, j'ai modélisé une voiture, puis je l'ai importée et utilisé le moteur physique pour la faire se déplacer. Grâce au modèle de roue très complet comprenant les amortisseurs et la puissance, il suffit d'un petit peu de plomberie pour faire quelque chose de plutôt impressionnant.

Voici donc une sorte de jeep, ainsi qu'une boule que j'ai utilisée pour m'entraîner à importer des matériaux complexes depuis Blender. Et que ça marche bien ! Prochaine étape : ajouter obstacles et plans inclinés pour faire bondir la bagnole.

X-Plane en stream sur la télé

Eh bien ça marche ! Je ne sais pas trop ce qui a fait la différence, mais avec un Raspberry Pi réinstallé de neuf, et une reconfiguration complète des options dans Steam Remote, j'ai un X-Plane stable (une fois le chargement complété, j'ai quand même eu 2 déconnexions avant). Les commandes au pad sont moins chiadées qu'avec le hotas, mais sur grand écran, c'est très, très agréable. Je m'en suis mis plein les yeux.

Steam remote et Raspberry Pi

Ayant découvert la fonctionnalité "Remote Play" de Steam, je tente de bidouiller pour le faire fonctionner depuis ma tour jusqu'à ma télé avec un Raspberry Pi. Et le résultat est, heu, particulier.

Tout d'abord, c'est déjà hyper impressionnant que ça fonctionne tout court, et sans trop se casser le bol : la partie serveur de Steam Remote fonctionne toute seule, et le steamplay sur Raspberry Pi s'installe très facilement. Une fois qu'on a compris qu'il fallait faire un Ctrl-Alt-F1 pour aller dans le framebuffer et démarrer le client depuis là, c'est plutôt tranquille. Ensuite, le serveur est détecté, les périphériques aussi, bref, magie.

Cependentant, j'ai encore 1 souci : autant sur le même switch, la connection est tout à fait stable, en passant par le deuxième switch près de la télé, j'ai des coupures toutes les 3 minutes : le client quitte brutalement la session, et je dois me reconnecter.

Alors, que se passe-t-il ? La seule idée que j'ai, c'est que le switch de la télé est en 1Gb/s, alors que le switch près de la tour est en 100Mb/s. Est-ce que ça cause des pertes sur certains types de paquet ? Peut-être de l'UDP ?

Au vu du prix des switchs de nos jours, j'ai bien envie de simplement mettre à jour mon antiquité (25 ans d'âge tout de même !) et voir ce que ça donne.

Bonne année !

Permettez moi de souhaiter à mes nombreux lecteurs une excellente année 2024 !