Bon, je suppose que tu as compris que je ne voulais pas dire que le
matériel cher ne tombait pas en panne, hein :)
Ben...Mais j'ai remarqué par exemple que :
-les alims bas de gamme ne fournissent pas les voltages spécifiés,
et fluctuent. Rien de tel pour faire planter un proc.
-les RAM bas de gamme ne fonctionnent pas à la spécification CAS
inscrite dessus fiablement. Un memtest86 avec un réglage CAS agressif le
montre sans équivoque.
-les cartes mères bas de gamme ont des BIOS horriblement buggés, et des
bus PCI au fonctionnement aléatoire (j'ai longtemps eu mon écran qui ne
s'allumait qu'une fois sur 3 au démarrage du PC : problème de BIOS...)
-les cartes graphiques bas de gamme surchauffent et plantent.
-les boitiers bas de gamme sont mal ventilés, le système surchauffe et
plante ou pire fait des erreurs bizarres impossible à reproduire.
Tiens, tout ceci décrit assez exactement mon ordinateur. Il faut
rajouter les disques durs qui fuient et le son qui pue la
friture. Sauf la carte mère c'est une Asus-bidule. "C'est de la
marque" quand même ça, merde. Conclusion la prochaine fois j'irais pas
chez un assembleur. De toute façon j'espère bien que ce sera pas un
PC. Y'a les niagaras de Sun qui me font baver depuis un moment.
Bon, je suppose que tu as compris que je ne voulais pas dire que le
matériel cher ne tombait pas en panne, hein :)
Ben...
Mais j'ai remarqué par exemple que :
-les alims bas de gamme ne fournissent pas les voltages spécifiés,
et fluctuent. Rien de tel pour faire planter un proc.
-les RAM bas de gamme ne fonctionnent pas à la spécification CAS
inscrite dessus fiablement. Un memtest86 avec un réglage CAS agressif le
montre sans équivoque.
-les cartes mères bas de gamme ont des BIOS horriblement buggés, et des
bus PCI au fonctionnement aléatoire (j'ai longtemps eu mon écran qui ne
s'allumait qu'une fois sur 3 au démarrage du PC : problème de BIOS...)
-les cartes graphiques bas de gamme surchauffent et plantent.
-les boitiers bas de gamme sont mal ventilés, le système surchauffe et
plante ou pire fait des erreurs bizarres impossible à reproduire.
Tiens, tout ceci décrit assez exactement mon ordinateur. Il faut
rajouter les disques durs qui fuient et le son qui pue la
friture. Sauf la carte mère c'est une Asus-bidule. "C'est de la
marque" quand même ça, merde. Conclusion la prochaine fois j'irais pas
chez un assembleur. De toute façon j'espère bien que ce sera pas un
PC. Y'a les niagaras de Sun qui me font baver depuis un moment.
Bon, je suppose que tu as compris que je ne voulais pas dire que le
matériel cher ne tombait pas en panne, hein :)
Ben...Mais j'ai remarqué par exemple que :
-les alims bas de gamme ne fournissent pas les voltages spécifiés,
et fluctuent. Rien de tel pour faire planter un proc.
-les RAM bas de gamme ne fonctionnent pas à la spécification CAS
inscrite dessus fiablement. Un memtest86 avec un réglage CAS agressif le
montre sans équivoque.
-les cartes mères bas de gamme ont des BIOS horriblement buggés, et des
bus PCI au fonctionnement aléatoire (j'ai longtemps eu mon écran qui ne
s'allumait qu'une fois sur 3 au démarrage du PC : problème de BIOS...)
-les cartes graphiques bas de gamme surchauffent et plantent.
-les boitiers bas de gamme sont mal ventilés, le système surchauffe et
plante ou pire fait des erreurs bizarres impossible à reproduire.
Tiens, tout ceci décrit assez exactement mon ordinateur. Il faut
rajouter les disques durs qui fuient et le son qui pue la
friture. Sauf la carte mère c'est une Asus-bidule. "C'est de la
marque" quand même ça, merde. Conclusion la prochaine fois j'irais pas
chez un assembleur. De toute façon j'espère bien que ce sera pas un
PC. Y'a les niagaras de Sun qui me font baver depuis un moment.
J'ai marrant j'ai toujours cru que le ventilateur c'était une
plaisanterie. Que les performances dépendent d'un système de
refroidissement aussi primitif ça fait archaïque. Bon, je vais changer
le ventilo aussi, sans lésiner.
J'ai marrant j'ai toujours cru que le ventilateur c'était une
plaisanterie. Que les performances dépendent d'un système de
refroidissement aussi primitif ça fait archaïque. Bon, je vais changer
le ventilo aussi, sans lésiner.
J'ai marrant j'ai toujours cru que le ventilateur c'était une
plaisanterie. Que les performances dépendent d'un système de
refroidissement aussi primitif ça fait archaïque. Bon, je vais changer
le ventilo aussi, sans lésiner.
Je ne sais pas, mais pour mon 2600+ à partir de 60° ça délire
sévère. En tout cas ce sont des chiffres réalistes.
tu ulisises lm_sensors ?
Je ne sais pas, mais pour mon 2600+ à partir de 60° ça délire
sévère. En tout cas ce sont des chiffres réalistes.
tu ulisises lm_sensors ?
Je ne sais pas, mais pour mon 2600+ à partir de 60° ça délire
sévère. En tout cas ce sont des chiffres réalistes.
tu ulisises lm_sensors ?
(quoique je
n'ai toujours pas compris si l'exécution d'opengl impliquait la carte
vidéo ou pas).
(quoique je
n'ai toujours pas compris si l'exécution d'opengl impliquait la carte
vidéo ou pas).
(quoique je
n'ai toujours pas compris si l'exécution d'opengl impliquait la carte
vidéo ou pas).
Montre-moi un seul de tes programmes écrit en C, que je le critique.
Je ne connais pas beaucoup de personnes qui récupèrent les codes
renvoyés par une fonction intrinsèque C (que ce soit malloc() ou un
simple fprintf()). Le simple fait qu'un truc comme :
fprintf(fp, "%sn", chaine);
compile est une absurdité. fprintf renvoie un int et non un void !
Lorsqu'on travaille sur des programmes complexes de plusieurs
centaines de milliers de lignes de codes en C et qu'on essaye de
tracer un segfault aléatoires sur un tel problème, on peste et on y
passe du temps.
Personnellement, j'ai rarement ouvert un debugger en ADA, très
rarement en Fortran,
Montre-moi un seul de tes programmes écrit en C, que je le critique.
Je ne connais pas beaucoup de personnes qui récupèrent les codes
renvoyés par une fonction intrinsèque C (que ce soit malloc() ou un
simple fprintf()). Le simple fait qu'un truc comme :
fprintf(fp, "%sn", chaine);
compile est une absurdité. fprintf renvoie un int et non un void !
Lorsqu'on travaille sur des programmes complexes de plusieurs
centaines de milliers de lignes de codes en C et qu'on essaye de
tracer un segfault aléatoires sur un tel problème, on peste et on y
passe du temps.
Personnellement, j'ai rarement ouvert un debugger en ADA, très
rarement en Fortran,
Montre-moi un seul de tes programmes écrit en C, que je le critique.
Je ne connais pas beaucoup de personnes qui récupèrent les codes
renvoyés par une fonction intrinsèque C (que ce soit malloc() ou un
simple fprintf()). Le simple fait qu'un truc comme :
fprintf(fp, "%sn", chaine);
compile est une absurdité. fprintf renvoie un int et non un void !
Lorsqu'on travaille sur des programmes complexes de plusieurs
centaines de milliers de lignes de codes en C et qu'on essaye de
tracer un segfault aléatoires sur un tel problème, on peste et on y
passe du temps.
Personnellement, j'ai rarement ouvert un debugger en ADA, très
rarement en Fortran,
J'y comprends rien à c'est quoi que vous voulez dire.
Normal.
J'y comprends rien à c'est quoi que vous voulez dire.
Normal.
J'y comprends rien à c'est quoi que vous voulez dire.
Normal.
Le Sat, 06 May 2006 11:14:26 +0000, JKB a écrit :Mais il a un seul défaut... Lorsqu'on parle ADA ou Fortran, on passe
toujours pour des vieux schoques. Les langages en question ont beau
être très bien ficelés, il devient très difficile de trouver un bon
programmeur Fortran ou ADA, alors que des bidouilleurs C, C++, C# et
java, on en trouve à la pelle !
Tu retardes. Aujourd'hui les jeunes apprennent C# et PHP. Java, un peu,
mais c'est dépassé dans l'esprit de beaucoup. C, ils en ont vaguement
fait; C++, c'est strictement réservé aux vieux schnoques, plus personne
n'apprend ça depuis 10 ans.
Le Sat, 06 May 2006 11:14:26 +0000, JKB a écrit :
Mais il a un seul défaut... Lorsqu'on parle ADA ou Fortran, on passe
toujours pour des vieux schoques. Les langages en question ont beau
être très bien ficelés, il devient très difficile de trouver un bon
programmeur Fortran ou ADA, alors que des bidouilleurs C, C++, C# et
java, on en trouve à la pelle !
Tu retardes. Aujourd'hui les jeunes apprennent C# et PHP. Java, un peu,
mais c'est dépassé dans l'esprit de beaucoup. C, ils en ont vaguement
fait; C++, c'est strictement réservé aux vieux schnoques, plus personne
n'apprend ça depuis 10 ans.
Le Sat, 06 May 2006 11:14:26 +0000, JKB a écrit :Mais il a un seul défaut... Lorsqu'on parle ADA ou Fortran, on passe
toujours pour des vieux schoques. Les langages en question ont beau
être très bien ficelés, il devient très difficile de trouver un bon
programmeur Fortran ou ADA, alors que des bidouilleurs C, C++, C# et
java, on en trouve à la pelle !
Tu retardes. Aujourd'hui les jeunes apprennent C# et PHP. Java, un peu,
mais c'est dépassé dans l'esprit de beaucoup. C, ils en ont vaguement
fait; C++, c'est strictement réservé aux vieux schnoques, plus personne
n'apprend ça depuis 10 ans.
Ce qui est d'ailleurs typique des élucubrations françaises, que ce soit
Ada, ou Eiffel ou Caml. Il y a une tradition de bateleurs de foire chez
nous, où on t'explique qu'un langage va tout révolutionner, faire qu'un
programme ne sera jamais faux, qu'on travaillera 10 fois plus vite et
avec 10 fois moins de lignes, qu'on pourra prouver l'exactitude du
programme et toutes autres poudres de perlinpinpin et huiles de serpent.
Ce qui est d'ailleurs typique des élucubrations françaises, que ce soit
Ada, ou Eiffel ou Caml. Il y a une tradition de bateleurs de foire chez
nous, où on t'explique qu'un langage va tout révolutionner, faire qu'un
programme ne sera jamais faux, qu'on travaillera 10 fois plus vite et
avec 10 fois moins de lignes, qu'on pourra prouver l'exactitude du
programme et toutes autres poudres de perlinpinpin et huiles de serpent.
Ce qui est d'ailleurs typique des élucubrations françaises, que ce soit
Ada, ou Eiffel ou Caml. Il y a une tradition de bateleurs de foire chez
nous, où on t'explique qu'un langage va tout révolutionner, faire qu'un
programme ne sera jamais faux, qu'on travaillera 10 fois plus vite et
avec 10 fois moins de lignes, qu'on pourra prouver l'exactitude du
programme et toutes autres poudres de perlinpinpin et huiles de serpent.
On Sat, 6 May 2006, JKB wrote:Montre-moi un seul de tes programmes écrit en C, que je le critique.
Je ne connais pas beaucoup de personnes qui récupèrent les codes
renvoyés par une fonction intrinsèque C (que ce soit malloc() ou un
simple fprintf()). Le simple fait qu'un truc comme :
fprintf(fp, "%sn", chaine);
Ben non. Autant le retour de malloc() est intéressant à tous les coups à
récupérer ("j'ai réussi/j'ai échoué dans mon alloc"), autant connaître le
nombre de caractères imprimés n'est pas souvent très intéressant à
connaître... Il peut y avoir une erreur bien sûr, mais ce sera une erreur
d'affichage. Alors mis à part pour faire décoller des fusées ;-), je ne
vois pas trop l'intérêt de récupérer la sortie de {f|sn|vsn}printf.
compile est une absurdité. fprintf renvoie un int et non un void !
Lorsqu'on travaille sur des programmes complexes de plusieurs
centaines de milliers de lignes de codes en C et qu'on essaye de
tracer un segfault aléatoires sur un tel problème, on peste et on y
passe du temps.
... mais pas à cause d'un printf dont on n'a pas récupéré la sortie.
Personnellement, j'ai rarement ouvert un debugger en ADA, très
rarement en Fortran,
Pardon ? ADA je veux bien te croire, je ne connais pas du tout le langage.
Mais FORTRAN, j'ai plus de mal à le croire... D'autant plus que ce que je
reproche aux programmeurs FORTRAN, c'est de toujours vouloir utiliser
FORTRAN 77, et pas F90, qui améliore quand même pas mal de choses ...
On Sat, 6 May 2006, JKB wrote:
Montre-moi un seul de tes programmes écrit en C, que je le critique.
Je ne connais pas beaucoup de personnes qui récupèrent les codes
renvoyés par une fonction intrinsèque C (que ce soit malloc() ou un
simple fprintf()). Le simple fait qu'un truc comme :
fprintf(fp, "%sn", chaine);
Ben non. Autant le retour de malloc() est intéressant à tous les coups à
récupérer ("j'ai réussi/j'ai échoué dans mon alloc"), autant connaître le
nombre de caractères imprimés n'est pas souvent très intéressant à
connaître... Il peut y avoir une erreur bien sûr, mais ce sera une erreur
d'affichage. Alors mis à part pour faire décoller des fusées ;-), je ne
vois pas trop l'intérêt de récupérer la sortie de {f|sn|vsn}printf.
compile est une absurdité. fprintf renvoie un int et non un void !
Lorsqu'on travaille sur des programmes complexes de plusieurs
centaines de milliers de lignes de codes en C et qu'on essaye de
tracer un segfault aléatoires sur un tel problème, on peste et on y
passe du temps.
... mais pas à cause d'un printf dont on n'a pas récupéré la sortie.
Personnellement, j'ai rarement ouvert un debugger en ADA, très
rarement en Fortran,
Pardon ? ADA je veux bien te croire, je ne connais pas du tout le langage.
Mais FORTRAN, j'ai plus de mal à le croire... D'autant plus que ce que je
reproche aux programmeurs FORTRAN, c'est de toujours vouloir utiliser
FORTRAN 77, et pas F90, qui améliore quand même pas mal de choses ...
On Sat, 6 May 2006, JKB wrote:Montre-moi un seul de tes programmes écrit en C, que je le critique.
Je ne connais pas beaucoup de personnes qui récupèrent les codes
renvoyés par une fonction intrinsèque C (que ce soit malloc() ou un
simple fprintf()). Le simple fait qu'un truc comme :
fprintf(fp, "%sn", chaine);
Ben non. Autant le retour de malloc() est intéressant à tous les coups à
récupérer ("j'ai réussi/j'ai échoué dans mon alloc"), autant connaître le
nombre de caractères imprimés n'est pas souvent très intéressant à
connaître... Il peut y avoir une erreur bien sûr, mais ce sera une erreur
d'affichage. Alors mis à part pour faire décoller des fusées ;-), je ne
vois pas trop l'intérêt de récupérer la sortie de {f|sn|vsn}printf.
compile est une absurdité. fprintf renvoie un int et non un void !
Lorsqu'on travaille sur des programmes complexes de plusieurs
centaines de milliers de lignes de codes en C et qu'on essaye de
tracer un segfault aléatoires sur un tel problème, on peste et on y
passe du temps.
... mais pas à cause d'un printf dont on n'a pas récupéré la sortie.
Personnellement, j'ai rarement ouvert un debugger en ADA, très
rarement en Fortran,
Pardon ? ADA je veux bien te croire, je ne connais pas du tout le langage.
Mais FORTRAN, j'ai plus de mal à le croire... D'autant plus que ce que je
reproche aux programmeurs FORTRAN, c'est de toujours vouloir utiliser
FORTRAN 77, et pas F90, qui améliore quand même pas mal de choses ...
Le 09-05-2006, à propos de
Re: language,
Stéphane Zuckerman écrivait dans fr.comp.os.linux.debats :On Sat, 6 May 2006, JKB wrote:Montre-moi un seul de tes programmes écrit en C, que je le critique.
Je ne connais pas beaucoup de personnes qui récupèrent les codes
renvoyés par une fonction intrinsèque C (que ce soit malloc() ou un
simple fprintf()). Le simple fait qu'un truc comme :
fprintf(fp, "%sn", chaine);
Ben non. Autant le retour de malloc() est intéressant à tous les coups à
récupérer ("j'ai réussi/j'ai échoué dans mon alloc"), autant connaître le
nombre de caractères imprimés n'est pas souvent très intéressant à
connaître... Il peut y avoir une erreur bien sûr, mais ce sera une erreur
d'affichage. Alors mis à part pour faire décoller des fusées ;-), je ne
vois pas trop l'intérêt de récupérer la sortie de {f|sn|vsn}printf.
C'est un simple exemple. Maintenant, dans certains programmes, il
est utile de savoir par exemple que tout ce qu'on voulait écrire
dans un fichier a bien été écrit.
... mais pas à cause d'un printf dont on n'a pas récupéré la sortie.
Et si... Ça m'est déjà arrivé. On écrit un truc, mal écrit dans un
fichier à cause d'un bug bien avant dans le programme en question et
lorsqu'on essaye de relire, le truc se casse la figure.
Pardon ? ADA je veux bien te croire, je ne connais pas du tout le langage.
Mais FORTRAN, j'ai plus de mal à le croire... D'autant plus que ce que je
reproche aux programmeurs FORTRAN, c'est de toujours vouloir utiliser
FORTRAN 77, et pas F90, qui améliore quand même pas mal de choses ...
Autant entre F66 et F77, je suis d'accord, mais la syntaxe du F77
est très bien fichue. Bien au contraire, F90 (et les 95 et 2003)
apportent plein de trucs permettant à un programme de devenir
illisible.
Le 09-05-2006, à propos de
Re: language,
Stéphane Zuckerman écrivait dans fr.comp.os.linux.debats :
On Sat, 6 May 2006, JKB wrote:
Montre-moi un seul de tes programmes écrit en C, que je le critique.
Je ne connais pas beaucoup de personnes qui récupèrent les codes
renvoyés par une fonction intrinsèque C (que ce soit malloc() ou un
simple fprintf()). Le simple fait qu'un truc comme :
fprintf(fp, "%sn", chaine);
Ben non. Autant le retour de malloc() est intéressant à tous les coups à
récupérer ("j'ai réussi/j'ai échoué dans mon alloc"), autant connaître le
nombre de caractères imprimés n'est pas souvent très intéressant à
connaître... Il peut y avoir une erreur bien sûr, mais ce sera une erreur
d'affichage. Alors mis à part pour faire décoller des fusées ;-), je ne
vois pas trop l'intérêt de récupérer la sortie de {f|sn|vsn}printf.
C'est un simple exemple. Maintenant, dans certains programmes, il
est utile de savoir par exemple que tout ce qu'on voulait écrire
dans un fichier a bien été écrit.
... mais pas à cause d'un printf dont on n'a pas récupéré la sortie.
Et si... Ça m'est déjà arrivé. On écrit un truc, mal écrit dans un
fichier à cause d'un bug bien avant dans le programme en question et
lorsqu'on essaye de relire, le truc se casse la figure.
Pardon ? ADA je veux bien te croire, je ne connais pas du tout le langage.
Mais FORTRAN, j'ai plus de mal à le croire... D'autant plus que ce que je
reproche aux programmeurs FORTRAN, c'est de toujours vouloir utiliser
FORTRAN 77, et pas F90, qui améliore quand même pas mal de choses ...
Autant entre F66 et F77, je suis d'accord, mais la syntaxe du F77
est très bien fichue. Bien au contraire, F90 (et les 95 et 2003)
apportent plein de trucs permettant à un programme de devenir
illisible.
Le 09-05-2006, à propos de
Re: language,
Stéphane Zuckerman écrivait dans fr.comp.os.linux.debats :On Sat, 6 May 2006, JKB wrote:Montre-moi un seul de tes programmes écrit en C, que je le critique.
Je ne connais pas beaucoup de personnes qui récupèrent les codes
renvoyés par une fonction intrinsèque C (que ce soit malloc() ou un
simple fprintf()). Le simple fait qu'un truc comme :
fprintf(fp, "%sn", chaine);
Ben non. Autant le retour de malloc() est intéressant à tous les coups à
récupérer ("j'ai réussi/j'ai échoué dans mon alloc"), autant connaître le
nombre de caractères imprimés n'est pas souvent très intéressant à
connaître... Il peut y avoir une erreur bien sûr, mais ce sera une erreur
d'affichage. Alors mis à part pour faire décoller des fusées ;-), je ne
vois pas trop l'intérêt de récupérer la sortie de {f|sn|vsn}printf.
C'est un simple exemple. Maintenant, dans certains programmes, il
est utile de savoir par exemple que tout ce qu'on voulait écrire
dans un fichier a bien été écrit.
... mais pas à cause d'un printf dont on n'a pas récupéré la sortie.
Et si... Ça m'est déjà arrivé. On écrit un truc, mal écrit dans un
fichier à cause d'un bug bien avant dans le programme en question et
lorsqu'on essaye de relire, le truc se casse la figure.
Pardon ? ADA je veux bien te croire, je ne connais pas du tout le langage.
Mais FORTRAN, j'ai plus de mal à le croire... D'autant plus que ce que je
reproche aux programmeurs FORTRAN, c'est de toujours vouloir utiliser
FORTRAN 77, et pas F90, qui améliore quand même pas mal de choses ...
Autant entre F66 et F77, je suis d'accord, mais la syntaxe du F77
est très bien fichue. Bien au contraire, F90 (et les 95 et 2003)
apportent plein de trucs permettant à un programme de devenir
illisible.
