Hibernation et Macbook Air 2013

Dark Templar

Ex-vénérable sage
Club iGen
24 Avril 2002
16 898
1 044
Toujours là
www.pontida.fr
Bonjour,

Je viens de m'acheter un nouveau Macbook Air (13", i7) et j'ai voulu désactiver l'hibernation car:
  • Ça prend 8 Go
  • J'avais lu à un moment que la durée de vie des SSD était limitée, et qu'écrire le contenu de la RAM à chaque veille n'aidait pas
  • L'ordinateur démarre en 15 secondes (réouverture des applications comprise), donc l'hibernation ne m'apporte pas grand chose
Je suis donc passé par le classique pmset -a hibernatemode 0 et j'ai viré le fichier sleepimage.
Pas de chance, ledit fichier réapparaît au démarrage. Après quelques recherches je ne suis pas le seul (cf macrumors).
Note: Power Nap est activé sur secteur, mais je ne pense pas que ça change quelque chose.

Avant d'aller plus loin dans mes manipulations (ex: création d'un dossier ou fichier verrouillé sleepimage), j'aimerais comprendre les impacts.
Tout d'abord, comment exactement fonctionne la veille sur mon ordinateur ? Je vois dans les infos une valeur standbydelay (3H) décrite comme le délai avant hibernation automatique après la mise en veille. Dois-je donc comprendre que le contenu du fichier sleepimage ne sera réellement écrit qu'après 3H, et qu'en attendant c'est juste de l'espace alloué ?
Je vois aussi une valeur autopoweroffdelay mais pas vu la description dans le man, à quoi correspond-elle ?
Y'a-t-il une page sur le site d'Apple qui explique comment se passent les choses ?

Ensuite, en supposant que mon ordinateur écrit effectivement le contenu de la RAM sur le SSD à chaque fois que je le mets en veille, quel sera l'impact sur la durée de vie du SSD ?
 
perso j'ai crée et verrouillé le fichier en écriture , plus de soucis et vu que je ne mets jamais en veille/hibernation mon SSD je ne peux pas te dire lol
 
Salut Dark Templar.

Il y a 2 états absolus de ton Mac : 'Allumé' (= 'ON', ou 'Powered on') et 'Éteint' (= 'OFF', ou 'Powered off'). En mode 'ON', ton Mac consomme l'énergie correspondant aux processus actifs sur la source d'énergie disponible. En mode 'OFF', ton Mac ne consomme pas d'énergie, puisqu'il n'y a pas de processus actifs.

----------​

Un 3è facteur intervient pour compliquer un peu ce scénario binaire : la 'RAM' (Random Access Memory), qui survient uniquement en mode 'ON' du Mac. C'est un système de stockage des informations actives du Mac qui ne consiste pas en leur écriture sur le disque dur, mais en leur rétention instantanée dans une couche de 'mémoire volatile' (si je puis dire). L'avantage est l'accessibilité instantanée de ces données et leur conversion instantanée (figure-toi en train de taper du texte dans la page d'un éditeur de texte : tant que tu n'as pas sauvegardé, rien ne s'écrit sur le DDI du Mac, tout s'inscrit dans la RAM et toutes tes corrections à la volée raturent ce contenu de la RAM. La RAM est donc comme une instance d'inscriptions volatiles, d'autant plus instantanément disponible et fluidement métamorphique qu'elle est 'virtuelle'. L'inconvénient est que, si le contenu de la RAM n'est pas sauvegardé (càd. transformé en écriture du Disque Dur), alors un passage brutal du mode 'ON' (Éveil ou Activité) au mode 'OFF' (Extinction ou Inactivité) supprime la RAM avec tous ses contenus volatils et tout disparaît, par exemple du texte que tu avais écrit... dans la RAM et pas sur ton disque.

Donc, en modes binaires 'ON' & 'OFF', sachant que le mode 'ON' supporte la modalité secondaire 'RAM', un processus 'SAVE' (sauvegarde) intervient pour transférer des contenus choisis de la RAM au DDI avant tout passage délibéré du mode 'ON' au mode 'OFF'.

----------​

Un 4è paramètre vient encore compliquer :D ce beau scénario : c'est le caractère 'Discret' ('discontinu') des processus actifs à l'écran en fonction d'un double état de l'utilisateur qui les dirige : 'OP'[_ÉRATIF' = présent et &#339;uvrant) / 'INOP' [_ÉRATIF' = absent et oisif) <je simplifie>. Ce 'switch' entre les modes 'OP' et 'INOP' intervient pendant le mode 'ON' du Mac (car il serait extrêmement laborieux de solidariser les modes 'OP' avec 'ON' et 'INOP' avec 'OFF', sous peine d'avoir à rallumer le Mac et à 'rebooter' autant de fois dans une journée qu'il y aurait 'reprise' du mode 'OP' après interruption en mode 'INOP'. Même au travail, il y a des pauses 'déj.' quand ce n'est pas 'le patron veut vous voir illico' :D). D'où l'astuce d'un mode 'SLEEP' (= mise en sommeil) des activités du Mac, permettant à tout le moins d'économiser l'écran et déjà de ne pas consommer autant d'énergie qu'en plein mode 'OP' alors même qu'il y a eu bascule en mode 'INOP'. Il s'agit d'une 'mise en pause' générale, qui néanmoins préserve intégralement la RAM, sans qu'il y ait eu besoin de sauvegarder forcément tous ses contenus volatiles. Rabattre par exemple le couvercle d'un portable le fait passer en mode 'SLEEP' et réouvrir le couvercle le ramène en mode 'ON' sans que la RAM (normalement) ait jamais été affectée, mais seulement le restant des processus actifs qui ont été mis en pause.

----------​

Un 5è paramètre vient sur-compliquer ce scénario qui tend à devenir touffu :D [imaginons Virgile en train de conduire Dante vers le chemin de l'«Enfer_du_Computing» - à bon droit lui donnerait-il à lire cette inscription liminaire qui devrait être gravée en toutes lettres sur le capot de chaque ordinateur, fût-il un Mac réputé pour son intuitivité ne réclamant que des dons d'enfant_manipulateur pour être «dirigé_comme_un_vélo» : «Passé l'allumage de cet instrument, âmes simples perdez toute espérance!»]. Ce 5è paramètre est la faculté de 'Déplacement' de l'opérateur, qui doit s'analyser par rapport à l'ordinateur comme la faculté qu'a l'usager de le 'transporter' au lieu de le laisser en position 'fixe', càd. de le convertir d'un mode 'IMMOB' à un mode 'MOB'. Cette possibilité concerne les ordinateurs 'portables', càd. qui ne doivent pas compter comme les 'fixes' sur une source d'énergie [en principe] inépuisable (le secteur), mais doivent pouvoir embarquer une source d'énergie d'appoint (la batterie). <problème additionnel : les 'fixes' doivent pouvoir, en cas de panne de courant, disposer aussi d'une source d'énergie d'appoint>.

L'utilisation d'un portable sur batterie (résumée par le sigle 'MOB') implique d'avoir à optimiser la consommation d'une réserve d'énergie limitée tout en maintenant le mode 'ON' pour ne pas avoir répétitivement à 'rebooter'. D'où l'introduction d'un sous-mode de sommeil = le 'SAFE_SLEEP' (= 'Hibernation') qui copie d'abord le contenu de la RAM sur le DDI (donnant un fichier aussi volumineux que la RAM = la 'SLEEP_IMAGE') avant de désactiver les processus du Mac. Ce sous-mode 'hibernatif' de la mise en sommeil simple d'une part préserve davantage d'énergie que le sommeil simple (puisque les processus du Mac dont la RAM sont déactivés) ; d'autre part, la sauvegarde de la RAM en écriture sur le DDI ('SleepImage') permet d'affronter la possibilité fâcheuse d'une chute drastique des réserves de la batterie en-dessous du seuil opératoire, ou de son débranchage accidentel.

[Un autre sous-mode du mode 'SLEEP' est le 'HYBRID_SLEEP', qui avant tout mode en sommeil copie le contenu de la RAM au DDI pour produire une 'SleepImage', mais ne fait passer le Mac qu'en mode 'SLEEP' simple après cela, et pas en 'SAFE', ce qui permet une réactivation instantanée au lieu de différée des processus à l'écran puisque la RAM a été préservée.]

En 'SAFE_SLEEP' mode (ou 'Hibernate' mode), il y a (ré-)écriture du contenu de la RAM au DDI juste avant le passage à l'Hibernation, de manière à ce que le fichier 'SleepImage' soit disponible au Réveil pour rétablir les processus du Mac dans l'état on_quit (étant donné que la RAM, à la différence du mode 'SLEEP' simple, n'est pas maintenue active pendant l'hibernation).


&#9099;


Pfuiii! Ça commence à faire longuet, ce 'pèxe' sur un sujet ouvrant des perspectives bien moins délectables que celles d'un sommeil capable de rêve... :D

Désactiver ou pas la fonction 'SAFE_SLEEP' (= 'hibernate mode) sur ton Mac, et par suite benner ou pas la 'sleepimage' dévoreuse sur le DD d'autant d'espace que la taille de la RAM - cela dépend largement de ton profil d'utilisateur : nomade ou pas ET activateur ou pas de la fonction 'AUTOSAVE' dans les applications actives qui la supportent (genre 'traitement de texte').

Si tu veux que les commandes que tu passes créent une désactivation permanente, et pas ponctuelle, il te faut faire précéder ta commande par sudo (commande 'root' = 'SuperUser commands to DO'), ce qui implique une session-admin où tu puisses taper un mot-de-passe admin pour emprunter les droits 'root'). Ainsi, dans le «Terminal», tu te connectes en 'root' par défaut par la commande :

Bloc de code:
sudo su

et &#8617; (retour-chariot ou touche 'Enter'). Demande de 'password' (= mot-de-passe admin) que tu tapes à l'aveugle, aucun caractère n'apparaissant, suivi à nouveau de &#8617; Maintenant, tu es en mode 'root' par défaut pour toutes les commandes qui suivent (attention!).

Fais un copier-coller de :

Bloc de code:
pmset -g | grep hibernatemode

et &#8617; pour connaître le statut de ton mode 'SLEEP', et normalement tu devrais voir la valeur par défaut : = 3 (qui est l'écriture de la RAM au DDI sous forme d'une 'sleepimage' avant tout passage au sommeil). Donc tu copies-colles :

Bloc de code:
pmset -a hibernatemode 0

et &#8617; pour désactiver le mode 'SAFE_SLEEP' et comme c'est une commande 'root', ça devrait tenir la root_e :D

Puis bennage de la 'sleepimage' en place par :

Bloc de code:
rm /private/var/vm/sleepimage

et &#8617; ('rm' comme 'remove' = 'ôte-moi-ça-de-ci' :D)

Tu peux toujours, genre 'qui va à la chasse, perd sa place / qui revient, trouve un chien', mettre un 'chien' = une 'effigie vide' à la place du 'maître' = la 'sleepimage' ainsi :

Bloc de code:
chflags uchg /private/var/vm/sleepimage

et &#8617; et quitter le mode 'root' (par prudence) ainsi :

Bloc de code:
exit

et &#8617;


Si tu voulais te raviser, dans le «Terminal» repasse en mode 'root' ainsi :

Bloc de code:
sudo su

et &#8617; plus 'password' et encore &#8617;

puis vérifie l'état des lieux par :

Bloc de code:
pmset -g | grep hibernatemode

et &#8617; ce qui devrait donner le statut = 0

tu peux benner l'effigie vide de ta 'sleepimage' en place par :

Bloc de code:
rm /private/var/vm/sleepimage

et &#8617; puis tu ramènes maintenant au mode par défaut re-créateur de 'sleepimage' ainsi :

Bloc de code:
pmset -a hibernatemode 3

et &#8617;


----------​



J'ai gardé pour la fin l'Arme Secrète (je me demande si je n'aurais pas mieux fait de la garder pour moi? :D). C'est l'application «SmartSleep» qui te coûtera la modique somme d'environ 5&#8364; toutes taxes comprises, dont on peut traduire le programme par : 'Sommeil_Futé' qui te propose une GUI avec choix du mode de 'Sommeil' :

- System default
- a) Smart sleep
- b) Sleep only
- c) Hibernate only
- d) Sleep and hibernate



- a) = Sommeil Futé = sommeil simple si la charge de la batterie est au-dessus du niveau de sommeil avec hibernation <+20%> ; sommeil avec hibernation si la charge de batterie est en-dessous du niveau de sommeil avec hibernation <-20%> ; hibernation seule si la charge de batterie est en-dessous de 5% ou moindre que 5'.

- b) Sommeil = l'ordinateur permute en mode SLEEP simple, en ne préservant l'état que dans la RAM la batterie conservant les contenus de la RAM.

- c) Hibernation = l'ordinateur permute en mode SAFE_SLEEP seul, en sauvegardant les contenus de la RAM sur le disque <= fichier 'sleepimage'> sans que la batterie soit utilisée.

- d) Sommeil avec Hibernation = l'ordinateur permute en mode SLEEP après avoir sauvegardé les contenus de la RAM sur le DDI comme dans le mode Hibernation.​

L'intérêt de ce logiciel remarquable est, à partir de l'icône affichée dans la barre de menus supérieure du Finder, qu'il donne le choix à tout moment de switcher à la volée d'un mode à un autre mode de 'SLEEP' en fonction du mode opératoire prévisionnel de l'usager : nomade ou domiciliaire notamment. Car pourquoi, finalement, établir des préférences en mode 'constant' au lieu de 'variable', sachant que rien n'est plus 'inconstant', justement, que la nature humaine et les comportements qui en découlent? :D


[Ah! si les hommes bénéficiaient eux aussi d'une application «SmartSleep»... Ils pourraient sur commande ne dormir jamais [= fonction 'Insomnia' -sic- de «SmartSleep»] comme le notoire Edison (inventeur de la lampe à incandescence qui ne craignait pas pour rien les ténèbres consécutives à l'extinction de l'alimentation de la lampe... de la conscience et qui donc devait détester cordialement l'inventeur de ... l'interrupteur :D) ; ou bien dormir à volonté par tout petits segments en passant instantanément de l'état de veille sur-active à l'état de sommeil profond et vice-versa sans délai et sans oubli, sur simple commande auto-personnelle, comme l'illustre Napoléon, capable de dicter 60 lettres à haute voix dans un même espace du présent à 60 scribes sautant sans effort d'un contexte d'improvisation à l'autre -quelle RAM!, et capable de dormir du sommeil du juste sur le champ de bataille d'Austerlitz en ayant choisi la position basse la plus défavorable et l'ordonnance centrale des troupes la plus vulnérable avec moitié moins d'effectifs afin de faire croire à l'adversaire en position haute qu'il pourrait re-jouer victorieusement contre lui la man&#339;uvre d'enveloppement latéral d'Hannibal à Cannes, ce qui était exactement l'illusion déployée dans l'espace du futur champ de bataille par Napoléon contre un général Autrichien dont il savait pertinemment qu'il avait suivi les cours de stratégie de l'École de Guerre Classique. L'histoire rapporte que quand Napoélon entendit dans la nuit du 1er Décembre 1805 les troupes autrichiennes faire mouvement latéral d'encerclement sur sa droite le long du plateau du Pratzen - il sut qu'il venait de remporter la Bataille d'Austerlitz avant même de l'avoir livrée et il... s'endormit, pour passer dit-il au réveil la «plus belle nuit de sa vie». Sans compter donc les siestes si prisées des méridionaux dont les meilleures, veut le dicton, sont celles où l'«on ne dort que d'un &#339;il».]


&#9099;
 
Dernière édition par un modérateur:
....
[Ah! si les hommes bénéficiaient eux aussi d'une application «SmartSleep»... Ils pourraient sur commande ne dormir jamais [= fonction 'Insomnia' -sic- de «SmartSleep»] comme le notoire Edison (inventeur de la lampe à incandescence qui ne craignait pas pour rien les ténèbres consécutives à l'extinction de l'alimentation de la lampe... de la conscience et qui donc devait détester cordialement l'inventeur de ... l'interrupteur :D) ; ou bien dormir à volonté par tout petits segments en passant instantanément de l'état de veille sur-active à l'état de sommeil profond et vice-versa sans délai et sans oubli, sur simple commande auto-personnelle, comme l'illustre Napoléon, capable de dicter 60 lettres à haute voix dans un même espace du présent à 60 scribes sautant sans effort d'un contexte d'improvisation à l'autre -quelle RAM!, et capable de dormir du sommeil du juste sur le champ de bataille d'Austerlitz en ayant choisi la position basse la plus défavorable et l'ordonnance centrale des troupes la plus vulnérable avec moitié moins d'effectifs afin de faire croire à l'adversaire en position haute qu'il pourrait re-jouer victorieusement contre lui la manœuvre d'enveloppement latéral d'Hannibal à Cannes, ce qui était exactement l'illusion déployée dans l'espace du futur champ de bataille par Napoléon contre un général Autrichien dont il savait pertinemment qu'il avait suivi les cours de stratégie de l'École de Guerre Classique. L'histoire rapporte que quand Napoélon entendit dans la nuit du 1er Décembre 1805 les troupes autrichiennes faire mouvement latéral d'encerclement sur sa droite le long du plateau du Pratzen - il sut qu'il venait de remporter la Bataille d'Austerlitz avant même de l'avoir livrée et il... s'endormit, pour passer dit-il au réveil la «plus belle nuit de sa vie». Sans compter donc les siestes si prisées des méridionaux dont les meilleures, veut le dicton, sont celles où l'«on ne dort que d'un œil».]


Mais justement! nos MacBook n'ayant qu'une seule webcam, peut-on en conclure qu'ils ne dorment au mieux que d'un oeil? :confused:

Ceci mérite réflexion...
 
Mais justement! nos MacBook n'ayant qu'une seule webcam, peut-on en conclure qu'ils ne dorment au mieux que d'un oeil?

LOL. J'avais oublié le cas des Cyclopes - qui soulèvent la question de l'humanité des 'monstres' : Polyphème était-il capable de bonne sieste où l'on ne 'dort que d'un &#339;il'? :D

Et comme tu le soulignes par ailleurs, les Macs n'ayant qu'un &#339;il, n'ont-ils pas en partage cette essence d'une monstruosité cyclopéenne qui les interdit également de bonne sieste? Ce n'est donc pas pour rien que dans la GUI de l'application «SmartSleep», il n'est à aucun moment question de 'mode_sieste' justement...:D
 
Quoi qu'il en soit, moi pour la sieste, je reste fidèle au mode Slip_only!
 
Macomaniac, merci pour ta réponse.

Un autre sous-mode du mode 'SLEEP' est le 'HYBRID_SLEEP', qui avant tout mode en sommeil copie le contenu de la RAM au DDI pour produire une 'SleepImage', mais ne fait passer le Mac qu'en mode 'SLEEP' simple après cela, et pas en 'SAFE', ce qui permet une réactivation instantanée au lieu de différée des processus à l'écran puisque la RAM a été préservée.
Mes questions portent justement sur le mode hybride, les autres sont clairs. Es-tu certain que le fichier sleepimage est écrit au moment de la veille ? Je demande car ça m'a l'air en contradiction avec ce qui est indiqué dans le manuel de pmset:

Bloc de code:
     [U]standby[/U] causes kernel power management to automatically hibernate a
     machine after it has slept for a specified time period. This saves power
     while asleep. This setting defaults to ON for supported hardware. The
     setting standby will be visible in pmset -g if the feature is supported
     on this machine.

     [U]standby[/U] only works if hibernation is turned on to hibernatemode 3 or 25.

     [U]standbydelay[/U] specifies the delay, in seconds, before writing the hiberna-
     tion image to disk and powering off memory for Standby.
D'où ma question dans mon message d'origine au sujet de standbydelay.
En mode hybride (3) sur un ordinateur qui support standby, ma compréhension est la suivante :
1. Le mac rentre en veille
2. Après standbydelay, il passe en hibernation automatiquement quelque soit le niveau de batterie.
Ce que je veux savoir c'est si la mémoire est enregistrée au point 1 ou au point 2.

En outre, j'ai trouvé un début d'explication sur autopoweroffdelay, qui semble correspondre à standby mais sur secteur, la différence étant ajoutée pour ne pas changer le comportement de standby apparu avant.

Tu peux toujours, genre 'qui va à la chasse, perd sa place / qui revient, trouve un chien', mettre un 'chien' = une 'effigie vide' à la place du 'maître' = la 'sleepimage' ainsi :
Sauf que, si le système me recrée un fichier sleepimage, c'est qu'il doit y avoir une raison. C'est pour ça qu'avant de créer un fichier à la place et empêcher l'OS de travailler normalement, je veux comprendre exactement ce qui se passe et pourquoi le système le re-crée automatiquement quand il ne devrait pas.
nano /var/vm/sleepimage me confirme que le fichier, bien que faisant 8Go, est vide.

Merci pour le lien vers SmartSleep, j'y réfléchirai une fois que j'ai les idées claires sur le fonctionnement. Pour l'instant je ne suis pas sûr d'en avoir besoin.


Je vais repasser mon ordi en mode hybride pour l'instant et regarder dans les logs système ce qui se passe sur secteur et batterie après poweroffdelay et standbydelay.
Connaissez-vous un moyen de d'enregistrer l'activité disque avec précision ?

[Edit] Je me réponds à moi-même, fs_usage écoute tout ce qui se passe du côté de fsevents. Donc dans mon cas:
Bloc de code:
sudo fs_usage -f filesys | grep sleepimage
 
Dernière édition:
Salut encore Dark Templar.

Le mode 'hybride', c'est la même chose que le 'safe sleep' qui est l'option par défaut des Macs qui la supportent : hibernatemode = 3. Il s'agit d'une option qui commence par écrire un 'fichier-hibernation' (hibernate file), càd. écrire le contenu de la RAM sur le DDI sous forme de 'sleepimage' en préalable au passage à l'état de 'sleep', càd. de sommeil simple, dans lequel la RAM est maintenue grâce à l'activité de la batterie.

Double avantage : assurer d'entrée ses arrières (l'état des processus peut toujours être reconstitué d'après lecture de la sleepimage en cas de pépin brutal, genre arrachage de la batterie) + garder l'instantanéité du réaffichage de la sortie du sommeil simple grâce à la RAM qui a été préservée en activité.

Inconvénient : pompe les réserve de la batterie, comme tout état de sommeil simple.

----------​

Ce que tu cibles par 'stand-by' rejoint une 'sous-modalité' hibernative du mode 'sleep', ou sommeil simple présente par défaut sur les Macs qui la supportent. Si tu préfères : une sécurité implémentée sur la fonction de sommeil simple. Par défaut : lorsqu'un Mac est en mode 'sommeil simple' (et pas 'safe sleep' où une 'hibernate file' a été pré-écrite sur le DDI = 'sleepimage'), la RAM demeure active, et donc pompe les ressources de la batterie. Une alerte est implémentée, qui se déclenche à la barre des 20% de charge restante de la batterie, déclenchant automatiquement l'écriture d'une 'hibernate file' = le transfert des contenus de la RAM au DDI sous forme de 'sleepimage'. Une 2è sécurité est implémentée par défaut : le passage au mode 'hibernate' strict = désactivation de tous les processus y compris la RAM, donc arrêt de tout pompage sur la batterie, à la barre de charge 5%.

Donc, dans ce contexte, la 'sous-modalité' 'stand-by' consiste à anticiper cet épuisement progressif de la batterie dans le mode 'sommeil simple' sans attendre le déclenchement par défaut de l'écriture d'une 'hibernate file' à la barre des 20%, ni le passage à l'hibernation radicale à la barre des 5%, mais en préfixant une plage horaire (d'après ce que l'usager peut prévoir) de 1H, 2H etc. à partir du début de la mise en sommeil simple, où il va y avoir automatiquement cumul des 2 fonctions hibernatives de sécurité : écriture de l'hibernate file (sleepimage) au DDI et mise en état d'hibernation par désactivation de la RAM et donc arrêt du pompage sur la batterie.


L'utilisation de la fonction 'stand-by' revient à raccourcir volontairement et prévisionnellement le laps de temps où intervient sinon par défaut : 1° l'écriture de l'hibernate file aux 20% de charge batterie et 2° le passage à l'hibernation aux 5% de charge. Elle solidarise les 2 fonctions en prévoyant un déclenchement prévisionnel de l'hibernation-mode à partir d'un sleep-mode (sommeil simple).

Manifestement ce recours vise là encore un compromis : garder la possibilité d'un réveil instantané du Mac sur la base de la RAM restée active, mais prévenir un prolongement trop long du mode sommeil simple en situation nomade, risquant d'affaiblir exagérément la charge de la batterie. C'est donc le calcul : si d'ici [1H/2H etc.] je n'ai pas été amené à réveiller mon Mac, ce que je veux pouvoir faire instantanément sur la RAM, alors je préfère encore qu'il passe en hibernation-mode forcé, afin de me garder de la charge batterie en réserve.

----------​

Aaaah! le nomadisme... Quelle ascèse là où on se figurait de la liberté! :D L'obligation de calculer l'épuisement progressif du 'carburant' et d'y adapter des «ruses de la Raison» comme le disait compère Hegel :D


Tout ça, au fond, parce que notre nomade à la fois veut que tout aille VITE mais aussi que tout soit DURABLE - ce qui est antinomique comme chacun le sait :D Comment pouvoir multiplier les 'cents mètres' sur la distance d'un 'marathon'? Et bien : en marchant entre lesdits 'cents mètres', voire en se faisant prendre en stop sur de larges portions.

----------​

Il est clair que tout ce qui précède n'est possible que si l'hibernate mode = 3, valeur par défaut, est établi sur le Mac. Si comme moi, qui n'utilise jamais un ordinateur en fonction nomade et qui ignore donc ces constraintes paradoxales, mais utilise un MacBook Pro sur secteur en le détournant à une fonction d'ordinateur de Bureau, tu vires les préférences à hibernatemode = 0 par commande sudo, jamais aucune sleepimage ne se recrée (je n'ai pas cherché à créer de 'sleepimage' blanche, c'est 'zéro sleepimage' et aucune ne se recrée après la commande sudo), la modalité 'safe sleep' est abolie, de même que toute intervention d'hibernation par défaut à la barre 20% de la charge batterie pour écrire une 'hibernate file', ou à 5% pour désactiver la RAM. Le Mac ne connaît que : ON, OFF, et SIMPLE SLEEP qu'on pourrait appeler 'sieste' :D où la RAM est toujours active.

Ce qui est intéressant à remarquer, en dehors de ce cas qui révèle que macomaniac = olibrius :D, c'est que Apple ne propose pas aux usagers de OS X une option : 'hibernation directe'. Il s'agit toujours en fait d'une fonctionnalité de coulisses qui vient implémenter le mode 'SLEEP', soit en pré-écrivant l'hibernate file avant le passage au sommeil simple (SAFE SLEEP), soit, dans le cadre du sommeil simple (SIMPLE SLEEP) en prenant la main en mode 'alerte automatique' en 2 séquences distinctes : écriture de l'hibernate file aux 20% de la charge batterie et désactivation aux 5%, ou encore en prenant la main en mode 'hibernation différée' lorsque le laps de temps du stand-by a été préfixé, ce par une double-intervention liée : écriture de la sleepimage et passage au sommeil profond de la désactivation de la RAM en plus du reste.

Il n'y a que des extensions ou applications de tierce partie qui proposent entre autres toutes les options possibles en déclenchement direct. C'est pourquoi j'ai tressé des lauriers à l'application «SmartSleep» qui propose, comme commande instantanée : 'Start Insomnia', 'Sleep Now', 'Hibernate Now', 'Sleep and Hibernate Now' - ce qu'un nomade, je présume, pourrait trouver assez commode, notamment, paradoxalement, la possibilité de commander un 'Hibernate Now' qui fait défaut aux options du Mac.
 
Le mode 'hybride', c'est la même chose que le 'safe sleep' qui est l'option par défaut des Macs qui la supportent : hibernatemode = 3. Il s'agit d'une option qui commence par écrire un 'fichier-hibernation' (hibernate file), càd. écrire le contenu de la RAM sur le DDI sous forme de 'sleepimage' en préalable au passage à l'état de 'sleep', càd. de sommeil simple, dans lequel la RAM est maintenue grâce à l'activité de la batterie.
Désolé d'insister, mais j'ai l'impression que ce que tu décris c'est le mode hybride sur les anciens portables (par exemple mon précédent MacBook Pro). Peux-tu me donner un lien vers la doc qui explique tous ces processus ? Parce que d'après mes tests ce n'est pas le cas sur mon Macbook Air.

J'ai effectué les tests suivants:
  1. Supprimer sleepimage et redémarrer: un nouveau fichier sleepimage, vide, est recréé au redémarrage
  2. Laisser sleepimage et redémarrer: Le système conserve le fichier précédent et n'y accède même pas (confirmé par ls -lu /var/vm)
  3. Mettre l'ordinateur en veille et le réveiller quelques minutes après: toujours pas d'écriture ni même d'accès au fichier sleepimage
  4. Mettre l'ordinateur en veille pour plusieurs heures sur secteur: toujours pas d'écriture ni même d'accès au fichier sleepimage. L'ordi se réveille toutes les heures pour diverses opérations.
  5. Mettre l'ordinateur en veille pour plusieurs heures sur batterie: les logs systèmes montrent qu'après standbydelay (3h), OS X a transféré une partie de la RAM vers le swap, puis transféré le reste dans sleepimage. Quelques heures plus tard je l'ai branché au secteur, il est alors sorti d'hibernation et revenu en veille normale.

J'en conclus donc que le fichier sleepimage sera réellement utilisé seulement si je laisse mon ordinateur en veille plus de 3h sur batterie, ce qui n'arrivera pas plusieurs fois par jour et donc pas d'inquiétude à avoir pour la durée de vie du SSD.

Ce que tu cibles par 'stand-by' rejoint une 'sous-modalité' hibernative du mode 'sleep', ou sommeil simple présente par défaut sur les Macs qui la supportent. Si tu préfères : une sécurité implémentée sur la fonction de sommeil simple. Par défaut : lorsqu'un Mac est en mode 'sommeil simple' (et pas 'safe sleep' où une 'hibernate file' a été pré-écrite sur le DDI = 'sleepimage'), la RAM demeure active, et donc pompe les ressources de la batterie. Une alerte est implémentée, qui se déclenche à la barre des 20% de charge restante de la batterie, déclenchant automatiquement l'écriture d'une 'hibernate file' = le transfert des contenus de la RAM au DDI sous forme de 'sleepimage'. Une 2è sécurité est implémentée par défaut : le passage au mode 'hibernate' strict = désactivation de tous les processus y compris la RAM, donc arrêt de tout pompage sur la batterie, à la barre de charge 5%.
OK, ce n'est pas le standby mais c'est intéressant néanmoins. J'aurais du activer ça sur mon précédent Macbook Pro, ça m'aurait accéléré la veille.

Donc, dans ce contexte, la 'sous-modalité' 'stand-by' consiste à anticiper cet épuisement progressif de la batterie dans le mode 'sommeil simple' sans attendre le déclenchement par défaut de l'écriture d'une 'hibernate file' à la barre des 20%, ni le passage à l'hibernation radicale à la barre des 5%, mais en préfixant une plage horaire (d'après ce que l'usager peut prévoir) de 1H, 2H etc. à partir du début de la mise en sommeil simple, où il va y avoir automatiquement cumul des 2 fonctions hibernatives de sécurité : écriture de l'hibernate file (sleepimage) au DDI et mise en état d'hibernation par désactivation de la RAM et donc arrêt du pompage sur la batterie.
OK, ça correspond effectivement à mes tests.

Ce qui est intéressant à remarquer, en dehors de ce cas qui révèle que macomaniac = olibrius :D, c'est que Apple ne propose pas aux usagers de OS X une option : 'hibernation directe'.
Je ne pense pas que ce soit vraiment nécessaire de toute façon avec le mode stand-by. L'utilisation batterie pendant 3h sur un ordinateur en veille doit être minimale.

---------- Nouveau message ajouté à 21h31 ---------- Le message précédent a été envoyé à 21h15 ----------

Tiens, je viens de trouver quelque chose d'intéressant: http://support.apple.com/kb/HT4392

Pour résumer, sur un Mac récent qui supporte le standby, la veille doit fonctionner comme ceci par défaut:
  1. Mise en veille normale
  2. Après une période prédéfinie (1h ou 3h par défaut), copie du contenu mémoire sur le disque et passage en mode "standby" qui est un mode de veille profonde mais pas l'hibernation
  3. Lorsque la batterie descend sous les 5%, passage en hibernation ?

Ça ne correspond exactement ni au mode d'hibernation 0, ni au mode 3, ni au mode 25, ni même à aucune combinaison des 4 bits possibles décrits dans le man de pmset. :confused:
 
Salut Dark Templar.

Comme je raisonne d'après mon expérience sur un MacBook Pro_Early 2011 (aucune machine plus récente) <OS = Mountain Lion>, j'ignore tout expérimentalement parlant du mode 'Stand-By' dont bénéficie ton MacBook Air_2013.

Ce qui me semble donc d'après mon expérience du MacBook Pro_Early 2011:

&#10057;

- a) tout d'abord, c'est que l'utilisateur qui ne passe pas par le «Terminal» est condamné, en matière de mise en sommeil du Mac, au mode par défaut défini par Apple, qui est le hibernatemode 3. Ce lorsque tu rabats le couvercle de ton portable ou que le portable ouvert tu presses le bouton 'power' et choisis l'option 'suspendre', ou si le délai temporel imparti dans l'option : Préférences Système/Économiseur d'énergie/Ordinateur en veille après : est écoulé.

Ce sommeil (sur les portables post 2005) défini par le mode par défaut : hibernatemode 3 est, stricto sensu, le SAFE SLEEP, qui est le correspondant Mac de ce qui est désigné par mode 'Hybrid' sous Windows (terme non utilisé par Apple). À ma connaissance toujours, ce SAFE SLEEP est caractérisé par 2 processus successifs : 1° écriture du contenu de la RAM au DD dans le fichier 'sleepimage' en préalable = fonction 'SAFE' ; 2° passage de l'état 'éveil' à l'état 'sommeil' qui signifie pour l'essentiel :

- sortie vidéo, airport, ethernet, bluetooth, audio input/output = désactivés
- processeur en état de low power
- décélération de la rotation des disques actifs (DDI, disque optique, disque externe) = spin down
-RAM maintenue active​

= fonction 'SLEEP', qui tout en 'supprimant' ou 'affaiblissant' la demande en énergie de composants maintient intégralement la RAM active. D'où la possibilité d'une sortie instantanée du sommeil.

C'est du moins ma compréhension du mode 'SAFE SLEEP' comme type de sommeil par défaut des portables Macs post 2005 et défini par le mode : hibernatemode 3.

&#10057;

- b) le mode SLEEP ou sommeil simple. Il n'est nullement accessible aux utilisateurs qui ne passent pas par le «Terminal» ou la GUI d'une application de tierce partie. Il correspond à l'option : hibernatemode 0. Qui, stricto sensu, signifie la même chose question état de sommeil que le sommeil précédent du SAFE SLEEP, mais avec absence d'écriture préalable du contenu de la RAM dans un fichier 'sleepimage' du DD. C'est donc le même sommeil, à part qu'il n'est pas safe, c'est-à-dire qu'en cas de défaillance brutale de la batterie pour un portable fonctionnant sur batterie, le contenu de la RAM gardée active pendant le sommeil disparaît (et il n'y a pas dans ce cas le 'backup' de la 'sleepimage'.

Pour activer ce mode SLEEP comme préférence durable devenant le 'default' défini par l'utilisateur, il ne faut pas se contenter dans le «Terminal» d'écrire les commandes :

Bloc de code:
pmset -a hibernatemode 0

parce que cette option ne fera pas durer la préférence SLEEP au-delà de la fermeture de session de l'utilisateur, pas plus qu'il ne suffit de commander :

Bloc de code:
rm /private/var/vm/sleepimage

qui supprime le fichier 'sleepimage' en place, pour empêcher la re-création d'une nouvelle 'sleepimage' (vide au re-créé) au re-boot.

Pour établir le mode SLEEP comme 'default' durable, il faut attacher aux commandes précédentes les droits de 'root' et donc écrire :

Bloc de code:
sudo pmset -a hibernatemode 0

et :

Bloc de code:
sudo rm /private/var/vm/sleepimage

ce qui implique chaque fois la frappe du mot-de-passe admin. Alors, aucune 'sleepimage', même vide, ne se re-crée au re-boot car la fonction 'sauvegarder la RAM dans un fichier 'sleepimage' à telle adresse du DD' a été désactivée en mode permanent.

Aux seules conditions de passer les commandes 'sudo' ci-dessus, le mode de sommeil par défaut SAFE SLEEP se trouve désactivé, et le nouveau mode de sommeil par défaut SLEEP se trouve activé. C'est ce qui a lieu sur mon MacBook Pro et l'expérience me prouve de façon dirimante qu'aucune 'sleepimage' n'existe ni ne se re-crée à l'adresse /private/var/vm et donc que le mode de sommeil de mon Mac est bien SLEEP = hibernatemode 0.

&#10057;

- c) le mode HIBERNATE ou 'sommeil moyen' (aurais-je envie d'écrire). Nullement non plus accessible aux utilisateurs qui ne passent pas par le «Terminal» ou des softs de Tierce Partie - sauf de manière automatique et non délibérée, à la suite de l'alerte batterie qui intervient aux 20% de charge restante lorsque le Mac se trouve en sommeil conformément à l'option par défaut : hibernatemode 3.

Ce mode HIBERNATE désigne 2 processus consécutifs : 1° écriture des contenus de la RAM au fichier 'sleepimage' du DD (backup) ; 2° passage au même état de sommeil que ceux vus précédemment, avec pour unique modification la désactivation de la RAM qui dans les 2 autres modes vus précédemment (SAFE SLEEP & SLEEP) se trouve par contre maintenue en activité.

L'avantage du mode HIBERNATE est qu'il est moins gourmand en énergie (lorsque le portable est sur batterie seule) que les modes SAFE SLEEP & SLEEP où le maintient de la RAM en activité consomme de la charge batterie. Son inconvénient est que pour réafficher l'état des processus du Mac, le contenu du fichier 'sleepimage' du DD dot être lu au préalable, donc la réactivation complète demande un délai.

Afin d'établir ce mode HIBERNATE comme 'Default' qui se maintiendra au re-boot, il faut écrire dans le «Terminal» :

Bloc de code:
sudo pmset -a hibernatemode 1


+ password, de manière à sceller cette commande par les droits de root.

&#10057;

- d) le mode STAND-BY. D'après ce que je m'en figure, mais sans aucune référence expérimentale de ma part, il doit s'agir d'une option nouvelle, implémentée sur les portables Macs récents, qui permet de soumettre le mode SAFE SLEEP par défaut (hibernatemode 3), sur les portables qui le supportent, à une contrainte temporelle de passage au mode hibernate. Donc un mode que je me risquerais à appeler : 'Super-Hybride'. Enveloppant un triple processus consécutif : 1° écriture préalable de la RAM à la 'sleepimage' ; 2° passage à l'état de sommeil dans lequel la RAM demeure activée [ces 2 processus 1° + 2° correspondent exactement à l'option SAFE SLEEP classique] ; 3° déclenchement de l'état HIBERNATE, càd. désactivation de la RAM en sus des processus déjà désactivés ou ralentis du SAFE SLEEP, après un laps de temps de sommeil préfixé, dit le STANDBYDELAY. Le Standbydelay serait donc le délai temporel imparti à la fonction classique par défaut SAFE SLEEP pour perdurer en laissant la RAM active ; après quoi, se déclencherait automatiquement le passage au mode HIBERNATE par désactivation de la RAM.

Je me figure alors que dans le «Terminal» (si le mode Standby n'est pas activable en mode graphique pour l'utilisateur), il doit falloir établir et/ou confirmer :

Bloc de code:
sudo pmset -a standby 1

et

Bloc de code:
sudo pmset -a hibernatemode 3

avant de commander optionnellement la durée du standbydelay, càd. combien de temps va durer le sommeil classique avec RAM activée (permettant une réactivation instantanée si nécessaire) avant que la mise en hibernation intervienne automatiquement :

Bloc de code:
sudo pmset -a standbydelay 1200

en secondes, d'où 1200 sec = 20'. Et pour quelqu'un qui veut accélérer les choses :

Bloc de code:
sudo pmset -a standbydelay 600

pour un délai de durée du sommeil avant hibernation de 10'.

[Comme je suis ici en pleines conjectures spéculatives hors de mon champ d'expérience, une question que je me pose est : le STAND-BY qui intervient après tant de temps défini de SAFE SLEEP est-il la même chose que le mode HIBERNATE = sommeil avec additionnellement désactivation de la RAM? Ou bien correspond-il à une hibernation 'plus profonde', et donc moins gourmande en énergie encore que sommeil + RAM désactivée? Il ne faut pas oublier ici, toujours pour me livrer à des spéculations, que le but de la man&#339;uvre n'est pas d'ÉTEINDRE le Mac, car le temps de re-boot demeurerait important, mais de minimiser la dépense en énergie d'un Mac inutilisé mais néanmoins directement réactivable. Donc ce qui éventuellement serait la substituation au 'sommeil moyen' de l'hibernation d'un 'sommeil profond' du standby ne pourrait pas franchir un point limite du.. 'Coma' :D. Je me demande additionnellement si ce mode 'Super-hybride' = le SAFE SLEEP----&#8594;STANDBY ou 'SS_S' (lol) ne correspond pas au 'SMART SLEEP' de l'application du même nom?

En fait je me demande plein de choses, à commencer par l'utilité de tous ces raffinements tordus, mais n'utlisant pas d'ordinateur en mode 'nomade', je ne suis certainement pas le mieux placé pour en capturer la subtile 'positivité'...:D]

&#10057;
 
Dernière édition par un modérateur:
macomaniac, merci encore pour ta réponse.

Comme je raisonne d'après mon expérience sur un MacBook Pro_Early 2011 (aucune machine plus récente) <OS = Mountain Lion>, j'ignore tout expérimentalement parlant du mode 'Stand-By' dont bénéficie ton MacBook Air_2013.
D'accord, ça explique donc les divergences entre tes précédentes réponses et ce que j'observe. Comme précisé précédemment, je m'intéresse au fonctionnement sur le Macbook Air 2013. Si tu as des liens vers la doc pour les ordinateurs récents ça m'intéresse car pour l'instant ce que j'ai trouvé sur le site d'Apple est léger.


Pour activer ce mode SLEEP comme préférence durable devenant le 'default' défini par l'utilisateur, il ne faut pas se contenter dans le «Terminal» d'écrire les commandes :

Bloc de code:
pmset -a hibernatemode 0

parce que cette option ne fera pas durer la préférence SLEEP au-delà de la fermeture de session de l'utilisateur
pmset ne peut être utilisé qu'en root et enregistre les changements au niveau du système, pas de l'utilisateur (dans /Library/Preferences/SystemConfiguration/com.Apple.PowerManagement.plist, qui n'est éditable que par l'utilisateur root). Si tu n'utilises pas sudo, il ne se passe rien, c'est tout.

pas plus qu'il ne suffit de commander :

Bloc de code:
rm /private/var/vm/sleepimage

qui supprime le fichier 'sleepimage' en place, pour empêcher la re-création d'une nouvelle 'sleepimage' (vide au re-créé) au re-boot.
Même chose, les droits sur sleepimage étant 600, avec comme propriétaire l'utilisateur root, la commande ci-dessus sans sudo ne fera rien.


Afin d'établir ce mode HIBERNATE comme 'Default' qui se maintiendra au re-boot, il faut écrire dans le «Terminal» :

Bloc de code:
sudo pmset -a hibernatemode 1
Attention à ça néanmoins, c'est clairement déconseillé par Apple. Je ne pense pas qu'il y ait d'impossibilité, mais je suppose qu'ils ne le testent pas autant que les modes 0, 3 et 25.


- d) le mode STAND-BY. D'après ce que je m'en figure, mais sans aucune référence expérimentale de ma part, il doit s'agir d'une option nouvelle, implémentée sur les portables Macs récents, qui permet de soumettre le mode SAFE SLEEP par défaut (hibernatemode 3), sur les portables qui le supportent, à une contrainte temporelle de passage au mode hibernate. Donc un mode que je me risquerais à appeler : 'Super-Hybride'. Enveloppant un triple processus consécutif : 1° écriture préalable de la RAM à la 'sleepimage' ; 2° passage à l'état de sommeil dans lequel la RAM demeure activée [ces 2 processus 1° + 2° correspondent exactement à l'option SAFE SLEEP classique]
Encore une fois, j'en doute. À la fois mes tests et Apple indiquent l'inverse : passage en veille simple d'abord et écriture du contenu de la RAM (après pageing) sur le SSD après standbydelay.

[Comme je suis ici en pleines conjectures spéculatives hors de mon champ d'expérience, une question que je me pose est : le STAND-BY qui intervient après tant de temps défini de SAFE SLEEP est-il la même chose que le mode HIBERNATE = sommeil avec additionnellement désactivation de la RAM? Ou bien correspond-il à une hibernation 'plus profonde', et donc moins gourmande en énergie encore que sommeil + RAM désactivée?
Non, c'est l'inverse. En hibernation, l'ordinateur est physiquement éteint, c'est tout le principe (test simple: si la batterie est retirée ou déchargée pendant l'hibernation, l'ordinateur continue à hiberner). Il ne réagit à rien hormis l'appui sur la touche d'allumage.

En standby, l'ordinateur est presque en hibernation mais continue à alimenter un minimum de composants au moins pour réagir à un appui sur le clavier/trackpad ou une ouverture du capot (couvercle ?).

L'intérêt du standby semble être limité à un démarrage du réveil plus rapide qu'en hibernation car il s'enclenche dès l'ouverture du capot sans attendre que l'utilisateur n'appuie sur la touche power (:mouais:).
L'intérêt du délai avant le standby, par contre, est de ne pas écrire le contenu de la RAM sur le disque pour une "petite sieste". Donc, sur le principe, rien n'empêche Apple d'implémenter un comportement similaire sur les machines ne supportant pas stand-by: qui passeraient automatiquement en hibernation après quelques heures et n'écriraient le contenu de la RAM qu'à ce moment là.

Je me demande additionnellement si ce mode 'Super-hybride' = le SAFE SLEEP----&#8594;STANDBY ou 'SS_S' (lol) ne correspond pas au 'SMART SLEEP' de l'application du même nom?
D'après la description que tu en fais, tout ce que fait le "smart sleep" c'est choisir le mode d'hibernation entre 0, 1 et 3 en fonction de l'état de la batterie au moment de la veille, non ?
 
Je pense que nos points de vue se recoupent pour l'essentiel. Restent quelques points qui paraissent soulever des interprétations divergentes.

&#9099;

En ce qui concerne le «StandBy», où je conjecture qu'il s'agit d'un passage en hibernation après un processus de Safe Sleep :

Encore une fois, j'en doute. À la fois mes tests et Apple indiquent l'inverse : passage en veille simple d'abord et écriture du contenu de la RAM (après pageing) sur le SSD après standbydelay

Si c'est le cas, le «StandBy» serait implémenté sur le mode SLEEP simple, càd. sans backup de la RAM préalable à la 'sleepimage', et donc l'état par défaut devrait être : hibernatemode 0. Ce qui me semble en contradiction avec la règle qui solidarise 'sleepimage' et hibernatemode 3. En cas de défaillance brutale de la batterie dans ce laps de temps de sommeil simple qui précèderait le StandBy, donc pendant le Standbydelay, la RAM serait désactivée et son contenu effacé sans sauvegarde préalable. Donc le StandBy solidaire d'un mode SLEEP simple préalable ne serait pas SAFE. Je n'arrive pas à croire à un tel revirement de la part d'Apple.

Tu donnes un lien à une page Apple où j'ai été voir et voici le contenu décisif :

[The standby mode activates after just over an hour of "regular" sleep.

To enter standby, the computer must: - Be running on battery power [etc...]

The state of the computer is saved to the flash storage (SSD), THEN the power to the hardware subsystems turns off to increase the length of the standby. For example, RAM memory and the USB bus are powered off during the standby.

To exit standby, do any one of the following:

Press a key.
Open the lid.
Click the trackpad.
When the computer exits standby, the state of the system image stored on the flash storage is used to restore the system to its pre-standby state. The computer returns to full operation within a few seconds.

If you leave the computer in standby long enough for the battery to deplete fully, the computer will shut down. You can recover your computer to its pre-standby state and any unsaved work should not be lost. To exit standby at this point, attach the computer to an AC power source and press the Power button.
]


Voici mon interprétation en herméneutique macomaniac : le regular sleep évoqué ne peut en rien être le simple SLEEP, car à partir de 2005 le sommeil par défaut sur les Macs est le SAFE SLEEP conformément à la règle universelle du hibernatemode 3. Donc 'regular' ne peut vouloir dire que 'conforme à la règle par défaut = hibernatemode 3' et donc désigner le SAFE SLEEP. Le SLEEP, qualifié de 'sommeil simple' n'est en rien 'regular', car c'est une option qui fait exception à la règle par défaut du SAFE SLEEP. Il s'ensuit nécessairement que le backup à la 'sleepimage' précède la mise en sommeil conformément à la règle de sécurité ('safe') du SAFE SLEEP.

J'admets alors que la phrase : «The state of the computer is saved to the flash storage (SSD), THEN the power to the hardware subsystems turns off to increase the length of the standby. For example, RAM memory and the USB bus are powered off during the standby.», si elle s'applique toute entière au moment du déclenchement du standby, introduit soit une redondance, soit un paradoxe.

- redondance : si j'admets que le sommeil précédant le standby est le SAFE SLEEP, le backup à la sleepimage est déjà intervenu avant la mise en sommeil. Il y aurait donc redondance d'écriture ;

- paradoxe : si j'admets que le sommeil précédant le standby n'est qu'un simple SLEEP où la RAM demeure activée sans backup préalable à la sleepimage, alors le mode Standby introduit une exception en contradiction avec la règle de sécurité universelle d'Apple qui est le hibernatemode 3. Au lieu d'implémenter le hibernatemode 3 = SAFE SLEEP, il implémenterait un état d'exception à la règle = le hibernatemode 0 = SLEEP (simple et pas regular) où aucun backup à une sleepimage n'est pré-écrit. Cet état d'exception à la règle (consistant alors en un hibernatemode 0), quoique instauré comme 'Default', serait malgré tout 'sur-écrit' (over-written) par l'intervention du Standby (afin qu'une sleepimage' puisse être écrite en contradiction avec le mode 0), sans pourtant qu'il y ait retour à la règle universelle du hibernatemode 3, puisqu'au prochain état de mise en sommeil, le mode SLEEP simple sans backup à la 'sleepimage' devrait de nouveau prévaloir.​

Toute ma logique s'insurge contre l'admission de cette contradiction. Je ne peux, logiquement parlant, qu'introduire une CÉSURE TEMPORELLE dans ma lecture de la phrase, et comprendre : «The state of the computer is saved to the flash storage (SSD)<FIRST>/----------- /<THEN> the power to the hardware subsystems turns off» - où le <first> que j'interpole désignerait le préalable du 'sommeil regular' = SAFE SLEEP = backup à la 'sleepimage' en préalable du sommeil ; et le <then> le passage à l'hibernation après une phase de SLEEP précédé du SAFE, lorsque le standby intervient.


&#9099;

En ce qui concerne l'hibernation, où je déclare qu'il s'agit d'un état de sommeil approfondi et pas d'extinction :

Non, c'est l'inverse. En hibernation, l'ordinateur est physiquement éteint, c'est tout le principe (test simple: si la batterie est retirée ou déchargée pendant l'hibernation, l'ordinateur continue à hiberner). Il ne réagit à rien hormis l'appui sur la touche d'allumage.

À supposer que ce soit le cas, il n'y aurait pas besoin d'inventer un mot (= 'hibernation') différent de l'extinction. Dans ce cas de figure, les anciens Macs (mais post 2005) n'auraient connu que 2 états distincts de l'Éveil : le SLEEP (désactivation des connections externes, pour simplifier + ralentissement des processus internes + maintien de la RAM en activité) et l'EXTINCTION (= désactivation intégrale). Comment alors insérer dans ce scénario le hibernatemode 1, ou sa variante : le hibernatemode 25, que j'appelle au sens strict 'hibernation'? Il ne s'agit pas d'une EXTINCTION, puisqu'il n'y a pas re-boot. Dans mon esprit, il s'agit d'un réveil d'un état de sommeil différent de celui du SLEEP simple en ce que la RAM a été désactivée. Sans qu'il y ait re-boot, il faut donc le temps de délai de lecture de la 'sleepimage' pour que le réaffichage intervienne. En mode automatique, ce me semble ce qui intervient aux 20% de charge batterie ; l'EXTINCTION ('powering off') aux 5%.

Si tu t'appuies sur la phrase du texte d'Apple : « the power to the hardware subsystems turns off to increase the length of the standby. For example, RAM memory and the USB bus are powered off during the standby» pour le déclarer, moi je ne fais pas la même lecture. Je ne lis pas : «The computer is powered off», je lis «The hardware subsystems and the RAM are powered off», parce que le 1er cas de figure signifie l'extinction pure et simple, incompatible avec un réveil sans re-démarrage (re-boot), alors que le 2 cas de figure évoque une désactivation de la RAM et de systèmes périphériques du hardware, mais en aucun cas une désactivation du PROCESSEUR qui se trouve low-powered et pas powered off ; et en aucun cas une désactivation du KERNEL et de l'architecture de l'OS telle que le Kernel l'a déployée. Car si c'était le cas, il ne pourrait en aucun cas y avoir 'réveil' sans re-démarrage, ce qui impliquerait notamment que l'EFI_Firmware devrait reprendre la main en point de départ du processus. Ce qui n'est pas le cas en réveil d'hibernation - du moins si je ne confonds pas ce concept avec celui d'extinction.


&#9099;
 
Dernière édition par un modérateur:
Si c'est le cas, le «StandBy» serait implémenté sur le mode SLEEP simple, càd. sans backup de la RAM préalable à la 'sleepimage', et donc l'état par défaut devrait être : hibernatemode 0. Ce qui me semble en contradiction avec la règle qui solidarise 'sleepimage' et hibernatemode 3. En cas de défaillance brutale de la batterie dans ce laps de temps de sommeil simple qui précèderait le StandBy, donc pendant le Standbydelay, la RAM serait désactivée et son contenu effacé sans sauvegarde préalable. Donc le StandBy solidaire d'un mode SLEEP simple préalable ne serait pas SAFE. Je n'arrive pas à croire à un tel revirement de la part d'Apple.
hibernatemode 0 veut dire désactivation totale de l'hibernation, ce qui n'est pas le cas ici.
Quand au revirement, il est assez relatif. Prenant en compte le fait que
  1. Les batteries sont maintenant inamovibles
  2. Tu expliques qu'il y a sauvegarde automatique lorsque la batterie descent à 20% de sa capacité
Les seuls cas à risque (réduit qui plus est par la sauvegarde automatique depuis Lion) sont, comme tu le dis, une défaillance brutale de la batterie, de la RAM, de la carte mère, etc. Honnêtement, ça n'a pas plus de chances de se produire en veille qu'en utilisation normale.

- paradoxe : si j'admets que le sommeil précédant le standby n'est qu'un simple SLEEP où la RAM demeure activée sans backup préalable à la sleepimage, alors le mode Standby introduit une exception en contradiction avec la règle de sécurité universelle d'Apple qui est le hibernatemode 3. Au lieu d'implémenter le hibernatemode 3 = SAFE SLEEP, il implémenterait un état d'exception à la règle = le hibernatemode 0 = SLEEP (simple et pas regular) où aucun backup à une sleepimage n'est pré-écrit. Cet état d'exception à la règle (consistant alors en un hibernatemode 0), quoique instauré comme 'Default', serait malgré tout 'sur-écrit' (over-written) par l'intervention du Standby (afin qu'une sleepimage' puisse être écrite en contradiction avec le mode 0), sans pourtant qu'il y ait retour à la règle universelle du hibernatemode 3, puisqu'au prochain état de mise en sommeil, le mode SLEEP simple sans backup à la 'sleepimage' devrait de nouveau prévaloir.[/INDENT]
Plutôt qu'une contradiction ou un paradoxe, je vois ça comme un simple report temporel. On est bien dans un mode "safe sleep" au sens où, si la batterie s'épuise, je récupèrerai quand même mes données. Contrairement au mode 3, il y a séparation temporelle de l'entrée en veille et de l'écriture de l'état de la RAM. C'est pour ça je suppose que mon ordinateur indique 3 plutôt que zéro, car zéro est clair sur le fait qu'il n'y a pas d'hibernation du tout.

Toute ma logique s'insurge contre l'admission de cette contradiction. Je ne peux, logiquement parlant, qu'introduire une CÉSURE TEMPORELLE dans ma lecture de la phrase, et comprendre : «The state of the computer is saved to the flash storage (SSD)<FIRST>/----------- /<THEN> the power to the hardware subsystems turns off» - où le <first> que j'interpole désignerait le préalable du 'sommeil regular' = SAFE SLEEP = backup à la 'sleepimage' en préalable du sommeil ; et le <then> le passage à l'hibernation après une phase de SLEEP précédé du SAFE, lorsque le standby intervient.
Non, tout le paragraphe se situe après la phrase "The standby mode activates after just over an hour of "regular" sleep".
Et encore une fois, mes tests confirment qu'il n'y a pas écriture du fichier sleepimage au moment de la veille. Je ne sais pas pourquoi par contre Apple indique 1h par défaut sur sa kb, et le réglage du Macbook Air est à 3h. Peut-être que, les nouvelles machines ayant une meilleure autonomie, il a été décidé d'augmenter le délai.



À supposer que ce soit le cas, il n'y aurait pas besoin d'inventer un mot (= 'hibernation') différent de l'extinction.

Dans ce cas de figure, les anciens Macs (mais post 2005) n'auraient connu que 2 états distincts de l'Éveil : le SLEEP (désactivation des connections externes, pour simplifier + ralentissement des processus internes + maintien de la RAM en activité) et l'EXTINCTION (= désactivation intégrale). Comment alors insérer dans ce scénario le hibernatemode 1, ou sa variante : le hibernatemode 25, que j'appelle au sens strict 'hibernation'? Il ne s'agit pas d'une EXTINCTION, puisqu'il n'y a pas re-boot. Dans mon esprit, il s'agit d'un réveil d'un état de sommeil différent de celui du SLEEP simple en ce que la RAM a été désactivée. Sans qu'il y ait re-boot, il faut donc le temps de délai de lecture de la 'sleepimage' pour que le réaffichage intervienne. En mode automatique, ce me semble ce qui intervient aux 20% de charge batterie ; l'EXTINCTION ('powering off') aux 5%.
Les deux apportent des fonctions bien différentes à l'utilisateur. Dans un cas (extinction, pré 10.7) on redémarre de rien, dans l'autre on récupère toute sa session.

Au niveau alimentation des composants, néanmoins, il n'y a que la veille et l'extinction (et le standby récemment, qui est comme tu dis un sommeil profond). L'hibernation n'est pas un état intermédiaire: l'ordinateur est physiquement éteint.
C'est pour ça que pour le sortir d'hibernation tu dois utiliser la touche "power" et pas n'importe quelle touche comme en veille (ou en standby). C'est pour ça que, si tu as un ordi avec lecteur CD, tu entends le bruit de son initialisation comme un démarrage normal. C'est pour ça aussi que la note d'Apple dit "si votre ordinateur mets du temps à sortir du stand-by (qui, comme l'hibernation, récupère le contenu de la RAM depuis le disque), vérifiez que le disque de démarrage est sélectionné correctement".

Raisonnons à l'inverse : si l'hibernation avait besoin de courant, que ce passerait-il une fois que la batterie atteint zéro %? Le fait que, même en retirant la batterie (sur un ordi qui le permet), on récupère toujours nos données après, confirme que le but de l'hibernation est bien de récupérer son état en cas de coupure de l'alimentation (sinon, pourquoi appeler "safe sleep" le mode de veille qui repose sur l'hibernation pour garantir la conservation de cet état?).

Si tu t'appuies sur la phrase du texte d'Apple : « the power to the hardware subsystems turns off to increase the length of the standby. For example, RAM memory and the USB bus are powered off during the standby» pour le déclarer, moi je ne fais pas la même lecture. Je ne lis pas : «The computer is powered off», je lis «The hardware subsystems and the RAM are powered off», parce que le 1er cas de figure signifie l'extinction pure et simple, incompatible avec un réveil sans re-démarrage (re-boot), alors que le 2 cas de figure évoque une désactivation de la RAM et de systèmes périphériques du hardware, mais en aucun cas une désactivation du PROCESSEUR qui se trouve low-powered et pas powered off ; et en aucun cas une désactivation du KERNEL et de l'architecture de l'OS telle que le Kernel l'a déployée. Car si c'était le cas, il ne pourrait en aucun cas y avoir 'réveil' sans re-démarrage, ce qui impliquerait notamment que l'EFI_Firmware devrait reprendre la main en point de départ du processus.
En gros oui. En mode standby, contrairement à l'hibernation, certains éléments matériels restent alimentés. Le système et son noyau ne sont néanmoins plus chargés en mémoire et l'ordinateur repart de ce qui est sur le disque (sur ma machine ça prend moins de 5 secondes, merci le SSD rapide).
 
Salut Dark White Templar :D

Après ré-examen matinal des arguments échangés, il me faut reconnaître que la vérité m'a échappé sur les deux points cruciaux du débat, alors qu'elle ne t'échappait pas. Bref, que ce sont tes idées qui sont en adéquation avec les faits, et non les miennes.

[Il m'est d'autant moins difficile ici de reconnaître une erreur que cette reconnaissance s'accompagne simultanément de l'admission d'une vérité. La reconnaissance d'une erreur, lorsque par exemple une idée ne s'avère manifestement pas en concordance avec un donné de faits, met davantage l'esprit en difficulté quand aucune vérité n'est disponible pour remplacer les jugements erronés, et donc que l'admission d'avoir erré ne donne lieu qu'à la situation d'ignorance de quelqu'un qui ne sait plus quoi penser du tout à propos d'un objet quelconque. Il me revient que Descartes voit dans la «précipitation d'esprit» la raison principale de l'«erreur», parce que, dit-il, l'esprit des hommes répugne invinciblement à n'avoir aucune idée des choses et à se trouver bêtement confronté à des faits bruts de l'expérience. C'est-à-dire que l'esprit humain privlégie l'intellligibilité, fût-elle inadéquate, à l'inintelligibilité d'une expérience irrationnelle. D'où, remarque-t-il de façon acérée, la volonté des hommes d'échapper à un état durable d'incompréhension qui accorde aux faits bruts l'hégémonie, pour précipiter leur adhésion sur des jugements qui les éclairent, quand bien même cette lumière d'intelligible ne prendrait les choses qu'avec le biais de l'erreur, au lieu de la droiture du vrai. Il en tire la conséquence qu'il n'est pas aussi difficile qu'on l'imagine de quitter le faux pour le vrai, lorsque le vrai s'offre à l'esprit, si l'esprit n'oublie pas en chemin que l'obscure clarté des idées incertaines s'empruntait à distance à la lumière d'évidence.]

- 1° en ce qui concerne l'hibernation.

J'ai fait le test (par quoi j'aurais dû commencer, en sortant de l'état de 'sommeil' = hibernatemode 0 qui avait mes préférences sur mon MacBook Pro :)) d'activer le mode hibernation stricto sensu (= hibernatemode 1) sur mon ordinateur. Constat des faits :

a) à l'activation de la commande dans le «Terminal», un fichier 'sleepimage' de la taille de la RAM (&#8771; 8 Go sur mon Mac) se crée avant tout backup à l'adresse : /private/var/vm. Le fichier est vide d'écriture, à l'instar d'une image-disque vide créée par l'Utilitaire de Disque avant toute écriture de contenus dans son espace.

b) la mise en sommeil du Mac (j'ai choisi de refermer le couvercle comme procédé) s'accompagne pendant 30" (sur mon Mac) d'un signal lumineux fixe au voyant de la tranche avant du portable, lequel s'éteint complètement ensuite. Le couvercle réouvert, la réactivation du Mac n'est effectivement possible qu'en pressant le bouton 'Power', ce qui déclenche (sur mon Mac) le bruit classique du test à vide du Super-Drive avant écran laiteux où s'entrevoit en une sorte d'image-filigrane l'espace du Bureau avec ses objets et les fenêtres ouvertes d'applications (j'ai fait le test pendant que j'improvise cette réponse : je vois la fenêtre ouverte de Safari à la page du forum MacBook Air et le brouillon du texte que j'ai amorcé). Cet affichage de type : 'filigrane laiteux' s'accompagne d'une barre de chargement pointillée en bas de l'écran le temps de la réactivation des processus à l'écran.​

&#10056;

L'hibernation conduit donc le Mac au même état qu'une extinction =un «power-off» complet, et la sortie de cet état est bien un re-démarrage, le bruit du Super-Drive signalant bien le re-déclenchement de l'EFI-Firmware de la Carte-Mère comme lors d'un démarrage ou re-démarrage standard. La différence avec le processus standard d'extinction paraît se situer à la fois en amont et en aval. 'En amont' : il y a backup des contenus de la RAM à la sleepimage du DD (ce qui prend les 30" de signal lumineux fixe que je constate) ; 'en aval' : le re-démarrage, s'il commence de la même manière en mode 'sortie_d'hibernation' et en mode 'sortie_d'extinction', paraît diverger à un point donné du processus.
- En 'sortie_d'extinction', la séquence : EFI_check-up Hardware/Firmware_exécution_boot.efi_lanceur_mach_kernel_démarrage autonome du noyau (kernel/kexts) &#8594; donne lieu à un processus de déploiement de l'architecture de l'OS 'branche à branche' si je peux dire avant écran de mot-de-passe de session (44" sur mon Mac) ; après quoi, l'ouverture de session, si j'attends l'activation complète de toutes les applications prédéfinies qui se lancent à l'ouverture (dont DropBox, Butler, EarthDesk...), prend exactement 1' 35" (sic). Donc au total 2' 30' en comprenant la frappe des identifiants de session.

- En 'sortie d'hibernation', je présume une identité de processus (tu vas me dire : encore de l'aventurisme conjectural à la macomaniac) de la séquence : EFI_check-up Hardware/Firmware_exécution_boot.efi_lanceur_mach_kernel_démarrage autonome du noyau (kernel/kexts) &#8594; à partir de quoi je me figure un déploiement de l'OS à partir de la lecture de la sleepimage. Ce processus complet prend 30", 4" pour EFI_check-up Hardware/Firmware_exécution_boot.efi_lanceur_mach_kernel_démarrage autonome du noyau (kernel/kexts) &#8594; scan de la sleepimage donnant l'affichage-filigrane, et 25" pour le chargement complet de l'OS avec session active.​

La sortie de l'état de 'power off' du mode hibernation est donc de 2' plus rapide que la sortie de l'état de 'power off' du mode extinction. Sans compter que l'affichage des fenêtres des applications ouvertes dans le 1er cas, alors que dans le 2è tout est à relancer à neuf.

&#9099;

2° en ce qui concerne le standby.

- a) Les faits.

Ne disposant pas d'un Mac qui le supporte à ta différence, je me suis trouvé à conjecturer ce qui pouvait se passer ou ne pouvait pas se passer à partir de réquisits logiques, tandis que tu disposais de données de faits constatables permettant d'étalonner tes idées. Comme je n'ai pas de raisons de remettre en doute les faits que tu rapportes, mieux vaut que je les admette comme avérés, au lieu d'en fabriquer d'imaginaires.

Donc, lorsque l'option «standby» est choisie sur un portable qui la supporte, le déclenchement de ce type de mise en veille (au refermement du couvercle du Mac, admettons) produit dans l'ordre :

- 1° zéro backup de la RAM à la sleepimage (j'admets tes constats lorsque tu dis qu'aucun travail d'écriture qui serait intervenu n'est enregistré dans les logs).

mise en sommeil normal, conformément au dénominateur commun de cet état entre le sommeil simple (SLEEP) et le sommeil sécurisé (SAFE SLEEP), qui est pour l'essentiel : ON_POWERED = RAM ; LOW_POWERED = Processeur ; SPIN_DOWN = disques qui tournent s'il y a lieu ; OFF_POWERED : ports notamment.

backup à la sleepimage passé le délai imparti de sommeil normal dit 'standbydelay'.

passage au standby équivalant non pas à une hibernation (car il n'y a pas de 'powering_off' complet de l'ordinateur impliquant la nécessité d'un re-démarrage à partir de l'EFI) ; mais à une accentuation de l'état de sommeil normal, càd. passage à un sommeil profond. Ce qui se marque par une extension du OFF_POWER (sans qu'il s'agisse de sa généralisation complète), soit OFF_POWER = RAM + (je conjecture à nouveau) davantages de sous-composants hardware notamment.

sortie du standby par lecture de la sleepimage sans re-démarrage à partir de l'EFI.​

Donc : j'admets cet état de choses d'après tes observations (et une lecture désormais au 1er degré du texte d'Apple, sans ergotage herméneutique :))

&#10056;

- b) l'interprétation des faits.

C'est là que je récupérerais volontiers ma liberté d'esprit critique, non certes contre toi, mais en & pour soi par confrontation de ces données de faits avec les exigences logiques. Au cas où tu n'es pas harrassé de ma prose, il se trouve que dans un autre fil j'ai été amené à deux considérations concernant la contradiction logique (ici : messages #14 & #23) qui s'abrègent par la définition de la contradiction comme conjonction ('ET' = &) d'une proposition affirmative universelle de type : (&#8704;)X_P & d'une proposition existentielle négative qui lui fait exception de type : (&#8707;)X_non-P (ex. : «Tous les hommes sont mortels» ET «Quelques hommes ne sont pas mortels». La conjonction :' ET' signifie que les 2 propositions sont admises simultanément et regardant le même espace comme vraies (= 1, ou 'TRUE'). La contradiction logique, à la différence de la contrariété logique ((&#8704;)X_P & non-(&#8704;)X_PTous les hommes sont mortels» & «Aucun homme n'est mortel» = 'TRUE' qui est bloquante, car absurde, et donc ne conduit à aucun processus au-delà de sa position - la contradiction logique, donc, entrelace les effets d'une règle générale aux effets d'une exception particulière. Elle permet donc un processus, mais ce dernier est incohérent.

Si je raconte tout ça, c'est parce que l'option exceptionnelle du Standby me paraît introduire une contradiction logique dans les instructions de programmation de OS X par son affirmation = 'TRUE' en conjonction (ET = &) avec la règle générale du Safe Sleep elle-même affirmée = 'TRUE'.

Car lorsque tu déclares :

mon ordinateur indique 3 plutôt que zéro

je comprends que dans le «Terminal», activée l'option «standby», tu as passé la commande :

Bloc de code:
pmset -g | grep hibernatemode

et tu as obtenu comme réponse :

Bloc de code:
hibernatemode      3

ce qui prouve que la règle générale du safe sleep est bien activée en conjonction (ET) avec l'option exceptionnelle du standby.

Je lis ainsi la contradiction : la règle hibernatemode 3 commande que la séquence : backup &#8594; sleep = TRUE dans tous les cas ; l'exception standby commande que la séquence : backup &#8594; sleep = FALSE dans un cas.

Car il semble clair que l'option du standby n'est pas une nouvelle règle générale, comme hibernatemode 0 ou hibernatemode 1 le sont, si bien que : si hibernatemode 0 = TRUE, alors hibernatemode 3 = FALSE ; mais une exception à la règle affirmée en conjonction de la règle hibernatemode 3 = TRUE.

Comment les développeurs d'Apple s'y sont-ils pris pour 'gérer' ces instructions in & per se contradictoires? Je dois dire que cela m'intéresserait d'avoir sous les yeux leur code. Dans le cas de la contradiction de 'Layouts Constraints' que j'avais relevé dans les logs sur le fil que j'ai évoqué, le remarquable est qu'il y a a priori dans OS X un programme ('AUTO LAYOUT') chargé de 'surmonter' une telle contradiction d'instructions en dégradant la priorité de l'instruction qui fait exception par rapport aux instructions qui tiennent lieu de règle parce que cohérentes. Ce par un report temporel de l'exécution de l'instruction eu égard à l'exécution actuelle des instructions régulières.

Mais il s'agit là d'une exception accidentelle suscitée par l'installation d'applications tierces, alors que l'instruction du standby est une exception programmée. Quand tu dis :

Plutôt qu'une contradiction ou un paradoxe, je vois ça comme un simple report temporel. On est bien dans un mode "safe sleep" au sens où, si la batterie s'épuise, je récupèrerai quand même mes données. Contrairement au mode 3, il y a séparation temporelle de l'entrée en veille et de l'écriture de l'état de la RAM. C'est pour ça je suppose que mon ordinateur indique 3 plutôt que zéro, car zéro est clair sur le fait qu'il n'y a pas d'hibernation du tout.

j'ai bien l'impression que tu suspectes toi aussi une contradiction d'instructions à établir l'option standby (qui implique en un cas que : backup &#8594; sleep = FALSE) en conjonction avec la règle du hibernatemode 3 ou safe sleep (qui implique dans tous les cas que : backup &#8594; sleep = TRUE). Et, au vu de la façon dont opère dans les faits l'option standby, que tu irais dans le sens d'une solution trouvée par les développeurs consistant dans une dégradation de la priorité des instructions de la règle avec report temporel.

Le problème étant, à l'inverse de la contradiction des 'Layouts Constraints' où c'est la priorité de l'exception qui est dégradée par rapport à ce qui tient lieu de règle (la cohérence générale des autres 'Constraints'), qu'il s'agirait ici de dégrader la priorité de la règle en faveur de l'exception (comme ce que fait l'ordinateur HAL dans le film «2001»). J'imaginerais pour ma part que les développeurs ont plutôt instruit à l'intérieur de la règle hibernatemode 3 une variation de conditions d'exécution selon que le cas de figure : standby = TRUE or FALSE - ce qui a des chances de déboucher sur l'effet que tu décris.

J'ai peur d'atteindre les limites spatiales d'un post unique, donc j'abrège pour dire que : cette contradiction d'instructions, même gérée programmatiquement, introduit quand même au niveau de l'universalité de la règle sécuritaire a priori de la mise en veille (= backup préalable) une exception in-sécuritaire tout le temps du SLEEP normal qui est déconcertante.

&#9099;
 
Dernière édition par un modérateur:
Bonsoir,
Juste pour apporter ma contribution, non pas sur la mise en veille prolongée et son fichier idoine , mais sur la durée de vie du SSD.
Ce qui suit n'est qu'une compilation de tout ce que j'ai pu comprendre de ce que j'ai lu du net. J'ai pu mal interpréter des choses...


Je pense qu'on a trop peur pour le SSD, et que la légende urbaine du SSD qui peut vieillir très vite prend trop le dessus sur la réalité.
Chez pcinpact (ou encore pcworld) ils ont fait des tests il y a quelques temps sur la durée de vie des SSD.
Actuellement, avec les commandes TRIM, la durée de vie des cellules est d'environ 10000 cycles (d'écriture). Ce qui correspond à peu près à 5 années non stop d'utilisation (donc bien plus longtemps avec les portables qui n'ont pas la vocation d'être utilisés H24) avec des écriture de plusieurs milliers de Gigaoctets par jours (5 To sur pcworld). USage qui est largement hors de propos en tant que disque système, et même pour nous dans les MBA.
Après avoir écrit plus de 240 To écrits, leur SSD (à pcworld) n'affichait une usure que de 4500 cycles.
Bref, je pense que le fichier de mise en veille prolongée, comme le swap, ne risque pas de nuire à la durée de vie du SSD. Du moins pas avant minimum 5-10 ans. D'ici là on aura déjà changé de machine, à mon avis.
 
OK, macomaniac, je pense que nous avons maintenant la même compréhension des choses. Le caractère in-sécuritaire de l'exception est tout relatif (je n'ai pas le MTBF des composants mais en gros on tomberait dans le cas "vraiment pas de bol" :rateau:). Je trouve personnellement que c'est un bon compromis.

Pour l'introduction d'une contradiction ou en tout cas d'une certaine incohérence entre le comportement décrit dans le man et le comportement réel je suis d'accord: hibernatemode = 3 implique
  • sauvegarde de la ram au moment de la veille --> faux
  • conservation de l'alimentation de la RAM tant que la batterie n'atteint pas un état critique --> faux
Donc, un cas d'exception rajouté sans vouloir toucher à la définition de l'interface (à défaut de parler d'API), ce qui n'est pas forcément très bon.

PS: il n'y a pas de white templar, seulement des (high) templar et des dark templar (très important :siffle: ).

Je pense qu'on a trop peur pour le SSD, et que la légende urbaine du SSD qui peut vieillir très vite prend trop le dessus sur la réalité. [...]
C'est ce qui ressort de ce que j'ai pu lire récemment. Même en considérant que certains disques grand public sont plutôt donnés à 3000 qu'à 10000 cycles, il semble que les fabricants aient été très conservateurs dans leurs annonce (ce que je comprend). Donc, tant que mon disque ne se rempli pas, je ne me fais pas plus de souci que ça, bien que je garde mes ordis 5 ans.