je faisais état il y a quelques jours sur ce même forum d'une instabilité
chronique de ma mdk 10, demandant comment diagnostiquer la source du
problème. On m'a conseillé de surveiller mes logs, de vérifier les progs
lancés par cron, et éventuellement de changer d'environnement graphique.
D'habitude j'utilise kde, donc j'en ai profité pour découvrir xfce 4 (très
sympa), mais j'ai toujours des plantages inopinés et bizarres de
programmes.
J'ai vérifié pour cron : il ne lancait aucun programme, donc j'en ai profité
pour le désactiver.
Restent les logs. J'ai cru repérer un truc lié à gconfd à chaque plantage de
programme, mais je n'en suis pas certain : à peu près au moment où plante
un programme, j'ai ces séries de lignes dans mon log système :
Aug 4 23:44:20 olivier gconfd (root-6540): démarrage (version 2.4.0.1), pid
6540 utilisateur « root »
Aug 4 23:44:20 olivier gconfd (root-6540): Adresse
« xml:readonly:/etc/gconf/gconf.xml.mandatory » résolue vers une source de
configuration en lecture seule à la position 0
Aug 4 23:44:20 olivier gconfd (root-6540): Adresse
« xml:readwrite:/root/.gconf » résolue vers une source de configuration
enregistrable à la position 1
Aug 4 23:44:20 olivier gconfd (root-6540): Adresse
« xml:readonly:/etc/gconf/gconf.xml.defaults » résolue vers une source de
configuration en lecture seule à la position 2
puis peu après :
Aug 4 23:46:20 olivier gconfd (root-6540): Le serveur GConf n'est pas en
cours d'utilisation, arrêt.
Aug 4 23:46:20 olivier gconfd (root-6540): Sortie
Est-il possible que ce bazar soit effectivement la cause de mes déboires ?
Quelqu'un peut-il m'éclairer là-dessus ? Autre souci : je ne trouve pas
gconf dans la liste des service (en supposant que le d de gconfd indique
qu'il s'agit d'un service) ?
Je te conseille de choisir une grosse applis en C ou c++ (le noyau c'est bon). Rebooter en mode console uniquement, et lancer des compils en boucles avec -j comme option pour make (make -j). Si ca plante de maniere aleatoire et bisare lors des compils, alors il est fort probable que ce soit hard...
Sans aller jusqu'à une grosse appli, je me rappelle avoir compilé il y a deux ou trois semaines quelques libs et programmes pour les essayer et avoir rencontré des plantages réguliers de la compil. J'avais à chaque fois le même message d'erreur me demandant de faire un rapport de bug sur gcc, mais en relançant make sans me soucier de ce message, il finissait par terminer la compil correctement. Pour un même soft, les plantages sur plusieurs compils différentes intervenaient à des moments différents. Est-ce que ça peut être significatif (j'étais sous KDE à ce moment) ?
Alors tu as bien un probleme hard. C'est significatif a 99%. Lis imperativement le Signal 11 HOWTO: http://www.linux-france.org/article/sig11-fr/
Autre test qui marche bien chez moi quand j'ai des problemes hards: Prends un gros fichier (plusieurs mega) bzip le et bunzip ensuite... Si ca marche pas ca confirmera independemment de gcc.
Si c'est ca, bien reste plus qu'a trouver qui est responsable. Chez moi ca a ete: - Un disque dur mort - Une carte video qui deconne - Des peripheriques scsi bisares.
Dans le 1% qui serait pas hard, il reste un bug dans le noyau ou un pilote. Si vraiment tu as des doutes, trouve 100Mo pour faire une partition de test avec une install differente et un peu de scratch pour faire tes compil gcc ;-)
Bon courage.
Yannick
-- _/ Yannick Patois ___________________________________________________ | web: http://feelingsurfer.net/garp/ | Garp sur irc undernet | | email: | | | ATTAC dans le Pays de Gex: http://attacgex.ouvaton.org |
Olivier Thiery wrote:
Yannick Patois wrote:
Je te conseille de choisir une grosse applis en C ou c++ (le noyau c'est
bon).
Rebooter en mode console uniquement, et lancer des compils en boucles
avec -j comme option pour make (make -j).
Si ca plante de maniere aleatoire et bisare lors des compils, alors il
est fort probable que ce soit hard...
Sans aller jusqu'à une grosse appli, je me rappelle avoir compilé il y a
deux ou trois semaines quelques libs et programmes pour les essayer et
avoir rencontré des plantages réguliers de la compil. J'avais à chaque fois
le même message d'erreur me demandant de faire un rapport de bug sur gcc,
mais en relançant make sans me soucier de ce message, il finissait par
terminer la compil correctement. Pour un même soft, les plantages sur
plusieurs compils différentes intervenaient à des moments différents.
Est-ce que ça peut être significatif (j'étais sous KDE à ce moment) ?
Alors tu as bien un probleme hard. C'est significatif a 99%.
Lis imperativement le Signal 11 HOWTO:
http://www.linux-france.org/article/sig11-fr/
Autre test qui marche bien chez moi quand j'ai des problemes hards:
Prends un gros fichier (plusieurs mega) bzip le et bunzip ensuite... Si
ca marche pas ca confirmera independemment de gcc.
Si c'est ca, bien reste plus qu'a trouver qui est responsable. Chez moi
ca a ete:
- Un disque dur mort
- Une carte video qui deconne
- Des peripheriques scsi bisares.
Dans le 1% qui serait pas hard, il reste un bug dans le noyau ou un
pilote. Si vraiment tu as des doutes, trouve 100Mo pour faire une
partition de test avec une install differente et un peu de scratch pour
faire tes compil gcc ;-)
Bon courage.
Yannick
--
_/ Yannick Patois ___________________________________________________
| web: http://feelingsurfer.net/garp/ | Garp sur irc undernet |
| email: patois@calvix.org | |
| ATTAC dans le Pays de Gex: http://attacgex.ouvaton.org |
Je te conseille de choisir une grosse applis en C ou c++ (le noyau c'est bon). Rebooter en mode console uniquement, et lancer des compils en boucles avec -j comme option pour make (make -j). Si ca plante de maniere aleatoire et bisare lors des compils, alors il est fort probable que ce soit hard...
Sans aller jusqu'à une grosse appli, je me rappelle avoir compilé il y a deux ou trois semaines quelques libs et programmes pour les essayer et avoir rencontré des plantages réguliers de la compil. J'avais à chaque fois le même message d'erreur me demandant de faire un rapport de bug sur gcc, mais en relançant make sans me soucier de ce message, il finissait par terminer la compil correctement. Pour un même soft, les plantages sur plusieurs compils différentes intervenaient à des moments différents. Est-ce que ça peut être significatif (j'étais sous KDE à ce moment) ?
Alors tu as bien un probleme hard. C'est significatif a 99%. Lis imperativement le Signal 11 HOWTO: http://www.linux-france.org/article/sig11-fr/
Autre test qui marche bien chez moi quand j'ai des problemes hards: Prends un gros fichier (plusieurs mega) bzip le et bunzip ensuite... Si ca marche pas ca confirmera independemment de gcc.
Si c'est ca, bien reste plus qu'a trouver qui est responsable. Chez moi ca a ete: - Un disque dur mort - Une carte video qui deconne - Des peripheriques scsi bisares.
Dans le 1% qui serait pas hard, il reste un bug dans le noyau ou un pilote. Si vraiment tu as des doutes, trouve 100Mo pour faire une partition de test avec une install differente et un peu de scratch pour faire tes compil gcc ;-)
Bon courage.
Yannick
-- _/ Yannick Patois ___________________________________________________ | web: http://feelingsurfer.net/garp/ | Garp sur irc undernet | | email: | | | ATTAC dans le Pays de Gex: http://attacgex.ouvaton.org |
g.patel
On Thu, 05 Aug 2004 16:18:18 +0200, Olivier Thiery wrote:
Sans aller jusqu'à une grosse appli, je me rappelle avoir compilé il y a deux ou trois semaines quelques libs et programmes pour les essayer et avoir rencontré des plantages réguliers de la compil. J'avais à chaque fois le même message d'erreur me demandant de faire un rapport de bug sur gcc, mais en relançant make sans me soucier de ce message, il finissait par terminer la compil correctement. Pour un même soft, les plantages sur plusieurs compils différentes intervenaient à des moments différents. Est-ce que ça peut être significatif
c'est meme assez typique. Voir la configuration de la mémoire dans le Bios; essayer de baisser la vitesse d'accès; ou bien carrément essayer des barettes de marque différente.
Gérard Patel
On Thu, 05 Aug 2004 16:18:18 +0200, Olivier Thiery
<olivierthiery@free.fr> wrote:
Sans aller jusqu'à une grosse appli, je me rappelle avoir compilé il y a
deux ou trois semaines quelques libs et programmes pour les essayer et
avoir rencontré des plantages réguliers de la compil. J'avais à chaque fois
le même message d'erreur me demandant de faire un rapport de bug sur gcc,
mais en relançant make sans me soucier de ce message, il finissait par
terminer la compil correctement. Pour un même soft, les plantages sur
plusieurs compils différentes intervenaient à des moments différents.
Est-ce que ça peut être significatif
c'est meme assez typique.
Voir la configuration de la mémoire dans le Bios; essayer de baisser
la vitesse d'accès; ou bien carrément essayer des barettes
de marque différente.
On Thu, 05 Aug 2004 16:18:18 +0200, Olivier Thiery wrote:
Sans aller jusqu'à une grosse appli, je me rappelle avoir compilé il y a deux ou trois semaines quelques libs et programmes pour les essayer et avoir rencontré des plantages réguliers de la compil. J'avais à chaque fois le même message d'erreur me demandant de faire un rapport de bug sur gcc, mais en relançant make sans me soucier de ce message, il finissait par terminer la compil correctement. Pour un même soft, les plantages sur plusieurs compils différentes intervenaient à des moments différents. Est-ce que ça peut être significatif
c'est meme assez typique. Voir la configuration de la mémoire dans le Bios; essayer de baisser la vitesse d'accès; ou bien carrément essayer des barettes de marque différente.
Gérard Patel
Olivier Thiery
Merci pour toutes ces réponses utiles.
Yannick Patois wrote:
Je te conseille de choisir une grosse applis en C ou c++ (le noyau c'est bon). Rebooter en mode console uniquement, et lancer des compils en boucles avec -j comme option pour make (make -j). Si ca plante de maniere aleatoire et bisare lors des compils, alors il est fort probable que ce soit hard...
Sans aller jusqu'à une grosse appli, je me rappelle avoir compilé il y a deux ou trois semaines quelques libs et programmes pour les essayer et avoir rencontré des plantages réguliers de la compil. J'avais à chaque fois le même message d'erreur me demandant de faire un rapport de bug sur gcc, mais en relançant make sans me soucier de ce message, il finissait par terminer la compil correctement. Pour un même soft, les plantages sur plusieurs compils différentes intervenaient à des moments différents. Est-ce que ça peut être significatif (j'étais sous KDE à ce moment) ?
Olivier
Merci pour toutes ces réponses utiles.
Yannick Patois wrote:
Je te conseille de choisir une grosse applis en C ou c++ (le noyau c'est
bon).
Rebooter en mode console uniquement, et lancer des compils en boucles
avec -j comme option pour make (make -j).
Si ca plante de maniere aleatoire et bisare lors des compils, alors il
est fort probable que ce soit hard...
Sans aller jusqu'à une grosse appli, je me rappelle avoir compilé il y a
deux ou trois semaines quelques libs et programmes pour les essayer et
avoir rencontré des plantages réguliers de la compil. J'avais à chaque fois
le même message d'erreur me demandant de faire un rapport de bug sur gcc,
mais en relançant make sans me soucier de ce message, il finissait par
terminer la compil correctement. Pour un même soft, les plantages sur
plusieurs compils différentes intervenaient à des moments différents.
Est-ce que ça peut être significatif (j'étais sous KDE à ce moment) ?
Je te conseille de choisir une grosse applis en C ou c++ (le noyau c'est bon). Rebooter en mode console uniquement, et lancer des compils en boucles avec -j comme option pour make (make -j). Si ca plante de maniere aleatoire et bisare lors des compils, alors il est fort probable que ce soit hard...
Sans aller jusqu'à une grosse appli, je me rappelle avoir compilé il y a deux ou trois semaines quelques libs et programmes pour les essayer et avoir rencontré des plantages réguliers de la compil. J'avais à chaque fois le même message d'erreur me demandant de faire un rapport de bug sur gcc, mais en relançant make sans me soucier de ce message, il finissait par terminer la compil correctement. Pour un même soft, les plantages sur plusieurs compils différentes intervenaient à des moments différents. Est-ce que ça peut être significatif (j'étais sous KDE à ce moment) ?
Olivier
Nicolas George
Yannick Patois wrote in message <cetfc1$qsf$:
Lis imperativement le Signal 11 HOWTO: http://www.linux-france.org/article/sig11-fr/
Scandale, <URL: http://www.linux-france.org/article/sig11-fr/sig11-fr-15.html > ne signale même pas RUMT <URL: http://www.eleves.ens.fr/home/george/info/prg/rumt.html >.
Yannick Patois wrote in message <cetfc1$qsf$1@sunnews.cern.ch>:
Lis imperativement le Signal 11 HOWTO:
http://www.linux-france.org/article/sig11-fr/
Scandale, <URL:
http://www.linux-france.org/article/sig11-fr/sig11-fr-15.html > ne
signale même pas RUMT <URL:
http://www.eleves.ens.fr/home/george/info/prg/rumt.html >.
Lis imperativement le Signal 11 HOWTO: http://www.linux-france.org/article/sig11-fr/
Scandale, <URL: http://www.linux-france.org/article/sig11-fr/sig11-fr-15.html > ne signale même pas RUMT <URL: http://www.eleves.ens.fr/home/george/info/prg/rumt.html >.
viphakoneniko
Le gros du pb, reste que les gens commencent à utiliser leur distrib, à tout paramétrer, avant d'avoir fait toutes les mises à jour. Perso, la première chose que je fais après l'install, c la mise à jour complète.
Ainsi, la Mandrake 10.0 Official est très stable actuellement, avec le noyau 2.6.3-15mdk. Et avec les drivers NVIDIA 6106 les tous derniers, c encore mieux.
Par ailleurs, et cela reste un pb majeur pour Linux selon moi, c'est la diversité des configurations possibles avec un PC qui font apparaitre le manque crucial de support matériel de cet OS. Ya qu'à voir, ça marche chez certains, et d'autres qui ont un composant légèrement différent, ça marche plus, ou c instable. Faut vraiment que cela évolue si Linux veut être crédible.
Sinon, cet OS est vraiment génial, dès qu'on a le matos qui faut :) A nous de favoriser les vendeurs de matos qui sont supportés, cela limite la casse pour les utilisateurs (perso maintenant je n'achète que du matos dont je sais que cela a été testé et que cela marche nickel) et pousse à développer pour linux également.
Velà mon humble avis.
Le gros du pb, reste que les gens commencent à utiliser leur distrib,
à tout paramétrer, avant d'avoir fait toutes les mises à jour.
Perso, la première chose que je fais après l'install, c la mise à jour
complète.
Ainsi, la Mandrake 10.0 Official est très stable actuellement, avec le
noyau 2.6.3-15mdk. Et avec les drivers NVIDIA 6106 les tous derniers,
c encore mieux.
Par ailleurs, et cela reste un pb majeur pour Linux selon moi, c'est
la diversité des configurations possibles avec un PC qui font
apparaitre le manque crucial de support matériel de cet OS.
Ya qu'à voir, ça marche chez certains, et d'autres qui ont un
composant légèrement différent, ça marche plus, ou c instable.
Faut vraiment que cela évolue si Linux veut être crédible.
Sinon, cet OS est vraiment génial, dès qu'on a le matos qui faut :)
A nous de favoriser les vendeurs de matos qui sont supportés, cela
limite la casse pour les utilisateurs (perso maintenant je n'achète
que du matos dont je sais que cela a été testé et que cela marche
nickel) et pousse à développer pour linux également.
Le gros du pb, reste que les gens commencent à utiliser leur distrib, à tout paramétrer, avant d'avoir fait toutes les mises à jour. Perso, la première chose que je fais après l'install, c la mise à jour complète.
Ainsi, la Mandrake 10.0 Official est très stable actuellement, avec le noyau 2.6.3-15mdk. Et avec les drivers NVIDIA 6106 les tous derniers, c encore mieux.
Par ailleurs, et cela reste un pb majeur pour Linux selon moi, c'est la diversité des configurations possibles avec un PC qui font apparaitre le manque crucial de support matériel de cet OS. Ya qu'à voir, ça marche chez certains, et d'autres qui ont un composant légèrement différent, ça marche plus, ou c instable. Faut vraiment que cela évolue si Linux veut être crédible.
Sinon, cet OS est vraiment génial, dès qu'on a le matos qui faut :) A nous de favoriser les vendeurs de matos qui sont supportés, cela limite la casse pour les utilisateurs (perso maintenant je n'achète que du matos dont je sais que cela a été testé et que cela marche nickel) et pousse à développer pour linux également.
Velà mon humble avis.
mykey
Bonjour
Mdk 10 instable? non certainement pas. mais peut-être avec des programmes bogués, ça oui!
J'ai la 9.2, j'adore (je préfère à la 9.1 aussi)!
J'ai essayé mdk 10.0, ça m'a déplu. A peine 10 minutes d'utilisations de KDE 3.2, la nouvelle version j'ai constaté nombre de bugs!
Par exemple, pour fermer/redémarrer/éteindre, plus moyen de double-cliquer sur le champ, il faut passer par le bouton OK.
Autre truc *mega agassant*: Konqueror, dans cette version, il y a vait 1 seul bug agassant. Alors je m'explique: j'ouvre une 1ère fenêtre konqueror, ensuite une 2ème et même une 3ème. Si maintenant une erreur se produit sur la 3ème (exemple, erreur copie de fichiers) l'erreur devrait s'afficher sur cette 3ème, mais en fait non. Elle s'affiche toujours (toutes les erreurs s'affichent) sur la -1ère- fenêtre!
Très agassant quand il faut allé recliqué sur la 1ère fenêtre qui se trouve sur un autre bureau pour valider cette erreur. En plus, il n'y a pas de focus sur l'erreur c'est pour ça que c'était agassant.
Mais il y a des trucs (beaucoup de trucs) mieux fait sous KDE 3.2 que sous la 3.1.
Donc en fin de compte, MDK10 c'est bien, mais c'est KDE3.2 qui m'agassait. Et toujours impossible de passer à Gnome, j'ai des fonctionnalités beaucoup plus intéressantes sous KDE :-(
A présent je suis toujours sous ma 9.2, avec aucun problème. J'adore :)
Au revoir, et merci d'avoir lu mes quelques commentaires. -- Registered Linux User #361637 <http://counter.li.org/> <http://mykey57.free.fr/>
Bonjour
Mdk 10 instable? non certainement pas.
mais peut-être avec des programmes bogués, ça oui!
J'ai la 9.2, j'adore (je préfère à la 9.1 aussi)!
J'ai essayé mdk 10.0, ça m'a déplu.
A peine 10 minutes d'utilisations de KDE 3.2, la nouvelle version j'ai
constaté nombre de bugs!
Par exemple, pour fermer/redémarrer/éteindre, plus moyen de
double-cliquer sur le champ, il faut passer par le bouton OK.
Autre truc *mega agassant*: Konqueror, dans cette version, il y a vait 1
seul bug agassant. Alors je m'explique: j'ouvre une 1ère fenêtre
konqueror, ensuite une 2ème et même une 3ème. Si maintenant une erreur
se produit sur la 3ème (exemple, erreur copie de fichiers) l'erreur
devrait s'afficher sur cette 3ème, mais en fait non. Elle s'affiche
toujours (toutes les erreurs s'affichent) sur la -1ère- fenêtre!
Très agassant quand il faut allé recliqué sur la 1ère fenêtre qui se
trouve sur un autre bureau pour valider cette erreur. En plus, il n'y a
pas de focus sur l'erreur c'est pour ça que c'était agassant.
Mais il y a des trucs (beaucoup de trucs) mieux fait sous KDE 3.2 que
sous la 3.1.
Donc en fin de compte, MDK10 c'est bien, mais c'est KDE3.2 qui
m'agassait. Et toujours impossible de passer à Gnome, j'ai des
fonctionnalités beaucoup plus intéressantes sous KDE :-(
A présent je suis toujours sous ma 9.2, avec aucun problème. J'adore :)
Au revoir, et merci d'avoir lu mes quelques commentaires.
--
Registered Linux User #361637 <http://counter.li.org/>
<http://mykey57.free.fr/>
Mdk 10 instable? non certainement pas. mais peut-être avec des programmes bogués, ça oui!
J'ai la 9.2, j'adore (je préfère à la 9.1 aussi)!
J'ai essayé mdk 10.0, ça m'a déplu. A peine 10 minutes d'utilisations de KDE 3.2, la nouvelle version j'ai constaté nombre de bugs!
Par exemple, pour fermer/redémarrer/éteindre, plus moyen de double-cliquer sur le champ, il faut passer par le bouton OK.
Autre truc *mega agassant*: Konqueror, dans cette version, il y a vait 1 seul bug agassant. Alors je m'explique: j'ouvre une 1ère fenêtre konqueror, ensuite une 2ème et même une 3ème. Si maintenant une erreur se produit sur la 3ème (exemple, erreur copie de fichiers) l'erreur devrait s'afficher sur cette 3ème, mais en fait non. Elle s'affiche toujours (toutes les erreurs s'affichent) sur la -1ère- fenêtre!
Très agassant quand il faut allé recliqué sur la 1ère fenêtre qui se trouve sur un autre bureau pour valider cette erreur. En plus, il n'y a pas de focus sur l'erreur c'est pour ça que c'était agassant.
Mais il y a des trucs (beaucoup de trucs) mieux fait sous KDE 3.2 que sous la 3.1.
Donc en fin de compte, MDK10 c'est bien, mais c'est KDE3.2 qui m'agassait. Et toujours impossible de passer à Gnome, j'ai des fonctionnalités beaucoup plus intéressantes sous KDE :-(
A présent je suis toujours sous ma 9.2, avec aucun problème. J'adore :)
Au revoir, et merci d'avoir lu mes quelques commentaires. -- Registered Linux User #361637 <http://counter.li.org/> <http://mykey57.free.fr/>
Olivier Thiery
Je voulais vous remercier pour vos conseils : j'ai viré toutes mes barrettes de ram défectueuses (après seulement un an et demi de fonctionnement, ça me dégoûte un peu des assembleurs) pour un machin garanti 10 ans, et ça marche maintenant nickel. Je peux garder ma mdk 10 (ouf, je l'aimais bien au fond)
Olivier
Je voulais vous remercier pour vos conseils : j'ai viré toutes mes barrettes
de ram défectueuses (après seulement un an et demi de fonctionnement, ça me
dégoûte un peu des assembleurs) pour un machin garanti 10 ans, et ça marche
maintenant nickel. Je peux garder ma mdk 10 (ouf, je l'aimais bien au fond)
Je voulais vous remercier pour vos conseils : j'ai viré toutes mes barrettes de ram défectueuses (après seulement un an et demi de fonctionnement, ça me dégoûte un peu des assembleurs) pour un machin garanti 10 ans, et ça marche maintenant nickel. Je peux garder ma mdk 10 (ouf, je l'aimais bien au fond)
Olivier
Txo
Le Fri, 06 Aug 2004 17:16:26 +0200, Olivier Thiery a écrit :
j'ai viré toutes mes barrettes de ram défectueuses (après seulement un an et demi de fonctionnement, ça me dégoûte un peu des assembleurs)
Les assembleurs ne sont pas toujours responsables. J'en connais un qui a fini par contrôler toutes les pièces qu'il reçoit pour éviter que les clients fassent eux même le test.
Les prix de plus en plus bas font que les fabriquants réduisent à l'extrême le contrôle de qualité de ce qu'ils fabriquent.
-- -+- Dominique Marin http://txodom.free.fr -+- «Les génies sont des êtres qui donneront des idées aux crétins qui viendront vingt ans plus tard.» -+- L.Aragon -+-
Le Fri, 06 Aug 2004 17:16:26 +0200, Olivier Thiery a écrit :
j'ai viré toutes mes barrettes
de ram défectueuses (après seulement un an et demi de fonctionnement, ça me
dégoûte un peu des assembleurs)
Les assembleurs ne sont pas toujours responsables. J'en connais un qui a
fini par contrôler toutes les pièces qu'il reçoit pour éviter que les
clients fassent eux même le test.
Les prix de plus en plus bas font que les fabriquants réduisent à
l'extrême le contrôle de qualité de ce qu'ils fabriquent.
--
-+- Dominique Marin http://txodom.free.fr -+-
«Les génies sont des êtres qui donneront des idées
aux crétins qui viendront vingt ans plus tard.»
-+- L.Aragon -+-
Le Fri, 06 Aug 2004 17:16:26 +0200, Olivier Thiery a écrit :
j'ai viré toutes mes barrettes de ram défectueuses (après seulement un an et demi de fonctionnement, ça me dégoûte un peu des assembleurs)
Les assembleurs ne sont pas toujours responsables. J'en connais un qui a fini par contrôler toutes les pièces qu'il reçoit pour éviter que les clients fassent eux même le test.
Les prix de plus en plus bas font que les fabriquants réduisent à l'extrême le contrôle de qualité de ce qu'ils fabriquent.
-- -+- Dominique Marin http://txodom.free.fr -+- «Les génies sont des êtres qui donneront des idées aux crétins qui viendront vingt ans plus tard.» -+- L.Aragon -+-
Jerome Lambert
Le Fri, 06 Aug 2004 21:22:55 +0200, Txo a écrit : (...)
Les assembleurs ne sont pas toujours responsables. J'en connais un qui a fini par contrôler toutes les pièces qu'il reçoit pour éviter que les clients fassent eux même le test.
Les prix de plus en plus bas font que les fabriquants réduisent à l'extrême le contrôle de qualité de ce qu'ils fabriquent.
Ce qui fait que j'ai du faire 3 fois l'aller-retour chez moi-assembleur pour trouver une barrette qui passait le memtest86 ... :-(
-- Jerome "Moi, je trouve ça rigolo quand y a un truc qui marche pas avec Linux. Chercher à le faire marcher m'amuse beaucoup. C'est mieux qu'un jeu vidéo." M. in fr.comp.os.linux.debats
Le Fri, 06 Aug 2004 21:22:55 +0200, Txo a écrit :
(...)
Les assembleurs ne sont pas toujours responsables. J'en connais un qui a
fini par contrôler toutes les pièces qu'il reçoit pour éviter que les
clients fassent eux même le test.
Les prix de plus en plus bas font que les fabriquants réduisent à
l'extrême le contrôle de qualité de ce qu'ils fabriquent.
Ce qui fait que j'ai du faire 3 fois l'aller-retour chez moi-assembleur
pour trouver une barrette qui passait le memtest86 ... :-(
--
Jerome
"Moi, je trouve ça rigolo quand y a un truc qui marche pas avec Linux.
Chercher à le faire marcher m'amuse beaucoup. C'est mieux qu'un jeu vidéo."
M. in fr.comp.os.linux.debats
Le Fri, 06 Aug 2004 21:22:55 +0200, Txo a écrit : (...)
Les assembleurs ne sont pas toujours responsables. J'en connais un qui a fini par contrôler toutes les pièces qu'il reçoit pour éviter que les clients fassent eux même le test.
Les prix de plus en plus bas font que les fabriquants réduisent à l'extrême le contrôle de qualité de ce qu'ils fabriquent.
Ce qui fait que j'ai du faire 3 fois l'aller-retour chez moi-assembleur pour trouver une barrette qui passait le memtest86 ... :-(
-- Jerome "Moi, je trouve ça rigolo quand y a un truc qui marche pas avec Linux. Chercher à le faire marcher m'amuse beaucoup. C'est mieux qu'un jeu vidéo." M. in fr.comp.os.linux.debats
