Entre Notion qui vous enferme dans son cloud, Obsidian qui facture la synchro dans son cloud 48 dollars par an et Evernote qui est devenu l'ombre de lui-même... trouver un outil de notes qui tourne chez vous sans dépendre de personne, c'est devenu la quête du Graal. Mais heureusement, TriliumNext Notes coche à peu près toutes les cases.

C'est une appli de prise de notes hiérarchique, open source (AGPL-3.0), qui tourne en local ou sur votre serveur. Imaginez une arborescence de dossiers, sauf qu'au lieu de copier un fichier dans 3 endroits différents, vous le clonez. C'est juste un lien ce qui fait que votre doc "Setup Proxmox" existe à la fois dans "Homelab" et dans "Tutos Linux" sans bouffer un octet de plus.

L'interface de TriliumNext Notes avec son arborescence de notes

Côté fonctionnalités, accrochez-vous puisque ça embarque un éditeur WYSIWYG avec support Markdown, des notes de code avec coloration syntaxique, un canvas Excalidraw pour griffonner des schémas, des diagrammes Mermaid, mind maps, et même des cartes géo avec traces GPX ! Y'a aussi un calendrier, un Kanban, des tableaux, un Web Clipper pour capturer des pages web d'un clic, et un moteur de recherche full-text qui fouille dans toutes vos notes. Franchement, pour un truc gratuit, vous en avez pour votre argent (euuh ?).

Le premier réflexe, ce serait de se dire "encore un clone de Notion". Sauf que que nenni les rabats joie ! Car LE truc qui fait vraiment la diff par rapport à un Anytype ou un Notion, c'est la synchronisation maison. Vous posez une instance serveur sur votre NAS, votre Proxmox, ou même un Raspberry Pi (ça tourne dessus sans broncher), et hop, toutes vos machines se synchronisent via votre réseau.

Pour l'installer, vous avez l'embarras du choix. En desktop classique, un brew install --cask trilium-notes sur Mac, un winget install TriliumNext.Notes sur Windows, ou un Flatpak / .deb / .rpm sur Linux et c'est plié.

Mais le vrai kif, c'est de le poser sur un serveur pour synchroniser toutes vos machines. Avec Docker, ça donne :

docker run -d -p 8080:8080 -v ~/trilium-data:/home/node/trilium-data triliumnext/trilium

Simuler des clics, des frappes clavier, planifier l'extinction du PC ou prendre des screenshots en boucle, tout ça sans écrire une seule ligne de code... c'est ce que propose Tasket++ , un petit outil open source développé par un dev français.

En gros, c'est un planificateur d'actions utilisateur pour Windows 10 et plus. Vous définissez une liste d'actions (clic ici, tape ça, attends 5 secondes, ouvre ce fichier.exe), vous programmez le tout et hop, ça tourne en boucle sans que vous leviez le petit doigt. Le truc se lance au démarrage via une entrée dans la base de registre, ou via un raccourci .lnk sur le bureau et côté actions disponibles, c'est assez complet pour un outil qui pèse à peine 30 Mo.

Vous avez les séquences de touches avec gestion des délais entre chaque touche (pas mal pour simuler une frappe humaine plutôt qu'un copier-coller robotique), les déplacements de curseur pixel par pixel, le collage de texte, et surtout toute une batterie de commandes système : éteindre le PC via shutdown -s, redémarrer, tuer un processus avec taskkill, ouvrir un fichier ou une URL, créer ou supprimer des dossiers, et même prendre des captures d'écran automatiques en .png.

D'ailleurs, le coup des screenshots planifiés au démarrage, c'est un use case assez malin pour surveiller l'activité d'une machine ou pour fabriquer un timelapse de votre bureau !

Et sinon OUAIS, ça peut aussi simuler votre présence devant le PC. Des mouvements de souris, des clics, des frappes clavier... du coup si votre logiciel de monitoring corporate vous casse les pieds pendant la pause café, bon bah, vous savez ce qu'il vous reste à faire (j'ai rien dit ^^). Attention par contre, si votre boîte utilise un vrai EDR ou un agent qui checke les processus actifs, ça risque de pas suffire. Ce genre de monitoring va malheureusement souvent au-delà du simple mouvement de souris.

Cet outil c'est l'œuvre d'Amir Hammoutene, ingénieur dev basé en région parisienne, qui bosse dessus depuis février 2024. Pour les curieux qui connaissent Actiona , c'est dans la même veine, sauf que Actiona c'est plus complet mais faut toucher à du scripting, alors que Tasket++ c'est 100% GUI, y'a qu'à cliquer.

L'interface ne paie pas de mine (on est sur du Qt classique, pas du Material Design), mais bon, elle fait le taf ! Vous créez vos tâches dans des onglets, vous empilez vos actions dans l'ordre, et vous lancez sur votre machine.

Les fichiers de tâches sont alors sauvegardés en .scht dans un dossier saved_tasks/. Ce qui manque le plus je trouve c'est les raccourcis globaux pour déclencher une tâche depuis n'importe quelle appli, genre pendant un jeu. Mais c'est justement prévu dans les prochaines versions, avec aussi des alertes sonores et un portage Linux. Par contre, pour le moment c'est Windows only, et sauf si vous compilez le code source vous-même avec Qt Creator, pas moyen de le faire tourner sur autre chose.

C'est dispo gratuitement sur le Microsoft Store , ou en version portable (un .zip de 30 Mo à décompresser dans mon dossier, pas d'install).

Bref, si vous cherchez un truc simple pour automatiser vos actions quotidiennes sans vous farcir du scripting, allez jeter un oeil. Merci à Amir pour le lien !

Si vous bossez avec le CI/CD de GitLab, y'a un angle mort que vous n'avez probablement jamais vérifié : La config de votre pipeline elle-même. Celle qui décide quelles images faire tourner et quels secrets exposer sans oublier les jobs à lancer. Et ça personne ne la scanne !

C'est d'ailleurs exactement cet angle d'attaque qu'ont choisi les pirates derrière l'attaque tj-actions en mars 2025, qui a touché plus de 23 000 organisations en modifiant simplement des tags de version. Ou encore l'attaque sur Trivy , où un scanner de sécurité s'est retrouvé lui-même vérolé. Le schéma est toujours le même : on s'infiltre comme Mario, par la tuyauterie et pas par la porte d'entrée.

Plumber que je vous présente aujourd'hui, est un outil open source en Go qui scanne votre .gitlab-ci.yml et les réglages de votre repo pour détecter les failles de configuration. Vous l'installez via Homebrew (brew tap getplumber/plumber && brew install plumber), vous lancez plumber analyze à la racine de votre projet, et il vous sort un rapport de conformité. 2 minutes chrono, même pas besoin de toucher à votre CI.

Plumber embarque 14 contrôles de sécurité qui couvrent les erreurs de configuration les plus courantes. Ça détecte les images Docker taguées latest (le classique qui traîne dans 80% des projets), les branches pas protégées, les curl | bash sans vérification, et même les jobs de sécurité qu'on a désactivés en douce avec un petit allow_failure: true. Vous savez, le réglage foireux qui fait que votre pipeline affiche tout vert... alors qu'il ne scanne plus rien du tout !

Côté output, Plumber génère une sorte de liste d'ingrédients de votre pipeline, un peu comme l'étiquette sur un paquet de bouffe mais pour votre chaîne de déploiement. Ça vous dit exactement quelles images, quels scripts et quelles dépendances tournent dans vos jobs. Le tout dans un format standard que d'autres outils de sécu peuvent digérer.

Pour l'intégrer directement dans votre pipeline GitLab, c'est 2 lignes :

include:
 - component: gitlab.com/getplumber/plumber/plumber@v0.1.30

J'sais pas si vous vous en rendez compte mais les agents IA qui codent sur votre machine ont accès à vos clés SSH, vos credentials AWS, votre Keychain et compagnie. Ils ont accès à TOUT ! C'est comme filer les clés de votre appart à un gars que vous avez croisé sur le parking de Leclerc y'a pas 5 min.

Hazmat prend le problème à l'envers : au lieu de demander poliment à l'agent de se tenir tranquille, il l'enferme dans un compte macOS séparé. Du coup, vos ~/.ssh, ~/.aws, votre Keychain deviennent structurellement inaccessibles. Pour en profiter, faut faire un

brew install dredozubov/tap/hazmat

cd /tmp

hazmat init --bootstrap-agent claude

Vous vous souvenez d'eMule ? Le petit âne qui monopolisait votre connexion ADSL pendant 3 jours pour télécharger un fichier de 700 Mo... et les fameux "Linux_ISO.avi" qui n'étaient absolument pas des ISOs Linux ?

Eh bien le bougre est de retour sur macOS. macMule c'est eMule packagé en .app native, compatible Apple Silicon via Rosetta 2, zéro configuration. Vous glissez dans Applications, vous lancez, et hop ça se connecte tout seul aux serveurs ed2k et au réseau Kad. Hé oui, ça tourne encore en 2026.

Côté technique, l'app fait environ 1 Go parce qu'elle embarque Wine Crossover (la couche de compatibilité Windows par Gcenx). Le développeur Martin Derouet a pris le build Community x64 d'eMule par irwir, l'a wrappé dans un bundle .app self-contained, et comme ça, ça se lance comme n'importe quelle app Mac.

Y'a pas de dépendances externes à installer, et surtout pas de terminal à ouvrir. Les fichiers téléchargés atterrissent alors dans ~/Library/Application Support/macMule/drive_c/eMule/Incoming/... c'est pas super intuitif comme chemin, mais au moins c'est rangé.

D'ailleurs, si vous avez suivi l'actualité de Wine 10.0 et le support ARM , vous savez que la couche de compatibilité Windows n'a jamais été aussi solide. macMule en profite directement. Et si vous voulez compiler votre propre build, le script est dispo : ./build.sh pour la dernière version stable ou ./build.sh 0.70b pour une version spécifique. Faut juste avoir Homebrew avec wine-crossover et Rosetta 2 installés.

J'ai été surpris que les réseaux ed2k et Kad soient encore debout. Mais c'est cool car ces réseaux hébergent des fichiers qu'on ne trouve nulle part ailleurs. Des archives oubliées, des vieux logiciels, des trucs que personne n'a jamais re-uploadé nulle part. C'est un peu le grenier d'Internet, poussiéreux mais plein de trésors pour qui sait chercher et plein de malwares aussi, alors gaffe à vous !

Attention quand même, ça reste un client P2P pour le réseau ed2k donc les précautions habituelles s'appliquent. Vérifiez ce que vous téléchargez, et n'oubliez pas que l'Arcom (ex-Hadopi) veille toujours au grain.

Bref, si vous avez la nostalgie du petit âne et que vous êtes sur Mac, c'est par là !

Merci à Martin pour la découverte !

Le noyau Linux 7.1 devrait supprimer la possibilité de compiler un noyau pour les processeurs Intel 486. C'est la première fois depuis 2012 qu'une architecture processeur est retirée du noyau, et le minimum requis passera du 486 au Pentium. L'Intel 486 a 37 ans.

Un processeur de 1989

L'Intel 486 est sorti en 1989. C'est le processeur qui a fait passer les PC de la ligne de commande au monde graphique, et il a été vendu pendant une bonne partie des années 90.

Le 486SX, sa version sans coprocesseur mathématique, et l'AMD Elan, une variante embarquée, sont aussi concernés par cette suppression. Le patch a été proposé par Ingo Molnar, un des développeurs historiques du noyau Linux.

La dernière fois que Linux a retiré le support d'une architecture processeur, c'était en 2012, quand le 80386 avait été abandonné. Ca fait donc 14 ans que personne n'avait touché à ce genre de nettoyage.

Du ménage dans le code

Le patch supprime trois options de configuration du noyau : M486, M486SX et MELAN. Sans ces options, il ne sera plus possible de compiler un noyau Linux spécifiquement pour un 486. Le processeur minimum deviendra le Pentium, qui supporte les instructions TSC et CMPXCHG8B, deux fonctions que le 486 ne gère pas.

Molnar explique que le code de compatibilité pour ces vieux processeurs pose régulièrement des problèmes et demande du temps de maintenance que les développeurs préfèrent consacrer à autre chose. Linus Torvalds avait d'ailleurs déclaré dès 2022 que les processeurs 486 n'étaient plus utilisés que comme pièces de musée.

Et le 32 bits, alors ?

Le retrait du 486 ne veut pas dire que Linux abandonne le 32 bits. Le noyau continue de supporter les architectures 32 bits, et il y a encore suffisamment de processeurs Atom et de systèmes embarqués 32 bits en circulation pour que ça reste le cas un moment.

Mais la tendance est claire : l'avenir de Linux sur x86 est en 64 bits, et le code 32 bits finira par suivre le même chemin que le 486.

Aucune distribution Linux récente ne proposait de toute façon un noyau compilé pour 486. Les utilisateurs qui font tourner Linux sur ce type de matériel pourront continuer avec des noyaux plus anciens.

Ca concerne très peu de monde en pratique, mais c'est quand même un petit moment d'histoire informatique. Le 486 a été le premier vrai processeur grand public chez Intel, et le voir disparaître du noyau Linux après 37 ans de bons et loyaux services, ça fait quelque chose.

En tout cas les développeurs du noyau semblent soulagés de pouvoir enfin faire le ménage. Pour la petite histoire, mon premier PC était un 386 SX25, et je suis ensuite passé directement au Pentium 60 (celui qui avait le bug de la virgule flottante), je trouve ça dingue qu'avec tous les ordinateurs que j'ai eu chez moi, je n'ai jamais eu de 486 !

Source : Phoronix

Le système de distribution d'applications Linux vient de publier la version 1.16.4, qui corrige quatre failles de sécurité découvertes dans son mécanisme de bac à sable.

La plus critique permettait à une app de sortir de son environnement isolé pour accéder à tous les fichiers de la machine et y exécuter du code. Le Steam Deck et la plupart des grandes distributions sont concernés.

Quatre failles, dont une critique

Flatpak, c'est le format de distribution d'applications qui s'est imposé sur Linux ces dernières années. Son principe : chaque application tourne dans un bac à sable isolé du reste du système, un peu comme sur iOS. C'est aussi le format utilisé par le Steam Deck de Valve pour installer des applications en mode bureau.

La version 1.16.4, publiée le 7 avril, corrige quatre failles de sécurité. La plus grave, référencée CVE-2026-34078, est une vraie mauvaise surprise : une application pouvait exploiter des liens symboliques dans les options d'exposition du portail Flatpak pour accéder à l'intégralité des fichiers de la machine hôte, et même y exécuter du code.

Des fichiers supprimés et des téléchargements détournés

La deuxième faille (CVE-2026-34079) permettait de supprimer des fichiers sur la machine hôte en passant par un bug dans le cache du chargeur dynamique ld.so. Flatpak supprimait les fichiers de cache obsolètes sans vérifier que le chemin fourni par l'application pointait bien vers le bon répertoire.

Deux autres problèmes ont aussi été corrigés : l'un permettait de lire des fichiers via le service système de Flatpak, l'autre de perturber le téléchargement d'une application lancé par un autre utilisateur, sans possibilité de l'arrêter proprement.

Qui doit mettre à jour

Toutes les distributions Linux qui utilisent Flatpak sont concernées, et c'est un paquet de monde : Fedora, Ubuntu, Linux Mint, SteamOS sur le Steam Deck, et bien d'autres.

La mise à jour vers la version 1.16.4 est disponible, ou le sera très vite, via les canaux habituels de chaque distribution. Si vous utilisez un Steam Deck en mode bureau avec des apps Flatpak installées via Discover, la mise à jour devrait arriver automatiquement.

C'est quand même un comble : un système conçu pour isoler les applications qui laisse une porte grande ouverte vers tout le système. Que Flatpak se fasse prendre en défaut sur son coeur de métier, ça fait un peu désordre.

Bon par contre, la réactivité a été bonne : la faille a été identifiée et corrigée, et les détails n'ont été publiés qu'avec le correctif disponible. C'est la base, mais au moins c'est fait.

Source : Phoronix

Quand je vois tout le taf que j'ai à la maison, je vous avoue que je rêve d'un robot qui vide le lave-vaisselle, arrose les plantes et ramasse le linge pendant que moi je glandouille sur le canapé (ou que je bosse parce que je glandouille jamais en fait...Argh...). Hé bien bonne nouvelle, une équipe de chercheurs de NYU vient de publier les plans complets pour en construire un et tout ça en open source pour environ 9 200 dollars !

YOR, pour " Your Own Robot ", c'est un robot mobile avec deux bras articulés, une base sur roues qui se déplace dans tous les sens, et un lift télescopique qui est tout simplement... un vérin de bureau debout. Du coup le robot peut descendre à 60 cm du sol pour ramasser vos chaussettes et monter à 1,24 m pour atteindre un placard en hauteur. Et le vérin se verrouille tout seul en cas de coupure de courant (comme ça, pas de bras qui s'écrasent au sol...).

Le coût total des composants revient comme je vous le disais à environ 9 200 dollars. Les deux bras représentent à eux seuls plus de la moitié du budget (5 000 dollars), la base roulante un bon quart (2 700 dollars). Le reste, c'est de l'électronique grand public et des profilés alu et le cerveau, c'est un Raspberry Pi 5 avec 16 Go de RAM. Quand on sait qu'un Mobile ALOHA (le robot de Stanford) revient à environ 32 000 dollars et que les plateformes commerciales dépassent les 100 000... y'a pas photo !

YOR et ses deux bras articulés sur base omnidirectionnelle

Un truc original dans ce robot, ce sont les pinces. L'équipe a d'ailleurs conçu des grippers custom capables de manipuler des objets délicats ou de serrer fort ce qui est bien utile et y'a aussi une caméra stéréo sur la tête pour que le robot cartographie son environnement et se repère tout seul dans une pièce.

Pour le piloter, pas besoin de matériel exotique puisque des manettes Meta Quest 3 suffisent. Vous restez debout derrière le robot et vous contrôlez tout, les bras, la base, la hauteur. Et le truc cool, c'est que quand vous déplacez la base, les pinces restent stables sur l'objet qu'elles tiennent. Cela lui permet par exemple d'attraper une assiette et de se déplacer vers le lave-vaisselle sans tout faire valdinguer.

YOR en action : lave-vaisselle, arrosage et ramassage

Côté recherche, l'équipe est même allée encore plus loin. En pilotant le robot à la main une centaine de fois (avec des iPhones fixés sur les pinces comme caméras supplémentaires), ils ont entraîné une IA capable de reproduire les gestes toute seule. Résultat, 9 réussites sur 10 dans un test de tri des déchets en autonomie (la poubelle JAUNE !!!!), du genre donc attraper un carton avec les deux bras, le soulever, contourner un obstacle, le déposer dans la poubelle de tri... et tout ça sans intervention humaine. Et bien sûr, si vous voulez tester vos propres algos avant de risquer du vrai matos, y'a un simulateur pour ça.

L'empreinte au sol de cette bestiole fait 43 × 34,5 cm. En gros, la taille d'un carton à pizza. Le projet est porté par une équipe de NYU et UC Berkeley et parmi les auteurs, on retrouve Soumith Chintala (NYU), le co-créateur de PyTorch. Toute la doc de construction est dispo sur build.yourownrobot.ai , avec la liste complète des composants en Google Sheets, les modèles CAD et le code Python sous licence MIT sur GitHub .

YOR face à la concurrence : petit, pas cher, open source

J'ai rarement vu un projet aussi bien documenté pour ce niveau de complexité mais attention quand même, ça reste un projet de recherche, et pas un kit Lego. Faut savoir souder, câbler des batteries, et être à l'aise avec Python et Git. C'est donc un sacré projet de plusieurs week-ends (comptez plutôt des mois si vous débutez). Mais c'est aussi ça qui est cool, puisque vous construisez VOTRE robot, et pas celui d'un constructeur chinois que vous avez payé une couille en dropshipping.

Si les robots open source vous branchent, le ToddlerBot à 4 300 dollars propose également une approche bipède imprimable en 3D, et si vous voulez voir ce que la coordination bimanuelle donne à l'échelle industrielle ... y'a du choix.

Bref, 9 200 dollars, licence MIT, la liste complète des composants, ça fait grave envie !! En tout cas, c'est le genre de projet à suivre de prêt...

Pour la partie impression 3D du châssis, si vous n'avez pas encore d'imprimante, une Creality Ender-3 V3 fera l'affaire pour les pièces structurelles, et un Raspberry Pi 5 est au cœur du projet. (liens affiliés)

Source

Bon, j'ai la crève et y'a du bricolage qui m'attend, du coup aujourd'hui y'aura pas des centaines d'article. Mais faut quand même que je vous parle de Hister , le nouveau projet d'Adam Tauber (le créateur de Searx ) qui indexe localement tout ce que vous visitez sur le web pour le retrouver en texte intégral.

Vous installez l'extension Chrome ou Firefox, vous lancez le binaire Go sur votre machine (ça tourne sous Linux, macOS et Windows), et hop, chaque page que vous visitez est indexée en full-text. Du coup, quand vous cherchez ce tuto que vous aviez lu y'a 3 semaines mais dont vous avez zappé l'URL, vous ouvrez l'interface web locale de Hister, vous tapez un mot qui était dans le contenu de la page et ça ressort ! Si vous aviez testé Deeper History à l'époque, c'est le même concept mais en beaucoup plus costaud.

L'interface de Hister - sobre mais efficace

Sous le capot, Hister utilise blevesearch, un moteur d'indexation en Go qui gère le fuzzy matching et les requêtes booléennes. En gros, vous tapez "configuration nginx reverse proxy" et ça vous ressort cette page de doc que vous aviez consultée y'a un mois, même si vous ne vous souvenez que de 2 mots. Efficace donc. Et l'outil capture les pages telles qu'elles étaient au moment de votre visite donc si un site modifie son contenu ou si un article disparaît, vous aurez toujours la version d'origine. Y'a même un mode aperçu hors-ligne pour consulter ces snapshots sans connexion !

Côté vie privée (forcément, quand ça vient du mec qui a pondu Searx déjà en 2013... le temps file les amis ^^), tout reste sur votre machine. Et pour les domaines sensibles comme votre banque ou votre mutuelle, une blacklist permet même d'exclure certains sites de l'indexation. Enfin pour ceux qui ont déjà des années de navigation derrière eux, la commande hister import aspirera votre historique Chrome ou Firefox existant, comme ça pas besoin de repartir de zéro.

Pour installer ça, téléchargez le binaire depuis les releases GitHub , puis lancez le serveur et installez l'extension ( Firefox ou Chrome) qui va bien. Y'a aussi un Docker Compose pour ceux qui préfèrent tout conteneuriser. Prévoyez aussi quelques Go sur le disque pour la base d'index car ça se rempli vite...

Tauber dit avoir réduit sa dépendance à Google de moitié en un mois et demi juste avec ça. Et je trouve ça logique parce que quand vous avez déjà visité la bonne page une fois, ça ne sert plus à rien de redemander à Google de vous la remonter entre 3 pubs et une réponse IA à côté de la plaque. Autant récupérer ce que vous aviez déjà !

Voilà, je suis sûr que ça va vous plaire... Et si vous voulez tester avant d'installer quoi que ce soit, une démo tourne en ligne.

Allez, je retourne bricoler...

Cloudflare qui sort un successeur open source à WordPress le 1er avril, je vous avoue que ça sentait le poisson d'avril à plein nez. Sauf que non !! EmDash est bien réel, son code est sur GitHub sous licence MIT, et ça s'installe en une commande toute simple !

L'idée de base pour Cloudflare, c'est de dire que WordPress a plus de 20 ans et bien qu'il alimente 40% du web, son architecture de plugins est un emmental (Le gruyère n'a pas de trou les amis ^^). En effet, 96% des failles de sécurité viennent des extensions et pas du noyau PHP ni des thèmes et en 2025, on a quand même explosé le record de failles dans l'écosystème WP.

Du coup Cloudflare, grand prince (Matthew ^^ Ok, je sors...) a tout repris de zéro en TypeScript et avec l'aide de nombreux agents IA. Et de ce que j'ai compris, le gros morceau de ce projet, visiblement, c'est l'isolation des plugins.

Car sur WordPress, une extension a accès à toute la base de données et au système de fichiers (d'où l'importance de bien les choisir ). Alors que sur EmDash, chaque plugin tourne dans son propre isolat avec un modèle de capacités déclaratives. En gros, le plugin annonce dans un fichier manifeste JSON ce dont il a besoin, genre read:content ou email:send, et il ne peut rien faire d'autre. S'il veut accéder au réseau, il doit même préciser le hostname exact. Comme ça fini les extensions qui aspirent vos données en douce. Par contre, ça veut aussi dire que vos plugins WordPress actuels ne marcheront pas tels quels...

Côté stack, c'est comme je disais du TypeScript de bout en bout avec Astro 6.0 en frontend (pour les thèmes) et Node.js derrière. L'auth passe également par des passkeys par défaut (enfin, plus de mots de passe !) et y'a même un système de paiement natif via le standard ouvert x402 pour monétiser du contenu.

Et le truc qui va vous rassurer si vous êtes allergique au cloud : c'est auto-hébergeable. En fait, le CMS peut tourner sur Cloudflare Workers, mais aussi sur n'importe quel serveur Node.js avec SQLite. Les abstractions sont portables, avec Kysely pour le SQL et l'API S3 pour le stockage. Du coup vous pouvez brancher PostgreSQL, Turso, AWS S3, ou tout bêtement des fichiers en local. Le bonheur !

Le truc cool pour les bidouilleurs, c'est que chaque instance expose un serveur MCP (Model Context Protocol) et une CLI pour piloter le CMS par script. Y'a aussi des Agent Skills pour que les agents IA puissent créer du contenu, gérer les médias et modifier le schéma sans toucher au dashboard. C'est clairement pensé pour l'ère des agents IA.

Et pour ceux qui veulent migrer depuis leur WordPress, c'est prévu pour vous faciliter la tâche puisqu'il y a le support d'export WXR classique ou via un plugin dédié qui crée un endpoint sécurisé protégé par mot de passe. Que ce soient les médias, les custom post types...etc tout est transférable en quelques minutes. Par contre, attention les shortcodes et les blocs Gutenberg custom ne passeront pas tels quel, faudra faire des ajustements.

Car oui c'est une v0.1.0 preview, donc on peut le dire, une bonne grosse beta qui bave mais je trouve ça super cool car le drama WP Engine vs WordPress a montré que l'écosystème était fragile, et c'est bien de réintroduire un peu de diversité. Par contre, remplacer un CMS qui fait tourner 40% du web, c'est hyper ambitieux et ça se fera pas en un trimestre. Car la vraie force de WordPress, c'est sa communauté, ses milliers de plugins et de thèmes, et ça pour le moment, y'a pas grand chose sur EmDash.

M'enfin, si vous voulez tester c'est npm create emdash@latest et c'est parti mon kiki. Ah et y'a aussi un playground sur emdashcms.com pour vous faire une idée sans rien installer. Pour ma part, je testerai ça dès que j'aurais 5 min, mais pour le moment, je ne me vois pas quitter WordPress car EmDash n'a pas (encore) ce petit truc en plus qui me ferait changer... On verra d'ici quelques temps.

Source

Et si je vous disais qu'on pouvait faire tourner Firefox dans un terminal ? Et pas un navigateur en mode texte, hein. Non, le véritable Firefox, avec ses onglets, les images, la totale... Hé oui c'est possible et que ça fonctionne via SSH, donc depuis un serveur distant. Bienvenue dans le futur (ou le passé, j'sais plus trop) !

Term.everything c'est un compositeur Wayland construit from scratch en Go qui, au lieu de balancer l'image sur votre écran, la convertit en caractères ANSI et l'affiche dans le terminal. Du coup, n'importe quelle app GUI Linux peut tourner là-dedans. Firefox, un gestionnaire de fichiers, un lecteur vidéo... et même Doom (parce que si ça peut pas faire tourner Doom, ça compte pas). Le binaire fait une poignée de Mo, c'est sous licence AGPL-3.0, et y'a zéro dépendance externe.

L'outil propose 2 modes d'affichage. Le mode basique qui convertit les pixels en blocs Unicode, et dont la qualité dépend du nombre de lignes et colonnes de votre terminal. Plus vous zoomez out (Ctrl+- sur Alacritty), plus c'est net... mais plus ça rame. Donc si votre terminal supporte le protocole image, genre Kitty ou iTerm2, l'autre mode, c'est du rendu pleine résolution et là non seulement c'est pas dégeu mais en plus ça marche bien !

Le truc vraiment dingue, c'est surtout le SSH parce que si vous avez un serveur Linux distant, vous vous connectez dessus en SSH, vous lancez term-everything firefox et hop, Firefox s'affiche dans votre terminal local. Pas de X11 forwarding relou à mettre en place ni de VNC / RDP zarbi.

Pour les admins sys qui gèrent des serveurs headless, c'est quand même sympa ! D'ailleurs si vous aimez les outils SSH bien pensés , celui-ci aussi va vous plaire.

Par contre, on est encore en bêta et certaines apps vont planter ou refuser de se lancer. C'est normal, c'est un compositeur Wayland complet écrit par un seul gars (chapeau l'artiste !). Ce n'est donc pas le genre de truc qu'on met en prod, mais pour du dépannage sur un serveur Debian distant ou juste pour la beauté du geste, ça envoie du pâté.

Le créateur de term.everything est d'ailleurs le même qui avait codé Fontemon , un jeu vidéo caché dans une police de caractères. On est donc clairement dans la catégorie "parce qu'on peut le faire et que c'est marrant".

Bref, si vous voulez épater vos collègues en lançant KDE dans un terminal par-dessus SSH, ou juste jouer à Doom dans tmux, c'est par là que ça se passe.

Amusez-vous bien et merci à Lorenper pour l'info !

Si vous êtes abonné Qobuz et que vous êtes sous Linux, vous connaissez cette douleur sourde qui vous coupe le souffle la nuit : IL N'Y A PAS DE CLIENT OFFICIEL ! Vous êtes donc condamné comme n'importe quel gueux à utiliser le lecteur web, qui est aussi "audiophile-phile" qu'un casque de chantier.

Mais heureusement, QBZ vient régler ça, et vous allez voir, c'est du sérieux !

Il s'agit d'un client natif et open source (sous licence MIT) écrit en Rust avec Tauri 2.0 côté desktop et SvelteKit pour l'interface, ce qui fait que c'est léger, que ça démarre vite, et surtout ça gère le bit-perfect via 4 backends audio au choix : PipeWire, ALSA, ALSA Direct (accès exclusif au DAC) et PulseAudio.

Le switching de sample rate se fait alors à la volée, de 44.1 à 192 kHz, selon ce que votre DAC supporte. Pour les audiophiles... bah ça change tout par rapport au resampling sauvage du navigateur. Ouf, on est sauvé en fait ^^

Côté fonctionnalités, c'est clairement loin du petit projet bricolé un dimanche soir en vibe coding puisque ce lecteur décode nativement FLAC, MP3, AAC, ALAC, WavPack, Ogg Vorbis et Opus, le tout avec du gapless playback et de la normalisation de loudness EBU R128. Je comprends pas tout parce que je suis pas expert là dedans, mais si vous aimez la Hi-Fi, je sais que ça vous parle.

Y'a aussi une gestion de bibliothèque locale avec scan de dossiers et indexation SQLite, et même un import de playlists depuis Spotify, Apple Music, Tidal ou Deezer. Ainsi, si vous migrez vers Qobuz, ça vous fera gagner des heures plutôt que de tout vous retaper à créer à la main !

Niveau intégrations, c'est aussi super complet : scrobbling Last.fm et ListenBrainz, enrichissement MusicBrainz, pochettes via Discogs, contrôle MPRIS et touches média. Et le casting vers Chromecast, DLNA/UPnP et AirPlay est intégré. Le Chromecast directement depuis un client Linux sans bidouille, c'est pas courant, et ça fait plaizzz !

L'interface est également hyper soignée avec 26 thèmes au choix (Dark, OLED, Nord, Dracula, Tokyo Night...) et 17 panneaux de visualisation dont un spectre, un oscilloscope et un spectrogramme. Y'a même un mode immersif plein écran, le tout dispo en 5 langues dont le français.

Pour l'installation, c'est packagé proprement : Flatpak, AUR, Snap, AppImage, DEB, RPM et même un DMG pour macOS (Apple Silicon, expérimental) et si vous êtes sur Arch, un petit yay -S qbz-bin et c'est réglé.

Par contre, il y a quelques limites à connaître comme le seeking sur des pistes hi-res au-dessus de 96 kHz qui peut prendre 10 à 20 secondes. ALSA Direct bloque aussi les autres applis audio (logique, c'est l'accès exclusif). Et le bit-perfect via PipeWire est limité quand on lance le tout en sandbox Flatpak. En fait, le problème c'est que la sandbox bloque l'accès direct au matériel donc si vous voulez le max de qualité, optez pour le paquet natif.

Si Qobuz est votre service de streaming et que Linux est votre OS préféré d'amour, les alternatives payantes comme Audirvana ou Roon ne sont clairement pas données. C'est pour cela que je vous parle de QBZ qui fait le boulot gratuitement comme un chef et dont le développeur (vicrodh) est super actif (il recherche des contributeurs si vous voulez l'aider).

Et un grand merci à Pierre pour le tuyau !

Vous vous souvenez de Civilization III ? Hé bien des fans ont décidé de le recréer de zéro en open source avec OpenCiv3 , et franchement ça a de la gueule, vous allez voir !

En fait, leur idée c'était pas juste de cloner le jeu de Sid Meier tel quel, mais plutôt de le réimaginer en corrigeant tous les trucs qui étaient cassés à l'époque, mais aussi en virant les limites arbitraires du moteur original et en poussant le modding aussi loin que possible. En gros, ils nous ont pondu un Civ3 comme il aurait dû être si les développeurs avaient eu le temps de tout finir.

Côté technique, c'est du Godot avec du C#, ça tourne sur Windows, Linux et Mac et c'est sous licence MIT. Du coup vous pouvez forker le truc et en faire votre propre version si ça vous chante.

Après, voilà, on est encore en pré-alpha. La version 0.3 "Dutch" est sortie en décembre dernier, et permet de lancer une partie, explorer la carte, créer des villes et taper sur vos voisins. Mais la fin du jeu n'est pas encore là. Et le truc sympa, c'est que contrairement à d'habitude, le jeu fonctionne en mode standalone avec des graphismes de remplacement, donc pas forcément besoin d'avoir Civ3 installé. Après si vous avez l'édition Conquests ou Complete qui traîne quelque part sur votre disque dur, OpenCiv3 est capable d'importer les graphismes originaux pour un rendu fidèle !

Mais comme vous l'avez compris, le vrai kiff du projet, c'est le modding. Le Civ3 original vous laissait modifier trois bricoles via des fichiers texte, et c'était pas ouf... Mais OpenCiv3, lui, veut ouvrir toutes les portes en changeant les règles de combat, en ajoutant des mécaniques de jeu, en créant des scénarios complets, voire en inventant de toutes pièces de nouvelles civilisations... bref tout est prévu pour être modifiable. Ça rappelle un peu ce qu' UnCiv fait avec Civ V sur Android , sauf que c'est sur PC.

Voilà, c'est encore super jeune mais si vous avez la nostalgie des soirées "encore un tour", ça vaut le coup de garder un œil dessus !

À découvrir ici : OpenCiv3

Si vous en avez marre de perdre vos recettes de cuisine dans des apps comme Whisk ou Paprika qui ferment tous les 6 mois, ou de devoir scroller 14 pages de storytelling avant d'arriver aux ingrédients... y'a un truc qui devrait vous plaire. Ça s'appelle Cooklang , et c'est un langage de markup pour écrire vos recettes en texte brut et les garder à vie !

En gros, vous créez un fichier .cook avec Notepad, Sublime Text ou votre terminal favori, vous écrivez votre recette en français normal et vous ajoutez quelques marqueurs type : @farine{200%g} pour un ingrédient avec sa quantité, #fouet{} pour un ustensile, ~{25%minutes} pour un minuteur.

Du coup, à partir de ce petit fichier texte, l'outil génère alors automatiquement la liste de courses, les minuteurs et un joli rendu lisible. Y'a pas de compte à créer, ni de serveur Notion à monter... C'est juste vos recette chez vous !

Et le truc vraiment sympa, c'est que la syntaxe reste parfaitement lisible même sans l'outil... en fait votre recette de carbonara reste une recette de carbonara, et pas un fichier XML avec 47 balises imbriquées. D'ailleurs si vous versionnez vos fichiers avec un Git, vous pouvez tracer l'évolution de vos recettes au fil du temps, pour voir par exemple quand vous avez décidé de mettre plus d'ail dans la marinade et pourquoi votre tarte aux pommes de 2024 était meilleure que celle de 2023.

La syntaxe Cooklang : lisible par un humain, exploitable par la machine

Côté écosystème, c'est très complet pour un projet open source et complètement gratuit ! Y'a un CLI écrit en Rust qui fait serveur web intégré ( la démo est ici ), des apps iOS et Android avec synchronisation, des plugins pour VS Code, Vim et Emacs (pour les puristes), un plugin Obsidian pour afficher vos recettes directement dans votre vault, et même un mode Raspberry Pi Zero pour héberger votre précieux livre de recettes familial sur le réseau WiFi local.

Comme ça, un petit cookcli server et tout le monde à la maison peut consulter les recettes depuis son téléphone. Par contre, attention, y'a pas de mode collaboratif en temps réel, c'est chacun son fichier... c'est pas Google Docs non plus.

Le système de mise à l'échelle est pas mal non plus. Quand vous triplez les quantités de votre blanquette pour le repas du dimanche, le sel et le poivre restent fixes (parce que non, on ne triple pas la quantité de pincées de sel quand on passe à 6 personnes). Sauf que ça marche pas pour tout : les temps de cuisson, faut quand même les ajuster vous-mêmes et si une recette dépend d'une autre, genre votre sauce hollandaise maison, vous pouvez la référencer directement dans votre préparation avec @./sauces/Hollandaise{150%g}.

D'ailleurs, y'a une astuce que je trouve carrément cool, c'est que si vous trouvez une recette en ligne qui vous plaît, vous pouvez coller cook.md/ devant l'URL et ça la convertit automatiquement au format Cooklang, prête à être intégrée dans votre collection de recette. Comme ça, pas besoin de tout retaper à la main comme un scribe du Moyen Âge !

Le projet existe depuis janvier 2021 et c'est sous licence MIT. Dans un monde (prenez une grosse voix grave) où chaque app de cuisine veut votre email, vos données et 5 euros par mois, la vraie résistance s'organise avec des fichiers texte de cuisine de 2 Ko qu'on peut ouvrir dans n'importe quel éditeur de texte , synchroniser via Syncthing ou balancer sur une clé USB.

Et si tout ce qui vous intéresse c'est uniquement la bouffe, il y a des recettes ici et des recettes là .

Bref, créez un fichier boeufbourguignon.cook, balancez-y votre recette avec les marqueurs et lancez cookcli server pour voir le résultat... il manque plus qu'un git blame pour savoir qui a mis trop d'oignons !

Merci à Fabien pour la découverte !

GNOME trop rigide, KDE Plasma trop usine à gaz, Xfce trop vintage... J'sais pas si vous êtes d'accord avec ça, mais c'est l'avis de ce développeur solo ultra acharné qui a décidé de tout refaire from scratch. Ça lui a pris 9 ans de boulot à coder du C++ sur le framework Qt, et à créer 48 composants modulaires pour fourer tout ça dans un environnement de bureau Linux, entièrement indépendant qui ne dérive d'aucun projet existant, qu'il a appelé Orbitiny Desktop !

Le truc chouette avec cet environnement de bureau, c'est sa modularité car chaque composant tourne dans son propre processus, ce qui veut dire que si le gestionnaire de fichiers plante, votre panneau et vos icônes de bureau restent en place. On est donc trèèèès loin du crash GNOME Shell qui vous renvoie sur l'écran de connexion en plein milieu d'un truc important !

Et le truc qui va plaire aux bidouilleurs, c'est que le bazar est 100% portable. Vous décompressez l'archive tar.gz de 185 Mo sur une clé USB, vous lancez le script start-orbitiny et hop, vous avez votre bureau perso sur n'importe quelle machine Linux. Tous les réglages sont sauvegardés dans le dossier d'extraction... du coup vous pouvez trimballer votre config partout avec vous. Et si vous préférez une installation classique, y'a aussi un script graphique install-orbitiny à lancer avec sudo.

Côté features, c'est plutôt fourni ! Orbitiny intègre son propre gestionnaire de fichiers (Qutiny), un presse-papier système, un gestionnaire de périphériques USB et un tableau de bord avec barre de recherche.

Le gestionnaire de fichiers gère la recherche par nom et contenu, la vue en double panneau et des trucs assez originaux genre le "File Join" qui permet de fusionner des fichiers texte par simple drag and drop, ou le "Image Join" qui colle des images entre elles verticalement. Y'a aussi un système de gestes de souris configurables sur le bureau (jusqu'à 12 tracés par bouton gauche ou droit), des bureaux indépendants par moniteur ET par bureau virtuel (chaque écran physique a son propre fond d'écran et ses propres raccourcis), et un panneau avec 18 applets qu'on repositionne par simple glisser-déposer, sans passer par un mode édition.

Le petit bonus sympa, c'est le support WINE et DOSBOX intégré. Vous balancez un .exe Windows sur le bureau ou dans le gestionnaire de fichiers et ça lance direct via WINE. Pareil pour les vieux programmes DOS via DOSBOX. Pas besoin de bidouiller des fichiers .desktop custom à la main (bon ok, faut quand même que WINE soit installé sur votre distro). Après ça ne marche pas forcément avec tous les programmes Windows non plus... va savoir pourquoi certains .exe passent et d'autres plantent. Les mystères de la vie !

Ah et j'allais oublier un truc : Orbitiny peut aussi tourner en mode overlay, c'est-à-dire par-dessus un autre environnement de bureau. Vous gardez votre GNOME ou votre KDE en dessous et vous superposez Orbitiny par-dessus pour profiter de ses fonctionnalités sans tout changer. C'est pratique pour tester sans engagement !

Le projet est sous licence GPLv2, disponible sur SourceForge et tourne sur toute distro Linux basée sur X11. Attention par contre, pas de support Wayland pour l'instant, c'est du X11 only, ce qui risque de poser souci à terme vu que Wayland remplace progressivement X11 sur Ubuntu, Fedora et compagnie. Oubliez pas non plus que c'est un projet d'un seul développeur, donc les mises à jour arrivent quand elles arrivent. Après si vous cherchez d'autres moyens de personnaliser votre bureau Linux , y'a de quoi faire.

Bref, 9 ans de boulot solo pour un environnement de bureau qui tient plutôt bien la route, faut quand même saluer l'effort !! Et un grand merci à François pour le partage !