Comme de plus en plus de monde, j'ai maintenant un processeur double
coeur (Core2 Duo), et je m'aperçois que la plupart des logiciels ne
peuvent utiliser que 50 % de sa puissance (i.e. un seul coeur).
Qu'en est-il des compilateurs ?
Existe-t-il des outils pour répartir la compilation sur deux
processeurs ou plus ?
(Je précise que tous les fichiers de mes projets (sources, objets,
exe) tiennent largement en RAM, donc le disque dur ne reste pas
longtemps un goulot d'étranglement.)
"Michael DOUBEZ" a écrit dans le message de news: 46a434ad$0$23935$
De toute façon, c'est le processeur et non le disque le maillon faible pour une compilation... Pas nécessairement, c'est pourquoi gcc a l'option -pipe qui permet
d'éviter la création de fichiers temporaires entre les phases de compilation.
Tu as testé pour voir de quel ordre était le gain de temps ?
Je ne me souviens plus mais sur mon AMDK6, c'était assez conséquent. Je ne parle même pas des terminaux UNIX quand j'étais étudiant. A l'occasion j'essayerai sur mon projet actuel.
Je me souviens aussi que egcs avait du mal à compiler des programmes qui utilisaient de façon intensive les templates (quelques centaines de Mo pour blitz je crois); aujourd'hui ce ne serait rien (et les compilateurs sont plus performants/intelligents) mais à l'époque il fallait repartionner le disque pour augmenter le swap.
Aujourd'hui, j'avoue ne pas y penser et mettre -pipe dès que je peux.
Michael
"Michael DOUBEZ" <michael.doubez@free.fr> a écrit dans le message de news:
46a434ad$0$23935$426a74cc@news.free.fr...
De toute façon, c'est le processeur et non le disque le maillon faible
pour une compilation...
Pas nécessairement, c'est pourquoi gcc a l'option -pipe qui permet
d'éviter la création de fichiers temporaires entre les phases de
compilation.
Tu as testé pour voir de quel ordre était le gain de temps ?
Je ne me souviens plus mais sur mon AMDK6, c'était assez conséquent. Je
ne parle même pas des terminaux UNIX quand j'étais étudiant. A
l'occasion j'essayerai sur mon projet actuel.
Je me souviens aussi que egcs avait du mal à compiler des programmes qui
utilisaient de façon intensive les templates (quelques centaines de Mo
pour blitz je crois); aujourd'hui ce ne serait rien (et les compilateurs
sont plus performants/intelligents) mais à l'époque il fallait
repartionner le disque pour augmenter le swap.
Aujourd'hui, j'avoue ne pas y penser et mettre -pipe dès que je peux.
"Michael DOUBEZ" a écrit dans le message de news: 46a434ad$0$23935$
De toute façon, c'est le processeur et non le disque le maillon faible pour une compilation... Pas nécessairement, c'est pourquoi gcc a l'option -pipe qui permet
d'éviter la création de fichiers temporaires entre les phases de compilation.
Tu as testé pour voir de quel ordre était le gain de temps ?
Je ne me souviens plus mais sur mon AMDK6, c'était assez conséquent. Je ne parle même pas des terminaux UNIX quand j'étais étudiant. A l'occasion j'essayerai sur mon projet actuel.
Je me souviens aussi que egcs avait du mal à compiler des programmes qui utilisaient de façon intensive les templates (quelques centaines de Mo pour blitz je crois); aujourd'hui ce ne serait rien (et les compilateurs sont plus performants/intelligents) mais à l'époque il fallait repartionner le disque pour augmenter le swap.
Aujourd'hui, j'avoue ne pas y penser et mettre -pipe dès que je peux.
Michael
Fabien LE LEZ
On Mon, 23 Jul 2007 07:37:06 -0000, James Kanze :
C'est à peu près ce que je me démande moi-même. Pour beaucoup, le compilateur lit des données, puis il les traite. À part la phase de l'optimisation, il n'y a pas besoin de garder beaucoup en RAM.
Quid de tous les fichiers objets ? Et des headers inclus dans plusieurs modules différents ? Avec assez de RAM, tout ça n'a pas à être relu -- tout reste dans le cache.
On Mon, 23 Jul 2007 07:37:06 -0000, James Kanze
<james.kanze@gmail.com>:
C'est à peu près ce que je me démande moi-même. Pour beaucoup,
le compilateur lit des données, puis il les traite. À part la
phase de l'optimisation, il n'y a pas besoin de garder beaucoup
en RAM.
Quid de tous les fichiers objets ? Et des headers inclus dans
plusieurs modules différents ? Avec assez de RAM, tout ça n'a pas à
être relu -- tout reste dans le cache.
C'est à peu près ce que je me démande moi-même. Pour beaucoup, le compilateur lit des données, puis il les traite. À part la phase de l'optimisation, il n'y a pas besoin de garder beaucoup en RAM.
Quid de tous les fichiers objets ? Et des headers inclus dans plusieurs modules différents ? Avec assez de RAM, tout ça n'a pas à être relu -- tout reste dans le cache.
Fabien LE LEZ
On Mon, 23 Jul 2007 07:27:37 -0000, James Kanze :
(Et si j'étais mauvaise langue, je dirais que sous Windows, tu gagnes, parce que tu as un processeur pour les virus
Les virus sous Windows, c'est plus ou moins une légende. J'en ai déjà vu, mais les problèmes liés aux virus sont anecdotiques -- bien moins fréquents, par exemple, que les problèmes liés aux pannes matérielles.
Par contre, il est vrai que les anti-virus sont un énorme facteur de ralentissement des machines. Mais les machines ayant besoin d'un anti-virus, et les machines de compilation, sont rarement les mêmes.
On Mon, 23 Jul 2007 07:27:37 -0000, James Kanze
<james.kanze@gmail.com>:
(Et si j'étais mauvaise langue, je dirais que sous Windows, tu
gagnes, parce que tu as un processeur pour les virus
Les virus sous Windows, c'est plus ou moins une légende. J'en ai déjà
vu, mais les problèmes liés aux virus sont anecdotiques -- bien moins
fréquents, par exemple, que les problèmes liés aux pannes matérielles.
Par contre, il est vrai que les anti-virus sont un énorme facteur de
ralentissement des machines. Mais les machines ayant besoin d'un
anti-virus, et les machines de compilation, sont rarement les mêmes.
(Et si j'étais mauvaise langue, je dirais que sous Windows, tu gagnes, parce que tu as un processeur pour les virus
Les virus sous Windows, c'est plus ou moins une légende. J'en ai déjà vu, mais les problèmes liés aux virus sont anecdotiques -- bien moins fréquents, par exemple, que les problèmes liés aux pannes matérielles.
Par contre, il est vrai que les anti-virus sont un énorme facteur de ralentissement des machines. Mais les machines ayant besoin d'un anti-virus, et les machines de compilation, sont rarement les mêmes.
Fabien LE LEZ
On Mon, 23 Jul 2007 07:37:06 -0000, James Kanze :
Pour beaucoup, le compilateur lit des données, puis il les traite.
En plus de mon autre réponse, note qu'on apprécie particulièrement une compilation rapide quand on doit compiler plusieurs fois dans la même journée. Et si jamais tous les sources restent en cache en permanence, il n'y a rien à lire sur le disque dur.
On Mon, 23 Jul 2007 07:37:06 -0000, James Kanze
<james.kanze@gmail.com>:
Pour beaucoup,
le compilateur lit des données, puis il les traite.
En plus de mon autre réponse, note qu'on apprécie particulièrement une
compilation rapide quand on doit compiler plusieurs fois dans la même
journée. Et si jamais tous les sources restent en cache en permanence,
il n'y a rien à lire sur le disque dur.
Pour beaucoup, le compilateur lit des données, puis il les traite.
En plus de mon autre réponse, note qu'on apprécie particulièrement une compilation rapide quand on doit compiler plusieurs fois dans la même journée. Et si jamais tous les sources restent en cache en permanence, il n'y a rien à lire sur le disque dur.
Rakotomandimby (R12y) Mihamina
Fabien LE LEZ - :
les machines ayant besoin d'un anti-virus, et les machines de compilation, sont rarement les mêmes.
incontestable.
-- "C'est très facile d'avoir des idées de partage quand on n'a rien." Patrice KARATCHENTZEFF
Fabien LE LEZ - <olu9a357cck4kp8cppbnukcvb4gegreqke@4ax.com> :
les machines ayant besoin d'un
anti-virus, et les machines de compilation, sont rarement les mêmes.
incontestable.
--
"C'est très facile d'avoir des idées de partage quand on n'a rien."
Patrice KARATCHENTZEFF
les machines ayant besoin d'un anti-virus, et les machines de compilation, sont rarement les mêmes.
incontestable.
-- "C'est très facile d'avoir des idées de partage quand on n'a rien." Patrice KARATCHENTZEFF
Michael DOUBEZ
On Mon, 23 Jul 2007 07:27:37 -0000, James Kanze :
(Et si j'étais mauvaise langue, je dirais que sous Windows, tu gagnes, parce que tu as un processeur pour les virus
Les virus sous Windows, c'est plus ou moins une légende. J'en ai déjà vu, mais les problèmes liés aux virus sont anecdotiques -- bien moins fréquents, par exemple, que les problèmes liés aux pannes matérielles.
Pour les cognants peut être mais j'aide des personnes qui ne connaissent rien à l'info a l'utiliser dans leur travail (en général des petits magasins) et les anti virus leur sauvent la vie (ou du moins leur compta); ils ouvrent tous les mail frauduleux qu'ils reçoivent et se font facilement avoir par le phishing.
Il y en a un, récemment, qui a ouvert un fichier: le 'virus' (si on peut vraiment appeler ça comme ça aujourd'hui) lui a déplacé et renommé (avec des caractères aléatoires) tous ses répertoires. Sans parler de cette vielle dame qui ne voulait plus que sa petite fille approche de son ordinateur car elle avait choppé un virus qui ouvrait des pop-ups de liens vers des sites pornos.
Michael
On Mon, 23 Jul 2007 07:27:37 -0000, James Kanze
<james.kanze@gmail.com>:
(Et si j'étais mauvaise langue, je dirais que sous Windows, tu
gagnes, parce que tu as un processeur pour les virus
Les virus sous Windows, c'est plus ou moins une légende. J'en ai déjà
vu, mais les problèmes liés aux virus sont anecdotiques -- bien moins
fréquents, par exemple, que les problèmes liés aux pannes matérielles.
Pour les cognants peut être mais j'aide des personnes qui ne connaissent
rien à l'info a l'utiliser dans leur travail (en général des petits
magasins) et les anti virus leur sauvent la vie (ou du moins leur
compta); ils ouvrent tous les mail frauduleux qu'ils reçoivent et se
font facilement avoir par le phishing.
Il y en a un, récemment, qui a ouvert un fichier: le 'virus' (si on peut
vraiment appeler ça comme ça aujourd'hui) lui a déplacé et renommé (avec
des caractères aléatoires) tous ses répertoires. Sans parler de cette
vielle dame qui ne voulait plus que sa petite fille approche de son
ordinateur car elle avait choppé un virus qui ouvrait des pop-ups de
liens vers des sites pornos.
(Et si j'étais mauvaise langue, je dirais que sous Windows, tu gagnes, parce que tu as un processeur pour les virus
Les virus sous Windows, c'est plus ou moins une légende. J'en ai déjà vu, mais les problèmes liés aux virus sont anecdotiques -- bien moins fréquents, par exemple, que les problèmes liés aux pannes matérielles.
Pour les cognants peut être mais j'aide des personnes qui ne connaissent rien à l'info a l'utiliser dans leur travail (en général des petits magasins) et les anti virus leur sauvent la vie (ou du moins leur compta); ils ouvrent tous les mail frauduleux qu'ils reçoivent et se font facilement avoir par le phishing.
Il y en a un, récemment, qui a ouvert un fichier: le 'virus' (si on peut vraiment appeler ça comme ça aujourd'hui) lui a déplacé et renommé (avec des caractères aléatoires) tous ses répertoires. Sans parler de cette vielle dame qui ne voulait plus que sa petite fille approche de son ordinateur car elle avait choppé un virus qui ouvrait des pop-ups de liens vers des sites pornos.
Michael
James Kanze
On Jul 23, 9:03 pm, Fabien LE LEZ wrote:
On Mon, 23 Jul 2007 07:27:37 -0000, James Kanze :
(Et si j'étais mauvaise langue, je dirais que sous Windows, tu gagnes, parce que tu as un processeur pour les virus
Les virus sous Windows, c'est plus ou moins une légende. J'en ai déj à vu, mais les problèmes liés aux virus sont anecdotiques -- bien moins fréquents, par exemple, que les problèmes liés aux pannes matérie lles.
Pas selon CAIC. Il y a beaucoup plus de problèmes sous Windows que sous d'autres systèmes. (Sans doute au moins en partie parce que ça rapporte plus aux pirates de s'attaquer au Windows.)
Par contre, il est vrai que les anti-virus sont un énorme facteur de ralentissement des machines. Mais les machines ayant besoin d'un anti-virus, et les machines de compilation, sont rarement les mêmes.
En effet, la risque de virus dépend surtout de ce qu'on fait avec la machine. En faisant attention, il n'y a pas de raison d'avoir un virus nulle part. Mais ce n'est pas toujours si évident. En tout cas, j'ai vu des problèmes réels de virus sous Windows (mais qui ne m'ont pas touché, parce que je n'ai pas ouvert le courriel), et non sous d'autres systèmes, et ça, bien que je travaille dans les milieux où Unix prédomine.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Jul 23, 9:03 pm, Fabien LE LEZ <grams...@gramster.com> wrote:
On Mon, 23 Jul 2007 07:27:37 -0000, James Kanze
<james.ka...@gmail.com>:
(Et si j'étais mauvaise langue, je dirais que sous Windows, tu
gagnes, parce que tu as un processeur pour les virus
Les virus sous Windows, c'est plus ou moins une légende. J'en ai déj à
vu, mais les problèmes liés aux virus sont anecdotiques -- bien moins
fréquents, par exemple, que les problèmes liés aux pannes matérie lles.
Pas selon CAIC. Il y a beaucoup plus de problèmes sous Windows
que sous d'autres systèmes. (Sans doute au moins en partie parce
que ça rapporte plus aux pirates de s'attaquer au Windows.)
Par contre, il est vrai que les anti-virus sont un énorme facteur de
ralentissement des machines. Mais les machines ayant besoin d'un
anti-virus, et les machines de compilation, sont rarement les mêmes.
En effet, la risque de virus dépend surtout de ce qu'on fait
avec la machine. En faisant attention, il n'y a pas de raison
d'avoir un virus nulle part. Mais ce n'est pas toujours si
évident. En tout cas, j'ai vu des problèmes réels de virus sous
Windows (mais qui ne m'ont pas touché, parce que je n'ai pas
ouvert le courriel), et non sous d'autres systèmes, et ça, bien
que je travaille dans les milieux où Unix prédomine.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
(Et si j'étais mauvaise langue, je dirais que sous Windows, tu gagnes, parce que tu as un processeur pour les virus
Les virus sous Windows, c'est plus ou moins une légende. J'en ai déj à vu, mais les problèmes liés aux virus sont anecdotiques -- bien moins fréquents, par exemple, que les problèmes liés aux pannes matérie lles.
Pas selon CAIC. Il y a beaucoup plus de problèmes sous Windows que sous d'autres systèmes. (Sans doute au moins en partie parce que ça rapporte plus aux pirates de s'attaquer au Windows.)
Par contre, il est vrai que les anti-virus sont un énorme facteur de ralentissement des machines. Mais les machines ayant besoin d'un anti-virus, et les machines de compilation, sont rarement les mêmes.
En effet, la risque de virus dépend surtout de ce qu'on fait avec la machine. En faisant attention, il n'y a pas de raison d'avoir un virus nulle part. Mais ce n'est pas toujours si évident. En tout cas, j'ai vu des problèmes réels de virus sous Windows (mais qui ne m'ont pas touché, parce que je n'ai pas ouvert le courriel), et non sous d'autres systèmes, et ça, bien que je travaille dans les milieux où Unix prédomine.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze
On Jul 23, 8:59 pm, Fabien LE LEZ wrote:
On Mon, 23 Jul 2007 07:37:06 -0000, James Kanze :
C'est à peu près ce que je me démande moi-même. Pour beaucoup, le compilateur lit des données, puis il les traite. À part la phase de l'optimisation, il n'y a pas besoin de garder beaucoup en RAM.
Quid de tous les fichiers objets ? Et des headers inclus dans plusieurs modules différents ? Avec assez de RAM, tout ça n'a pas à être relu -- tout reste dans le cache.
Ou non, selon le cas. C'est sûr que si on compile une centaine de modules à la suite, il y a de fortes chances que le système ai les données dans ses caches mémoire. À condition d'avoir beaucoup de mémoire. Mais c'est toujours de l'entrée/sortie par rapport au compilateur : ce n'est pas quelque chose qu'il peut paralelliser en se servant de plusieurs processeurs. (Il y aura certainement des choses à faire dans la paralellisation des algorithmes d'optimisation. Mais je ne connais pas de compilateur qui en est là aujourd'hui.)
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Jul 23, 8:59 pm, Fabien LE LEZ <grams...@gramster.com> wrote:
On Mon, 23 Jul 2007 07:37:06 -0000, James Kanze
<james.ka...@gmail.com>:
C'est à peu près ce que je me démande moi-même. Pour beaucoup,
le compilateur lit des données, puis il les traite. À part la
phase de l'optimisation, il n'y a pas besoin de garder beaucoup
en RAM.
Quid de tous les fichiers objets ? Et des headers inclus dans
plusieurs modules différents ? Avec assez de RAM, tout ça n'a pas à
être relu -- tout reste dans le cache.
Ou non, selon le cas. C'est sûr que si on compile une centaine
de modules à la suite, il y a de fortes chances que le système
ai les données dans ses caches mémoire. À condition d'avoir
beaucoup de mémoire. Mais c'est toujours de l'entrée/sortie par
rapport au compilateur : ce n'est pas quelque chose qu'il peut
paralelliser en se servant de plusieurs processeurs. (Il y aura
certainement des choses à faire dans la paralellisation des
algorithmes d'optimisation. Mais je ne connais pas de
compilateur qui en est là aujourd'hui.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
C'est à peu près ce que je me démande moi-même. Pour beaucoup, le compilateur lit des données, puis il les traite. À part la phase de l'optimisation, il n'y a pas besoin de garder beaucoup en RAM.
Quid de tous les fichiers objets ? Et des headers inclus dans plusieurs modules différents ? Avec assez de RAM, tout ça n'a pas à être relu -- tout reste dans le cache.
Ou non, selon le cas. C'est sûr que si on compile une centaine de modules à la suite, il y a de fortes chances que le système ai les données dans ses caches mémoire. À condition d'avoir beaucoup de mémoire. Mais c'est toujours de l'entrée/sortie par rapport au compilateur : ce n'est pas quelque chose qu'il peut paralelliser en se servant de plusieurs processeurs. (Il y aura certainement des choses à faire dans la paralellisation des algorithmes d'optimisation. Mais je ne connais pas de compilateur qui en est là aujourd'hui.)
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze
On Jul 23, 11:47 pm, Fabien LE LEZ wrote:
On Mon, 23 Jul 2007 07:37:06 -0000, James Kanze :
Pour beaucoup, le compilateur lit des données, puis il les traite.
En plus de mon autre réponse, note qu'on apprécie particulièrement une compilation rapide quand on doit compiler plusieurs fois dans la même journée. Et si jamais tous les sources restent en cache en permanence, il n'y a rien à lire sur le disque dur.
Dans la pratique, je crois que c'est peu probable. Il y a combien de cache : 1 Go ? Ou plus souvent, moins. Et n'oublie pas que tout ce que tu lis ou écris y passe : les pages Web, la doc, etc. Or, typiquement, tes bibliothèques vont bien dépasser ça, ou au moins en être proche. Donc, après l'édition de liens, il n'y a plus d'en-tête dans la cache.
Où la cache pourrait jouer un rôle, c'est dans le cas des rebuild complet, où tu rélis <iostream> des milliers de fois, sans forcement lire ou écrire assez d'autre choses entre temps pour qu'il soit purgé de la cache. (L'option -pipe de g++ pourrait aider ici, parce qu'elle s'assure que les « fichiers » intermédiaires sont des pipes, et donc, n'utilise jamais plus d'un bloc dans la cache.)
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Jul 23, 11:47 pm, Fabien LE LEZ <grams...@gramster.com> wrote:
On Mon, 23 Jul 2007 07:37:06 -0000, James Kanze
<james.ka...@gmail.com>:
Pour beaucoup,
le compilateur lit des données, puis il les traite.
En plus de mon autre réponse, note qu'on apprécie particulièrement une
compilation rapide quand on doit compiler plusieurs fois dans la même
journée. Et si jamais tous les sources restent en cache en permanence,
il n'y a rien à lire sur le disque dur.
Dans la pratique, je crois que c'est peu probable. Il y a
combien de cache : 1 Go ? Ou plus souvent, moins. Et n'oublie
pas que tout ce que tu lis ou écris y passe : les pages Web, la
doc, etc. Or, typiquement, tes bibliothèques vont bien dépasser
ça, ou au moins en être proche. Donc, après l'édition de liens,
il n'y a plus d'en-tête dans la cache.
Où la cache pourrait jouer un rôle, c'est dans le cas des
rebuild complet, où tu rélis <iostream> des milliers de fois,
sans forcement lire ou écrire assez d'autre choses entre temps
pour qu'il soit purgé de la cache. (L'option -pipe de g++
pourrait aider ici, parce qu'elle s'assure que les
« fichiers » intermédiaires sont des pipes, et donc, n'utilise
jamais plus d'un bloc dans la cache.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Pour beaucoup, le compilateur lit des données, puis il les traite.
En plus de mon autre réponse, note qu'on apprécie particulièrement une compilation rapide quand on doit compiler plusieurs fois dans la même journée. Et si jamais tous les sources restent en cache en permanence, il n'y a rien à lire sur le disque dur.
Dans la pratique, je crois que c'est peu probable. Il y a combien de cache : 1 Go ? Ou plus souvent, moins. Et n'oublie pas que tout ce que tu lis ou écris y passe : les pages Web, la doc, etc. Or, typiquement, tes bibliothèques vont bien dépasser ça, ou au moins en être proche. Donc, après l'édition de liens, il n'y a plus d'en-tête dans la cache.
Où la cache pourrait jouer un rôle, c'est dans le cas des rebuild complet, où tu rélis <iostream> des milliers de fois, sans forcement lire ou écrire assez d'autre choses entre temps pour qu'il soit purgé de la cache. (L'option -pipe de g++ pourrait aider ici, parce qu'elle s'assure que les « fichiers » intermédiaires sont des pipes, et donc, n'utilise jamais plus d'un bloc dans la cache.)
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Christophe Lephay
"James Kanze" a écrit dans le message de news:
(Sans doute au moins en partie parce que ça rapporte plus aux pirates de s'attaquer au Windows.) [...]
En effet, la risque de virus dépend surtout de ce qu'on fait avec la machine. En faisant attention, il n'y a pas de raison d'avoir un virus nulle part. Mais ce n'est pas toujours si évident. En tout cas, j'ai vu des problèmes réels de virus sous Windows (mais qui ne m'ont pas touché, parce que je n'ai pas ouvert le courriel), et non sous d'autres systèmes, et ça, bien que je travaille dans les milieux où Unix prédomine.
Le facteur principal de propagation d'un virus, c'est l'ignorance de l'utilisateur. Si on ajoute à cela le fait que windows est largement plus utilisés par les particuliers (plus susceptibles de taper leur numéro de carte bleue), c'est en effet logique que windows soit la cible privilégiée des auteurs de virus et autres crackers.
"James Kanze" <james.kanze@gmail.com> a écrit dans le message de news:
1185262269.594213.39580@o61g2000hsh.googlegroups.com...
(Sans doute au moins en partie parce
que ça rapporte plus aux pirates de s'attaquer au Windows.)
[...]
En effet, la risque de virus dépend surtout de ce qu'on fait
avec la machine. En faisant attention, il n'y a pas de raison
d'avoir un virus nulle part. Mais ce n'est pas toujours si
évident. En tout cas, j'ai vu des problèmes réels de virus sous
Windows (mais qui ne m'ont pas touché, parce que je n'ai pas
ouvert le courriel), et non sous d'autres systèmes, et ça, bien
que je travaille dans les milieux où Unix prédomine.
Le facteur principal de propagation d'un virus, c'est l'ignorance de
l'utilisateur. Si on ajoute à cela le fait que windows est largement plus
utilisés par les particuliers (plus susceptibles de taper leur numéro de
carte bleue), c'est en effet logique que windows soit la cible privilégiée
des auteurs de virus et autres crackers.
(Sans doute au moins en partie parce que ça rapporte plus aux pirates de s'attaquer au Windows.) [...]
En effet, la risque de virus dépend surtout de ce qu'on fait avec la machine. En faisant attention, il n'y a pas de raison d'avoir un virus nulle part. Mais ce n'est pas toujours si évident. En tout cas, j'ai vu des problèmes réels de virus sous Windows (mais qui ne m'ont pas touché, parce que je n'ai pas ouvert le courriel), et non sous d'autres systèmes, et ça, bien que je travaille dans les milieux où Unix prédomine.
Le facteur principal de propagation d'un virus, c'est l'ignorance de l'utilisateur. Si on ajoute à cela le fait que windows est largement plus utilisés par les particuliers (plus susceptibles de taper leur numéro de carte bleue), c'est en effet logique que windows soit la cible privilégiée des auteurs de virus et autres crackers.
