Vue lecture

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.

OpenZFS 2.4.2 sort avec le support du noyau Linux 7.0

OpenZFS 2.4.2 est sortie ce 12 mai, et c'est une mise à jour qu'attendaient pas mal de gens qui font tourner du Linux 7.0 (le tout dernier noyau Linux stable). OpenZFS, pour ceux qui ne suivent pas, c'est le portage libre du célèbre système de fichiers ZFS originellement développé par Sun Microsystems, et désormais maintenu par une communauté autour de FreeBSD et Linux.

ZFS, en gros, c'est ce qui permet de gérer des pools de disques de plusieurs téraoctets avec snapshots, compression, déduplication et auto-réparation des données. Le genre d'outil qu'on retrouve dans les NAS sérieux et les serveurs de stockage.

La grosse nouveauté de cette 2.4.2, c'est le support du noyau Linux 7.0 stable. La version précédente 2.4.1 plafonnait à Linux 6.19, et beaucoup d'admins qui ont mis à jour leur distribution se retrouvaient avec un système qui refusait de charger le module ZFS.

C'est résolu. La compatibilité historique est aussi maintenue jusqu'à Linux 4.18, ce qui permet aux serveurs un peu anciens de continuer à profiter des dernières corrections. Côté BSD, FreeBSD 13.3 et plus restent supportés.

Dans le détail des changements, on trouve des corrections sur initramfs (le système qui charge le noyau au démarrage), le support de l'appel système POSIX_FADV_DONTNEED qui permet à une application de dire au noyau qu'elle n'a plus besoin d'un fichier en cache (ce qui libère de la RAM), les premiers patchs préparatoires pour Linux 7.1, et un durcissement des en-têtes SPDX (les balises de licence en tête de chaque fichier). Rien de spectaculaire, mais c'est ce genre de maintenance discrète qui fait tenir un projet sur la durée.

Pour ceux qui ne veulent pas passer sur la branche 2.4, l'équipe a aussi publié OpenZFS 2.3.7 en parallèle. Mêmes corrections de stabilité, kernels supportés un peu plus anciens. Ça permet aux infrastructures conservatrices de rester sur leur branche sans rater les fixes importants.

Si vous tournez sur Proxmox, TrueNAS, ou un Linux avec ZFS en racine, allez donc vérifier la version dispo dans vos dépôts. La 2.4.2 va probablement arriver sous quelques jours.

Source : Phoronix

Il essaye de réparer une GoPro Hero 10, et c'est l'enfer

Hugh Jeffreys , le YouTuber australien qui démonte tout ce qu'il trouve, s'est attaqué cette fois à une GoPro Hero 10 achetée 100 dollars avec un message d'erreur "no camera input".

Traduction : la caméra ne reçoit plus l'image du capteur. Sur Hackaday , le récit complet est savoureux pour qui aime la réparation board-level (la réparation au niveau de la carte, avec fer à souder et microscope, plutôt que le simple swap de pièces).

Pour ne pas y aller à l'aveugle, il achète une seconde GoPro Hero 10 HS à 40 dollars, censée donner ses pièces. Premier souci : le démontage.

La GoPro Hero 10 a un écran tactile collé au châssis avec une telle quantité d'adhésif que le retirer sans le briser tient du miracle. Hugh y arrive après plusieurs essais avec un sèche-cheveux et beaucoup de patience, mais c'est clair que GoPro n'a pas pensé à la réparabilité une seconde.

Vient ensuite le swap du module caméra, l'élément suspecté sur la première unité. Démontage, montage, reset usine, mise à jour firmware, rien n'y fait. Le message d'erreur revient. Hugh teste plusieurs combinaisons, sans plus de succès, et finit par admettre qu'il manque cruellement de schémas électroniques pour aller plus loin.

Sans la documentation interne que GoPro garde évidemment fermée, impossible de tracer le signal du capteur jusqu'à la puce de traitement.

Twist final : la seconde GoPro, présentée comme HS pour dégât des eaux, s'avère réparable après un bon nettoyage à l'isopropanol et un séchage soigneux.

Elle redémarre, capture des images, et fonctionne comme neuve. Hugh termine donc avec une GoPro qui marche pour 40 dollars, et une autre qui finit en boîte à pièces de rechange.

La leçon est simple. Sans schémas et sans accès au programmateur officiel de GoPro, la réparation board-level d'une caméra moderne tient parfois plus de la loterie que du diagnostic, surtout quand le constructeur fait tout pour décourager l'ouverture.

Et pendant que les marques serrent la vis sur la documentation technique, des gens comme Hugh tentent encore de prouver que ces appareils peuvent vivre une seconde vie.

Franchement, GoPro pourrait offrir un peu plus de prise aux réparateurs indépendants. On peut toujours rêver.

Source : Hackaday

Magic Pointer, le pointeur de souris pensé par Google DeepMind

Du côté de Google DeepMind, on s'amuse à réinventer le pointeur de souris. Le projet s'appelle Magic Pointer, c'est un pointeur piloté par Gemini (le modèle d'IA maison de Google) qui comprend ce que vous désignez à l'écran.

L'idée est simple. Vous survolez un élément (un tableau, une image, un PDF, une recette), vous tapez ou dites ce que vous voulez en faire, et Gemini exécute en tenant compte du contexte visuel précis.

Les démos publiées font effectivement leur petit effet. Vous survolez un tableau de chiffres et vous demandez un camembert ? Le graphique apparaît directement dans la zone visée. Vous pointez une recette en ligne et vous dites "double les ingrédients" ? La liste se réécrit avec les nouvelles quantités.

Vous pointez un PDF de 30 pages et vous demandez un résumé en bullet points ? Gemini sort un résumé qui colle aux pages effectivement visées, pas au document entier. C'est exactement le genre d'interaction qu'on attendait d'une IA depuis des années, et qui jusqu'ici se faisait toujours en mode "copier la zone puis coller dans une fenêtre de chat".

Côté disponibilité, Magic Pointer est dispo en démo dans Google AI Studio (l'interface dev de Google pour jouer avec Gemini), avec un déploiement progressif annoncé dans Gemini pour Chrome et dans les Googlebook, ces ordinateurs récemment annoncés par Google. Pas de date pour une arrivée sur d'autres navigateurs, ni en français au passage, mais on peut imaginer que Chrome reste prioritaire pour Google.

Côté technique, DeepMind reste un peu flou sur le pipeline exact. Gemini reçoit visiblement une capture autour du pointeur (un rectangle de quelques centaines de pixels), plus le texte demandé, et renvoie l'action à exécuter. C'est bluffant.

Maintenant on verra bien comment ça tient en conditions réelles avec des documents complexes, des sites mal formatés ou des PDF mal scannés où la reconnaissance de texte galère déjà. La vraie question, c'est aussi la latence. Aussi malin que soit le système, si ça met cinq secondes à comprendre, on ira plus vite en copier-collant.

Source : Google

Des utilisateurs Google Cloud facturés des milliers de dollars par erreur

Un truc franchement rageant remonte du côté de chez Google Cloud, et c'est The Register qui a mené l'enquête. Plusieurs développeurs ont vu leur facture Google Cloud exploser entre 3000 et 10000 dollars en quelques minutes, pour des services qu'ils n'ont jamais utilisés : génération vidéo Veo 3, tokens du modèle Gemini, le tout via leurs clés API Maps. Et le pire, c'est qu'ils avaient suivi à la lettre les recommandations officielles de Google.

La doc Google vous dit en effet de mettre votre clé Maps en clair côté client (dans le JavaScript de votre site, par exemple), parce qu'elle sert à afficher une carte dans un navigateur. Sauf que voilà, si vous activez sur votre projet Google Cloud d'autres APIs (comme Gemini ou Veo, l'outil de génération vidéo de Google), la même clé peut être utilisée pour appeler ces services.

Un bot malveillant trouve la clé sur n'importe quel site (le code source d'une page web est lisible par tout le monde), s'en sert pour générer des milliers de vidéos IA, et c'est le proprio du projet qui paie l'addition.

Le plus pénible, ce sont les spending caps, ces plafonds de dépenses que Google met en avant comme garde-fou. En pratique, ils ne déclenchent qu'une alerte par mail, pas une coupure réelle des services.

Vous recevez l'alerte alors que la facture grimpe déjà depuis dix minutes, et le temps de réagir, c'est déjà fini. Plusieurs devs disent avoir vu leur compte passer de quelques euros à plusieurs milliers en moins d'une heure. Ça pique.

Et Google ? La firme refuse les remboursements en parlant d'un problème "industrie-wide", autrement dit "tout le monde a ce souci, c'est pas notre faute". Pratique pour eux, moins pour les développeurs qui se retrouvent avec une note salée pour des services qu'ils n'ont jamais demandés.

Le vrai sujet, c'est le mélange clé Maps publique par design + accès Gemini activé par défaut sur le même projet. Ce n'est pas une faille au sens technique du terme, c'est une configuration que Google a choisie et qui transforme chaque clé Maps en bombe potentielle pour le portefeuille de celui qui l'utilise.

Si vous bossez sur Google Cloud, allez donc vérifier que Gemini et Veo ne sont pas activés sur les projets qui n'en ont pas besoin, et restreignez vos clés Maps à des domaines précis dans la console. C'est moche, mais visiblement c'est à vous de le faire.

Source : The Register

The Punisher One Last Kill : que vaut le retour de Frank Castle sur Disney+ ?

Frank Castle est de retour, mais il n'a jamais semblé aussi brisé. Avec The Punisher: One Last Kill, Disney+ tente un pari risqué : transformer la machine à tuer de Jon Bernthal en un homme hanté par ses démons, avant de le plonger dans un enfer urbain ultra-violent. Si la performance de l'acteur est impériale, le format court et certains choix scénaristiques laissent un sentiment d'inachevé.

Sortie de la saison 2 d’Ahsoka : Disney douche les espoirs des fans de Star Wars

Il va falloir s'armer d'une patience de Jedi, et peut-être même plus encore. Alors que les fans attendaient de pied ferme des nouvelles de la célèbre apprentie d'Anakin Skywalker, Lucasfilm a enfin lâché une date. Mais le soulagement a vite laissé place à la frustration : la saison 2 d'Ahsoka ne débarquera pas sur Disney+ avant le début de l'année 2027. Un calendrier qui confirme que la galaxie lointaine n'a jamais semblé aussi inaccessible.

❌