Le 27-05-2010, JKB a écrit :Le 27-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
Marc Boyer ?crivait dans fr.comp.lang.c :Ca dépend. Les bons (rigoureux, motivés), que tu commences par Java ou par C,
ils arrivent au même point à la fin. Mais le ventre mou, il a plus appris.
Par contre, oui, il se met à postuler sur les mêmes jobs que les bons.
Les bons (au début de leur cursus), on ne sait pas encore que ce
sera des bons. Il faut quelques séances pour s'en rendre compte.
Oui, mais ils le sont déjà.
La question, c'est selection vs formation de masse.
Le propos de Marc Espie, tel que je l'ai compris, c'est: il vaut
mieux dégouter rapidement ceux qui n'arriveront à rien de bon.
A mon sens, on peut quand même leur apprendre des choses, même si
le risque est qu'il se retrouve sous-compétent pour certaines tâches.De mon côté utilisateur, je trouve que les ordis plantent moins
de nos jours qu'il y a disons 15 ans. A l'époque, on pouvait pas
accuser Java.
Je n'ai _jamais_ réussi à faire planter un VAX. Je n'ai _jamais_
réussi non plus à faire planter mon Goupil G3 qui tournait
alternativement sous Flex-9 et UniFLEX. À toutes les époques de
l'informatique, il y a eu des codes crades et des codes propres. Le
problème actuel, c'est que la démocratisation des IDE permet
beaucoup plus facilement l'écriture de codes crades. Pourtant, à
côté de mon G3, il y avait un 80286 sous MS-DOS 3.30 qui lui,
n'arrêtait pas de planter...
Pareil: mon Linux/Ubuntu ne plante quasiment jamais (sauf une machine,
mais je soupsonne un pb disque, et j'ai la flemme de résinstaller sur
un disque sain).La puissance des machines aussi n'est pas là pour assainir le code.
Non, mais le soft est devenu moins cher.
Ma fille trouve des jeux gratuits qui m'auraient fait baver à son age.
Dans le débat IDE vs vielleries, je n'ai jamais réussi à configuer
un plugin emacs pour qu'il fasse en mode java ou C++ ce que fait Eclipse.
OK, quelques exemples ne font pas une généralité, mais mon sentiment
reste que le soft est moins cher, que le code critique (que je connais)
fait de plus en plus de chose, et reste fiable.
La puissance des machines fait qu'on a plus a economiser la CPU et
la mémoire. Donc, oui, il faut un double coeur pour bosser et surfer
sur Internet (le moindre site mal codé occupe 100% d'un coeur), mais
si ces sites avaient du être codé en C, ils n'existeraient pour la
plupart pas.
Lorsque la compilation d'un bête programme de quelques centaines de
lignes n'était pas négligeabme, tu recherchais tes bugs à la main.
Tu ne compilais pas pour voir si ça passait. Aujourd'hui, je vois
des types qui compilent, testent, compilent, testent... et au final
ne savent pas si leur code est bon ou non, seulement qu'il passe 99%
des tests. Et on s'étonne de voir des OS entiers exploser...
Comme tu le disais, MS-DOS plantait déjà à cette époque...
Le 27-05-2010, JKB <knatschke@koenigsberg.fr> a écrit :
Le 27-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
Marc Boyer ?crivait dans fr.comp.lang.c :
Ca dépend. Les bons (rigoureux, motivés), que tu commences par Java ou par C,
ils arrivent au même point à la fin. Mais le ventre mou, il a plus appris.
Par contre, oui, il se met à postuler sur les mêmes jobs que les bons.
Les bons (au début de leur cursus), on ne sait pas encore que ce
sera des bons. Il faut quelques séances pour s'en rendre compte.
Oui, mais ils le sont déjà.
La question, c'est selection vs formation de masse.
Le propos de Marc Espie, tel que je l'ai compris, c'est: il vaut
mieux dégouter rapidement ceux qui n'arriveront à rien de bon.
A mon sens, on peut quand même leur apprendre des choses, même si
le risque est qu'il se retrouve sous-compétent pour certaines tâches.
De mon côté utilisateur, je trouve que les ordis plantent moins
de nos jours qu'il y a disons 15 ans. A l'époque, on pouvait pas
accuser Java.
Je n'ai _jamais_ réussi à faire planter un VAX. Je n'ai _jamais_
réussi non plus à faire planter mon Goupil G3 qui tournait
alternativement sous Flex-9 et UniFLEX. À toutes les époques de
l'informatique, il y a eu des codes crades et des codes propres. Le
problème actuel, c'est que la démocratisation des IDE permet
beaucoup plus facilement l'écriture de codes crades. Pourtant, à
côté de mon G3, il y avait un 80286 sous MS-DOS 3.30 qui lui,
n'arrêtait pas de planter...
Pareil: mon Linux/Ubuntu ne plante quasiment jamais (sauf une machine,
mais je soupsonne un pb disque, et j'ai la flemme de résinstaller sur
un disque sain).
La puissance des machines aussi n'est pas là pour assainir le code.
Non, mais le soft est devenu moins cher.
Ma fille trouve des jeux gratuits qui m'auraient fait baver à son age.
Dans le débat IDE vs vielleries, je n'ai jamais réussi à configuer
un plugin emacs pour qu'il fasse en mode java ou C++ ce que fait Eclipse.
OK, quelques exemples ne font pas une généralité, mais mon sentiment
reste que le soft est moins cher, que le code critique (que je connais)
fait de plus en plus de chose, et reste fiable.
La puissance des machines fait qu'on a plus a economiser la CPU et
la mémoire. Donc, oui, il faut un double coeur pour bosser et surfer
sur Internet (le moindre site mal codé occupe 100% d'un coeur), mais
si ces sites avaient du être codé en C, ils n'existeraient pour la
plupart pas.
Lorsque la compilation d'un bête programme de quelques centaines de
lignes n'était pas négligeabme, tu recherchais tes bugs à la main.
Tu ne compilais pas pour voir si ça passait. Aujourd'hui, je vois
des types qui compilent, testent, compilent, testent... et au final
ne savent pas si leur code est bon ou non, seulement qu'il passe 99%
des tests. Et on s'étonne de voir des OS entiers exploser...
Comme tu le disais, MS-DOS plantait déjà à cette époque...
Le 27-05-2010, JKB a écrit :Le 27-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
Marc Boyer ?crivait dans fr.comp.lang.c :Ca dépend. Les bons (rigoureux, motivés), que tu commences par Java ou par C,
ils arrivent au même point à la fin. Mais le ventre mou, il a plus appris.
Par contre, oui, il se met à postuler sur les mêmes jobs que les bons.
Les bons (au début de leur cursus), on ne sait pas encore que ce
sera des bons. Il faut quelques séances pour s'en rendre compte.
Oui, mais ils le sont déjà.
La question, c'est selection vs formation de masse.
Le propos de Marc Espie, tel que je l'ai compris, c'est: il vaut
mieux dégouter rapidement ceux qui n'arriveront à rien de bon.
A mon sens, on peut quand même leur apprendre des choses, même si
le risque est qu'il se retrouve sous-compétent pour certaines tâches.De mon côté utilisateur, je trouve que les ordis plantent moins
de nos jours qu'il y a disons 15 ans. A l'époque, on pouvait pas
accuser Java.
Je n'ai _jamais_ réussi à faire planter un VAX. Je n'ai _jamais_
réussi non plus à faire planter mon Goupil G3 qui tournait
alternativement sous Flex-9 et UniFLEX. À toutes les époques de
l'informatique, il y a eu des codes crades et des codes propres. Le
problème actuel, c'est que la démocratisation des IDE permet
beaucoup plus facilement l'écriture de codes crades. Pourtant, à
côté de mon G3, il y avait un 80286 sous MS-DOS 3.30 qui lui,
n'arrêtait pas de planter...
Pareil: mon Linux/Ubuntu ne plante quasiment jamais (sauf une machine,
mais je soupsonne un pb disque, et j'ai la flemme de résinstaller sur
un disque sain).La puissance des machines aussi n'est pas là pour assainir le code.
Non, mais le soft est devenu moins cher.
Ma fille trouve des jeux gratuits qui m'auraient fait baver à son age.
Dans le débat IDE vs vielleries, je n'ai jamais réussi à configuer
un plugin emacs pour qu'il fasse en mode java ou C++ ce que fait Eclipse.
OK, quelques exemples ne font pas une généralité, mais mon sentiment
reste que le soft est moins cher, que le code critique (que je connais)
fait de plus en plus de chose, et reste fiable.
La puissance des machines fait qu'on a plus a economiser la CPU et
la mémoire. Donc, oui, il faut un double coeur pour bosser et surfer
sur Internet (le moindre site mal codé occupe 100% d'un coeur), mais
si ces sites avaient du être codé en C, ils n'existeraient pour la
plupart pas.
Lorsque la compilation d'un bête programme de quelques centaines de
lignes n'était pas négligeabme, tu recherchais tes bugs à la main.
Tu ne compilais pas pour voir si ça passait. Aujourd'hui, je vois
des types qui compilent, testent, compilent, testent... et au final
ne savent pas si leur code est bon ou non, seulement qu'il passe 99%
des tests. Et on s'étonne de voir des OS entiers exploser...
Comme tu le disais, MS-DOS plantait déjà à cette époque...
Le 27-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
Marc Boyer ?crivait dans fr.comp.lang.c :La puissance des machines aussi n'est pas là pour assainir le code.
Non, mais le soft est devenu moins cher.
Non. Le soft à qualité égale n'a pas baissé. Je fais dans le calcul
et franchement, je ne vois pas bien le prix chuter.
Ma fille trouve des jeux gratuits qui m'auraient fait baver à son age.
Dans le débat IDE vs vielleries, je n'ai jamais réussi à configuer
un plugin emacs pour qu'il fasse en mode java ou C++ ce que fait Eclipse.
Je code exclusivement avec vim. Zut, j'ai marché dedans ;-)
Et avec vim, je code du C, Fortran all flavours, RPL/2 (ben oui, on
n'est jamais mieux servi que par soi-même) même en utilisant des
trucs aussi antédiluviens que Motif...
OK, quelques exemples ne font pas une généralité, mais mon sentiment
reste que le soft est moins cher, que le code critique (que je connais)
fait de plus en plus de chose, et reste fiable.
J'ai surtout l'impression qu'il y a de plus en plus deux mondes
totalements différents : le monde du soft critique et le monde du
soft qui peut planter. Et ce qu'on permet à plus de choses de
planter aujourd'hui qu'on ne le permettait il y a quelques années.
Je passe pour un dinosaure parce que lorsque j'écris du C, je teste
tous les retours de fonctions et que j'implante des mécanismes de
récupération d'erreur !
La puissance des machines fait qu'on a plus a economiser la CPU et
la mémoire. Donc, oui, il faut un double coeur pour bosser et surfer
sur Internet (le moindre site mal codé occupe 100% d'un coeur), mais
si ces sites avaient du être codé en C, ils n'existeraient pour la
plupart pas.
Et alors ? Ce n'est pas parce qu'on n'a plus à économiser les
ressources qu'on doit absolument coder comme un goret.
Et cette
réflexion va très loin. Actuellement, je suis en train de réécrire
un allocateur pour Solaris parce qu'il y a des bugs à la turc dans
_tous_ les mallocs de Solaris. J'ai testé, c'est une régression
datant de Solaris 8 et _personne_ n'a réussi à dire à Sun de
corriger la chose parce que visiblement, le problème est marginal.
Il faut vraiment être dans une configuration spécifique pour voir
arriver le problème, mais il est bien là, pas de doute.
Je trouve personnellement inadmissible d'avoir un OS avec un
allocateur qui ne libère pas par free() _toute_ la mémoire allouée par
le malloc() correspondant. Heureusement que le mmap() se comporte
correctement et permet d'émuler à peu de frais un malloc() décent !
Lorsque la compilation d'un bête programme de quelques centaines de
lignes n'était pas négligeabme, tu recherchais tes bugs à la main.
Tu ne compilais pas pour voir si ça passait. Aujourd'hui, je vois
des types qui compilent, testent, compilent, testent... et au final
ne savent pas si leur code est bon ou non, seulement qu'il passe 99%
des tests. Et on s'étonne de voir des OS entiers exploser...
Comme tu le disais, MS-DOS plantait déjà à cette époque...
C'est surtout les softs _sur_ MS-DOS qui le faisait planter...
Le 27-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
Marc Boyer ?crivait dans fr.comp.lang.c :
La puissance des machines aussi n'est pas là pour assainir le code.
Non, mais le soft est devenu moins cher.
Non. Le soft à qualité égale n'a pas baissé. Je fais dans le calcul
et franchement, je ne vois pas bien le prix chuter.
Ma fille trouve des jeux gratuits qui m'auraient fait baver à son age.
Dans le débat IDE vs vielleries, je n'ai jamais réussi à configuer
un plugin emacs pour qu'il fasse en mode java ou C++ ce que fait Eclipse.
Je code exclusivement avec vim. Zut, j'ai marché dedans ;-)
Et avec vim, je code du C, Fortran all flavours, RPL/2 (ben oui, on
n'est jamais mieux servi que par soi-même) même en utilisant des
trucs aussi antédiluviens que Motif...
OK, quelques exemples ne font pas une généralité, mais mon sentiment
reste que le soft est moins cher, que le code critique (que je connais)
fait de plus en plus de chose, et reste fiable.
J'ai surtout l'impression qu'il y a de plus en plus deux mondes
totalements différents : le monde du soft critique et le monde du
soft qui peut planter. Et ce qu'on permet à plus de choses de
planter aujourd'hui qu'on ne le permettait il y a quelques années.
Je passe pour un dinosaure parce que lorsque j'écris du C, je teste
tous les retours de fonctions et que j'implante des mécanismes de
récupération d'erreur !
La puissance des machines fait qu'on a plus a economiser la CPU et
la mémoire. Donc, oui, il faut un double coeur pour bosser et surfer
sur Internet (le moindre site mal codé occupe 100% d'un coeur), mais
si ces sites avaient du être codé en C, ils n'existeraient pour la
plupart pas.
Et alors ? Ce n'est pas parce qu'on n'a plus à économiser les
ressources qu'on doit absolument coder comme un goret.
Et cette
réflexion va très loin. Actuellement, je suis en train de réécrire
un allocateur pour Solaris parce qu'il y a des bugs à la turc dans
_tous_ les mallocs de Solaris. J'ai testé, c'est une régression
datant de Solaris 8 et _personne_ n'a réussi à dire à Sun de
corriger la chose parce que visiblement, le problème est marginal.
Il faut vraiment être dans une configuration spécifique pour voir
arriver le problème, mais il est bien là, pas de doute.
Je trouve personnellement inadmissible d'avoir un OS avec un
allocateur qui ne libère pas par free() _toute_ la mémoire allouée par
le malloc() correspondant. Heureusement que le mmap() se comporte
correctement et permet d'émuler à peu de frais un malloc() décent !
Lorsque la compilation d'un bête programme de quelques centaines de
lignes n'était pas négligeabme, tu recherchais tes bugs à la main.
Tu ne compilais pas pour voir si ça passait. Aujourd'hui, je vois
des types qui compilent, testent, compilent, testent... et au final
ne savent pas si leur code est bon ou non, seulement qu'il passe 99%
des tests. Et on s'étonne de voir des OS entiers exploser...
Comme tu le disais, MS-DOS plantait déjà à cette époque...
C'est surtout les softs _sur_ MS-DOS qui le faisait planter...
Le 27-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
Marc Boyer ?crivait dans fr.comp.lang.c :La puissance des machines aussi n'est pas là pour assainir le code.
Non, mais le soft est devenu moins cher.
Non. Le soft à qualité égale n'a pas baissé. Je fais dans le calcul
et franchement, je ne vois pas bien le prix chuter.
Ma fille trouve des jeux gratuits qui m'auraient fait baver à son age.
Dans le débat IDE vs vielleries, je n'ai jamais réussi à configuer
un plugin emacs pour qu'il fasse en mode java ou C++ ce que fait Eclipse.
Je code exclusivement avec vim. Zut, j'ai marché dedans ;-)
Et avec vim, je code du C, Fortran all flavours, RPL/2 (ben oui, on
n'est jamais mieux servi que par soi-même) même en utilisant des
trucs aussi antédiluviens que Motif...
OK, quelques exemples ne font pas une généralité, mais mon sentiment
reste que le soft est moins cher, que le code critique (que je connais)
fait de plus en plus de chose, et reste fiable.
J'ai surtout l'impression qu'il y a de plus en plus deux mondes
totalements différents : le monde du soft critique et le monde du
soft qui peut planter. Et ce qu'on permet à plus de choses de
planter aujourd'hui qu'on ne le permettait il y a quelques années.
Je passe pour un dinosaure parce que lorsque j'écris du C, je teste
tous les retours de fonctions et que j'implante des mécanismes de
récupération d'erreur !
La puissance des machines fait qu'on a plus a economiser la CPU et
la mémoire. Donc, oui, il faut un double coeur pour bosser et surfer
sur Internet (le moindre site mal codé occupe 100% d'un coeur), mais
si ces sites avaient du être codé en C, ils n'existeraient pour la
plupart pas.
Et alors ? Ce n'est pas parce qu'on n'a plus à économiser les
ressources qu'on doit absolument coder comme un goret.
Et cette
réflexion va très loin. Actuellement, je suis en train de réécrire
un allocateur pour Solaris parce qu'il y a des bugs à la turc dans
_tous_ les mallocs de Solaris. J'ai testé, c'est une régression
datant de Solaris 8 et _personne_ n'a réussi à dire à Sun de
corriger la chose parce que visiblement, le problème est marginal.
Il faut vraiment être dans une configuration spécifique pour voir
arriver le problème, mais il est bien là, pas de doute.
Je trouve personnellement inadmissible d'avoir un OS avec un
allocateur qui ne libère pas par free() _toute_ la mémoire allouée par
le malloc() correspondant. Heureusement que le mmap() se comporte
correctement et permet d'émuler à peu de frais un malloc() décent !
Lorsque la compilation d'un bête programme de quelques centaines de
lignes n'était pas négligeabme, tu recherchais tes bugs à la main.
Tu ne compilais pas pour voir si ça passait. Aujourd'hui, je vois
des types qui compilent, testent, compilent, testent... et au final
ne savent pas si leur code est bon ou non, seulement qu'il passe 99%
des tests. Et on s'étonne de voir des OS entiers exploser...
Comme tu le disais, MS-DOS plantait déjà à cette époque...
C'est surtout les softs _sur_ MS-DOS qui le faisait planter...
Le 27-05-2010, JKB a écrit :Le 27-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
Marc Boyer ?crivait dans fr.comp.lang.c :La puissance des machines aussi n'est pas là pour assainir le code.
Non, mais le soft est devenu moins cher.
Non. Le soft à qualité égale n'a pas baissé. Je fais dans le calcul
et franchement, je ne vois pas bien le prix chuter.
Peut-être que le calcul est un monde à part. C'est quand même l'ancetre,
et il a du atteindre sa maturité avant les autres.Ma fille trouve des jeux gratuits qui m'auraient fait baver à son age.
Dans le débat IDE vs vielleries, je n'ai jamais réussi à configuer
un plugin emacs pour qu'il fasse en mode java ou C++ ce que fait Eclipse.
Je code exclusivement avec vim. Zut, j'ai marché dedans ;-)
Et avec vim, je code du C, Fortran all flavours, RPL/2 (ben oui, on
n'est jamais mieux servi que par soi-même) même en utilisant des
trucs aussi antédiluviens que Motif...
Je code uniquement avec xemacs... Mais assez peu en fait.
C'était pas pour faire une bataille d'éditeur, mais pour montrer qu'un
truc relativement nouveau, à base de Java, a su implanter vite des
choses qu'un bon vieux truc robuste ne sait pas encore faire.
Mais là encore, un exemple ne fait pas une généralité.
OK, quelques exemples ne font pas une généralité, mais mon sentiment
reste que le soft est moins cher, que le code critique (que je connais)
fait de plus en plus de chose, et reste fiable.
J'ai surtout l'impression qu'il y a de plus en plus deux mondes
totalements différents : le monde du soft critique et le monde du
soft qui peut planter. Et ce qu'on permet à plus de choses de
planter aujourd'hui qu'on ne le permettait il y a quelques années.
Ca doit dépendre des domaines.
Pour l'informatique grand public, j'ai quand même l'impression d'un mieux.
Pour l'informatique embarqué aérospatiale, on a plutôt durci, puisqu'on a
plutot moins d'incident alors qu'il y a 100 à 1000 fois plus de code.
Pour l'automobile, il y a plus de code et plus de bug. Je n'ai pas d'idée
sur le nb de bug par ligne de code.
Je passe pour un dinosaure parce que lorsque j'écris du C, je teste
tous les retours de fonctions et que j'implante des mécanismes de
récupération d'erreur !
Les retours de fonction, ça me semble normal (encore que printf, j'avoue,
je laisse tomber).
Récupération d'erreur ? A quel niveau ?
La puissance des machines fait qu'on a plus a economiser la CPU et
la mémoire. Donc, oui, il faut un double coeur pour bosser et surfer
sur Internet (le moindre site mal codé occupe 100% d'un coeur), mais
si ces sites avaient du être codé en C, ils n'existeraient pour la
plupart pas.
Et alors ? Ce n'est pas parce qu'on n'a plus à économiser les
ressources qu'on doit absolument coder comme un goret.
Entre une extrème et l'autre, il y a plusieurs milieux, dont un juste
peut-être.Et cette
réflexion va très loin. Actuellement, je suis en train de réécrire
un allocateur pour Solaris parce qu'il y a des bugs à la turc dans
_tous_ les mallocs de Solaris. J'ai testé, c'est une régression
datant de Solaris 8 et _personne_ n'a réussi à dire à Sun de
corriger la chose parce que visiblement, le problème est marginal.
Il faut vraiment être dans une configuration spécifique pour voir
arriver le problème, mais il est bien là, pas de doute.
Je trouve personnellement inadmissible d'avoir un OS avec un
allocateur qui ne libère pas par free() _toute_ la mémoire allouée par
le malloc() correspondant. Heureusement que le mmap() se comporte
correctement et permet d'émuler à peu de frais un malloc() décent !
D'un autre côté, Solaris, c'est l'histoire d'un échec, non ?
Lorsque la compilation d'un bête programme de quelques centaines de
lignes n'était pas négligeabme, tu recherchais tes bugs à la main.
Tu ne compilais pas pour voir si ça passait. Aujourd'hui, je vois
des types qui compilent, testent, compilent, testent... et au final
ne savent pas si leur code est bon ou non, seulement qu'il passe 99%
des tests. Et on s'étonne de voir des OS entiers exploser...
Comme tu le disais, MS-DOS plantait déjà à cette époque...
C'est surtout les softs _sur_ MS-DOS qui le faisait planter...
Ben, pourtant, c'est pas le rôle d'un OS de protéger les applis
saines des applis buggées ?
Faire tourner un OS sans appli, c'est un peu comme une appli sans
utilisateur, c'est vachement plus facile, non ?
Le 27-05-2010, JKB <knatschke@koenigsberg.fr> a écrit :
Le 27-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
Marc Boyer ?crivait dans fr.comp.lang.c :
La puissance des machines aussi n'est pas là pour assainir le code.
Non, mais le soft est devenu moins cher.
Non. Le soft à qualité égale n'a pas baissé. Je fais dans le calcul
et franchement, je ne vois pas bien le prix chuter.
Peut-être que le calcul est un monde à part. C'est quand même l'ancetre,
et il a du atteindre sa maturité avant les autres.
Ma fille trouve des jeux gratuits qui m'auraient fait baver à son age.
Dans le débat IDE vs vielleries, je n'ai jamais réussi à configuer
un plugin emacs pour qu'il fasse en mode java ou C++ ce que fait Eclipse.
Je code exclusivement avec vim. Zut, j'ai marché dedans ;-)
Et avec vim, je code du C, Fortran all flavours, RPL/2 (ben oui, on
n'est jamais mieux servi que par soi-même) même en utilisant des
trucs aussi antédiluviens que Motif...
Je code uniquement avec xemacs... Mais assez peu en fait.
C'était pas pour faire une bataille d'éditeur, mais pour montrer qu'un
truc relativement nouveau, à base de Java, a su implanter vite des
choses qu'un bon vieux truc robuste ne sait pas encore faire.
Mais là encore, un exemple ne fait pas une généralité.
OK, quelques exemples ne font pas une généralité, mais mon sentiment
reste que le soft est moins cher, que le code critique (que je connais)
fait de plus en plus de chose, et reste fiable.
J'ai surtout l'impression qu'il y a de plus en plus deux mondes
totalements différents : le monde du soft critique et le monde du
soft qui peut planter. Et ce qu'on permet à plus de choses de
planter aujourd'hui qu'on ne le permettait il y a quelques années.
Ca doit dépendre des domaines.
Pour l'informatique grand public, j'ai quand même l'impression d'un mieux.
Pour l'informatique embarqué aérospatiale, on a plutôt durci, puisqu'on a
plutot moins d'incident alors qu'il y a 100 à 1000 fois plus de code.
Pour l'automobile, il y a plus de code et plus de bug. Je n'ai pas d'idée
sur le nb de bug par ligne de code.
Je passe pour un dinosaure parce que lorsque j'écris du C, je teste
tous les retours de fonctions et que j'implante des mécanismes de
récupération d'erreur !
Les retours de fonction, ça me semble normal (encore que printf, j'avoue,
je laisse tomber).
Récupération d'erreur ? A quel niveau ?
La puissance des machines fait qu'on a plus a economiser la CPU et
la mémoire. Donc, oui, il faut un double coeur pour bosser et surfer
sur Internet (le moindre site mal codé occupe 100% d'un coeur), mais
si ces sites avaient du être codé en C, ils n'existeraient pour la
plupart pas.
Et alors ? Ce n'est pas parce qu'on n'a plus à économiser les
ressources qu'on doit absolument coder comme un goret.
Entre une extrème et l'autre, il y a plusieurs milieux, dont un juste
peut-être.
Et cette
réflexion va très loin. Actuellement, je suis en train de réécrire
un allocateur pour Solaris parce qu'il y a des bugs à la turc dans
_tous_ les mallocs de Solaris. J'ai testé, c'est une régression
datant de Solaris 8 et _personne_ n'a réussi à dire à Sun de
corriger la chose parce que visiblement, le problème est marginal.
Il faut vraiment être dans une configuration spécifique pour voir
arriver le problème, mais il est bien là, pas de doute.
Je trouve personnellement inadmissible d'avoir un OS avec un
allocateur qui ne libère pas par free() _toute_ la mémoire allouée par
le malloc() correspondant. Heureusement que le mmap() se comporte
correctement et permet d'émuler à peu de frais un malloc() décent !
D'un autre côté, Solaris, c'est l'histoire d'un échec, non ?
Lorsque la compilation d'un bête programme de quelques centaines de
lignes n'était pas négligeabme, tu recherchais tes bugs à la main.
Tu ne compilais pas pour voir si ça passait. Aujourd'hui, je vois
des types qui compilent, testent, compilent, testent... et au final
ne savent pas si leur code est bon ou non, seulement qu'il passe 99%
des tests. Et on s'étonne de voir des OS entiers exploser...
Comme tu le disais, MS-DOS plantait déjà à cette époque...
C'est surtout les softs _sur_ MS-DOS qui le faisait planter...
Ben, pourtant, c'est pas le rôle d'un OS de protéger les applis
saines des applis buggées ?
Faire tourner un OS sans appli, c'est un peu comme une appli sans
utilisateur, c'est vachement plus facile, non ?
Le 27-05-2010, JKB a écrit :Le 27-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
Marc Boyer ?crivait dans fr.comp.lang.c :La puissance des machines aussi n'est pas là pour assainir le code.
Non, mais le soft est devenu moins cher.
Non. Le soft à qualité égale n'a pas baissé. Je fais dans le calcul
et franchement, je ne vois pas bien le prix chuter.
Peut-être que le calcul est un monde à part. C'est quand même l'ancetre,
et il a du atteindre sa maturité avant les autres.Ma fille trouve des jeux gratuits qui m'auraient fait baver à son age.
Dans le débat IDE vs vielleries, je n'ai jamais réussi à configuer
un plugin emacs pour qu'il fasse en mode java ou C++ ce que fait Eclipse.
Je code exclusivement avec vim. Zut, j'ai marché dedans ;-)
Et avec vim, je code du C, Fortran all flavours, RPL/2 (ben oui, on
n'est jamais mieux servi que par soi-même) même en utilisant des
trucs aussi antédiluviens que Motif...
Je code uniquement avec xemacs... Mais assez peu en fait.
C'était pas pour faire une bataille d'éditeur, mais pour montrer qu'un
truc relativement nouveau, à base de Java, a su implanter vite des
choses qu'un bon vieux truc robuste ne sait pas encore faire.
Mais là encore, un exemple ne fait pas une généralité.
OK, quelques exemples ne font pas une généralité, mais mon sentiment
reste que le soft est moins cher, que le code critique (que je connais)
fait de plus en plus de chose, et reste fiable.
J'ai surtout l'impression qu'il y a de plus en plus deux mondes
totalements différents : le monde du soft critique et le monde du
soft qui peut planter. Et ce qu'on permet à plus de choses de
planter aujourd'hui qu'on ne le permettait il y a quelques années.
Ca doit dépendre des domaines.
Pour l'informatique grand public, j'ai quand même l'impression d'un mieux.
Pour l'informatique embarqué aérospatiale, on a plutôt durci, puisqu'on a
plutot moins d'incident alors qu'il y a 100 à 1000 fois plus de code.
Pour l'automobile, il y a plus de code et plus de bug. Je n'ai pas d'idée
sur le nb de bug par ligne de code.
Je passe pour un dinosaure parce que lorsque j'écris du C, je teste
tous les retours de fonctions et que j'implante des mécanismes de
récupération d'erreur !
Les retours de fonction, ça me semble normal (encore que printf, j'avoue,
je laisse tomber).
Récupération d'erreur ? A quel niveau ?
La puissance des machines fait qu'on a plus a economiser la CPU et
la mémoire. Donc, oui, il faut un double coeur pour bosser et surfer
sur Internet (le moindre site mal codé occupe 100% d'un coeur), mais
si ces sites avaient du être codé en C, ils n'existeraient pour la
plupart pas.
Et alors ? Ce n'est pas parce qu'on n'a plus à économiser les
ressources qu'on doit absolument coder comme un goret.
Entre une extrème et l'autre, il y a plusieurs milieux, dont un juste
peut-être.Et cette
réflexion va très loin. Actuellement, je suis en train de réécrire
un allocateur pour Solaris parce qu'il y a des bugs à la turc dans
_tous_ les mallocs de Solaris. J'ai testé, c'est une régression
datant de Solaris 8 et _personne_ n'a réussi à dire à Sun de
corriger la chose parce que visiblement, le problème est marginal.
Il faut vraiment être dans une configuration spécifique pour voir
arriver le problème, mais il est bien là, pas de doute.
Je trouve personnellement inadmissible d'avoir un OS avec un
allocateur qui ne libère pas par free() _toute_ la mémoire allouée par
le malloc() correspondant. Heureusement que le mmap() se comporte
correctement et permet d'émuler à peu de frais un malloc() décent !
D'un autre côté, Solaris, c'est l'histoire d'un échec, non ?
Lorsque la compilation d'un bête programme de quelques centaines de
lignes n'était pas négligeabme, tu recherchais tes bugs à la main.
Tu ne compilais pas pour voir si ça passait. Aujourd'hui, je vois
des types qui compilent, testent, compilent, testent... et au final
ne savent pas si leur code est bon ou non, seulement qu'il passe 99%
des tests. Et on s'étonne de voir des OS entiers exploser...
Comme tu le disais, MS-DOS plantait déjà à cette époque...
C'est surtout les softs _sur_ MS-DOS qui le faisait planter...
Ben, pourtant, c'est pas le rôle d'un OS de protéger les applis
saines des applis buggées ?
Faire tourner un OS sans appli, c'est un peu comme une appli sans
utilisateur, c'est vachement plus facile, non ?
Le 27-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
Marc Boyer ?crivait dans fr.comp.lang.c :Le 27-05-2010, JKB a écrit :
J'ai surtout l'impression qu'il y a de plus en plus deux mondes
totalements différents : le monde du soft critique et le monde du
soft qui peut planter. Et ce qu'on permet à plus de choses de
planter aujourd'hui qu'on ne le permettait il y a quelques années.
Ca doit dépendre des domaines.
Pour l'informatique grand public, j'ai quand même l'impression d'un mieux.
Pour l'informatique embarqué aérospatiale, on a plutôt durci, puisqu'on a
plutot moins d'incident alors qu'il y a 100 à 1000 fois plus de code.
Pour l'automobile, il y a plus de code et plus de bug. Je n'ai pas d'idée
sur le nb de bug par ligne de code.
En tant qu'utilisateur final, j'ai une assez bonne idée de la
qualité de l'automobile actuelle en générale et de l'informatique
embarquée dans celle-ci en particulier ;-)
Je crois que c'est même ne raison de l'arrivée massive de
l'informatique dans l'utomobile et de la qualité d'icelle que j'ai
ressorti ma DS du garage...
Je passe pour un dinosaure parce que lorsque j'écris du C, je teste
tous les retours de fonctions et que j'implante des mécanismes de
récupération d'erreur !
Les retours de fonction, ça me semble normal (encore que printf, j'avoue,
je laisse tomber).
Récupération d'erreur ? A quel niveau ?
À tous les niveaux pour qu'un programme ne termine pas sur un
laconique segmentation fault par exemple. Je teste explicitement les
retours de toutes les fonctions qui peuvent dans le contexte ne pas
s'achever correctement.
D'un autre côté, Solaris, c'est l'histoire d'un échec, non ?
Non. Solaris, c'était un bon OS avant que Sun ne développe java et
en colle partout y compris dans le coeur de Solaris.
Le 27-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
Marc Boyer ?crivait dans fr.comp.lang.c :
Le 27-05-2010, JKB <knatschke@koenigsberg.fr> a écrit :
J'ai surtout l'impression qu'il y a de plus en plus deux mondes
totalements différents : le monde du soft critique et le monde du
soft qui peut planter. Et ce qu'on permet à plus de choses de
planter aujourd'hui qu'on ne le permettait il y a quelques années.
Ca doit dépendre des domaines.
Pour l'informatique grand public, j'ai quand même l'impression d'un mieux.
Pour l'informatique embarqué aérospatiale, on a plutôt durci, puisqu'on a
plutot moins d'incident alors qu'il y a 100 à 1000 fois plus de code.
Pour l'automobile, il y a plus de code et plus de bug. Je n'ai pas d'idée
sur le nb de bug par ligne de code.
En tant qu'utilisateur final, j'ai une assez bonne idée de la
qualité de l'automobile actuelle en générale et de l'informatique
embarquée dans celle-ci en particulier ;-)
Je crois que c'est même ne raison de l'arrivée massive de
l'informatique dans l'utomobile et de la qualité d'icelle que j'ai
ressorti ma DS du garage...
Je passe pour un dinosaure parce que lorsque j'écris du C, je teste
tous les retours de fonctions et que j'implante des mécanismes de
récupération d'erreur !
Les retours de fonction, ça me semble normal (encore que printf, j'avoue,
je laisse tomber).
Récupération d'erreur ? A quel niveau ?
À tous les niveaux pour qu'un programme ne termine pas sur un
laconique segmentation fault par exemple. Je teste explicitement les
retours de toutes les fonctions qui peuvent dans le contexte ne pas
s'achever correctement.
D'un autre côté, Solaris, c'est l'histoire d'un échec, non ?
Non. Solaris, c'était un bon OS avant que Sun ne développe java et
en colle partout y compris dans le coeur de Solaris.
Le 27-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
Marc Boyer ?crivait dans fr.comp.lang.c :Le 27-05-2010, JKB a écrit :
J'ai surtout l'impression qu'il y a de plus en plus deux mondes
totalements différents : le monde du soft critique et le monde du
soft qui peut planter. Et ce qu'on permet à plus de choses de
planter aujourd'hui qu'on ne le permettait il y a quelques années.
Ca doit dépendre des domaines.
Pour l'informatique grand public, j'ai quand même l'impression d'un mieux.
Pour l'informatique embarqué aérospatiale, on a plutôt durci, puisqu'on a
plutot moins d'incident alors qu'il y a 100 à 1000 fois plus de code.
Pour l'automobile, il y a plus de code et plus de bug. Je n'ai pas d'idée
sur le nb de bug par ligne de code.
En tant qu'utilisateur final, j'ai une assez bonne idée de la
qualité de l'automobile actuelle en générale et de l'informatique
embarquée dans celle-ci en particulier ;-)
Je crois que c'est même ne raison de l'arrivée massive de
l'informatique dans l'utomobile et de la qualité d'icelle que j'ai
ressorti ma DS du garage...
Je passe pour un dinosaure parce que lorsque j'écris du C, je teste
tous les retours de fonctions et que j'implante des mécanismes de
récupération d'erreur !
Les retours de fonction, ça me semble normal (encore que printf, j'avoue,
je laisse tomber).
Récupération d'erreur ? A quel niveau ?
À tous les niveaux pour qu'un programme ne termine pas sur un
laconique segmentation fault par exemple. Je teste explicitement les
retours de toutes les fonctions qui peuvent dans le contexte ne pas
s'achever correctement.
D'un autre côté, Solaris, c'est l'histoire d'un échec, non ?
Non. Solaris, c'était un bon OS avant que Sun ne développe java et
en colle partout y compris dans le coeur de Solaris.
le 27-05-2010, ? propos de
re: apprendre le langage c et quelques questions,
marc boyer ?crivait dans fr.comp.lang.c :Pour l'automobile, il y a plus de code et plus de bug. Je n'ai pas d'idée
sur le nb de bug par ligne de code.
En tant qu'utilisateur final, j'ai une assez bonne idée de la
qualité de l'automobile actuelle en générale et de l'informatique
embarquée dans celle-ci en particulier ;-)
Je crois que c'est même ne raison de l'arrivée massive de
l'informatique dans l'utomobile et de la qualité d'icelle que j'ai
ressorti ma DS du garage...
le 27-05-2010, ? propos de
re: apprendre le langage c et quelques questions,
marc boyer ?crivait dans fr.comp.lang.c :
Pour l'automobile, il y a plus de code et plus de bug. Je n'ai pas d'idée
sur le nb de bug par ligne de code.
En tant qu'utilisateur final, j'ai une assez bonne idée de la
qualité de l'automobile actuelle en générale et de l'informatique
embarquée dans celle-ci en particulier ;-)
Je crois que c'est même ne raison de l'arrivée massive de
l'informatique dans l'utomobile et de la qualité d'icelle que j'ai
ressorti ma DS du garage...
le 27-05-2010, ? propos de
re: apprendre le langage c et quelques questions,
marc boyer ?crivait dans fr.comp.lang.c :Pour l'automobile, il y a plus de code et plus de bug. Je n'ai pas d'idée
sur le nb de bug par ligne de code.
En tant qu'utilisateur final, j'ai une assez bonne idée de la
qualité de l'automobile actuelle en générale et de l'informatique
embarquée dans celle-ci en particulier ;-)
Je crois que c'est même ne raison de l'arrivée massive de
l'informatique dans l'utomobile et de la qualité d'icelle que j'ai
ressorti ma DS du garage...
D'un autre côté, Solaris, c'est l'histoire d'un échec, non ?
D'un autre côté, Solaris, c'est l'histoire d'un échec, non ?
D'un autre côté, Solaris, c'est l'histoire d'un échec, non ?
Le 27-05-2010, JKB a écrit :Le 27-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
Marc Boyer ?crivait dans fr.comp.lang.c :Le 27-05-2010, JKB a écrit :
J'ai surtout l'impression qu'il y a de plus en plus deux mondes
totalements différents : le monde du soft critique et le monde du
soft qui peut planter. Et ce qu'on permet à plus de choses de
planter aujourd'hui qu'on ne le permettait il y a quelques années.
Ca doit dépendre des domaines.
Pour l'informatique grand public, j'ai quand même l'impression d'un mieux.
Pour l'informatique embarqué aérospatiale, on a plutôt durci, puisqu'on a
plutot moins d'incident alors qu'il y a 100 à 1000 fois plus de code.
Pour l'automobile, il y a plus de code et plus de bug. Je n'ai pas d'idée
sur le nb de bug par ligne de code.
En tant qu'utilisateur final, j'ai une assez bonne idée de la
qualité de l'automobile actuelle en générale et de l'informatique
embarquée dans celle-ci en particulier ;-)
Je crois que c'est même ne raison de l'arrivée massive de
l'informatique dans l'utomobile et de la qualité d'icelle que j'ai
ressorti ma DS du garage...
La carricature est amusante, mais ne restons pas à cela.
La baisse de consommation des moteurs n'est possible que grace aux
calculateurs embarqués. Les nouvelles tenues de route aussi (pour corriger
le coup de la Smart qui s'était retournée devant les photographes, à
ma connaissance, ils n'ont rien changé de matériel dans la voiture, mais
ajoutée une tache de surveillance dans le calculo).
Mais en effet, ils sont venus avec des bugs.
Et pour en revenir au propos initial, c'est la question du taux de bug
résiduel par nb de ligne qui est intéressante du point de vue informatique
(du point de vue système, c'est le nb de bug total...)Je passe pour un dinosaure parce que lorsque j'écris du C, je teste
tous les retours de fonctions et que j'implante des mécanismes de
récupération d'erreur !
Les retours de fonction, ça me semble normal (encore que printf, j'avoue,
je laisse tomber).
Récupération d'erreur ? A quel niveau ?
À tous les niveaux pour qu'un programme ne termine pas sur un
laconique segmentation fault par exemple. Je teste explicitement les
retours de toutes les fonctions qui peuvent dans le contexte ne pas
s'achever correctement.
T'en es pas à faire à la main ton système d'exceptions à la setjmp,
longjmp ?
D'un autre côté, Solaris, c'est l'histoire d'un échec, non ?
Non. Solaris, c'était un bon OS avant que Sun ne développe java et
en colle partout y compris dans le coeur de Solaris.
Et ton bug, il date de quand ?
Le 27-05-2010, JKB <knatschke@koenigsberg.fr> a écrit :
Le 27-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
Marc Boyer ?crivait dans fr.comp.lang.c :
Le 27-05-2010, JKB <knatschke@koenigsberg.fr> a écrit :
J'ai surtout l'impression qu'il y a de plus en plus deux mondes
totalements différents : le monde du soft critique et le monde du
soft qui peut planter. Et ce qu'on permet à plus de choses de
planter aujourd'hui qu'on ne le permettait il y a quelques années.
Ca doit dépendre des domaines.
Pour l'informatique grand public, j'ai quand même l'impression d'un mieux.
Pour l'informatique embarqué aérospatiale, on a plutôt durci, puisqu'on a
plutot moins d'incident alors qu'il y a 100 à 1000 fois plus de code.
Pour l'automobile, il y a plus de code et plus de bug. Je n'ai pas d'idée
sur le nb de bug par ligne de code.
En tant qu'utilisateur final, j'ai une assez bonne idée de la
qualité de l'automobile actuelle en générale et de l'informatique
embarquée dans celle-ci en particulier ;-)
Je crois que c'est même ne raison de l'arrivée massive de
l'informatique dans l'utomobile et de la qualité d'icelle que j'ai
ressorti ma DS du garage...
La carricature est amusante, mais ne restons pas à cela.
La baisse de consommation des moteurs n'est possible que grace aux
calculateurs embarqués. Les nouvelles tenues de route aussi (pour corriger
le coup de la Smart qui s'était retournée devant les photographes, à
ma connaissance, ils n'ont rien changé de matériel dans la voiture, mais
ajoutée une tache de surveillance dans le calculo).
Mais en effet, ils sont venus avec des bugs.
Et pour en revenir au propos initial, c'est la question du taux de bug
résiduel par nb de ligne qui est intéressante du point de vue informatique
(du point de vue système, c'est le nb de bug total...)
Je passe pour un dinosaure parce que lorsque j'écris du C, je teste
tous les retours de fonctions et que j'implante des mécanismes de
récupération d'erreur !
Les retours de fonction, ça me semble normal (encore que printf, j'avoue,
je laisse tomber).
Récupération d'erreur ? A quel niveau ?
À tous les niveaux pour qu'un programme ne termine pas sur un
laconique segmentation fault par exemple. Je teste explicitement les
retours de toutes les fonctions qui peuvent dans le contexte ne pas
s'achever correctement.
T'en es pas à faire à la main ton système d'exceptions à la setjmp,
longjmp ?
D'un autre côté, Solaris, c'est l'histoire d'un échec, non ?
Non. Solaris, c'était un bon OS avant que Sun ne développe java et
en colle partout y compris dans le coeur de Solaris.
Et ton bug, il date de quand ?
Le 27-05-2010, JKB a écrit :Le 27-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
Marc Boyer ?crivait dans fr.comp.lang.c :Le 27-05-2010, JKB a écrit :
J'ai surtout l'impression qu'il y a de plus en plus deux mondes
totalements différents : le monde du soft critique et le monde du
soft qui peut planter. Et ce qu'on permet à plus de choses de
planter aujourd'hui qu'on ne le permettait il y a quelques années.
Ca doit dépendre des domaines.
Pour l'informatique grand public, j'ai quand même l'impression d'un mieux.
Pour l'informatique embarqué aérospatiale, on a plutôt durci, puisqu'on a
plutot moins d'incident alors qu'il y a 100 à 1000 fois plus de code.
Pour l'automobile, il y a plus de code et plus de bug. Je n'ai pas d'idée
sur le nb de bug par ligne de code.
En tant qu'utilisateur final, j'ai une assez bonne idée de la
qualité de l'automobile actuelle en générale et de l'informatique
embarquée dans celle-ci en particulier ;-)
Je crois que c'est même ne raison de l'arrivée massive de
l'informatique dans l'utomobile et de la qualité d'icelle que j'ai
ressorti ma DS du garage...
La carricature est amusante, mais ne restons pas à cela.
La baisse de consommation des moteurs n'est possible que grace aux
calculateurs embarqués. Les nouvelles tenues de route aussi (pour corriger
le coup de la Smart qui s'était retournée devant les photographes, à
ma connaissance, ils n'ont rien changé de matériel dans la voiture, mais
ajoutée une tache de surveillance dans le calculo).
Mais en effet, ils sont venus avec des bugs.
Et pour en revenir au propos initial, c'est la question du taux de bug
résiduel par nb de ligne qui est intéressante du point de vue informatique
(du point de vue système, c'est le nb de bug total...)Je passe pour un dinosaure parce que lorsque j'écris du C, je teste
tous les retours de fonctions et que j'implante des mécanismes de
récupération d'erreur !
Les retours de fonction, ça me semble normal (encore que printf, j'avoue,
je laisse tomber).
Récupération d'erreur ? A quel niveau ?
À tous les niveaux pour qu'un programme ne termine pas sur un
laconique segmentation fault par exemple. Je teste explicitement les
retours de toutes les fonctions qui peuvent dans le contexte ne pas
s'achever correctement.
T'en es pas à faire à la main ton système d'exceptions à la setjmp,
longjmp ?
D'un autre côté, Solaris, c'est l'histoire d'un échec, non ?
Non. Solaris, c'était un bon OS avant que Sun ne développe java et
en colle partout y compris dans le coeur de Solaris.
Et ton bug, il date de quand ?
In article <htm13j$4i1$,
Marc Boyer wrote:D'un autre côté, Solaris, c'est l'histoire d'un échec, non ?
Sur le plan technique ? certainement pas ! Sun a longtemps ete leader
en performances sur les gros unix avec plein de memoire, plein de disques,
et beaucoup de coeurs.
Les problemes de sun ont toujours ete cote marketing, en particulier avec
une conversion rate de vendeur materiel en vendeur logiciel, et un
decoupage en sous-divisions tres bizarres, qui se faisaient la concurrence
l'une avec l'autre.
Solaris fait quand meme partie des trucs qu'oracle a recupere avec le
rachat. S'ils s'en foutaient totalement, ils n'auraient pas commence
a faire chier en changeant la politique de distribution de CDs...
In article <htm13j$4i1$1@news.cict.fr>,
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> wrote:
D'un autre côté, Solaris, c'est l'histoire d'un échec, non ?
Sur le plan technique ? certainement pas ! Sun a longtemps ete leader
en performances sur les gros unix avec plein de memoire, plein de disques,
et beaucoup de coeurs.
Les problemes de sun ont toujours ete cote marketing, en particulier avec
une conversion rate de vendeur materiel en vendeur logiciel, et un
decoupage en sous-divisions tres bizarres, qui se faisaient la concurrence
l'une avec l'autre.
Solaris fait quand meme partie des trucs qu'oracle a recupere avec le
rachat. S'ils s'en foutaient totalement, ils n'auraient pas commence
a faire chier en changeant la politique de distribution de CDs...
In article <htm13j$4i1$,
Marc Boyer wrote:D'un autre côté, Solaris, c'est l'histoire d'un échec, non ?
Sur le plan technique ? certainement pas ! Sun a longtemps ete leader
en performances sur les gros unix avec plein de memoire, plein de disques,
et beaucoup de coeurs.
Les problemes de sun ont toujours ete cote marketing, en particulier avec
une conversion rate de vendeur materiel en vendeur logiciel, et un
decoupage en sous-divisions tres bizarres, qui se faisaient la concurrence
l'une avec l'autre.
Solaris fait quand meme partie des trucs qu'oracle a recupere avec le
rachat. S'ils s'en foutaient totalement, ils n'auraient pas commence
a faire chier en changeant la politique de distribution de CDs...
Vi + gcc + gdb pour tout le monde ;-)
Vi + gcc + gdb pour tout le monde ;-)
Vi + gcc + gdb pour tout le monde ;-)
JKB a écrit :Vi + gcc + gdb pour tout le monde ;-)
Heu.... C'est soit vi + sdb ou équivalent, soit emacs + gdb/dbx, sinon
tu mélanges les torchons et les serviettes...
Ok, hors charte, je sors :-)
JKB a écrit :
Vi + gcc + gdb pour tout le monde ;-)
Heu.... C'est soit vi + sdb ou équivalent, soit emacs + gdb/dbx, sinon
tu mélanges les torchons et les serviettes...
Ok, hors charte, je sors :-)
JKB a écrit :Vi + gcc + gdb pour tout le monde ;-)
Heu.... C'est soit vi + sdb ou équivalent, soit emacs + gdb/dbx, sinon
tu mélanges les torchons et les serviettes...
Ok, hors charte, je sors :-)
