Bonjour
Fonzerelli.
Le « crépuscule du matin » est plus favorable à ma faculté de discernement que le « crépuscule du soir ». Je m'avise donc ce matin d'une confusion de termes que j'ai commise hier soir : j'ai écrit
disksleep à la place de
sleep.
- disksleep est une assertion en voie d'obsolescence, qui n'a de pertinence qu'avec des disques à plateaux : elle cible le délai d'inactivité graphique avant intervention d'un ralentissement de la vitesse de rotation du HDD. Pour des Macs à SSD (comme le tien), cette assertion est nulle, quand bien même elle serait associée à une valeur numérique.
- sleep est l'assertion qui cible la mise en sommeil de l'activité du Système après un délai d'inactivité graphique de l'utilisateur. C'est donc elle qui doit être associée à une valeur numérique supérieure à l'assertion displaysleep (sommeil de l'écran = obscurcissement). Par exemple : displaysleep 2 sleep 5.
Une fois fixé le délai de
sleep >
displaysleep, le choix de la valeur de l'
hibernatemode fixe la modalité du
sleep en question :
0 = mise en
sommeil simple passé le délai = maintien en charge de la RAM pendant le sommeil sans écriture à la
sleepimage des contenus de la RAM en préalable (=> la session se re-déploie sur la base de la RAM) ;
3 = mise en
sommeil simple passé le délai = maintien en charge de la RAM pendant le sommeil mais impliquant une écriture préalable à la
sleepimage par précaution (=> la session se re-déploie encore sur la base de la RAM) ;
25 = mise en
sommeil profond passé le délai = sommeil avec RAM déchargée de ses contenus et désactivée, avec écriture préalable à la
sleepimage de ses contenus (=> la session se re-déploie sur la base de la
sleepimage).
Le
standby est l'
hibernation à proprement parler : un état du Système plus radicalement désactivé que lors du sommeil (
simple ou
profond) =
léthargie. La passage du
sommeil au
standby est réglé par la valeur de l'assertion du
standbydelay : délai de sommeil avant mise en
hibernation radicale. Le
standby implique la désactivation de la RAM avec effacement de ses contenus : il présuppose donc une écriture de ses contenus à la
sleepimage afin que la session puisse se re-déployer sur la base de la
sleepimage. En cas d'
hibernatemode 25, cette écriture à la
sleepimage a été accomplie en préalable à un
sommeil profond impliquant une RAM effacée et désactivée : le
standby s'opére donc directement passé le délai imparti ; en cas d'
hibernatemode 3, l'écriture à la
sleepimage a été aussi accomplie en préalable à un
sommeil simple impliquant une RAM maintenue en charge avec ses contenus : le
standby s'opère donc par désactivation de la RAM après ré-écriture de ses contenus à la
sleepimage (il y aura donc re-déploiement de la session sur la base de la
sleepimage par
overriding du redéploiement régulier sur la base de la RAM maintenue en charge pendant le
sommeil simple) ; en cas d'
hibernatemode 0, aucune écriture à la
sleepimage n'a été accomplie en préalable du
sommeil simple impliquant une RAM maintenue en charge avec ses contenus : le
standby intervient alors en surpassement (
overriding) de l'assertion de l'
hibernatemode 0, par écriture des contenus de la RAM à la
sleepimage avant effacement de la RAM et sa désactivation. La session se re-déploiera également sur la base de la
sleepimage, par
overriding du redéploiement régulier sur la base de la RAM maintenue en charge pendant le
sommeil simple).
--------------------
Il y a clairement, là, prévoyance d'une
issue logique en cas d'assertions
contradictoires : le
standby impliquant effacement/désactivation de la RAM et re-déploiement de session sur la base d'une
sleepimage ayant sauvegardé les contenus de la RAM / l'
hibernatemode 3 et
0 impliquant la préservation de la RAM dans le sommeil et le re-déploiement de la session sur la base de la RAM => le
standby a priori surpasse (
override) les préférences de ces
hibernatemode en effaçant la RAM et en déterminant un réveil sur la base de la
sleepimage : il opère donc une assimilation à l'
hibernatemode 25.
À scruter les choses de près, la résolution de la
contradiction entre l'
hibernatemode 3 et le
standby (préservation de la RAM vs effacement de la RAM) par
privilège du
standby (
overriding de l'
hibernatemode 3 avec effacement de la RAM), en déterminant un redéploiement de la session sur les bases de la
sleepimage (comme dans l'
hibernatemode 25) n'introduit pas de problème logistique majeur, car l'
hibernatemode 3 implique intrinsèquement une écriture par précaution à la
sleepimage => le
standby "actualise" cette précaution.
Par contre, la résolution de la
contradiction entre l'
hibernatemode 0 et le
standby (préservation de la RAM vs effacement de la RAM) par privilège du
standby (
overriding de l'
hibernatemode 0 avec effacement de la RAM), ne peut déterminer un re-déploiement de la session sur les bases de la
sleepimage (comme dans l'
hibernatemode 25) qu'en rendant fonctionnel un fichier
sleepimage sur le disque que l'
hibernatemode 0 a précisément pour vocation d'invalider - ce qui permet a priori sa suppression pour gagner de l'espace-disque (par exemple, sur mon
MacBook Pro, je privilégie toujours l'
hibernatemode 0, afin de pouvoir remplacer la
sleepimage de 8 Go à 16 Go - étendue de ma RAM - par un fichier
sleepimage verrouillé vide de
0 Ko). Si j'optais pour un
standbydelay susceptible d'intervenir dans la pratique, alors le
standby aurait pouvoir de
surpassement (
overriding) de l'assertion de l'
hibernatemode 0, et il y aurait création de force d'une
sleepimage > 8 Go (après déverrouillage du fichier vide verrouillé) afin de permettre un re-déploiement de la session sur sa base en sortie du
standby - ce qui serait en
antagonisme majeur avec mes choix de gestion de l'espace-disque. Pour surmonter ce paradoxe, il faut donc que je désactive le
standby, ou du moins que je fixe un
standbydelay insusceptible d'intervenir dans la pratique, afin de préserver une valeur de
0 Ko de la
sleepimage verrouillée.
--------------------
Il est, bien entendu, possible de différencier les assertions selon les 2
flags fondamentaux
-b (situation nomade sur batterie) et
-c (situation sédentaire sur secteur) en optant y compris pour chacun de ces
flags pour des
hibernatemode différents. Par exemple :
Bloc de code:
sudo pmset -b hibernatemode 25 -c hibernatemode 3
en interpolant éventuellement des valeurs différentes relatives au
standby et au
standbydelay :
Bloc de code:
sudo pmset -b hibernatemode 25 displaysleep 2 sleep 4 standby 1 standbydelay 10 -c hibernatemode 3 displaysleep 5 sleep 10 standby 0 standbydelay 10800
où les cas de contradiction logique des assertions se trouvent réduits à néant.
Par contre, en cas de choix des
hibernatemode :
Bloc de code:
sudo pmset -b hibernatemode 25 -c hibernatemode 0
je pourrais certes moduler ainsi mes assertions :
Bloc de code:
sudo pmset -b hibernatemode 25 displaysleep 2 sleep 4 standby 1 standbydelay 10 -c hibernatemode 0 displaysleep 5 sleep 10 standby 0 standbydelay 10800
un cas majeur de contradiction logique ne pourrait être évité : la présence au disque d'une
sleepimage requise par l'
hibernatemode 25 et recréée par lui alors que l'
hibernatemode 0 a pour vocation de permettre de se dispenser de l'
existence d'une
sleepimage. Il y aurait alors arbitrage logique en faveur de l'
hibernatemode 25 par
overriding du
0, ce qui conduit l'utilisateur à des décisions
éthiques : si le mode
nomade est privilégié avec l'
hibernatemode 25, il convient d'opter en position sédentaire
-c pour l'
hibernatemode 3 impliquant aussi une
sleepimage ; si le mode
sédentaire est privilégié avec l'
hibernatemode 0 impliquant une suppression de la
sleepimage, alors le mode
nomade sur batterie
-b doit être considéré comme forclos (c'est personnellement parlant, mon choix éthique radical : je n'utilise jamais hors de chez moi aucun appareil électronique : ni ordinateur, ni téléphone ni quoi que ce soit d'autre. J'ai choisi d'être entièrement dépouillé de tout autre autre contact que celui délivré par ma perception naturelle du monde...).
--------------------
