Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Le Mac Mini 2018

68 réponses
Avatar
Manfred La Cassagn=c3=a8re
Bonjour à tou(te)s,

une question simple ce matin:
maintenant qu'on nous a présenté la bête, y en a-t-il parmi vous qui
comptent investir dans ce nouveau Mini?
A+
--
Manfred
Middle Of Nowhere
iMac Intel Core 2 Duo, early 2009, OS X 10.11.6
"I would trade all my technology for an afternoon with Socrates."(S.J.)

8 réponses

3 4 5 6 7
Avatar
voir_le_reply-to
pehache wrote:
Ceci dit ton choix de redémarrer n'est pas rationnel : le temps perdu à
le faire dépasse largement le temps que tu vas (éventuellement) gagner
par la suite. Et tu arriverais au même résultat avec un simple "sudo
purge".

Je prends bonne note de ton conseil et je l'archive, mais dans mon monde
"à moi" (qui ne prétend à rien) les raisons que tu invoques sont à
moduler à l'aune du SSD interne et de la vélocité de la machine :
1/ le swap a complètement été révolutionné par les SSD : je ne sais pas
si, sur le plan théorique, on peut arriver à faire une différence entre
les vitesses de lecture/écriture dans la RAM ou sur le SSD, mais à
l'utilisation que j'en ai, je ne décèle aucune différence. Aussi bien
mes redémarrages ne sont plus motivés par l'apparition d'une grande
"rammerie", mais seulement par un désir de "propre" parfaitement
arbitraire, vestige de ma manière de faire "d'avant". (ai-je besoin de
dire que pour moi le SSD est une révolution et que j'en suis fan ?)
2/ Le boot d'un SSD sous Mojave, franchement, ça se compte en secondes
désormais. À mettre en balance avec le lancement du terminal et la
saisie de ta commande... et surtout avec le fait que cela ne résout QUE
la question du cache. Je ne sais pas si d'autres éléments que le cache
ne sont pas réinitialisés par le redémarrage. Des infos ?
--
Gérald
Avatar
Patrick
On 2018-11-15 17:34:06 +0000, pehache said:
Le 15/11/2018 à 18:00, Patrick a écrit :
On 2018-11-15 15:51:33 +0000, pehache said:
Le 15/11/2018 à 16:34, Patrick a écrit :

Tu aurais de la documentation ou des URL sur le « swap en mémoire »

"swap en mémoire" je ne connais pas ce terme :-)

Les guillemets qui encadrent l'expression t'ont sans doute échappés ;-)
qu'effectuerait Windows ou les différents Unix depuis des lustres.
Parce que, moi, je cherche encore. Je ne savais pas que sur ces OS tout
comme sur macOS depuis peu, une application qui quitte ne libèrait pas
les ressources qui lui sont associées. Je ne demande qu'à apprendre.

par exemple
https://www.randco.fr/blog/2012/gestion-de-la-ram-sous-linux/
https://docs.microsoft.com/en-us/windows/desktop/fileio/file-caching

Merci pour les liens. Concernant Linux, je lis :
Comme nous l’avons vu précédemment, comparé à la RAM, un disque dur est
environ 100x plus lent. C’est dans ce cadre qu’est utilisé la mémoire
tampon. Linux place dans celle-ci toutes les données en attente
d’écriture sur le disque, les données lues sur un disque conservées
pour améliorer les performances du système (resultat d’un ‘ls’, droits
sur les fichiers, …), la position des blocs libres sur les disques, ...
En bref, toutes les informations utiles pour augmenter les performances
du système dans ses interactions avec les périphériques tel que les
disques durs.

Et pour Windows :
By default, Windows caches file data that is read from disks and
written to disks. This implies that read operations read file data from
an area in system memory known as the system file cache, rather than
from the physical disk. Correspondingly, write operations write file
data to the system file cache rather than to the disk, and this type of
cache is referred to as a write-back cache.

Placer en mémoire cache les opérations de lecture et les opérations en
attente d'écritures sur des fichiers, IBM le faisait déjà dans les
années 80. L'idée est d'éviter une entrée-sortie sur disque à chaque
lecture / écriture de fichier.
On ne parle pas du tout de la même chose.
Avatar
Patrick
On 2018-11-15 19:02:24 +0000, pehache said:
Le 15/11/2018 à 19:40, Gilbert OLIVIER a écrit :
pehache wrote:
Le 15/11/2018 à 17:15, Gerald a écrit :
2/ d'expérience, l'ouverture successive d'applications diverses puis
leur fermeture fait qu'au bout d'un moment la "mémoire" active est de
plus en plus utilisée. Aboutissant parfois au swap et donc, à terme de
quelques jours, poru moi, au redémarrage pour faire propre.

Ca c'est possible : quand il n'y a pas de RAM libre et qu'une appli en
demande, l'OS doit arbitrer entre benner des données conservées en cache
(ce qui est immédiat) ou swapper une application ouverte de la RAM vers le
disque (ce qui est plus lent).

Sans oublier la mémoire compressée.

Oui
C'est dans cet arbitrage qu'elle intervient ou bien elle dépends
d'autres processus?

J'imagine, mais en pratique je ne sais pas.

macOS compresse la mémoire vive sous deux conditions :
- La machine commence à saturer car elle manque de RAM par rapport au
nombre de process en cours d'exécution et de leur pression sur la
mémoire.
- Le compression sera effectuée uniquement sur des applications
ouvertes mais inactives afin de libérer de l'espace. Si cela ne suffit
pas les ressources de l'application seront paginées et donc écrites sur
disque.
Donnez de la mémoire à votre Mac, il vous le rendra au centuple ;-)
Avatar
Patrick
On 2018-11-15 17:40:16 +0000, pehache said:
Le 15/11/2018 à 18:10, Patrick a écrit :
Là, tu parles d'APFS, le nouveau système de fichiers d'Apple. Mais
pehache va nous dire que c'est une gestion de fichiers classique qui
existe sur tous les OS qu'il connaît ;-)

Il va surtout dire que le système de fichier (APFS ou autre) est
indépendant de l'OS. Le fichier que la simple duplication d'un fichier
n'entraine pas l'allocation de nouveaux blocs sur le disque est une
caractéristique d'APFS, pas de macOS.

J'ai parlé concernant APFS de système de fichiers, pas d'OS. Et puis
faire tourner NTFS sous macOS ou APFS sous Windows est quand même une
gageure.
Il va aussi dire que les caractéristiques d'APFS sont grosso-modo les
mêmes que celles de ZFS, qui a été introduit en 2005 par Sun.
Il y a aussi des changements au niveau de la gestion de la RAM. macOS
Mojave a des secrets bien enfouis sous le capot.

Il faudrait surtout arrêter de penser que macOS recèle des trucs
extraordinaires qui n'existeraient nulle part ailleurs. D'autant moins que
le code source du noyau et de toute la base de l'OS est libre, donc un
"secret" ne le resterait pas bien longtemps.

Bon écoute, je me lasse de ces propos de cour d'école. Propos qui
reflètent bien ce qu'est devenu Usenet, malheureusement.
Avatar
JPP
In article
<1nybtai.15o9f4k1c6nqm0N%
,
(Gerald) wrote:
2/ Le boot d'un SSD sous Mojave, franchement, ça se compte en secondes
désormais.

A ce propos, je m'étonne du temps qu'il faut pour voir apparaitre la
barre de progression du démarrage sur mon iMac 13,2/late 2012
(SSD512/16GB/HSierra), soit 20 à 30s.
Est-ce dû à la vérification des 16GB de RAM ?
Le iMac 7,1/mid 2007 (SSD256/4GB/El Capitan)) démarre bien plus vite de
même que le MBP13 9,2/mid 2012 (SSD256/8GB/El Capitan)
Avatar
JPP
In article <5bee940e$0$20311$,
Patrick wrote:
les ressources de l'application seront paginées et donc écrites sur
disque.

Le "et donc" est de trop :-)
En RAM tout est paginé (voir mon post précédent), le swap exporte les
pages sur le volume système selon un algorithme qui doit prendre pas mal
de critères en compte en dehors de la simple ancienneté des pages
inutilisées en mémoire.
Avatar
voir_le_reply-to
JPP wrote:
2/ Le boot d'un SSD sous Mojave, franchement, ça se compte en secondes
désormais.

A ce propos, je m'étonne du temps qu'il faut pour voir apparaitre la
barre de progression du démarrage sur mon iMac 13,2/late 2012
(SSD512/16GB/HSierra), soit 20 à 30s.
Est-ce dû à la vérification des 16GB de RAM ?

Aucune idée... plutôt le lancement des disques à plateaux ?
Mais tu as aiguisé ma curiosité et je viens d'aller chronométrer mon
redémarrage après extinction complète (puisqu'il n'y a plus de son de
démarrage pour donner le top départ. Mon disque interne est chiffré, le
boot se fait donc en deux temps : pré-boot qui amène sur l'écran de
déverrouillage, puis boot avec barre de progression, jusqu'à apparition
de la barre des menus et fin de l'ouverture de session :
pré-boot = 18 s
boot = 22 s
C'est marrant, intuitivement j'avais l'impression d'un pré-boot quasi
instantané mais ce n'est pas le cas et c'est logique : il y a bien un
boot véritable, sur le système de la partition recovery, les chiffres
sont donc logiquement très semblables. Les quatre secondes de différence
peuvent même probablement s'expliquer par la détection de l'iPhone et de
l'iPad qui étaient branchés en recharge et qui se signalent par un
signal sonore avec léger ralentissement de la barre de progression.
Mon affirmation ci-dessus devient donc : "le boot d'un SSD sous Mojave,
ça prend environ 40 s. désormais". (à quoi, en toute honnêteté, il
faudrait rajouter la saisie des mots de passe pour déverrouiller les
disques externes, et le lancement éventuel automatique d'applications.
Par contre le lancement de mes utilitaires était compris dans les 22 s.
à savoir PopChar, CCC User Agent, Dropbox et iStat Menus.
À moins d'une minute tout compris pour revenir au même état
opérationnel, un redémarrage "de propreté" est désormais
particulièrement indolore.
--
Gérald
Avatar
pehache
Le 17/11/2018 à 02:57, Gerald a écrit :
JPP wrote:
2/ Le boot d'un SSD sous Mojave, franchement, ça se compte en secondes
désormais.

A ce propos, je m'étonne du temps qu'il faut pour voir apparaitre la
barre de progression du démarrage sur mon iMac 13,2/late 2012
(SSD512/16GB/HSierra), soit 20 à 30s.
Est-ce dû à la vérification des 16GB de RAM ?

Aucune idée... plutôt le lancement des disques à plateaux ?
Mais tu as aiguisé ma curiosité et je viens d'aller chronométrer mon
redémarrage après extinction complète (puisqu'il n'y a plus de son de
démarrage pour donner le top départ. Mon disque interne est chiffré, le
boot se fait donc en deux temps : pré-boot qui amène sur l'écran de
déverrouillage, puis boot avec barre de progression, jusqu'à apparition
de la barre des menus et fin de l'ouverture de session :
pré-boot = 18 s
boot = 22 s
C'est marrant, intuitivement j'avais l'impression d'un pré-boot quasi
instantané mais ce n'est pas le cas et c'est logique : il y a bien un
boot véritable, sur le système de la partition recovery, les chiffres
sont donc logiquement très semblables. Les quatre secondes de différence
peuvent même probablement s'expliquer par la détection de l'iPhone et de
l'iPad qui étaient branchés en recharge et qui se signalent par un
signal sonore avec léger ralentissement de la barre de progression.
Mon affirmation ci-dessus devient donc : "le boot d'un SSD sous Mojave,
ça prend environ 40 s. désormais". (à quoi, en toute honnêteté, il
faudrait rajouter la saisie des mots de passe pour déverrouiller les
disques externes, et le lancement éventuel automatique d'applications.
Par contre le lancement de mes utilitaires était compris dans les 22 s.
à savoir PopChar, CCC User Agent, Dropbox et iStat Menus.
À moins d'une minute tout compris pour revenir au même état
opérationnel, un redémarrage "de propreté" est désormais
particulièrement indolore.

Reboot d'un (bon) PC de 2007, amélioré avec un SSD, actuellement sous
Xubuntu : 20s tout compris.
macOS est incroyablement lourd.
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
3 4 5 6 7