xryl669 a écrit 94 commentaires

Il n’y pas d’applications Google supplémentaire installée, Google Maps est notamment absent.

J'aimerais savoir comment ils ont fait cela. Car lorsque tu lances Android Auto, il vérifie:

1. Que tous les outils google sont installés (Service Google Play, Google Maps, Play Service Framework, Google Jeux, Google Music, Google aspirateur, etc…)
2. Que les versions sont à jour (impossible de ne pas mettre à jour, sinon AA ne démarre pas).
3. Que les certificats soient à jour pour le décryptage du code (et à défaut, télécharge les nouveaux certificats pour décrypter le code)

Bref, impossible de modifier le code de AA qui est livré (partiellement) crypté. Donc pour moi, soit Graphene OS cache Google Maps (c'est ce que j'ai sur mon téléphone, Google Maps est visible dans AA mais non visible dans la liste des applications Android), soit ils sont sacrément fort et ont réussi à déjouer les contre mesures de Google.

Visiblement, aucune des "distributions" Android ne supporte d'alternative au spyware que représente Android Auto. Sur chaque "version", il faut installer toute la suite des applications Google pour que ça fonctionne, donc merci la bonne dizaine d'applications inutiles, non désactivables et dévoreuses de batterie.

Je suis d'ailleurs étonné que GrapheneOS, qui prône ne pas vouloir de root sur le smartphone, autoriser à installer la suite Google qui elle, fonctionne complètement en root, sans aucun contrôle, en by-passant le mécanisme de base d'Android (comme le fait qu'Android Auto n'apparaît pas comme une application dans Android, les services qu'il a installés ne sont pas listés dans les applications système, etc…) pour quasiment tout son fonctionnement.

À la base Android Auto c'est un protocole type VNC pour envoyer son écran à distance, recevoir la position du doigt sur le touchscreen de la voiture et certaines infos du véhicule. Il y a bien eu un reverse engineering du protocole, mais visiblement personne n'a fait un AA-like open source qui évite cette erreur de Google.

À chaque fois que je dois utiliser une application en python, j'ai un arrière goût de bile dans la gorge. Je sais que quelque chose va casser, je sais que même si rien ne casse, la prochaine chose va casser, je sais que je n'aurais jamais assez de place pour stocker 40 versions différentes de la même bibliothèque (surtout en embarqué).

Honnêtement, à part pour du prototype, je trouve que l'environnement Python est une horreur.

Le python, c'est génial comme langage, c'est concis, c'est simple et facile à apprendre.

Mais l'évolution du langage qui n'est pas rétrocompatible et qui casse donc toute la base de code de la version précédente, ça, c'est mal.

Avec l'avènement de l'IA, et des notebooks Jupyter, il y a eu une explosion des utilisateurs python qui n'apprennent pas le fonctionnement du langage et de son univers.

Résultat: impossible de faire rentrer papa dans maman, le moindre projet utilisant 2 programmes Python ne fonctionnent jamais entre eux. Alors il faut les faire tourner dans un venv séparé et donc les faire communiquer via de l'IPC système. Déjà que Python c'est lent, là, c'est carrément dément.

En ce moment, je dois utiliser une librarie qui utilise un code en C (et donc du binding) sauf que la version système installé partout sur n'importe quel système de moins de 10ans est 4 ans en avance de ce que le code python attend. Si au moins python faisait comme tous les autres langages de programmation (c'est à dire de supporter nativement du FFI), la mise à niveau n'imposerait pas de réécrire tout le code du binding. Mais là, c'est l'enfer…

La preuve, dans le texte, il manque des mots. C'est un problème d'attention qu'on m'a dit ;-)

Typiquement, les coroutines (et le async/await en général) résolvent un problème que l'on aurait jamais eu si on avait pris le bon design dès le départ.

Le problème initial, c'est de vouloir faire un code avec des callbacks, parce que, asynchrone tout ça… Et de réfléchir à chaque ressource comme si on devait y accéder avec un chemin complet: "s'authentifier, demander X, puis Y, enfin Z".

Du coup, on trouve du bon vieux QNetworkReply avec ses callbacks/signaux Qt imbitables.

En réalité, le fonctionnement de ce type d'API (authentication/authorization/actions) est typiquement une machine à état. Ton client doit prouver un état (il est authentifié, et autorisé à accéder à une ressource) mais après les requêtes sont assez simple en 1:1.

Dans l'exemple précédent, X, Y c'est juste un état. Une fois demandé, le client est X ou Y, tu peux demander Z directement, voire W si W dépends de X uniquement.

Et donc, typiquement, le bon design, sans forcément faire appel aux coroutines, c'est de maintenir une variable d'état et une boucle principale qui agit sur cet état. En pseudo code c'est aussi simple que:

struct Client
{
  enum State 
  {
    NoConnected = 0,   
    Authenticated,
    Authorized,
    Ready,
    Requesting,
    [...] 
  } state;

  enum ResourceType
  {
    Me,
    KVMList,
    [...]
  } requiredResource;


  [...]

  std::unordered_map<ResourceType, std::function<...> actions;
  void setAction(RessourceType type, std::function<...> func) { actions[type] = func; }


  string answer; // Where all request answer goes

  // OVH API helpers here
  string me() { setAction(Me, [jsonData] { return jsonData["me"]; }); return triggerAction(Me); } 

  string triggerAction(ResourceType type) 
  {
    if (state < Ready) {
      // Handle state ramp up
      waitMainLoopRampup();
    }
    requiredResource = type;
    state = Requesting;

    waitMainLoop();
    state = Ready;
    return answer;
  }





};

std::unordered_map<Client::ResourceType, const char*> ovhAPI = { 
{Client::Me, "/me/"},   
{Client::KVMList, "/kvmlist/"},   
[...]
};

QNetworkReply nam;



bool mainLoop()
{
   QUrl url;
   switch (client.state) {
     case NoConnected: url = "http://ovhapi/authentification"; break;
     case Authenticated: url = "http://ovhapi/authorization" + ovhAPI[client.requiredResource]; break; 

     case Ready: return true; // Nothing to do
     default: return false;
   }
   // The only network request element
   nam.get(url).connect(client.actions[client.requiredResource]);
}

Ici, tout est replié sur un seul niveau d'asynchronisme, et plus des asynchronismes imbriqués. Tu enregistres la fonction que tu veux voir exécutée dans le client, et lorsque tu déclenche l'action d'accéder à la ressource, le client te retourne le résultat, de manière asynchrone, sans que tu n'aies à implémenter toute la logique d'accès à chaque objet qui t'intéresse.

Le mainLoop ci-dessus, c'est en gros le scheduler caché dans les coroutines, sauf que c'est un code qui ne cache rien du coup sans utiliser les trucs comme la sauvegarde de la pile et les pseudo tâches.

Surtout, tu peux exécuter des requêtes en parallèle (tu peux avoir plusieurs threads qui gèrent un mainLoop avec le client partagé), ce qui est très difficile à faire correctement avec les coroutines, car justement lorsqu'une coroutine est en "await", elle est ininterruptible (vu que techniquement, elle n'existe même plus sur la pile d'appel).

Non c'est pas du tout évident, un qatari consommant méchamment plus qu'un nigérian (j'en sais rien, j'ai pas vérifié), c'est le mode de vie qui compte, pas le nombre de personnes sur Terre.

Méchamment, c'est méchant. Un qatari mange comme les autres humains, environ 2000kCal par jour. Il a en moyenne autant d'enfant. Son mode de vie, aussi dispendieux qu'il soit, ne rattrapera jamais les ressources d'une personne supplémentaire.

Même un USien qui utilise 5 Terres par an (métrique complètement farfelue en plus, mais passons), tu auras donc plus à gagner à limiter une personne supplémentaire (tu "économises" 5 personnes virtuelle) qu'à limiter sa consommation (tu "économises" 4 personnes virtuelles si d'un coup, il se met à consommer en adéquation avec la capacité de production de la Terre , ce qui n'a que très peu de chance d'arriver).

Il n'y a aucune chance qu'un enfant USien consomme comme un Éthiopien en plus, donc il faut également prendre en compte la croissance exponentielle de ses propres enfants, etc…

Bref, l'impact d'une baisse démographique majeure est le plus court chemin vers la soutenabilité.

Non seulement ces générations devront payer nos retraites mais aussi la transition écologique. Si en plus tu leur laisses une démographie en berne, ils sont cuits et ne pourront rien faire.

Je vois aucun rapport avec les retraites, à part une sorte de bourrage de crâne franco-français. Il y a de nombreux pays qui n'ont pas notre système de retraite et qui s'en sorte sans problème avec une démographie en décroissance. Un moment ou à un autre, il faudra payer le cadeau d'une génération qui a été fait à la première génération de retraité en France. Si tu veux que ce "coût" impacte le moins possible, forcément, il vaut mieux qu'il y ait moins de cotisants qui souffrent que beaucoup de cotisants qui souffrent.

Je ne comprends pas pourquoi si la démographie est en berne, ils seraient cuit. Bien au contraire en fait. Avec un peuple moins nombreux, les problèmes de logements seraient quasiment résolus (et en plus, si l'offre dépasse la demande, les loyers & crédits baissent, la surpopulation anxiogène baisse, les incivilités aussi, etc…).

Le problème, ce n'est pas des enfants sur des vélos, le vrai problème, c'est les boomers dans leur SUV (1 par personne sinon c'est pas drôle).

À part un jalousie latente et une haine injustifiable, je ne comprends pas ce genre d'argument. Un SUV consomme moins de fait que la voiture qu'il remplace. Du point de vue écologique, la plupart des SUV sont donc un bénéfice pour les problèmes les plus urgents (à savoir la diminution de l'effet de serre). Les VE ont maintes fois prouvés avoir un impact plus que positif sur la réduction de CO2 dans l'atmosphère (en tout cas, en France).

Quand au 1 par personne, je te rejoins sur ce point. Le jour où on arrêtera la centralisation forcée vers les villes (métropoles et autre), magiquement le nombre de véhicules sur les routes chutera de manière exponentielle. Les véhicules ne seront plus remplacés aussi souvent (car c'est le kilométrage qui cause le remplacement des véhicules, pas leur âge), donc moins d'impact écologique. Mais ça veut dire plus (+) de télétravail, remettre les services de proximités dans les agglomérations plus petites où se situe la majorité des travailleurs au lieu de centraliser dans la "métropole", etc…

Intéressant, merci.

Il me semblait que pour faire une pointure plus petite, il suffisait de ne pas monter toutes les aiguilles. En gros, tu montes une aiguille sur deux et tu as une pointure 1.41 fois plus petite (d'après la vidéo).

Avec cette machine imprimée en 3d, on peut tricoter une chaussette en 2 temps, 3 mouvements.

Par contre, je ne comprends pas bien comment on fait le talon.

Franchement, on en fait tout une histoire de faire du code parallèle, mais il est sacrément plus difficile de faire du code perpendiculaire.

Là, aucun langage ne propose quoi que ce soit, surtout dès qu'il s'agit d'utiliser un nombre de dimensions supérieures à 2.

À la limite, il y aurait le brainfuck:

   ,
   ,
 .+++.
   ,
   ,

Contrairement à ce qui est indiqué dans l'article, on peut parfaitement avoir des pointeurs null dans Zig. Cf cet exemple. Sinon, impossible d'implémenter une liste chaînée, une queue, etc…

En même temps, vu que Zig peut utiliser un "module" C++ qui lui supporte le RAII, rien ne t'empêche de RAIIser ton code en C++ et de l'utiliser dans Zig, non ?

Ah, c'est encore pire que ce que je pensais.

Dans cet exemple de code, comment accèdes-tu à la variable err "globale" dans le scope du else ?

Si tu ne peux pas, dans ce cas, impossible d'utiliser une variable err ou a ou b nulle part, car le jour où la fonction gen_ten_or_none change de signature (suite à une maintenance de code par exemple) pour retourner une erreur, une variable err vient "shadow aliaser" tes propres variables sans aucun message d'alerte.

Autant dans ce cas, définir err et it et a et b comme mot clé du langage. C'est assez déroutant en fait.

De plus map prend un "fonction scope" comme argument et pas un "parameter list" du coup, ce qui fait un peu mélanges d'effluves, car les autres fonctions attendent toutes un "parameter list".

Comment faire pour avoir un code plus long dans un map ? (Genre 2 lignes, ou assigner une variable externe lors de l'itération?).

C'est l'it qui sort du bois dans le map, qui rencontre un a qui se croit supérieur au b lorsqu'il sort, mais en cas de problème, il err sans exception.

Magnifique… Je suppose qu'écrire 'a,' ou 'it,' pour pouvoir choisir le nom de la variable dans une fonction lambda eu été trop de dépense d'énergie, résultat, il y a des variables magiques qui sortent de nulle part, qui empêche (du moins, je l'espère) l'utilisation de ces noms partout ailleurs (c'est clair que it, a, err sont jamais utilisées dans du code standard).

Bref, c'est nul comme choix.

Le bit est incompressible

Ouais, sauf en informatique quantique. Et dans certains films aussi.

Les fixer sur son tableau de chasse, s'entend.

Le gars dans l'article l'a tenté pour son extension. En gros, il a mis en quarantaine le site "youtube.com". Son extension a été désactivée sur le site, mais pas uBlock origin. C'est à dire que Mozilla outrepasse ta configuration avec une liste inconnue d'extensions.

Pire, si l'extension est mise sur la barre d'outils (à côté de l'adresse bar) comme la majorité des extensions font, il n'y a aucun signal visuel que l'extension est désactivée (comme par exemple, mettre l'icône en grisé, ou mettre une barre diagonale rouge sur l'icône).

Dit différemment, si tu as mis un uBlock Origin et qu'il prend l'envie à Mozilla d'interdire cette extension sur youtube, elle peut le faire, et tu n'en saura rien. (Bon, exemple douteux, vu que quand UBO n'est pas là, tu le vois direct sur le web).

Imagine pour un NoScript, DoNotTrack, StopTheMadness ou autre…

What ? Tu as une source ?

https://lapcatsoftware.com/articles/2023/7/1.html

Oui. Ceci dit, les autres navigateurs proposent quasiment la même chose, même sous Android.

Pour Tor ou I2P, c'est pas possible sur Android. Le mode privé, c'est autant privé que les autres. Pocket, c'est pas libre, c'est gratuit seulement.

Après chacun ses besoins, je dis pas.

Personnellement, j'évite de mettre tous mes œufs dans le même panier, la synchro des mots de passes c'est Bitwarden sur mon NAS. Pour les marques pages, j'ai ma solution perso sur mon NAS aussi. Jamais je ne voudrais synchroniser mes onglets, le problème étant que j'ai du mal à les fermer, je vais pas m'alourdir avec ceux des autres machines en plus.

C'est bien de faire la liste des ajouts et corrections de bugs mais il faut également parler de ce qui a été enlevé aussi, comme par exemple, les extensions sous Android. Impossible d'installer une extension hors de la liste de …. roulements de tambours… 18 extensions certifiées par Mozilla.

Pour moi, le seul intérêt de Firefox sous Android, c'est de pouvoir avoir les extensions. Il est pas plus rapide que Chrome, pas plus ergonomique (voire un peu moins). Le fait d'enlever les extensions, c'est un coup de couteau dans le dos. Déjà que le passage aux webextensions…

En installant une version nightly et en bidouillant (procédure assez complexe), on se rend compte que l'on peut facilement faire marcher les autres extensions, ce n'est donc pas une raison technique qui justifie ce choix. Quelle est la raison?

Sans parler de la récente orientation de Mozilla de désactiver certaines extensions suivant le site web où vous êtes…

Je reste toujours fidèle à Firefox sur mes périphériques, mais c'est plus par conviction que par choix logique et justifiable. J'espère sérieusement que ça va changer dans les mois qui viennent et que certaines killer features vont revenir sur Firefox…

Espressif, le firmware n'est pas ouvert, tu te trompes, tu confonds avec esp-idf qui est ouvert, mais qui se repose sur:
1. Le code en ROM (vérifie les scripts de l'éditeur de lien, tu verras, en gros, la libc est en ROM, la gestion des MMU est en ROM, etc…)
2. Des librairies statique en .a précompilés (pour le WIFI, le Bluetooth, le SOC, l'implémentation bas niveau de FreeRTOS, etc…) qui seraient, sous linux, des binaires firmwares.

Mais après tout, on s'en fiche un peu qu'il soit ouvert, vu que tu peux pas le modifier de toute façon (tu peux pas changer l'architecture du CPU, ni le hardware, ni le plan mémoire, ni…). C'est une plateforme très ouverte et documentée par rapport à la concurrence, type STM32 ou autre, mais certainement pas libre.

RISC-V sur ESP32-C est pas plus ouvert que le Tensilica LX7 des ESP32-S.

Je pense pas que device tree ait le moindre lien avec UEFI. Le device tree, c'est juste une description, binaire, de ce que la machine a comme périphériques. Le device tree n'a aucun "driver", aucun code, rien n'est exécuté sur/avec le device tree.
Le device tree est utilisé par linux, une fois démarré pour savoir quel driver installer et lancer (il faut donc qu'ils soient compilé dans l'image Linux, ou via des modules dans le initrd / rootfs).

L'UEFI, c'est un OS avant l'OS. Il implémente un mini OS suffisant pour démarrer un vrai OS (et accessoirement, valider que le vrai OS est bien celui qui est autorisé). C'est, fonctionnellement, comme u-boot, pas étonnant que u-boot ait implémenté les API UEFI.

Les drivers de ce mini OS sont spécifiques à ta machine, il n'est pas question d'avoir tous les drivers du monde comme linux, il faut juste pouvoir faire les opérations de base, c'est à dire pouvoir charger des données d'un support de stockage, démarrer la mémoire et le CPU, accessoirement afficher quelque chose (via un écran ou un port série ou le réseau) et passer la main.

Quelque soit la machine, l'API de ces drivers est standardisée en UEFI (contrairement à u-boot, où c'est de l'open source, comprendre: chacun sa sauce), donc c'est plus simple pour les vendeurs d'OS et les fabricants de matériels. C'est inutile pour une carte avec un microcontrolleur où les composants physiques sont connus et fixes (ici, u-boot suffit avec ses drivers spécifiques), mais pour un PC où chaque composant provient d'un fabricant différent inconnu avant l'assemblage (mémoire, carte réseau, GPU, etc…), c'est indispensable.

un compilateur ne sait pas si ta boucle est faite 10,100,10 000 fois.

D'ailleurs son code C est tronqué ,quand il deplit il fait 8 fois, mais le compilateur comment il sait qu'il peut déplier 8 fois ?

Beh si, il sait justement. Le loop unrolling, c'est pas fait sur le compteur de boucle for i = O; i < N; i++), mais sur le nombre d'ALU disponible sur le CPU, on le nombre d'exécution qui peuvent se faire en parallèle (SIMD). À la limite, il peut aussi déplier sur la taille du cache et du prefetcher (si la boucle touche une zone de 16 octets, il va déplier suffisamment pour les 4 itérations rentrent dans une ligne de caches de 64 octets).

De toute façon, le compilateur va convertir ton code en une sorte d'arbre logique des opérations à effectuer sur les données, et le backend va essayer de mapper ces opérations le mieux possible sur l'architecture binaire cible. Et le gros problème, c'est justement de décrire cette architecture cible en étant le plus efficace (et juste!) possible.

L'itanium est arrivé trop tôt et le soft était pas prêt à utiliser cette architecture. Les algorithmes SIMD/vectorisés sont arrivés des années plus tard.

De plus, c'est quasi impossible de faire un processeur efficace avec de multiples instructions/cycle sans avoir de out of order ou au moins une sorte de microcode. Les dépendances sont simplement insolvables sans résoudre l'ordre d'accès aux données (sequential memory access synchronization) sur un vecteur de plusieurs opérations, ce que le compilateur ne fourni pas (sauf en C++ pour les atomiques, mais c'est tout).
Donc, au niveau du processeur, si tu as la séquence de code:

A = B
B++
C = D
D = B
A += C

Bien que toutes ces opérations soient indépendantes les unes des autres (sauf la dernière), le processeur ne peut pas faire A = B en même temps que B++ car l'accès et le stockage à B doit être synchronisé sur ses ALU. Avec le OutOfOrder, il peut réordonner (A=B, C=D) et (B++, D=B) s'il le veut et s'affranchir de la synchronisation des caches pour saturer ses unités d'exécution.

Le compilateur ne peut pas changer l'ordre non plus (à la limite le C=D peut remonter) car le D=B a un effet observable donc B doit être calculé. Je ne parle même pas des atomiques/volatiles.

Ici avec 2 unités d'exécutions, tu ne peux pas faire moins que 4 cycles (A = B, puis B++, puis (C=D, D=B), puis A+=C) sans OoO, vue les dépendances.

Je parle ici de l'aspect implémentation et pas mathématique évidemment.

J'ai beaucoup de mal avec une nouvelle architecture "exotique", aussi bien soit elle. Car faire tourner une nouvelle ISA sur un FPGA, j'ai un peu l'impression que c'est facile (Leon, Microblaze, Pico8/32, RISC-V).

Le problème, paradoxalement, c'est pas le hard du CPU, c'est le hard complet (avec les devices, type bus SPI pour la flash du boot, PCIe, USB, etc…) et évidemment le soft.

Le soft, c'est réussir à faire intégrer le générateur de code pour l'architecture dans GCC et/ou LLVM (chose qui est déjà très compliquée à réaliser, ça ne s'écrit pas avec le dos d'une cuillère), mais s'assurer que ça fonctionne avec tous les paquets nécessaires pour un OS.

Un raspberry-pi like, c'est avoir un CPU avec tous les périphériques nécessaires à booter linux (c'est à dire flash NOR ou SPI + gestionnaire d'interruption + MMU complexe + DMA + …), mais également tous les périphériques nécessaires à l'OS (sortie vidéo, réseau, IO pour l'IHM, powersaving, encodage et décodage video, GPU, etc…) et pouvoir compiler, sans erreur, tous les paquets d'une distribution type debian (donc avec du C/C++, mais aussi du Java, du Rust, du Go, … autant de compilateur à implémenter).

Déjà, avec le tsunami RISC-V, c'est pas gagné, alors avec une ISA toute neuve sans une masse d'implémentation, je pense que c'est mort…

À la limite, une carte type "Arduino" avec un microcontrolleur sans OS, pourquoi pas. Mais même dans ce cas, tous les périphériques d'un microcontrolleur sont à implémenter, et c'est pas un Freecore qui va fournir cette implémentation.

Visiblement, sous Wayland, la pipette utilise une fonction qui retourne l'échantillonnage (triplet de couleur) du buffer de donnée image, et donc ni sa position, ni l'application concernée.

Impossible donc pour Gimp de savoir que l'utilisateur a cliqué sur une image de Gimp (qui peut être mise à l'échelle par Wayland d'ailleurs (ce qui est très souvent le cas en 4K), donc avoir subit une interpolation. Bref, l'interface "sécurité" de Wayland qui isole les applications / le gestionnaire de fenêtre joue parfaitement son rôle, si bien que le résultat est inutile.

Dans un monde pro, par exemple sur Apple, tu peux avoir un échantillonnage des pixels, et il est associé aux informations de profil de couleur (ce qui est, à la fois sécure et correct). Mais Wayland est très basique (trop) et visiblement, le bât blesse ici car l'information est manquante. Si en plus il faut attendre que ce soit aux clients de Wayland de faire le calcul de ceci, c'est mort avant plusieurs années, si jamais c'est fait un jour. Normalement, avec un bon protocole de fenêtre, chaque fenêtre/buffer pourrait avoir son propre profil de couleur et ce serait au gestionnaire de fenêtre de faire la conversion finale pour avoir la même chose sur un écran calibré donné. Typiquement, c'est ce que tu as dans Final Cut par exemple, lorsque tu preview un rush UHDTV sur un écran sRGB. L'image est très sombre (voire noire) sans ajustement de profil, pourtant elle est parfaitement visible dans la fenêtre de preview sous MacOS. Mais imagine la galère entre une fenêtre Gtk dans un environnement KDE qui n'ont aucune notion du profil des images/buffer.

Je me suis déjà fait avoir une fois en travaillant sur un RAW pour impression avec une forte dynamique sur MacOS, qui rendait nickel sur l'écran du Mac calibré et qui, une fois imprimé en tableau pour un client, était tout écrasé. L'imprimeur n'a jamais voulu reconnaître qu'il ne prenait pas en compte le profil de couleur de l'image fournie seulement du sRGB par défaut (lequel ?). Bref, j'aurais dû convertir l'image avant l'export en sRGB type Windows et là, peut être que j'aurais eu les bonnes dynamiques.

Moi aussi, un langage descriptif de l'interface (type QML) ça me botte.

Jusqu'à ce que l'on réalise qu'il n'est pas dynamique, il faut le compiler sur l'hôte pour que ça donne l'UI (contrairement à QtQuick/QML).

Du coup, pour moi, ça perd pas mal d'intérêt.

Pourquoi ne pas faire un éditeur graphique (c'est quand même beaucoup plus simple à utiliser) s'il faut compiler de toutes façons ?

Là où ça aurait vraiment été super classe, c'est une description de l'UI (en JSON, ou même comme ils ont fait), que l'on peut changer au runtime, avec un lien entre les widgets et les signaux générés (et gérés dans le code compilé, lui). Histoire de pouvoir, par exemple, modifier le fichier, l'uploader sur la cible et zou le nouvel UI apparaît.

Sur un processeur embarqué, c'est gagner un temps fou de développement, car il suffit simplement d'avoir un système de fichier et un serveur web (très simple sur ESP32, Pi et autre) au lieu d'avoir à générer un binaire monstrueux, faire un OTA et attendre que ça reboote pour voir le résultat.

Après, il y a la solution demo "web", c'est pas mal, mais moins pratique qu'un éditeur graphique au final.

J'ai aussi un peu de mal avec le rust et l'embarqué, le support de rust dans l'embarqué, c'est quand même pas trop top en ce moment, mais ça s'améliore… C'est surtout le manque de bibliothèques qui m'empêche d'utiliser rust et si le système en dépend, ça fait un langage de programmation en plus à gérer dans la chaîne de compilation déjà complexe d'un projet embarqué.