depuis quelques jours, le freeb sur mon pc reboot tout seul.
Ça arrive comme ça... de manière aléatoir. J'ai regarder comme ça tantôt
le résultat de last(1) et il semble que j'ai rebooté... sans en avoir eu
conscience.
Bon, je me demande si je suis seul dans mon ordinateur (ce qui devrait
être le cas!). Par où est-ce que je commence pour vérifier que mon ordi
ne reboot pas par l'action de quelqu'un d'autre. Je ne connais vraiment
pas grand chose au réseau. Un lien sur internet? Liens vers des ports,
appli etc.
On Thu, 18 Nov 2004, "Olivier" == Olivier Cherrier wrote: ..
Olivier> J'ai eu exactement le même prob chez un client. Il s'est Olivier> avéré qu'il y a un bug dans INET6 (toujours 'open', Olivier> d'ailleurs). Essaie de recompiler ton noyal sans INET6 pour Olivier> voir, sauf si tu l'utilises bien sûr.
Ok, je recompile, car je ne me sers pas de INET6.
Olivier> Est-ce cyclique ?
Non. Ça arrive à peu près n'importe quand. Pas de lien entre chaque coups. D'un autre côté, j'ai refait le monde hier soir et j'ai pas encore planté depuis. Mais bon, comme je disais, des fois ça peut faire une journée avant de planté... ou deux.
Si ça ne replante pas, j'ai donc, je pense, réparé. Cependant, si c'est le cas, j'aime pas pensé que mon system s'est détraqué comme ça sans mon intervention. J'ai trouvé sysutils/rkhunter dans les ports et un autre du genre et aussi security/snort. C'est un début.
Merci
-- Serge Gagnon Quebec, Qc, Canada
On Thu, 18 Nov 2004, "Olivier" == Olivier Cherrier wrote:
..
Olivier> J'ai eu exactement le même prob chez un client. Il s'est
Olivier> avéré qu'il y a un bug dans INET6 (toujours 'open',
Olivier> d'ailleurs). Essaie de recompiler ton noyal sans INET6 pour
Olivier> voir, sauf si tu l'utilises bien sûr.
Ok, je recompile, car je ne me sers pas de INET6.
Olivier> Est-ce cyclique ?
Non. Ça arrive à peu près n'importe quand. Pas de lien entre chaque coups.
D'un autre côté, j'ai refait le monde hier soir et j'ai pas encore planté
depuis. Mais bon, comme je disais, des fois ça peut faire une journée
avant de planté... ou deux.
Si ça ne replante pas, j'ai donc, je pense, réparé.
Cependant, si c'est le cas, j'aime pas pensé que mon system s'est
détraqué comme ça sans mon intervention.
J'ai trouvé sysutils/rkhunter dans les ports et un autre du genre et
aussi security/snort. C'est un début.
On Thu, 18 Nov 2004, "Olivier" == Olivier Cherrier wrote: ..
Olivier> J'ai eu exactement le même prob chez un client. Il s'est Olivier> avéré qu'il y a un bug dans INET6 (toujours 'open', Olivier> d'ailleurs). Essaie de recompiler ton noyal sans INET6 pour Olivier> voir, sauf si tu l'utilises bien sûr.
Ok, je recompile, car je ne me sers pas de INET6.
Olivier> Est-ce cyclique ?
Non. Ça arrive à peu près n'importe quand. Pas de lien entre chaque coups. D'un autre côté, j'ai refait le monde hier soir et j'ai pas encore planté depuis. Mais bon, comme je disais, des fois ça peut faire une journée avant de planté... ou deux.
Si ça ne replante pas, j'ai donc, je pense, réparé. Cependant, si c'est le cas, j'aime pas pensé que mon system s'est détraqué comme ça sans mon intervention. J'ai trouvé sysutils/rkhunter dans les ports et un autre du genre et aussi security/snort. C'est un début.
Merci
-- Serge Gagnon Quebec, Qc, Canada
Serge Gagnon
On Thu, 18 Nov 2004, "Arnaud" == Arnaud Boudou wrote: ..
Arnaud> Et que donne un Memtest ?
Je met le résultat de la commande memtest all 1 --log en ligne à ftp://quenix1.dyndns.org/users/serge/memtest.log parce que c'est beaucoup de ligne.
Voilà, merci!
On Thu, 18 Nov 2004, "Arnaud" == Arnaud Boudou wrote:
..
Arnaud> Et que donne un Memtest ?
Je met le résultat de la commande memtest all 1 --log en ligne à
ftp://quenix1.dyndns.org/users/serge/memtest.log
parce que c'est beaucoup de ligne.
On Thu, 18 Nov 2004, "Arnaud" == Arnaud Boudou wrote: ..
Arnaud> Et que donne un Memtest ?
Je met le résultat de la commande memtest all 1 --log en ligne à ftp://quenix1.dyndns.org/users/serge/memtest.log parce que c'est beaucoup de ligne.
Voilà, merci!
Eric Masson
"Serge" == Serge Gagnon writes:
'Lut,
Serge> Non. Ça arrive à peu près n'importe quand. Pas de lien entre Serge> chaque coups.
T'as vérifié la panne thermique ?
Mon K6II 350 m'a alerté sur l'état de son ventilo par ce moyen :/
Éric Masson
-- En effet, les FAQ sont des "conseils d'utilisation" et non des règles à respecter. -+-BC in <http://www.le-gnu.net> Si tu veux du CU, retourne à la FAQ-+-
Serge> Non. Ça arrive à peu près n'importe quand. Pas de lien entre
Serge> chaque coups.
T'as vérifié la panne thermique ?
Mon K6II 350 m'a alerté sur l'état de son ventilo par ce moyen :/
Éric Masson
--
En effet, les FAQ sont des "conseils d'utilisation"
et non des règles à respecter.
-+-BC in <http://www.le-gnu.net> Si tu veux du CU, retourne à la FAQ-+-
Serge> Non. Ça arrive à peu près n'importe quand. Pas de lien entre Serge> chaque coups.
T'as vérifié la panne thermique ?
Mon K6II 350 m'a alerté sur l'état de son ventilo par ce moyen :/
Éric Masson
-- En effet, les FAQ sont des "conseils d'utilisation" et non des règles à respecter. -+-BC in <http://www.le-gnu.net> Si tu veux du CU, retourne à la FAQ-+-
Serge Gagnon
On Thu, 18 Nov 2004, "Eric" == Eric Masson wrote:
"Serge" == Serge Gagnon writes:
Eric> 'Lut,
Serge> Non. Ça arrive à peu près n'importe quand. Pas de lien entre Serge> chaque coups.
Eric> T'as vérifié la panne thermique ?
Eric> Mon K6II 350 m'a alerté sur l'état de son ventilo par ce moyen :/
Non, pour mal faire, j'ai déinstallé xmbmon il y a un mois et demie pour je ne sais quelle raison. Bon là c'est réinstallé et la température semble stable et bonne.
Serge> Non. Ça arrive à peu près n'importe quand. Pas de lien entre
Serge> chaque coups.
Eric> T'as vérifié la panne thermique ?
Eric> Mon K6II 350 m'a alerté sur l'état de son ventilo par ce moyen :/
Non, pour mal faire, j'ai déinstallé xmbmon il y a un mois et demie pour
je ne sais quelle raison. Bon là c'est réinstallé et la température
semble stable et bonne.
Serge> Non. Ça arrive à peu près n'importe quand. Pas de lien entre Serge> chaque coups.
Eric> T'as vérifié la panne thermique ?
Eric> Mon K6II 350 m'a alerté sur l'état de son ventilo par ce moyen :/
Non, pour mal faire, j'ai déinstallé xmbmon il y a un mois et demie pour je ne sais quelle raison. Bon là c'est réinstallé et la température semble stable et bonne.
-- Serge Gagnon Quebec, Qc, Canada
Arnaud Boudou
Je met le résultat de la commande memtest all 1 --log en ligne à ftp://quenix1.dyndns.org/users/serge/memtest.log parce que c'est beaucoup de ligne.
En fait je pensais plus à celui là : http://www.memtest.org/
-- Arnaud Boudou http://www.goddess-gate.com
Je met le résultat de la commande memtest all 1 --log en ligne à
ftp://quenix1.dyndns.org/users/serge/memtest.log
parce que c'est beaucoup de ligne.
En fait je pensais plus à celui là : http://www.memtest.org/
Je met le résultat de la commande memtest all 1 --log en ligne à ftp://quenix1.dyndns.org/users/serge/memtest.log parce que c'est beaucoup de ligne.
En fait je pensais plus à celui là : http://www.memtest.org/
-- Arnaud Boudou http://www.goddess-gate.com
Serge Gagnon
On Thu, 18 Nov 2004, "Arnaud" == Arnaud Boudou wrote:
+> Je met le résultat de la commande memtest all 1 --log en ligne à +> ftp://quenix1.dyndns.org/users/serge/memtest.log parce que c'est +> beaucoup de ligne.
Arnaud> En fait je pensais plus à celui là : http://www.memtest.org/
Je suis désolé, je ne peux donner de réponse. Il semble que j'ai un problème quand je tente de copier memtest sur la disquette:
; sudo dd if'='memtest86+-1.30.bin of'='/dev/fd0 Password: dd: /dev/fd0: Invalid argument 194+1 records in 194+0 records out 99328 bytes transferred in 4.584434 secs (21666 bytes/sec) ;
et puis quand j'éssaie de rebooter avec la disquette, ça dit: loading....... et puis, un prompt comme celui-là _ en bas de l'écran à gauche et il ne se passe plus rien.
Je vais investiguer mes petits problèmes de dd et je verrai ensuite.
Merci pour l'aide que j'ai eu.
-- Serge Gagnon Quebec, Qc, Canada
On Thu, 18 Nov 2004, "Arnaud" == Arnaud Boudou wrote:
+> Je met le résultat de la commande memtest all 1 --log en ligne à
+> ftp://quenix1.dyndns.org/users/serge/memtest.log parce que c'est
+> beaucoup de ligne.
Arnaud> En fait je pensais plus à celui là : http://www.memtest.org/
Je suis désolé, je ne peux donner de réponse.
Il semble que j'ai un problème quand je tente de copier memtest sur la
disquette:
; sudo dd if'='memtest86+-1.30.bin of'='/dev/fd0
Password:
dd: /dev/fd0: Invalid argument
194+1 records in
194+0 records out
99328 bytes transferred in 4.584434 secs (21666 bytes/sec)
;
et puis quand j'éssaie de rebooter avec la disquette, ça dit:
loading.......
et puis, un prompt comme celui-là _ en bas de l'écran à gauche et il ne
se passe plus rien.
Je vais investiguer mes petits problèmes de dd et je verrai ensuite.
On Thu, 18 Nov 2004, "Arnaud" == Arnaud Boudou wrote:
+> Je met le résultat de la commande memtest all 1 --log en ligne à +> ftp://quenix1.dyndns.org/users/serge/memtest.log parce que c'est +> beaucoup de ligne.
Arnaud> En fait je pensais plus à celui là : http://www.memtest.org/
Je suis désolé, je ne peux donner de réponse. Il semble que j'ai un problème quand je tente de copier memtest sur la disquette:
; sudo dd if'='memtest86+-1.30.bin of'='/dev/fd0 Password: dd: /dev/fd0: Invalid argument 194+1 records in 194+0 records out 99328 bytes transferred in 4.584434 secs (21666 bytes/sec) ;
et puis quand j'éssaie de rebooter avec la disquette, ça dit: loading....... et puis, un prompt comme celui-là _ en bas de l'écran à gauche et il ne se passe plus rien.
Je vais investiguer mes petits problèmes de dd et je verrai ensuite.
Merci pour l'aide que j'ai eu.
-- Serge Gagnon Quebec, Qc, Canada
talon
Serge Gagnon wrote:
; sudo dd if'='memtest86+-1.30.bin of'='/dev/fd0 Password: dd: /dev/fd0: Invalid argument 194+1 records in 194+0 records out 99328 bytes transferred in 4.584434 secs (21666 bytes/sec) ;
Essaye simplement cp memtest.. /dev/fd0 Le dd est devenu trés capricieux, il lui faut des blocs complets, je ne sais plus quoi.
--
Michel TALON
Serge Gagnon <ser_gagnon@sympatico.ca> wrote:
; sudo dd if'='memtest86+-1.30.bin of'='/dev/fd0
Password:
dd: /dev/fd0: Invalid argument
194+1 records in
194+0 records out
99328 bytes transferred in 4.584434 secs (21666 bytes/sec)
;
Essaye simplement cp memtest.. /dev/fd0
Le dd est devenu trés capricieux, il lui faut des blocs complets, je ne
sais plus quoi.
; sudo dd if'='memtest86+-1.30.bin of'='/dev/fd0 Password: dd: /dev/fd0: Invalid argument 194+1 records in 194+0 records out 99328 bytes transferred in 4.584434 secs (21666 bytes/sec) ;
Essaye simplement cp memtest.. /dev/fd0 Le dd est devenu trés capricieux, il lui faut des blocs complets, je ne sais plus quoi.
--
Michel TALON
pornin
According to Ralph- :
Mais petit bemol, gcc 3.4.2 est horriblement plus lent que le 2.95 ce qui embetant sur les petites machines (ma gate souffre, mais j'suis passé en compilation sur le P4 du coup pour elle..)
(En plus de demander deux à trois fois plus de cpu, gcc 3.4.2 consomme aussi beaucoup plus de mémoire -- donc, sur une machine faible en RAM, c'est plutôt un facteur 10 qu'on se prend.)
Ça, c'est la faute à l'équipe qui fait gcc et c'est général à l'ensemble des unixoïdes libres. Ils ont réécrit plein de trucs dedans et ont choisi une structure compliquée qui fait que c'est gros et que ça rame. Mais seuls les gcc 3.x ont un support décent du C++ (le 2.95 se débrouille mais il y a des différences de support de certains points du standard, qui font que certains logiciels doivent être compilés avec un gcc 3.x -- et comme l'ABI n'a été stabilisée que dans les 3.x récents, il faut utiliser le même compilateur C++ pour tout). Pour le C, certains ports ne peuvent être compilés qu'avec gcc 3.x (notamment SDL, à cause d'un bout d'assembleur inline qui utilise une syntaxe qui n'existe pas en 2.95).
En bref, ce n'est pas la faute à FreeBSD ; c'est une plaie que FreeBSD subit, tout comme un quelconque Linux. C'est juste que ça se voit beaucoup sous FreeBSD, où on compile beaucoup (à cause des ports et de la tradition -- bien pratique en elle-même -- de l'upgrade à partir des sources).
D'un autre côté, en l'absence de concurrence, gcc est un logiciel dont il est interdit de dire du mal. Enfin, j'espère que fr.comp.os.bsd sera un milieu un peu protégé, mais sur un espace de discussion publique moyen où on a laissé rentrer des adeptes du logiciels libre, toute critique de gcc se fait immédiatement opposer un truc du genre "tu fais mieux peut-être ? Montre-moi le code !". XFree86 était ainsi, jusqu'à ce que X.org apparaisse. Les derniers logiciels encore monopolistiques (ils sont seuls dans leur catégorie, et trop indispensables pour être contournés) sont gcc et les binutils. Mais écrire un compilateur C ou C++, ou un assembleur ou un linker, c'est long, pénible, difficile si on veut faire les choses bien, et interopérer avec les features bizarres des outils GNU n'a rien d'évident : par exemple, le "symbol versioning" qui est très à la mode n'est documenté nulle part (il est plus facile d'interopérer avec le linker de chez Sun, c'est dire !).
--Thomas Pornin
According to Ralph- <-@-.->:
Mais petit bemol, gcc 3.4.2 est horriblement plus lent que le 2.95 ce
qui embetant sur les petites machines (ma gate souffre, mais j'suis
passé en compilation sur le P4 du coup pour elle..)
(En plus de demander deux à trois fois plus de cpu, gcc 3.4.2 consomme
aussi beaucoup plus de mémoire -- donc, sur une machine faible en RAM,
c'est plutôt un facteur 10 qu'on se prend.)
Ça, c'est la faute à l'équipe qui fait gcc et c'est général à l'ensemble
des unixoïdes libres. Ils ont réécrit plein de trucs dedans et ont
choisi une structure compliquée qui fait que c'est gros et que ça
rame. Mais seuls les gcc 3.x ont un support décent du C++ (le 2.95 se
débrouille mais il y a des différences de support de certains points du
standard, qui font que certains logiciels doivent être compilés avec un
gcc 3.x -- et comme l'ABI n'a été stabilisée que dans les 3.x récents,
il faut utiliser le même compilateur C++ pour tout). Pour le C, certains
ports ne peuvent être compilés qu'avec gcc 3.x (notamment SDL, à cause
d'un bout d'assembleur inline qui utilise une syntaxe qui n'existe pas
en 2.95).
En bref, ce n'est pas la faute à FreeBSD ; c'est une plaie que FreeBSD
subit, tout comme un quelconque Linux. C'est juste que ça se voit
beaucoup sous FreeBSD, où on compile beaucoup (à cause des ports et de
la tradition -- bien pratique en elle-même -- de l'upgrade à partir des
sources).
D'un autre côté, en l'absence de concurrence, gcc est un logiciel dont
il est interdit de dire du mal. Enfin, j'espère que fr.comp.os.bsd sera
un milieu un peu protégé, mais sur un espace de discussion publique
moyen où on a laissé rentrer des adeptes du logiciels libre, toute
critique de gcc se fait immédiatement opposer un truc du genre "tu fais
mieux peut-être ? Montre-moi le code !". XFree86 était ainsi, jusqu'à
ce que X.org apparaisse. Les derniers logiciels encore monopolistiques
(ils sont seuls dans leur catégorie, et trop indispensables pour être
contournés) sont gcc et les binutils. Mais écrire un compilateur C ou
C++, ou un assembleur ou un linker, c'est long, pénible, difficile si on
veut faire les choses bien, et interopérer avec les features bizarres
des outils GNU n'a rien d'évident : par exemple, le "symbol versioning"
qui est très à la mode n'est documenté nulle part (il est plus facile
d'interopérer avec le linker de chez Sun, c'est dire !).
Mais petit bemol, gcc 3.4.2 est horriblement plus lent que le 2.95 ce qui embetant sur les petites machines (ma gate souffre, mais j'suis passé en compilation sur le P4 du coup pour elle..)
(En plus de demander deux à trois fois plus de cpu, gcc 3.4.2 consomme aussi beaucoup plus de mémoire -- donc, sur une machine faible en RAM, c'est plutôt un facteur 10 qu'on se prend.)
Ça, c'est la faute à l'équipe qui fait gcc et c'est général à l'ensemble des unixoïdes libres. Ils ont réécrit plein de trucs dedans et ont choisi une structure compliquée qui fait que c'est gros et que ça rame. Mais seuls les gcc 3.x ont un support décent du C++ (le 2.95 se débrouille mais il y a des différences de support de certains points du standard, qui font que certains logiciels doivent être compilés avec un gcc 3.x -- et comme l'ABI n'a été stabilisée que dans les 3.x récents, il faut utiliser le même compilateur C++ pour tout). Pour le C, certains ports ne peuvent être compilés qu'avec gcc 3.x (notamment SDL, à cause d'un bout d'assembleur inline qui utilise une syntaxe qui n'existe pas en 2.95).
En bref, ce n'est pas la faute à FreeBSD ; c'est une plaie que FreeBSD subit, tout comme un quelconque Linux. C'est juste que ça se voit beaucoup sous FreeBSD, où on compile beaucoup (à cause des ports et de la tradition -- bien pratique en elle-même -- de l'upgrade à partir des sources).
D'un autre côté, en l'absence de concurrence, gcc est un logiciel dont il est interdit de dire du mal. Enfin, j'espère que fr.comp.os.bsd sera un milieu un peu protégé, mais sur un espace de discussion publique moyen où on a laissé rentrer des adeptes du logiciels libre, toute critique de gcc se fait immédiatement opposer un truc du genre "tu fais mieux peut-être ? Montre-moi le code !". XFree86 était ainsi, jusqu'à ce que X.org apparaisse. Les derniers logiciels encore monopolistiques (ils sont seuls dans leur catégorie, et trop indispensables pour être contournés) sont gcc et les binutils. Mais écrire un compilateur C ou C++, ou un assembleur ou un linker, c'est long, pénible, difficile si on veut faire les choses bien, et interopérer avec les features bizarres des outils GNU n'a rien d'évident : par exemple, le "symbol versioning" qui est très à la mode n'est documenté nulle part (il est plus facile d'interopérer avec le linker de chez Sun, c'est dire !).
--Thomas Pornin
talon
Thomas Pornin wrote:
Ça, c'est la faute à l'équipe qui fait gcc et c'est général à l'ensemble des unixoïdes libres. Ils ont réécrit plein de trucs dedans et ont choisi une structure compliquée qui fait que c'est gros et que ça rame. Mais seuls les gcc 3.x ont un support décent du C++ (le 2.95 se débrouille mais il y a des différences de support de certains points du standard, qui font que certains logiciels doivent être compilés avec un
Outre le problème du C++, je vois surtout l'optimiseur qui a fait des progrés considérables avec gcc3. Sur des programmes de calcul, j'ai vu le compilateur Intel produire des exécutables jusqu'à deux fois plus rapides que gcc2. Avec un gcc3 récent l'écart s'est considérablement réduit. C'est clair que cette optimisation énormément améliorée prend du temps de compilation. Aprés tout la compilation on ne la fait qu'une seule fois, et avec des machines comme l'Athlon64 elle finit par passer rapidement. A la rigueur il y a des trucs pour rendre la compilation plus rapide pour les gens qui en font beaucoup, genre distcc. Par contre optimiser au maximum bénéficie tout le temps, à tout le monde. La complexité dont tu parles, c'est aussi en grande partie le prix à payer pour avoir un compilateur multi architectures, et qui peut faire la compilation croisée de toutes ces architectures. Et ça c'est un autre avantage décisif de gcc. Icc peut trés bien compiler plus rapidement et produire des exécutables plus rapides, il ne doit se soucier que de gérer une seule architecture.
--
Michel TALON
Thomas Pornin <pornin@nerim.net> wrote:
Ça, c'est la faute à l'équipe qui fait gcc et c'est général à l'ensemble
des unixoïdes libres. Ils ont réécrit plein de trucs dedans et ont
choisi une structure compliquée qui fait que c'est gros et que ça
rame. Mais seuls les gcc 3.x ont un support décent du C++ (le 2.95 se
débrouille mais il y a des différences de support de certains points du
standard, qui font que certains logiciels doivent être compilés avec un
Outre le problème du C++, je vois surtout l'optimiseur qui a fait
des progrés considérables avec gcc3. Sur des programmes de calcul,
j'ai vu le compilateur Intel produire des exécutables jusqu'à deux fois
plus rapides que gcc2. Avec un gcc3 récent l'écart s'est
considérablement réduit. C'est clair que cette optimisation énormément
améliorée prend du temps de compilation. Aprés tout la compilation on
ne la fait qu'une seule fois, et avec des machines comme l'Athlon64
elle finit par passer rapidement. A la rigueur il y a des trucs
pour rendre la compilation plus rapide pour les gens qui en font
beaucoup, genre distcc. Par contre optimiser au maximum bénéficie
tout le temps, à tout le monde. La complexité dont tu parles, c'est
aussi en grande partie le prix à payer pour avoir un compilateur
multi architectures, et qui peut faire la compilation croisée de toutes
ces architectures. Et ça c'est un autre avantage décisif de gcc.
Icc peut trés bien compiler plus rapidement et produire des exécutables
plus rapides, il ne doit se soucier que de gérer une seule
architecture.
Ça, c'est la faute à l'équipe qui fait gcc et c'est général à l'ensemble des unixoïdes libres. Ils ont réécrit plein de trucs dedans et ont choisi une structure compliquée qui fait que c'est gros et que ça rame. Mais seuls les gcc 3.x ont un support décent du C++ (le 2.95 se débrouille mais il y a des différences de support de certains points du standard, qui font que certains logiciels doivent être compilés avec un
Outre le problème du C++, je vois surtout l'optimiseur qui a fait des progrés considérables avec gcc3. Sur des programmes de calcul, j'ai vu le compilateur Intel produire des exécutables jusqu'à deux fois plus rapides que gcc2. Avec un gcc3 récent l'écart s'est considérablement réduit. C'est clair que cette optimisation énormément améliorée prend du temps de compilation. Aprés tout la compilation on ne la fait qu'une seule fois, et avec des machines comme l'Athlon64 elle finit par passer rapidement. A la rigueur il y a des trucs pour rendre la compilation plus rapide pour les gens qui en font beaucoup, genre distcc. Par contre optimiser au maximum bénéficie tout le temps, à tout le monde. La complexité dont tu parles, c'est aussi en grande partie le prix à payer pour avoir un compilateur multi architectures, et qui peut faire la compilation croisée de toutes ces architectures. Et ça c'est un autre avantage décisif de gcc. Icc peut trés bien compiler plus rapidement et produire des exécutables plus rapides, il ne doit se soucier que de gérer une seule architecture.
--
Michel TALON
Eric Masson
"Michel" == Michel Talon writes:
'Lut,
Michel> Icc peut trés bien compiler plus rapidement et produire des Michel> exécutables plus rapides, il ne doit se soucier que de gérer Michel> une seule architecture.
3 : ia32, ia32e, ia64
Éric Masson
--
et me dis quil y a eu une merde avec le serveur truc machin et que ca a fait un gros server crash. OU ets la merde????? Fallait choisir le serveur bidule, c'est pour ça.
-+- EJ in guide du linuxien pervers - "Tout ça c'est de la bidouille" -+-
"Michel" == Michel Talon <talon@lpthe.jussieu.fr> writes:
'Lut,
Michel> Icc peut trés bien compiler plus rapidement et produire des
Michel> exécutables plus rapides, il ne doit se soucier que de gérer
Michel> une seule architecture.
3 : ia32, ia32e, ia64
Éric Masson
--
et me dis quil y a eu une merde avec le serveur truc machin et que ca a
fait un gros server crash. OU ets la merde?????
Fallait choisir le serveur bidule, c'est pour ça.
-+- EJ in guide du linuxien pervers - "Tout ça c'est de la bidouille" -+-
Michel> Icc peut trés bien compiler plus rapidement et produire des Michel> exécutables plus rapides, il ne doit se soucier que de gérer Michel> une seule architecture.
3 : ia32, ia32e, ia64
Éric Masson
--
et me dis quil y a eu une merde avec le serveur truc machin et que ca a fait un gros server crash. OU ets la merde????? Fallait choisir le serveur bidule, c'est pour ça.
-+- EJ in guide du linuxien pervers - "Tout ça c'est de la bidouille" -+-
