C'est la fin d'une époque. Le noyau Linux, le cœur du système qui pilote le matériel et les communications, s'apprête à supprimer le support d'AppleTalk, ce vieux protocole réseau qu'Apple utilisait dans les années 80 et 90 pour faire dialoguer ses Mac entre eux avant que TCP/IP, le langage commun d'internet, ne s'impose partout.

À l'époque, c'était plutôt malin: vous branchiez deux machines et une imprimante, et elles se trouvaient toutes seules, sans la moindre configuration, du plug-and-play avant l'heure à un moment où monter un réseau relevait encore du casse-tête réservé aux initiés.

Aujourd'hui, plus grand monde ne parle ce dialecte. Il en subsiste quelques traces dans Bonjour, la techno maison qui détecte automatiquement imprimantes et appareils sur un réseau local, mais le protocole d'origine, lui, est mort depuis longtemps.

Près de 4000 lignes de code vont donc disparaître avec la version 7.2 du noyau, et Apple avait lui-même enterré AppleTalk dès 2009, du temps de Mac OS X Snow Leopard. Autant dire que le préavis a été large.

Le plus étonnant, c'est ce qui a déclenché le grand ménage. Ce n'est pas vraiment l'abandon par les utilisateurs, mais une vague de correctifs générés par intelligence artificielle qui a fini par saturer la liste de diffusion des développeurs réseau.

Depuis quelques mois, des outils basés sur des grands modèles de langage, balancent automatiquement des "corrections" de bugs sur du code que personne n'avait réclamé, pour un protocole que plus aucun matériel ne fait tourner.

Et chaque proposition, même inutile, mobilise un humain qui doit la lire, la tester et vérifier qu'elle ne casse rien ailleurs, du temps précieux soustrait au vrai travail de mainteneurs déjà débordés par les contributions légitimes.

C'est Jakub Kicinski, qui supervise toute la pile réseau du noyau, qui a fini par trancher: plutôt que de faire éplucher par ses équipes des patchs pondus en série par des machines pour réparer une techno morte, il a préféré retirer AppleTalk d'un seul geste.

Et il n'en est pas à son coup d'essai. Au cycle précédent, pour Linux 7.1, il avait déjà passé à la trappe ARCnet, l'ISDN, la radio amateur et toute une collection de vieux pilotes réseau oubliés, soit près de 138 000 lignes effacées d'un coup, dans ce qu'il a lui-même baptisé la "LLM-pocalypse".

Le code d'AppleTalk ne finit quand même pas tout à fait à la poubelle, puisqu'il rejoint AX.25 et la radio amateur dans un dépôt GitHub mis de côté, pour les rares curieux qui voudraient encore bidouiller avec.

Bref, c'est une première: des contributions automatisées qui font retirer du code encore fonctionnel. L'IA ne crée pas toujours. Parfois, elle déblaie.

Source : Phoronix

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 faites tourner un petit serveur gratuit chez Oracle, je vous invite prestement, comme dirait Godefroy, à aller vérifier votre compte. Car oui mes amis, Oracle vient de diviser par deux son offre "Always Free" sur les machines ARM, et ils l'ont fait sans prévenir personne. Bouuuuuh ! Cela veut dire que leur fameuse bécane gratuite à 4 cœurs ARM (Ampere A1) et 24 Go de RAM, celle que la moitié de la communauté self-hosting fait tourner pour héberger son site web, son VPN ou son petit lab , est officiellement passée à 2 OCPU et 12 Go de mémoire .

La tristesse m'envahit... snif.

Cela veut donc dire que si vous avez une instance configurée en 4 OCPU / 24 Go, vous êtes dorénavant au-dessus de la limite gratuite. Vous devrez donc rapidement la redimensionner à 2 OCPU / 12 Go, et ça, ça prend 5 à 10 minutes.

Pour ce faire, il faudra vous rendre sur l'affreux dashboard d'Oracle Cloud. Vous ouvrez alors votre instance, Actions puis More actions puis Edit. Vous dépliez la ensuite la section Shape du VM.Standard.A1.Flex, vous mettez 2 OCPU et 12 Go, vous sauvegardez et vous validez le reboot comme des bonhommes, lol.

Ouais, faut redémarrer le VPS, puis se reconnecter dessus en SSH, et c'est réglé. Le guide de Viren070 détaille ce redimensionnement vers 2 OCPU pas à pas si vous voulez être un peu plus tenu par la main.

Et si vous ne touchez à rien parce que balek frrr ??? Et bien si votre compte est en Pay-As-You-Go, tout ce qui dépassera la nouvelle limite gratuite risque de vous être facturé, d'après les retours d'utilisateurs qui ont contacté le support Oracle. Et si vous êtes sur un compte purement gratuit, c'est l'instance elle-même qui peut être stoppée ou récupérée par Oracle. Bref, dans les deux cas, mieux vaut s'en occuper soi-même que de découvrir le problème en mode facture surprise ou disparition de serveur.

Je trouve quand même que le plus gênant dans cette histoire, c'est le silence d'Oracle. Ils n'ont fait aucune annonce ni aucun mail aux clients. Les gens s'en sont rendus compte simplement parce que la page de doc a changé... D'ailleurs, au moment où j'écris ces lignes, le simulateur de coûts d'Oracle affiche encore 0 € pour une instance 4 OCPU / 24 Go, ce qui me laisse penser que la facturation réelle pourrait se déclencher possiblemenet un peu plus tard.

Personne ne sait exactement quand le couperet tombera en fait et c'est ça le souci...

Petite précaution au passage, si vous redimensionnez, sur ARM, Oracle est en permanence à court de capacité... Donc quand vous éteignez votre instance pour la reconfigurer, rien ne vous garantit que vous récupérerez vos cœurs au reboot. Ils peuvent très bien partir à quelqu'un d'autre donc si vous tenez plus à votre machine qu'à vos propres gosses, passez le compte en Pay-As-You-Go avant de la redimensionner. Cela vous permettra de réduire le risque de le voir se faire dégommer.

Et voilà comme un bout d'offre "Always Free" (ce qui veut dire en français, "Toujours gratuit", je me permets de le souligner en toute subtilité QUAND MÊME) vient de prendre fin... Après c'est un peu logique parce que 4 cœurs ARM offerts à vie, c'était plutôt généreux dans le monde dans lequel on vit.

Mais bon, diviser leur offre par deux sans prévenir, en laissant notamment les comptes Pay-As-You-Go se prendre potentiellement une claque en facture alors qu'ils n'ont pas été prévenu, c'est pas un move que la communauté des adorateur du grand Oracle va apprécier je pense...

Bref, si vous avez une instance ARM chez Oracle, allez la vérifier maintenant parce que 5 petites minutes de resize aujourd'hui valent mieux qu'une facture surprise demain...

Source

Vous connaissez le duo Prometheus et Grafana ? C'est le grand classique pour surveiller ses serveurs, mais configurer tout ce bazar et le garder propre, c'est vite l'enfer. Alors pour ceux qui veulent juste garder un oeil sur leur homelab plutôt que de perdre le peu de cheveux qu'il leur reste à configurer Grafana durant des heures, j'ai trouvé pour vous Beszel .

Beszel est un outil de monitoring de serveurs ultra-léger et surtout super simple à mettre en place. Le projet est tout récent et développé en Go, ce qui permet d'avoir des binaires minuscules et une consommation de ressources ridicule

Donc si vous cherchez un outil de monitoring Linux self-hosted aussi simple à prendre en main que Kula dont je vous ai déjà parlé, ça vaut le coup d'aller jeter un oeil.

La mécanique de Beszel repose sur deux morceaux, à savoir le hub et l'agent. Le hub, c'est l'interface web construite au-dessus de PocketBase, qui sert de tableau de bord centralisé quant à l'agent, lui, il tourne discrètement sur chaque machine à surveiller et remonte les métriques au hub. "Discrètement", ça veut dire qu'il consomme à peine 10 à 15 Mo de RAM donc c'est parfait pour le faire tourner sur une vieille machine ou un tout petit Raspberry Pi sans que ça tousse-tousse !

Le truc vraiment cool aussi, c'est la gestion native des conteneurs Docker. Au lieu de simplement suivre l'état général comme avec un outil de suivi des processus classique (je pense à pstop par exemple), il liste chaque conteneur et affiche sa consommation individuelle en CPU, mémoire et réseau. Donc pour tous ceux qui auto-hébergent des dizaines de services, c'est un pur bonheur.

Côté métriques, y'a aussi tout ce qu'il faut pour ne rien louper. L'outil permet de suivre la consommation CPU, la mémoire (incluant le swap et le ZFS ARC), l'espace disque, les entrées/sorties réseau, la moyenne de charge et même la température des composants. En 15 secondes, tout s'affiche proprement.

Il gère aussi des trucs plus poussés comme la santé des disques via les données S.M.A.R.T., l'état de la batterie et même la consommation de vos cartes graphiques Nvidia, AMD ou Intel. Attention, pour le S.M.A.R.T. et le GPU par contre, il faudra que vous installiez les utilitaires système correspondants sur la machine hôte (smartmontools, nvidia-smi...) pour que l'agent puisse remonter les infos.

Et la configuration ? Hé bien c'est un simple fichier docker-compose.yml et voilà c'est plié !

Lors du premier lancement du hub, vous devrez vous créer un compte administrateur, puis cliquer sur "Ajouter un système", et l'interface vous génèrera une clé publique. Il suffira ensuite de filer cette clé à votre agent via sa variable d'environnement (dans son docker-compose.yml, par exemple) et les deux copains commenceront à causer. C'est pas plus compliqué que ça ! Même un notaire pourrait le faire ^^.

Le hub intègre également une gestion multi-utilisateur bien foutue puisque chaque utilisateur peut avoir accès à ses propres machines, tandis que l'administrateur peut décider de partager certains systèmes. Si vous voulez sécuriser le tout, l'outil supporte aussi de nombreux fournisseurs OAuth2 et OIDC comme Google, GitHub ou Keycloak, et vous pouvez même couper complètement la connexion par mot de passe.

Beszel s'occupe aussi des sauvegardes automatiques de vos données de surveillance, en local ou directement sur un stockage compatible S3. Et pour les alertes, pas de panique, car l'outil est compatible avec Shoutrrr . Cela vous permettra de configurer des notifications par Discord, Telegram, Teams ou mail si le CPU s'affole ou si un disque commence à saturer.

Par contre, si vous cherchez un outil d'analyse de logs complet ou de détection de bug réseau ultra-précis, laissez tomber car c'est pas la "mission de vie" de Beszel. Sauf si bien sûr, vous le couplez avec un autre outil. Après pour le reste, c'est parfait.

Vous pouvez tester la version v0.18.7 en vous rendant sur le site officiel .

Si vous avez un homelab, il vous arrive peut-être parfois de vous retrouver en galère parce qu'en essayant de caser un énième serveur dans votre baie, vous réalisez, trop tard, qu'il vous manque deux unités ou que le switch est monté à la mauvaise profondeur. Heureusement, Gareth Evans, un dev qui devait galérer avec exactement le même souci, a sorti Rackula , un outil open source qui vous laisse dessiner le rack de votre homelab en glisser-déposer, avant de sortir la carte bleue.

Vous attrapez des équipements à la souris, vous les empilez dans votre rack virtuel, et vous voyez immédiatement ce qui rentre ou pas. Et c'est plutôt joli puisque les façades des machines qu'on peut voir dans l'outil ne sont pas des dessins génériques. Elles viennent de la NetBox devicetype-library , la grosse base communautaire qui référence les vraies façades avant de tout un tas de matos (Dell, Ubiquiti, Supermicro…). Grâce à ce truc, votre rack virtuel ressemblera donc à votre vrai rack, et pas à un schéma chelou fait en Lego.

Pour l'installer, rien de plus simple. Soit vous passez par la démo web, soit vous l'auto-hébergez en une commande Docker :

docker run -d -p 8080:8080 ghcr.io/rackulalives/rackula:latest

Votre designer de rack tournera alors sur le port 8080. Ce qu'il vous faut donc, c'est juste un endroit pour faire tourner Docker , genre un VPS, un NAS Synology , un Raspberry Pi ou une VM Proxmox ... Bref ce que vous avez déjà sous la main.

Une fois votre baie dessinée, vous l'exportez en PNG, PDF ou SVG, ou vous partagez carrément un lien (ou un QR code) à vos potes. C'est pratique pour par exemple documenter une install ou frimer avec votre setup. Côté technique, c'est codé en Svelte et en TypeScript, et sous licence MIT, donc gratuit et bidouillable à volonté !!

Avant ça, je me souviens, pour documenter un rack ou un réseau, on se débrouillait avec Visio (qui se souvient ??), voire plus récemment avec un vieux template draw.io un peu cheap, ou pire, une photo floue prise au téléphone.

Avec Rackula, le boulot est propre !

Faut juste pas se tromper sur ce que c'est. Rackula. Pour être clair, c'est un outil de visualisation, et pas un DCIM complet. Donc si vous voulez gérer vos adresses IP, votre inventaire ou calculer la conso électrique et le refroidissement de votre baie, il faudra rester sur du NetBox ou du RackTables, un peu plus lourds à déployer. N'oubliez pas non plus que par défaut (tant que vous n'avez pas activé le mode API avec authentification quoi...), tous les schémas que vous créez restent dans le local storage de votre navigateur. Donc si vous videz votre cache, tout partira dans les limbes du grand vide cosmique numérique.

Ce projet est porté par un seul dev assisté de Claude, qui l'assume tranquillement dans ses commits, et y'a même déjà des tutos pour l'installer sur NAS Synology et UGREEN qui traînent sur le net.

Bref, Rackula, c'est l'outil idéal pour ceux qui aiment empiler du serveur et qui veulent un plan propre de leur baie sans se ruiner. Indispensable si vous vous auto-hébergez.

Et merci à j0j0b4rj0 pour le lien !

Oliver Sieber, un chercheur de chez Exodus Intelligence, vient de publier l'exploit complet d'une faille qui tient dans un seul caractère. C'est la CVE-2026-23111, planquée dans nf_tables, c'est à dire au bout du noyau Linux qui filtre les paquets réseau. Un bug discret donc, qui transforme un compte tout pourri, sans le moindre privilège, en compte root sur la machine... et qui vous fait sortir d'un conteneur au passage.

Le scénario, vous le connaissez si vous traînez ici depuis un moment. Un utilisateur qui dispose d'un compte sans droit particulier sur une machine Linux (y compris parce qu'il a exploité une autre faille avant, dans une appli web par exemple) lance l'exploit, et se retrouve avec les pleins pouvoirs. Pas de vecteur distant, rien à cliquer : c'est l'arme qu'on dégaine une fois le pied dans la porte. Que ce soit un shell avec des droits limités, un conteneur compromis, un compte de service... tout y passe et hop, root sur l'hôte !

Le bug lui-même, c'est ce qu'on appelle un use-after-free, c'est à dire que le noyau réutilise un bout de mémoire qu'il a déjà libéré, et forcément ça part en vrille. Exodus a titré son analyse complète "Off By !", un clin d'œil au classique off-by-one des développeurs, sauf qu'ici le coupable c'est un test inversé. Un caractère de trop, une condition qui dit l'inverse de ce qu'elle devrait, et voilà. Et le correctif, lui, tient en une seule ligne.

Le fameux caractère : le ! qui inversait le test dans nft_map_catchall_activate(). Le correctif le retire, et c'est tout (commit 8fdb05de).

La faille a d'ailleurs été reproduite deux fois, par deux équipes qui ne se sont pas concertées. Exodus l'a validé sur Debian Bookworm, Debian Trixie, Ubuntu 22.04 et 24.04. FuzzingLabs avait sorti sa propre version dès avril, par un chemin complètement différent, et l'avait fait tourner sur RHEL 10 juste avant le Pwn2Own de Berlin. Bref, ça marche, c'est bien documenté, et c'est public.

Mais le pire, c'est le calendrier de tout ce merdier puisque le patch a été mis à dispo le 5 février. Ensuite, y'a eu l'exploit de FuzzingLabs publié le 16 avril, suivi d'un write-up détaillé d'Exodus le 8 juin. Autrement dit, ça fait des mois que le correctif existe et des semaines que le code d'exploitation traîne dans la nature.

La seule chose qui vous sépare donc d'un compte root offert à n'importe qui, c'est d'avoir mis à jour ou pas.

Et cette faille s'ajoute à une sacrée série de failles root-local sur Linux ce printemps. Y'a eu Copy Fail , y'a eu Dirty Frag et sa variante Fragnesia ... à chaque fois le même refrain, un compte sans droit qui finit root sur une install standard. C'est devenu presque routinier, et Synacktiv pointe une raison plutôt pertinente en nous expliquant que c'est à cause (ou grâce ^^) aux outils d'IA qui décortiquent les patchs pour en sortir un exploit rapidos, qui marche direct avant même que la correction soit déployée partout.

Du coup, qu'est-ce que vous devez faire ?

Hé bien le plus simple d'abord, c'est de mettre à jour le noyau et vous rebootez. Ubuntu a corrigé 22.04, 24.04 et 25.10, Debian a patché Bookworm et Trixie (avec un backport en 6.1 pour Bullseye), et Red Hat, SUSE et Amazon Linux ont suivi. Comme la version corrigée exacte dépend de votre distrib, jetez donc un œil à l'advisory qui correspond à la vôtre.

Si vous gérez une machine où tournent des utilisateurs ou des workloads pas franchement de confiance, vous pouvez également couper le chemin d'attaque sans attendre le patch. La faille a besoin des user namespaces non privilégiés, un mécanisme qui laisse un process lambda se bricoler son propre bac à sable avec des droits root à l'intérieur.

Et nf_tables comme ces namespaces, sur la plupart des desktops et pas mal de serveurs, c'est actif par défaut, donc oui, sans le patch vous êtes probablement exposé.

Pour les désactiver, le plus universel c'est user.max_user_namespaces=0 : un sysctl -w user.max_user_namespaces=0 pour tout de suite, et la même ligne dans un fichier genre /etc/sysctl.d/99-userns.conf pour que ça tienne au reboot.

Ça marche sur toutes les distros mais c'est radical, ça coupe tous les user namespaces, même ceux de root. Sur Debian et les vieilles Ubuntu, t'as plus fin avec kernel.unprivileged_userns_clone=0 qui ne vise que les non-privilégiés. Et sur Ubuntu 24.04, bonne nouvelle, c'est déjà restreint par défaut via AppArmor. Attention quand même, ça peut casser des trucs qui s'appuient dessus, genre le bac à sable de Chrome ou Flatpak.

À faire en connaissance de cause, donc.

La parade en vrai : une fois les user namespaces non privilégiés coupés, un compte lambda qui tente d'en créer un (le prérequis de l'exploit) se fait jeter sur un "No space left on device".

Après la bonne nouvelle, c'est que d'après les chercheurs, aucune exploitation dans la nature pour cette faille précise n'a été constaté à ce jour. Après comme sa cousine Copy Fail, elle, a déjà atterri au catalogue des failles activement exploitées de la CISA, ne traînez pas trop. Bref, comme d'hab padpanik, vous mettez à jour, vous rebootez, et on n'en parle plus.

Source

Il y a des failles qui réclament un arsenal de hacker chevronné, et puis il y a HTTP/2 Bomb, qui se contente de quelques kilo-octets pour faire vaciller des serveurs parmi les plus utilisés de la planète. Dévoilée le 2 juin sous la référence CVE-2026-49975, elle s'attaque à HTTP/2, le protocole qui transporte une bonne partie des pages que vous consultez chaque jour.

Le résultat ressemble à une mauvaise blague. Une poignée d'octets envoyés au bon endroit, et la mémoire vive du serveur se met à enfler jusqu'à engloutir des dizaines de gigaoctets en quelques secondes, jusqu'à ce que la machine ne réponde plus à personne.

On parle ici d'une attaque par déni de service, un DoS dans le jargon, dont le but n'est pas de dérober quoi que ce soit mais d'asphyxier le serveur. Rien de bien neuf, donc, sauf que l'ampleur du désastre, elle, l'est totalement.

Toute l'astuce tient dans le mariage de deux mécanismes connus depuis des lustres. HTTP/2 sait compresser les en-têtes des requêtes pour éviter de répéter cent fois la même chose, et c'est précisément cette générosité que l'attaquant retourne contre le serveur, en faisant référence des milliers de fois à un en-tête glissé une seule fois, si bien que la machine réserve de la mémoire à tour de bras pour quelque chose qui, au départ, ne pèse presque rien. C'est le principe de la bombe de décompression, ce fichier piégé minuscule qui se déplie en montagne de données dès qu'on l'ouvre.

Et comme si ça ne suffisait pas, l'attaquant fait mine de ne pas pouvoir recevoir la réponse, ce qui interdit au serveur de boucler sa tâche et de relâcher ce qu'il a accumulé. Quelques octets envoyés de loin en loin, et la connexion reste ouverte indéfiniment. C'est diabolique de simplicité.

Les chiffres, eux, font carrément peur. Sur Envoy, les chercheurs ont mesuré un rapport de plus de 5 000 pour 1, avec 32 Go engloutis en une dizaine de secondes, là où Apache craque en moins de vingt secondes et nginx comme IIS en moins d'une minute. Une simple connexion domestique à 100 Mb/s peut donc mettre à genoux une infrastructure entière.

Le plus déroutant dans cette histoire, c'est que les deux ingrédients de la recette traînaient en accès libre depuis des années. Il aura fallu attendre l'équipe de Codex, et le chercheur Quang Luong, pour avoir l'idée de les mélanger et constater les dégâts.

Du côté des correctifs, tout le monde n'est pas logé à la même enseigne. nginx a réagi avec sa version 1.29.8 et une nouvelle option pour brider les en-têtes, Apache a corrigé dans mod_http2 2.0.41, mais Microsoft IIS, Envoy et Cloudflare Pingora attendaient encore leur rustine au moment de la divulgation.

Bref, vieille recette, ingrédients connus, mais cocktail dévastateur. Si vous gérez un serveur en HTTP/2, allez vérifier vos versions avant qu'on ne teste la recette à votre place.

Source : The Hacker News

Monter son propre serveur Git, ça rime souvent avec déployer une usine à gaz bourrée d'options qu'on n'utilisera jamais. Heureusement, Soft Serve prend le contre-pied total de tout ça ! Ce serveur Git self-hosted de charmbracelet (la bande derrière Bubble Tea, Glow, Freeze et Gum) fait sa vie dans le terminal et se pilote via SSH.

Un coup de brew install charmbracelet/tap/soft-serve (ou Docker, ou go install), vous lancez soft serve et hop, vous voilà avec un serveur Git complet qui tourne grâce à un seul binaire. Pour parcourir vos dépôts, pas besoin de navigateur, vous vous connectez juste en SSH et une petite interface en mode texte s'ouvre direct dans votre terminal. Genre ssh git.chezvous.net, et vous voilà en train de naviguer dans l'arborescence, lire les fichiers avec coloration syntaxique, fouiller les commits. Le tout sans quitter le shell !

Créer un dépôt, ça se fait en une ligne :

ssh -p 23231 localhost repo create mon-projet

git remote add origin ssh://localhost:23231/mon-projet
git push origin main

Une mise à jour récente du noyau Linux a cassé le support de certains adaptateurs Bluetooth MediaTek, ceux qui sont intégrés aux puces Wi-Fi qu'on trouve sur beaucoup de cartes mères modernes.

Le résultat : votre clavier sans fil, votre souris ou votre casque Bluetooth ne se connectent plus après la mise à jour. Pour les utilisateurs Linux, c'est le genre de régression franchement pénible, pour rester poli.

Al Williams raconte sur Hackaday avoir traqué le problème jusqu'à un fichier précis du noyau : btmtk.c, le pilote qui gère les puces Bluetooth MediaTek. Deux lignes de code suffisent à contourner le problème. Sa rustine consiste à remplacer une fonction de gestion d'erreur par une instruction qui marque la sortie comme "non terminée" et continue. C'est pas génial sur le papier, mais ça fait remarcher le matériel le temps qu'un correctif officiel arrive en amont.

Le problème, c'est que ce n'est pas un simple paramètre à changer. Il faut récupérer les sources du noyau, installer la boîte à outils de compilation, patcher la ligne concernée, recompiler juste le module problématique, l'installer dans /lib/modules, et rebooter.

Deux lignes. Pour un développeur Linux, c'est la routine. Pour un utilisateur lambda qui a juste envie que sa souris remarche, c'est franchement relou.

Al teste sa rustine sur OpenSUSE Tumbleweed (une distribution Linux à mises à jour continues), mais la procédure marche aussi sur Debian, Ubuntu et la plupart des autres distros, avec quelques ajustements de chemins. Il insiste : c'est temporaire. Le bug est connu des développeurs du noyau, et le correctif définitif devrait remonter dans les prochaines versions stables.

Le truc un peu naze, c'est que Bluetooth sur Linux a longtemps eu la réputation d'être un cauchemar. La situation s'était nettement améliorée ces dernières années avec BlueZ (la pile Bluetooth officielle de Linux) et le support natif dans la plupart des distros. Voir une régression d'envergure refaire surface en 2026 sur du matériel grand public, ça refait grincer des dents les vieux Linuxiens qui pensaient avoir refermé ce chapitre.

Et puis ça illustre bien le modèle de développement du noyau. Les régressions arrivent parce que le code évolue très vite et que tout le matériel ne peut pas être testé en permanence. Quand ça pète, la communauté patche. Quand le patch est validé, il remonte. C'est lent, mais ça finit toujours par marcher. Le truc, c'est qu'entre les deux, vous restez avec votre clavier Bluetooth en rade .

Si vous êtes touché par le problème, l'article complet d'Al Williams sur Hackaday donne toutes les commandes pas à pas . Le fix est documenté ligne par ligne, ça prend une trentaine de minutes pour quelqu'un qui est très à l'aise avec un terminal.

Source : Hackaday