Nouveau pilote 582.28 réservé aux GPU GeForce 700/800/900/10 Series



Intel verrouille la mémoire des portables Panther Lake et lie l’étiquette iGPU à la bande passante. Conséquence directe ; les OEM n’auront plus de marge pour rogner sur la LPDDR5X.
Les intégrateurs devront utiliser de la LPDDR5X à 7 467 MT/s ou plus. En dessous, Windows 11 n’affichera qu’un générique « Intel (R) Graphics » ; au seuil ou au-dessus, le nom complet « Intel (R) Arc (TM) Graphics B390 » ou « B370 » s’affichera dans le Gestionnaire des tâches.

L’objectif est d’empêcher des configurations Panther Lake bridées par une mémoire trop lente. Sur ces SoC monoblocs, la LPDDR5X alimente CPU et iGPU ; une fréquence élevée conditionne le débit utile, donc le framerate et la réactivité globale.
Les SKU phares acceptent jusqu’à 9 600 MT/s, plafond actuel de la LPDDR5X. Les offres OEM incluant ce sommet de gamme existent déjà, ce qui laisse entrevoir des portables correctement dimensionnés côté bande passante.

Intel développe aussi un SoC Panther Lake orienté consoles portables, avec un Arc B380 attendu. La puce conserverait 12 cœurs Xe, avec un binning et des fréquences légèrement réduites pour maintenir des performances proches à TDP inférieur.
La même contrainte de vitesse mémoire s’appliquera, avec un intérêt accru en mobile. Les OEM pourront viser 9 600 MT/s pour maximiser le rendement perf/W des iGPU Arc dans un châssis compact.

Au-delà du marquage, l’imposition des 7 467 MT/s répond à un enjeu de cohérence produit : un iGPU Arc B390/B370 sans bande passante se comporte en sous-régime et plombe l’expérience. Normaliser la LPDDR5X accélère l’adoption d’Arc mobile en limitant les configurations « pièges » sur le segment mainstream et handheld.
Source : TechPowerUp
Les premiers binnings du Ryzen 7 9850X3D tombent avec 13 échantillons passés au crible, et les scores SP se resserrent. Conséquence directe : un profil très proche du 9800X3D, mais à des fréquences et tensions plus hautes.
Les overclockers sugi0lover et chunmu82 publient une première salve de résultats orientés « silicon lottery », pas un concours de FPS. Sur 13 puces, HardwareLuxx agrège un SP moyen de 120, avec une plage de 118 à 121, une fréquence enregistrée à 5,624 GHz et une tension moyenne de 1,320 V.

Chunmu82 indique que certains « samples » étrangers repérés en ligne peuvent afficher des SP plus élevés que des unités retail locales selon les lectures ASUS, ce qui complique les comparaisons. À équipement similaire, le 9850X3D demande plus de tension sur les boosts élevés que le 9800X3D : HardwareLuxx relève 1,341 V en single-core contre 1,119 V pour le 9800X3D.

Les premiers logs s’appuient sur une X870E APEX, DDR5-6000 CL26 G.SKILL et un watercooling custom stabilisé à 20 °C côté eau. Les résultats mémoire sont jugés sains. Côté silicium, chunmu82 note des rendements de cœurs meilleurs sur le Ryzen 7 9800X3D, quand le 9850X3D semble un peu plus favorable au PBO en comportement de boost.
| Entrée | Fréquence | Tension | Score SP (Silicon Prediction) |
|---|---|---|---|
| 9850X3D CPU #1 | 5.625 MHz | 1.290V | 120 |
| 9850X3D CPU #2 | 5.625 MHz | 1.271 V | 120 |
| 9850X3D CPU #3 | 5.625 MHz | 1.272V | 120 |
| 9850X3D CPU #4 | 5.625 MHz | 1.299V | 121 |
| 9850X3D CPU #5 | 5.625 MHz | 1.287V | 120 |
| 9850X3D CPU #6 | 5.625 MHz | 1.318V | 119 |
| 9850X3D CPU #7 | 5.625 MHz | 1.301V | 120 |
| 9850X3D CPU #8 | 5.625 MHz | 1.325V | 120 |
| 9850X3D CPU #9 | 5.625 MHz | 1.317V | 119 |
| 9850X3D CPU #10 | 5.625 MHz | 1.311 V | 120 |
| 9850X3D CPU #11 | 5.622 MHz | 1.355V | 118 |
| 9850X3D CPU #12 | 5.624 MHz | 1.338V | 119 |
| 9850X3D CPU #13 | 5.611 MHz | 1.348V | 118 |
| HWL Sample | 5.624 MHz | 1.320V | 120 |
Les données HardwareLuxx ne sont pas strictement comparables : la rédaction allemande a utilisé une ProArt X670E-Creator WIFI, même si la DDR5-6000 était aussi au menu. Cette hétérogénéité carte mère/BIOS pèse sur la lecture des SP et des VID.
Au vu de ce lot, le Ryzen 7 9850X3D apparaît très proche du 9800X3D, simplement cadencé plus haut et avec une exigence en tension supérieure sur les pointes. Pour l’overclocking, la fenêtre attendue reste similaire à celle du 9800X3D, avec des variations liées au SP et au couple carte mère/BIOS.
À ce stade, la dispersion SP relativement serrée (118–121) suggère des échantillons plutôt homogènes, mais l’écart de tension relevé en boost pourrait impacter l’enveloppe thermique et les marges PBO en usage soutenu selon le refroidissement et le plafond de PPT.
Source : VideoCardz, Uniko’s Hardware, HardwareLuxx
Samsung Electronics a officialisé une annonce majeure pour les joueurs : l’intégralité de sa gamme de téléviseurs OLED 2026, ainsi que ses moniteurs gaming Odyssey OLED, sera compatible avec la technologie NVIDIA G-SYNC. Un choix stratégique qui confirme l’orientation gaming très marquée de la marque coréenne, alors que NVIDIA reste la référence côté GPU pour […]
L’article Tous les téléviseurs et moniteurs OLED gaming Samsung 2026 seront compatibles NVIDIA G-SYNC est apparu en premier sur HardwareCooking.
Si vous utilisez Notepad++, faut que vous sachiez qu'il s'est passé un truc moche. Entre juin et décembre 2025, les serveurs de mise à jour de votre éditeur de texte préféré ont été carrément piratés. Et c'est carrément une opération d'espionnage probablement menée par un groupe parrainé par l'État chinois. Ouin 🥲.
En gros, les attaquants ont réussi à compromettre l'infrastructure de l'ancien hébergeur du projet. Du coup, ils ont pu détourner le trafic de mise à jour pour rediriger certains utilisateurs vers des serveurs malveillants. Ces serveurs envoyaient ensuite des fichiers de mise à jour vérolés au lieu des vrais binaires. C'est le genre de nouvelle qui file des frissons dans le dos quand on sait que des millions de dev utilisent ce logiciel quotidiennement.
Les hackers ont exploité une vulnérabilité dans le script getDownloadUrl.php et ont gardé un accès interne jusqu'au 2 décembre dernier. Heureusement, Notepad++ a depuis migré vers un nouvel hébergeur beaucoup plus costaud et sécurisé.
Donc si vous avez fait une mise à jour durant cette période, y'a de fortes chances que vous soyez concernés. L'outil de mise à jour WinGup manquait apparemment de contrôles de vérification suffisants, ce qui a permis cette redirection.
C'est moche de voir un outil open source aussi iconique se faire cibler de la sorte.
Heureusement, l'équipe de développement a réagi. Voici donc ce qu'il faut faire pour dormir tranquille :
Ensuite, un petit coup de nettoyage avec un antivirus ne fera pas de mal et si vous cherchez des alternatives le temps que ça se tasse, vous pouvez jeter un œil à Notepads ou même NotepadNext qui font du super boulot.
Bref, restez vigilants et ne traînez pas pour faire le ménage sur votre PC !

Vous connaissez sûrement TradingView pour suivre les cours de la bourse / crypto, et son fameux langage Pine Script. C'est top pour bidouiller des indicateurs techniques sans se prendre la tête, mais dès qu'on veut sortir du bac à sable pour intégrer ça dans un bot perso ou un backend, ça se corse sévère. Alors moi je fais pas tout ça, ni trading, ni dev autour du trading, mais je sais qu'on peut se retrouver souvent bloqué par les limites de la plateforme.
Hé bien bonne nouvelle pour tous les traders en culottes courtes qui n'ont pas encore compris que le DCA c'est + efficace que le day-trading, Alaa-eddine (un lecteur fidèle, coucou !) a bossé sur un projet qui va vous plaire : PineTS .
PineTS ce n'est pas encore l'un de ses parseurs bancal mais un vrai transpiler ET un runtime complet qui permet d'exécuter du code Pine Script directement dans un environnement Javascript ou TypeScript. Il vous faudra évidemment Node.js et votre bon vieux navigateur pour que ça fonctionne.?
Vous prenez votre script ta.rsi(close, 14), vous lancez un npm install pinets et hop, ça tourne sur votre serveur. PineTS gère la "transpilation" (non, c'est pas quand on a chaud sous les bras ^^) à la volée et fournit une implémentation des fonctions standard de Pine Script (v5 et v6). Il supporte déjà plus de 60 indicateurs techniques (SMA, EMA, MACD, Bollinger...), le multi-timeframe et même le streaming de données temps réel.
Du coup, ça ouvre des portes assez dingues ! Et si vous vous demandez si Pine Script est similaire à JavaScript, la réponse est "pas tout à fait", mais PineTS fait le pont entre les deux mondes. Vous pouvez grâce à ça récupérer des données de marché via n'importe quelle API (CCXT, Binance...), les passer à la moulinette PineTS, et utiliser le résultat pour trigger des ordres ou nourrir une IA.
Attention par contre, tout n'est pas encore supporté à 100%. Sauf si vous restez sur du standard, là c'est royal... Mais si vous utilisez des fonctions graphiques très exotiques, faudra vérifier tout pour ne pas finir sur la paille. Le seul truc qui manque peut-être, c'est une compatibilité totale avec les scripts v4, mais bon, on est en v6 maintenant et pour la logique de trading pure, c'est propre.
D'ailleurs, pour ceux qui utilisent ChatGPT pour écrire du Pine Script, sachez que vous pouvez maintenant intégrer ces snippets générés par l'IA directement dans vos propres applis Node.js. C'est quand même plus flexible que de copier-coller ça dans TradingView à chaque fois.
Et ce n'est pas tout (hé oui ^^) car pour la partie visuelle, il a aussi sorti également QFChart , une bibliothèque dédiée pour afficher le tout avec de jolis graphiques financiers. C'est le combo gagnant pour se faire un dashboard de trading sur mesure sans dépendre de l'infra de TradingView.
Perso, je trouve ça génial pour ceux qui veulent garder la main sur leur exécution ou faire du backtesting sérieux avec leurs propres données. En fait, c'est exactement ce qu'il manquait aux traders-developpeurs pour coder leur propre logique de A à Z. Le projet est open source et dispo sur GitHub et y'a même un playground pour tester vos scripts en live et voir la transpilation en temps réel.
Si vous faites du trading algo, ça vaut clairement le coup d'œil.
PineTS est à découvrir ici ! Et un grand merci à Alaa-eddine pour le partage !

Ce matin, je discutais avec Emmanuel (un lecteur fidèle) sur mon Linkedin Korben et il m'a partagé une ressource vraiment chouette. Si comme moi vous jouez un peu parfois avec un serveur Proxmox qui tourne à la maison pour vos expérimentations ou votre domotique, vous savez que configurer chaque VM ou conteneur LXC peut vite devenir chronophage. On copie-colle des commandes, on installe des dépendances, on se plante, on recommence... La routine quoi sauf que cette routine peut vite devenir reloue.
Hé bien, fini la galère !!!! Le projet dont je veux vous parler aujourd'hui s'appelle Proxmox VE Helper-Scripts et c'est une collection communautaire de scripts (plusieurs centaines !) qui permet d'installer et de configurer tout un tas de services en une seule ligne de commande.
En gros, c'est une immense boîte à outils pour votre hyperviseur. Vous avez besoin d'une instance Home Assistant pour gérer des ampoules connectées ? Hop, vous lancez le script et ça vous crée le conteneur LXC tout propre. Vous voulez monter un serveur média avec Plex ou Jellyfin ? Pareil, c'est généralement plié en quelques minutes (selon votre connexion évidemment).
Vous allez sur le site, vous cherchez l'outil qui vous intéresse, vous copiez la commande bash fournie (du style bash -c "...") et vous la collez dans le shell de votre nœud Proxmox. Et hop, l'assistant se lance. Il vous pose quelques questions (IP statique ou DHCP, espace disque, RAM... ce genre de trucs classiques) et puis tente de s'occuper de tout le reste (si les planètes sont bien alignées et que votre karma est au top !).
Je trouve ça génial parce que non seulement ça gère l'installation, mais ça s'occupe aussi des mises à jour. Mais bon, attention quand même parce qu'une mise à jour upstream peut parfois casser le script, donc prudence. C'est d'ailleurs super utile si vous utilisez Proxmox sur un Raspberry Pi (via Pimox), même si l'architecture ARM peut poser souci avec certains scripts. D'ailleurs, bonne nouvelle pour les utilisateurs de Pimox : il existe Pimox-Scripts , un portage de ces mêmes Helper Scripts mais adaptés spécifiquement pour ARM/Raspberry Pi. Tous les scripts ne sont pas encore dispos (moins de contributeurs), mais y'a déjà de quoi faire !
Parmi les scripts disponibles, on retrouve les classiques Docker, AdGuard Home, Pi-hole, mais aussi des trucs plus pointus pour le monitoring ou la sécurité. C'est vraiment très complet, y compris si vous êtes dans une optique de création de lab de cybersécurité .
Après, je dois quand même vous faire une petite mise en garde de circonstance. Car comme d'habitude, exécuter des scripts bash trouvés sur le net direct en root... comment dire... c'est jamais sans risque. Le code est open source et maintenu par une communauté active, ça facilite l'audit, mais ce n'est pas une garantie de sécurité absolue. Sauf si vous aimez vivre dangereusement, jetez toujours un œil au code avant de valider. La confiance n'exclut pas le contrôle !!
Un grand merci à Emmanuel pour le tuyau initial et à Karl pour l'info sur Pimox-Scripts !

Si vous faites du "vibe coding" avec Claude ou Codex, vous savez que laisser un agent IA faire sa life, c'est un peu risqué. Si celui-ci se met à exécuter des rm -rf sur votre ordi de boulot, vous êtes dans la merde !
Heureusement, Kevin Lynagh a sorti Vibe et pour vous résumer le délire, c'est une VM Linux ultra-légère capable de sandboxer vos agents IA.
Hop, on commence par installer Vibe. Plusieurs options s'offrent à vous :
curl -LO https://github.com/lynaghk/vibe/releases/download/latest/vibe-macos-arm64.zip
unzip vibe-macos-arm64.zip
sudo mv vibe /usr/local/bin
Et là, c'est prêt. C'est du Rust pur compilé avec le framework Virtualization.framework d'Apple, donc ça va viiiiite !
Et ce que vous pouvez voir au lancement de Vibe, c'est le mapping entre vos dossiers locaux liés à Claude, Codex et compagnie, et les dossiers qui sont dans la VM.
Pour démarrer une VM, c'est aussi simple que ça :
./vibe
Oui, c'est tout. 10 secondes plus tard, vous avez un shell Linux avec un accès réseau et un partage automatique de vos dossiers. Notez jute que la première fois il faut une connexion réseau pour télécharger l'image de base de Debian. Après, tout est en local.
Le truc cool, c'est que Vibe utilise un système copy-on-write où chaque VM part d'une image de base commune et seules les modifications sont stockées. Comme ça même si vous lancez 10 VMs, ça bouffe pas votre SSD.
Bon ok, j'en ai lancé que 2 en vrai mais l'idée est là ^^
Ensuite c'est simple, il suffit de lancer la commande Claude ou Codex directement dans le terminal que ça vous a créé, de les configurer comme si vous étiez sur votre ordinateur et puis c'est parti, vous pouvez les lancer avec le mode --yolo pour Codex ou avec --allow-dangerously-skip-permissions pour Claude.
Et c'est tout ! Si ça fait de la merde, ce sera dans la VM et vous ne risquerez rien ! Les fichiers sont bien sûr créés et dispo dans le répertoire dans lequel vous avez lancé vibe. Mais tout sera exécuté dans la VM donc y'a plus aucun risque.
Bref, si vous faites du vibe coding et que vous voulez pas finir avec un sudo rm -rf / généré par une IA un peu trop enthousiaste... bah voilà quoi. Le tout en moins de 1200 lignes de Rust, open source sous licence MIT.
Taaadaaaa ! À découvrir ici !

![]()
![]()
![]()
![]()
Un nouvel échantillon grimpe à 5,7 GHz en charge et creuse l’écart sur Geekbench. Les écarts se stabilisent autour de +10 % face au 285K.
Un résultat Geekbench liste un système ASUS ROG STRIX Z890-E GAMING WIFI équipé d’un Intel Core Ultra 9 290K Plus, 24 cœurs répartis en 8+16, et 64 Go de DDR5-6800. La fiche indique une fréquence maximale relevée à 5,7 GHz durant le test, et 5,6 GHz en valeur de pic listée.

Par rapport à une précédente fuite du même 290K Plus (3456 mono, 24610 multi), ce nouvel essai progresse d’environ 2,3 % en mono et 2,0 % en multi. Attention toutefois aux variables : l’ancien run tournait sur une Gigabyte Z890 AORUS TACHYON ICE avec 48 Go de DDR5-8000 et un profil d’alimentation Balanced, comparaison non homogène.
Le tableau officiel Geekbench du Core Ultra 9 285K affiche 3200 en mono et 22560 en multi. Face à ces valeurs, le nouveau run du Core Ultra 9 290K Plus ressort à environ +10,5 % en simple cœur et +11,3 % en multicœur.
Le 270K Plus, attendu aux côtés des 250K et 290K, a également fuité avec la même topologie 24 cœurs mais à fréquence inférieure. Vu récemment à 3235/21368 sur une Gigabyte Z890 EAGLE WIFI7 avec 64 Go de DDR5-4800, il se cale proche du 285K.
Intel n’a pas encore officialisé un rafraîchissement Arrow Lake « Plus » pour LGA-1851. La répétition des configurations 24 cœurs laisse penser à un travail centré sur les fréquences et l’optimisation plateforme, plus que sur l’architecture.
Si ces écarts se confirment en tests applicatifs et jeux, le 290K Plus devrait afficher des gains appréciables en productivité multicœur grâce à ses fréquences rehaussées. Reste à savoir si Intel a également optimisé les latences inter-tiles et l’interconnexion entre P-cores, E-cores et cache L3 , un point sur lequel la firme reste muette.
En l’absence de ces améliorations structurelles, les limitations en gaming observées sur le 285K risqueraient de persister malgré la puissance brute supplémentaire : la série Ultra 200 n’a jamais manqué de performances théoriques, mais bien de réactivité dans les échanges de données critiques pour le jeu. Un refresh purement fréquentiel suffira pour dominer en multi-thread ; pour rattraper AMD et les anciens Raptor Lake en gaming, il faudrait une refonte plus profonde de l’architecture tile.
Source : VideoCardz