Dans la toute dernière livraison d'«
Onyx» (la version
2.9.1), l'auteur a judieusement édité les options par défaut des 2 panneaux devenus problématiques de son logiciel :
Je trouve cette démarche particulièrement opportune --> sachant, en effet, qu'un certain nombre d'utilisateurs sont amenés à opérer - périodiquement ou en cas d'urgence - "un coup d'«
Onyx"
(selon leur expression qui m'a toujours paru une énigme intellectuelle, jusqu'à ce que je m'avise qu'ils entendaient par là l'exécution successive des options cochées par défaut des panneaux Nettoyage & Automation 
) ; et comme chez un nombre notable d'entre eux doit se rencontrer la combinaison des 3 facteurs : OS «
Yosemite» instruisant le
kext_signing x SSD de Tierce-Partie x activation de «
Trim Enabler» - alors l'exécution de la suppression des caches-système proposée par défaut dans les versions antérieures d'«
Onyx» n'aurait pas manqué de planter leur Mac devant le panneau d'interdiction de stationner
(je reviens plus bas sur la raison de cet 'effet' que j'avais déjà essayé de décortiquer ici [TRIM] Yosemite et son bridage au message #131 et qui avait alerté le développeur d'«Onyx» : voir son message #140).
Il ne serait pas souhaitable, en effet, que la réputation du logiciel «
Onyx», qui est grande, vienne à être entachée de soupçons de dangerosité, parce que telle option de
Nettoyage ou d'
Automation proposée par défaut conduirait à un plantage d'un certain nombre de Macs. L'avertissement explicite, affiché par l'auteur en regard de l'option de suppression des caches-système non cochée désormais par défaut, ne peut qu'inciter les utilisateurs ayant activé «
Trim Enabler » à y regarder à deux fois avant de cocher la case fatidique et à en exécuter l'option. Ils ne pourront s'en prendre qu'à eux-mêmes si leur Mac plante.
♤
J'aurais juste une dernière petite question avant de prendre congé ("Inspecteur
Columbo, sors du corps de
macomaniac!"
) : comme je l'ai souligné dans une annotation en vert de ma capture du panneau
Nettoyage/Système d'«
Onyx», j'ai un doute raisonnable concernant l'option demeurée cochée par défaut :
Supprimer les fichiers Cache : Démarrage.
En effet, dans mon esprit du moins, le cache de
Démarrage n'est autre que le
kernelcache (dit : "
prelinkedkernel" :
kernel pré-associé) qui se trouve à l'adresse :
/System/Library/Caches/com.apple.kext.caches/Startup/kernelcache) --> comme l'indique le dossier parent
Startup (= "démarrage"), il s'agit bien du cache de démarrage du Système.
Car le fichier démarreur de l'OS exécuté par l'
EFI au
boot : le
Boot_Loader : boot.efi (at:
/System/Library/CoreServices) ne charge pas le
kernel isolé (at:
/System/Library/Kernels/kernel), lequel
kernel aurait à se débrouiller tout seul comme un grand pour aller chercher les
kexts (extensions du noyau) natives Apple une à une (at:
/System/Library/Extensions) pour les vérifier avant de les charger (fichtrement long, le démarrage dans ces conditions!) ; mais ce que charge au démarrage le
boot.efi, c'est le
kernelcache, fichier qui 'mâche' la tâche du kernel, en solidarisant à l'avance (
prelink) le code intégral du
kernel - son clone exact ici - avec l'
enveloppe globale des
kexts offerte à être chargée en bloc selon l'argument de cache :
All_Loaded = "toutes chargées en bloc certifié conforme".
Sous «
Yosemite», qui comporte par défaut l'argument de
boot en
NVRAM de vérification d'intégrité des
kexts natives Apple (
kext_signing), «
Trim Enabler» modifie cet argument de
boot en lui substituant celui dédié aux développeurs :
boot-args=kext-dev-mode=1. Je me figure que cet argument de
boot qui transite au démarrage jusqu'au
kernel revient à l'instruction : "charge-moi en bloc sans discuter l'enveloppe des
kexts Apple présentée en cache dans le
kernelcache et tant qu'il n'y a pas de blocage-système en retour, laisse faire"
. Si le
kernelcache est supprimé, c'est le
kernel solidaire qui est chargé, et n'ayant pas d'enveloppe de
kexts certifiée conforme à charger en bloc, il va passer la revue des extensions Apple natives une à une, tâche pour laquelle l'instruction du
boot-args=kext-dev-mode=1 ne fait plus sens et donc saute, en étant
overriden par l'instruction par défaut : "Vérifie au compte-goutte l'intégrité de chaque extension Apple". Et donc, parvenu à la
kext litigieuse (bidouillée par «
Trim Enabler) :
IOAHCIFamily.kext - le
kernel suspend le chargement --> panneau d'interdiction de stationner.
J'ai essayé de fournir une représentation (à mes risques et périls) de la raison pour laquelle la suppression du
kernelcache (qui lie le
kernel à une tâche de chargement d'un "bloc d'extensions garanti") va planter les Macs cactérisés par le triple critère :
SSD de Tierce-Partie x
Trim Enabler x
Yosemite, malgré la modification de l'argument de
boot en
NVRAM à
boot-args=kext-dev-mode=1. Et donc pour résumer mon sentiment : laisser la case du fichier cache :
Démarrage (=
kernelcache dans le dossier parent
Startup)
cochée par défaut dans le panneau
Nettoyage/Système, c'est laisser la porte ouverte à un plantage programmé des Macs concernés par l'équation ci-dessus.
♧
a déjà répondu exactement dans le même sens. Comme lui, j'utilise «Trim Enabler» sans complexe sur mon Mac qui a un SSD «Crucial» et supporte «Yosemite», parce que, ayant déjà planté volontairement mon Mac à fins expérimentales une dizaine de fois à coup de 
