Garde-fou mémoire macOS
KlodyMem
Ce que c'est
Daemon Swift qui surveille la pression mémoire réelle et suspend les gros consommateurs avant l'asphyxie. Deux agents supervisés : la garde et la barre de menus.
La décision d'architecte
ps rss sous-estime l'empreinte MLX d'un facteur ~30 : seul phys_footprint dit la vérité.Ce qui a mal tourné
Trois croyances mesurées, puis abandonnées. Le ratio de swap paraissait le signal évident : il plafonne autour de 96 % en permanence, parce que le pager redimensionne son propre fichier. S'en servir comme seuil déclenche en continu. Une croissance de swap d'environ 1 Gio/s pendant le chargement d'un modèle de 35 milliards de paramètres est normale, pas un incident. Et ps rss sous-estime l'empreinte MLX d'un facteur voisin de 30 — seul phys_footprint dit la vérité. Toute supervision bâtie sur rss annonce donc que tout va bien jusqu'à l'instant où le système meurt.
Un SIGKILL 137 parfaitement muet. Copier un binaire Mach-O signé avec cp invalide sa signature, et macOS le tue sans message exploitable. La séquence qui marche est rm, puis cp, puis codesign -f -s -. Plusieurs heures perdues à chercher un bug applicatif qui n'existait pas.
Ce qui reste volontairement désactivé. L'arrêt forcé des applications au seuil critique existe dans le code mais n'est pas armé. Un garde-fou mémoire qui ferme le navigateur de l'utilisateur sans prévenir ne sera pas gardé une semaine.
Les chiffres
Le code
Compétences mobilisées
Projets liés
- Klody Core — Plan de contrôle
- klodyfan — Contrôle ventilo · anti-throttle
Vos données ne peuvent pas sortir ?
C'est exactement le problème que je résous. Un appel de 30 minutes suffit à cadrer un audit.