Voil=E0 : il y a deux ans environ, un de mes deux disques avait l=E2ch=E9
(salet=E9 de sata) et je ne tournais plus qu'avec un seul disque. Lors
d'un nettoyage Windows, il me semble que j'avais accept=E9 l'option
compressant les fichiers (et programmes) non-utilis=E9s depuis plus de
xx jours.
Je voudrais arr=EAter cette option et ne plus rien compresser.
Mais je ne sais pas o=F9 choper la commande.
Dans un menu Windows 2000 Pro ?
Une ligne de commande ?
La BDR ?
L'OS gère, et passe d'une tache à l'autre en fonction de différents critères
'Tain la mauvaise foi :) Y avait une mouche qui passait peut-être ? N'empêche, je ne voyais pas la définition "être multi-tâches" comme "savoir gérer de multiples tâches", mais plutôt "exécuter plusieurs tâches en même temps", et ça ne date pas d'hier.
-- Clairon - Nuance ...
Bonjour !
Marc Boyer a ecrit le 13/03/2007 17:45:
"gérer" n'est pas synonyme d'"exécuter"
L'OS gère, et passe d'une tache à l'autre en fonction
de différents critères
'Tain la mauvaise foi :) Y avait une mouche qui passait peut-être ?
N'empêche, je ne voyais pas la définition "être multi-tâches" comme
"savoir gérer de multiples tâches", mais plutôt "exécuter plusieurs
tâches en même temps", et ça ne date pas d'hier.
L'OS gère, et passe d'une tache à l'autre en fonction de différents critères
'Tain la mauvaise foi :) Y avait une mouche qui passait peut-être ? N'empêche, je ne voyais pas la définition "être multi-tâches" comme "savoir gérer de multiples tâches", mais plutôt "exécuter plusieurs tâches en même temps", et ça ne date pas d'hier.
-- Clairon - Nuance ...
Nina Popravka
On Tue, 13 Mar 2007 18:42:05 +0100, Alain Redic wrote:
loin de moi l'idée de vouloir contredire, mais c'étaient les mêmes arguments cités à l'époque pour stacker. A l'usage on s'est vite rendu compte de la lenteur de celui-ci.
Pour avoir utilisé, à l'époque, et Stacker, et la compression NTFS, je peux t'affirmer que c'était incomparable. -- Nina
On Tue, 13 Mar 2007 18:42:05 +0100, Alain Redic <nospam@nospam.org>
wrote:
loin de moi l'idée de vouloir contredire, mais c'étaient les mêmes
arguments cités à l'époque pour stacker.
A l'usage on s'est vite rendu compte de la lenteur de celui-ci.
Pour avoir utilisé, à l'époque, et Stacker, et la compression NTFS, je
peux t'affirmer que c'était incomparable.
--
Nina
On Tue, 13 Mar 2007 18:42:05 +0100, Alain Redic wrote:
loin de moi l'idée de vouloir contredire, mais c'étaient les mêmes arguments cités à l'époque pour stacker. A l'usage on s'est vite rendu compte de la lenteur de celui-ci.
Pour avoir utilisé, à l'époque, et Stacker, et la compression NTFS, je peux t'affirmer que c'était incomparable. -- Nina
Marc Boyer
Le 13-03-2007, Clairon a écrit :
Marc Boyer a ecrit le 13/03/2007 17:45:
"gérer" n'est pas synonyme d'"exécuter"
L'OS gère, et passe d'une tache à l'autre en fonction de différents critères
'Tain la mauvaise foi :) Y avait une mouche qui passait peut-être ?
Un peu. Ceci dit, c'est aussi que je pense que cette terminologie vient d'une époque où l'on avait pas d'OS multi-taches. D'ailleurs, on a encore des OS (assez spécifique -- OSEK) multi-tache non préemptif, mono processeur.
N'empêche, je ne voyais pas la définition "être multi-tâches" comme "savoir gérer de multiples tâches", mais plutôt "exécuter plusieurs tâches en même temps", et ça ne date pas d'hier.
Ben... On peut voir que Wikipédia va dans mon sens (avec plusieurs distinctions). Le problème est que le mot vient des années 60, à une époque où un ordinateur était un gros truc qui lisait des cartes et exécutait (grosso modo) chaque carte l'une après l'autre.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Le 13-03-2007, Clairon <cbrione@free.fr> a écrit :
Marc Boyer a ecrit le 13/03/2007 17:45:
"gérer" n'est pas synonyme d'"exécuter"
L'OS gère, et passe d'une tache à l'autre en fonction
de différents critères
'Tain la mauvaise foi :) Y avait une mouche qui passait peut-être ?
Un peu. Ceci dit, c'est aussi que je pense que cette terminologie
vient d'une époque où l'on avait pas d'OS multi-taches.
D'ailleurs, on a encore des OS (assez spécifique -- OSEK)
multi-tache non préemptif, mono processeur.
N'empêche, je ne voyais pas la définition "être multi-tâches" comme
"savoir gérer de multiples tâches", mais plutôt "exécuter plusieurs
tâches en même temps", et ça ne date pas d'hier.
Ben... On peut voir que Wikipédia va dans mon sens (avec plusieurs
distinctions). Le problème est que le mot vient des années 60, à
une époque où un ordinateur était un gros truc qui lisait des cartes
et exécutait (grosso modo) chaque carte l'une après l'autre.
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
L'OS gère, et passe d'une tache à l'autre en fonction de différents critères
'Tain la mauvaise foi :) Y avait une mouche qui passait peut-être ?
Un peu. Ceci dit, c'est aussi que je pense que cette terminologie vient d'une époque où l'on avait pas d'OS multi-taches. D'ailleurs, on a encore des OS (assez spécifique -- OSEK) multi-tache non préemptif, mono processeur.
N'empêche, je ne voyais pas la définition "être multi-tâches" comme "savoir gérer de multiples tâches", mais plutôt "exécuter plusieurs tâches en même temps", et ça ne date pas d'hier.
Ben... On peut voir que Wikipédia va dans mon sens (avec plusieurs distinctions). Le problème est que le mot vient des années 60, à une époque où un ordinateur était un gros truc qui lisait des cartes et exécutait (grosso modo) chaque carte l'une après l'autre.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Jean-Claude BELLAMY
"Alain Redic" a écrit dans le message de news:et6nof$2p8f$
NON, cela ne ralentit pas du tout, car le fichier occupant MOINS de place sur le disque, le temps de transfert (très long à l'échelle du processeur) se trouve réduit d'autant. Donc le temps perdu dans la décompression est très largement compensé par le gain de temps de lecture du fichier.
loin de moi l'idée de vouloir contredire, mais c'étaient les mêmes arguments cités à l'époque pour stacker. Et ils étaient EXACTS !
A l'usage on s'est vite rendu compte de la lenteur de celui-ci.
Et bien NON justement, ayant été un des premiers utilisateurs de "Stacker" (honteusement pompé par Microsoft par la suite dans DRVSPACE !). Je n'ai jamais constaté le moindre ralentissement, sur plusieurs machines, avec la solution purement logicielle, et a fortiori avec la solution matérielle (sur 2 machines j'avais une carte ISA qui effectuait elle même les opérations de compression et décompression)
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] http://www.bellamyjc.org ou http://jc.bellamy.free.fr
"Alain Redic" <nospam@nospam.org> a écrit dans le message de
news:et6nof$2p8f$1@talisker.lacave.net...
NON, cela ne ralentit pas du tout, car le fichier occupant MOINS de
place sur le disque, le temps de transfert (très long à l'échelle du
processeur) se trouve réduit d'autant.
Donc le temps perdu dans la décompression est très largement compensé
par le gain de temps de lecture du fichier.
loin de moi l'idée de vouloir contredire, mais c'étaient les mêmes
arguments cités à l'époque pour stacker.
Et ils étaient EXACTS !
A l'usage on s'est vite rendu compte de la lenteur de celui-ci.
Et bien NON justement, ayant été un des premiers utilisateurs de "Stacker"
(honteusement pompé par Microsoft par la suite dans DRVSPACE !).
Je n'ai jamais constaté le moindre ralentissement, sur plusieurs machines,
avec la solution purement logicielle, et a fortiori avec la solution
matérielle (sur 2 machines j'avais une carte ISA qui effectuait elle même
les opérations de compression et décompression)
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP]
http://www.bellamyjc.org ou http://jc.bellamy.free.fr
"Alain Redic" a écrit dans le message de news:et6nof$2p8f$
NON, cela ne ralentit pas du tout, car le fichier occupant MOINS de place sur le disque, le temps de transfert (très long à l'échelle du processeur) se trouve réduit d'autant. Donc le temps perdu dans la décompression est très largement compensé par le gain de temps de lecture du fichier.
loin de moi l'idée de vouloir contredire, mais c'étaient les mêmes arguments cités à l'époque pour stacker. Et ils étaient EXACTS !
A l'usage on s'est vite rendu compte de la lenteur de celui-ci.
Et bien NON justement, ayant été un des premiers utilisateurs de "Stacker" (honteusement pompé par Microsoft par la suite dans DRVSPACE !). Je n'ai jamais constaté le moindre ralentissement, sur plusieurs machines, avec la solution purement logicielle, et a fortiori avec la solution matérielle (sur 2 machines j'avais une carte ISA qui effectuait elle même les opérations de compression et décompression)
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] http://www.bellamyjc.org ou http://jc.bellamy.free.fr
Alain Redic
Et bien NON justement, ayant été un des premiers utilisateurs de "Stacker" (honteusement pompé par Microsoft par la suite dans DRVSPACE !). Je n'ai jamais constaté le moindre ralentissement,
bin moi si, et je suis pas le seul, idem bien évidemment avec dbl/drvspace (6.20/6.22). Et pourtant, ça tournait sur des rolls de l'époque.
Qu'importe, Nina à raison de dire que c'est incomparable, c'est juste l'argument que je reprenais.
Et bien NON justement, ayant été un des premiers utilisateurs de
"Stacker" (honteusement pompé par Microsoft par la suite dans DRVSPACE !).
Je n'ai jamais constaté le moindre ralentissement,
bin moi si, et je suis pas le seul, idem bien évidemment avec
dbl/drvspace (6.20/6.22).
Et pourtant, ça tournait sur des rolls de l'époque.
Qu'importe, Nina à raison de dire que c'est incomparable, c'est juste
l'argument que je reprenais.
Et bien NON justement, ayant été un des premiers utilisateurs de "Stacker" (honteusement pompé par Microsoft par la suite dans DRVSPACE !). Je n'ai jamais constaté le moindre ralentissement,
bin moi si, et je suis pas le seul, idem bien évidemment avec dbl/drvspace (6.20/6.22). Et pourtant, ça tournait sur des rolls de l'époque.
Qu'importe, Nina à raison de dire que c'est incomparable, c'est juste l'argument que je reprenais.
