Averelll avait écrit le 18.01.2010 :
> Michel Doucet a écrit :
>> Bonjour/soir, le Mon, 18 Jan 2010 18:38:26 +0100, *Averelll* a caressé son
>> clavier pour nous dire dans le message suivant:
>>
>>>> Je préfère une Dacia qui marche qu'une Porsche bling-bling qui doit
>>>> aller en révision tous les 15 jours ...
>>>>
>>> tellement imbu de votre petite personne que vous passez votre temps à
>>> vouloir imposer votre choix en proférant mensonges et contrevérités.
>>
>> Préférer ne veut pas dire imposer.
>
> C'est pourquoi depuis des années vous ne cessez de troller les groupes
> windows avec mépris et suffisance.
>
> > Imposer c'est ce que MS$ fait avec ces
>> softs troués installés sans le consentement des consommateurs au mépris des
>> lois européennes.
>>
> et c'est reparti avec vos obsessions. Vous êtes un grand malade.
Linux n'est pas le préféré, et il n'arrive pas à s'imposer
Tirer en leçon, Monsieur le Trôleur Obsessionnel
L'étrange chimie qui agite votre cerveau créée des effets propres à
votre personne, vous faisant croire à l'universalité de vos propos, qui
sont, je dois le dire, juste délirants
Avec la lumière du jour, il est préférable d'ouvrir grand les fenêtres
et de vous laisser pénétrer par la lumière salvatrice et réparatrice,
qui dissipera les ombres qui se cachent derrière vous
Le pingouin qui hante vos rêves doit vous quitter au chant du coq,
quitte à le retrouver dès la nuit tombée
Ces quelques heures de répits seront indiscutablement profitables à
tous les deux, et ils vous remercieront chaleureusement
--
P4nd1-P4nd4 vous salue, et annonce que le petit ourson possède
désormais son blog
p4nd1-p4nd4.over-blog.com
Le Wed, 20 Jan 2010 06:57:03 +0100 Kojak a écrit :
Le Wed, 20 Jan 2010 06:29:44 +0100, Stephan Peccini a écrit :
> Le 20/01/2010 00:47, P4nd1-P4nd4 a écrit : > > SOus Linux, hohohohoh > > OK, tu ne connais pas Linux.
Il n'y a pas que Linux qu'il ne connaît pas !
Hormis, balancer des «hoho», «hihi», «haha», des liens déb iles ou des expressions toutes faites qu'il a lu à droite et à gauche (comme récemment avec un «chic des chiffres» ou bien «chic un argument »), il ne connaît strictement rien.
C'est peut-être un robot ?
Le Wed, 20 Jan 2010 06:57:03 +0100
Kojak <nntpspy@janville.Borg.invalid> a écrit :
Le Wed, 20 Jan 2010 06:29:44 +0100,
Stephan Peccini <stephan@photonature.fr> a écrit :
> Le 20/01/2010 00:47, P4nd1-P4nd4 a écrit :
> > SOus Linux, hohohohoh
>
> OK, tu ne connais pas Linux.
Il n'y a pas que Linux qu'il ne connaît pas !
Hormis, balancer des «hoho», «hihi», «haha», des liens déb iles ou des
expressions toutes faites qu'il a lu à droite et à gauche (comme
récemment avec un «chic des chiffres» ou bien «chic un argument »), il
ne connaît strictement rien.
Le Wed, 20 Jan 2010 06:57:03 +0100 Kojak a écrit :
Le Wed, 20 Jan 2010 06:29:44 +0100, Stephan Peccini a écrit :
> Le 20/01/2010 00:47, P4nd1-P4nd4 a écrit : > > SOus Linux, hohohohoh > > OK, tu ne connais pas Linux.
Il n'y a pas que Linux qu'il ne connaît pas !
Hormis, balancer des «hoho», «hihi», «haha», des liens déb iles ou des expressions toutes faites qu'il a lu à droite et à gauche (comme récemment avec un «chic des chiffres» ou bien «chic un argument »), il ne connaît strictement rien.
C'est peut-être un robot ?
debug this fifo
P4nd1-P4nd4 wrote:
Cette commande omet de citer la partition SWAP, partition inutile qui ne fait que perdre de l'espace disque en utilisant un format fantasque
<foo> omg, j'ai un fichier PAGEFILE.SYS de 6100 Mo dans C: <bar> ça sert à rien, efface !
P4nd1-P4nd4 wrote:
Cette commande omet de citer la partition SWAP, partition inutile qui ne
fait que perdre de l'espace disque en utilisant un format fantasque
<foo> omg, j'ai un fichier PAGEFILE.SYS de 6100 Mo dans C:
<bar> ça sert à rien, efface !
Utilise un seul dique, mets le second dans un boitier USB et utilise le pour faire des sauvegardes full et incrémentales
Ca c'est beaucoup plus inteligent, et ca montre une certaine compréhension de l'exploitation qui te fait défaut
OK, tu ne sais pas ce que c'est une production informatique avec ses contraintes de continuité de service.
Toi non plus car tu ne peux choisir entre sauvegardes et continuité de services...
-- P4nd1-P4nd4 vous salue, et annonce que le petit ourson possède désormais son blog p4nd1-p4nd4.over-blog.com
Stephan Peccini
Le 20/01/2010 09:58, P4nd1-P4nd4 a écrit :
Toi non plus car tu ne peux choisir entre sauvegardes et continuité de services...
Continue tu es génial ... enfin, génial dans le n'importe quoi. Non, tu ne sais pas ce que c'est qu'une production informatique.
-- Stéphan Peccini Les photos : <URL:http://photonature.fr> Les Pyrénées : <URL:http://photonature.fr/pyrenees> Le blog : <URL:http://pyrenees.peccini.fr>
Le 20/01/2010 09:58, P4nd1-P4nd4 a écrit :
Toi non plus car tu ne peux choisir entre sauvegardes et continuité de
services...
Continue tu es génial ... enfin, génial dans le n'importe quoi. Non, tu
ne sais pas ce que c'est qu'une production informatique.
--
Stéphan Peccini
Les photos : <URL:http://photonature.fr>
Les Pyrénées : <URL:http://photonature.fr/pyrenees>
Le blog : <URL:http://pyrenees.peccini.fr>
Toi non plus car tu ne peux choisir entre sauvegardes et continuité de services...
Continue tu es génial ... enfin, génial dans le n'importe quoi. Non, tu ne sais pas ce que c'est qu'une production informatique.
-- Stéphan Peccini Les photos : <URL:http://photonature.fr> Les Pyrénées : <URL:http://photonature.fr/pyrenees> Le blog : <URL:http://pyrenees.peccini.fr>
Stephan Peccini
Le 20/01/2010 09:56, P4nd1-P4nd4 a écrit :
Heuu, les backuops sous Windows utilisent des snapshots...
Tu veux bien donner un lien expliquant comment cela fonctionne.
-- Stéphan Peccini Les photos : <URL:http://photonature.fr> Les Pyrénées : <URL:http://photonature.fr/pyrenees> Le blog : <URL:http://pyrenees.peccini.fr>
Le 20/01/2010 09:56, P4nd1-P4nd4 a écrit :
Heuu, les backuops sous Windows utilisent des snapshots...
Tu veux bien donner un lien expliquant comment cela fonctionne.
--
Stéphan Peccini
Les photos : <URL:http://photonature.fr>
Les Pyrénées : <URL:http://photonature.fr/pyrenees>
Le blog : <URL:http://pyrenees.peccini.fr>
Heuu, les backuops sous Windows utilisent des snapshots...
Tu veux bien donner un lien expliquant comment cela fonctionne.
-- Stéphan Peccini Les photos : <URL:http://photonature.fr> Les Pyrénées : <URL:http://photonature.fr/pyrenees> Le blog : <URL:http://pyrenees.peccini.fr>
talon
NiKo wrote:
Par contre, fragmenter sur des pistes différentes (Et non alignées), je doute fort que ce soit plus productif, car dans les technos mécaniques qu'on utilise aujourd'hui, c'est le déplacement des têtes qui est le plus couteux en temps.
Je serais curieux que tu développes ton point de vue ...
Fragmenter c'est en théorie toujours couteux en temps, MAIS. Dans les systèmes Unix, il y a plusieurs programmes qui tournent en même temps, chacun accédant à plusieurs fichiers. Potentiellement à tout instant plusieurs dizaines ou centaines de fichiers sont ouverts en accés. Ce qui relativise énormément l'intérêt du fait que UN fichier est ou non fragmenté. Les systèmes Unix combattent aussi l'effet de la fragmentation en cachant agressivement les fichiers en accés, y compris en faisant de la lecture en avant pour profiter au maximum des accés consécutifs, et finalement les accès effectifs au disque sont groupés et ordonnés selon l'algorithme de l'ascenseur. Au total, bien que sur la lecture d'un fichier donné, le système est moins rapide qu'un système FAT parfaitement défragmenté (qui a évidemment les performances optimales) il est globalement bien plus performant pour l'ensemble des programmes concurrents qu'un système FAT qui commence à se fragmenter. Enfin, comme la fragmentation est gérée raisonnablement sur la durée de vie du système de fichiers elle ne prend pas les proportions catastrophiques obtenues par FAT qui essaye de loger des fichiers non fragmentés le plus possible jusqu'au point où il ne reste plus que des trous inappropriés répartis uniformément ce qui oblige ensuite à fragmenter maximalement les fichiers.
--
Michel TALON
NiKo <NiKo@nomail.svp> wrote:
Par contre, fragmenter sur des pistes différentes (Et non alignées), je
doute fort que ce soit plus productif, car dans les technos mécaniques
qu'on utilise aujourd'hui, c'est le déplacement des têtes qui est le
plus couteux en temps.
Je serais curieux que tu développes ton point de vue ...
Fragmenter c'est en théorie toujours couteux en temps, MAIS. Dans les
systèmes Unix, il y a plusieurs programmes qui tournent en même temps,
chacun accédant à plusieurs fichiers. Potentiellement à tout instant
plusieurs dizaines ou centaines de fichiers sont ouverts en accés. Ce
qui relativise énormément l'intérêt du fait que UN fichier est ou non
fragmenté. Les systèmes Unix combattent aussi l'effet de la
fragmentation en cachant agressivement les fichiers en accés, y compris
en faisant de la lecture en avant pour profiter au maximum des accés
consécutifs, et finalement les accès effectifs au disque sont groupés et
ordonnés selon l'algorithme de l'ascenseur. Au total, bien que sur la
lecture d'un fichier donné, le système est moins rapide qu'un système
FAT parfaitement défragmenté (qui a évidemment les performances
optimales) il est globalement bien plus performant pour l'ensemble des
programmes concurrents qu'un système FAT qui commence à se fragmenter.
Enfin, comme la fragmentation est gérée raisonnablement sur la durée de
vie du système de fichiers elle ne prend pas les proportions
catastrophiques obtenues par FAT qui essaye de loger des fichiers non
fragmentés le plus possible jusqu'au point où il ne reste plus que des
trous inappropriés répartis uniformément ce qui oblige ensuite à
fragmenter maximalement les fichiers.
Par contre, fragmenter sur des pistes différentes (Et non alignées), je doute fort que ce soit plus productif, car dans les technos mécaniques qu'on utilise aujourd'hui, c'est le déplacement des têtes qui est le plus couteux en temps.
Je serais curieux que tu développes ton point de vue ...
Fragmenter c'est en théorie toujours couteux en temps, MAIS. Dans les systèmes Unix, il y a plusieurs programmes qui tournent en même temps, chacun accédant à plusieurs fichiers. Potentiellement à tout instant plusieurs dizaines ou centaines de fichiers sont ouverts en accés. Ce qui relativise énormément l'intérêt du fait que UN fichier est ou non fragmenté. Les systèmes Unix combattent aussi l'effet de la fragmentation en cachant agressivement les fichiers en accés, y compris en faisant de la lecture en avant pour profiter au maximum des accés consécutifs, et finalement les accès effectifs au disque sont groupés et ordonnés selon l'algorithme de l'ascenseur. Au total, bien que sur la lecture d'un fichier donné, le système est moins rapide qu'un système FAT parfaitement défragmenté (qui a évidemment les performances optimales) il est globalement bien plus performant pour l'ensemble des programmes concurrents qu'un système FAT qui commence à se fragmenter. Enfin, comme la fragmentation est gérée raisonnablement sur la durée de vie du système de fichiers elle ne prend pas les proportions catastrophiques obtenues par FAT qui essaye de loger des fichiers non fragmentés le plus possible jusqu'au point où il ne reste plus que des trous inappropriés répartis uniformément ce qui oblige ensuite à fragmenter maximalement les fichiers.
--
Michel TALON
JKB
Le 20-01-2010, ? propos de Re: Lettre à Monsieur Doucet, Stephan Peccini ?crivait dans fr.comp.os.linux.debats :
Le 20/01/2010 09:56, P4nd1-P4nd4 a écrit :
Heuu, les backuops sous Windows utilisent des snapshots...
Tu veux bien donner un lien expliquant comment cela fonctionne.
Il te l'a dit. Il prend une photo, c'est instantané.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 20-01-2010, ? propos de
Re: Lettre à Monsieur Doucet,
Stephan Peccini ?crivait dans fr.comp.os.linux.debats :
Le 20/01/2010 09:56, P4nd1-P4nd4 a écrit :
Heuu, les backuops sous Windows utilisent des snapshots...
Tu veux bien donner un lien expliquant comment cela fonctionne.
Il te l'a dit. Il prend une photo, c'est instantané.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 20-01-2010, ? propos de Re: Lettre à Monsieur Doucet, Stephan Peccini ?crivait dans fr.comp.os.linux.debats :
Le 20/01/2010 09:56, P4nd1-P4nd4 a écrit :
Heuu, les backuops sous Windows utilisent des snapshots...
Tu veux bien donner un lien expliquant comment cela fonctionne.
Il te l'a dit. Il prend une photo, c'est instantané.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Yliur
Le Wed, 20 Jan 2010 09:12:42 +0000 (UTC) (Michel Talon) a écrit :
NiKo wrote: > > Par contre, fragmenter sur des pistes différentes (Et non > alignées), je doute fort que ce soit plus productif, car dans les > technos mécaniques qu'on utilise aujourd'hui, c'est le déplacement > des têtes qui est le plus couteux en temps. > > Je serais curieux que tu développes ton point de vue ...
Fragmenter c'est en théorie toujours couteux en temps, MAIS. Dans les systèmes Unix, il y a plusieurs programmes qui tournent en même temps, chacun accédant à plusieurs fichiers. Potentiellement à tout instant plusieurs dizaines ou centaines de fichiers sont ouverts en accés. Ce qui relativise énormément l'intérêt du fait que UN fichier est ou non fragmenté. Les systèmes Unix combattent aussi l'effet de la fragmentation en cachant agressivement les fichiers en accés, y compris en faisant de la lecture en avant pour profiter au maximum des accés consécutifs, et finalement les accès effectifs au disque sont groupés et ordonnés selon l'algorithme de l'ascenseur. Au total, bien que sur la lecture d'un fichier donné, le système est moins rapide qu'un système FAT parfaitement défragmenté (qui a évidemme nt les performances optimales) il est globalement bien plus performant pour l'ensemble des programmes concurrents qu'un système FAT qui commence à se fragmenter. Enfin, comme la fragmentation est gérée raisonnablement sur la durée de vie du système de fichiers elle ne prend pas les proportions catastrophiques obtenues par FAT qui essaye de loger des fichiers non fragmentés le plus possible jusqu'au point où il ne reste plus que des trous inappropriés répartis uniformém ent ce qui oblige ensuite à fragmenter maximalement les fichiers.
Hum... Quand tu parles de "système FAT", tu veux dire "la gestion de la FAT par Windows", c'est ça ? J'imagine qu'on peut gérer de différentes manières un système en FAT (l'emplacement des fichiers notamment).
Es-tu sûr que Windows "essaye de loger des fichiers non fragmentés le plus possible" ? Il me semble que quand tu as un disque pas tellement plein il est rapidement fragmenté, alors qu'il devrait rester de la place pour un fichier d'un peu n'importe quelle taille. Et il me semble que dans Defrag tu te retrouves vite avec des bouts un peu partout, même peu de temps après une défragmentation et avec un disque pas trop rempli.
Le Wed, 20 Jan 2010 09:12:42 +0000 (UTC)
talon@lpthe.jussieu.fr (Michel Talon) a écrit :
NiKo <NiKo@nomail.svp> wrote:
>
> Par contre, fragmenter sur des pistes différentes (Et non
> alignées), je doute fort que ce soit plus productif, car dans les
> technos mécaniques qu'on utilise aujourd'hui, c'est le déplacement
> des têtes qui est le plus couteux en temps.
>
> Je serais curieux que tu développes ton point de vue ...
Fragmenter c'est en théorie toujours couteux en temps, MAIS. Dans les
systèmes Unix, il y a plusieurs programmes qui tournent en même temps,
chacun accédant à plusieurs fichiers. Potentiellement à tout instant
plusieurs dizaines ou centaines de fichiers sont ouverts en accés. Ce
qui relativise énormément l'intérêt du fait que UN fichier est ou non
fragmenté. Les systèmes Unix combattent aussi l'effet de la
fragmentation en cachant agressivement les fichiers en accés, y
compris en faisant de la lecture en avant pour profiter au maximum
des accés consécutifs, et finalement les accès effectifs au disque
sont groupés et ordonnés selon l'algorithme de l'ascenseur. Au total,
bien que sur la lecture d'un fichier donné, le système est moins
rapide qu'un système FAT parfaitement défragmenté (qui a évidemme nt
les performances optimales) il est globalement bien plus performant
pour l'ensemble des programmes concurrents qu'un système FAT qui
commence à se fragmenter. Enfin, comme la fragmentation est gérée
raisonnablement sur la durée de vie du système de fichiers elle ne
prend pas les proportions catastrophiques obtenues par FAT qui essaye
de loger des fichiers non fragmentés le plus possible jusqu'au point
où il ne reste plus que des trous inappropriés répartis uniformém ent
ce qui oblige ensuite à fragmenter maximalement les fichiers.
Hum... Quand tu parles de "système FAT", tu veux dire "la gestion de
la FAT par Windows", c'est ça ? J'imagine qu'on peut gérer de
différentes manières un système en FAT (l'emplacement des fichiers
notamment).
Es-tu sûr que Windows "essaye de loger des fichiers non fragmentés le
plus possible" ? Il me semble que quand tu as un disque pas tellement
plein il est rapidement fragmenté, alors qu'il devrait rester de la
place pour un fichier d'un peu n'importe quelle taille. Et il me
semble que dans Defrag tu te retrouves vite avec des bouts un peu
partout, même peu de temps après une défragmentation et avec un
disque pas trop rempli.
Le Wed, 20 Jan 2010 09:12:42 +0000 (UTC) (Michel Talon) a écrit :
NiKo wrote: > > Par contre, fragmenter sur des pistes différentes (Et non > alignées), je doute fort que ce soit plus productif, car dans les > technos mécaniques qu'on utilise aujourd'hui, c'est le déplacement > des têtes qui est le plus couteux en temps. > > Je serais curieux que tu développes ton point de vue ...
Fragmenter c'est en théorie toujours couteux en temps, MAIS. Dans les systèmes Unix, il y a plusieurs programmes qui tournent en même temps, chacun accédant à plusieurs fichiers. Potentiellement à tout instant plusieurs dizaines ou centaines de fichiers sont ouverts en accés. Ce qui relativise énormément l'intérêt du fait que UN fichier est ou non fragmenté. Les systèmes Unix combattent aussi l'effet de la fragmentation en cachant agressivement les fichiers en accés, y compris en faisant de la lecture en avant pour profiter au maximum des accés consécutifs, et finalement les accès effectifs au disque sont groupés et ordonnés selon l'algorithme de l'ascenseur. Au total, bien que sur la lecture d'un fichier donné, le système est moins rapide qu'un système FAT parfaitement défragmenté (qui a évidemme nt les performances optimales) il est globalement bien plus performant pour l'ensemble des programmes concurrents qu'un système FAT qui commence à se fragmenter. Enfin, comme la fragmentation est gérée raisonnablement sur la durée de vie du système de fichiers elle ne prend pas les proportions catastrophiques obtenues par FAT qui essaye de loger des fichiers non fragmentés le plus possible jusqu'au point où il ne reste plus que des trous inappropriés répartis uniformém ent ce qui oblige ensuite à fragmenter maximalement les fichiers.
Hum... Quand tu parles de "système FAT", tu veux dire "la gestion de la FAT par Windows", c'est ça ? J'imagine qu'on peut gérer de différentes manières un système en FAT (l'emplacement des fichiers notamment).
Es-tu sûr que Windows "essaye de loger des fichiers non fragmentés le plus possible" ? Il me semble que quand tu as un disque pas tellement plein il est rapidement fragmenté, alors qu'il devrait rester de la place pour un fichier d'un peu n'importe quelle taille. Et il me semble que dans Defrag tu te retrouves vite avec des bouts un peu partout, même peu de temps après une défragmentation et avec un disque pas trop rempli.
