Je pense, en effet, que le processus
com.apple.IconServices est une innovation de «
Mavericks» -
Sly. Je ne l'avais jamais rencontré antérieurement et personnellement j'aurais à lui objecter deux effets collatéraux des plus discutables : d'abord, l'inondation littérale d'une série de répertoires d'accueil :
com.apple.IconServices (distribués dans une sous-arborescence de
/private/var/folders/) par des
fichiers_caches : '
iscachebmp' qui s'empilent au fur et à mesure des actions d'affichage graphique de l'utilisateur dans sa session ; d'autre part, une pesée considérable sur la RAM, qui, d'une valeur d'environ 300 Mo en ouverture de session, grimpe en cours d'exercice jusqu'à environ 900 Mo en dépassant le poids de la
kernel_task.
Je me demande s'il n'y a pas là un quelque chose de concomitant du changement des bibliothèques de ressources graphiques introduites par «
Mavericks» (abandon des
QuickTime_frameworks pour le
AV Kit_Foundation).
♤
Purger périodiquement la part
inactive de la RAM était une pratique classique des MacUsers avant «
Mavericks» et le maintien de cette pratique est sujet à discussion, dans la mesure où «
Mavericks» a introduit une gestion de la RAM d'un type nouveau : il n'y a pas simplement
empilement linéaire des 'charges', au fur et à mesure que l'utilisateur ouvre de nouvelles applications sans fermer les précédentes, jusqu'au point critique de saturation où se déclenche le
swap (qui est un pis aller) ; il y a
compression des charges correspondant aux applications momentanément d'arrière-plan, processus pouvant croître exponentiellement avec leur multiplication mais au prix d'une augmentation de la
pression sur la mémoire qui tend vers une limite. Donc, théoriquement parlant, il faudrait laisser le Système se débrouiller pour gérer la RAM avec son nouveau protocole, une faible marge de RAM
libre ne signifiant pas que le point de saturation est atteint puisque le taux de compression de mémoire est susceptible de continuer d'augmenter.
Sans vouloir m'engager dans un débat byzantin sur la question, je ne suis pas entièrement convaincu qu'une RAM constamment sur-occupée par des charges exerçant des pressions considérables sans mécanisme clairement établi de délestage soit gérée autrement qu'en fonctionnement 'sub-critique'. D'où, personnellement parlant, ma conservation de la pratique de la
Vieille École consistant à purger pédiodiquement la RAM afin de récupérer de l'espace libre. En ce qui te concerne,
Pierre, tu pourrais y voir tout pragmatiquement le moyen d'un test : est-ce que son emploi ponctuel ou périodique te permet de surmonter les phases de 'gel' de l'activité sur ton
iMac?
Pour conserver cette pratique sous «
Mavericks», il est bon de savoir que le programme qui permet cette opération (le
binaire :
purge at
/usr/sbin) a vu ses droits changer avec
10.9 --> désormais, activer ce programme requiert des droits
root, alors que des droits simplement
admin suffisaient dans les OS antérieurs. Ce 'tour de vis' nécessite donc un contournement que je te décris selon les 2 modes d'emploi possibles du binaire
purge que sont l'
AppleScript et le
cron.
♧
- AppleScript. Méthode chérie de la Vieille École, car petite application logeable dans le «Dock» et permettant d'un coup de pointeur de déclencher la purge à la volée. Pour pouvoir la ré-employer sous «Mavericks» :
- Imposer d'abord sur le binaire purge un SETUID, qui est le bit_s décidant que le programme, quelle que soit l'identité de son initiateur (et ici ce sera toi : un simple admin), s'exécutera toujours par transfert de l'identité exécutive à son propriétaire = root --> pour établir le SETUID sur purge, tu ouvres donc le «Terminal» et tu passes la commande :
Bloc de code:
sudo chmod 4755 /usr/sbin/purge
et ↩︎ (touche 'Entrée' pour activer la commande) --> demande de password (commande sudo) = tu tapes ton mot-de-passe admin à l'aveugle, aucun caractère ne se montrant à la frappe, et derechef ↩︎. 4000 en valeur octale établit le SETUID bit_s sur un binaire, à quoi il faut ajouter la valeur octale des permissions déjà instaurées, soit 755 root:wheel, ce qui donne un total de 4755. Si tu enchaînes avec la commande :
tu devrais lire en réponse :
Bloc de code:
-rw[COLOR="Red"]s[/COLOR]r-xr-x root wheel /usr/sbin/purge
le bit_s (en remplacement de l'executive_bit : x) signalant que le SETUID est en place. Re-démarrer est recommandable. Lors de la réparation des permissions par l'«Utilitaire de disque», tu noteras l'avertissement : Autorisations différentes sur « usr/sbin/purge » ; attendu -rwxr-xr-x , actuellement : rwsr-xr-x . ATTENTION : le fichier SUID « usr/sbin/purge » a été modifié et ne sera pas réparé --> cela signifie que le Système a enregistré ta customisation des permissions du binaire purge et la respecte.
----------
- Maintenant tu vas à /Applications/Utilitaires et tu lances «Éditeur AppleScript». Dans la fenêtre de saisie d'un nouveau script qui s'ouvre, tu fais un copier-coller de :
et tu presses le bouton 'Compiler' de la barre de menus de la fenêtre. Puis tu vas à la barre de menus supérieure de l'application, menu : Fichier/Exporter, tu écris comme titre : Purge, comme emplacement : Applications, comme format de fichier : Application (important!) et tu fais 'Enregistrer' --> ta petite application AppleScript se trouve dans ton dossier général des Applications, d'où un glisser-déposer te permet d'en loger le raccourci dans la partie droite de ton «Dock» --> quand tu seras en difficulté avec ta RAM, un clic sur «Purge» délestera ta RAM de ses charges inactives --> à toi de voir si ta situation s'améliore.
- Cron. Un Cron est une action de toile de fond enregistrée par le Système dans la Crontab et qui s'exécute selon une périodicité décidée par son créateur. Il y a 2 sortes de cron : d'utilisateur (dont les droits d'exécution sont ceux dudit) et du Système (dont les droits d'exécution sont ceux de root) --> même si le SETUID précédent permet à un admin initiateur d'un cron de le faire s'exécuter avec les droits du propriétaire root du binaire, je te recommande nonosbstant un cron-du_Système, car, par-delà la question de droits, il y a l'extension de l'application du cron : un cron du Système va s'exercer quelle que soit la session ouverte, alors qu'un cron d'utilisateur est limité dans sa sphère d'action à le seule session ouverte de l'utilisateur qui l'a défini.
- D'abord tu télécharges et installes CronniX, éditeur gratuit de crons dans OSX.
----------
- Tu lances «CronniX» qui par défaut va afficher une fenêtre de saisie en mode : cron pour l'utilisateur --> tu vas à la barre supérieure des menus de l'application à Fichier/Ouvrir le cron du système, puis dans la fenêtre tu presses le bouton : Nouveau et dans la fenêtre de programmation le bouton : 'Expert' (☞
☜ et tu t'arranges pour avoir quelque chose qui ressemble à ceci :
Tu noteras, en bas, que la commande à saisir est : /usr/sbin/purge. Par ailleurs, que dans le tableau de périodicité au-dessus, tu dois inscrire un * aux rubriques : jour de semaine / Mois / Jour du Mois / Heure, ce qui signifie : 'pour_tout' sans exclusive. Par contre à la première rubrique : Minute, mon exemple : 59 signifie qu'à chaque 59è minute de toute heure/jour/semaine/mois, le binaire purge va être activé par le cron. Tu peux éditer cette valeur ainsi :
si tu voulais un cron_purge s'activant toutes les 15', à la 15è, 30è, 45è et 59è minute de chaque heure de l'horloge interne du Mac.
♡
☞ l'avantage d'un
cron : purge sur le déclenchement manuel d'un
AppleScript : purge est précisément son caractère automatique. Mais cet avantage a exactement son revers : lors de l'exécution du binaire
purge, il est bon de savoir que la RAM est provisoirement gelée dans sa capacité de supporter des actions de l'utilisateur. Si tu es en train (comme moi ici dans la page d'édition de
MacGé) de saisir du texte et que le
cron_purge se déclenche, tu es provisoirement dans l'incapacité de continuer ta saisie pendant une bonne dizaine de secondes, et si tu cherches à anticiper trop vite la re-disponibilité de la RAM, il va y avoir la saisie de caractères incongrus. De même, si tu es en train de bavarder sur «
FaceTime» avec ta chérie et que tu sois rattrapé par le
cron purge, alors l'image va se figer et le son, après extinction brève, va connaître un court purgatoire pendant lequel la voix de l'élue de ton cœur va ressembler à celle d'un
Troll : accélérée et crépitante
.
Repasser par «
CronniX» permet la suppression de
crons importuns qui font '
troller' les voix chères et '
cavalcader' les caractères d'écriture
. De ce point de vue, un petit
AppleScript 'presse-bouton' offre l'avantage de permettre de choisir l'occasion sans être surpris par un automatisme.
♢
