J'ai pas mal de déplacements pro en ce moment, et comme je suis sur plein de projets en même temps, c'est un peu relou. Parce que tout ne tourne pas uniquement sur mon ordi portable. J'ai des traitements un peu plus lourds qui tournent par exemple sur mon Mac Studio et faut dire que je lui en fais vraiment voir de toutes les couleurs à celui-là...

La plupart du temps, j'arrive heureusement à tout gérer à distance en me connectant en SSH à l'ordinateur via mon VPN privé (ça me permet d'avoir toutes mes machines sur le même réseau local virtuel comme ça c'est chiffré et sécurisé) mais il arrive parfois que je doive cliquer sur un bouton ou taper un mot de passe via l'interface de macOS.

Jusqu'à présent pour ce genre de choses, j'utilisais donc l'application Partage d'Écran fournie par Apple, mais je ne sais pas vous, chez moi ça lag furieusement et c'est vraiment pas pratique à utiliser. Bref, j'aime pas.

Je me suis donc rabattu sur des Real VNC et compagnie, mais pareil, ce n'est pas un protocole et des clients que je trouve très efficaces. Et j'avais pas envie non plus de payer un peu au pif une app présentée comme meilleure comme celle-ci d'Apple pour voir ce que ça donne :

Du coup, je me suis créé à l'aide d'agent IA, ma propre application de prise de contrôle à distance en y mettant toutes les fonctionnalités dont j'avais besoin.

Ça s'appelle Korben Remote Desktop et ça fonctionne en deux parties. On a d'un côté un petit agent sur l'ordi à contrôler, qui demande juste les autorisations système "Enregistrement de l'écran" et "Accessibilité" (sans oublier la fonctionnalité de Session à distance activée dans Partage, pour le tunnel SSH au niveau des réglages de macOS), et de l'autre côté le client sur le Mac que vous avez sous les yeux. Les deux se parlent ensuite à travers un tunnel SSH chiffré, sur votre réseau local ou votre VPN privé, sans passer par aucun serveur chez moi ni ailleurs puisque l'appli refuse carrément les adresses IP publiques pour des questions de sécurité.

Voici tout ce que j'ai mis en place dans cette application :

• Une image fluide, jusqu'en 4K. Capture ScreenCaptureKit, encodage HEVC ou H.264 par la puce du Mac, transport UDP chiffré avec de la parité Reed-Solomon pour encaisser les paquets perdus. Qualité au choix (Automatique, 720p, 1080p, 4K ou Native) et cadence de 30, 60 ou 120 images par seconde.
• Un Wi-Fi qui coupe n'est plus un drame. Une micro-coupure est traitée comme un retard et pas comme une perte, et trois priorités de présentation (Réactif, Équilibré, Fluide) règlent le tampon selon que vous voulez la latence la plus basse ou aucun gel d'image.
• Le son aussi. Le son système du Mac distant arrive au format Opus, et si y'a pas de son, aucune bande passante n'est consommée pour ça.
• Souris, clavier et raccourcis. Défilement précis, boutons latéraux compris, et les raccourcis partent au Mac distant tant qu'il a le clavier (⌘C copie là-bas, pas chez vous). Ceux du client sont donc basculés en ⌃⌥⌘ pour ne pas leur marcher dessus.
• Un mode jeu. Capturer la souris (⌃⌥⌘G) cache le curseur, envoie le mouvement brut sans le bloquer aux bords de l'image et passe le clavier en touches physiques, donc W reste la touche W quelle que soit la disposition. Les manettes passent aussi, en expérimental.
• Tous les écrans. Vous passez d'un écran à l'autre, ou vous les affichez tous à la fois (⌃⌥⌘A), rangés comme sur le Mac distant, le pointeur passe de l'un à l'autre et une fenêtre se tire d'un écran à l'autre. Un écran branché ou débranché pendant la session apparaît ou disparaît tout seul.
• Zoom et plein écran. Un zoom comme celui de macOS (pincement à partir du curseur, déplacement à deux doigts, double toucher) et un plein écran système dont la barre d'outils se range.
• Les fenêtres des apps distantes, chez vous. Une fenêtre d'une application du Mac distant (un Terminal du Studio, par exemple) peut s'ouvrir comme une fenêtre indépendant sur votre Mac. Vous la déplacez, la redimensionnez, vous tapez et cliquez dedans, et c'est l'application distante qui répond. Quand elle a accès au clavier, la barre des menus de votre Mac affiche même les menus de cette application distante, et un clic droit y ouvre le vrai menu contextuel du Mac distant.
• Fichiers et presse-papiers. Presse-papiers texte partagé, transfert de fichiers dans les deux sens, y compris en glisser-déposer vers et depuis le Finder distant. Un transfert interrompu peut également reprendre sans tout recommencer. Les fichiers reçus sont ensuite mis en quarantaine, comme n'importe quel téléchargement.
• Reconnexion automatique. Si le lien tombe, l'image se grise et le client réessaie jusqu'à ce que vous l'arrêtiez, en gardant vos fenêtres déportées. Et si aucune session n'est ouverte sur le Mac distant (après un redémarrage, par exemple), l'appli vous propose alors d'ouvrir le Partage d'écran d'Apple pour taper votre mot de passe, puis reprend la main dès que l'agent est prêt (J'ai pas d'autre choix que de faire comme ça).
• Un Mac qui ne montre rien pendant que vous bossez dessus. Durant une session, l'écran du Mac distant est noir pour quelqu'un qui passerait devant, son clavier et sa souris sont bloqués et ses haut-parleurs sont coupés (le son, lui, continue d'arriver chez vous). À la déconnexion, l'agent demande au lecteur multimédia de se mettre en pause (s'il peut le faire) et verrouille la session, par défaut.
• Un accès depuis un simple navigateur. L'agent peut aussi ouvrir un accès web, à démarrer explicitement dans sa fenêtre. Vous copiez un lien à usage unique valable quinze minutes, vous l'ouvrez dans Safari ou Chrome sur votre réseau privé, vous comparez l'empreinte du certificat avec celle affichée par l'agent, et vous retrouvez l'écran, le son, le zoom et le contrôle sans rien installer. Les fichiers et les fenêtres séparées restent réservés au client Mac.
• Sécurisé par défaut. Tunnel SSH obligatoire pour le client natif (votre compte SSH est la clé, aucun compte à créer nulle part), TLS avec échange de clés ECDHE et ChaCha20-Poly1305 pour le lien de contrôle, AES-256-GCM pour l'image et le son, adresses publiques refusées, et un seul viewer à la fois (le deuxième doit demander la place au premier, qui répond oui ou non).
• Une vraie app Mac. Barre latérale avec vos Macs, barre d'outils native, fenêtre Réglages, menus complets, mode sombre, français ou anglais selon la langue du système, et les Macs du réseau qui ont la session à distance activée sont trouvés tout seuls par Bonjour. Les statistiques du flux (⌃⌥⌘I) donnent la latence, la gigue, le tampon et les pertes, et une "liaison économe" allège tout d'un coup pour un réseau lent ou compté.

Ce que ça ne fait pas encore par contre, c'est pas de réveil à distance, pas de déverrouillage FileVault après un redémarrage à froid (prévu sur macOS 26, mais pas encore validé), les gestes du trackpad comme la rotation ou le balayage à trois doigts ne passent pas, et le verrouillage des majuscules reste celui du Mac distant. Il faut macOS 14 minimum des deux côtés, et les deux applications sont universelles, Apple Silicon comme Intel (testées sur Apple Silicon, l'Intel et macOS 14 restent à valider).

Maintenant pour pour l'utiliser tous les jours, ce que je peux vous dire c'est que ça marche très bien. Maintenant, j'ai pas eu d'autres testeurs que moi-même pour le moment mais ça fait tout ce dont j'ai besoin.

Et je me suis payé le luxe également d'adapter le code (en version ultra alpha, j'ai pas encore assez testé ça) pour Windows et Linux. Et l'application iOS est également sur les rails.

Maintenant, comme d'hab, j'ai essayé de la mettre sur l'App Store d'Apple mais ils sont tellement casse couilles que je ne sais pas si j'y arriverai. Mais peu importe, je me suis dit que ça vous servirait alors je vous ai fait un petit site ici pour télécharger mon app : remotedesktop.korben.info .

C'est 100% gratuit, y'a aucune télémétrie ni pub dedans et je n'ai pas de plan de carrière avec ce logiciel si ce n'est de l'améliorer par petites touches au fil du temps. Je l'ai créé pour mes besoins et je me suis dit que ce serait dommage de ne pas vous en faire profiter, c'est tout.

Voilà, donc n'hésitez pas à tester. C'est conçu pour macOS mais j'ai décliné ça pour Windows et Linux (je le redis, c'est de l'alpha pour Win et Linux) afin que chaque client puisse prendre le contrôle de n'importe quelle machine peu importe son système d'exploitation.

Enjoy !

Omar Khaled, lecteur de Korben.info et développeur m'a envoyé un petit mail pour me faire découvrir sa dernière réalisation : Shotnix . Comme vous le savez, même si je fais une petite pause en ce moment, j'ai l'habitude de faire pour mes Patreons et ma chaine Youtube des tutos en screencast pour vous montrer quelques bidouilles.

Donc forcement c'est le genre d'outil qui m'intéresse puisque Shotnix permet d'enregistrer votre écran pour faire ce genre de contenus ou simplement montrer par exemple une manip à un collègue ou à un client. Cette app gratuite pour Mac est tellement bien conçue que quand vous avez terminé votre enregistrement, la vidéo qui s'ouvre alors est déjà montée !

Si vous avez jeté un œil au stockage de votre Mac sous macOS 27 récemment, vous avez forcément croisé ce gros bloc "Données système" que Réglages Système ne vous explique jamais vraiment en détail.

Mais c'était sans compter sur MacSpace , une appli libre qui s'attaque justement à ce truc-là, et qui s'occupe également au passage des modèles d'Apple Intelligence histoire de gagner un peu de place.

En réalité, "Données système" n'est pas un dossier mais tout le bordel et l'espace dont macOS a besoin. Mais quand on creuse un peu, on peut découvrir grâce à MacSpace à quoi tout ceci correspond dans le détail.

Données système ventilé par catégorie, avec l'historique des versions marqué Irréversible

Le bouton "Libérer" supprimera alors ce qui ne craint pas. Je pense aux caches des applications fermées, les rapports de diagnostic et de plantage datés de plus de 7 jours, et les ressources système inutilisées. De son côté, l'historique des versions de vos documents a son propre bouton, marqué "Irréversible" puisque les anciennes versions partent pour de bon. En effet, n'espérez pas retrouver ce que vous avez supprimé avec MacSpace dans la corbeille.

Notez bien que pour ces ressources système, comme pour les fichiers marqués purgeables et les modèles d'IA, ce n'est pas MacSpace qui s'occupe de la suppression. L'app confie ce travail à CacheDelete, l'outil de purge que macOS lance lui-même quand le disque est presque plein, sans toutefois indiquer quels fichiers il emporte. Mais bon, vous ne prendrez pas grand risque puisque ces fichiers se téléchargeront ou se créeront à nouveau s'ils redeviennent nécessaires, et MacSpace ne touchera bien sûr jamais à vos documents, à Photos, à Mail ni à Messages.

Le module "Autres fichiers système" retirera aussi du Mac les copies locales de vos fichiers OneDrive ou iCloud Drive, qui resteront dans le cloud et reviendront dès que vous les ouvrirez.

Et puis il y a Apple Intelligence dont je vous parlais il y a quelques jours avec l'outil RemoveMacAI , qui supprime les modèles restés sur le disque et bloque leur retour avec un profil renvoyant leurs téléchargements vers un port local fermé. Hé bien MacSpace passe par une autre porte puisqu'il règle Siri sur une langue différente de celle du Mac, ce qui suffit à macOS pour décider qu'Apple Intelligence n'est pas dispo. MacSpace peut alors purger les modèles, qui peuvent peser 12 Go si pas plus.

Attention quand même, ça veut dire que Siri ne vous parlera plus dans la langue de votre Mac. Et avec la synchronisation iCloud de Siri activée, ce changement de langue débarquera aussi sur votre iPhone et votre iPad. MacSpace vous prévient bien sûr et vous montre comment couper cette synchro. Pour revenir en arrière, il suffit après de rebasculer l'interrupteur pour retrouver votre langue et votre voix Siri d'origine (macOS pourra alors retélécharger les modèles).

Le dernier module, Debloat, aligne 14 switchs pour couper la télémétrie, les publicités personnalisées, Siri AI ou l'indexation de vos données par Apple Intelligence, dont 6 via un profil de configuration à approuver une fois. Et comme macOS rallume certains réglages tout seul (l'identifiant publicitaire revient à peu près chaque jour, d'après le développeur), MacSpace vérifie toutes les 15 minutes tant qu'il tourne et coupe à nouveau ce que macOS a rallumé, hors règles du profil.

Les switchs de Debloat et le bouton "Tout activer"

Pour réussir à faire tout ça, MacSpace installe un daemon système qui n'exécute que des opérations inscrites dans son code et n'accepte que des clients signés par la même équipe. L'app n'a aucune télémétrie, et ne se sert du réseau que pour ses mises à jour.

Côté config, il vous faut évidemment un Mac Apple Silicon sous macOS 27. C'est gratos, sous licence MIT, dispo en français, et ça s'installe soit en DMG, soit via Homebrew comme ceci :

brew install --cask 1architect/macspace/macspace

Dernier détail, il n'y a pas de désinstalleur donc avant de virer l'app, appuyez sur "Tout activer" dans Debloat et rallumez Apple Intelligence si vous l'aviez coupé, sinon les réglages modifiés resteront en place.

Source : MacSpace sur GitHub

Vous avez envie de voir à quoi ressemble Googlebook OS , mais pas du tout envie de dégainer +1000 balles pour un ordi bridé ? Ça tombe bien, un développeur a codé gbos-vm , un outil open source sous licence MIT qui lance sur un Mac Apple Silicon l'image de recovery de Google (conçu à l'origine pour le Dell Googlebook), dans une machine virtuelle boostée par le GPU.

Ce n'est donc pas un Android générique habillé en Googlebook mais un script qui télécharge l'image officielle (la build 16471258, ARM64, Android 17), en vérifiant l'empreinte, puis la fait démarrer sous QEMU avec Vulkan traduit vers Metal. Et rien de chez Google n'est redistribué dans le dépôt (pas de Playstore de base donc...).

Côté Mac, il vous faut donc un Mac avec archi Silicon, Homebrew, les outils en ligne de commande de Xcode, un JDK et le SDK Android (plateforme API 34 minimum) avec son NDK. Et comptez 16 Go de RAM en pratique car la VM en squatte 4 mais les compilations successives en auront besoin d'un peu plus. Et le script installera de lui-même tout ce qui vous manquera côté Homebrew, sans jamais vous demander un accès via sudo. Comptez environ 9 Go pour le download de tout ça et minimum 60 Go de libre pour la VM.

git clone https://github.com/skylartaylor/gbos-vm.git
cd gbos-vm
./install.sh

Ensuite, vous ouvrez l'application construite (dispo dans work/host/Googlebook VM.app), dont la mission est de lancer la VM et de l'éteindre proprement quand vous la quittez.

Le premier boot prendra environ 45 secondes sur un MacBook M5 et si un sélecteur d'utilisateur s'affiche, cliquez juste sur "User" et y'a pas de mot de passe. Notez que la souris est capturée par défaut, et que le raccourci ⌃⌥ la libèrera.

Voilà, c'est pas encore parfait car le bluetooth peut crasher, on est limité à 60 images par seconde max et que les échanges entre la VM et l'hôte (le mac) sont un peu instables mais j'imagine que tout ceci se bonifiera avec le temps...

Si vous êtes sous macOS 27, vous avez peut-être remarqué que pour désactiver Apple Intelligence, il fallait couper les fonctions une par une. Mais ce que vous ne savez probablement pas, c'est que même si vous faites ça, les modèles restent stockés sur votre disque dur. Donc forcément, ça prend de la place !!

Heureusement, il existe une application nommée RemoveMacAI qui permet de supprimer ces modèles et empêcher macOS de les retélécharger.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/removemacai-supprimer-apple-intelligence-macos-27/removemacai-supprimer-apple-intelligence-macos-27-1.mp4">lien vers la vidéo</a>.

brew install omlahore/tap/removemacai
removemacai

Whisky , l'interface qui permettait de lancer des jeux Windows sur un Mac sans bidouiller Wine à la main, n'est malheureusement plus maintenue. Son dépôt est archivé et son README nous prévient que n'importe quel jeu lancé via Whisky peut péter à tout moment !! Et je sais, c'est assez insupportable de vivre avec cette épée de Damoclès au-dessus de la tête.

Alors je vais un peu soulager votre stress en vous présentant Highball qui est une appli Mac libre, avec une version en ligne de commande, qui installe et règle Wine, DXMT et DXVK à votre place, puis vous branche sur Steam ou sur votre bibliothèque Epic pour lancer n'importe quel jeu Windows sur votre bon vieux Mac OS. Par contre, on est sur de la bêta++ mais c'est vraiment un bon candidat à la relève de Whisky.

Pour installer Highball ça passe soit par un .dmg ou par la commande brew install --cask highball, ensuite vous cliquez sur "Get started" et il installera Rosetta si besoin, téléchargera le moteur et préparera un environnement Windows aux petits oignons. Au premier lancement, Steam déballera alors son gros client de 235 Mo, et sachez que sous Rosetta ça peut prendre de 15 à 25 minutes quand même ! Et ensuite, bah tout sera rassemblé dans le dossier ~/Library/Application Support/Highball/ . Donc si vous le supprimez, ce sera pareil qu'une désinstallation.

Le gros plus de Highball c'est surtout sa base de compatibilité et pour chaque jeu, l'app vous donne le mode graphique à utiliser, et signale d'avance ceux qui embarquent un anti-triche au niveau du noyau, donc ceux qui ne tourneront pas. Voilà c'est bien de le savoir avant de télécharger quoi que ce soit et de galérer avec l'install. Foutus anti-cheats !!

Moi je l'ai connecté à mon Steam et voici ce que j'obtiens :

La bibliothèque Steam dans Highball : Portal est Vérifié, Left 4 Dead 2 et Team Fortress 2 sont Communauté, THE FINALS est Bloqué

Une fois que vous avez sélectionné votre jeu, comme ici, le Portal que j'ai installé, ça vérifie si ça peut fonctionner sur votre ordinateur. Et ensuite, Highball applique pour vous la "recette" qui va bien pour que ça tourne sans encombre sur le Mac.

La fiche de Portal : vérifié sur un M1 Pro, avec la liste des réglages que Highball applique avant le lancement

Lisez quand même bien les fiches des jeux. Parce que pour certains, vous risquez d'être surpris. Par exemple, sur Red Dead Redemption 2, c'est marqué comme jouable sur un M1 Pro mais en réalité le jeu démarre et atteint le menu, mais il n'est pas jouable de manière "confortable" sur ce Mac puisque l'image saccade, et sur 16 Go, la mémoire déborde comme quand vous mettez vos grosses fesses dans la baignoire.

J'ai lancé Portal !!!

Pour le reste, il vous faudra un Mac Apple Silicon sous macOS 14 minimum. D3DMetal, le composant d'Apple, n'est pas fourni donc faut accepter la licence du Game Porting Toolkit et il se téléchargera à part (j'avais parlé de Game Porting Toolkit 4 à sa sortie). Côté launchers, Steam et Epic passent sans souci, Rockstar et l'app EA affichent leur screen de connexion et lancent leurs jeux, mais GOG Galaxy restera malheureusement à l'état d'écran noir.

Pour ma part, j'ai lancé aussi la version remasterisée de Command & Conquer / Red Alert et ça tourne du feu de Dieu, donc je suis très content de cette install !!

Voilà les amigos, le code est sous GPL-3.0 et le projet promet qu'il n'y aura jamais d'offre payante !! Voilà, vous pouvez revendre votre licence Crossover sauf si vous avez des besoins pointus que Highball n'arrive pas à résoudre.

Windows 11 dans une machine virtuelle sur un Mac Apple Silicon, ça se fait depuis looooongtemps avec des outils comme Parallels ou UTM. Mais tart, l'outil en ligne de commande qui crée et clone des VM comme on le ferait avec des conteneurs, n'en est pas capable, parce que la virtualisation d'Apple sur laquelle il repose ne gère officiellement que macOS et Linux.

Sauf qu'un dev nommé Mustafa Akin, vient de publier un fork qui permet d'installer Windows 11 avec tart sans un seul clic.

Je viens de le tester sur mon Mac Studio M4 Max avec l'ISO française de Windows 11 et j'ai trouvé que ça fonctionnait super, d'où ce petit tuto.

Ce qu'il vous faut avant de commencer

Pour vous lancer là dedans, il vous faut donc un Mac Apple Silicon sous macOS 26.6 ou 27, Xcode pour compiler tout ça, et bien sûr une ISO de Windows 11 ARM64 ( faudra vous démerder ensuite avec la licence ). Par contre, faut le savoir, ce fork repose sur deux réglages privés d'Apple, non documentés, qu'une mise à jour de macOS pourra shooter à tout moment. Donc ne montez pas votre futur homelab là dessus sans un plan de repli.

Compiler tart et créer la VM

Sur son site, Mustafa Akin publie un binaire tout fait, mais j'ai préféré compiler le programme car le script de création du paquet de son fork signe proprement l'application en local avec le droit de virtualisation qui va bien.

git clone --branch windows-guest-extras https://github.com/mustafaakin/tart.git
cd tart
git checkout e4c623c
./scripts/package-windows-preview.sh 0.1.0-windows-preview
export PATH="$PWD/dist/windows-preview/tart.app/Contents/MacOS:$PATH"

La commande export rend ce tart.app accessible au niveau du système prioritaire devant un éventuel tart déjà installé. Il ne reste alors qu'à lui passer votre ISO... tart téléchargera alors les pilotes virtio-win et WinFsp, fabriquera son propre média d'installation et démarrera Windows sans rien demander de plus.

tart create win11 --from-iso ~/Downloads/Win11_Arm64.iso

Ça m'a pris en tout et pour tout 26 minutes pour obtenir cette VM Windows fonctionnelle. Notez également que l'installation force l'anglais américain et que d'autres langues peuvent poser souci mais avec mon ISO française, l'interface est bien restée en français. Seul le clavier est resté en QWERTY au départ.

Installer le pilote et l'agent à la mano

L'auteur écrit sur son blog que l'install de l'agent doit se faire manuellement pour l'instant mais ce qu'il a oublié de préciser c'est que le pilote viosock, celui qui relie le Mac à la VM, n'est pas dans la liste des pilotes que tart injecte (viostor, viogpudo, NetKVM, viorng et viofs). Résultat, chez moi, tart exec ne fonctionnait pas. Comme ce pilote se trouve dans l'ISO virtio-win que tart a gardée dans son cache, il suffit donc de le copier dans un dossier partagé, contenant l'agent publié avec la préversion :

hdiutil attach -readonly -nobrowse ~/.tart/cache/windows/sha256:303f7ae40dad495d6ae474fdc571df58958a4dbc5c37a522d80f9a203867949d.iso
mkdir -p ~/tart-share
cp -R /Volumes/virtio-win-0.1.302/viosock/w11/ARM64 ~/tart-share/viosock
hdiutil detach /Volumes/virtio-win-0.1.302
curl -L -o ~/tart-share/tart-guest-agent.exe https://github.com/mustafaakin/tart/releases/download/windows-preview-0.1.0/tart-guest-agent.exe
tart run win11 --dir=share:$HOME/tart-share

Comme la commande tart run garde la main, laissez-la tourner et ouvrez un second terminal pour la suite, en y refaisant l'export ci-dessous depuis le dossier tart, sinon vous appellerez un autre tart.

export PATH="$PWD/dist/windows-preview/tart.app/Contents/MacOS:$PATH"

Au démarrage, la session admin (mot de passe admin) s'ouvre alors toute seule et vous arrivez sur le bureau. Le dossier partagé apparaît sur le lecteur Z:, dans un dossier share. Ouvrez PowerShell en administrateur (et n'oubliez pas que le clavier est en QWERTY) pour installer le pilote, puis déclarer l'agent comme tâche lancée à l'ouverture de session, parce que c'est dans cette session que sont le presse-papiers et le bureau :

pnputil /add-driver Z:\share\viosock\viosock.inf /install
mkdir "C:\Program Files\Tart"
copy Z:\share\tart-guest-agent.exe "C:\Program Files\Tart\"
$a = New-ScheduledTaskAction -Execute "$env:SystemRoot\System32\conhost.exe" -Argument '--headless "C:\Program Files\Tart\tart-guest-agent.exe" --run-agent'
$t = New-ScheduledTaskTrigger -AtLogOn -User $env:USERNAME
$s = New-ScheduledTaskSettingsSet -ExecutionTimeLimit ([TimeSpan]::Zero) -RestartCount 999 -RestartInterval (New-TimeSpan -Minutes 1)
$p = New-ScheduledTaskPrincipal -UserId $env:USERNAME -LogonType Interactive -RunLevel Highest
Register-ScheduledTask -TaskName "Tart Guest Agent" -Action $a -Trigger $t -Settings $s -Principal $p
Start-ScheduledTask -TaskName "Tart Guest Agent"
Get-Service VirtioSocketWSP

Le service VirtioSocketWSP doit alors afficher Running. S'il n'existe pas, c'est que le pilote n'est pas passé et tart exec ne répondra pas. Relisez alors la sortie de pnputil et vérifiez que le dossier viosock contient bien viosock.inf.

Vérifier que le terminal de Windows répond

Retournez ensuite dans le terminal du Mac et entrez cette commande pour connaitre le numéro de version du Windows :

tart exec win11 cmd /c ver
Microsoft Windows [version 10.0.26200.8037]

Informations système dans la VM : Windows 11 Famille, build 26200, sur une "Apple Virtualization Generic Platform" en ARM64

L'intérêt de tout ça c'est surtout d'avoir un Windows jetable. Vous devez arrêtez d'abord la VM de base avec tart exec win11 shutdown /s /t 0 puis pour cloner la VM, faites un : tart clone win11 w1 . C'est instantané, et y'a plus qu'à la démarrer avec un tart run w1 --no-graphics.

Avec --no-graphics ça démarre sans fenêtre et vous pouvez alors lancer ce que vous voulez avec tart exec. Ensuite pour tout stopper, un petit tart stop w1, et un tart delete w1 pour supprimer la VM et voilà...

Ce qui ne marche pas

En tout cas, n'en faites pas votre Windows de tous les jours car il n'y a ni son ni accélération graphique, pas de possibilité de suspendre le Windows et la virtualisation imbriquée se fige dès que Windows veut démarrer WSL2 ou Hyper-V.

La commande Get-Tpm confirme aussi l'absence de TPM. Et selon l'auteur, le disque est le point faible de ce Windows ARM 64 sous tart, en partie parce que tart rempli très vite les SSD avec ses logs. Pensez aussi à changer le mot de passe, puisque le compte est admin avec le mot de passe admin, et que SSH est ouvert sur le réseau interne de tart.

Mais pour tester des logiciels Windows ou scripter des trucs, ça tient bien la route.

Source : Mustafa Akin

Je vous ai déjà parlé des fameuses collections de Retro-eXo , dont le fameux eXoDOS en tête qui contient des milliers de jeux DOS, Windows 3.x, Windows 95/98 et ScummVM livrés clé en main, tout bien configurés. Sauf que sur Mac, bah pas de bol, eXo n'est pas supporté faute de volontaire pour y porter l'interface.

Alors c'est là qu'arrive Exodium sur son cheval blanc, qui n'est ni plus ni moins qu'un merveilleux lanceur gratuit et open source pour Mac Apple Silicon, Linux et Windows et dont la mission est de remplacer LaunchBox, l'interface Windows fournie avec les collections. Le catalogue de jeux est bien sûr livré avec l'appli, donc vous parcourez les fiches sans rien télécharger, et quand un jeu vous branche, vous cliquez simplement sur "Download" et hop, il descend des torrents officiels d'eXo tel un rafteur en manque d'adrénaline, puis se lance dans l'émulateur qui va bien (ou presque... mais je vais y revenir).

L'étagère des collections, et un jeu en cours de téléchargement

Et surtout, ça ne se limite pas à eXoDOS puisque vous avez aussi ses packs allemand, espagnol et polonais, ainsi que eXoWin3x, et eXoScummVM, où chaque jeu tourne sur la version de ScummVM qui va bien pour lui (c'est eXo qui choisit).

Quant à eXoWin9x, il boote carrément un vrai Windows 95 / 98 sous DOSBox-X ou 86Box, que l'appli va chercher avec votre premier jeu Win9x, ainsi qu'environ 2,5 Go d'images système.

Moi, ce que j'adore, c'est l'ambiance avec de la musique MT-32 et General MIDI qui fonctionne au poil, puisque les ROM Roland et la banque de sons SoundCanvas sont récupérées direct dans la collection. Les manuels, les scans de boîtes et les pubs de magazines sont là aussi, et comme les vidéos d'aperçu sont lues directement dans les archives, vous pouvez voir ce que donne le jeu, avant même de le récupérer. Et pour chaque titre, vous pouvez aussi activer un shader CRT, régler les cycles CPU ou éditer la config DOSBox à la main. Bref, c'est assez souple pour que chacun s'y retrouve.

Par contre, hors Windows, les quelques 2 400 jeux qu'eXo a réglés pour DOSBox ECE (c'est une des variantes de DOSBox) passent tous sous DOSBox Staging, avec une config traduite automatiquement. La fiche du jeu vous prévient donc que l'expérience peut "varier", et comme y'a qu'une poignée de titres qui exploitent les spécificités d'ECE, comme par exemple les réglages 3dfx Voodoo ou le pistolet GunStick, les jeux peuvent se comporter parfois bizarrement ou différemment de ce dont vous avez l'habitude. Par contre, sous Windows, c'est le vrai ECE d'eXo qui se lance, donc 0 souci !

L'autre chose à savoir, et là c'est qu'Exodium est un client BitTorrent. Donc il rejoindra l'essaim d'eXoDOS et renverra des bouts de data aux autres joueurs tant qu'il restera ouvert. Ça c'est le comportement prévu par défaut, mais si vous ne voulez rien partager, il suffit de décocher l'option lors de l'installation.

Ou plus tard de couper le partage dans les réglages réseau de eXo. L'envoi tombera alors à 1 ko/s au lieu de s'arrêter. Maintenant si vous avez déjà la collection sur un disque, sachez que le mode hors ligne ne lancera pas le client torrent.

3 jeux en cours, avec le nombre de pairs et le volume partagé

Niveau installation, le DMG macOS est réservé aux Mac Apple Silicon, donc rien pour les malheureux qui sont encore sous Mac Intel. Et comme l'appli n'est pas signée avec un Developer ID Apple, Gatekeeper vous enverra chier au premier lancement, donc levez le blocage, glissez-la dans Applications, puis tapez une fois dans un terminal :

xattr -cr /Applications/Exodium.app

Ou passez par Sentinel , c'est plus simple.

Maintenant, sous Linux spécifiquement, Exodium n'est pas indispensable pour eXoDOS car les patchs Linux officiels le font déjà tourner avec leur interface exogui. Mais ça sert surtout pour eXoWin3x, eXoWin9x et eXoScummVM, qui sont totalement absents de la liste de ces patchs. Notez que sur Mac, il existe aussi le patch non officiel de NightsPaladin , mais il vous faudra la collection eXoDOS sur un disque ainsi que Homebrew et Python alors qu'Exodium, lui, vous laissera commencer l'aventure avec un seul jeu sans avoir à récup toute la collection !

Source : GitHub

Le projet Asahi Linux vient enfin de fusionner le support des Mac M3 dans son installateur. En clair, ça veut dire que si vous avez un MacBook Air, un MacBook Pro ou un iMac équipé d'un M3, d'un M3 Pro ou d'un M3 Max, vous pouvez y installer Linux dès maintenant.

Et la liste de ce qui fonctionne est plus longue que ce que je pouvais craindre. La webcam, les micros internes, le WiFi, le Bluetooth, l'USB 3 jusqu'aux 10 Gb/s permis par la machine, et le décodage vidéo accéléré, AV1 compris.

Le Thunderbolt aussi, est même arrivé cet été. Apple avait troqué, sur les M3 Pro et M3 Max, son vieux contrôleur de ports USB contre une puce ACE3 posée sur un bus SPMI au lieu de l'I2C. Il a donc fallu reverse tout ce petit monde afin que l'USB 3 et le Thunderbolt marchent sur l'ensemble de la gamme M3.

Si vous voulez vous lancer, l'installation doit encore passer par le mode Expert de l'installeur, parce que c'est encore tout frais. Mais quand la bêta de Fedora Linux 45, sera implémentée d'ici quelques semaines, ça devrait fonctionner en install normale.

Après le gros manque, c'est la 3D. N'attendez ni performances, ni accélération 3D économe en énergie puisque tout est géré par la partie CPU du M3. Et ce n'est pas de la mauvaise volonté de la part des dev puisque le GPU du M3 s'écarte nettement de celui des M1 et M2 : ray tracing matériel, mesh shaders, et le Dynamic Caching maison d'Apple. Il y a donc énormément à refaire et même si le chantier a commencé, pour le moment, on n'a pas de date.

Les autres limites ont l'air nettement moins définitives comme pour la mise en veille qui ne fonctionne pas et le port HDMI des MacBook qui est coupé. Cela s'explique par le fait que le composant DCP qui gère ces 2 aspects là c'est pas encore piloté par Asahi, mais ça ne devrait pas tarder.

Le Mac Studio, lui, reste à la rue. Le M3 Ultra n'est pas supporté, et les M4 et M5 en sont au tout début, avec le stockage, le PCIe et le démarrage multicœur qui tournent mais pas grand-chose d'autre. Donc plus votre machine est récente, plus il va falloir être patient...

Perso, j'avais un iMac M3 et franchement, j'ai été très déçu par cette machine. Pour de la bureautique ça allait très bien, mais dès qu'on bidouille un peu fort, ça pédale dans la semoule. Je suis donc passé au Mac Studio depuis et je ne le regrette pas une seconde.

En tout cas, je sais que si je veux recycler ce "vieil" iMac M3, je peux maintenant lui installer Linux... ça vaut peut-être le coup, à condition d'assumer un desktop sans la moindre accélération 3D ^^.

Source : le billet d'annonce d'Asahi Linux et Neowin .

Je ne sais pas vous, mais chez moi, mes câbles USB-C se ressemblent tous. Et dans le tas, j'en ai qui chargent mon MacBook deux fois plus vite que d'autres. Et franchement, en les regardant, je ne peux pas vous dire lesquels sont les plus efficaces. Alors que mon Mac, lui, apparemment, il le sait déjà.

En tout cas, c'est ce que j'ai compris en allant lire le site de WhatCable. Ce qu'ils expliquent, c'est qu'à chaque branchement, le contrôleur de port d'un Mac Apple Silicon envoie un message à la puce que certains câbles embarquent et récupère sa fiche d'identité : débit annoncé, ampérage, fabricant. De ce que j'ai compris, macOS range la réponse dans le registre IOKit sous forme d'objets bruts, et ne l'affiche nulle part en clair. Snif...

Et c'est cette réponse que WhatCable va chercher, puis traduit. L'app vit dans la barre de menus, vous branchez un câble, et elle vous dit alors instantanément lequel des trois maillons plafonne la charge : Soit le chargeur, soit le câble, soit le Mac lui-même quand sa batterie est presque pleine.

Et vous obtenez le même verdict côté débit.

L'app confronte aussi la fiche du câble à sa spécification USB-PD et lève un carton jaune quand quelque chose cloche. Ça peut être l'identifiant fabricant à zéro, les bits réservés utilisés de travers...etc. Moi, je parle bien ici de contrefaçon de câbles, mais l'app reste très prudente dans sa formulation. Elle signale juste des trucs bizarres, et elle ne dit jamais qu'un câble est une contrefaçon.

Après, la plupart des câbles sous 60 W n'ont aucune puce à interroger, donc il n'y a rien à lire, et certains ne répondent correctement qu'avec un appareil branché à l'autre bout. Sur les ports USB-C en façade d'un Mac mini ou d'un Studio, aucune donnée de câble ne remonte non plus. C'est à cause de l'architecture d'Apple.

Côté matériel, il vous faut donc un Mac Apple Silicon sous macOS 14 minimum, les Mac Intel ne publiant pas ces données du tout. L'app est gratuite et son code est sous licence MIT, sauf le dossier des fonctions Pro où là, faudra débourser environ 10 €.

Si vous avez Homebrew, vous pouvez installer l'app rapidement comme ceci :

brew install --cask darrylmorley/whatcable/whatcable

L'app est même en français si vous avez séché les cours d'anglais. Bref, de quoi trier votre caisse de câbles sans vous planter...

Faire tourner un modèle en local sur un Mac, c'est réglé depuis un moment. Ce qui l'est moins par contre, c'est de brancher un agent de code dessus, parce qu'à chaque reprise de session, le serveur doit malheureusement remouliner des dizaines de milliers de tokens de contexte avant de sortir le premier mot...

Ce calcul, ça s'appelle le cache KV, et la plupart des serveurs le gardent en mémoire. Du coup, quand le modèle se décharge, le cache part avec dans le grand vide...

C'est pourquoi oMLX a pris le parti d'écrire ce cache sur le disque, au format safetensors, car le contexte déjà envoyé une fois, prompt système et fichiers lus compris, se recharge depuis le SSD au lieu d'être recalculé, y compris après un redémarrage du serveur.

De son côté, LM Studio conserve lui aussi son cache MLX sur disque , mais dans un fichier temporaire qu'il efface quand le modèle se décharge. Les deux outils écrivent sur le disque, mais un seul conserve réellement son cache.

Côté raccordement, le serveur oMLX expose l'API OpenAI et l'API Anthropic ce qui permet par exemple à Claude Code de taper directement sur localhost. Et y'a même un tableau de bord qui nous dit quoi faire dans le terminal pour brancher Claude Code ou d'autres avec oMLX.

Sur oMLX, le cache disque est donc actif d'office et son plafond par défaut, parce qu'il en faut bien un, se calcule à 10 % de la capacité du disque qui l'héberge. Sur un SSD d'un téraoctet par exemple, ça fait cent gigaoctets qui peuvent partir en cache sans que personne n'ait rien demandé. Donc prévoyez un peu de place... Après rassurez-vous, ça se vide d'un clic sur un bouton dans le tableau de bord et la taille peut se régler.

Le deuxième piège est plus sournois puisqu'une installation par défaut via pip ne compile pas les kernels Metal, et les modèles GLM-5.2, MiniMax M3 et Qwen3.5 retombent alors sans prévenir sur un chemin générique... Donc je vous incite fortement à utiliser uniquement les DMG proposés qui contiennent déjà les kernels Metal compilés comme il faut.

Reste à savoir ce que ça donne vraiment dans un usage quotidien... Le cache attaque l'attente avant le premier mot mais pas la vitesse à laquelle les mots sortent ensuite donc tout dépend du modèle et de la machine que vous avez. Mais en tout cas, pour un usage avec des agents (coding par exemple), ce sera plus efficace d'utiliser oMLX que Ollama ou LMStudio.

Source : omlx.ai

Hier, je suis tombé sur ce tweet :

Kuber, un développeur de 19 ans a demandé à Claude Code, de lui pondre un pilote pour sa vieille imprimante pour macOS. Et visiblement, ça a intéressé pas mal de monde puisque le tweet a fait +3 millions de vues.

Il a ensuite publié le dépôt sur Github et la transcription complète de la session. Et ce que ça raconte c'est surtout un bras de fer avec macOS, et un montage bidouillesque au possible qui finit par tenir sur une machine virtuelle Linux et un daemon root.

Pour la petite histoire, son imprimante est une HP Laser 1008a. C'est en réalité une Samsung rebrandée car HP a racheté la division impression de Samsung , il y a une dizaine d'années. Et ces machines parlent un langage un peu niche qui est le SPL3. C'est un langage maison qui n'est ni du PostScript ni du PCL standard. Et comme vous vous en doutez, HP n'a jamais sorti de pilote macOS pour cette gamme. Donc officiellement, cette imprimante ne peut pas imprimer depuis un Mac.

La mission a donc consisté à recompiler SpliX, un pilote libre qui parle le SPL3 et à se battre avec macOS pour qu'il puisse causer via l'interface USB de l'imprimante déclarée en IPP-over-USB. Il a fallu ensuite ruser en mettant en place une VM Linux afin de faire tourner h24 un codec de HP uniquement dispo sous Linux. Et voilà ! La file d'impression envoie le travail sur un port local, un daemon root le récupère, le fait passer par le codec dans cette VM, et écrit le résultat directement sur l'USB.

Bref, ça marche et ça imprime maintenant depuis n'importe quelle application.

Alors vous l'aurez compris, ce n'est pas vraiment un dev de pilote pour macOS mais plutôt une espèce d'assemblage de différents éléments pour la plupart libres, afin de réussir à imprimer sous macOS avec ce modèle d'imprimante. Mais ce qui est intéressant, c'est que le mainteneur de SpliX a débarqué sur le dépôt de Kuber avec une archive de fichiers de test et une série de questions. Cela veut dire que si lui et Kuber trouvent l'octet qui diffère, la VM Linux et le daemon root vont disparaître et il ne restera plus qu'un paquet tout ce qu'il y a de plus classique à installer.

Voilà c'est finalement la seule partie de l'histoire où on répare vraiment quelque chose. Mais ça reste quand même une belle histoire où l'IA permet de s'affranchir des limites techniques imposées par les fabricants et éditeurs de logiciels. Et ça, moi j'adore !

Source : le fil de Kuber sur X , avec la transcription intégrale de la session et le dépôt du projet .

Vous glissez une app dans la corbeille du Mac, elle disparaît du dossier Applications, et vous pensez que c'est réglé ? Que vous êtes naïfs ! Hé oui, ce que vous ne savez pas, c'est que ses préférences, ses caches et son container restent bien présent dans votre ~/Library, parfois pendant des années, encombrant votre espace disque pour rien.

Hé bien s'occuper de tout ce merdier, c'est le job de PureMac , une app native codée en SwiftUI qui piste ces fichiers-là pour libérer des ressources sur votre mac. Elle croise l'identifiant du bundle, celui de l'équipe de développement, les entitlements et les métadonnées Spotlight, selon trois niveaux d'agressivité en fonction de ce que vous voulez ratisser.

Elle sait aussi prendre le problème dans l'autre sens puisque son chercheur de fichiers orphelins parcourt ~/Library pour retrouver les restes d'applications que vous avez virées il y a trois ans et dont plus rien ne vous rappelle l'existence.

Et si vous développez, il y a de quoi récupérer bien plus de place avec les DerivedData, les runtimes de simulateur Xcode, les couches Docker, les caches npm, yarn, pnpm et Homebrew. Bon, ça vous savez déjà le faire avec docker system prune, deux ou trois autres commandes, ou avec Mole en ligne de commande dont je vous ai déjà parlé. Mais l'intérêt ici, c'est de tout voir d'un coup avant d'arbitrer.

Côté données, il n'y a rien à surveiller puisque PureMac n'embarque aucune télémétrie ni appel réseau. Et la licence, c'est du 100% licence MIT, là où d'autres outils similaires comme Pearcleaner ajoute une Commons Clause qui en interdit la revente, que AppCleaner, lui, s'arrête à la désinstallation, ou encore que CleanMyMac nécessite d'acheter une licence.

Pour le faire tourner, il vous faut macOS 13 au minimum, et ça s'installe en une ligne avec brew install --cask puremac. Sinon, il y a un .dmg signé et notarisé à récupérer directement.

Par contre, sachez que ça réclame le l'accès complet au disque, soit la permission la plus large que macOS distribue, et il ne garde aucun journal des chemins qu'il a supprimés. Surtout que quand un fichier est supprimé, il l'est pour de bon, donc vérifiez bien les choses avant de les supprimer.

Le nettoyeur de caches, est également une opération sans retour. Alors pour un cache ça n'a pas d'importance, puisqu'il se régénèrera tout seul. Mais pour un reste dans ~/Library qui contenait, j'sais pas, par exemple une licence, un wallet crypto ou vos réglages, c'est une autre affaire.

Donc soyez TRÈS prudent et lisez bien les chemins d'accès vers les fichiers avant de cliquer pour les supprimer, histoire de pas faire de conneries.

Si vous avez un serveur Pi-hole à la maison, il a dû vous arriver qu'un site déconne, qu'une image ne charge pas, ou qu'un simple bouton ne réponde plus. Alors pour remédier à ça, vous ouvrez un onglet vers l'admin Pi-hole, vous fouillez dans les requêtes bloquées, vous whitelistez au jugé, puis vous rechargez pour voir si ça marche. Ça prend 30 secondes à chaque fois, ça casse les couilles et ça arrive plus souvent que ce qu'on aimerait...

Mais heureusement, Holeberry met tout ça dans la barre de menus de macOS pour vous faire gagner grave de temps

L'app détecte l'onglet actif de Safari, Chrome ou Firefox et débloque le domaine correspondant en un clic. Comme ça, plus besoin de deviner lequel des quarante domaines bloqués casse la page. Elle affiche aussi les derniers blocages en direct, et permet de couper le filtrage pour une durée choisie, le temps de finir un achat en ligne qui n'aime pas les bloqueurs.

Elle peut aussi gérer deux instances Pi-hole en parallèle avec synchronisation, pratique quand on a un Pi principal et un secondaire qui prend le relais. Les identifiants partent dans la Keychain macOS et pas dans un fichier de conf qui traîne comme ça c'est sécurisé. Et surtout, ça supporte Pi-hole v5 et v6 aussi bien en local qu'à distance.

Si ça vous branche, notez que l'app n'est pas notarisée, donc Gatekeeper va faire la gueule. La commande pour passer outre est indiquée dans le README :

xattr -cr /Applications/Holeberry.app

Mais vous pouvez aussi utiliser Sentinel pour faire ça.

À récupérer sur GitHub pour ceux qui veulent !