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...

Ce tutoriel explique comment installer Sync-in sur un NAS Synology à l'aide de Docker, en effectuant le lien avec les données existantes sur le NAS.

Le post Comment installer Sync-in sur un NAS Synology ? a été publié sur IT-Connect.

Speedtest.net c'est pratique, sauf que ça a été racheté par Accenture en 2026 et chaque test envoie votre IP, le nom de votre FAI et votre localisation à leurs serveurs...

Alors pourquoi ne pas adopter LibreSpeed , l'alternative open source que vous hébergez chez vous, et qui ne contient aucun sans tracker ??? L'outil est signé Federico Dossena, ça a été lancé en 2016 et c'est sous licence LGPL v3. Et ce que ça mesure c'est la vitesse du download, de l'upload, le ping, le jitter , et ça relève aussi l'adresse IP et le nom de votre FAI.

Côté déploiement, c'est du classique. Vous déposez les fichiers sur votre serveur, dont speedtest.js et speedtest_worker.js pour le frontend, vous configurez le backend via config.json, et hop c'est lancé. Un simple VPS ou n'importe quelle autre machine sur votre LAN fera l'affaire.

Et comme vous choisissez le serveur de test, y'a pas de saturation par d'autres utilisateurs, pas de route réseau bizarre vers un data center à l'autre bout de l'Europe et surtout, les résultats sont parfaitement reproductibles donc pour les "homelabers" (c'est comme ça qu'on dit ?) ou les équipes réseau, c'est assez chouette.

Il y a aussi le mode multi-serveur pour comparer des endpoints, le partage de résultats via lien unique, et un CLI librespeed avec ses flags --server et --host pour les fans du terminal. Des backends officiels en Go et Rust existent aussi sur le github de librespeed , signe que le projet est sérieux.

Et surtout, les résultats sont fiables, sauf si votre serveur plafonne à 20 Mbit/s et dans ce cas, vous mesurerez sa liaison et pas la vôtre. Ça coule de source, mais je tenais à le préciser quand même...

Voilà, l'interface est moche, en tout cas beaucoup plus que celle de Speed.cloudflare.com , par contre l'essentiel est là. Et surtout, les mesures restent chez vous plutôt que de partir ailleurs.

Bon, maintenant que vous avez vos chaînes IPTV qui tournent via Tunarr ou xTeVe, votre flux XMLTV est super propre. Mais il vous manque un seul truc : Un guide de programme potable.

Hé bien GridTV développé par l'ami JohnnyBeGood est là pour ça !

GridTV c'est une interface web en PHP/JS/CSS qui transforme toute source XMLTV compatible en guide TV façon grille horizontale, avec l'indicateur "maintenant" visible en permanence, un barre de progression du programme en cours, et les émissions passées qui se retrouvent automatiquement grisées. C'est exactement ce à quoi ressemble le guide TV de votre box opérateur, mais en mieux, et pour votre propre contenu !

Pour le déploiement, Docker est le chemin recommandé plutôt que de tout configurer à la main : git clone, cd GridTV, docker compose up -d, et hop, vous ouvrez localhost:8080.

Un assistant de setup vous demandera alors votre source EPG obligatoire et une playlist M3U si notamment vous voulez utiliser le player intégré, et une fois validé, vous retombez directement sur la grille.

Ça se met en place en moins de 5 min mais si vous préférez installer sans Docker, ou plutôt sans la couche conteneur, il y a également sur le Github des exemples de config pour Apache et Nginx dans la doc. Caddy fonctionnera aussi et la doc concernant Traefik, c'est pour le cas où GridTV tourne en Docker mais derrière un reverse proxy.

Côté fonctionnalités, le player HLS s'ouvre en PiP (Picture in Picture) dans un coin en cliquant sur une chaîne et le multi-EPG vous permettra de configurer plusieurs sources avec un petit switch. GridTV propose aussi des rappels de programme via notifications navigateur, 15 minutes avant la diffusion. Mais pour en profiter, l'onglet du browser doit rester ouvert et les notifs autorisées.

Et il y a aussi possibilité de générer un export PDF/PNG du guide sur 24h. C'est pas indispensable mais ça permet pour ceux qui veulent d'imprimer le programme de la soirée.

Chaque visiteur de l'instance peut aussi utiliser / paramétrer ses propres URLs XMLTV/M3U, car rien n'est stocké côté serveur. Hé oui, tout passe par le localStorage du navigateur donc vous pouvez partager votre instance avec autant de monde que vous voulez, ça n'a pas d'impact.

La version Steampunk

Et il y a même des thèmes genre cyberpunk, steampunk, magazine ou le thème par défaut. Et la page de monitoring admin expose également une sonde accessible via un endpoint compatible Uptime Kuma qui renvoie le code HTTP 200 si tout va bien. Sinon, ce sera du code 503. Bref, ça vous connaissez...

Bref, l'outil est jeune mais bien construit et une démo live tourne ici guide.demo.johnnybegood.fr . A suvire donc....

Et si vous cherchez juste des listes de chaînes IPTV gratuites , c'est par là !

Si vous faites tourner WireGuard depuis un réseau filtré par DPI (Genre en Russie, Iran, Chine, et autres pays défenseurs de la libertéééé (non)), vous avez sans doute remarqué que les tunnels tombent rapidement. En effet, les signatures des protocoles et notamment du protocole WireGuard sont devenues facilement identifiables. Les filtres modernes de censure sont ainsi capable de les bloquer en quelques secondes. C'est pour ça que wg-obfuscator , sorti par Alexey Cluster (le dev derrière le mod hakchi de la NES Classic Mini dont je vous parlais en 2017), m'a tapé dans l'œil.

Concrètement, c'est un petit proxy en C qui se glisse entre votre WireGuard et le réseau. Vous le lancez aux deux bouts du tunnel, et lui déguise les paquets pour qu'ils ressemblent à du STUN (le protocole utilisé par les outils de visioconf, rarement bloqué) ou à un flux random pas reconnaissable. WireGuard continue ainsi de tourner sans aucune modification...

C'est vraiment bien fichu son truc et surtout, par rapport à AmneziaWG (un célèbre fork de WireGuard souvent cité comme référence en obfuscation), hé bien y'a juste un binaire à rajouter, alors que AmneziaWG, lui, modifie TOUT le protocole. Il faut donc remplacer les client ET le serveur ce qui est bien relou.

Comme wg-obfuscator se contente uniquement de faire le proxy, vous gardez votre setup WireGuard classique et donc ça fonctionnera partout... Sur OpenWrt, MikroTik avec RouterOS 7.4+ sur ARM64/x86_64 via Docker, NixOS, Android, ou un simple Raspberry.

Par contre, l'outil utilise une clé symétrique en texte clair donc c'est pas du chiffrement fort, mais du camouflage.

Côté config, on est sur du fichier INI tout simple :

[main]
source-lport = 13255
target = 10.13.1.100:13255
key = votre_secret
masking = STUN
verbose = 2

Hello les amis, voici ma petite trouvaille du jour, idéale pour ceux qui jouent en ce moment avec des adresses IP : ip66.dev . C'est une base de géolocalisation IP et entièrement libre, livrée au format MMDB (le même que celui de MaxMind) qui permet de remplacer direct un fichier GeoLite2 dans vos libs existantes (Python, Go, Node.js), sans toucher au code.

L'équipe de Cloud 66 maintient cette liste à jour sous licence CC BY 4.0 et tout est utilisable simplement en récupérant le fichier mmdb.

Pour le télécharger :

curl -LO https://downloads.ip66.dev/db/ip66.mmdb

go install github.com/maxmind/mmdbinspect/cmd/mmdbinspect@latest
mmdbinspect -db ip66.mmdb 8.8.8.8

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

Depuis qu'Amazon a coupé le téléchargement USB de nos ebooks Kindle (sniiiif), héberger sa propre bibliothèque est passé du statut de bricolage du dimanche aprem au geste héroïque de préservation de notre souveraineté !

Alors si vous voulez vous lancer, sachez que Kavita , le serveur de lecture auto-hébergé développé depuis 2020, est l'un des candidats les plus solides du moment. C'est un lecteur web qui gère EPUB, PDF, comics CBZ/CBR et manga avec mode de lecture droite-à-gauche pour les aficionados et grâce lui, nos ebooks peuvent reprendre leur indépendance.

Ce truc, ça se déploie en Docker ou via Scoop pour Windows en 4 lignes de PowerShell.

De mon côté, j'ai installé Kavita sur mon NAS Synology alors voici la marche à suivre si vous voulez faire pareil.

Installation sur NAS Synology (Container Manager)

Testé sur DSM 7.2 avec Container Manager. Pour QNAP via Container Station ou TrueNAS, la logique est la même puisque c'est du Docker standard.

Étape 1 - Préparer les dossiers

Sur votre NAS, créez deux dossiers via Panneau de configuration > Dossier partagé :

• docker/kavita/config pour la config et la base SQLite de Kavita
• data/library/books pour votre bibliothèque (pointez où vous stockez déjà vos EPUB et CBZ)

Étape 2 - Le docker-compose.yml

Ouvrez ensuite Container Manager > Projet > Créer, donnez-lui le nom kavita, et collez ce docker-compose :

services:
 kavita:
 image: jvmilazz0/kavita:latest
 container_name: kavita
 restart: unless-stopped
 ports:
 - "5000:5000"
 environment:
 - TZ=Europe/Paris
 volumes:
 - /volume1/docker/kavita/config:/kavita/config
 - /volume1/data/library/books:/manga

L'image jvmilazz0/kavita:latest est celle référencée dans la doc officielle. Côté container, les chemins sont /kavita/config et /manga (peu importe que ce soit du manga ou des romans, c'est juste le nom historique du point de montage).

Étape 3 - Lancer le conteneur

Validez le projet. L'image se télécharge (environ 200 Mo), puis le conteneur démarre. Si le port 5000 est déjà pris sur votre NAS, changez le mapping en 5001:5000 par exemple.

Étape 4 - Premier lancement

Dans votre navigateur, allez sur http://IP-DU-NAS:5000. L'écran d'accueil vous demande alors de vous créer un compte admin.

Validez, puis allez dans les préférences pour passer l'interface en français et rafraichissez la page.

Ensuite, dans les paramètres du serveur > Bibliothèques, ajoutez une bibliothèque : Type "Livre" pour les EPUB/PDF ou "Manga"/"Comic" selon le contenu, le choix du dossier pointant vers /manga. Le scan démarre automatiquement.

Étape 5 - Organisation des dossiers

Attention, Kavita est sensible à la structure des dossiers donc pour qu'il identifie correctement les séries, organisez vos dossiers comme ça :

/manga
├── Asterix/
│ ├── Asterix - Tome 01.cbz
│ └── Asterix - Tome 02.cbz
├── Stephen King/
│ ├── Ça.epub
│ └── Shining.epub

Un sous-dossier par série ou par auteur, pas tout en vrac dans un dossier unique.

Étape 6 - Accès distant (optionnel)

Maintenant, pour accéder à Kavita depuis l'extérieur, le plus propre c'est un reverse proxy avec HTTPS. Sur Synology, soit via DSM > Portail web > Proxy inversé, soit via Nginx Proxy Manager . Pointez votre sous-domaine sur IP-NAS:5000 et activez Let's Encrypt.

Ou alors, moi ce que j'aime bien faire aussi, c'est rien du tout et passer par Tailscale !

Côté fonctionnalités

Côté ergonomie, franchement ils n'ont pas chômé puisqu'on y retrouve le lecteur intégré avec modes single page, double page, webtoon ou même mode immersif plein écran. Des thèmes light, dark, sepia, + un mode personnalisé en CSS si vous voulez.

Y'a aussi de la synchro de progression de lecture entre tous vos appareils, du coup vous pouvez commencer un chapitre sur le laptop pendant votre pause café et le finir sur le téléphone dans le métro. C'est appréciable au quotidien.

Y'a aussi de la gestion multi-utilisateur avec authentification OIDC pour ceux qui aiment faire les choses bien (et ratings + listes individuels par compte, donc votre meilleur pote peut lire ses romans de Tom Clancy à côté de votre collection de docs techniques sans qu'on les mélange).

Il y a également une surveillance automatique des dossiers pour tout ce qui est import auto et de la recherche full-text avec filtres par métadonnées (titre, auteur, série, genre, langue).

Et si vous avez des enfants, il est possible de mettre en place des restrictions par classification d'âge pour éviter qu'ils ne fouillent dans vos comics de Manara. Et le clou du spectacle spécial barbu, c'est l'export d'annotations vers Obsidian via le plugin officiel pour les nerds du second cerveau.

Kavita propose même une fonction "Send to Kindle" pour balancer un EPUB vers votre liseuse Amazon. Sur Windows, vous pouvez aussi le transformer en service système avec Shawl pour qu'il démarre tout seul au boot, et côté Linux, un docker-compose suffira largement.

Voilà, dans cette jungle bordélique des outils ebooks auto-hébergeables, Kavita se positionne comme une option moderne et stable. Je préfère Kavita à Calibre car l'interface web est carrément plus moderne et hyper fluide à l'usage.

Vous l'aurez compris, côté concurrence, Kavita est historiquement plus orientée mixte ebooks-comics que Komga (qui supporte aussi les EPUB et PDF mais reste très ancré culture comics). Alors si vous hésitez entre les outils du moment, mon tour d'horizon des outils ebooks self-hosted devrait vous éclairer (avec notamment le drame Booklore !!).

Ah et y'a aussi Kavita+, la version premium à 4 $ par mois (2 $ le premier mois avec le code FIRSTTIME) qui ajoutera la sync AniList, des recommandations personnalisées, des collections intelligentes et l'enrichissement de métadonnées automatique. Après, perso, pour un usage classique, je trouve que la version gratuite fait déjà largement le job, mais si vous gérez +50 000 fichiers et que vous voulez pas passer la soirée à taguer des séries entières, là ça peut carrément valoir le coup.

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

Une IA qui pense que 2026 ressemble à un monde fait de bateaux à vapeur et de vastes réseaux ferroviaires, et qui considère qu'une seconde guerre mondiale est très peu probable... voilà Talkie-1930, le nouveau modèle de langage à 13 milliards de paramètres lancé par Nick Levine, David Duvenaud et Alec Radford (l'un des architectes de GPT-2 chez OpenAI).

LE truc avec ce modèle d'un nouveau genre, c'est qu'il n'a JAMAIS lu un mot écrit après le 31 décembre 1930. Pas de Wikipedia, pas de Reddit, pas de GitHub....et j'en passe.

Si ça vous branche, vous pouvez tester la démo direct sur talkie-lm.com/chat , et les poids sont dispos sur HuggingFace sous licence Apache 2.0 !

Alors pourquoi 1930 et pas 1950 ou 1900 ?

Hé bien tout simplement parce que c'est la date précise à laquelle les œuvres tombent dans le domaine public aux États-Unis. L'équipe a donc pu aspirer 260 milliards de tokens de livres, journaux, périodiques, revues scientifiques, brevets et jurisprudence antérieurs à cette date sans risquer la moindre poursuite légale.

Et c'est là que ça devient amusant parce que quand on demande à Talkie-1930 de décrire le futur, il imagine comme je vous le disais en intro, un monde dominé par les bateaux à vapeur et les trains et c'est logique car c'était l'horizon technologique de son corpus à l'époque. Le modèle considère aussi qu'une seconde guerre mondiale est improbable (il ne connaît évidemment que la Première) et du coup, ça donne un terrain d'expérimentation fascinant pour étudier le raisonnement temporel et la généralisation hors distribution moderne.

L'équipe a publié trois checkpoints : talkie-1930-13b-base (modèle brut), talkie-1930-13b-it (pour le chat) et talkie-web-13b-base (un jumeau d'architecture identique mais entraîné sur FineWeb à titre de comparaison). Cette approche "modèle jumeau" permet par exemple de mesurer précisément ce qui vient de l'architecture vs ce qui vient des données.

Pour la phase de post-training, l'équipe a utilisé Claude Sonnet 4.6 comme juge dans une procédure DPO (Direct Preference Optimization). Ils ont également généré des conversations synthétiques entre Claude Opus 4.6 et Talkie pour le fine-tuning supervisé. Bref, c'est un modèle ultra-vintage entraîné à l'aide de modèles ultra-modernes.

L'équipe travaille déjà sur un système OCR custom pour les documents historiques (les OCR conventionnels n'atteignent que 30% de l'efficacité d'apprentissage face à du texte transcrit manuellement) et vise un modèle de niveau GPT-3 pour l'été 2026, avec un corpus pouvant atteindre plus d'un trillion de tokens.

Bref, Talkie-1930 c'est un projet de recherche assez chouette pour tous ceux qui aiment creuser les LLMs. Le code est sur GitHub sous Apache 2.0, et la démo en ligne marche très bien si vous voulez juste tester sans installer.

Amusez-vous bien !

Source

"GitHub n'est plus un endroit pour faire du travail sérieux."

C'est signé Mitchell Hashimoto, le créateur de HashiCorp, de Vagrant ou plus récemment de Ghostty, et l'utilisateur numéro 1299 de la plateforme depuis février 2008.

Et quand un mec qui a passé 18 ans à pousser du code presque tous les jours sur Github annonce qu'il se casse, bah ça vaut clairement le coup de comprendre pourquoi.

L'annonce est tombée hier : Ghostty , le terminal en Zig pour macOS et Linux va quitter la plateforme. Pas tout de suite, pas brutalement, mais la décision est prise. Hashimoto précise qu'il discute "avec plusieurs fournisseurs (commerciaux comme FOSS)" pour choisir la nouvelle maison pour son code, et qu'un miroir en lecture seule restera accessible sur l'URL GitHub actuelle pour ne pas casser les liens des PRs et des issues. La migration sera, je cite, "aussi incrémentale que possible" pour les contributeurs.

Mais alors, qu'est-ce qui a déclenché cette situation ? Hé bien la semaine du 20 avril a été vraiment catastrophique ! Tout d'abord, le 22 avril, l'agent Copilot et le traitement des commentaires de PR sont tombés une demi-journée à cause d'une erreur de sérialisation. Le 23 avril, c'était encore pire puisqu'un bug dans la merge queue a produit des merges incorrects pour les PRs fusionnées en mode squash quand le groupe contenait plus d'une PR.

Cette situation a même été carrément reconnue officiellement par GitHub, puisque 2092 pull requests ont été affectées ... du coup des changements précédemment mergés se sont retrouvés involontairement annulés par les merges suivants. Ensuite, le 27 avril, rebelote sur les Github Actions.

Bref, comme le dit Hashimoto dans The Register : "je ne peux plus coder avec GitHub".

Hashimoto fait état d'un attachement quasi sentimental avec la plateforme. Il a lancé Vagrant en partie pour impressionner GitHub, en espérant secrètement décrocher une embauche un jour. Embauche qui n'est jamais venue, mais l'attachement est resté. "J'aime GitHub plus qu'on devrait aimer une chose", écrit-il, "et je suis en colère contre lui".

C'est pas de la posture donc puisqu'il a vécu depuis 2008 toute l'histoire de la plateforme en passant par le rachat par Microsoft en 2018 jusqu'à l'âge Copilot. Et c'est ce qui rend sa décision vachement intéressante car c'est pas un libriste hardcore qui crachait déjà sur GitHub avant le rachat. Non, c'est un vrai fidèle de la première heure !

Mitchell Hashimoto ( Source )

Alors ses raisons sont-elles valables ?

Pour vous la faire courte, c'est OUI ! Mais ma réponse longue mérite un peu de nuance quand même, parce que c'est jamais aussi simple.

Côté faits, son constat est vraiment étayé. GitHub a publiquement reconnu sur son blog officiel que ses récentes pannes sont dues à "une croissance rapide, un couplage architectural et des limitations de gestion de charge". Pas de complot donc mais un aveu honnête.

Quand votre infra ne tient plus la charge et que vos services principaux tombent quasi quotidiennement, vendre du cloud computing devient trèèèès compliqué. Alors pour un projet open source qui dépend des Actions pour ses tests automatiques, des PRs pour les contributions extérieures, ou des Issues pour son support... 2 heures de blocage par jour, c'est franchement énorme et ça casse bien les couilles.

C'est l'équivalent d'un quart de la journée de travail balayé et sur un trimestre, ça commence à coûter super cher en énergie mentale...

Maintenant, Hashimoto souhaite quand même conserver ses projets personnels sur GitHub. Seul Ghostty migre, donc ce n'est pas non plus un boycott idéologique de Microsoft, ni une croisade contre la centralisation. C'est surtout une décision pragmatique pour un projet collectif qui doit fonctionner H24.

Un dépôt perso peut se permettre une heure de downtime sans drama. Je le précise pour éviter de transformer le sujet en guerre culturelle prêt à penser. C'est plus un divorce avec négociation qu'une révolution sanguinaire.

Après y'a des alternatives... De leur côté, Codeberg et Forgejo tournent super bien sans oublier GitLab pour ceux qui préfèrent du commercial all-in-one, ou tout simplement Gitea ou Forgejo en version auto-hébergée pour ceux qui veulent vraiment garder la main.

L'auto-hébergement n'a jamais été aussi accessible . Un VPS Linux à 5 balles par mois, un Forgejo en Docker compose, un fournisseur de CI externe ou des runners locaux... et vous avez une forge équivalente à un GitHub des années 2015. Le hic, c'est surtout l'effet réseau car un mainteneur peut migrer son repo, mais comment ramener ses contributeurs qui ont toutes leurs notifs, leurs follows, leur réputation accumulée sur GitHub ?

C'est pas si simple...

Car c'est là que ça coince vraiment. En fait, le verrou n'est pas technique, il est social, et c'est pas demain matin qu'on le fera sauter. Ghostty peut se permettre de quitter GitHub précisément parce que le projet a atteint la masse critique où les contributeurs viennent même quand on déménage mais la plupart des projets open source n'ont pas ce luxe.

Pour eux, partir de GitHub c'est risquer de perdre 90 pourcent de leur visibilité du jour au lendemain. Et sans visibilité, pas de contributeurs et pas de PRs... du coup le projet se plante avant même de démarrer. C'est dommage !

Notez quand même que Forgejo travaille d'ailleurs activement sur la fédération via ActivityPub , et à terme, ça pourrait permettre une vraie décentralisation des forges sur le modèle de Mastodon. Mais à condition que l'écosystème suive...

Maintenant, pour les mainteneurs qui se reconnaissent dans la frustration de Hashimoto, le moment est plutôt favorable, je trouve, pour aller tester Codeberg sur un projet secondaire avant de peut-être déménager votre projet principal.

Tout ça est faisable en un week-end ou deux. Certes, il y a un petit coût à cette migration, mais disons que c'est un investissement pour la sérénité de demain.

Bref, un gros big up à Hashimoto pour son courage !

Source

DOOM a déjà été porté sur des thermostats, des tests de grossesse, et même un piano ! Manquait donc plus que les chatbots IA !

Et voilà que c'est fait puisque Chris Nager vient de faire tourner DOOM dans ChatGPT et Claude, jouable directement dans la fenêtre du chat.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/doom-chatgpt-claude-mcp/doom-chatgpt-claude-mcp-1.qt">lien vers la vidéo</a>.

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

Souvenez-vous, en mai 2025 quand je vous parlais de BleachBit 5.0 et de son grand ménage de printemps. Hé bien Andrew Ziem, le développeur historique du soft, vient de balancer la version 6.0 samedi dernier !

Et c'est annoncé comme la plus grosse release du projet depuis des années, avec plus de 100 améliorations et bug fixes au programme. Et surtout deux nouveautés qui sortent du lot.

La première, c'est un Cookie Manager qui vous laisse enfin choisir quels cookies garder lors d'un nettoyage, sur les navigateurs Chromium et Firefox. Plus besoin donc de tout dégager d'un coup et de devoir ressaisir vos sessions partout.

Vous gardez ce qui compte (banque, mail, sites où vous êtes loggés en permanence) et le reste passe à la machine. Andrew a même mis une vidéo de démo sur la page de release pour montrer le truc en action.

Une boîte mail avec 12 000 messages non lus (genre 32 par jour pendant un an), c'est pas une vie mais c'est pas une fatalité non plus puisque Lakshay Gupta vient de poster NeatMail . Cet outil est un assistant IA qui labelise vos mails Gmail ou Outlook automatiquement et qui rédige des brouillons de réponse dans votre style d'écriture. Le code est dispo sur Github, auto-hébergeable, mais je reviendrai sur la licence (spoiler : c'est custom)...

L'interface marketing de NeatMail

En gros, vous connectez votre Gmail ou Outlook via OAuth (rien à faire côté mot de passe, et tant mieux vu les fuites récentes via les outils IA ), et NeatMail utilise ensuite OpenAI GPT-4o mini en backend pour classifier chaque mail entrant (avec un taux annoncé de 95% de confiance, mais c'est à voir en pratique).

Comme ça, plutôt que d'attendre que vous traitiez vos messages par batch comme un facteur dépressif, le truc bosse en temps réel ! Un mail arrive, hop, label appliqué et ainsi de suite. Et si le système juge que ça mérite une réponse, il vous prépare un brouillon dans votre ton habituel.

Y'a aussi des trucs qui font la différence avec un simple filtre Gmail. Le système se souvient des conversations passées pour rester cohérent dans les brouillons, vérifie votre calendrier avant de proposer un créneau, et apprend votre style à force de relire ce que vous écrivez. La fonctionnalité de désinscription en un clic balaye aussi les newsletters promo, et il y a même une intégration Telegram qui ping votre téléphone quand un mail vraiment important arrive ("Oh cool encore un mail de mon avocat !").

Le chaos d'une boîte Gmail sans tri auto

Côté code, c'est du Next.js 16 + React 19 pour le front, Hono.js pour le backend, PostgreSQL pour les métadonnées, Redis Upstash pour la déduplication, et Inngest qui orchestre les workflows. Le tout majoritairement codé en TypeScript, avec un Dockerfile prêt à dégainer.

Faut juste vos identifiants Google Cloud, Microsoft Entra et OpenAI à côté pour faire tourner ça chez vous, ce qui n'est pas hyper user friendly à trouver mais reste faisable un dimanche pluvieux si vous avez la niak.

Pour le pricing, NeatMail propose 7 jours d'essai gratuit puis 7 dollars par mois. À comparer donc avec Superhuman qui demande entre 30 et 40 dollars mensuels pour le même genre de service, ou SaneBox qui démarre à 7 dollars mais ne propose pas de rédaction de brouillons par IA.

Sauf que là, le code EST sur GitHub, du coup si vous avez la flemme de payer 84 dollars par an (le prix d'un bon resto en amoureux 😍) et que vous savez configurer un PostgreSQL, vous économisez votre argent et vous gardez la main sur l'infra !

Brouillon de réponse pré-rédigé directement dans Gmail

Après faut quand même garder en tête que NeatMail est encore jeune, et que c'est un projet solo. Et côté licence, c'est pas du MIT pur puisque la licence réelle s'appelle "NeatMail Open Source License". C'est donc de la licence faite maison, avec de l'auto-hébergement autorisé, mais une interdiction complète de revendre une instance ou de monter un business concurrent.

Donc si vous comptiez forker le projet pour monter votre SaaS concurrent, oubliez ça direct, car ce n'est pas autorisé. Côté privacy, le créateur précise qu'aucun contenu de mail n'est stocké en base, mais juste les métadonnées (sachant que les mails passent quand même par OpenAI pour la classification, faut pas se mentir...).

Voilà, je trouve l'idée plutôt sympa. Le code est dispo sur GitHub si vous voulez self-hoster votre boîte mail intelligente, ou comme je vous le disais, y'a la version SaaS sur neatmail.app à 7 dollars par mois pour les flemmards. Carrément moins cher que Superhuman !

Le scraping web, c'est un combat permanent contre les sites qui changent leur HTML toutes les deux semaines. Vous vous emmerdez à coder vos sélecteurs CSS, ça marche pendant un mois, puis le site refait son design et hop, votre script s'éteint en silence. C'est pourquoi Karim Shoair (alias D4Vinci sur GitHub) a sorti Scrapling, un framework Python qui s'adapte tout seul quand le DOM bouge.

La clé c'est adaptive=True sur n'importe quel sélecteur. Vous lui dites "je cherchais .product", Scrapling sauvegarde alors la signature de l'élément (texte, attributs, position dans l'arbre), et la prochaine fois que le site a renommé sa classe, il retrouve l'élément via similarité.

Concrètement ça donne ça :

from scrapling.fetchers import StealthyFetcher
StealthyFetcher.adaptive = True
page = StealthyFetcher.fetch('https://example.com', headless=True)
product = page.css_first('.product', adaptive=True) # Retrouve l'élément même si la classe a changé

Le truc marche grâce à un algo de similarité maison qui compare la structure DOM autour de l'élément. L'auteur lui-même a écrit un long post Medium intitulé " Creating self-healing spiders with Scrapling in Python without AI ", et ça résume bien la philosophie : pas de modèle IA mais juste des heuristiques solides !

La doc précise que adaptive=True ne sauvegarde que le premier élément de la sélection. Du coup si vous récupérez 50 produits d'un coup avec .css('.product'), seul le premier sera adapté. Faudra donc soit utiliser css_first comme dans l'exemple, soit boucler manuellement et appeler adaptive sur chaque élément. C'est bon à savoir...

Y'a également 3 fetchers selon le besoin. Fetcher pour les requêtes HTTP rapides avec spoofing TLS, StealthyFetcher qui passe Cloudflare Turnstile via un navigateur furtif (Camoufox sous le capot), et DynamicFetcher qui lance un Chromium ou un Chrome via Playwright pour les sites lourds en JS. Du coup vous pouvez démarrer léger en HTTP et basculer vers un navigateur uniquement quand un site bloque, sans réécrire votre code.

Côté perfs, le README annonce du lourd : 2 ms pour extraire 5000 éléments contre 1584 ms pour BeautifulSoup avec lxml. Sauf que Parsel et Scrapy font aussi 2 ms. Donc le gain vient du moteur lxml utilisé en direct, ce qui veut dire que si vous étiez déjà sur Scrapy, vous ne gagnerez pas en vitesse brute. Mais si vous traînez encore du BS4 partout, le saut sera énorme !

Sur le terrain anti-bot, ça se compare bien à Botasaurus dont je vous avais parlé. La différence c'est que Scrapling embarque un ProxyRotator natif et propose un blocage d'ads/trackers (~3500 domaines) activable via block_ads=True ou automatique en mode MCP, ce qui simplifie la vie quand vous tournez sur un serveur (où les IPs des datacenter se font régulièrement filtrer). Botasaurus, lui, vous laisse gérer la rotation à la main.

Détail sympa pour les bidouilleurs : y'a également un serveur MCP intégré (pip install "scrapling[ai]"). Du coup Claude ou Cursor peuvent piloter Scrapling directement pour extraire des données, en réduisant la consommation de tokens car l'IA ne voit pas tout le HTML brut, juste ce qui est extrait. Pour les agents qui scrappent en boucle, c'est cool.

Notez que les sponsors Platinum du projet sont tous des fournisseurs de proxies (DataImpulse, BirdProxies, Evomi, etc.). C'est logique vu l'usage du framework, mais gardez en tête que pour bypasser un Cloudflare sérieux à grande échelle, vous aurez besoin de proxies résidentiels payants, donc d'eux. L'outil est gratuit, mais le contournement industriel ne l'est pas.

Pour installer, c'est pip install "scrapling[fetchers]" puis scrapling install pour récupérer les binaires navigateur. Une image Docker existe aussi (pyd4vinci/scrapling) et y'a même un shell interactif (scrapling shell) pour debugger vos sélecteurs en live.

Bref, c'est carrément pas mal pour ceux qui scrapent régulièrement. Alors si BS4 vous fait pleurer, allez voir par ici .

Et merci à Letsar pour le lien !

Et si vous aviez UN seul soft qui bloque les pubs comme Pi-hole, qui parle DoH/DoT/DoQ comme AdGuard Home, ET qui sait faire du serveur DNS faisant autorité pour vos zones perso ?

Hé bien c'est exactement ce que fait Technitium DNS Server , un projet open source sous licence GPLv3 maintenu par TechnitiumSoftware. Concrètement, avec ce truc, vous obtenez un résolveur récursif, un sinkhole avec blocklists, et un serveur de zones (Primary, Secondary, Stub) dans le même process. Du coup, pour un homelab type, fini d'empiler Pi-hole + Unbound + BIND, tout est dans la même console web !

Pour démarrer sur Linux ou Raspberry Pi, l'installeur officiel fait tout en moins d'une minute :

curl -sSL https://download.technitium.com/dns/install.sh | sudo bash

Sinon Docker marche aussi avec docker pull technitium/dns-server:latest. Vous tapez ensuite http://localhost:5380/ dans le navigateur, login admin/admin (à changer dare-dare !), et hop, vous êtes dans la console web. Le serveur tourne direct, faudra juste pointer votre routeur ou vos clients dessus pour qu'il filtre tout le réseau.

La console web Technitium - tableau de bord principal

Côté blocage, la console propose un Quick Add pour piocher direct dans les block lists populaires (du style Hagezi). Les listes se mettent à jour quotidiennement, et l'app interne Advanced Blocking gère même des regex et des listes différentes par IP ou sous-réseau client. Pratique, non ?

Genre du blocage strict pour la tablette du salon, plus permissif sur votre ordi, et un mode safe-search obligatoire pour la chambre des gosses. Notez quand même que certaines Smart TV Samsung ou apps gaming hardcodent leur DNS, du coup faudra ajouter une règle de routage sur le firewall de la box pour vraiment forcer Technitium.

L'écran d'ajout des block lists, avec le bouton Quick Add

Niveau protocoles, c'est du costaud : DNS-over-TLS, DNS-over-HTTPS (HTTP/1.1, HTTP/2, HTTP/3), DNS-over-QUIC, plus le DNS-over-PROXY-protocol pour les load balancers. Y'a aussi le DNSSEC complet (RSA, ECDSA, EdDSA, NSEC/NSEC3, DANE TLSA), les transferts de zones AXFR/IXFR, le routage Tor pour les forwarders, et le support du Cloudflare hidden DNS resolver. Soit le set qu'on attend chez un FAI sérieux.

Côté perfs, le serveur encaisse plus de 100 000 requêtes/seconde sur du Gigabit Ethernet d'après les benchs officiels. Sur un Raspberry Pi 4 avec 2 Go de RAM, ça tourne peinard pour une famille de 4 (genre 200 à 300 Mo de RAM en charge avec Hagezi Pro et ses 750 000 entrées, donc carrément de la marge).

Et y'a aussi un DHCP multi-réseaux, du clustering, du SSO via OpenID Connect, du 2FA TOTP, plus des apps internes pour DNS64 (clients IPv6-only), DNS Rebinding Protection, et Advanced Forwarding. Tout ça pour un soft destiné à tourner chez vous.

Côté zones, on peut monter du Primary (zone classique gérée localement), du Secondary (réplique d'une autre zone), du Stub, ou du Conditional Forwarder, plus du Catalog Zones pour ceux qui automatisent à grande échelle. Pratique pour gérer un domaine perso, un homelab entier, ou un split-horizon entre réseau interne et externe. Pas mal pour un soft "maison".

À noter quand même quelques pièges. À part sur Linux et Raspberry Pi où ça tourne nickel, sous Windows 10/11 c'est plus chaotique : Internet Connection Sharing, Hyper-V, Docker Desktop et Defender Application Guard squattent tous le port 53, donc faudra changer le port d'écoute si vous tournez sur un poste de travail. Y'a même des cas tordus où Hyper-V garde le port après désinstallation, et le seul fix c'est un net stop hns ou un reboot complet.

Si vous chargez beaucoup de blocklists volumineuses, la RAM grimpe vite (les pros conseillent de consolider sur une seule liste comme Hagezi Pro). Le cache est aussi froid au premier démarrage, donc les premières requêtes prennent leur temps avant que tout se fluidifie (genre 30 secondes à 1 minute pour redevenir réactif, donc évitez de rebooter en pleine visio).

Mais avec tout ça, vous gagnez un truc rare : un seul outil pour filtrer pubs et trackers à l'échelle du réseau (utile à l'heure où certains pays parlent de criminaliser les bloqueurs côté navigateur ), résoudre vos requêtes en récursif, et héberger vos propres zones DNS. Tout ça avec une UI web qui supporte le dark mode (oui, ça compte aussi ^^).

Bref, franchement à tester si vous voulez la main complète sur votre infrastructure DNS sans bricoler 3 softs en parallèle. Sur un Pi à 35 balles posé derrière la box, ça dépote sa race. Le projet est sur GitHub, le site officiel est ici, et merci à Axala sur Discord pour le tuyau !

Source

Vous synchronisez 4 ou 5 dossiers vers plusieurs serveurs avec rsync ? Alors vous connaissez ce sketch quand un job mouline pendant que les autres font la queue, parce que rsync de base c'est mono-thread et ça avance en file indienne.

Hé bien y'a un petit utilitaire Python qui dégoupille tout ça, pondu par overflowy. Ça s'appelle parallel-rsync et le nom annonce la couleur !

L'idée c'est de pouvoir empiler plusieurs jobs rsync en parallèle, avec une config YAML pour piloter le tout. Vous décrivez vos sources et destinations dans sync.yml, vous lancez parallel-rsync -c sync.yml --workers 4 --max-per-host 2, et hop, ça parallélise.

Le bougre tourne sur un ThreadPoolExecutor Python 3 qui spawn N processus rsync système avec un cap global et un cap par hôte. Et pendant ce temps, des barres de progression vous affichent l'avancement de chaque transfert sans que la console parte en sucette.

La dernière fois, je vous parlais de rsyncy qui collait juste une barre de progression à un rsync solo mais là, on monte clairement d'un cran avec une orchestration multi-cibles.

--workers cap c'est donc le nombre total de processus rsync simultanés (4 par défaut). --max-per-host limite la concurrence par destination (2 par défaut, histoire de ne pas saturer un seul serveur, parce que oui, balancer 8 rsync sur la même machine c'est juste se tirer une balle dans le pied côté I/O).

--timeout met une laisse à chaque rsync, --dry-run ajoute le flag à toutes les commandes pour tester avant de tirer, et --no-progress débraye les barres si vous voulez juste les logs. Côté logging, --log-file et --log-level font également le job.

Par contre y'a pas de retry automatique donc si une session SSH coupe en plein transfert, faudra relancer à la main. C'est logique mais un peu dommage.

Sur un homelab, ce genre de config YAML permet de résoudre le problème des synchros récurrentes avec un seul fichier centralisé au lieu de 8 scripts shell.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/parallel-rsync/parallel-rsync-1.mp4">lien vers la vidéo</a>.

Andrey Letov vient de sortir Notepad++ for Mac , un portage natif Apple Silicon de l'éditeur culte créé par Don Ho. Notez quand même que Don Ho n'a rien à voir avec ce projet. C'est un portage communautaire indépendant, lancé en mars dernier.

Vous récupérez le binaire universel qui tourne nativement sur les puces M1 à M5 et sur les vieux Macs Intel. C'est de l'Objective-C++ compilé pur jus avec le même moteur d'édition Scintilla qu'utilise la version Windows (Scintilla est cross-platform avec un build Cocoa officiel).

Après, tout le reste a dû être refait à la main, parce que le Notepad++ original utilise massivement Win32 pour son interface. Letov a donc réécrit la couche UI from scratch en Cocoa pour coller aux conventions macOS, avec menus, dialogues, file pickers et raccourcis clavier qui se comportent comme ceux d'une vraie app Mac.

L'interface de Notepad++ sous macOS

Côté prérequis, comptez sur macOS 11 (Big Sur) au minimum, en dessous ça ne tournera pas. Donc si vous êtes resté sur Catalina ou plus vieux, ouais, désolé pour vous, faut passer votre tour.

Côté fonctionnalités, on retrouve le pack classique du Notepad++ qu'on connaît, coloration syntaxique pour 80 langages, recherche regex, find in files, bookmark de lignes, recherche incrémentale, split view pour bosser sur deux fichiers en parallèle, enregistrement de macros pour automatiser les tâches répétitives, écosystème de plugins, et l'interface dispo dans plus de 90 langues.

C'est gratuit, sous licence GPL v3 mais attention quand même, les plugins Windows compilés en .dll ne sont pas portables tels quels. Il vous faudra une version macOS recompilée pour chacun, et le catalogue dispo aujourd'hui est forcément plus maigre qu'en face. Bref, du Notepad++ comme on l'aime, mais avec moins d'extensions pour l'instant.

Après tant que Letov tiendra le rythme, ça roulera, mais le jour où il décrochera ou que la version Windows partira dans une direction qu'il ne suit pas, le port macOS va probablement diverger ou s'éteindre. On verra bien.

En attendant, si vous bossez sur Mac et que Notepad++ vous manque depuis votre époque Windows (on fait tous des erreurs ^^), foncez le tester, l'app a l'air bien fichue à première vue et le projet itère vite.

Bref, j'espère que ça durera.