Bonjour,
Le principe de la compression (qui d'ailleurs peut se faire sur une
disquette), est que les valeurs sont recodées en tenant moins de
place, le principal effet est un "ralentissement", dans la mesure ou
le fichier doit être décodé puis recodé lors de son utilisation,
le second problème est qu'éventuellement le fichier n'est pas lisible
par tous les logiciels...
Sinon, il ne devrait pas y avoir de perte
de données, mais ce n'est à mon sens pas une exploitation
rationnelle, c'est juste une possibilité d'économiser l'achat de
disques durs,
Bonjour,
Le principe de la compression (qui d'ailleurs peut se faire sur une
disquette), est que les valeurs sont recodées en tenant moins de
place, le principal effet est un "ralentissement", dans la mesure ou
le fichier doit être décodé puis recodé lors de son utilisation,
le second problème est qu'éventuellement le fichier n'est pas lisible
par tous les logiciels...
Sinon, il ne devrait pas y avoir de perte
de données, mais ce n'est à mon sens pas une exploitation
rationnelle, c'est juste une possibilité d'économiser l'achat de
disques durs,
Bonjour,
Le principe de la compression (qui d'ailleurs peut se faire sur une
disquette), est que les valeurs sont recodées en tenant moins de
place, le principal effet est un "ralentissement", dans la mesure ou
le fichier doit être décodé puis recodé lors de son utilisation,
le second problème est qu'éventuellement le fichier n'est pas lisible
par tous les logiciels...
Sinon, il ne devrait pas y avoir de perte
de données, mais ce n'est à mon sens pas une exploitation
rationnelle, c'est juste une possibilité d'économiser l'achat de
disques durs,
Dans le message news: ,
le_troll s'est ainsi exprimé:Bonjour,
Le principe de la compression (qui d'ailleurs peut se faire sur une
disquette), est que les valeurs sont recodées en tenant moins de
place, le principal effet est un "ralentissement", dans la mesure ou
le fichier doit être décodé puis recodé lors de son utilisation,
NON, il n'y a pas forcément de ralentissement.
Il peut même y avoir ACCÉLÉRATION !
Tout va dépendre du type de processeur et du type de DD.
En effet, si les opérations de compression/décompression consomment du
temps
CPU, en contrepartie, comme un fichier compressé occupe (généralement)
beaucoup moins d'espace sur le DD, les temps de transferts (lecture et
écriture) sont considérablement réduits.
Or ces temps d'accès disques se chiffrent en millisecondes, alors que les
temps CPU s'expriment plutôt en nanosecondes.
Donc la compression va généralement faire gagner du temps, contrairement à
la "croyance populaire" !
(les seuls cas où ce n'est pas vrai concerne les fichiers pour lesquels la
compression n'apporte rien, p.ex. les fichiers JPEG, ZIP, CAB,... , qui
sont
déjà compressés au départ)le second problème est qu'éventuellement le fichier n'est pas lisible
par tous les logiciels...
NON, car c'est totalement TRANSPARENT pour les logiciels.
Quand un logiciel veut accéder à un fichier, le système de fichier
intervient AVANT, en effectuant compression/décompression préalable (idem
pour le chiffrement/déchiffrement dans le cas de EFS).
Il ne pourrait y avoir pb :
- qu'avec des utilitaires de bas niveau, qui vont lire
physiquement un disque secteur par secteur p.ex..
- dans le cas d'un multiboot, si un OS essaie d'accéder
aux fichiers compressés situés sur une partition
commune. (je pense essentiellement à Linux, qui sait
lire des NTFS, mais qui peut avoir des pb avec les
fichiers compressés)Sinon, il ne devrait pas y avoir de perte
de données, mais ce n'est à mon sens pas une exploitation
rationnelle, c'est juste une possibilité d'économiser l'achat de
disques durs,
NON, pas forcément !
Très souvent on est confronté au pb de la partition système (qui contient
%systemroot%) devenue trop étroite.
(cela m'est déjà arrivé, alors que les applis, les documents,... sont
pourtant sur d'autres partitions)
P.ex. l'installation du SP2 nécessite énormément d'espace libre.
Il y a certes la possibilité de la redimensionner avec un partitonneur,
mais
cette opération est toujours un peu risquée.
(Et n'est pas toujours possible, en particulier s'il y a déjà des fichiers
compressés ou chiffrés)
Donc la compression des fichiers est souvent la SEULE solution, qui a
l'avantage en plus d'être immédiate (pas de reboot) et d'être
transparente.
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
http://www.bellamyjc.org *
Dans le message news:erM8pEoiEHA.4020@TK2MSFTNGP10.phx.gbl ,
le_troll <le_trol@paris.fr> s'est ainsi exprimé:
Bonjour,
Le principe de la compression (qui d'ailleurs peut se faire sur une
disquette), est que les valeurs sont recodées en tenant moins de
place, le principal effet est un "ralentissement", dans la mesure ou
le fichier doit être décodé puis recodé lors de son utilisation,
NON, il n'y a pas forcément de ralentissement.
Il peut même y avoir ACCÉLÉRATION !
Tout va dépendre du type de processeur et du type de DD.
En effet, si les opérations de compression/décompression consomment du
temps
CPU, en contrepartie, comme un fichier compressé occupe (généralement)
beaucoup moins d'espace sur le DD, les temps de transferts (lecture et
écriture) sont considérablement réduits.
Or ces temps d'accès disques se chiffrent en millisecondes, alors que les
temps CPU s'expriment plutôt en nanosecondes.
Donc la compression va généralement faire gagner du temps, contrairement à
la "croyance populaire" !
(les seuls cas où ce n'est pas vrai concerne les fichiers pour lesquels la
compression n'apporte rien, p.ex. les fichiers JPEG, ZIP, CAB,... , qui
sont
déjà compressés au départ)
le second problème est qu'éventuellement le fichier n'est pas lisible
par tous les logiciels...
NON, car c'est totalement TRANSPARENT pour les logiciels.
Quand un logiciel veut accéder à un fichier, le système de fichier
intervient AVANT, en effectuant compression/décompression préalable (idem
pour le chiffrement/déchiffrement dans le cas de EFS).
Il ne pourrait y avoir pb :
- qu'avec des utilitaires de bas niveau, qui vont lire
physiquement un disque secteur par secteur p.ex..
- dans le cas d'un multiboot, si un OS essaie d'accéder
aux fichiers compressés situés sur une partition
commune. (je pense essentiellement à Linux, qui sait
lire des NTFS, mais qui peut avoir des pb avec les
fichiers compressés)
Sinon, il ne devrait pas y avoir de perte
de données, mais ce n'est à mon sens pas une exploitation
rationnelle, c'est juste une possibilité d'économiser l'achat de
disques durs,
NON, pas forcément !
Très souvent on est confronté au pb de la partition système (qui contient
%systemroot%) devenue trop étroite.
(cela m'est déjà arrivé, alors que les applis, les documents,... sont
pourtant sur d'autres partitions)
P.ex. l'installation du SP2 nécessite énormément d'espace libre.
Il y a certes la possibilité de la redimensionner avec un partitonneur,
mais
cette opération est toujours un peu risquée.
(Et n'est pas toujours possible, en particulier s'il y a déjà des fichiers
compressés ou chiffrés)
Donc la compression des fichiers est souvent la SEULE solution, qui a
l'avantage en plus d'être immédiate (pas de reboot) et d'être
transparente.
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
http://www.bellamyjc.org Jean-Claude.Bellamy@wanadoo.fr *
JC.Bellamy@free.fr
Dans le message news: ,
le_troll s'est ainsi exprimé:Bonjour,
Le principe de la compression (qui d'ailleurs peut se faire sur une
disquette), est que les valeurs sont recodées en tenant moins de
place, le principal effet est un "ralentissement", dans la mesure ou
le fichier doit être décodé puis recodé lors de son utilisation,
NON, il n'y a pas forcément de ralentissement.
Il peut même y avoir ACCÉLÉRATION !
Tout va dépendre du type de processeur et du type de DD.
En effet, si les opérations de compression/décompression consomment du
temps
CPU, en contrepartie, comme un fichier compressé occupe (généralement)
beaucoup moins d'espace sur le DD, les temps de transferts (lecture et
écriture) sont considérablement réduits.
Or ces temps d'accès disques se chiffrent en millisecondes, alors que les
temps CPU s'expriment plutôt en nanosecondes.
Donc la compression va généralement faire gagner du temps, contrairement à
la "croyance populaire" !
(les seuls cas où ce n'est pas vrai concerne les fichiers pour lesquels la
compression n'apporte rien, p.ex. les fichiers JPEG, ZIP, CAB,... , qui
sont
déjà compressés au départ)le second problème est qu'éventuellement le fichier n'est pas lisible
par tous les logiciels...
NON, car c'est totalement TRANSPARENT pour les logiciels.
Quand un logiciel veut accéder à un fichier, le système de fichier
intervient AVANT, en effectuant compression/décompression préalable (idem
pour le chiffrement/déchiffrement dans le cas de EFS).
Il ne pourrait y avoir pb :
- qu'avec des utilitaires de bas niveau, qui vont lire
physiquement un disque secteur par secteur p.ex..
- dans le cas d'un multiboot, si un OS essaie d'accéder
aux fichiers compressés situés sur une partition
commune. (je pense essentiellement à Linux, qui sait
lire des NTFS, mais qui peut avoir des pb avec les
fichiers compressés)Sinon, il ne devrait pas y avoir de perte
de données, mais ce n'est à mon sens pas une exploitation
rationnelle, c'est juste une possibilité d'économiser l'achat de
disques durs,
NON, pas forcément !
Très souvent on est confronté au pb de la partition système (qui contient
%systemroot%) devenue trop étroite.
(cela m'est déjà arrivé, alors que les applis, les documents,... sont
pourtant sur d'autres partitions)
P.ex. l'installation du SP2 nécessite énormément d'espace libre.
Il y a certes la possibilité de la redimensionner avec un partitonneur,
mais
cette opération est toujours un peu risquée.
(Et n'est pas toujours possible, en particulier s'il y a déjà des fichiers
compressés ou chiffrés)
Donc la compression des fichiers est souvent la SEULE solution, qui a
l'avantage en plus d'être immédiate (pas de reboot) et d'être
transparente.
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
http://www.bellamyjc.org *
Dans le message news: ,
le_troll s'est ainsi exprimé:Bonjour,
Le principe de la compression (qui d'ailleurs peut se faire sur
une disquette), est que les valeurs sont recodées en tenant moins de
place, le principal effet est un "ralentissement", dans la mesure ou
le fichier doit être décodé puis recodé lors de son utilisation,
NON, il n'y a pas forcément de ralentissement.
Il peut même y avoir ACCÉLÉRATION !
Tout va dépendre du type de processeur et du type de DD.
En effet, si les opérations de compression/décompression consomment
du temps CPU, en contrepartie, comme un fichier compressé occupe
(généralement) beaucoup moins d'espace sur le DD, les temps de
transferts (lecture et écriture) sont considérablement réduits.
Or ces temps d'accès disques se chiffrent en millisecondes, alors que
les temps CPU s'expriment plutôt en nanosecondes.
Donc la compression va généralement faire gagner du temps,
contrairement à la "croyance populaire" !
(les seuls cas où ce n'est pas vrai concerne les fichiers pour
lesquels la compression n'apporte rien, p.ex. les fichiers JPEG, ZIP,
CAB,... , qui sont déjà compressés au départ)
Dans le message news:erM8pEoiEHA.4020@TK2MSFTNGP10.phx.gbl ,
le_troll <le_trol@paris.fr> s'est ainsi exprimé:
Bonjour,
Le principe de la compression (qui d'ailleurs peut se faire sur
une disquette), est que les valeurs sont recodées en tenant moins de
place, le principal effet est un "ralentissement", dans la mesure ou
le fichier doit être décodé puis recodé lors de son utilisation,
NON, il n'y a pas forcément de ralentissement.
Il peut même y avoir ACCÉLÉRATION !
Tout va dépendre du type de processeur et du type de DD.
En effet, si les opérations de compression/décompression consomment
du temps CPU, en contrepartie, comme un fichier compressé occupe
(généralement) beaucoup moins d'espace sur le DD, les temps de
transferts (lecture et écriture) sont considérablement réduits.
Or ces temps d'accès disques se chiffrent en millisecondes, alors que
les temps CPU s'expriment plutôt en nanosecondes.
Donc la compression va généralement faire gagner du temps,
contrairement à la "croyance populaire" !
(les seuls cas où ce n'est pas vrai concerne les fichiers pour
lesquels la compression n'apporte rien, p.ex. les fichiers JPEG, ZIP,
CAB,... , qui sont déjà compressés au départ)
Dans le message news: ,
le_troll s'est ainsi exprimé:Bonjour,
Le principe de la compression (qui d'ailleurs peut se faire sur
une disquette), est que les valeurs sont recodées en tenant moins de
place, le principal effet est un "ralentissement", dans la mesure ou
le fichier doit être décodé puis recodé lors de son utilisation,
NON, il n'y a pas forcément de ralentissement.
Il peut même y avoir ACCÉLÉRATION !
Tout va dépendre du type de processeur et du type de DD.
En effet, si les opérations de compression/décompression consomment
du temps CPU, en contrepartie, comme un fichier compressé occupe
(généralement) beaucoup moins d'espace sur le DD, les temps de
transferts (lecture et écriture) sont considérablement réduits.
Or ces temps d'accès disques se chiffrent en millisecondes, alors que
les temps CPU s'expriment plutôt en nanosecondes.
Donc la compression va généralement faire gagner du temps,
contrairement à la "croyance populaire" !
(les seuls cas où ce n'est pas vrai concerne les fichiers pour
lesquels la compression n'apporte rien, p.ex. les fichiers JPEG, ZIP,
CAB,... , qui sont déjà compressés au départ)
Dans le message news: ,
le_troll s'est ainsi exprimé:Bonjour,
Le principe de la compression (qui d'ailleurs peut se faire sur une
disquette), est que les valeurs sont recodées en tenant moins de
place, le principal effet est un "ralentissement", dans la mesure ou
le fichier doit être décodé puis recodé lors de son utilisation,
NON, il n'y a pas forcément de ralentissement.
Il peut même y avoir ACCÉLÉRATION !
Tout va dépendre du type de processeur et du type de DD.
En effet, si les opérations de compression/décompression consomment du
temps
CPU, en contrepartie, comme un fichier compressé occupe (généralement)
beaucoup moins d'espace sur le DD, les temps de transferts (lecture et
écriture) sont considérablement réduits.
Or ces temps d'accès disques se chiffrent en millisecondes, alors que les
temps CPU s'expriment plutôt en nanosecondes.
Donc la compression va généralement faire gagner du temps, contrairement à
la "croyance populaire" !
(les seuls cas où ce n'est pas vrai concerne les fichiers pour lesquels la
compression n'apporte rien, p.ex. les fichiers JPEG, ZIP, CAB,... , qui
sont
déjà compressés au départ)le second problème est qu'éventuellement le fichier n'est pas lisible
par tous les logiciels...
NON, car c'est totalement TRANSPARENT pour les logiciels.
Quand un logiciel veut accéder à un fichier, le système de fichier
intervient AVANT, en effectuant compression/décompression préalable (idem
pour le chiffrement/déchiffrement dans le cas de EFS).
Il ne pourrait y avoir pb :
- qu'avec des utilitaires de bas niveau, qui vont lire
physiquement un disque secteur par secteur p.ex..
- dans le cas d'un multiboot, si un OS essaie d'accéder
aux fichiers compressés situés sur une partition
commune. (je pense essentiellement à Linux, qui sait
lire des NTFS, mais qui peut avoir des pb avec les
fichiers compressés)Sinon, il ne devrait pas y avoir de perte
de données, mais ce n'est à mon sens pas une exploitation
rationnelle, c'est juste une possibilité d'économiser l'achat de
disques durs,
NON, pas forcément !
Très souvent on est confronté au pb de la partition système (qui contient
%systemroot%) devenue trop étroite.
(cela m'est déjà arrivé, alors que les applis, les documents,... sont
pourtant sur d'autres partitions)
P.ex. l'installation du SP2 nécessite énormément d'espace libre.
Il y a certes la possibilité de la redimensionner avec un partitonneur,
mais
cette opération est toujours un peu risquée.
(Et n'est pas toujours possible, en particulier s'il y a déjà des fichiers
compressés ou chiffrés)
Donc la compression des fichiers est souvent la SEULE solution, qui a
l'avantage en plus d'être immédiate (pas de reboot) et d'être
transparente.
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
http://www.bellamyjc.org *
Dans le message news:erM8pEoiEHA.4020@TK2MSFTNGP10.phx.gbl ,
le_troll <le_trol@paris.fr> s'est ainsi exprimé:
Bonjour,
Le principe de la compression (qui d'ailleurs peut se faire sur une
disquette), est que les valeurs sont recodées en tenant moins de
place, le principal effet est un "ralentissement", dans la mesure ou
le fichier doit être décodé puis recodé lors de son utilisation,
NON, il n'y a pas forcément de ralentissement.
Il peut même y avoir ACCÉLÉRATION !
Tout va dépendre du type de processeur et du type de DD.
En effet, si les opérations de compression/décompression consomment du
temps
CPU, en contrepartie, comme un fichier compressé occupe (généralement)
beaucoup moins d'espace sur le DD, les temps de transferts (lecture et
écriture) sont considérablement réduits.
Or ces temps d'accès disques se chiffrent en millisecondes, alors que les
temps CPU s'expriment plutôt en nanosecondes.
Donc la compression va généralement faire gagner du temps, contrairement à
la "croyance populaire" !
(les seuls cas où ce n'est pas vrai concerne les fichiers pour lesquels la
compression n'apporte rien, p.ex. les fichiers JPEG, ZIP, CAB,... , qui
sont
déjà compressés au départ)
le second problème est qu'éventuellement le fichier n'est pas lisible
par tous les logiciels...
NON, car c'est totalement TRANSPARENT pour les logiciels.
Quand un logiciel veut accéder à un fichier, le système de fichier
intervient AVANT, en effectuant compression/décompression préalable (idem
pour le chiffrement/déchiffrement dans le cas de EFS).
Il ne pourrait y avoir pb :
- qu'avec des utilitaires de bas niveau, qui vont lire
physiquement un disque secteur par secteur p.ex..
- dans le cas d'un multiboot, si un OS essaie d'accéder
aux fichiers compressés situés sur une partition
commune. (je pense essentiellement à Linux, qui sait
lire des NTFS, mais qui peut avoir des pb avec les
fichiers compressés)
Sinon, il ne devrait pas y avoir de perte
de données, mais ce n'est à mon sens pas une exploitation
rationnelle, c'est juste une possibilité d'économiser l'achat de
disques durs,
NON, pas forcément !
Très souvent on est confronté au pb de la partition système (qui contient
%systemroot%) devenue trop étroite.
(cela m'est déjà arrivé, alors que les applis, les documents,... sont
pourtant sur d'autres partitions)
P.ex. l'installation du SP2 nécessite énormément d'espace libre.
Il y a certes la possibilité de la redimensionner avec un partitonneur,
mais
cette opération est toujours un peu risquée.
(Et n'est pas toujours possible, en particulier s'il y a déjà des fichiers
compressés ou chiffrés)
Donc la compression des fichiers est souvent la SEULE solution, qui a
l'avantage en plus d'être immédiate (pas de reboot) et d'être
transparente.
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
http://www.bellamyjc.org Jean-Claude.Bellamy@wanadoo.fr *
JC.Bellamy@free.fr
Dans le message news: ,
le_troll s'est ainsi exprimé:Bonjour,
Le principe de la compression (qui d'ailleurs peut se faire sur une
disquette), est que les valeurs sont recodées en tenant moins de
place, le principal effet est un "ralentissement", dans la mesure ou
le fichier doit être décodé puis recodé lors de son utilisation,
NON, il n'y a pas forcément de ralentissement.
Il peut même y avoir ACCÉLÉRATION !
Tout va dépendre du type de processeur et du type de DD.
En effet, si les opérations de compression/décompression consomment du
temps
CPU, en contrepartie, comme un fichier compressé occupe (généralement)
beaucoup moins d'espace sur le DD, les temps de transferts (lecture et
écriture) sont considérablement réduits.
Or ces temps d'accès disques se chiffrent en millisecondes, alors que les
temps CPU s'expriment plutôt en nanosecondes.
Donc la compression va généralement faire gagner du temps, contrairement à
la "croyance populaire" !
(les seuls cas où ce n'est pas vrai concerne les fichiers pour lesquels la
compression n'apporte rien, p.ex. les fichiers JPEG, ZIP, CAB,... , qui
sont
déjà compressés au départ)le second problème est qu'éventuellement le fichier n'est pas lisible
par tous les logiciels...
NON, car c'est totalement TRANSPARENT pour les logiciels.
Quand un logiciel veut accéder à un fichier, le système de fichier
intervient AVANT, en effectuant compression/décompression préalable (idem
pour le chiffrement/déchiffrement dans le cas de EFS).
Il ne pourrait y avoir pb :
- qu'avec des utilitaires de bas niveau, qui vont lire
physiquement un disque secteur par secteur p.ex..
- dans le cas d'un multiboot, si un OS essaie d'accéder
aux fichiers compressés situés sur une partition
commune. (je pense essentiellement à Linux, qui sait
lire des NTFS, mais qui peut avoir des pb avec les
fichiers compressés)Sinon, il ne devrait pas y avoir de perte
de données, mais ce n'est à mon sens pas une exploitation
rationnelle, c'est juste une possibilité d'économiser l'achat de
disques durs,
NON, pas forcément !
Très souvent on est confronté au pb de la partition système (qui contient
%systemroot%) devenue trop étroite.
(cela m'est déjà arrivé, alors que les applis, les documents,... sont
pourtant sur d'autres partitions)
P.ex. l'installation du SP2 nécessite énormément d'espace libre.
Il y a certes la possibilité de la redimensionner avec un partitonneur,
mais
cette opération est toujours un peu risquée.
(Et n'est pas toujours possible, en particulier s'il y a déjà des fichiers
compressés ou chiffrés)
Donc la compression des fichiers est souvent la SEULE solution, qui a
l'avantage en plus d'être immédiate (pas de reboot) et d'être
transparente.
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
http://www.bellamyjc.org *
Euh, non, décompresser pour lire/écrire, puis recompresser, faudrait
me dire comment ça va plus vite que lire directement ???
Euh, non, décompresser pour lire/écrire, puis recompresser, faudrait
me dire comment ça va plus vite que lire directement ???
Euh, non, décompresser pour lire/écrire, puis recompresser, faudrait
me dire comment ça va plus vite que lire directement ???
Eh BELLAMY, déjà que tu m'as envoyé chier une fois que je te
demandais des renseignements pour cracker NT (d'après ton site),
n'oublies pas moi! Maintenant tu viens dire des conneries:
Un fichier compressé est illisible directement par l'OS,
çà ne veut rien dire "par l'OS" !
il passe par
une décompression suivant un algorithme, puis in fine, repasse par
une phase de compression, ceci en plus des opération habituelles;
Qui a dit le contraire ?
alors que ce soit transparent (éventuellement), mais que ça ne prenne
pas plus de temps CPU,
Tu mérite bien ton pseudo de troller , toi !
ben tu bave des conneries, retourne sur NT!
Au fait, je te signale que XP fait partie de la famille NT!
Eh BELLAMY, déjà que tu m'as envoyé chier une fois que je te
demandais des renseignements pour cracker NT (d'après ton site),
n'oublies pas moi! Maintenant tu viens dire des conneries:
Un fichier compressé est illisible directement par l'OS,
çà ne veut rien dire "par l'OS" !
il passe par
une décompression suivant un algorithme, puis in fine, repasse par
une phase de compression, ceci en plus des opération habituelles;
Qui a dit le contraire ?
alors que ce soit transparent (éventuellement), mais que ça ne prenne
pas plus de temps CPU,
Tu mérite bien ton pseudo de troller , toi !
ben tu bave des conneries, retourne sur NT!
Au fait, je te signale que XP fait partie de la famille NT!
Eh BELLAMY, déjà que tu m'as envoyé chier une fois que je te
demandais des renseignements pour cracker NT (d'après ton site),
n'oublies pas moi! Maintenant tu viens dire des conneries:
Un fichier compressé est illisible directement par l'OS,
çà ne veut rien dire "par l'OS" !
il passe par
une décompression suivant un algorithme, puis in fine, repasse par
une phase de compression, ceci en plus des opération habituelles;
Qui a dit le contraire ?
alors que ce soit transparent (éventuellement), mais que ça ne prenne
pas plus de temps CPU,
Tu mérite bien ton pseudo de troller , toi !
ben tu bave des conneries, retourne sur NT!
Au fait, je te signale que XP fait partie de la famille NT!
Bonjour à tous !
Je voudrais intervenir dans cette discussion car cela me semble
intéressant
et je trouve les esprits un peu trop chaud pour aussi peu de choses !
Je ne sais pas si compresser le disque dur peut ou pas ralentir ou
accélérer
le fonctionnement du système, ne l'ayant pas testé et mesuré moi-même.
Mais ce que dit JC Bellamy n'est peut-être pas (Au conditionnel) idiot. Je
m'explique :
Comme il l'a rappelé, et ce n'est pas un scoop, un disque dur lit et écrit
considérablement plus lentement qu'une mémoire RAM.
Prenons un exemple : On a un fichier compressé sur le disque qui fait deux
fois moins en taille que celui d'origine. La lecture de ce fichier par le
disque va se faire deux fois plus vite ! Ces temps étant relativement
longs,
le gain sera important. La décompression, elle, se faisant en RAM à des
vitesses considérablement plus grandes, il y aurait théoriquement
accélération si on additionne temps de lecture disque et décompression en
RAM.
Mais la question est de savoir si ce fichier va être effectivement
décompressé en RAM (Suppose une grosse quantité de RAM et une gestion de
la
mémoire idyllique) ou bien réécrit une fois décompressé sur le disque dur
dans un fichier "temporaire" ! Si c'est le deuxième cas de figure, on perd
du temps, c'est évident !
Cordialement
========== > Jean-Jacques
Bonjour à tous !
Je voudrais intervenir dans cette discussion car cela me semble
intéressant
et je trouve les esprits un peu trop chaud pour aussi peu de choses !
Je ne sais pas si compresser le disque dur peut ou pas ralentir ou
accélérer
le fonctionnement du système, ne l'ayant pas testé et mesuré moi-même.
Mais ce que dit JC Bellamy n'est peut-être pas (Au conditionnel) idiot. Je
m'explique :
Comme il l'a rappelé, et ce n'est pas un scoop, un disque dur lit et écrit
considérablement plus lentement qu'une mémoire RAM.
Prenons un exemple : On a un fichier compressé sur le disque qui fait deux
fois moins en taille que celui d'origine. La lecture de ce fichier par le
disque va se faire deux fois plus vite ! Ces temps étant relativement
longs,
le gain sera important. La décompression, elle, se faisant en RAM à des
vitesses considérablement plus grandes, il y aurait théoriquement
accélération si on additionne temps de lecture disque et décompression en
RAM.
Mais la question est de savoir si ce fichier va être effectivement
décompressé en RAM (Suppose une grosse quantité de RAM et une gestion de
la
mémoire idyllique) ou bien réécrit une fois décompressé sur le disque dur
dans un fichier "temporaire" ! Si c'est le deuxième cas de figure, on perd
du temps, c'est évident !
Cordialement
========== > Jean-Jacques
Bonjour à tous !
Je voudrais intervenir dans cette discussion car cela me semble
intéressant
et je trouve les esprits un peu trop chaud pour aussi peu de choses !
Je ne sais pas si compresser le disque dur peut ou pas ralentir ou
accélérer
le fonctionnement du système, ne l'ayant pas testé et mesuré moi-même.
Mais ce que dit JC Bellamy n'est peut-être pas (Au conditionnel) idiot. Je
m'explique :
Comme il l'a rappelé, et ce n'est pas un scoop, un disque dur lit et écrit
considérablement plus lentement qu'une mémoire RAM.
Prenons un exemple : On a un fichier compressé sur le disque qui fait deux
fois moins en taille que celui d'origine. La lecture de ce fichier par le
disque va se faire deux fois plus vite ! Ces temps étant relativement
longs,
le gain sera important. La décompression, elle, se faisant en RAM à des
vitesses considérablement plus grandes, il y aurait théoriquement
accélération si on additionne temps de lecture disque et décompression en
RAM.
Mais la question est de savoir si ce fichier va être effectivement
décompressé en RAM (Suppose une grosse quantité de RAM et une gestion de
la
mémoire idyllique) ou bien réécrit une fois décompressé sur le disque dur
dans un fichier "temporaire" ! Si c'est le deuxième cas de figure, on perd
du temps, c'est évident !
Cordialement
========== > Jean-Jacques
Dans le message news:uk$ ,
le_troll s'est ainsi exprimé:Eh BELLAMY, déjà que tu m'as envoyé chier une fois que je te
demandais des renseignements pour cracker NT (d'après ton site),
Je ne suis pas un pirate et n'ai jamais encouragé le piratage ...
Si je t'ai envoyé "faciliter ton transit intestinal", c'est que j'ai eu
raison de le faire ...n'oublies pas moi! Maintenant tu viens dire des conneries:
Un fichier compressé est illisible directement par l'OS,
çà ne veut rien dire "par l'OS" !
Un OS comporte forcément un gestionnaire de fichiers, qui supporte un ou
plusieurs système de fichiers, lesquels ont pour mission de décoder
éventuellement les fichiers compressés ou chiffrés.il passe par
une décompression suivant un algorithme, puis in fine, repasse par
une phase de compression, ceci en plus des opération habituelles;
Qui a dit le contraire ?alors que ce soit transparent (éventuellement), mais que ça ne prenne
pas plus de temps CPU,
Tu mérite bien ton pseudo de troller , toi !
Tu devrais concourir dans la catégorie "mauvaise foi" ...
A quel endroit ai-je dit que cela ne consommait pas de CPU ?
"[...]
En effet, si les opérations de compression/décompression
consomment du temps CPU,[...]"
Bien sûr que les opérations de compression/décompression consomment du
temps
CPU.
MAIS :
" en contrepartie, comme un fichier compressé occupe
(généralement) beaucoup moins d'espace sur le DD,
les temps de transferts (lecture et écriture) sont
considérablement réduits."
Donc le temps GLOBAL peut se voir réduit.ben tu bave des conneries, retourne sur NT!
Au fait, je te signale que XP fait partie de la famille NT!
Donc je n'ai pas besoin d'y retourner, j'y suis déjà..
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
http://www.bellamyjc.org *
Dans le message news:uk$JxNpiEHA.396@TK2MSFTNGP12.phx.gbl ,
le_troll <le_trol@paris.fr> s'est ainsi exprimé:
Eh BELLAMY, déjà que tu m'as envoyé chier une fois que je te
demandais des renseignements pour cracker NT (d'après ton site),
Je ne suis pas un pirate et n'ai jamais encouragé le piratage ...
Si je t'ai envoyé "faciliter ton transit intestinal", c'est que j'ai eu
raison de le faire ...
n'oublies pas moi! Maintenant tu viens dire des conneries:
Un fichier compressé est illisible directement par l'OS,
çà ne veut rien dire "par l'OS" !
Un OS comporte forcément un gestionnaire de fichiers, qui supporte un ou
plusieurs système de fichiers, lesquels ont pour mission de décoder
éventuellement les fichiers compressés ou chiffrés.
il passe par
une décompression suivant un algorithme, puis in fine, repasse par
une phase de compression, ceci en plus des opération habituelles;
Qui a dit le contraire ?
alors que ce soit transparent (éventuellement), mais que ça ne prenne
pas plus de temps CPU,
Tu mérite bien ton pseudo de troller , toi !
Tu devrais concourir dans la catégorie "mauvaise foi" ...
A quel endroit ai-je dit que cela ne consommait pas de CPU ?
"[...]
En effet, si les opérations de compression/décompression
consomment du temps CPU,[...]"
Bien sûr que les opérations de compression/décompression consomment du
temps
CPU.
MAIS :
" en contrepartie, comme un fichier compressé occupe
(généralement) beaucoup moins d'espace sur le DD,
les temps de transferts (lecture et écriture) sont
considérablement réduits."
Donc le temps GLOBAL peut se voir réduit.
ben tu bave des conneries, retourne sur NT!
Au fait, je te signale que XP fait partie de la famille NT!
Donc je n'ai pas besoin d'y retourner, j'y suis déjà..
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
http://www.bellamyjc.org Jean-Claude.Bellamy@wanadoo.fr *
JC.Bellamy@free.fr
Dans le message news:uk$ ,
le_troll s'est ainsi exprimé:Eh BELLAMY, déjà que tu m'as envoyé chier une fois que je te
demandais des renseignements pour cracker NT (d'après ton site),
Je ne suis pas un pirate et n'ai jamais encouragé le piratage ...
Si je t'ai envoyé "faciliter ton transit intestinal", c'est que j'ai eu
raison de le faire ...n'oublies pas moi! Maintenant tu viens dire des conneries:
Un fichier compressé est illisible directement par l'OS,
çà ne veut rien dire "par l'OS" !
Un OS comporte forcément un gestionnaire de fichiers, qui supporte un ou
plusieurs système de fichiers, lesquels ont pour mission de décoder
éventuellement les fichiers compressés ou chiffrés.il passe par
une décompression suivant un algorithme, puis in fine, repasse par
une phase de compression, ceci en plus des opération habituelles;
Qui a dit le contraire ?alors que ce soit transparent (éventuellement), mais que ça ne prenne
pas plus de temps CPU,
Tu mérite bien ton pseudo de troller , toi !
Tu devrais concourir dans la catégorie "mauvaise foi" ...
A quel endroit ai-je dit que cela ne consommait pas de CPU ?
"[...]
En effet, si les opérations de compression/décompression
consomment du temps CPU,[...]"
Bien sûr que les opérations de compression/décompression consomment du
temps
CPU.
MAIS :
" en contrepartie, comme un fichier compressé occupe
(généralement) beaucoup moins d'espace sur le DD,
les temps de transferts (lecture et écriture) sont
considérablement réduits."
Donc le temps GLOBAL peut se voir réduit.ben tu bave des conneries, retourne sur NT!
Au fait, je te signale que XP fait partie de la famille NT!
Donc je n'ai pas besoin d'y retourner, j'y suis déjà..
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
http://www.bellamyjc.org *