Andrey Letov vient de sortir Notepad++ for Mac , un portage natif Apple Silicon de l'éditeur culte créé par Don Ho. Notez quand même que Don Ho n'a rien à voir avec ce projet. C'est un portage communautaire indépendant, lancé en mars dernier.

Vous récupérez le binaire universel qui tourne nativement sur les puces M1 à M5 et sur les vieux Macs Intel. C'est de l'Objective-C++ compilé pur jus avec le même moteur d'édition Scintilla qu'utilise la version Windows (Scintilla est cross-platform avec un build Cocoa officiel).

Après, tout le reste a dû être refait à la main, parce que le Notepad++ original utilise massivement Win32 pour son interface. Letov a donc réécrit la couche UI from scratch en Cocoa pour coller aux conventions macOS, avec menus, dialogues, file pickers et raccourcis clavier qui se comportent comme ceux d'une vraie app Mac.

L'interface de Notepad++ sous macOS

Côté prérequis, comptez sur macOS 11 (Big Sur) au minimum, en dessous ça ne tournera pas. Donc si vous êtes resté sur Catalina ou plus vieux, ouais, désolé pour vous, faut passer votre tour.

Côté fonctionnalités, on retrouve le pack classique du Notepad++ qu'on connaît, coloration syntaxique pour 80 langages, recherche regex, find in files, bookmark de lignes, recherche incrémentale, split view pour bosser sur deux fichiers en parallèle, enregistrement de macros pour automatiser les tâches répétitives, écosystème de plugins, et l'interface dispo dans plus de 90 langues.

C'est gratuit, sous licence GPL v3 mais attention quand même, les plugins Windows compilés en .dll ne sont pas portables tels quels. Il vous faudra une version macOS recompilée pour chacun, et le catalogue dispo aujourd'hui est forcément plus maigre qu'en face. Bref, du Notepad++ comme on l'aime, mais avec moins d'extensions pour l'instant.

Après tant que Letov tiendra le rythme, ça roulera, mais le jour où il décrochera ou que la version Windows partira dans une direction qu'il ne suit pas, le port macOS va probablement diverger ou s'éteindre. On verra bien.

En attendant, si vous bossez sur Mac et que Notepad++ vous manque depuis votre époque Windows (on fait tous des erreurs ^^), foncez le tester, l'app a l'air bien fichue à première vue et le projet itère vite.

Bref, j'espère que ça durera.

Docker Desktop bouffe la RAM comme vous le saucisson à l'apéro. Et même quand vous n'utilisez pas cette RAM, d'autres outils comme Lima ou Colima prennent aussi de la RAM.

Mais c'était sans compter sur smolvm , le projet de BinSquare et de l'équipe smol-machines, qui s'attaque au problème par un autre angle, à savoir utiliser des microVMs hardware-isolées qui bootent en moins de 200 millisecondes, qu'on configure en TOML, et qu'on peut packer dans un seul binaire .smolmachine qui tournera sur n'importe quel Mac ou Linux compatible.

Pas de daemon ni de service à lancer en background, non, c'est juste un bon vieil outil CLI codé en Rust qui boote une VM par workload et s'éteint quand c'est fini !

Ainsi, quand vous tapez :

smolvm machine run --image alpine -- sh -c "ma commande"

ça vous sort un noyau Linux complet avec son propre kernel, isolé via Hypervisor.framework sur Mac ou KVM sur Linux et tout ça en moins de temps qu'il n'en faut à Docker Desktop pour afficher sa fenêtre de démarrage. LOL

Le réseau est désactivé par défaut, mais si vous voulez l'activer, vous pouvez whitelister uniquement les domaines autorisés. Cette approche "deny by default" est rare dans l'écosystème conteneur, où en général on ouvre le réseau d'abord et on filtre après.

La fonctionnalité qui sort vraiment du lot, c'est surtout le packing en format .smolmachine. Concrètement, vous prenez votre image Docker (Python 3.12, Postgres, ce que vous voulez...), vous lancez :

smolvm pack create --image python:3.12-alpine -o ./python312

Et hop, magie magie, vous avez un exécutable totalement autonome avec tout ce qu'il faut dedans : kernel, rootfs, dépendances et tutti quanti comme disent les Allemands !

Plus besoin comme ça, d'installer quoi que ce soit du côté du destinataire de votre app. Vous balancez simplement votre binaire à un collègue, il le lance, et ça marche. Il est content, vous aussi, c'est trop bien, y'a plus qu'à aller boire ce truc dégeu qu'on appelle dans le sud, "un petit jaune" pour célébrer ça !!

Sous le capot, le moteur de virtualisation s'appuie sur libkrun , une bibliothèque VMM développée par Red Hat dans le cadre de l'initiative rust-vmm. Pour les noobzzzz, rust-vmm est un effort communautaire qui partage des composants Rust de virtualisation entre plusieurs projets : Firecracker (AWS), Cloud Hypervisor (Intel), crosvm (Google), libkrun (Red Hat) et donc smolvm.

Du coup les améliorations sur la mémoire ou la sécurité bénéficient à tous en parallèle. Côté kernel, smolvm embarque libkrunfw, un noyau custom optimisé pour démarrer hyper vite. J'ai testé, ça tient sa promesse < 200 ms !

La mémoire est élastique via virtio balloon ce qui fait que le host n'engage que ce que le guest utilise vraiment et récupère le reste automatiquement. Et les vCPUs dorment dans l'hyperviseur quand ils sont idle (en attente), ce qui permet d'over-provisionner sans payer le prix.

Côté sécu, y'a des détails qui sont cools aussi comme le SSH agent forwarding du host qui est exposé au guest sans jamais que les clés privées n'entrent dans la VM. En effet, c'est l'hyperviseur qui fait barrière donc vous pouvez cloner un repo privé depuis une VM jetable, comme un cochon, sans risquer d'exfiltrer vos identifiants si le code que vous lancez est foireux.

Et chaque workload a son propre kernel, donc une faille dans le kernel guest reste cantonnée à cette VM. Top hein ? Comparé à un conteneur Docker classique où une CVE kernel touche tout le host, c'est un autre niveau d'isolation.

Au niveau des concurrents, Firecracker (AWS) tourne uniquement sous Linux et vise les workloads serverless du cloud, mais pas le poste dev. Kata Containers de son côté fait du microVM mais boot en environ 500ms et nécessite une stack containerd lourde.

QEMU est puissant c'est sûr, mais boot en 15 à 30 secondes selon la config, donc oubliez, la vie est trop courte ! Quant à OrbStack dont je vous parle tout le temps puisque c'est l'alternative à Docker Desktop sur Mac qui est la plus aboutie aujourd'hui, ça reste quand même un outil proprio qui se repose sur Docker.

smolvm lui, boxe dans une autre catégorie puisque c'est une lib SDK embarquable, et pas juste un CLI, et son format .smolmachine n'a pas d'équivalent direct. C'est donc plus proche de l'esprit de Nix ou des binaires statiques Go, mais avec une isolation hardware réelle.

Sachez-le, en 2026, environ 42% des commits GitHub viennent de code généré ou assisté par IA. Je sais, ça en défrise pas mal mais c'est la nouvelle réalité.

Sauf qu'à chaque fois que vous lancez un script Python ou un paquet npm non relu, codé par une IA, vous prenez potentiellement un risque. En effet, à chaque fois, que vous donnez à du code potentiellement malveillant un accès direct à vos credentials, votre système de fichier ou encore votre réseau, vous vous exposez.

Ce bon vieux chmod +x && ./run.sh servi avec du café et beaucoup d'espoir, c'est terminé ! smolvm vous propose de basculer vers un modèle où l'isolation est l'état par défaut, et où ouvrir le réseau ou votre système de fichiers est une décision vraiment explicite. Donc parfait pour laisser des agents IA faire leur vie sur vos projets sans prendre de risques.

Notez que le support GPU est dans une branche séparée, et pas encore mergé. Et le projet est principalement piloté par BinSquare avec un Discord modeste derrière, et pas une fondation booster aux milliards d'Amazon ou de Google. Du coup ne déployez pas ça en prod sans backup... Mais pour du dev, de la sandbox d'agents IA, ou tout simplement pour distribuer votre binaire, c'est déjà très solide.

Et comme ça bouffe moins de RAM que Docker Desktop, sur un MacBook avec 16 Go, la différence se sent immédiatement.

Pour l'installer, ça passe par curl :

curl -sSL https://smolmachines.com/install.sh | bash

ou un download manuel depuis les releases GitHub.

Lancez ensuite

smolvm --help

ou ce hello world :

smolvm machine run --net --image alpine -- sh -c "echo 'Hello world from a microVM' && uname -a"

Et à vous de jouer !

Si vous voyagez avec un Macbook qui contient des trucs trèèèès sensibles, faut absolument que vous alliez tester cet outil.

PanicLock est le bouton "panique" qu'Apple n'a jamais voulu faire. Grâce à cela, en un clic, Touch ID se désactive totalement.

Plus de biométrie, et retour au mot de passe obligatoire pour rouvrir la session. Parce que oui, Touch ID, c'est ultra pratique au quotidien, sauf quand un agent à la frontière ou un flic un peu trop curieux vous demande gentiment (ou de force) de poser votre doigt sur le capteur de votre machine.

Sur iPhone, Apple a prévu quand même une astuce (5 pressions sur le bouton latéral et la biométrie se désactive). Mais sur Mac, rien !

Le principe de PanicLock, c'est tout simplement de cliquer sur l'icône dans la barre de menu ou d'appeler un raccourci clavier de votre choix et voilà ! Votre Mac se verrouille alors en désactivant Touch ID au passage.

Les devs ont aussi prévu une option "Lock on Close" qui déclenche le panic mode automatiquement lorsqu'on referme l'écran du Macbook, ce qui est la fonctionnalité la plus utile de tout le pack ! Vous fermez l'écran, et c'est mort, faut le mot de passe !

Sous le capot, ça fonctionne grâce à des fonctions natives de macOS qui sont tout simplement détournées pour permettre de désactiver la biométrie en 2 secondes. Notez que le code de PanicLock est sous licence MIT, et fonctionne 100% en offline.

Alors pourquoi c'est utile au-delà de la paranoïa que vous vous trimballez depuis que vos parents vous ont appris que vous aviez un frère adoptif secret ?

Hé bien y'a une vraie distinction juridique en jeu que j'évoquais d'ailleurs récemment dans mon article sur les cartes bancaires biométriques . En effet, aux États-Unis, la justice est divisée car en janvier 2025, la cour d'appel fédérale du District of Columbia a tranché dans US v. Brown que forcer quelqu'un à déverrouiller son téléphone violait le 5e amendement, parce que ça revient à témoigner contre soi-même.

Alors que la cour d'appel fédérale de l'Ouest Américain, elle, considère qu'un déverrouillage biométrique reste un acte physique qui n'est pas un témoignage, donc forçable. Et là, désactiver Touch ID avant un contrôle change donc tout puisque grâce à ça, on bascule dans le cas "mot de passe obligatoire", qui est mieux protégé légalement dans plusieurs juridictions. C'est exactement la même logique que la fonction iOS 18 qui affole la police , transposée côté Mac.

Je ne suis pas expert, mais je crois qu'en France, c'est un petit peu la même chose avec notre droit à ne pas nous auto-incriminer.

Côté limites, PanicLock désactive Touch ID, et c'est tout, donc si vous avez l'unlock par Apple Watch ou via une clé de sécurité, votre Mac restera quand même "ouvrable" autrement. Il faut donc penser à désactiver ces méthodes en parallèle si vous êtes vraiment dans une situation à risque.

Pour l'installer, c'est:

brew install paniclock/tap/paniclock

Vous savez cette télécommande Apple TV de première génération qui traîne dans un tiroir et dont vous ne faites rien ?

Bah y'a enfin un truc à faire avec ! Jinsoo An, alias machinarii sur GitHub, vient de sortir Hypervibe , un outil macOS qui transforme la télécommande de l'Apple TV en walkie-talkie comme disent les québecois, pour Claude Code.

Push-to-talk, swipes pour les commandes slash, boutons remappables, le tout pour coder à une seule main pendant que vous mangez vos chips au vinaigre de hipsters de l'autre.

Le principe est simple : vous tenez la télécommande comme un talkie, vous appuyez sur le bouton Siri pour parler à Claude Code (dictation Claude doit être activée préalablement), puis Play/Pause envoie le prompt, Menu fait Échap, et TV envoie un Ctrl+C pour annuler.

Et les swipes du touchpad sont mappés sur les commandes slash de Claude : swipe up pour /usage, swipe down pour /compact, swipe left pour /model, swipe right pour basculer en mode plan/auto-accept. Et comme vous pouvez vous en douter, ous les mappings sont modifiables à la volée via la barre de menu, et sauvegardés dans UserDefaults.

Hypervibe est en V0.1 expérimental, et y'a pas de binaire pré-compilé, donc vous devrez le compiler depuis les sources.

Notez quand même (parce qu'il faut rendre à César ce qui appartient à César) que Hypervibe est un fork de Remotastic de Lauschue, qui a posé les fondations du HID Siri Remote et du menu bar. Hypervibe ajoute en plus le push-to-talk, les swipes mappables sur les commandes Claude Code, et pas mal de petites subtilités pour que ça fonctionne au poil !. Côté licence c'est MIT, donc vous pouvez forker à votre tour si vous voulez ajouter votre propre layout.

Et voilà comme une télécommande à 3 balles en vente sur LeBonCoin devient un périphérique d'entrée pour Claude Code avec voix et gestures intégrés, pendant que des startups de dropshipping nous vendent des claviers "AI-native" à 300 €.

La bidouille plus fort que la douille !!

Cas pratique du week-end : ma pote Alex m'a passé son PC familial tournant sous Windows 8, car son fils a changé le mot de passe du Windows et n'a pas la moindre idée de ce qu'il a tapé. Pour faire sauter ce mot de passe sans tout réinstaller, j'utilise depuis des années la bonne vieille astuce Sticky Keys, qui consiste à booter sur une clé USB Windows pour accéder au Terminal de récupération via MAJ+F10. Sauf que pour préparer cette clé, j'avais juste mon MacBook sous la main.

Et là, surprise !

Sur Windows, Rufus fait ça en deux clics depuis dix ans. Sur macOS, ça reste un sport de combat. Boot Camp Assistant est toujours dans le dossier Utilitaires mais inopérant sur les Mac Apple Silicon, le Media Creation Tool de Microsoft ne tourne pas sur Mac, et les tutos Terminal vous font formater en exFAT sans préciser que votre install.wim va dépasser les 4 Go de FAT32.

Mais heureusement, WinDiskWriter , signé TechUnRestricted, vient combler ce trou.

Vous téléchargez d'abord la build adaptée à votre Mac depuis les releases GitHub (Intel et Apple Silicon dispo) et ensuite vous glissez votre ISO Windows 10 ou 11, vous choisissez votre clé USB dans la liste, et vous cliquez Start. Voilà. Lui s'occupe du reste : partitionnement, formatage, copie des fichiers, et surtout le split automatique de l'install.wim en plusieurs install.swm dès que la taille dépasse les 4 Go.

Ce point vaut une explication, parce que c'est là où la plupart des tutos Mac plantent en silence. En fait, depuis certaines ISO de Windows 10, le fichier install.wim qui contient l'image disque compressée pèse plus de 4 Go. Or FAT32 plafonne chaque fichier à 4 Go (très précisément 4 GiB moins 1 octet), et la majorité des firmwares UEFI bootent par défaut sur du FAT32, sauf à charger un pilote tiers genre UEFI:NTFS.

Donc soit vous formatez en exFAT et vous priez pour que le PC cible accepte le boot, ce qui est loin d'être garanti sur les machines un peu anciennes comme c'est mon cas ici. Soit vous splittez le .wim en plusieurs morceaux que le bootloader Windows sait recombiner à l'install. WinDiskWriter effectue la deuxième option par défaut, comme ça vous n'avez rien à configurer.

Et côté création de clé USB pure, il propose des trucs que Boot Camp Assistant ne faisait pas. Le patch Windows 11 intégré contourne également les vérifications TPM, la RAM minimale et le Secure Boot. Bref, c'est super pratique pour réinstaller Win 11 sur un PC qui ne coche pas les cases officielles.

Le BIOS Legacy est géré pour les vieilles machines, et la liste des Windows supportés remonte jusqu'à Vista, en x64 comme en x32. À noter quand même que le projet ne fournit pas de build macOS 32-bit, donc ce sera inutilisable sur des Mac Intel pré-2010. Mais bon, ça ne concerne plus grand monde.

Notez par contre que WinDiskWriter ne bypasse PAS l'obligation de compte Microsoft online introduite avec Windows 11 22H2. Donc si vous comptez vraiment réinstaller, vous devrez toujours sortir cette bonne vieille astuce OOBEBYPASSNRO en ligne de commande pour créer un compte local.

Du coup, une fois la clé prête, j'ai pu dérouler la procédure Sticky Keys et Alex a récupéré l'accès à son PC. Et tant qu'à faire, j'en ai profité pour rafraîchir cette vieille machine. D'abord upgrade Windows 8 vers Windows 8.1 avec la mise à jour normale du Store Microsoft. Puis Windows 8.1 vers Windows 10 grâce à la clé USB préparée avec WinDiskWriter, en lançant setup.exe depuis Windows 8.1 actif pour conserver la licence. Et enfin Windows 10 vers Windows 11 avec Flyoobe , dont je vous ai parlé en détail dans un autre article.

Bref, trois upgrades en chaîne, données préservées, et le PC d'Alex qui repart sur du Windows 11 récent et à jour (même sans TPM) !

Si vous bossez sur Mac et que Docker Desktop commence à vous prendre la tête, les amis, y'a une alternative super cool qui vient de débarquer. Ça s'appelle Mocker , c'est écrit en Swift, c'est sous licence AGPL-3.0, et le principe c'est de remplacer la CLI de Docker à l'identique : mêmes flags, mêmes formats de sortie, même syntaxe pour Compose. mocker run, mocker ps, mocker compose up (...bref, le README annonce 111 commandes et sous-commandes couvertes avec les flags qui matchent).

Pour l'installer, un brew tap us/tap && brew install mocker et c'est plié !

La plupart des images Docker Hub standards (format OCI) se pullent pareil, et votre fichier docker-compose.yml tourne le plus souvent sans rien retoucher. Attention quand même, si vous avez encore Docker Desktop qui tourne en parallèle, coupez-le avant de jouer avec mocker sinon vos ports vont faire la bagarre !

De plus, certaines features Docker très spécifiques (options de runtime exotiques, images qui tapent dans des sockets Linux particuliers) peuvent planter ou produire un avertissement côté Apple Containerization. Mais sur du stack web classique (nginx, postgres, redis, node), par contre, ça passe crème.

Mais alors, pourquoi ça fonctionne aussi bien ?

Hé bien parce que Mocker ne réinvente pas la roue, il l'enrobe. Rien de plus, rien de moins. En fait, sous le capot, c'est le framework Apple Container qui fait tout le boulot.

Pour rappel, c'est ce truc qu'Apple a sorti à la WWDC 2025 et qui permet ainsi de lancer une petite VM Linux dédiée par conteneur (au lieu de la grosse VM partagée à la Docker Desktop). Mocker délègue alors tout au binaire container d'Apple pour run, stop, exec et logs, tape directement dans le Containerization.ImageStore pour les pulls et les tags, et gère les ports via un petit proxy TCP userspace.

L'état des conteneurs, images, réseaux et volumes est alors stocké en JSON dans le dossier ~/.mocker/ sur votre Mac. Comme y'a rien de magique, vous pouvez tout inspecter à la main, ce qui est plutôt chouette !

Côté perfs, il y a quand même un coût. Selon les benchmarks publiés par le dev sur sa machine Apple Silicon, au démarrage d'un container Docker Desktop tourne à 320 ms, le CLI container d'Apple à 1030 ms, et Mocker à 1153 ms (3,6× plus lent que Docker, ~120 ms d'overhead sur Apple).

Dans la vraie vie, 800 ms de plus au boot c'est transparent si vous relancez 5 containers par jour en dev, mais ça devient clairement pénible si vous faites du CI local intensif avec 50 runs à la chaîne. Sur ces mêmes benchmarks, une fois que le container est up, CPU et mémoire s'en sortent ensuite pareil. Autrement dit, la VM par conteneur coûte au boot, mais pas au runtime. En tout cas, sur cette config de test pour les benchmarks.

Si vous voulez une alternative plus mature et commerciale, OrbStack reste encore une fois la référence sur Mac, mais c'est du freemium. Mocker, lui, est gratuit et open source du début à la fin.

Voilà les amis, si vous êtes sur Mac Apple Silicon et que Docker Desktop vous saoule, ça vaut grave le coup de tester !! Au pire vous revenez à Docker, au mieux vous gardez Mocker et vous arrêtez de payer la licence Business...

Apple confirme que macOS Tahoe 26 sera la dernière grande version compatible avec les Mac Intel. Une page historique se tourne au profit d’Apple Silicon.

Cet article macOS Tahoe 26 scelle la fin des Mac Intel a été publié en premier par GinjFo.

TRELLIS est un modèle IA capable, à partir d'un texte ou d'une image tout ce qu'il y a de plus normal, de générer un modèle en 3D. C'est développé par Microsoft Research et c'est assez génial. D'ailleurs j'en avait parlé en février dernier quand la bête ne tournait encore que sur des cartes NVIDIA.

Sauf que voilà, ça ne fonctionnait pas sur Apple Silicon, mais uniquement sur les machines compatibles CUDA. Enfin, jusqu'à aujourd'hui, puisque grâce au développeur Shivam Kumar, on dispose maintenant d'un portage pour les architectures Apple via PyTorch MPS.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/trellis-mac-limage-to-3d-de-microsoft-passe-sur-apple-silicon/trellis-mac-limage-to-3d-de-microsoft-passe-sur-apple-silicon-1.mp4">lien vers la vidéo</a>.

Apple prévoirait d'intégrer à iOS 27 des fonctions d'annulation et de rétablissement pour la gestion de l'écran d'accueil, tout en mettant l'accent sur la stabilité du système et l'autonomie de la batterie.

L’article iOS 27 : le changement discret qui pourrait plaire au plus grand nombre est apparu en premier sur Tom’s Hardware.

Sandbox-exec, c'est un utilitaire en ligne de commande dont pas grand monde ne parle mais qui est intégré à macOS et qui permet de lancer n'importe quel programme dans un bac à sable sécurisé, avec des restrictions sur mesure. Apple l'a déprécié, mais ça marche toujours... et c'est franchement pratique.

Avec ce truc, il suffit de créer un petit fichier de profil (extension .sb) et vous lancez votre commande avec sandbox-exec -f profil.sb votre_commande. En faisant ça, le programme de votre choix tournera dans un environnement verrouillé où il ne pourra accéder qu'à ce que vous autorisez explicitement.

Ensuite, vous avez deux philosophies. Soit vous bloquez tout par défaut et vous n'autorisez que le strict nécessaire, c'est-à-dire l'approche parano parfaite pour tester du code louche. Soit vous autorisez tout et vous ne bloquez que ce qui craint. La première est plus sûre, la seconde plus rapide à mettre en place.

Voici un exemple concret pour avoir un terminal coupé du réseau. Suffit de 3 lignes de profil (c'est du LISP) :

(version 1)
(allow default)
(deny network*)

Vous utilisez du matériel Elgato et un Mac ? Alors l'application Lolgato devrait vous intéresser car elle ajoute des fonctions en plus pour les lampes Elgato.

Le post Lolgato : l’outil qui booste le matériel Elgato sur Mac ! a été publié sur IT-Connect.

Bryan Keller vient de publier le résultat d'un projet un peu fou : il a porté Mac OS X 10.0 Cheetah sur la Nintendo Wii. La console de 2006 démarre sur le bureau Aqua avec clavier et souris USB. C'est lent, c'est limité, mais ça marche.

Pourquoi c'est possible

La Wii utilise un processeur PowerPC 750CL, un descendant direct du PowerPC 750CXe qui équipait les iBook G3 et certains iMac G3 au début des années 2000. C'est la même famille de processeurs, ce qui rend le portage techniquement envisageable.

La Wii dispose de 88 Mo de RAM (24 Mo de SRAM rapide et 64 Mo de GDDR3), ce qui est juste suffisant pour Mac OS X 10.0, dont les exigences minimales étaient de 128 Mo. Il a fallu jongler un peu.

Le noyau de Mac OS X, XNU, est open source via le projet Darwin. C'est ce qui a rendu le portage possible : sans accès au code source du noyau et du modèle de drivers IOKit, le projet n'aurait pas pu aboutir.

Comment il a fait

Keller a écrit un bootloader sur mesure qui charge le noyau depuis une carte SD et crée un "device tree" qui décrit le matériel de la Wii au système. Il a aussi patché le noyau pour l'adapter au hardware spécifique de la console, avec des corrections sur la gestion de la mémoire et le framebuffer.

Côté drivers, il a développé un driver pour le SoC Hollywood de la Wii, un driver de carte SD (qui communique avec le coprocesseur ARM Starlet de la console), un driver d'affichage qui convertit le signal RGB en YUV pour la sortie vidéo, et un driver USB pour le clavier et la souris. Le projet, baptisé "wiiMac", est disponible sur GitHub.

Ce qui marche et ce qui ne marche pas

Mac OS X démarre jusqu'au bureau Aqua. On peut installer le système et l'utiliser avec un clavier et une souris USB. La carte SD est accessible. Par contre, il n'y a ni Wi-Fi, ni Bluetooth, et le GPU de la Wii n'est pas exploité.

Les performances sont très limitées. Le projet avait démarré en 2013, mais Keller l'a repris sérieusement en 2025 après avoir vu le portage de Windows NT sur Wii.

Mac OS X sur une Wii, ça n'a aucune utilité pratique. Mais c'est quand même un joli tour de force technique. 

Source : Bryan Keller

J'sais pas si vous vous en rendez compte mais les agents IA qui codent sur votre machine ont accès à vos clés SSH, vos credentials AWS, votre Keychain et compagnie. Ils ont accès à TOUT ! C'est comme filer les clés de votre appart à un gars que vous avez croisé sur le parking de Leclerc y'a pas 5 min.

Hazmat prend le problème à l'envers : au lieu de demander poliment à l'agent de se tenir tranquille, il l'enferme dans un compte macOS séparé. Du coup, vos ~/.ssh, ~/.aws, votre Keychain deviennent structurellement inaccessibles. Pour en profiter, faut faire un

brew install dredozubov/tap/hazmat

cd /tmp

hazmat init --bootstrap-agent claude

Vous vous souvenez d'eMule ? Le petit âne qui monopolisait votre connexion ADSL pendant 3 jours pour télécharger un fichier de 700 Mo... et les fameux "Linux_ISO.avi" qui n'étaient absolument pas des ISOs Linux ?

Eh bien le bougre est de retour sur macOS. macMule c'est eMule packagé en .app native, compatible Apple Silicon via Rosetta 2, zéro configuration. Vous glissez dans Applications, vous lancez, et hop ça se connecte tout seul aux serveurs ed2k et au réseau Kad. Hé oui, ça tourne encore en 2026.

Côté technique, l'app fait environ 1 Go parce qu'elle embarque Wine Crossover (la couche de compatibilité Windows par Gcenx). Le développeur Martin Derouet a pris le build Community x64 d'eMule par irwir, l'a wrappé dans un bundle .app self-contained, et comme ça, ça se lance comme n'importe quelle app Mac.

Y'a pas de dépendances externes à installer, et surtout pas de terminal à ouvrir. Les fichiers téléchargés atterrissent alors dans ~/Library/Application Support/macMule/drive_c/eMule/Incoming/... c'est pas super intuitif comme chemin, mais au moins c'est rangé.

D'ailleurs, si vous avez suivi l'actualité de Wine 10.0 et le support ARM , vous savez que la couche de compatibilité Windows n'a jamais été aussi solide. macMule en profite directement. Et si vous voulez compiler votre propre build, le script est dispo : ./build.sh pour la dernière version stable ou ./build.sh 0.70b pour une version spécifique. Faut juste avoir Homebrew avec wine-crossover et Rosetta 2 installés.

J'ai été surpris que les réseaux ed2k et Kad soient encore debout. Mais c'est cool car ces réseaux hébergent des fichiers qu'on ne trouve nulle part ailleurs. Des archives oubliées, des vieux logiciels, des trucs que personne n'a jamais re-uploadé nulle part. C'est un peu le grenier d'Internet, poussiéreux mais plein de trésors pour qui sait chercher et plein de malwares aussi, alors gaffe à vous !

Attention quand même, ça reste un client P2P pour le réseau ed2k donc les précautions habituelles s'appliquent. Vérifiez ce que vous téléchargez, et n'oubliez pas que l'Arcom (ex-Hadopi) veille toujours au grain.

Bref, si vous avez la nostalgie du petit âne et que vous êtes sur Mac, c'est par là !

Merci à Martin pour la découverte !

Des chats en pixel art qui se baladent sur votre dock macOS et qui causent grâce à un LLM local... non vous ne rêvez pas car c'est ce qu'on peut obtenir avec CATAI , qui vous fera adopter 6 matous virtuels avec chacun sa personnalité.

En gros, c'est le Tamagotchi de votre dock, sauf qu'au lieu de biper quand il a faim, il vous cite du Nietzsche. Vous lancez l'app, et hop, un chat orange débarque. Il marche, il mange, il dort, il s'énerve... soit 368 sprites dessinés à la main (c'est devenu assez rare pour le souligner !!). Et quand le dock est masqué, le chat se téléporte directement sur le bord supérieur de votre fenêtre active. Parce que vous le savez, un chat, ça squatte toujours les rebords les plus improbables.

Vous pouvez en coller jusqu'à 6 en même temps, chacun avec sa couleur et son caractère. Le noir (Ombre) est philosophe et vous pose des questions existentielles, le blanc (Neige) s'exprime en vers, le gris (Einstein) vous balance des faits scientifiques et le brun (Indiana) raconte des aventures. De temps en temps, ils miaulent tout seuls dans des bulles pixel art. "Mrrp !", "Prrr...", "ronronronron". Perso, je trouve ça craquant.

Et quand vous cliquez sur un chat, ça ouvre une bulle de discussion connectée à Ollama (le moteur d'IA locale que vous connaissez sûrement). Si vous avez déjà un modèle qui tourne, votre matou vous répond alors avec sa propre personnalité. La mémoire de conversation est même persistante entre les sessions (max 20 messages par chat, pour garder un contexte de conversation raisonnable).

Comme c'est du Swift pur, juste les Command Line Tools suffisent pour compiler le fichier source :

swiftc -O -o cat cat.swift -framework AppKit -framework Foundation

49 jours, les amis, c'est la durée de vie d'un Mac avant que son réseau TCP ne s'effondre dans un silence assourdissant. Il suffit d'un overflow d'entier 32 bits dans le kernel XNU, une horloge interne qui se bloque, et hop, plus moyen d'ouvrir la moindre connexion. Le ping marche toujours, parce qu'ICMP se fout du TCP, mais pour le reste... c'est reboot obligatoire ou rien.

Pour savoir combien de temps il vous reste, tapez uptime dans le Terminal. Si votre Mac sous macOS Sequoia, Sonoma ou même Ventura tourne depuis plus de 7 semaines sans redémarrage, c'est le moment d'y remédier car le bug touche toutes les versions.

C'est l'équipe de Photon qui a révélé le problème. Celui-ci est apparu sur une flotte de Macs dédiée à la télémétrie iMessage. Pile 49,7 jours après le dernier redémarrage, plusieurs machines ont lâché en même temps. Plus de nouvelles connexions réseau, mais le ping répondait toujours.

En fouillant le code du noyau XNU d'Apple (qui est open source, faut le rappeler), ils sont tombé sur une variable tcp_now, qui est un compteur 32 bits qui s'incrémente chaque milliseconde. En gros, imaginez un compteur kilométrique qui arrivé au max (environ 4,3 milliards), repasse à zéro.

Sauf que le code contient un garde fou censé empêcher l'horloge de reculer du genre "si la nouvelle valeur est plus petite que l'ancienne, on ne met pas à jour". Ça a l'air malin mais en fait, au moment du rebouclage, patatras : la nouvelle valeur (proche de zéro) est forcément plus petite que l'ancienne (proche du max), du coup le garde fou bloque tout et l'horloge TCP se fige.

Et ensuite, ça part en cascade. Les connexions fermées restent normalement en TIME_WAIT durant 30 secondes sur macOS, avant d'être nettoyées par tcp_gc() mais avec l'horloge gelée, ce nettoyage ne se fait plus. Un netstat -an | grep TIME_WAIT montre alors la catastrophe en temps réel avec des connexions mortes qui s'empilent, et finissent par bouffer les 16 384 ports éphémères (range 49152-65535 sur macOS) restant... Et au bout de quelques heures, plus rien ne passe !

Photon a laissé tourner deux machines après l'overflow pour voir. Neuf heures plus tard, l'une affichait 8 000 connexions zombies et un load average de 49. La machine ne faisait plus que scanner sa propre file d'attente de connexions mortes.

Si ça vous rappelle quelque chose, c'est normal car j'sais pas si vous vous souvenais mais Windows 95 plantait au bout du même délai pour la même raison (le fameux GetTickCount() en 32 bits). Le Boeing 787 avait également un souci similaire au bout de 51 jours sur ses switches réseau, sans oublier le bug de l'an 2038 sous Unix, qui est la version signée du même phénomène. 30 ans séparent certains de ces bugs qui pourtant appartiennent à la même catégorie !

Après flippez pas car des devs avec des Macs à plus de 600 jours d'uptime disent n'avoir jamais eu le souci. À vrai dire, le bug ne se déclencherait que si votre Mac n'a aucun trafic TCP pile au moment de l'overflow. Si votre machine cause au réseau en permanence (et c'est le cas de 99% des Macs), l'horloge passe le cap sans broncher.

Les machines les plus exposées sont en fait les serveurs CI/CD sous macOS, les Mac mini en ferme de build Jenkins ou GitHub Actions, les Mac Pro dédiés au rendu 3D avec Blender ou Cinema 4D. Le MacBook qui passe en veille tous les soirs n'est pas vraiment concerné (le compteur tcp_now ne tourne pas pendant la veille, donc le délai de 49 jours ne concerne que le temps d'activité réel).

Maintenant pour vérifier votre compte à rebours personnel, ouvrez un Terminal et collez y ceci :

boot_sec=$(sysctl kern.boottime | grep -o 'sec = [0-9]*' | head -1 | awk '{print $3}')
now_sec=$(date +%s)
remain=$(( 4294967 - (now_sec - boot_sec) ))
echo "Temps restant avant overflow : $((remain/3600))h $((remain%3600/60))m"

CUPS, le système d'impression utilisé par macOS et la plupart des distributions Linux, est touché par deux nouvelles vulnérabilités. Elles ont été trouvées par des agents d'intelligence artificielle, et permettent une exécution de code à distance.

Aucun correctif officiel n'est disponible pour le moment, et les preuves de concept sont déjà publiques. Les environnements professionnels sont les premiers concernés.

Quand l'IA fait le boulot des chercheurs en sécurité

C'est un ingénieur sécurité de SpaceX, Asim Manizada, qui a publié les détails de ces deux failles. Le plus surprenant, c'est qu'il ne les a pas trouvées tout seul. Il a utilisé des agents IA pour analyser le code de CUPS et débusquer les problèmes.

Son travail s'inspire des recherches de Simone Margaritelli, qui avait déjà montré en 2024 comment enchaîner plusieurs failles CUPS pour exécuter du code à distance sur des machines Linux.

Les deux vulnérabilités portent les références CVE-2026-34980 et CVE-2026-34990. Elles touchent CUPS 2.4.16 et peuvent être combinées pour un résultat assez redoutable.

Deux failles qui se complètent

La première faille permet à un attaquant d'envoyer une tâche d'impression sur une file PostScript partagée, sans aucune authentification.

CUPS accepte par défaut les requêtes anonymes sur les files partagées, et un mécanisme d'échappement de caractères permet d'injecter du code qui sera exécuté en tant qu'utilisateur "lp". En pratique, un attaquant peut forcer le serveur à lancer un programme de son choix.

La seconde faille concerne l'authentification du démon cupsd. Un utilisateur local sans privilège peut tromper le service pour qu'il s'authentifie auprès d'un faux serveur IPP contrôlé par l'attaquant.

Le jeton récupéré permet alors d'écraser n'importe quel fichier avec les droits root. Combinées, les deux failles donnent à un attaquant distant et non authentifié la possibilité d' écraser des fichiers système en tant que root.

Pas de patch, mais des correctifs dans les tuyaux

Pour le moment, aucune mise à jour officielle de CUPS n'a été publiée. Michael Sweet, le créateur et mainteneur du projet, a mis en ligne des correctifs sur GitHub, mais il n'y a pas encore de version patchée à télécharger.

Manizada prévient que ces failles seront faciles à reproduire, vu que les preuves de concept sont publiques et que les modèles de langage actuels peuvent transformer un rapport technique en exploit fonctionnel en quelques minutes.

Côté impact, CUPS est le système d'impression par défaut de macOS et de la quasi-totalité des distributions Linux. Pour être vulnérable, il faut que le serveur CUPS soit accessible sur le réseau avec une file d'impression partagée configurée, ce qui est courant dans les environnements professionnels.

C'est quand même un drôle de signal. D'un côté, l'IA montre qu'elle sait trouver des failles de sécurité plus vite que les humains. De l'autre, les mainteneurs open source galèrent toujours autant pour sortir les correctifs à temps. Manizada lui-même le dit : les modèles de langage peuvent convertir un simple rapport technique en code d'attaque prêt à l'emploi.

Du coup, entre la divulgation d'une faille et le premier exploit, on parle de quelques heures, pas de quelques semaines. Si vous gérez des imprimantes en réseau, le plus prudent reste de couper le partage des files CUPS en attendant le patch, ou au moins de restreindre l'accès réseau au service. Pas très pratique, mais c'est le prix à payer quand le système d'impression a vingt ans de code derrière lui.

Source : The Register

J'sais pas si vous saviez mais Apple a planqué un LLM dans votre Mac et ne veut pas que vous y touchiez... enfin, pas directement. En effet, leur modèle est là, intégré au système via le framework FoundationModels, il tourne sur le Neural Engine sans connexion internet mais Apple l'a verrouillé derrière Siri. Du coup, impossible de l'appeler depuis un script ou un pipe shell et c'est là qu' apfel intervient !

L'outil s'installe en une commande :

brew install Arthur-Ficial/tap/apfel

Et hop, vous avez accès au modèle directement depuis votre terminal. Faut Apple Intelligence actif également, sinon, ça ne fonctionnera pas.

Ensuite, vous lui posez une question, et il vous répond. Vous lui "pipez" un fichier, et il le traite. Et le tout sans rien télécharger puisque le modèle est déjà sur votre machine !

C'est un LLM de 3 milliards de paramètres, quantifié en 2 et 4 bits, qui tourne nativement sur la puce Apple Silicon (M1 et au-delà) et il se défend plutôt bien face à Qwen-2.5-3B, si on en croit les benchmarks. La fenêtre de contexte est limitée à 4096 tokens (entrée + sortie combinées), soit environ 3000 mots, donc faut pas espérer lui faire digérer un roman mais pour transformer du texte, classifier des données ou résumer un paragraphe... ça fait bien le taf.

Apfel expose donc ce modèle de trois façons différentes. En CLI pure (compatible stdin/stdout, sortie JSON, codes d'erreur propres), en serveur HTTP compatible OpenAI sur localhost:11434 (avec streaming SSE, tool calling et CORS activé), et en chat interactif multi-turn.

Le serveur OpenAI c'est malin parce que d'un coup, tous vos outils savent causer à l'API OpenAI (Cursor, Continue.dev, n'importe quel SDK) et peuvent utiliser l'IA locale de votre Mac sans rien changer à leur code. Et le support MCP (Model Context Protocol) natif c'est très chouette aussi puisqu'il suffit de lancer apfel avec le flag --mcp, pour qu'il découvre automatiquement les outils disponibles, exécute les appels et renvoie les résultats.

D'ailleurs côté vie privée, c'est du béton armé car le framework FoundationModels d'Apple n'a pas accès à vos contacts, emails, calendrier ou photos et tout tourne sur le Neural Engine et le GPU, sans connexion internet.

Si vous avez déjà bidouillé avec Ollama et les modèles locaux , apfel c'est un peu la même philosophie... sauf que là vous n'avez rien à télécharger et contrairement à Perspective Intelligence qui transforme votre Mac en serveur web avec PostgreSQL et tout le tralala, apfel reste hyper minimaliste.

Attention quand même, faut être sous macOS 26 Tahoe minimum donc si vous êtes encore sous Sequoia 15.x ou Ventura 13.x, c'est mort, le framework FoundationModels n'existe pas sur ces versions. Et si vous avez un Mac Intel... ben non plus, le Neural Engine c'est Apple Silicon only.

Le projet inclut aussi des scripts démo sympas dans le dossier demo/.

Y'a par exemple cmd qui convertit du langage naturel en commandes shell, explain qui décortique les messages d'erreur, gitsum qui résume vos commits récents, ou encore mac-narrator qui commente l'activité de votre système en temps réel (c'est votre Mac qui se raconte à lui-même).

Perso, cmd c'est celui qui m'a le plus plu, même si bon, avec 4096 tokens de contexte, faut pas lui demander des commandes ffmpeg de 200 caractères.

Mais au-delà des démos, c'est en vrai que ça devient fun. Je vous montre quelques usages classiques d'abord :

apfel -f README.md "Résume ce projet en 3 phrases"

apfel -f code.py -s "Tu es un développeur expérimenté" "Trouve les bugs"

echo "Traduis ça en allemand : Salut" | apfel

Et les trucs un peu plus funs :

git diff HEAD~1 | apfel -f CONVENTIONS.md "Review ce diff par rapport à mes conventions"

apfel -f old.swift -f new.swift "Qu'est-ce qui a changé entre ces deux fichiers ?"

demo/oneliner "compte les IPs uniques dans access.log"

Vous pouvez même piper la sortie en JSON pour chaîner avec jq, ou lancer le mode --serve et brancher Cursor dessus pour avoir de l'autocomplétion locale gratuite. Et si vous êtes du genre parano, le mode --chat avec --context-strategy summarize gère automatiquement le contexte quand la conversation dépasse les 4096 tokens.

Et côté écosystème, y'a aussi apfel-gui (une interface SwiftUI native pour chatter avec le modèle, avec speech-to-text et text-to-speech on-device) et apfel-clip qui est en développement (ce sont des actions IA qui s'ajoutent dans la barre de menus pour corriger la grammaire, traduire, résumer) et le tout sous licence MIT, évidemment.

Bref, c'est un super modèle mais avec 3 milliards de paramètres et 4096 tokens de contexte, faut pas s'attendre non plus à remplacer Claude ou GPT. Les maths complexes, la génération de code avancée et les longues conversations, c'est pas son truc mais pour du scripting, de la classification ou transformer du texte à la volée... ça dépanne carrément !

Et ce modèle préfère refuser plutôt qu'halluciner, ce qui est plutôt une bonne surprise je trouve. Voilà, si vous avez un Mac Apple Silicon sous macOS Tahoe, apfel et ses outils valent le coup d'œil pour vos petites tâches IA basiques / rapides de tous les jours.

Au sein de macOS Tahoe 26.4, Apple a introduit une petite nouveauté destinée à mieux protéger les utilisateurs contre les redoutables attaques de type ClickFix.

Le post macOS 26.4 : le Terminal s’arme contre les attaques ClickFix a été publié sur IT-Connect.