❌

Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierFlux principal

Nano11 - Windows 11 passe sous la barre des 3 Go

✇Korben
Par : Korben
13 septembre 2025 à 14:21

2,8 Go. C’est tout ce qu’il faut à Nano11 pour faire tourner Windows 11. Et cette prouesse, on la doit à NTDEV, le développeur derrière le projet Tiny11 que vous connaissez peut-être déjà. Ce dernier vient encore de repousser les limites du dégraissage de Windows à un niveau que même Microsoft n’aurait jamais imaginé.

Pour mettre les choses en perspective, faut savoir qu’une installation standard de Windows 11 pèse facilement entre 20 et 30 Go selon les versions. Avec Nano11, on parle d’un ISO de seulement 2,2 Go et d’une empreinte disque de 2,8 Go une fois installé. C’est donc 3,5 fois plus petit que Tiny11, qui était déjà considéré comme ultra-léger.

Alors comment NTDEV a-t-il réussi cet exploit ? Et bien en virant absolument tout ce qui n’est pas indispensable au démarrage du système. Et quand je dis tout, c’est vraiment TOUT. Windows Update ? Dégagé. Microsoft Defender ? Aux oubliettes. Teams, Copilot, le nouveau Outlook qui est une catastrophe ambulante ? Disparus. Même les applications les plus basiques comme Météo ou Actualités ont sauté.

Le développeur ne cache pas que Nano11 est un “script expérimental extrême” conçu pour créer un environnement de test rapide et minimaliste. Sur son blog officiel , il indique utiliser maintenant la compression LZX au lieu de XPRESS, ce qui réduit encore plus la taille finale mais demande beaucoup de RAM pendant le processus de création.

Ce qui reste après le passage de Nano11, c’est donc vraiment le strict minimum à savoir le noyau Windows, l’interface graphique de base, et c’est à peu près tout. Pas de Windows Store, pas de possibilité d’ajouter des langues ou des pilotes après coup, pas de mises à jour de sécurité. C’est une installation figée dans le temps, impossible à maintenir ou à faire évoluer.

NTDEV lui-même prévient que Nano11 n’est absolument pas destiné à un usage quotidien. C’est plutôt pensé pour les développeurs qui ont besoin d’un environnement Windows ultra-léger pour tester rapidement une application, ou pour faire tourner des machines virtuelles sans bouffer toute la RAM disponible. L’installation se fait rapidement, et c’est donc parfait pour des tests.

Ce qui est chouette avec ce projet, c’est qu’il démontre à quel point Windows 11 est bourré de composants optionnels. Microsoft recommande officiellement 64 Go de stockage minimum, mais en réalité, le système peut tourner avec moins de 3 Go si on enlève tout le superflu.

Pour ceux qui veulent tester, le script Nano11 est disponible sur GitHub et il fonctionne avec n’importe quelle édition de Windows 11 (Pro, Home, LTSC). Le script prend en charge toutes les architectures et peut créer une image dans n’importe quelle langue, mais attention, une fois installé, impossible d’en ajouter d’autres. La dernière version de septembre 2025 est compatible avec Windows 11 24H2 et même les builds Canary les plus récentes.

Alors c’est sûr que Nano11 ne remplacera jamais votre Windows principal. C’est un proof of concept technique plus qu’autre chose mais si vous avez un vieux PC qui traîne ou si vous voulez créer une VM Windows ultra-légère pour un test rapide, ça peut valoir le coup d’œil.

Maintenant pour les utilisateurs qui cherchent un compromis entre légèreté et fonctionnalité, le script tiny11maker.ps1 reste une meilleure option car il dégraisse Windows tout en gardant la possibilité d’installer des mises à jour et d’ajouter des fonctionnalités par la suite.

Amusez-vous bien avec ce truc !

Obs.js transforme votre site en un caméléon qui s'adapte à chaque visiteur

✇Korben
Par : Korben
3 septembre 2025 à 15:09

Alors rien à voir avec le logiciel de streaming, mais sachez que Harry Roberts, le consultant en performance web derrière CSS Wizardry (et accessoirement un mec qui a bossé avec Google, la BBC et l’ONU), vient de sortir Obs.js .

L’idée de ce truc, c’est de transformer votre site web en véritable caméléon. Au lieu de servir la même expérience à tout le monde, la bibliothèque va détecter en temps réel les conditions de navigation de chaque visiteur. Batterie presque vide ? Connexion 2G pourrie ? Le site s’adapte automatiquement.

Pour cela, Roberts utilise des APIs natives du navigateur qui existent depuis des années mais que presque personne n’exploite vraiment. La Battery Status API et la Network Information API sont là, dans Chrome et consorts, à attendre qu’on leur trouve une utilité. Et voilà, Obs.js débarque et les combine de façon intelligente pour créer quelque chose de vraiment utile.

Mais alors concrètement, ça donne quoi ?

Et bien ce script ajoute des classes CSS directement sur votre balise <html>, comme ça…

<html class="has-latency-low
 has-bandwidth-high
 has-battery-charging
 has-connection-capability-strong
 has-conservation-preference-neutral
 has-delivery-mode-rich">

Et quand vous avez un visiteur avec 5% de batterie, hop, une classe .has-battery-critical apparaît.

.has-battery-critical * {
 animation: none !important;
 transition: none !important;
}

Vous pouvez alors désactiver toutes les animations et transitions avec une simple règle CSS. Plus besoin de JavaScript complexe ou de détection côté serveur. C’est propre !

Mais ça va bien plus loin que la batterie puisqu’Obs.js catégorise aussi la qualité de la connexion de vos visiteurs. Une connexion forte, modérée ou faible, et votre site peut s’adapter en conséquence. Vous pouvez ainsi servir des images haute résolution aux utilisateurs sur fibre, et des versions compressées à ceux qui galèrent en 3G Free ^^ dans le métro.

body {
 background-image: url('banner-4k.jpg');
}

.has-delivery-mode-lite body {
 background-image: url('banner-optimized.jpg');
}

Je trouve cette approche très progressive car si le navigateur ne supporte pas ces APIs ( Safari ne supporte ni Battery ni Network Information API ), le site peut continuer à fonctionner normalement. Roberts recommande d’ailleurs de placer le script directement en inline dans le <head> de votre page, avant tout autre script. Il précise cela pour que la détection se fasse le plus tôt possible et que les classes soient disponibles dès le premier render.

De plus, l’objet window.obs exposé par la bibliothèque vous donne accès à toutes les métriques collectées. Vous pouvez ainsi savoir si le Data Saver est activé, si l’appareil est branché sur secteur, ou même détecter les changements de réseau en temps réel. Imaginez les possibilités pour une progressive web app qui doit gérer des modes offline !

En plus, ce type d’optimisation adaptative peut réduire significativement la consommation de données et améliorer les temps de chargement. Il est possible en implémentant cela et en faisant les aménagements nécessaire, d’économiser jusqu’à 40% de bande passante pour les utilisateurs ayant des connexions lentes. C’est énorme quand on sait que chaque seconde de chargement supplémentaire peut faire perdre 20% de conversions.

La version actuelle est déjà fonctionnelle et disponible sous licence MIT et le support navigateur est principalement orienté Chromium pour l’instant, mais c’est déjà une base solide pour commencer à expérimenter.

Et connaissant le profil de Roberts (le mec a littéralement écrit le livre sur les performances CSS), j’imagine qu’on peut s’attendre à ce que le projet évolue rapidement…

Pour l’implémenter, c’est vraiment simple. Vous récupérez le script sur GitHub, vous le minifiez si nécessaire, et vous le collez dans le head de votre HTML. Pas de npm, pas de webpack, pas de configuration compliquée. C’est à l’ancienne !

Voilà, je me suis dis que pour les développeurs qui me lisent, ça peut vous permettre par exemple d’adapter votre stratégie de lazy loading, de modifier la fréquence de vos appels API, ou même de changer complètement l’architecture de votre app selon le contexte. Vous pourriez par exemple désactiver le polling temps réel des utilisateurs qui ont une petite connexion, et le passer en mode manuel.

Bref, si vous faites du développement web et que vous vous souciez un minimum de l’expérience utilisateur, Obs.js mérite un petit coup d’oeil !

Super Mario 64 - Le jeu qui gaspillait la mémoire de la N64

✇Korben
Par : Korben
30 août 2025 à 06:45

Ce matin, j’ai lu un truc qui m’a fait tilter. Vous saviez que Super Mario 64, ce chef-d’œuvre absolu qui a changé le jeu vidéo à tout jamais, était en fait un gouffre à mémoire sur Nintendo 64 ? C’est un programmeur nommé Kaze Emanuar s’est amusé à disséquer le code source et les résultats de son analyse sont plutôt… surprenants.

Pour comprendre l’ampleur du problème, il faut se replacer dans le contexte. La N64 avait 4 Mo de RDRAM rapide. Pour vous donner une idée, c’est à peine la taille d’une photo prise avec votre smartphone aujourd’hui. Et dans ces 4 Mo, il fallait caser les textures, le code, la musique, les buffers de sortie et les états des acteurs. Autant dire que chaque octet comptait.

Et pourtant, Mario 64 dilapidait cette précieuse mémoire comme s’il n’y avait pas de lendemain. Le jeu semble en effet avoir été livré dans une version debug avec “du code inutile partout”.

Le système audio à lui seul bouffe 512 Ko. Mais le plus dingue, c’est qu’au lieu de réutiliser intelligemment les buffers, le jeu alloue 4 buffers d’échantillons par note alors qu’un seul suffirait. Du coup c’est 51 Ko de RAM qui partent en fumée, soit l’équivalent de 17 textures. Ouch.

Les fonctions mathématiques ne sont pas en reste non plus. Les tables de sinus et cosinus auraient pu être divisées par quatre grâce à la symétrie circulaire, économisant 12 Ko supplémentaires. C’est assez pour 4 nouvelles textures de plus et un léger gain de performances.

Mais le plus gros gâchis se trouve sans doute dans la gestion des objets. Chaque acteur, même les plus simples, se voit allouer 608 octets peu importe sa complexité. Une allocation uniforme complètement inutile qui fait mal au cœur de tout développeur qui se respecte. Et je ne parle même pas du chargement des assets ! Le jeu charge des banks mémoire complètes incluant des objets totalement non pertinents comme des algues ou des mines aquatiques, alors qu’un seul élément est nécessaire.

Le build NTSC de Mario 64 n’utilisait même pas les optimisations du compilateur. Comme si Nintendo avait oublié d’activer le mode “optimisé” avant de lancer les cartouches en production. Mais bon, avant de taper sur l’équipe de développement, remettons les choses en perspective. On parle de 7 programmeurs qui avaient seulement 20 mois pour créer un jeu incroyable sur une console dont le hardware et les outils de développement étaient encore en cours de finalisation. Dans ce contexte, avoir 4 Mo de RAM rapide, c’était le luxe absolu et l’optimisation pouvait attendre.

Les travaux récents de programmeurs comme Kaze Emanuar montrent donc qu’avec les techniques modernes, on peut obtenir des performances 6 fois meilleures en utilisant le N64 Expansion Pack, qui est quelque chose que l’équipe originale n’avait pas.

La preuve que les développeurs ont appris de leurs erreurs c’est The Legend of Zelda: Ocarina of Time, sorti plus tard, qui était infiniment plus optimisé. Les leçons avaient été tirées et les outils s’étaient améliorés.

Au final, Mario 64 reste un monument du jeu vidéo malgré ses défauts techniques. Et franchement, quand on voit le résultat final, on se dit que quelques Mo gaspillés, ça valait largement le coup pour un jeu qui a changé l’industrie.

Source

❌
❌