Pour la nowel je vais (me faire) offir un SSD à mon mac mini 2009.
Il ira à la place de l'ancien DD et l'ancien ira dans un caddy à la
place du graveur qui est mort depuis belle lurette.
Le budget est de maxi 100 euros.
Lequel pouvez-vous me conseiller ?
La star du moment semble être le Vertex 3 ; qu'en pensez vous ?
60 Go me semble un strict minimum pour ce que j'ai à y mettre.
(Je vous demanderais plus tard quoi mettre dessus, système, applis...)
On Dec 5, 5:05 pm, patpro ~ patrick proniewski wrote: > > > Gérer la répartition entre SSD et DD au niveau de l'OS, donc > > en ayant connaissance du système de fichiers, permet priori d'avoir > > des stratégies plus sophistiquées qu'au niveau du contrôleur du > > disque. > > je ne sais pas trop.
Exemple : quand un nouveau fichier est écrit, le contrôleur du disque n'a aucun moyen de savoir si il sera souvent relu ou pas, et dans combien de temps. Donc il ne peut pas vraiment décider si il faut l'écrire dans la partie SSD ou dans la partie HD.
Un pilote au niveau OS par contre, peut faire une prédiction statistique suivant le type de fichier, sa taille, le répertoire dans lequel il se trouve, ou tout autre attribut du fichier.
sauf que quand tu écris un fichier, il est déjà en RAM, donc déjà potentiellement dans un cache bien plus rapide que le SSD. Après ça doit surement dépendre de l'OS et de la manière dont le process qui crée le fichier gère cette écriture, donc je n'irai pas spéculer.
Il faudrait que je vérifie au niveau du Momentus XT, mais il n'est pas idiot de supposer que par défaut il écrit sur le cache SSD, pour flusher ensuite en background sur le disque. De la sorte, l'utilisateur ne ressent pas de latence.
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
In article
<7856e803-10cd-49a2-90a2-73a76669ea43@ca1g2000vbb.googlegroups.com>,
pehache <pehache.7@gmail.com> wrote:
On Dec 5, 5:05 pm, patpro ~ patrick proniewski
<pat...@boleskine.patpro.net> wrote:
>
> > Gérer la répartition entre SSD et DD au niveau de l'OS, donc
> > en ayant connaissance du système de fichiers, permet priori d'avoir
> > des stratégies plus sophistiquées qu'au niveau du contrôleur du
> > disque.
>
> je ne sais pas trop.
Exemple : quand un nouveau fichier est écrit, le contrôleur du disque
n'a aucun moyen de savoir si il sera souvent relu ou pas, et dans
combien de temps. Donc il ne peut pas vraiment décider si il faut
l'écrire dans la partie SSD ou dans la partie HD.
Un pilote au niveau OS par contre, peut faire une prédiction
statistique suivant le type de fichier, sa taille, le répertoire dans
lequel il se trouve, ou tout autre attribut du fichier.
sauf que quand tu écris un fichier, il est déjà en RAM, donc déjà
potentiellement dans un cache bien plus rapide que le SSD. Après ça doit
surement dépendre de l'OS et de la manière dont le process qui crée le
fichier gère cette écriture, donc je n'irai pas spéculer.
Il faudrait que je vérifie au niveau du Momentus XT, mais il n'est pas
idiot de supposer que par défaut il écrit sur le cache SSD, pour flusher
ensuite en background sur le disque. De la sorte, l'utilisateur ne
ressent pas de latence.
patpro
--
A vendre : KVM IP 16 ports APC
http://patpro.net/blog/index.php/2008/01/12/133
On Dec 5, 5:05 pm, patpro ~ patrick proniewski wrote: > > > Gérer la répartition entre SSD et DD au niveau de l'OS, donc > > en ayant connaissance du système de fichiers, permet priori d'avoir > > des stratégies plus sophistiquées qu'au niveau du contrôleur du > > disque. > > je ne sais pas trop.
Exemple : quand un nouveau fichier est écrit, le contrôleur du disque n'a aucun moyen de savoir si il sera souvent relu ou pas, et dans combien de temps. Donc il ne peut pas vraiment décider si il faut l'écrire dans la partie SSD ou dans la partie HD.
Un pilote au niveau OS par contre, peut faire une prédiction statistique suivant le type de fichier, sa taille, le répertoire dans lequel il se trouve, ou tout autre attribut du fichier.
sauf que quand tu écris un fichier, il est déjà en RAM, donc déjà potentiellement dans un cache bien plus rapide que le SSD. Après ça doit surement dépendre de l'OS et de la manière dont le process qui crée le fichier gère cette écriture, donc je n'irai pas spéculer.
Il faudrait que je vérifie au niveau du Momentus XT, mais il n'est pas idiot de supposer que par défaut il écrit sur le cache SSD, pour flusher ensuite en background sur le disque. De la sorte, l'utilisateur ne ressent pas de latence.
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
xavier
patpro ~ patrick proniewski wrote:
Je suis contre le principe de tout déléguer aux couches hautes (ici une application tournant dans l'OS). Ça réduit fondamentalement la portabilité, ça pose des problèmes d'interaction et de compatibilité, etc.
Dans ce genre, tu te rappelles les premières versions de 4D qui tapaient directement sur le disque, sans passer par le filesystem ? Ca foirait à chaque MàJ du sytème.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
Je suis contre le principe de tout déléguer aux couches hautes (ici une
application tournant dans l'OS). Ça réduit fondamentalement la
portabilité, ça pose des problèmes d'interaction et de compatibilité,
etc.
Dans ce genre, tu te rappelles les premières versions de 4D qui tapaient
directement sur le disque, sans passer par le filesystem ? Ca foirait à
chaque MàJ du sytème.
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
(Jethro Tull)
Je suis contre le principe de tout déléguer aux couches hautes (ici une application tournant dans l'OS). Ça réduit fondamentalement la portabilité, ça pose des problèmes d'interaction et de compatibilité, etc.
Dans ce genre, tu te rappelles les premières versions de 4D qui tapaient directement sur le disque, sans passer par le filesystem ? Ca foirait à chaque MàJ du sytème.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
patpro ~ patrick proniewski
In article <1kbtdl1.16b7d44g3ibkaN%, (SbM) wrote:
> haaa... heu mais c'est pas le boulot du "WebProcess" ça ?
Je parle du dossier de cache entier, c'est-à-dire ~/Library/Caches
ha ok, carrément. Le mien fait actuellement 1 Go. Je pourrais le mettre en RAM, mais je n'ai pas envie de me prendre la tête à gérer un ramdisk. Cela dit, je l'ai fait, y'a longtemps, avec mon 7100 :).
> La mémoire utilisée par WebProcess grossit à mesure que tu te sers de > Safari, et le process quitte quand tu quittes Safari.
Je n'utilise pas Safari :)
Je n'ai pas trouvé d'alternative satisfaisante et j'aime bien l'intégration des techno apple dans leur soft (que ce soit Mail, Safari...). J'ai du mal à m'en défaire.
La taille de mon disque RAM étant volontairement limitée, je ne vois pas le problème.
ho je ne dis pas que c'est un problème, j'y trouverai certainement mon compte aussi, c'est jusque que j'ai la flemme.
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
In article <1kbtdl1.16b7d44g3ibkaN%sebastienmarty@yahoo.fr>,
sebastienmarty@yahoo.fr (SbM) wrote:
> haaa... heu mais c'est pas le boulot du "WebProcess" ça ?
Je parle du dossier de cache entier, c'est-à-dire ~/Library/Caches
ha ok, carrément. Le mien fait actuellement 1 Go. Je pourrais le mettre
en RAM, mais je n'ai pas envie de me prendre la tête à gérer un ramdisk.
Cela dit, je l'ai fait, y'a longtemps, avec mon 7100 :).
> La mémoire utilisée par WebProcess grossit à mesure que tu te sers de
> Safari, et le process quitte quand tu quittes Safari.
Je n'utilise pas Safari :)
Je n'ai pas trouvé d'alternative satisfaisante et j'aime bien
l'intégration des techno apple dans leur soft (que ce soit Mail,
Safari...). J'ai du mal à m'en défaire.
La taille de mon disque RAM étant volontairement limitée, je ne vois pas
le problème.
ho je ne dis pas que c'est un problème, j'y trouverai certainement mon
compte aussi, c'est jusque que j'ai la flemme.
patpro
--
A vendre : KVM IP 16 ports APC
http://patpro.net/blog/index.php/2008/01/12/133
> haaa... heu mais c'est pas le boulot du "WebProcess" ça ?
Je parle du dossier de cache entier, c'est-à-dire ~/Library/Caches
ha ok, carrément. Le mien fait actuellement 1 Go. Je pourrais le mettre en RAM, mais je n'ai pas envie de me prendre la tête à gérer un ramdisk. Cela dit, je l'ai fait, y'a longtemps, avec mon 7100 :).
> La mémoire utilisée par WebProcess grossit à mesure que tu te sers de > Safari, et le process quitte quand tu quittes Safari.
Je n'utilise pas Safari :)
Je n'ai pas trouvé d'alternative satisfaisante et j'aime bien l'intégration des techno apple dans leur soft (que ce soit Mail, Safari...). J'ai du mal à m'en défaire.
La taille de mon disque RAM étant volontairement limitée, je ne vois pas le problème.
ho je ne dis pas que c'est un problème, j'y trouverai certainement mon compte aussi, c'est jusque que j'ai la flemme.
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
sebastienmarty
patpro ~ patrick proniewski wrote:
In article <1kbtdl1.16b7d44g3ibkaN%, (SbM) wrote:
> > haaa... heu mais c'est pas le boulot du "WebProcess" ça ? > > Je parle du dossier de cache entier, c'est-à-dire ~/Library/Caches
ha ok, carrément. Le mien fait actuellement 1 Go. Je pourrais le mettre en RAM, mais je n'ai pas envie de me prendre la tête à gérer un ramdisk.
Bof, y a pas grand-chose à "gérer" : j'ai un script qui recrée le ramdisk au démarrage du Mac, et voilà. Et comme je ne l'éteins pratiquement jamais...
Je n'ai pas trouvé d'alternative satisfaisante et j'aime bien l'intégration des techno apple dans leur soft (que ce soit Mail, Safari...). J'ai du mal à m'en défaire.
Je n'ai peut-être pas de chance, mais Safari a /toujours/ plus ou moins merdouillé ici. Du coup je suis passé à Firefox puis aujourd'hui à Chrome.
> La taille de mon disque RAM étant volontairement limitée, je ne vois pas > le problème.
ho je ne dis pas que c'est un problème, j'y trouverai certainement mon compte aussi, c'est jusque que j'ai la flemme.
Ah ça, la flemme, dur de lutter contre :)
-- [SbM] <http://sebastienmarty.free.fr> - <http://tradintosh.free.fr> <http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr> "If the French were really intelligent, they'd speak English" (W. Sheed)
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
In article <1kbtdl1.16b7d44g3ibkaN%sebastienmarty@yahoo.fr>,
sebastienmarty@yahoo.fr (SbM) wrote:
> > haaa... heu mais c'est pas le boulot du "WebProcess" ça ?
>
> Je parle du dossier de cache entier, c'est-à-dire ~/Library/Caches
ha ok, carrément. Le mien fait actuellement 1 Go. Je pourrais le mettre
en RAM, mais je n'ai pas envie de me prendre la tête à gérer un ramdisk.
Bof, y a pas grand-chose à "gérer" : j'ai un script qui recrée le
ramdisk au démarrage du Mac, et voilà. Et comme je ne l'éteins
pratiquement jamais...
Je n'ai pas trouvé d'alternative satisfaisante et j'aime bien
l'intégration des techno apple dans leur soft (que ce soit Mail,
Safari...). J'ai du mal à m'en défaire.
Je n'ai peut-être pas de chance, mais Safari a /toujours/ plus ou moins
merdouillé ici. Du coup je suis passé à Firefox puis aujourd'hui à
Chrome.
> La taille de mon disque RAM étant volontairement limitée, je ne vois pas
> le problème.
ho je ne dis pas que c'est un problème, j'y trouverai certainement mon
compte aussi, c'est jusque que j'ai la flemme.
Ah ça, la flemme, dur de lutter contre :)
--
[SbM]
<http://sebastienmarty.free.fr> - <http://tradintosh.free.fr>
<http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr>
"If the French were really intelligent, they'd speak English" (W. Sheed)
> > haaa... heu mais c'est pas le boulot du "WebProcess" ça ? > > Je parle du dossier de cache entier, c'est-à-dire ~/Library/Caches
ha ok, carrément. Le mien fait actuellement 1 Go. Je pourrais le mettre en RAM, mais je n'ai pas envie de me prendre la tête à gérer un ramdisk.
Bof, y a pas grand-chose à "gérer" : j'ai un script qui recrée le ramdisk au démarrage du Mac, et voilà. Et comme je ne l'éteins pratiquement jamais...
Je n'ai pas trouvé d'alternative satisfaisante et j'aime bien l'intégration des techno apple dans leur soft (que ce soit Mail, Safari...). J'ai du mal à m'en défaire.
Je n'ai peut-être pas de chance, mais Safari a /toujours/ plus ou moins merdouillé ici. Du coup je suis passé à Firefox puis aujourd'hui à Chrome.
> La taille de mon disque RAM étant volontairement limitée, je ne vois pas > le problème.
ho je ne dis pas que c'est un problème, j'y trouverai certainement mon compte aussi, c'est jusque que j'ai la flemme.
Ah ça, la flemme, dur de lutter contre :)
-- [SbM] <http://sebastienmarty.free.fr> - <http://tradintosh.free.fr> <http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr> "If the French were really intelligent, they'd speak English" (W. Sheed)
patpro ~ patrick proniewski
In article <1kbth2a.5ektrw5t4nosN%, (Xavier) wrote:
patpro ~ patrick proniewski wrote:
> Je suis contre le principe de tout déléguer aux couches hautes (ici une > application tournant dans l'OS). Ça réduit fondamentalement la > portabilité, ça pose des problèmes d'interaction et de compatibilité, > etc.
Dans ce genre, tu te rappelles les premières versions de 4D qui tapaient directement sur le disque, sans passer par le filesystem ? Ca foirait à chaque MàJ du sytème.
j'ai jamais utilisé :) j'ai toujours été plus FileMaker que 4D. Et si je me fie à la rumeur (de l'époque), je me suis épargné des cheveux blancs.
Après, accéder à un device en RAW comme peut le faire Oracle, directement sans passer par l'OS ou le FS, c'est une méthode qui a fait ses preuves, mais qui reste cantonnée à un domaine ultra spécialisé. En tout cas, je ferai pas ça chez moi =)
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
In article <1kbth2a.5ektrw5t4nosN%xavier@groumpf.org>,
xavier@groumpf.org (Xavier) wrote:
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
> Je suis contre le principe de tout déléguer aux couches hautes (ici une
> application tournant dans l'OS). Ça réduit fondamentalement la
> portabilité, ça pose des problèmes d'interaction et de compatibilité,
> etc.
Dans ce genre, tu te rappelles les premières versions de 4D qui tapaient
directement sur le disque, sans passer par le filesystem ? Ca foirait à
chaque MàJ du sytème.
j'ai jamais utilisé :)
j'ai toujours été plus FileMaker que 4D. Et si je me fie à la rumeur (de
l'époque), je me suis épargné des cheveux blancs.
Après, accéder à un device en RAW comme peut le faire Oracle,
directement sans passer par l'OS ou le FS, c'est une méthode qui a fait
ses preuves, mais qui reste cantonnée à un domaine ultra spécialisé.
En tout cas, je ferai pas ça chez moi =)
patpro
--
A vendre : KVM IP 16 ports APC
http://patpro.net/blog/index.php/2008/01/12/133
In article <1kbth2a.5ektrw5t4nosN%, (Xavier) wrote:
patpro ~ patrick proniewski wrote:
> Je suis contre le principe de tout déléguer aux couches hautes (ici une > application tournant dans l'OS). Ça réduit fondamentalement la > portabilité, ça pose des problèmes d'interaction et de compatibilité, > etc.
Dans ce genre, tu te rappelles les premières versions de 4D qui tapaient directement sur le disque, sans passer par le filesystem ? Ca foirait à chaque MàJ du sytème.
j'ai jamais utilisé :) j'ai toujours été plus FileMaker que 4D. Et si je me fie à la rumeur (de l'époque), je me suis épargné des cheveux blancs.
Après, accéder à un device en RAW comme peut le faire Oracle, directement sans passer par l'OS ou le FS, c'est une méthode qui a fait ses preuves, mais qui reste cantonnée à un domaine ultra spécialisé. En tout cas, je ferai pas ça chez moi =)
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
patpro ~ patrick proniewski
In article <1kbtih1.j9zs221lk9k3vN%, (SbM) wrote:
patpro ~ patrick proniewski wrote:
> In article <1kbtdl1.16b7d44g3ibkaN%, > (SbM) wrote: > > > > haaa... heu mais c'est pas le boulot du "WebProcess" ça ? > > > > Je parle du dossier de cache entier, c'est-à-dire ~/Library/Caches > > ha ok, carrément. Le mien fait actuellement 1 Go. Je pourrais le mettre > en RAM, mais je n'ai pas envie de me prendre la tête à gérer un ramdisk.
Bof, y a pas grand-chose à "gérer" : j'ai un script qui recrée le ramdisk au démarrage du Mac, et voilà. Et comme je ne l'éteins pratiquement jamais...
je me doute bien. Mais il y a un truc qui me chiffonne en fait : je n'arrive pas savoir précisément ce qui est en cache et à quel endroit, à un instant T. L'OS met des tas de choses en cache et pas que sur le disque, bien au contraire. Notamment, si HFS+ fait bien son boulot il doit utiliser la RAM libre pour mettre en cache plein de chose, y compris des fichiers fraichement accédés. J'ai franchement l'impression que sur une courte période de temps, ton cache en RAM est redondant avec le cache d'HFS+ et d'autres mécanismes internes. Alors oui, si tu reviens 2h après sur une page web, le cache géré au bas niveau par HFS+ sera exempt des éléments nécessaires à ton navigateur, si bien qu'une nouvelle lecture des fichiers de cache du disque sera nécessaire. Là ton ramdisk est efficace.
J'adorerai avoir un soft qui me liste ce que j'ai dans les caches (d'HFS+, du disque dur, et d'ailleurs). Aussi, je n'ai pas trouvé de doc exhaustive sur la question chez Apple : tous les types de cache présentés hiérarchiquement, leur taille, leur durée de vie, etc.
'fin bref.
note périphérique, mais pas complètement décorrélée : Si y'a un développeur dans la salle, je suis intéressé par un soft en ligne de commande qui saurait convertir les chemins du type "/.vol/234881029/320682" en PATH compréhensible "~/Library/PreferencePanes".
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
In article <1kbtih1.j9zs221lk9k3vN%sebastienmarty@yahoo.fr>,
sebastienmarty@yahoo.fr (SbM) wrote:
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
> In article <1kbtdl1.16b7d44g3ibkaN%sebastienmarty@yahoo.fr>,
> sebastienmarty@yahoo.fr (SbM) wrote:
>
> > > haaa... heu mais c'est pas le boulot du "WebProcess" ça ?
> >
> > Je parle du dossier de cache entier, c'est-à-dire ~/Library/Caches
>
> ha ok, carrément. Le mien fait actuellement 1 Go. Je pourrais le mettre
> en RAM, mais je n'ai pas envie de me prendre la tête à gérer un ramdisk.
Bof, y a pas grand-chose à "gérer" : j'ai un script qui recrée le
ramdisk au démarrage du Mac, et voilà. Et comme je ne l'éteins
pratiquement jamais...
je me doute bien. Mais il y a un truc qui me chiffonne en fait : je
n'arrive pas savoir précisément ce qui est en cache et à quel endroit, à
un instant T.
L'OS met des tas de choses en cache et pas que sur le disque, bien au
contraire. Notamment, si HFS+ fait bien son boulot il doit utiliser la
RAM libre pour mettre en cache plein de chose, y compris des fichiers
fraichement accédés.
J'ai franchement l'impression que sur une courte période de temps, ton
cache en RAM est redondant avec le cache d'HFS+ et d'autres mécanismes
internes. Alors oui, si tu reviens 2h après sur une page web, le cache
géré au bas niveau par HFS+ sera exempt des éléments nécessaires à ton
navigateur, si bien qu'une nouvelle lecture des fichiers de cache du
disque sera nécessaire. Là ton ramdisk est efficace.
J'adorerai avoir un soft qui me liste ce que j'ai dans les caches
(d'HFS+, du disque dur, et d'ailleurs). Aussi, je n'ai pas trouvé de doc
exhaustive sur la question chez Apple : tous les types de cache
présentés hiérarchiquement, leur taille, leur durée de vie, etc.
'fin bref.
note périphérique, mais pas complètement décorrélée :
Si y'a un développeur dans la salle, je suis intéressé par un soft en
ligne de commande qui saurait convertir les chemins du type
"/.vol/234881029/320682" en PATH compréhensible
"~/Library/PreferencePanes".
patpro
--
A vendre : KVM IP 16 ports APC
http://patpro.net/blog/index.php/2008/01/12/133
> In article <1kbtdl1.16b7d44g3ibkaN%, > (SbM) wrote: > > > > haaa... heu mais c'est pas le boulot du "WebProcess" ça ? > > > > Je parle du dossier de cache entier, c'est-à-dire ~/Library/Caches > > ha ok, carrément. Le mien fait actuellement 1 Go. Je pourrais le mettre > en RAM, mais je n'ai pas envie de me prendre la tête à gérer un ramdisk.
Bof, y a pas grand-chose à "gérer" : j'ai un script qui recrée le ramdisk au démarrage du Mac, et voilà. Et comme je ne l'éteins pratiquement jamais...
je me doute bien. Mais il y a un truc qui me chiffonne en fait : je n'arrive pas savoir précisément ce qui est en cache et à quel endroit, à un instant T. L'OS met des tas de choses en cache et pas que sur le disque, bien au contraire. Notamment, si HFS+ fait bien son boulot il doit utiliser la RAM libre pour mettre en cache plein de chose, y compris des fichiers fraichement accédés. J'ai franchement l'impression que sur une courte période de temps, ton cache en RAM est redondant avec le cache d'HFS+ et d'autres mécanismes internes. Alors oui, si tu reviens 2h après sur une page web, le cache géré au bas niveau par HFS+ sera exempt des éléments nécessaires à ton navigateur, si bien qu'une nouvelle lecture des fichiers de cache du disque sera nécessaire. Là ton ramdisk est efficace.
J'adorerai avoir un soft qui me liste ce que j'ai dans les caches (d'HFS+, du disque dur, et d'ailleurs). Aussi, je n'ai pas trouvé de doc exhaustive sur la question chez Apple : tous les types de cache présentés hiérarchiquement, leur taille, leur durée de vie, etc.
'fin bref.
note périphérique, mais pas complètement décorrélée : Si y'a un développeur dans la salle, je suis intéressé par un soft en ligne de commande qui saurait convertir les chemins du type "/.vol/234881029/320682" en PATH compréhensible "~/Library/PreferencePanes".
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
gilles
Olivier Marti wrote:
Je fut confusionnant : je parle de ~/Library. Donc pas dans le système. Et les caches que j'ai vu passé sont ceux dans ~/Library aussi.
oui. je sais que j'ai commencé par dire "le système et les applis" mais j'ai bien précisé que la pratique, c'est : - installer le système (donc : système + applis + dossier utilisateur + dossiers invisibles /private etc.) - en 2, déporter les dossiers les moins utilisés (video, telechargements, documents, musique... selon l'usage)
on laisse au minimum le bureau (qui contient les fichiers en cours de travail) et le dossier ~/library sur le SSD.
C'est ce genre de phrase qui dessert ton propos : à quel moment ais-je dit que faire différemment de moi était idiot ou stupide ? Tu m'attribue une intolérance que je n'ai pas.
Cette discussion pourrait-être intéressante, mais pourquoi t'énerver à chaque fois, et verser dans la paranoïa ?
Je paraneuille pas :-) ma proposition a été qualifiée de stupide, mais pas par toi..
Au boulot, la plupart des salarié, éteint le chauffage et la lumière, et met le Mac (ou plus souvent le PC) dans le sac ... Eteint ou allumé, il faut que j'enquête !
ah pour le chauffage j'ai un programmateur :-) mais on est embettés par des scripts sur les navigateurs qui empêchent les machines de se couper automatiquement...
J'ai l'impression aussi que les applications qu'on rouvrent alors qu'on les a fermées récemment se rouvrent nettement plus vite. Effet de cache ?
Pas le cache, enfin pas que le cache. Les applis utilisent quasiment toutes des libraries partagées.
je ne suis pas développeur, mais, si je ne me trompe pas, quand une appli s'ouvre et charge la librarie pour afficher une fenetre de dialogue d'impression, la deuxième fois, la librairie est déjà chargé dans le système, ainsi que pour d'autres programmes.
A noter et j'enfonce des portes ouvertes, que autant l'ouverture d'une appli est une grosse et multiple opération de lectures, autant la fermeture, c'est... rien. Parce qu'une appli (ses fragments de code) n'a aucune raison d'avoir été modifiée pendant son utilisation (à part par des virus, sur PC !)
donc quand on ferme une appli, à part l'écriture des fichiers préférences, il ne se passe rien.
Mais j'ai relu un peu l'enfilade : c'est vrai que Patpro lui a utilisé ce terme. Vous êtes décidemment bien nerveux tous les deux !
bah, je vais me faire ma piqure et ça va aller mieux :-)
Pour l'instant, l'impression que ça me donnes et que selon la façon dont on utilise sa machine, la répartition entre SSD et plateaux n'est pas si évidente à décider. Et comme tu le soulignes, la taille de la ram est un autre élément important.
Mais cette discussion manque décidemment de chiffrages ... Est-ce que l'un de vous a eu l'occasion de tester les deux pratiques pour les comparer dans un seul contexte d'utilisation ?
Jusqu'à il y a un an ou deux, les SSD ne dépassaient que d'un facteur 1 ou 2 la vitesse séquentielle d'un disque dur classique en lecture (200 Mo/sec contre 100 Mo/sec), et étaient même parfois plus lents, en écriture (80 Mo/sec contre 100 pour un disque classique)..
Donc ça semblait pas intelligent des conseiller pour de l'écriture de gros fichiers (aperture ou iphoto, justement).
Alors qu'en accès séquentiel en lecture (cas typique du lancement d'un programme) le temps d'accès étant de 0,1ms c'est un progrès de facteur 100 par rapport au disque dur. Donc, ça semblait aussi plus logique de principalement utiliser le SSD pour l'ouverture des programmes, et du système.
Maintenant, avec les nouvelles générations, ce n'est plus le cas : en SATA-III ça carbure à 500 Mo/sec en lecture ou écriture, et en SATA-II ça sature à 250. Donc on peut maintenant conseiller les nouveaux SSD pour tout, sans restriction...
Ben, évidemment, moi je parle beaucoup de ressenti, pour avoir longuement testé (et mes clients aussi) les différences solutions.
et les retours que j'ai sont, effectivement, à part un utilisateur d'aperture, que le plus important c'est d'avoir le système et les applis : c'est ce qui transforme le mac en outil immédiatement disponible, et pour la majorité c'est ce qui compte.
Olivier Marti <olivier.marti@ensta.org> wrote:
Je fut confusionnant : je parle de ~/Library. Donc pas dans le système.
Et les caches que j'ai vu passé sont ceux dans ~/Library aussi.
oui.
je sais que j'ai commencé par dire "le système et les applis" mais j'ai
bien précisé que la pratique, c'est :
- installer le système (donc : système + applis + dossier utilisateur +
dossiers invisibles /private etc.)
- en 2, déporter les dossiers les moins utilisés (video,
telechargements, documents, musique... selon l'usage)
on laisse au minimum le bureau (qui contient les fichiers en cours de
travail) et le dossier ~/library sur le SSD.
C'est ce genre de phrase qui dessert ton propos : à quel moment ais-je
dit que faire différemment de moi était idiot ou stupide ? Tu m'attribue
une intolérance que je n'ai pas.
Cette discussion pourrait-être intéressante, mais pourquoi t'énerver à
chaque fois, et verser dans la paranoïa ?
Je paraneuille pas :-) ma proposition a été qualifiée de stupide, mais
pas par toi..
Au boulot, la plupart des salarié, éteint le chauffage et la lumière, et
met le Mac (ou plus souvent le PC) dans le sac ... Eteint ou allumé, il
faut que j'enquête !
ah pour le chauffage j'ai un programmateur :-)
mais on est embettés par des scripts sur les navigateurs qui empêchent
les machines de se couper automatiquement...
J'ai l'impression aussi que les applications qu'on rouvrent alors qu'on
les a fermées récemment se rouvrent nettement plus vite. Effet de cache
?
Pas le cache, enfin pas que le cache.
Les applis utilisent quasiment toutes des libraries partagées.
je ne suis pas développeur, mais, si je ne me trompe pas, quand une
appli s'ouvre et charge la librarie pour afficher une fenetre de
dialogue d'impression, la deuxième fois, la librairie est déjà chargé
dans le système, ainsi que pour d'autres programmes.
A noter et j'enfonce des portes ouvertes, que autant l'ouverture d'une
appli est une grosse et multiple opération de lectures, autant la
fermeture, c'est... rien.
Parce qu'une appli (ses fragments de code) n'a aucune raison d'avoir été
modifiée pendant son utilisation (à part par des virus, sur PC !)
donc quand on ferme une appli, à part l'écriture des fichiers
préférences, il ne se passe rien.
Mais j'ai relu un peu l'enfilade : c'est vrai que Patpro lui a utilisé
ce terme. Vous êtes décidemment bien nerveux tous les deux !
bah, je vais me faire ma piqure et ça va aller mieux :-)
Pour l'instant, l'impression que ça me donnes et que selon la façon dont
on utilise sa machine, la répartition entre SSD et plateaux n'est pas si
évidente à décider. Et comme tu le soulignes, la taille de la ram est un
autre élément important.
Mais cette discussion manque décidemment de chiffrages ... Est-ce que
l'un de vous a eu l'occasion de tester les deux pratiques pour les
comparer dans un seul contexte d'utilisation ?
Jusqu'à il y a un an ou deux, les SSD ne dépassaient que d'un facteur 1
ou 2 la vitesse séquentielle d'un disque dur classique en lecture (200
Mo/sec contre 100 Mo/sec), et étaient même parfois plus lents, en
écriture (80 Mo/sec contre 100 pour un disque classique)..
Donc ça semblait pas intelligent des conseiller pour de l'écriture de
gros fichiers (aperture ou iphoto, justement).
Alors qu'en accès séquentiel en lecture (cas typique du lancement d'un
programme) le temps d'accès étant de 0,1ms c'est un progrès de facteur
100 par rapport au disque dur.
Donc, ça semblait aussi plus logique de principalement utiliser le SSD
pour l'ouverture des programmes, et du système.
Maintenant, avec les nouvelles générations, ce n'est plus le cas : en
SATA-III ça carbure à 500 Mo/sec en lecture ou écriture, et en SATA-II
ça sature à 250.
Donc on peut maintenant conseiller les nouveaux SSD pour tout, sans
restriction...
Ben, évidemment, moi je parle beaucoup de ressenti, pour avoir
longuement testé (et mes clients aussi) les différences solutions.
et les retours que j'ai sont, effectivement, à part un utilisateur
d'aperture, que le plus important c'est d'avoir le système et les applis
: c'est ce qui transforme le mac en outil immédiatement disponible, et
pour la majorité c'est ce qui compte.
Je fut confusionnant : je parle de ~/Library. Donc pas dans le système. Et les caches que j'ai vu passé sont ceux dans ~/Library aussi.
oui. je sais que j'ai commencé par dire "le système et les applis" mais j'ai bien précisé que la pratique, c'est : - installer le système (donc : système + applis + dossier utilisateur + dossiers invisibles /private etc.) - en 2, déporter les dossiers les moins utilisés (video, telechargements, documents, musique... selon l'usage)
on laisse au minimum le bureau (qui contient les fichiers en cours de travail) et le dossier ~/library sur le SSD.
C'est ce genre de phrase qui dessert ton propos : à quel moment ais-je dit que faire différemment de moi était idiot ou stupide ? Tu m'attribue une intolérance que je n'ai pas.
Cette discussion pourrait-être intéressante, mais pourquoi t'énerver à chaque fois, et verser dans la paranoïa ?
Je paraneuille pas :-) ma proposition a été qualifiée de stupide, mais pas par toi..
Au boulot, la plupart des salarié, éteint le chauffage et la lumière, et met le Mac (ou plus souvent le PC) dans le sac ... Eteint ou allumé, il faut que j'enquête !
ah pour le chauffage j'ai un programmateur :-) mais on est embettés par des scripts sur les navigateurs qui empêchent les machines de se couper automatiquement...
J'ai l'impression aussi que les applications qu'on rouvrent alors qu'on les a fermées récemment se rouvrent nettement plus vite. Effet de cache ?
Pas le cache, enfin pas que le cache. Les applis utilisent quasiment toutes des libraries partagées.
je ne suis pas développeur, mais, si je ne me trompe pas, quand une appli s'ouvre et charge la librarie pour afficher une fenetre de dialogue d'impression, la deuxième fois, la librairie est déjà chargé dans le système, ainsi que pour d'autres programmes.
A noter et j'enfonce des portes ouvertes, que autant l'ouverture d'une appli est une grosse et multiple opération de lectures, autant la fermeture, c'est... rien. Parce qu'une appli (ses fragments de code) n'a aucune raison d'avoir été modifiée pendant son utilisation (à part par des virus, sur PC !)
donc quand on ferme une appli, à part l'écriture des fichiers préférences, il ne se passe rien.
Mais j'ai relu un peu l'enfilade : c'est vrai que Patpro lui a utilisé ce terme. Vous êtes décidemment bien nerveux tous les deux !
bah, je vais me faire ma piqure et ça va aller mieux :-)
Pour l'instant, l'impression que ça me donnes et que selon la façon dont on utilise sa machine, la répartition entre SSD et plateaux n'est pas si évidente à décider. Et comme tu le soulignes, la taille de la ram est un autre élément important.
Mais cette discussion manque décidemment de chiffrages ... Est-ce que l'un de vous a eu l'occasion de tester les deux pratiques pour les comparer dans un seul contexte d'utilisation ?
Jusqu'à il y a un an ou deux, les SSD ne dépassaient que d'un facteur 1 ou 2 la vitesse séquentielle d'un disque dur classique en lecture (200 Mo/sec contre 100 Mo/sec), et étaient même parfois plus lents, en écriture (80 Mo/sec contre 100 pour un disque classique)..
Donc ça semblait pas intelligent des conseiller pour de l'écriture de gros fichiers (aperture ou iphoto, justement).
Alors qu'en accès séquentiel en lecture (cas typique du lancement d'un programme) le temps d'accès étant de 0,1ms c'est un progrès de facteur 100 par rapport au disque dur. Donc, ça semblait aussi plus logique de principalement utiliser le SSD pour l'ouverture des programmes, et du système.
Maintenant, avec les nouvelles générations, ce n'est plus le cas : en SATA-III ça carbure à 500 Mo/sec en lecture ou écriture, et en SATA-II ça sature à 250. Donc on peut maintenant conseiller les nouveaux SSD pour tout, sans restriction...
Ben, évidemment, moi je parle beaucoup de ressenti, pour avoir longuement testé (et mes clients aussi) les différences solutions.
et les retours que j'ai sont, effectivement, à part un utilisateur d'aperture, que le plus important c'est d'avoir le système et les applis : c'est ce qui transforme le mac en outil immédiatement disponible, et pour la majorité c'est ce qui compte.
gilles
Philippe Manet wrote:
des retours sur le Kingston E-series qui sont SLC à un prix acceptable ?
les Kingston E sont des intel X25-E rebadgés..
les X25-E sont des excellents disques, mais à un prix d'or ! tu en as trouvé à un prix correct ?
en SLC j'ai eu acheté des solidata, pas eu de soucis, mais la boite n'est pas fiable (2 mois de livraison, et je n'ose pas imaginer le SAV)
Philippe Manet <yapu@invivo.edu> wrote:
des retours sur le Kingston E-series qui sont SLC à un prix acceptable ?
les Kingston E sont des intel X25-E rebadgés..
les X25-E sont des excellents disques, mais à un prix d'or ! tu en as
trouvé à un prix correct ?
en SLC j'ai eu acheté des solidata, pas eu de soucis, mais la boite
n'est pas fiable (2 mois de livraison, et je n'ose pas imaginer le SAV)
