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-LOhttps://downloads.ip66.dev/db/ip66.mmdb
Ensuite pour interroger une IP, l'outil
mmdbinspect
de MaxMind fera le job. Si vous l'avez pas déjà, une ligne suffit :
go install github.com/maxmind/mmdbinspect/cmd/mmdbinspect@latest
mmdbinspect -db ip66.mmdb 8.8.8.8
À l'intérieur de la réponse, vous trouverez le numéro et le nom de l'ASN, le pays avec son code ISO, le continent, en IPv4 et IPv6 :
Au lieu de moudre des heuristiques opaques, ip66 préfère tout simplement agréger des sources à partir des 5 registres régionaux (AFRINIC, APNIC, ARIN, LACNIC, RIPE NCC) pour les allocations, le BGP via RouteViews et RIPE RIS pour les vues publiques d'annonces, le RFC 8805 geofeed quand les opérateurs déclarent eux-mêmes leurs localisations, sans oublier GeoNames pour tout ce qui concerne les libellés.
Du coup chaque enregistrement dispose de son propre niveau de confiance (Very High, High, Medium, Low) selon la qualité de la source. Y'a même des marqueurs pour identifier les IPs VPN / Tor et compagnie.
Notez par contre, que c'est du country-level, et pas du city-level comme GeoIP2 City ou IPinfo Core, mais pour enrichir des logs, sortir des stats par pays ou bloquer un continent entier, c'est largement suffisant !
Et si vous voulez l'exposer en API plutôt que la requêter en local, ça se branche nickel sur le
mmdb-server
, un petit serveur Python qui sert les fichiers MMDB en HTTP. Vous lui pointez ip66.mmdb dans son dossier db/ et hop, c'est plié !
Bref, un fichier mmdb à DL, et votre serveur sait maintenant que 8.8.8.8 c'est l'oncle Google.
Datadog Labs vient de sortir
pup, un outil CLI codé en Rust qui donne à vos agents IA un accès complet à leur plateforme. L'idée c'est que pendant que Vercel et AWS galèrent de ouf à rendre leurs trucs « agent-friendly », Datadog, lui, dégaine un outil dédié qui expose +200 commandes sur plus de 33 de leurs produits, du monitoring aux SLOs en passant par la sécurité et les incidents.
Côté install c'est du classique, brew tap datadog-labs/pack && brew install pup, puis pup auth login pour le flow OAuth2 avec PKCE.
Plus besoin comme ça de balader vos clés API à vie dans des variables d'env, même si le fallback DD_API_KEY reste là quand même pour d'éventuels cas "headless". Une fois loggué, vous tapez alors par exemple :
et l'agent récupère du JSON 100% clean, prêt à être bouffé et digéré par Claude Code, Cursor ou peu importe ce que vous utilisez.
Pour détecter le mode agent, Pup regarde les variables d'environnement type CLAUDE_CODE ou CURSOR_AGENT, et bascule tout seul en sortie machine, avec tout ce qui va bien, genre les metadonnées, les hints et autres auto-approbation des prompts destructifs (oui, c'est à utiliser avec prudence, mais je vous fais confiance, vous êtes des pro).
Les commandes sont aussi auto-découvrables via pup --help ou pup agent schema, donc l'agent peut introspecter ce qu'il a à disposition sans que vous lui mâchiez le travail.
Y'a même un moteur de runbooks en YAML pour chaîner des étapes (commandes pup, shell, HTTP, workflows Datadog) avec interpolation de variables, conditions et polling. Pratique donc pour scripter un triage d'incident ou un déploiement, sans sortir un Argo ou un Temporal pour ça. Et pour les setups un peu plus velus, pup se compile aussi en WASM, donc vous pouvez le faire tourner dans Wasmtime ou un Cloudflare Worker.
À noter, le projet est encore en Preview, et que certaines API ne sont pas implémentées (Session Replay, Powerpacks, IP Allowlist).
"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 !
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 !
VS Code transitioned to a weekly stable release schedule starting with version 1.111 in March 2026, moving away from its previous monthly cadence. Versions 1.112 and 1.113 are the second and third releases under this new schedule, introducing integrated browser debugging, MCP (Model Context Protocol) server sandboxing, Copilot CLI agent permissions, and chat workflow improvements. This article details the most significant technical changes in both releases.