gVim, la version avec interface graphique du légendaire éditeur de texte Vim, récupère le support de GTK4. Pour situer, GTK c'est la boîte à outils qui dessine les fenêtres, les boutons et les menus des applications sous Linux.

Vim tournait jusqu'ici sur GTK2 et GTK3, deux versions vieillissantes. GTK4 modernise tout ça. Et le détail qui fait causer : le commit indique noir sur blanc que le portage a été co-écrit par Claude, l'IA d'Anthropic.

Le boulot a pris plusieurs semaines. Le support GTK4 est maintenant intégré au code de Vim, activable avec une option de compilation, --enable-gui=gtk4. GTK4 apporte un rendu plus moderne et un meilleur support des écrans haute densité, là où GTK2 commençait sérieusement à dater.

GTK2 n'est d'ailleurs plus vraiment maintenu côté GNOME depuis un bon moment, donc rester dessus n'était pas tenable éternellement. Pour l'instant, le script de configuration garde quand même GTK3 par défaut si vous ne précisez rien, le temps que la nouvelle version soit éprouvée. Aucune installation existante n'est donc affectée, et ça débarquera en option dans la prochaine version de Vim.

Le plus intéressant, ce n'est pas le code mais le tag "Co-authored-by: Claude" dans l'historique Git. Vim, c'est un projet open source vénérable, démarré en 1991, l'éditeur des barbus et des serveurs Linux du monde entier. L'éditeur n'a pas bougé sur ses fondamentaux depuis des décennies, et ce genre de modernisation graphique traîne souvent faute de bras pour s'en occuper.

Voir une IA créditée comme co-autrice sur une toolkit graphique de trente ans, c'est quand même un signal fort. Et personne n'a planqué la contribution : elle est assumée et tracée.

C'est exactement le bon réflexe. Le débat sur les contributions d'IA dans l'open source n'est pas nouveau, Greg Kroah-Hartman, un des mainteneurs du noyau Linux, avait déjà posé le sujet sur la table. Le vrai problème n'a jamais été "l'IA a écrit du code", mais "est-ce que c'est transparent et est-ce qu'un humain a relu et validé".

Ici, les deux cases sont cochées. Le code est passé par la revue habituelle du projet, et le crédit est explicite. Un curieux peut remonter le commit et voir précisément ce qui a été fait.

Bref, une IA qui aide à dépoussiérer une toolkit de trente ans en le disant clairement, c'est plutôt la version saine du truc.

Source : Phoronix

Faire tourner les logiciels Adobe sous Linux, c'est la quête éternelle des photographes et graphistes qui voudraient bien quitter Windows ou macOS mais qui n'ont rien de comparable côté Linux.

Adobe n'a jamais voulu porter sa suite officiellement. Du coup, depuis des années, des développeurs tentent de la faire fonctionner via Wine, le logiciel libre qui sait exécuter des programmes Windows sur Linux. Avec un succès souvent partiel, et beaucoup de bidouille manuelle.

Un développeur connu sous le pseudo sander110419 vient de publier une recette reproductible pour faire fonctionner Adobe Lightroom CC sur Linux. Pas Lightroom Classic, attention, mais bien la version Creative Cloud avec la synchronisation, qui dépend de plus de composants Windows.

Tout est documenté sur GitHub, avec les scripts, les DLL patchées et le mode d'emploi. La particularité, c'est qui a fait le travail. Le développeur a simplement donné une consigne à Claude Code, l'assistant de programmation d'Anthropic en ligne de commande, et il a regardé l'IA bosser.

La consigne tenait en une phrase : faire tourner Lightroom CC sur Linux, puis publier une recette reproductible. Et Claude Opus 4.7, le modèle utilisé, a tout fait en autonomie. Il a identifié les composants Windows manquants, écrit des stubs, des fausses DLL qui simulent le comportement attendu, patché celles qui posaient problème, testé le tout sous Wine 11.8 staging, puis rédigé le README et la documentation. L'humain a juste validé derrière.

Côté résultat, ça marche raisonnablement bien sur la dernière version testée (Lightroom CC 9.3.1). La synchronisation cloud fonctionne, l'interface répond, les fonctions de base sont là. Quelques boîtes de dialogue plantent encore, et certaines fonctions accélérées par la carte graphique ne sont pas complètement opérationnelles. Mais on est sur un usage réel possible, ce qui n'avait jamais été le cas auparavant pour cette version.

Au passage, c'est un cas d'école intéressant pour ceux qui suivent l'évolution des assistants IA. La tâche est typiquement le genre de travail que personne n'a vraiment envie de faire : ingrat, plein de tâtonnements, qui demande de lire de la doc obscure et de tester en boucle. Et c'est précisément le terrain où une IA en mode agentique tient le mieux la route aujourd'hui.

Source : Phoronix

Vous n'avez pas de Mac Silicon, mais vous avez vu passer mon article de ce matin sur vLLM-MLX et son serveur d'IA local ? Hé bien bonne nouvelle, je suis tombé ce midi sur Lemonade SDK , un serveur d'IA local communautaire sponsorisé par AMD (et largement codé par leurs ingénieurs), qui joue dans la même cour, mais côté PC + Mac !

C'est la même logique qu'avec vLLM-MLX, vous installez le serveur (un paquet clé en main selon votre OS, pas de bidouille pip), et il expose un endpoint compatible API OpenAI sur http://localhost:13305/api/v1. Vos scripts tapent dessus au lieu d'envoyer vos prompts, et votre pognon, chez OpenAI.

Le démarrage tient en une ligne. Un lemonade run Gemma-4-E2B-it-GGUF lance un modèle, et un lemonade launch claude branche carrément Claude Code sur votre machine.

Sauf que là où vLLM-MLX s'appuie sur MLX pour les puces Apple, Lemonade vise les NPU Ryzen AI et les GPU Radeon. Et c'est tout l'intérêt du truc car depuis la 10.0 sortie en mars, le NPU XDNA2 des machines Ryzen AI récentes sert enfin à faire tourner des LLM sous Linux, et plus juste à décorer la fiche technique !

La 10.5 apporte également 2 nouveautés qui valent le coup. D'abord, le support macOS passe de bêta à officiel. Toutes les grosses fonctions sont validées sur Mac (le texte via llama.cpp et Metal, le reste via les autres moteurs embarqués) et ensuite, ça bascule sur ROCm 7.13 pour llama.cpp et la génération d'images.

J'ai pas de PC Ryzen AI sous la main pour tâter du fameux NPU, donc j'ai fait mes tests sur mon GPU Metal à moi. Notez qu'un lemonade list crache tout le catalogue, Qwen, Gemma, Llama, DeepSeek et compagnie.

Et ça dépote ! Un petit Qwen3-0.6B dans le chat intégré tourne à ~96 tokens par seconde avec mes 32 Go de RAM, c'est donc une réponse quasi instantanée. Après un modèle de 0,6 milliard de paramètres, c'est le poids plume du ring, donc comptez nettement moins sur un gros 8B, mais ça tourne nickel.

Du coup, sur Mac, vLLM-MLX joue la carte du natif Apple via MLX, alors que l'intérêt de Lemonade c'est surtout le cross-plateforme et le NPU Ryzen AI. Et comparé à Ollama , vous gagnez ce NPU mais aussi les fonctions audio (synthèse vocale, transcription) + un gestionnaire graphique de modèles pour piocher vos modèles. Et tout ça est sous licence Apache 2.0.

Bref, que vous soyez team Mac ou team Ryzen, c'est zéro ligne de facture API en fin de mois et surtout vos données qui restent chez vous !

Source : Phoronix

Greg Kroah-Hartman, le numéro 2 du développement du noyau Linux après Linus Torvalds en personne, s'est offert un nouveau jouet en avril dernier : un assistant IA tournant en local sur son ordinateur, qu'il a appelé gkh_clanker_t1000 en clin d'œil au Terminator.

Le but, c'est de faire du fuzzing, c'est-à-dire balancer plein d'entrées bizarres sur du code pour voir ce qui casse. Et clanker, c'est l'argot anglais légèrement méprisant pour désigner les IA. C'est plutôt rigolo.

Le matériel, c'est un Framework Desktop, un mini PC modulaire et réparable, équipé du Ryzen AI Max+ "Strix Halo" d'AMD, avec ses seize cœurs et jusqu'à 128 Go de mémoire unifiée. Le tout fait tourner un grand modèle de langage en local, sans cloud, sans dépendance externe. Greg KH lui balance des bouts du noyau Linux à analyser, l'IA repère les fragments suspects, et lui, avec ses décennies d'expérience, regarde si c'est un vrai bug ou du bruit. Quand c'est un vrai bug, il écrit le patch lui-même.

Depuis avril, près de 24 patches issus de ce process ont été mergés dans la branche principale du noyau Linux. Ils touchent des sous-systèmes très variés : USB, HID, audio ALSA, partage de fichiers SMB, IO_uring, le pilote graphique Nouveau, et plein d'autres.

Tous portent une étiquette spéciale dans Git, "Assisted-by: gregkh_clanker_t1000", pour signaler à la communauté que l'IA a participé à leur découverte. C'est une transparence que pas mal d'autres projets feraient bien de copier.

Et la suite est déjà là. Greg KH travaille sur une version successeur baptisée gkh_clanker_2000, qui poursuit la même logique avec quelques évolutions de méthodologie. L'idée n'est pas que l'IA écrive du code à la place du mainteneur, mais qu'elle agisse comme un assistant qui débroussaille et signale, pendant qu'un humain expérimenté garde la responsabilité finale.

Le détail qui change tout, c'est que tout ça tourne en local. Pas d'API cloud, pas de fuite de bouts de noyau chez un fournisseur tiers. Pour un projet aussi sensible que le noyau Linux, ce n'est pas un détail. Et ça démontre qu'on n'a pas besoin de GPT-5 ou Claude Opus dans le cloud pour faire du travail sérieux d'analyse de code, un bon modèle local sur un bon PC suffit.

Source : Phoronix

Cult of the Dead Cow , un des plus vieux collectifs hacktivistes encore en activité, ne se contente pas que de balancer des manifestes politiques depuis 1984. Ils codent. Et leur dernier bébé en date s'appelle Veilid , et c'est un framework P2P qui veut faire à vos apps ce que Tor a fait à votre navigateur.

Histoire de vous expliquer, vous prenez Veilid, vous l'intégrez dans votre app mobile ou web, et d'un coup tout votre trafic passe par un réseau pair-à-pair (P2P) chiffré de bout en bout. Cela veut dire qu'il n'y a pas de serveur central qui stocke vos messages.

Concernant votre IP, celle-ci n'apparaît alors plus au niveau applicatif (le routage privé l'obfusque entre pairs), et chaque nœud est identifié par une clé publique Ed25519 256-bit. Donc autant dire un truc carrément impossible à brute-force.

Le projet a été annoncé à DEF CON 31 en août 2023 par Christien "DilDog" Rioux et Katelyn "Medus4" Bowden, 2 membres historiques de cDc, et près de trois ans plus tard, ça continue d'évoluer toujours à un rythme régulier.

L'idée technique vous la connaissez si vous avez déjà touché à du décentralisé : Une table de hachage distribuée (DHT, en fait un annuaire éclaté entre tous les nœuds du réseau) gère le routage, chaque nœud relaie du trafic chiffré qu'il ne peut pas lire, et les pairs s'échangent des données sans jamais révéler leur IP.

Perso, c'est l'approche qui me semble vachement plus saine pour faire du social sans Mark Zuckerberg dans la boucle. C'est dans le même esprit que Tor et qu' IPFS , sauf que Veilid est pensé dès le départ pour les développeurs d'applications. Donc c'est pas fait pour anonymiser de la navigation web ou stocker des fichiers. C'est un Tor des applications si vous préférez...

Le framework est codé en Rust avec des bindings Flutter et Dart pour le mobile ainsi qu'une cible WebAssembly pour le navigateur. Vous pouvez donc carrément déployer une app Veilid sur Linux, macOS, Windows, Android, iOS, et même directement dans Chrome ou Firefox via WASM.

Le code, lui, est découpé en plusieurs composants : veilid-core pour le moteur, veilid-tools pour les utilitaires, veilid-flutter pour le mobile, veilid-wasm pour le navigateur et veilid-server qu'on installe sur un VPS Debian ou Fedora pour faire tourner un nœud public. Voilà, et le tout est sous licence Mozilla Public License 2.0, donc copyleft mais compatible si vous y ajoutez du code propriétaire par dessus.

L'app phare qui tourne déjà sur ce framework, c'est VeilidChat , une messagerie type Signal mais sans aucun serveur, sans numéro de téléphone et sans annuaire centralisé. Vous échangez votre clé publique avec un pote, et hop, c'est parti.

Si ça vous dit d'y jeter un oeil, sachez que le code de Veilid n'est pas sur GitHub mais sur GitLab . Après c'est encore assez nouveau, ce qui veut dire que ça bouge beaucoup de release en release. Donc si vous voulez coder votre prochaine app par dessus ce framework, va falloir vous accrocher car ça cassera souvent.

Mais si vous codez du décentralisé et que vous en avez franchement marre de bricoler libp2p à coup de colle forte Python, Veilid mérite un sérieux coup d'œil. Et même si vous codez pas, gardez l'œil sur VeilidChat car le jour où une appli grand public sortira là-dessus, ça va vraiment envoyer du lourd.

Beaucoup plus que Signal ou Telegram, je pense !

Vous vous souvenez de l'encoche des MacBook Pro et autres Air d'Apple ? Mais siiii, celle qu'on avait tous trouvée bien moche en 2022, au point que je vous avais pondu un article entier pour la faire disparaître ! Hé bien 4 ans plus tard, sk-ruban a décidé de lui donner une vraie utilité avec notchi qui transforme proprement cette encoche maudite en un compagnon fait de pixel-art et d'amour qui réagit en temps réel à votre Claude Code.

La boucle est bouclée, mes amis !

Une fois installée, l'app détecte les événements de votre session Claude Code via les hooks officiels car ce sont eux qui balancent les "events" sur un socket Unix local qui sont ensuite parsés en temps réel afin d'animer les sprites logés dans le creux de votre encoche.

Cette mascotte a cinq états bien distincts. Elle se balade en mode idle quand vous bricolez à côté, elle s'agite quand Claude réfléchit, elle pique un roupillon en cas de pause prolongée, elle se concentre quand le contexte se compacte, et elle vous fait les gros yeux quand l'IA attend une validation.

Ça bosse fort !

Un clic sur l'encoche et le panneau s'étend pour afficher le feed des événements, votre temps de session, et le quota d'usage restant.

L'option d'analyse de sentiment est également très sympa. Si vous lui fournissez une clé API Anthropic, l'app analysera alors vos prompts pour faire varier l'humeur de la mascotte entre joyeux, triste, neutre ou pleurnichard. À noter quand même que chaque prompt déclenche un appel API facturé sur votre compte Anthropic, donc à activer en conscience si vous bombardez Claude toute la journée et que vous êtes pété de thunes. Ce dont je ne doute pas un instant !!

Les options de Notchi

Et pour ceux qui jonglent avec plusieurs instances de Claude Code, les sessions concurrentes sont également supportées avec un sprite individuel par session, histoire d'éviter la confusion quand vous lancez 3 agents en parallèle.

Sk-ruban s'est inspiré de Claude Island et Readout (deux autres projets qui détournent l'encoche), et les sprites sont dessinés sur Aseprite. C'est un peu dans le même esprit que Peon Ping qui balance des sons de Warcraft à chaque action de votre agent, mais avec un aspect visuel ludique plutôt que sonore. Il y a même déjà un portage Windows réalisé par AptatoX pour ceux qui ne sont pas sur Mac.

Au niveau prérequis, comptez macOS 15 Sequoia minimum et un MacBook avec une vraie encoche, ce qui exclut les MacBook Air sans notch et les MBP d'avant la refonte 14/16 pouces. Le projet est sous licence GPL-3.0 et l'install se fait par Homebrew avec brew install --cask notchi, ou en DMG direct depuis les releases.

Et un grand merci à Camille Roux pour le partage !

Branislav Đalić, un dev serbe basé à Belgrade, vient de balancer un projet plutôt original baptisé GitLike . Il s'agit d'un GitHub décentralisé qui stocke vos repos sur IPFS et remplace le mot de passe par votre clé Ethereum (votre wallet quoi...).

Vous connectez votre wallet via SIWE (le standard EIP-4361, signature dans MetaMask ou WalletConnect), vous créez un repo, et hop, chaque commit, chaque fichier, chaque arbre devient un objet IPFS adressé par son CID. Tout pareil que Git côté usage, sauf que derrière y'a pas de serveur GitHub mais un simple Worker Cloudflare qui orchestre Pinata ou Filebase pour pinner vos données.

Côté install, la doc propose tout simplement de faire un npm install -g gitlike avec ensuite l'utiliser avec les commandes Git habituelles (init, clone, push, pull, branch), sauf que le package n'est pas encore publié sur npm public pour l'instant. Du coup, faudra patienter ou aller chercher le code directement dans le repo GitHub si vous voulez bricoler dès aujourd'hui.

La doc officielle mais l'install npm marche pas.

L'architecture tient en 3 étages bien séparés. Votre navigateur s'occupe de l'interface et de la signature avec le wallet, un petit serveur Cloudflare joue les videurs en backend (qui a le droit d'écrire, dans quel ordre, à quelle vitesse), et IPFS stocke tout le code en mode décentralisé via Pinata ou Filebase.

Et si vos repos doivent rester privés, vous pouvez activer un chiffrement qui se fait directement dans votre navigateur, comme ça personne d'autre ne lit vos fichiers en clair. En gros, votre onglet de navigateur fait office de vitrine, le Worker joue le mec de la sécu, et IPFS sert de coffre-fort distribué.

Le truc cool, c'est que GitLike peut importer votre code directement depuis GitHub ou GitLab, donc migrer un projet existant ne prend que quelques clics ! Et vous retrouvez tout le confort moderne, à savoir les pull requests avec gestion des conflits, des règles de protection sur les branches sensibles, et même un système pour déléguer l'écriture à un agent IA avec un périmètre limité dans le temps et l'espace (genre, commit uniquement sur telle branche, et seulement pendant 24h).

Sympa, donc, pour vibe coder avec un agent 100% autonome sans pour autant lui filer toutes vos clés et qu'il ne détruise tout dans une apocalypse nucléaire (Quoi, j'en fais trop ?)

Après même si l'idée semble sympa, je trouve que ça déplace le risque plutôt que de le faire disparaître. Parce que si vous paumez votre wallet, vous perdez l'accès en écriture (et possiblement en lecture si c'est chiffré) à tous vos repos, et y'a plus qu'à recommencer. Donc sauvegarder votre seed phrase (les 12 ou 24 mots de récupération du wallet, vous savez) est donc critique !

Quand on voit le rythme auquel GitHub colle ses nouveautés derrière Copilot Pro, c'est peut-être une solution intéressante que de décentraliser tout ça. J'ai fait un article aussi sur Patreon pour tous ceux qui voudraient se barrer de Github.

Côté concurrence, vous trouverez également Radicle qui fonctionne en peer-to-peer pur (mais demande un daemon local) ou l'ancien Mango (Ethereum + IPFS, mais plus trop maintenu). GitLike, lui, mise tout sur le navigateur et votre wallet, donc c'est plus simple !

Après c'est jeune et faut voir ça plus comme un proof of concept solide qu'un GitHub-killer. Mais ça tient bien la route et je trouve l'idée d'un Git contrôlé par un wallet ethereum plutôt classe. C'est peut-être ça le vrai web3 ;)))

Allez donc jeter un œil à gitlike.dev !

Vous avez déjà essayé de dessiner une TUI (Interface utilisateur pour le Terminal) à la main dans votre IDE ?

Genre, calculer les paddings d'une Box ANSI à la mano et compter les caractères Unicode pour aligner trois colonnes ? Pffff quelle galère !! Hé bien cette mauvaise expérience, Javier Alonso Gómez, Staff Design Technologist chez Docker, vient de la transformer en simple drag-and-drop avec son outil TUIStudio .

En gros, c'est comme Figma mais pour vos applis terminal.

Vous lancez l'éditeur, vous balancez des composants sur un canvas, et un aperçu ANSI temps réel vous montre ce que ça donnera dans un vrai terminal. Il y a 21 composants prêts à l'emploi (Box, Button, TextInput, Table, Tree, Modal, Tabs, Spinner...), avec un moteur de layout qui supporte Absolute, Flexbox et Grid.

C'est du CSS pour le terminal si vous préférez et le truc cool, c'est que ça reste fidèle au rendu final, donc fini les tableaux qui débordent sans raison !

J'suis pas encore super doué !

Côté thèmes, vous avez également le droit à 8 palettes intégrées (Dracula, Nord, Solarized, Monokai, Gruvbox, Tokyo Night, Nightfox et Sonokai), et le canvas se met à jour live quand vous changez. Sympa, hein !

Niveau export, TUIStudio cible les frameworks Ink (TypeScript), BubbleTea (Go), Blessed (JavaScript), Textual (Python), OpenTUI (TypeScript) et Tview (Go) mais d'après ce que j'ai lu sur le site officiel, la fonction d'export vers tout ça n'est pas encore opérationnelle. Mais ça m'étonne car lors de mes tests, j'ai quand même pu voir que ça fonctionnait... Donc j'sais pas, peut-être que le site web n'a pas été mis à jour et que l'export est bien opérationnel ?

L'export

Ça tourne sur macOS Apple Silicon, Windows et Linux (.deb) et le code est sous licence MIT sur le repo GitHub .

Amusez-vous bien !

Je viens de pousser en prod une fonctionnalité sur laquelle je bosse depuis quelques temps et comme je suis content du résultat, c'est le moment de partager ça avec vous.

En haut à gauche du site, juste à côté de l'icône qui change le thème, vous trouverez un petit bouton "abc" qui jusqu'à présent ne servait qu'à appliquer une police spéciale dyslexique à mon contenu. Mais j'ai amélioré un peu tout ça pour que maintenant niveau "Confort de lecture" vous soyez refait !

En cliquant donc sur cette icône, s'ouvre un petit panneau de config avec dedans de quoi configurer votre expérience de lecture aux petits oignons. Police adaptée pour la dyslexie, espacement variable, fond couleur crème, mode audio TTS, lignes colorées pour guider l'œil...etc tout ça sans dépendre d'un service tiers.

Ensuite, vos réglages sont conservés dans le localStorage de votre navigateur pour les retrouver à chaque visite et il y a un petit lien en bas de la fenêtre pour réinitialiser tout ça.

Maintenant, l'histoire derrière cette feature, parce qu'elle est intéressante. À la base j'étais parti pour recoder un équivalent du " Bionic Reading ", vous savez ce truc à la mode qui met en gras le début de chaque mot pour soi-disant accélérer la lecture. J'avais déjà bien avancé quand je suis tombé sur une étude scientifique de 2024 qui démontait complètement le concept. En gros, les chercheurs ont mesuré que cela ne produisait aucun effet positif sur la vitesse de lecture ni sur la compréhension. Que dalle...

Du coup, pivot complet... J'ai tout repris pour bâtir un système basé sur ce qui marche vraiment, avec un principe simple : Chaque option du panneau affiche un badge "Sci ✓" si elle est soutenue par la recherche, ou "Pref" si c'est une préférence subjective documentée. Comme ça vous savez sur quoi vous cliquez et on évite le marketing déguisé en science.

Côté polices donc, vous avez 4 choix. La police par défaut du site, Lexend qui est une "variable font" développée par la Dr. Bonnie Shaver-Troup avec des résultats publiés montrant une amélioration significative de la fluidité de lecture, Atkinson Hyperlegible créée par le Braille Institute spécifiquement pour les personnes malvoyantes, et enfin OpenDyslexic que j'avais déjà. Pour cette dernière, je l'ai mise avec un badge "Pref" parce que la communauté dyslexique l'apprécie mais les études sont moins solides scientifiquement.

Les sliders d'espacement permettent également de jouer sur trois axes : espace entre les lettres, hauteur de ligne, largeur de la colonne de texte. Tout est calibré pour être utile sans casser le rendu. Vous pouvez aussi activer un fond crème qui utilise la couleur Solarized base3 (c'est #FDF6E3, reconnue dans la communauté des dev pour son confort de lecture sur une longue durée), et le texte non-justifié qui évite les "rivières" blanches entre mots qui posent problème notamment aux dyslexiques.

Pour le guide visuel, je vous ai mis 2 options. "Lignes colorées" qui applique un gradient cosinus caractère par caractère sur chaque ligne, avec une palette noir-bleu-noir-rouge qui alterne et permet à l'œil de suivre naturellement la progression du texte.

Et ce que j'ai appelé Saccade que j'ai gardé en option, marqué d'un badge orange "Pref ⚠" parce que la science dit que ça sert pas à grand chose, mais que si vous aimez visuellement, bah au moins c'est dispo !

Et puis il y a le mode audio (TTS) qui dépend de la qualité des voix installées sur votre système. Y'a pas d'IA là dedans, donc ça peut donner une lecture robotique sur certains OS. Une fois activé, ça apparaît en haut des articles avec une estimation de durée. Ça utilise la Web Speech API native de votre navigateur, donc zéro service externe une fois encore et ça respecte la voix système que vous avez configurée.

À ma connaissance, je suis le seul à proposer ce niveau de personnalisation pour l'accessibilité. N'oubliez pas qu'au delà de la démarche, l'accessibilité numérique est devenu une obligation légale en Europe avec l' European Accessibility Act qui s'applique depuis juin 2025 (Qui en a entendu parlé ? Pas grand monde je pense).

En tout cas, si je peux me permettre ce luxe de bosser sur des trucs qui ne rapportent pas un kopeck mais qui rendent le site plus agréable et plus accessible, c'est uniquement grâce à mes Patreons .

Alors un énorme merci à eux.

Tagger des milliers de photos à la main, c'est le genre de corvée qu'on remet tous à plus tard depuis des années. Mais c'était sans compter sur photo-folder-tagger de Laurent Voillot qui règle ça grâce à 6 modes IA spécialisés, le tout en local, sans envoyer une seule image dans le cloud.

Vous faites pointer l'outil sur un dossier, vous choisissez le mode IA correspondant à vos photos, et hop, des fichiers XMP annexes sont générés à côté de chaque cliché. Ces fichiers contiennent les tags et sont directement lisibles par Lightroom Classic, Capture One, Bridge, Darktable et DigiKam, ce qui évite d'avoir à ré-importer ou à modifier les originaux !

Les 6 modes couvrent des usages bien distincts. Le mode Balade utilise CLIP SigLIP2 pour la classification générale (~50 ms par photo). Le mode Animaux combine BioCLIP v1 + CLIP (~40 ms). Pour les oiseaux et les insectes, c'est BioCLIP 2, entraîné sur 214 millions d'images de biodiversité (TreeOfLife-200M), à ~55 ms par image. Le mode Vacances sort la grosse artillerie avec Ollama et qwen2.5vl pour générer des descriptions en langage naturel (~1.8 s par photo).

Et le mode qui mérite une mention spéciale c'est Astro capable d'identifier automatiquement les objets célestes : Galaxies, nébuleuses, amas d'étoiles... les tags XMP pointent alors vers les références Messier, NGC ou IC correspondantes. C'est assez dingue comme feature.

En tout cas, c'est plus précis d'avoir tous ces petits modèles spécialisés plutôt que d'avoir un seul modèle qui fait tout. BioCLIP 2 sur la faune donne par exemple des résultats qu'un modèle généraliste n'atteindra pas.

L'installation se fait après récupération des sources via pip install -r requirements.txt. Tout est configurable dans config.yaml, les modèles IA utilisés, la langue des tags, les seuils de confiance...etc puis ça se lance avec python photo_folder_tagger.py. Au passage, n'oubliez pas que si vos photos sont un peu floues avant de lancer le tagger, SuperImage peut les upscaler en amont.

Bref, si vous avez des disques entiers de photos nature, astro ou de rando qui traînent sans tags depuis des années, c'est l'outil qu'il vous faut.

Merci à Laurent Voillot.

Justin Poehnelt, Senior Developer Relations Engineer chez Google, vient de balancer sur Github un outil en ligne de commande (CLI), codé en Rust qui permet de faire un truc trop pratique, à savoir piloter entièrement Workspace depuis le terminal. Ce logiciel nommé GWS est donc capable de gérer Gmail, Drive, Calendar, Sheets et sept autres services Google d'un coup. Et en plus, comme il a été conçu pour les agents IA, donc c'est pas juste pour vous et votre terminal !

Une fois installé via npm, cargo, brew ou un binaire pré-compilé, vous tapez gws auth login pour vous authentifier via OAuth et vous pouvez ensuite attaquer onze services depuis votre shell : Drive, Gmail, Calendar, Sheets, Docs, Chat, Admin, Apps Script, Tasks, Workspace Events et Model Armor.

Niveau archi, au lieu de hard-coder chaque commande dans le binaire, gws interroge tout simplement le Discovery Service de Google au démarrage et reconstruit son arbre de commandes à la volée. Du coup quand Google ajoute un endpoint à l'API Sheets, le CLI le voit apparaître tout seul. C'est trop bien parce que ça évite de devoir attendre une release pour utiliser un éventuel nouveau service de Google. Et pour un agent IA qui re-fetch le schéma à chaque run, c'est plutôt une bonne idée.

Donc en plus de démarrer en moins d'une seconde, GWS crache des sorties en JSON structurées, y'a un mode --dry-run qui montre la requête sans l'envoyer, et de l'auto-pagination via --page-all. Et côté commandes utilitaires, vous avez aussi les + qui sont des helpers cousus main tels que gws gmail +send, gws drive +upload, gws calendar +agenda, gws sheets +append, gws gmail +triage et un gws gmail +standup-report qui résume vos mails de la semaine en quelques lignes.

Le repo embarque aussi 40+ skills d'agent prêts à l'emploi du type "résume mes mails non lus" ou "génère mon rapport", une extension Gemini CLI qui s'installe avec gemini extensions install https://github.com/googleworkspace/cli, et le helper +sanitize-response qui fait passer la sortie par Model Armor (le filtre anti-prompt-injection de Google Cloud) pour éviter les réponses bizarres.

En gros, c'est un outil pensé pour faire piloter votre Workspace par Claude, Gemini ou n'importe quel agent. Comme ça vous allez pouvoir écrire un workflow qui lit vos mails non lus, en fait un résumé, le poste dans un Chat et classe tout ça proprement dans Drive... sans avoir à toucher à la souris ni avoir à utiliser votre cerveau léthargique. Elle est pas belle la vie ?

Sauf que. Le projet porte le disclaimer "This is not an officially supported Google product", et un employé Google a confirmé sur le thread Hacker News (presque 1000 points, quand même) que c'est un projet DevRel. Comprendre : pas de SLA, pas de roadmap garantie, pas d'équipe SRE qui veille au grain. Vous savez comment ça finit chez Google avec ce genre de statut !

Bref si vous êtes chaud pour tester, le binaire est dispo ici . Maintenant reste à voir si Google lui donnera un statut officiel ou si GWS s'éteindra discrètement comme tant d'autres projets internes oubliés...

Si vous avez committé du code depuis VS Code depuis mi-avril, allez tout de suite vérifier vos messages de commit car vous avez peut-être un nouveau co-auteur que vous n'avez jamais embauché.

En effet, Microsoft a discrètement basculé le réglage par défaut de l'éditeur pour ajouter Co-authored-by: Copilot <[email protected]> à des commits que VS Code considérait à tort comme contenant des contributions IA, même quand vous n'avez pas utilisé Copilot, et même quand vous avez explicitement désactivé toutes les fonctions IA.

Quelle lose, hein ? La Product Manager Courtney Webster a poussé cette fameuse pull request #310226 des enfers le 15 avril dernier sans aucune description, et le dev dmitrivMS l'a mergée tranquillou le lendemain.

Et le résultat de tout ce bordel, vous pouvez le lire dans la PR #310226 qui a explosé sur GitHub : 372 pouces baissés contre 2 levés, 30 réactions "confused", et des dizaines de commentaires furieux.

L' issue de suivi #314311 , ouverte ensuite par dmitrivMS pour faire son point public, a elle aussi reçu un torrent de réactions virulentes. Tu m'étonnes, ils font vraiment n'importe quoi...

Maintenant si vous êtes dans ce cas, vous pouvez neutraliser ça immédiatement, ajoutez dans votre settings.json :

"git.addAICoAuthor": "off"

Deux fois plus rapide que LZ4 en décompression ?? Ah bon c'est possible ? Évidemment, quand Bertrand Lebonnois a publié zxc sur GitHub , et m'a envoyé un email pour me prévenir, j'ai été jeter un œil, surtout aux benchmarks.

Eh bien après analyse, c'est bien réel !

La philosophie de zxc est assez tranchée vous allez voir. Il s'agit d'une lib WORM (Write-Once, Read-Many) qui permet de compresser une fois lentement, à la compilation ou en CI, et ensuite de décompresser comme vous voulez des millions de fois sur les appareils de vos utilisateurs à la vitesse de l'éclair. Avec zxc, on accepte que la compression soit lente et complexe (pour trouver le bitstream parfait), afin que la décompression soit méga rapide et simple pour le processeur. C'est aussi simple que ça.

Le revers de la médaille, c'est que si vous voulez de la compression à la volée ou du streaming temps réel, ce n'est clairement pas adapté. Par contre, si vous produisez des assets une fois et qu'ensuite, vous les servez des milliers de fois, alors vous êtes exactement dans la cible.

En pratique, sur macOS M2 avec un corpus de test standard, zxc dépasse les ~12 000 Mo/s en décompression, contre ~5 600 Mo/s pour LZ4 --fast dans le même test. L'écart reste également hyper solide ailleurs : 1,8× sur ARM serveur (Google Axion) et 2× sur x86_64 (AMD).

Et l'API proposée par zxc ne s'arrête pas à un compresseur basique. En effet, un mode "seekable" permet d'accéder à n'importe quelle position d'une archive sans scanner le fichier depuis le début. Par exemple, vous packagez vos assets de jeux vidéo dans une seule archive zxc, et quand le joueur charge une texture précise, vous lisez directement le bon bloc, et pas tout le fichier.

Côté installation, c'est simple : brew install zxc sur macOS, apt install zxc sous Debian ou Ubuntu, pip install zxc-compress, npm install zxc, cargo add zxc-compress ou vcpkg install zxc sous Windows.

Des bindings officiels existent aussi pour Rust, Python, Node.js, Go et WASM et la communauté a aussi ajouté Nim et Free Pascal de son côté. Et comme c'est codé en C, y'a aucune dépendance lourde.

Sache que pour assoir la crédibilité du projet, zxc a été intégré dans lzbench et TurboBench, les deux outils de référence permettant de comparer les algos de compression. Et le paquet est déjà dispo dans les versions testing et unstable de Debian, ce qui veut dire que les mainteneurs ont validé le truc !

Bref, si vous gérez de la compression d'assets ou de firmwares dans votre pipeline, ça vaut le coup d'y jeter un oeil.

Merci à Bertrand pour l'info et chapeau pour le boulot !

Si vous utilisez Claude Code au quotidien, vous connaissez ce goût de sang qui vous monte dans la bouche lorsque, sans prévenir, cette putain de limite de quota imposée par Anthropic vous explose à la gueule ! Et le pire c'est que vous n'avez pas l'impression d'avoir fait grand chose.

En réalité, la vraie raison c'est surtout le "bruit" de toutes vos sorties shell. Un git log, un cargo test, un npm build... votre agent IA ingère tout ça comme du petit lait alors qu'il n'a besoin que d'une fraction pour comprendre ce qui se passe.

Breeef, c'est pas ouf quoi.

Heureusement pour vous RTK (Rust Token Killer) vient régler en partie ce problème. RTK c'est développé par un Français et c'est un proxy CLI en Rust qui s'intercale entre votre shell et votre agent IA, intercepte les commandes courantes et compresse leur sortie avant qu'elle n'atterrisse dans le contexte de votre agent.

Comme ça plutôt que de massacrer vos prompts ou de changer vos habitudes (et dieu sait que vous avez horreur de changer d'habitudes..lol), il attaque le bruit à la source grâce à 4 stratégies de compression : un filtrage du boilerplate, un regroupement des lignes similaires, une troncature intelligente et de la déduplication des répétitions.

Et tout ça s'intègre merveilleusement bien via un hook pour Claude Code, GitHub Copilot, Cursor, Gemini CLI, Windsurf, Cline, Codex... soit une bonne dizaine d'outils supportés !

Ainsi, votre git status devient rtk git status sans changer quoi que ce soit à vos habitudes... RTK fait tout le filtrage dans votre dos, ce qui est parfait ! C'est un outil qu'on installe et qu'on oublie.

Par exemple un git diff passe de 12 000 tokens à 960, soit 92% d'économie, un npm test tombe de 6 000 à 600 tokens et une session de refactoring sur 12 fichiers passe de 74 700 à 6 960 tokens d'après les benchmarks. En pratique, les utilisateurs constatent des économies autour de 70% sur l'ensemble d'une journée de boulot, ce qui représente plusieurs millions de tokens par semaine pour ceux qui bossent avec des agents IA à plein régime.

Moi ça fait plusieurs mois que je le teste et voici mes stats. Ça donne quand même 81,5 % d'économie de tokens !!

L'installation se fait en une commande : brew install rtk sur macOS, ou un script curl pour les autres plateformes, ou cargo install --git https://github.com/rtk-ai/rtk si vous préférez compiler ça vous-même.

Avec la commande rtk gain vous verrez un tableau comme ci-dessus avec les statistiques par commande, et rtk gain --history donnera l'historique détaillé. Y'a plus de 100 commandes couvertes, de git aux runners de tests en passant par AWS CLI, kubectl et docker. Par contre, ça marche pas super bien si vos sorties de commandes sont déjà très courtes. Ça ne fera pas de miracle mais pour des diffs volumineux ou de suites de tests qui crachent 3 000 lignes à chaque fois, c'est tip top !

Si vous utilisez des agents en mode autonome où une boucle tourne sans intervention, c'est même encore plus pertinent car chaque itération accumule du bruit de façon cumulative, et du coup le contexte se remplit de trucs inutiles à vitesse grand V. Moins de bruit grâce à RTK, c'est donc une économie de tokens mais c'est également un meilleur signal pour votre agent.

RTK est dispo en open source sur GitHub sous licence Apache 2.0.

Flash à sa grande époque c'était quand même tout un truc, mais est-ce que vous vous souvenez de Shockwave ? Le grand frère de Flash (techniquement c'était une autre techno bâtie sur Director mais bref...), qui était capable de faire tourner des trucs bien plus complexes que les vieux .swf ?

Et ben l'équipe derrière DirPlayer s'est tapé tout le reverse-engineering du moteur Director from scratch pour le ressusciter grâce à Rust et le rendre à nouveau fonctionnel dans nos navigateurs modernes !

Faut savoir qu'Adobe a débranché Shockwave Player en avril 2019 et Flash un peu plus tard, et avec eux c'est un pan entier du web rétro qui s'est retrouvé inaccessible du jour au lendemain. Du genre tous ces jeux qui tournaient sur Shockwave.com ou les vieux portails de mini-jeux des années 2000, paf, d'un coup plus moyen d'y rejouer.

Alors heureusement, pour Flash, y'a déjà Ruffle qui fait tourner les bons vieux .swf. Hé bien ici c'est le même principe avec DirPlayer pour les .dcr Shockwave.

L'outil se décline sous 3 formes. D'abord une extension Chrome qui détecte automatiquement les balises Shockwave qui traînent encore sur les vieux sites web, ce qui peut être sympa pour redécouvrir des sites des années 2000.

Y'a aussi une version standalone construite avec Electron qui embarque carrément un debugger Lingo (le langage de scripting de Director, super pratique si vous voulez bidouiller du contenu existant). Et enfin un polyfill JS auto-contenu qui réécrit les et directement sur votre site web.

Perso, pour vous faire une idée, je vous invite surtout à jeter un oeil à la démo web pour tester rapidement parce qu'il n'y a rien à installer. Mais dès que vous voudrez analyser ou debugger un vieux jeu en profondeur, faudra plutôt opter pour la version standalone.

Notez que DirPlayer utilise Ruffle en submodule Git donc les 2 projets sont liés et bonus côté sécurité, le tout tourne en WebAssembly avec le sandboxing du navigateur, donc y'aura plus toutes ces failles qu'on pouvait retrouver à l'époque sur l'ancien plugin Shockwave Player.

Pour les sites qui hébergent encore des applis ou des jeux Shockwave (genre archive.org, avec des musées interactifs ou des jeux des années 2000), c'est une nouvelle corde à leur arc. Et si vous avez de vieux .dcr planqués sur un disque dur, la démo web devrait pouvoir les avaler aussi (faudra tester quoi...).

Bref, grâce à Ruffle pour Flash et DirPlayer pour Shockwave, le web des années 90-2000 n'est pas encore tout à fait mort ! Un peu comme moi finalement ^^

Ouais, je sais, on est le 1er mai, et je suis pas censé bosser mais que voulez-vous on ne se refait pas ^^. Et si j'ai ouvert l'ordi ce matin, c'est pour vous parler de KULA !

KULA est un binaire tout simple qui permet de monitorer très facilement votre serveur Linux en temps réel, sans aucune dépendance. c0m4r , le dev derrière le projet, l'a codé en Go avec une obsession claire : Que ça marche partout sans rien installer à côté !

C'est vrai que les outils de monitoring temps réel sur Linux ont tendance à grossir avec le temps. Netdata est passé par exemple d'un script léger à une plateforme SaaS.

KULA veut faire exactement l'inverse ! Parce que si vous avez un VPS à 5 balles, un Raspberry Pi ou trois homelabs qui ronronnent dans le placard, c'est pas la peine de sortir un bazooka quand il y a ce petit binaire qui fait tout aussi bien.

Vous le posez sur la machine, vous lancez ./kula, et c'est plié ! Il y a même un installeur guidé en une commande (nia nia nia lisez le contenu du .sh avant de le lancer, nia nia nia, je me répète, je sais):

bash -c "$(curl -fsSL https://raw.githubusercontent.com/c0m4r/kula/refs/heads/main/addons/install.sh)"

Côté technique, le projet va chercher ses infos directement dans /proc et /sys toutes les secondes. Comme ça y'a pas besoin d'un programme "agent" séparé à installer, ni besoin de vous lancer dans du scraping HTTP. C'est juste KULA qui tourne en daemon et qui lit ce qui se passe au niveau du kernel.

Les données passent ensuite dans un moteur de stockage maison : un ring-buffer avec trois niveaux (1 seconde brut, 1 minute agrégé, 5 minutes agrégé), chacun ayant une taille max fixe (250 Mo, 150 Mo, 50 Mo par défaut). Et quand la limite est atteinte, les nouvelles données écrasent les vieilles. Comme ça l'usage disque est maîtrisé, et y'a pas besoin de faire de ménage.

Niveau métriques, c'est plutôt complet je trouve... CPU, GPU (VRAM, charge, conso), mémoire, swap, load average, processus par état, températures CPU/GPU/disque, batteries, entropie système, sync horloge. Le réseau remonte les débits par interface, les paquets par seconde, les erreurs, les drops, les retransmissions TCP, les connexions établies...etc.

Et côté disque c'est par composant : IOPS, lectures/écritures par seconde, octets/s, plus l'usage des systèmes de fichiers. Et bien sûr tout ce qui est containers Docker, podman, et même ces cgroups bruts dont vous êtes si fiers ^^, pour ceux qui font tourner des trucs sans Docker.

Et le truc auquel je ne m'attendais pas mais que j'aurais pu anticiper parce que c'est à la modeuuuuh, c'est l'assistant IA via Ollama. Vous configurez une instance Ollama locale, et le dashboard vous laisse causer à un modèle de votre choix qui peut analyser les courbes en cours, exporter du CSV par graphique, et même faire appel à une fonction get_metrics pour interroger les données en mode agent.

Tout ça en local bien sûr. C'est plutôt sympa pour debugger par exemple un pic de CPU récurrent à 3h du matin sans devoir vous taper des heures de graphes !

Le déploiement Docker c'est comme ça :

docker run -d --name kula --pid host --network host
 -v /proc:/proc:ro -v kula_data:/app/data c0m4r/kula:latest

Notez le paramètre --pid host et /proc:/proc:ro : car KULA a besoin de voir l'hôte et pas le container.

Bah ouais, c'est logique, sinon il va monitorer juste son propre container, ce qui n'a aucun intérêt, hein...

Notez que si vous êtes sur un VPS LXC mutualisé bas de gamme, certains hébergeurs restreignent l'accès à /proc du host... et là, malheureusement, KULA ne pourra remonter que ce qu'il voit ce qui est souvent pas grand-chose... sniiif.

Pour les puristes, y'a aussi des paquets .deb, .rpm, AUR pour Arch, et du multi-arch (amd64, ARM, RISC-V). Ça couvre à peu près tout ce qui se croise sur un homelab !

Et côté auth, c'est désactivé par défaut (le port par défaut est le 27960, pas le 80), mais quand vous l'activerez vous tomberez sur de l'Argon2id avec des jetons de session hashés en base.

Par contre, même si y'a quelques alertes internes (clock sync, low entropy, overload), vous n'aurez pas de notifications natives (pas de mail, ni Slack, ni webhook...etc). Et pas de support multi-node non plus puisque KULA monitore une machine à la fois.

Donc si vous avez 30 serveurs, faudra vous farcir 30 instances et 30 dashboards séparés. Pas glop ! Et bien sûr, c'est Linux only parce que tout repose sur /proc et /sys.

C'est encore un projet un peu jeune, donc à voir comment ça vieillit mais pour votre petit VPS perso d'amour ou une machine dans un setup d'auto-hébergement , c'est top pour esquiver à la fois htop qui est trop minimaliste et Grafana qui est trop usine à gaz.

Si vous voulez voir la démo, y'en a une ici : demo.kula.ovh !

Source

Monter un serveur HTTPS local pour bosser sur du Next.js ou du Vite, ça reste étrangement chiant. Faut mkcert pour générer les certifs, faut éditer le /etc/hosts à la mimine, installer caddy ou nginx en reverse proxy par-dessus... bref, vous voyez le diiiiliiiire ! Heureusement, Kamran Ahmed , le mec derrière roadmap.sh, vient de balancer Slim , un binaire Go standalone qui fait tout ça d'un coup.

Et tant qu'à faire, il rajoute aussi des tunnels publics à la ngrok au cas où vous voudriez présenter votre travail de dev payé au lance pierre, à un client pressé.

L'idée c'est donc de taper : slim start myapp --port 3000 et hop, votre app tourne OKLM en local sur le port 3000 et devient accessible via https://myapp.test avec un certif totalement valide reconnu à 100% par votre navigateur.

Ça permet d'esquiver tout config manuelle, puisque le binaire crée une autorité de certification locale (CA) dès le premier lancement, signe ensuite les certifs par domaine, et met à jour /etc/hosts tout seul, sans oublier de rediriger les ports 80/443 sur 10080/10443 sans même avoir besoin de root.

Et cette CA est ajoutée au trousseau du système, donc votre Chrome, Safari ou Firefox (ze best !!) la considèrent immédiatement comme légitime, sans alerte de sécurité. Du tout-en-un comme je l'aime quoi !

L'install se fait en une ligne (pensez à regarder comme d'hab le contenu du fichier .sh avant de le lancer, je ne le répéterais jamais assez) :

curl -sL https://slim.sh/install.sh | sh

slim start myapp --port 3000 --route /api=8080 --route /ws=9000

Datadog Labs vient de sortir pup , un outil CLI codé en Rust qui donne à vos agents IA un accès complet à leur plateforme. L'idée c'est que pendant que Vercel et AWS galèrent de ouf à rendre leurs trucs « agent-friendly », Datadog, lui, dégaine un outil dédié qui expose +200 commandes sur plus de 33 de leurs produits, du monitoring aux SLOs en passant par la sécurité et les incidents.

Côté install c'est du classique, brew tap datadog-labs/pack && brew install pup, puis pup auth login pour le flow OAuth2 avec PKCE.

Plus besoin comme ça de balader vos clés API à vie dans des variables d'env, même si le fallback DD_API_KEY reste là quand même pour d'éventuels cas "headless". Une fois loggué, vous tapez alors par exemple :

pup monitors list

pup metrics query --query="avg:system.cpu.user{*}" --from="1h"

Vous avez déjà voulu créer une appli desktop qui tourne sur Linux, Mac et Windows en même temps ? En Rust, c'était un peu compliqué jusqu'ici. Heureusement, Slint , créé par la société allemande SixtyFPS GmbH, propose une solution sympa !

L'idée, c'est de décrire votre interface dans des petits fichiers .slint (un genre de mini HTML/CSS pour appli native), et de brancher ça à du Rust, du C++, du JavaScript ou du Python. Comme ça, vous codez le visuel d'un côté, la logique de l'autre.

Et ce qui est encore plus cool c'est que leur runtime tient dans 300 KiB de RAM. A titre de comparaison, une appli Electron type Discord en bouffe plusieurs centaines de mégaoctets. Slint tourne donc aussi bien sur un Raspberry Pi, un microcontrôleur STM32, ou directement dans un navigateur via WebAssembly.

Par exemple, SK Signet, un fabricant sud-coréen leader sur le marché américain des bornes de recharge électrique, anime ses écrans tactiles 15 à 32 pouces avec. OTIV fait tourner ses trains autonomes dessus. WesAudio l'utilise également pour son plugin audio pro.

Donc c'est du sérieux et si vous voulez tester sans rien installer, direction SlintPad . Vous tapez du code, et le rendu apparaît dans le navigateur. Ensuite pour débuter un projet Slint en local, faudra faire un cargo install slint-lsp puis utiliser le template slint-rust-template dispo sur GitHub. 2 minutes de compilation plus tard et hop, vous avez votre première fenêtre.

Côté tarif, Slint est gratuit pour les projets open source et gratuit aussi pour les applis desktop, mobile ou web même propriétaires. Seul l'embarqué propriétaire est payant. Donc pour la majorité des gens, c'est gratos.

Le revers de la médaille c'est qu'il faudra apprendre un nouveau langage de description, et la bibliothèque de boutons et menus prêts à l'emploi est moins fournie qu'un Qt qui a 30 ans d'avance derrière lui. Mais ça vaut le coup d'essayer puis vu que tout le monde vibe code de toute façon, ça ne devrait pas vous poser trop de soucis.

Voilà, si vous bricolez vos propres outils sur Raspberry Pi ou que vous voulez juste une appli desktop ultra-légère sans embarquer un navigateur entier avec, c'est à regarder.

Merci Chrltc pour le lien !

Source : github.com/slint-ui/slint