Les devs de chez Google viennent de sortir un outil conçu pour les agents IA qui codent afin qu'ils deviennent des experts en développement d'agents IA sur Google Cloud. J'sais pas si je suis très clair, alors je vais essayer de vous expliquer tout ça.

Que vous soyez sur Claude Code, Codex d'OpenAI ou Gemini CLI (ça s'appelle agy cli maintenant d'ailleurs pour Antigravity CLI...), écrire un agent qui tient la route et le faire tourner dans le cloud de Mountain View, ça exige déjà de connaître par cœur l'ADK (Agent Development Kit) maison de Google, de savoir évaluer et coder le projet et surtout de tout déployer sans tout péter.

Ce sont clairement plusieurs métiers différents, et ça demande pas mal de connaissances, alors plutôt que de vous faire lire une doc bien chiante, les dev de Google ont eu l'idée de packager toute cette expertise dans des skills que votre agent de coding va lire à votre place.

Après, vous votre rôle, c'est de décrire tout ce que vous voulez en anglais ou en français et de siroter votre mojito. Et une fois que vous aurez fini, votre super agent générera le squelette du projet, le testera en local et poussera tout ça dans un runtime sur Google Cloud.

Pour l'installer, suffit de faire un petit :

uvx google-agents-cli setup

ou si vous voulez juste injecter les skills dans votre agent sans la CLI complète :

npx skills add google/agents-cli

Une fois la machinerie en place, vous aurez à votre service 7 modules de skills et 25 commandes qui couvrent tout le cycle de vie des agents Google Cloud, du scaffolding (croyez le ou non, en français, ça se dit échafaudage ...lol) à la publication sur Gemini Enterprise (ex-Vertex AI). Et puis Agents-CLI sait surtout générer tout ce qui est jeux de tests, noter les réponses avec un LLM qui fait office de juge, comparer 2 versions d'un même agent ou encore optimiser les prompts à partir des résultats collectés.

Microsoft vient de lâcher un truc qui va faire plaisir à tous ceux qui bidouillent fort des conteneurs Linux depuis leur machine Windows. Ça s'appelle WSL Containers (WSLC pour les intimes, et pas WSL 3) et l'objectif c'est de faire tourner des conteneurs Linux nativement sous Windows sans avoir à passer par des outils tiers du genre Docker.

Pour en profiter, tapez la commande suivante :

wsl --update --pre-release

Cela mettra à jour votre WSL en version 2.9.3 ou supérieure et vous obtiendrez alors une toute nouvelle commande : wslc.

WSLC est un alias qui lance en réalité container.exe et qui permet de gérer tout le cycle de vie d'un conteneur Linux avec des commandes très classiques : run, stop, build, tag, push, pull, prune. Voici un vrai exemple tiré de la doc de Microsoft :

wslc run -d --name=webtop -e PUID=1000 -e PGID=1000 -e TZ=Etc/UTC -p 3000:3000 -p 3001:3001 lscr.io/linuxserver/webtop:ubuntu-kde

Ce qu'on lance là c'est bien une image en provenance de LinuxServer dont je vous ai déjà parlé, et comme vous pouvez le voir, vous ne serez pas dépaysé si vous connaissez déjà un peu Docker.

L' ordonnanceur du noyau Linux vient de recevoir une proposition de mise à jour qui fait grimper les perfs de façon assez spectaculaire sur certaines charges. Hygon, le fondeur chinois qui fabrique des x86 sous licence de l'architecture Zen d'AMD, a envoyé une série de patches pour étendre le cache-aware scheduling, et les chiffres annoncés montent jusqu'à 360% de mieux en termes de transactions par seconde sur MySQL.

Pour comprendre le délire, faut revenir au cache-aware scheduling de base, le fameux CAS, conçu par les ingénieurs d'Intel (Tim Chen, Chen Yu et Peter Zijlstra) et tout juste mergé dans Linux 7.2. Sur un CPU moderne avec plusieurs caches de dernier niveau, le fameux LLC, l'ordonnanceur essaie de regrouper sur le même domaine de cache les tâches qui partagent des données. Du coup, moins de ratés de cache, moins de données qui font des allers-retours entre les caches, et donc de la perf en plus sans toucher au matos mais juste en plaçant mieux les tâches.

Le hic, c'est que ce CAS de base raisonne au niveau d'un seul LLC. Tant que votre charge tient dans un domaine de cache, nickel. Mais dès que la charge dépasse ce que peut contenir un seul cache partagé, l'ordonnanceur ne sait pas regrouper les tâches au niveau du dessus : elles se dispersent sur des cœurs qui ne partagent plus le même cache, et toute la localité s'évapore. Et ça tombe mal pour Hygon, dont les puces récentes ne sont pas un bloc unique mais un assemblage de chiplets (le C86-7490 en réunit quatre), avec plusieurs caches partagés éparpillés sur la galette.

D'où l'idée de développer ces patches, qui permettent un regroupement hiérarchique et offrent la possibilité de s'étendre ou de se contracter dynamiquement selon la taille de la charge et la topologie de la machine.

Hygon annonce donc jusqu'à +49% sur Hackbench , +20% sur Schbench (non, pas le rappeur), et ce fameux +360% sur MySQL !! C'est le feu !

Maintenant, avant de revendre votre PC pour en prendre un sous Hygon, attention ! Ces chiffres, ce sont des "jusqu'à", mesurés sur des topologies multi-domaines, donc typiquement de gros serveurs à plusieurs chiplets. Sur votre laptop avec un seul LLC, vous ne verrez donc sans doute rien passer.... Ouais, je sais, sniiiif. Le 360% n'est pas un gain universel, mais plutôt le pic sur la config qui souffrait le plus du problème.

Un fondeur chinois qui, parti d'une licence Zen d'AMD, en vient à pousser du code dans Linux pour faire tourner tout le monde plus vite, Intel et AMD compris, c'est chouette quand même. Si ça vous intéresse, les patches viennent d'être postés sur la mailing list du kernel , donc rien n'est encore intégré mais si ça passe la revue, c'est de la perf gratuite pour les machines qui en bavent le plus.

Source

Des chercheurs de l'université de Californie à San Diego, épaulés par Google, viennent de prouver un truc contre-intuitif : un Pixel mis au rebut il y a trois ans tient encore tête à un serveur professionnel sur certains calculs, au point qu'on peut en assembler un vrai data center au lieu de le foutre à la poubelle.

L'idée a été posée sur le blog de recherche de Google . Une fois l'appareil ouvert, les chercheurs retirent tout ce qui ne sert plus, l'écran, la batterie au lithium, les caméras et la coque, jusqu'à ne garder que la carte mère et sa puce, ce qu'on appelle un SoC, le processeur qui faisait tourner Android avant qu'on le bascule sur une distribution Linux des plus classiques.

Ce système, le même qui anime déjà l'immense majorité des serveurs de la planète, libère la puce des limites pensées pour un mobile, à commencer par ce bridage qui met les applications en pause dès qu'elles passent à l'arrière-plan. Ensuite, il suffit de relier ces cartes mères entre elles via Kubernetes, l'outil que les géants du web emploient déjà pour piloter les milliers de machines de leurs centres de données comme un seul gros ordinateur.

Le plus déroutant arrive là. Sur la plupart des tests ne mobilisant qu'un seul cœur, un Pixel Fold de 2023 dépasse un serveur ASUS RS720A-E11 pourtant équipé de deux gros processeurs AMD, le genre de bête qu'on retrouve dans les baies des entreprises.

Le serveur empile bien plus de cœurs en parallèle, si bien qu'il faut réunir entre 25 et 50 téléphones pour rivaliser avec son débit total. Mais bon. Dès lors que vous ramassez ces appareils gratuitement au lieu d'acheter du silicium neuf, l'équation se renverse.

Le vrai argument est écologique, puisque près de la moitié des émissions de carbone d'un smartphone sur toute sa vie part dans sa seule fabrication, surtout dans l'assemblage de la carte mère et du processeur, ce fameux carbone gris déjà cramé avant même que l'appareil ne s'allume.

On change pourtant de mobile tous les trois ou quatre ans, en balançant une puissance de calcul encore largement bonne à servir, pendant que les entreprises font fabriquer des serveurs flambant neufs pour les mêmes tâches. Le gâchis est énorme.

L'équipe a pour l'instant fait tourner une grappe de 20 téléphones, qui a encaissé sans broncher le pic de rendu des devoirs d'une classe de plus de 75 étudiants avec une latence plus basse que les services cloud du commerce. Elle prépare déjà un cluster d'environ 2 000 Pixel pour la rentrée, capable d'absorber une centaine de cours d'informatique en même temps pour une fraction du prix du cloud habituel.

Reste à rester lucide. Ces puces ont peu de mémoire, donc on les cantonne aux tâches légères, la correction automatisée ou les carnets de code, loin de l'entraînement d'un gros modèle d'IA.

Mais voir une montagne d'e-déchets se muer en salle de classe numérique, ça donne sacrément envie d'y croire. Surtout vu le nombre de Pixel qui dorment au fond de nos tiroirs, même moi j'en ai deux qui traînent pour tout vous dire.

Source : Techspot

Si vous hébergez vos propres services derrière une IP dynamique, vous connaissez sans doute des outils merveilleux comme DynDNS, NoIP, ou encore Cloudflare DDNS.

Sauf que dès que votre homelab mélange du Docker, du Proxmox et un cluster Kubernetes, ça devient vite le bordel à maintenir ! Mais Maxfield Allison, un contributeur du projet OPNsense, qui visiblement en avait marre lui aussi de gérer tout ça à la mimine, nous a pondu dnsweaver .

dnsweaver, ça fait pas repousser les cheveux sur les sysadmins (désolé ^^) mais c'est un outil en Go qui peut se lancer comme un service et qui se configure avec la clé API de votre Cloudflare (ou d'un autre provider) pour mettre à jour sa zone DNS. Comme ça, quand l'un de vos conteneurs démarre avec un label Traefik, hop, l'enregistrement DNS apparaît automatiquement. Et quand vous le virez, il disparaît.

C'est génial parce que ça vous permet de ne plus jamais toucher à votre zone DNS à la main.

Et une fonctionnalité incroyable de dnsweaver, c'est le split-horizon DNS qui permet de donner accès à votre réseau local et à ses services depuis n'importe où sur Internet, mais avec la bonne tête selon d'où vous vous connectez. Vous aurez grâce à ça, votre bitwarden.maison.fr qui pointe vers le 192.168.1.10 quand vous êtes chez vous sur le réseau local, et vers votre IP publique quand vous tapez la même adresse depuis l'extérieur. Comme ça, plus la peine de maintenir 2 configs séparées qui finiront toujours par diverger à un moment...

Et dnsweaver ne se contente pas d'un seul fournisseur et ça c'est cool. Comme ça, si vous voulez allier la puissance des services de Cloudflare (pour le cache, la sécurité, la protection DDoS...etc.) à, par exemple, un Technitium perso pour votre réseau interne, bah c'est possible ! dnsweaver pousse comme ça vers 7 backends en parallèle: Technitium, Cloudflare, Pi-hole, AdGuard Home, dnsmasq, le bon vieux RFC 2136 (pour BIND, PowerDNS ou le DNS de Windows Server) et même un webhook pour brancher un truc maison.

Côté détection, vous aurez capté, ça va lire les labels Traefik, Caddy ou nginx-proxy sur vos conteneurs Docker, les annotations Ingress sur Kubernetes, et côté Proxmox il récupère vos VMs (via l'agent QEMU) comme vos conteneurs LXC. Très cool donc pour les furieux qui gèrent plein d'instances sur différents serveurs !!

Pour l'installer, maintenant vous avez le choix: Soit vous passez par l'image Docker maxamill/dnsweaver, le registre ghcr.io ou un chart Helm si vous êtes plutôt team Kubernetes. Vous lui passez les credentials de vos providers (via des secrets Docker ou Kubernetes, et pas en clair dans un fichier qui traîne comme un gros nooooobbzzzz) et vous le laissez tourner. Il expose même des métriques Prometheus, du coup vous le surveillez comme le reste de votre stack.

Alors oui, je saiiiis, ExternalDNS fait déjà ce genre de boulot, sauf que c'est du Kubernetes only. Alors que dnsweaver, lui, avale les trois plateformes d'un coup, ce qui colle pile poil à l'ADN même du homelab bordélique que vous avez chez vous ^^.

Le projet est encore assez récent et porté par une seule personne mais ça évolue à une vitesse impressionnante (déjà des dizaines de versions livrées en quelques mois), alors je vous recommande de tester ça quand vous aurez 5 min (pas en prod tout de suite par contre, promettez le moi, bande de fifous !!)

Voilà, si gérer votre DNS maison vous bouffe un temps de dingue, dnsweaver est à envisager (pas comme votre cousin.e, donc... )

Quand on est habitué à Linux et qu'on se retrouve avec un Mac, même si c'est une base unix, c'est déroutant. Heureusement, Apple est de plus en plus ouvert au monde du libre et vient de publier la version 1.0 de Container , avec dedans des "container machines" qui ressemblent furieusement à WSL. Et ça nous permet comme ça d'avoir le meilleur des deux mondes : un macOS pour le quotidien, et un vrai Linux pour vos folles bidouilles.

Vous vous souvenez forcément de mon article où je vous présentais Apple Container , cet outil écrit en Swift qui fait tourner des conteneurs Linux dans des petites machines virtuelles. Et bien un an plus tard, le projet passe en 1.0, pile pour la WWDC, et la grosse nouveauté c'est donc ce mode "machine".

Le CLI container en action, sobre comme un terminal qui bosse ( Source )

Il s'agit d'un environnement qui vous permet de faire tourner de vraies distributions Linux comme Ubuntu, Debian ou Alpine, et pas juste un conteneur modelé sur une application. La machine lance le système d'init de l'image, donc un systemctl start postgresql fonctionnera comme sur un vrai serveur.

Et à la reconnexion, à partir du même terminal ou d'un autre, l'état de la machine n'est pas perdu. Surtout, elle mappe automatiquement votre utilisateur et votre répertoire home. Votre repo vit ainsi dans le $HOME de macOS, du coup vous éditez avec votre IDE côté Mac et vous compilez côté Linux, sans étape de copie entre les 2.

Pour la prise en main, entrez les commandes suivantes en prenant soin de remplacer alpine par la distrib de votre choix :

container machine create alpine:latest --name dev
container machine run -n dev whoami # votre user, pas root
container machine run -n dev # shell interactif

Ensuite, pour aller plus loin, vous pouvez le faire via un terminal en choisissant l'image que vous voulez ou concevoir votre propre image : n'importe quelle image Linux avec un /sbin/init fait l'affaire.

Après vous l'aurez compris parce que vous êtes les plus malins, il vous faut un Mac Apple silicon, et si ça se lance encore sur macOS 15, c'est avec des limitations et sans filet car les mainteneurs ne s'occupent actuellement que des bugs reproductibles sur macOS 26. Et migrer toute votre stack dev dessus aujourd'hui, c'est ce que je ne vous recommande pas sachant que c'est tout frais...

Mais ainsi, grâce à ces machines, plus besoin de choisir entre un Mac et une distribution Linux. Après est-ce que ça enterre OrbStack et Colima ? Pas tout de suite je pense, car ces outils tournent depuis des années sur des Mac Intel et des macOS pas tout neufs, alors que là, Apple exige sa puce maison.

Ah et côté x86, container fait aussi tourner des images amd64 via Rosetta, alors c'est le bonheur ! Et si le sujet vous branche, j'avais aussi causé de Mocker , un clone Docker natif pour Mac, et de WSL côté Windows si pour vous Mac c'est pas encore un projet ^^.

Bref, l'installeur signé est sur la page des releases , vous faites un petit container system start, et hop hop hop, à vous le kif du Linux sur votre petit Mac !