Brrrrr...

Alf92

10/10/2012 à 00:28

"MELMOTH" a écrit

Le troll de course qu'il y a sur frp !!! Combien de posts ???

*2227* à 22H45 le 9 octobre 2012...
Melmothéen, comme Il Se doit...

dis Melmoth, tu peux nous sortir des stats par participants ?

Stephane Legras-Decussy

10/10/2012 à 00:40

Le 10/10/2012 00:26, Alf92 a écrit :

l'autre jour j'ai vomi du alain minc.
putain ça a pas bon goût.
et dire que j'ai été nourri à ça pendant mes études...

il est la risée des talk show en ce moment ...

c'est le bon client pour une bon diner de cons ...

Jacques L'helgoualc'h

10/10/2012 à 00:50

Le 09-10-2012, Ghost-Rider a écrit :

Le 08/10/2012 11:39, birdy a écrit :

pépé flingueur
http://cjoint.com/?BJilJi3pTKZ

Ça commence comme Maoïste et ça finit à la National Rifle Association !

Le pouvoir est au bout du fusil©.
--
Jacques L'helgoualc'h

Alf92

10/10/2012 à 02:02

"Alf92" a écrit

histoire de relancer ce thread moribond :
http://cjoint.com/12oc/BJgtYViZtdi_2012-10-06_19.41.05r.jpg
c'est dans le Monde de ce soir (samedi 6 octobre) et ça résume parfaitement ce
que je pense d'Apple depuis quelques années.
pour ceux qui veulent lire l'article en ligne, je viens de le trouver là :
http://www.lemonde.fr/technologies/article/2012/10/05/apple-face-au-choc-des-realites_1770780_651865.html

un dernier pour la route ?
c'est parti !

________________________________________________
http://www.aduf.org/archives/pdf/2107.pdf

Et si nous prenions un peu de recul ? La cas de la Pomme...

A peine sorti, l'Iphone 5 est au coeur des conversations que l'on soit geek,
cadre, employé ou les trois à la fois... Toutes les couches sociales semblent
prises par la magie de la marque à la Pomme. Celle qui eut le flair de trouver
dans les ressorts de notre inconscient le déclic « I », le génial préfixe des
trois produits de rupture imaginé par Steve Jobs après avoir pris les rennes d'une
entreprise à la dérive depuis quinze ans. Ipad, Iphone, IPod, ou comment mon moi
(I = Je en anglais...), ma singularité, se projettent dans un produit tactile,
smart, branché, technologiquement en pointe. En gros, « J'existe +++ grâce à
lui », les autres le voient et on appartient à la communauté élue.

Reste maintenant à s'interroger sur les besoins réellement couverts par ces
gadgets vendus à prix d'or, fabriqués dans des usines du bout du monde dont on
dit qu'elles pratiquent des méthodes d'encadrement à la limite du supportable
avec, régulièrement, des drames humains, des jacqueries d'ouvriers, et des
interruptions des lignes de production que les médias relaient fréquemment.

Un smartphone « Up to Date » cumule à lui seul ce qu'un ordinateur, une tablette
et un écran TV fournissent en plus de la téléphonie. Son cycle de vie est
généralement estimé à trois ou quatre ans. Or les nouveautés se bousculent
actuellement tous les 18 mois à peu près et incitent les utilisateurs à
délaisser un matériel encore parfaitement au niveau au profit d'un autre. Tous s'accordent
à penser qu'un consommateur lambda ne peut, en un aussi court laps de temps,
utiliser toutes les ressources et possibilités de son « I quelque chose », si
tant est qu'il en ait un réel besoin. A quand une appli native pour détourner
les transactions financières extra-terrestres ?

D'autres, comme le très sérieux Wall Street Journal, que l'on ne peut soupçonner
d'être l'agent du prosélytisme
anti-consummièriste, s'interrogent sur le sens de cette boulimie de produits
High Tech en temps de crise. Et prennent à l'appui des chiffres illustrant les
sacrifices que certains foyers américains consentent à faire pour
s'équiper de ces gadgets. 116 dollars de plus pour leur smartphone qu'en 2007 et
48 de moins pour l'alimentation,
126 de moins pour les loisirs !

Apple produit ses téléphones à un coût unitaire de 207 dollars pour un prix de
vente public environ quatre fois
supérieur. Ses marges actuelles en liquidités ont doublé en 18 mois et
atteignent maintenant la mirobolante
somme de 117 milliards de dollars ! A titre de comparaison, la NASA, l'agence
spatiale américaine à qui l'on doit la
conquête de la lune et la recherche actuelle d'une trace de vie microbienne sur
Mars, dispose d'un budget annuel
de... 16 milliards, dont 2,5 pour le robot Curiosity. Un exemple pas tant décalé
lorsque l'on sait que l'exploitation
de minerais de l'espace est une option sérieuse à l'épuisement de nos ressources
terrestres.
Une partie de ce pactole pourrait servir aux recettes fiscales des États, qui en
ont bien besoin en ce moment,
à améliorer les conditions de travail dans les unités de production, toutes
externalisées, voire à réimplanter de
l'activité socialement utile aux USA. Sauf que ces options sont loin d'être
prioritaires puisque le tycoon du Net a
annoncé ce printemps
absurd money.
________________________________________________

"Alf92" <alf921@gmail.com> a écrit

histoire de relancer ce thread moribond :
http://cjoint.com/12oc/BJgtYViZtdi_2012-10-06_19.41.05r.jpg
c'est dans le Monde de ce soir (samedi 6 octobre) et ça résume parfaitement ce
que je pense d'Apple depuis quelques années.
pour ceux qui veulent lire l'article en ligne, je viens de le trouver là :
http://www.lemonde.fr/technologies/article/2012/10/05/apple-face-au-choc-des-realites_1770780_651865.html

un dernier pour la route ?
c'est parti !

________________________________________________
http://www.aduf.org/archives/pdf/2107.pdf

Et si nous prenions un peu de recul ? La cas de la Pomme...

A peine sorti, l'Iphone 5 est au coeur des conversations que l'on soit geek,
cadre, employé ou les trois à la fois... Toutes les couches sociales semblent
prises par la magie de la marque à la Pomme. Celle qui eut le flair de trouver
dans les ressorts de notre inconscient le déclic « I », le génial préfixe des
trois produits de rupture imaginé par Steve Jobs après avoir pris les rennes d'une
entreprise à la dérive depuis quinze ans. Ipad, Iphone, IPod, ou comment mon moi
(I = Je en anglais...), ma singularité, se projettent dans un produit tactile,
smart, branché, technologiquement en pointe. En gros, « J'existe +++ grâce à
lui », les autres le voient et on appartient à la communauté élue.

Reste maintenant à s'interroger sur les besoins réellement couverts par ces
gadgets vendus à prix d'or, fabriqués dans des usines du bout du monde dont on
dit qu'elles pratiquent des méthodes d'encadrement à la limite du supportable
avec, régulièrement, des drames humains, des jacqueries d'ouvriers, et des
interruptions des lignes de production que les médias relaient fréquemment.

Un smartphone « Up to Date » cumule à lui seul ce qu'un ordinateur, une tablette
et un écran TV fournissent en plus de la téléphonie. Son cycle de vie est
généralement estimé à trois ou quatre ans. Or les nouveautés se bousculent
actuellement tous les 18 mois à peu près et incitent les utilisateurs à
délaisser un matériel encore parfaitement au niveau au profit d'un autre. Tous s'accordent
à penser qu'un consommateur lambda ne peut, en un aussi court laps de temps,
utiliser toutes les ressources et possibilités de son « I quelque chose », si
tant est qu'il en ait un réel besoin. A quand une appli native pour détourner
les transactions financières extra-terrestres ?

D'autres, comme le très sérieux Wall Street Journal, que l'on ne peut soupçonner
d'être l'agent du prosélytisme
anti-consummièriste, s'interrogent sur le sens de cette boulimie de produits
High Tech en temps de crise. Et prennent à l'appui des chiffres illustrant les
sacrifices que certains foyers américains consentent à faire pour
s'équiper de ces gadgets. 116 dollars de plus pour leur smartphone qu'en 2007 et
48 de moins pour l'alimentation,
126 de moins pour les loisirs !

Apple produit ses téléphones à un coût unitaire de 207 dollars pour un prix de
vente public environ quatre fois
supérieur. Ses marges actuelles en liquidités ont doublé en 18 mois et
atteignent maintenant la mirobolante
somme de 117 milliards de dollars ! A titre de comparaison, la NASA, l'agence
spatiale américaine à qui l'on doit la
conquête de la lune et la recherche actuelle d'une trace de vie microbienne sur
Mars, dispose d'un budget annuel
de... 16 milliards, dont 2,5 pour le robot Curiosity. Un exemple pas tant décalé
lorsque l'on sait que l'exploitation
de minerais de l'espace est une option sérieuse à l'épuisement de nos ressources
terrestres.
Une partie de ce pactole pourrait servir aux recettes fiscales des États, qui en
ont bien besoin en ce moment,
à améliorer les conditions de travail dans les unités de production, toutes
externalisées, voire à réimplanter de
l'activité socialement utile aux USA. Sauf que ces options sont loin d'être
prioritaires puisque le tycoon du Net a
annoncé ce printemps
absurd money.
________________________________________________

Vous avez filtré cet utilisateur ! Consultez son message

"Alf92" a écrit

histoire de relancer ce thread moribond :
http://cjoint.com/12oc/BJgtYViZtdi_2012-10-06_19.41.05r.jpg
c'est dans le Monde de ce soir (samedi 6 octobre) et ça résume parfaitement ce
que je pense d'Apple depuis quelques années.
pour ceux qui veulent lire l'article en ligne, je viens de le trouver là :
http://www.lemonde.fr/technologies/article/2012/10/05/apple-face-au-choc-des-realites_1770780_651865.html

un dernier pour la route ?
c'est parti !

________________________________________________
http://www.aduf.org/archives/pdf/2107.pdf

Et si nous prenions un peu de recul ? La cas de la Pomme...

A peine sorti, l'Iphone 5 est au coeur des conversations que l'on soit geek,
cadre, employé ou les trois à la fois... Toutes les couches sociales semblent
prises par la magie de la marque à la Pomme. Celle qui eut le flair de trouver
dans les ressorts de notre inconscient le déclic « I », le génial préfixe des
trois produits de rupture imaginé par Steve Jobs après avoir pris les rennes d'une
entreprise à la dérive depuis quinze ans. Ipad, Iphone, IPod, ou comment mon moi
(I = Je en anglais...), ma singularité, se projettent dans un produit tactile,
smart, branché, technologiquement en pointe. En gros, « J'existe +++ grâce à
lui », les autres le voient et on appartient à la communauté élue.

Reste maintenant à s'interroger sur les besoins réellement couverts par ces
gadgets vendus à prix d'or, fabriqués dans des usines du bout du monde dont on
dit qu'elles pratiquent des méthodes d'encadrement à la limite du supportable
avec, régulièrement, des drames humains, des jacqueries d'ouvriers, et des
interruptions des lignes de production que les médias relaient fréquemment.

Un smartphone « Up to Date » cumule à lui seul ce qu'un ordinateur, une tablette
et un écran TV fournissent en plus de la téléphonie. Son cycle de vie est
généralement estimé à trois ou quatre ans. Or les nouveautés se bousculent
actuellement tous les 18 mois à peu près et incitent les utilisateurs à
délaisser un matériel encore parfaitement au niveau au profit d'un autre. Tous s'accordent
à penser qu'un consommateur lambda ne peut, en un aussi court laps de temps,
utiliser toutes les ressources et possibilités de son « I quelque chose », si
tant est qu'il en ait un réel besoin. A quand une appli native pour détourner
les transactions financières extra-terrestres ?

D'autres, comme le très sérieux Wall Street Journal, que l'on ne peut soupçonner
d'être l'agent du prosélytisme
anti-consummièriste, s'interrogent sur le sens de cette boulimie de produits
High Tech en temps de crise. Et prennent à l'appui des chiffres illustrant les
sacrifices que certains foyers américains consentent à faire pour
s'équiper de ces gadgets. 116 dollars de plus pour leur smartphone qu'en 2007 et
48 de moins pour l'alimentation,
126 de moins pour les loisirs !

Apple produit ses téléphones à un coût unitaire de 207 dollars pour un prix de
vente public environ quatre fois
supérieur. Ses marges actuelles en liquidités ont doublé en 18 mois et
atteignent maintenant la mirobolante
somme de 117 milliards de dollars ! A titre de comparaison, la NASA, l'agence
spatiale américaine à qui l'on doit la
conquête de la lune et la recherche actuelle d'une trace de vie microbienne sur
Mars, dispose d'un budget annuel
de... 16 milliards, dont 2,5 pour le robot Curiosity. Un exemple pas tant décalé
lorsque l'on sait que l'exploitation
de minerais de l'espace est une option sérieuse à l'épuisement de nos ressources
terrestres.
Une partie de ce pactole pourrait servir aux recettes fiscales des États, qui en
ont bien besoin en ce moment,
à améliorer les conditions de travail dans les unités de production, toutes
externalisées, voire à réimplanter de
l'activité socialement utile aux USA. Sauf que ces options sont loin d'être
prioritaires puisque le tycoon du Net a
annoncé ce printemps
absurd money.
________________________________________________

jdd

10/10/2012 à 10:26

Le 09/10/2012 22:48, MELMOTH a écrit :

*2227* à 22H45 le 9 octobre 2012...
Melmothéen, comme Il Se doit...

tu trouve ça comment?
jdd

--
http://www.dodin.net
Le wiki des forums son-image français: http://dodin.org/frsv/
http://jddtube.dodin.org/20120616-52-highway_v1115

markorki

10/10/2012 à 11:01

FiLH a écrit :

markorki<moicestmarkorkichezorangefr> wrote:

T'as pas de chance, moi j'ai connu de vrais génies dans ces années là,

T'as pas de chance... moi aussi :)

ben ça ne me gène pas...

enfin, des gens qui utilisaient peut-être nettement plus de 10% des
capacités de leur encéphale, des qui codaient proprement,

Tu oublies que la notion de « coder proprement » est devenu bien plus
exigeante depuis.

Maintenant, il faut respecter des normes de programmation, interfaces
standards, normes même sur lenommage des variables, des tas de trucs :
ce genre de trucs j'en ai spécifié dans les années 80 et de-ci de-là
jusqu'en passé 2000.

La seule évolution est la précision des specs qui s'est approfondie, et
les kg de "non papier" que ça engendre.

A l'époque il n'y avait pas de normes (encore qu'il y avait la bande à
Stallman, thompson et autres, et ajouter un perif (un coupleur de comms
par exemple) ou une fonctionnalité dans un Unix supposait déjà
derespecter un certain nombre disons d' "usages".

Par exemple, en 82 ou 83, on faisait du multi-fenétrage sur écran
monochrome, en 1024*768, avec déjà un équivalent X11 (c'est-à-dire des
terminaux textes déplaçables / superposables tous vus comme maintenant
des xterm) mais ce n'était que des "outils" pour des développements qui
touchaient aux télécomms.

Je maintiens que dès cette époque, chez certains, il y a avit des normes
préises, mais évidemment dont la portée était une équipe de
développement, voire un établissement.

devinaient
tout de suite où un autre allait ne pas voir un détail pourtant
important, et pouvaient tenir plusieurs conversations à la fois tout en
débuggant un driver, un dispatcher ou un compilateur...

Et ils cuisaient des pizza à la chaleur de leur front aussi... ahh... le
beau temps d'antan où le lait coulait à flot dans des rivières de
miel...

Des qui aidaient simultanément plusieurs personnes au debug tout en
tapotant sur plusieurs terminaux et en testant leurs modifs, je n'en ai
connu que deux, où j'étais. Je doute qu'il n'y en ait pas eu ailleurs ;-)
Mais en dehors de ce multi-processing extrème, des "gourous" j'en ai
connu d'autres.

... et quand tu codais sur des gros minis à l'époque, les codes étaient
peut-être "moins utilisés", mais par des gens plus exigeants et/ou plus
soucieux de faire du bon boulot.

Non. Par des gens qui bossaient sur des codes plus petits qui faisaient
bien moins de choses, qui n'étaient pas portables, qui utilisaient des
astuces indémerdables par quelqu'un d'autre que leur auteur.
Des codes suffisament petit pour être maintenus par de toutes petites
équipes.

Des codes qui font plus de choses...
Ils en font trop, le découpage en modules, ça existe, et le test
exhaustif, ça n'existe plus.
Un projet se pilote maintenant comme un avion de ligne: on fait des
hypothèses sur les tests à ne pas faire comme les pilotes négocient un
décollage avec un (ou des) organe(s) foireux.

Pas question de répondre "ça marchera peut-être dans laprochaine
version, mais pour l'instant on étudie le pb".

Parce qu'à l'époque on avait des codes simples qui ne dépendaient pas
d'autres codes et qui n'avaient pas de dépendances.

Désolé, mais les dépendances et les outils pour les gérer, ça avait été
absorbé par les "règles de l'art" depuis des années dans le monde mini
en 80.

La gestion de la complexité croissante s'appuie sur des outils également
plus complexes, ça ne devrait pas marcher plus mal.

J'ai l'impression à te lire que tu n'as aucune idée de ce que peut-être
un cycle de production de code.

À l'époque ils ne prenaient pas le temps de faire de tests de régression
par exemple. Là ça prend du temps.

????
J'ai quitté ce monde en 87 pour aller faire une autre informatique
(moins "système") pour changer de région, mais en 87 il y avait
longtemps qu'on intégrait aux jeux de tests et aux plans de tests tout
test ayant servi à vérifier la correction d'un bug, tout ce qui avait
fait l'objet d'une vérif sur une version le faisait dans toutes les
versions qui suivaient.
Si ce n'est pas de la non-régression, je ne sais pas ce que c'est.

A l'époque, les gens qui bossaient sur le système ne laissaient pas un
plantage inexploité :

Aujourd'hui ce ne serait pas UN plantage mais des centaines de miliers.
Donc imagine combien tu payerais ton logiciel si tu devais faire
analyser TOUS les dumps.

Mauvais argument : il y aurait peut-être des millier de plantages, mais
qui peuvent reposer sur les mêmes quelques erreurs élémentaires, le
millier de plantages n'étant dû qu'à la non correction pour cause de
non-analyse du premier.

J'ai connu ce pb, j'étais scié quand je sortais de mon équipe, de voir
que chez certains, un plantage donnait lieu à un fsck, et roule ma poule
: personne ne se demandait pourquoi, d'où forcément récidive avant
longtemps.
Essayer de comprendre était "une perte de temps". Apparemment, les n
reboots, les fsck et éventuellement les pertes de données n'en étaient
pas...

dump de toute la mémoire, et analyse avec les
moyens du bord... analyseur de "core dump" ou analyse "à la main" à
partir de l'état de la pile sysytème au moment du plantage, et en
descendant les tables système comme des grands. La motivation palliait
plus que largement la rusticité des outils, et un bug du noyau ne
trainait pas plus de quelques jours.

Un dump aujourd'hui ce n'est pas 16K comme à l'époque dont tu parles
mais 4Go ou plus.. je te laisse faire le calcul.

16KO dans les années 80 ???

tu étais né, t'es sûr ??
16KO, c'est l'ordre de grandeur (en moins gros) de la mémoire de
certains coupleurs à base de 6809, juste **coupleur**, hein.
Sur un mini multiprocesseur, la mémoire d'une carte processeur pouvait
quand-même se compter en MO, même s'il n'y en avait pas beaucoup:
l'apparition des MMU, c'est le début des années 80 (en fait, c'est
plutôt dès 1978, mais sur des minis à processeur "dispersé", ou
"discret" par opposition au processeur en un seul circuit intégré, et en
82 ou 83 chez Intel et Motorola).

Ne t'en fais pas j'ai AUSSI fait du débuggage sur dump imprimé de la
mémoire, je connais le taf.

Ah.. à l'époque on codait les années sur deux chiffres... preuve que tes
prétendus génies ne pensaient pas à tout :

Pas sûr.

D'une part, le codage de la date est de la responsabilité de ceux qui
ont codé le coeur du noyau, pas d'équipes éloignées qui ajoutent des
extensions.
D'autre part, aucun reproche à faire aux "génies" qui ont pondu Unix: le
temps sous Unix est compté en secondes à partir d'une date de référence,
et ça passe plus que largement l'an 2000 ou 3000 (l'offset ne doit pas
être déclaré en "byte" ;-).
C'est au niveau applicatif (ou chez les visionnaires à lunettes) que de
gros malins ont "allégé" le codage de la date.

FiLH a écrit :

markorki<moicestmarkorkichezorangefr> wrote:

T'as pas de chance, moi j'ai connu de vrais génies dans ces années là,

T'as pas de chance... moi aussi :)

ben ça ne me gène pas...

enfin, des gens qui utilisaient peut-être nettement plus de 10% des
capacités de leur encéphale, des qui codaient proprement,

Tu oublies que la notion de « coder proprement » est devenu bien plus
exigeante depuis.

Maintenant, il faut respecter des normes de programmation, interfaces
standards, normes même sur lenommage des variables, des tas de trucs :
ce genre de trucs j'en ai spécifié dans les années 80 et de-ci de-là
jusqu'en passé 2000.

La seule évolution est la précision des specs qui s'est approfondie, et
les kg de "non papier" que ça engendre.

A l'époque il n'y avait pas de normes (encore qu'il y avait la bande à
Stallman, thompson et autres, et ajouter un perif (un coupleur de comms
par exemple) ou une fonctionnalité dans un Unix supposait déjà
derespecter un certain nombre disons d' "usages".

Par exemple, en 82 ou 83, on faisait du multi-fenétrage sur écran
monochrome, en 1024*768, avec déjà un équivalent X11 (c'est-à-dire des
terminaux textes déplaçables / superposables tous vus comme maintenant
des xterm) mais ce n'était que des "outils" pour des développements qui
touchaient aux télécomms.

Je maintiens que dès cette époque, chez certains, il y a avit des normes
préises, mais évidemment dont la portée était une équipe de
développement, voire un établissement.

devinaient
tout de suite où un autre allait ne pas voir un détail pourtant
important, et pouvaient tenir plusieurs conversations à la fois tout en
débuggant un driver, un dispatcher ou un compilateur...

Et ils cuisaient des pizza à la chaleur de leur front aussi... ahh... le
beau temps d'antan où le lait coulait à flot dans des rivières de
miel...

Des qui aidaient simultanément plusieurs personnes au debug tout en
tapotant sur plusieurs terminaux et en testant leurs modifs, je n'en ai
connu que deux, où j'étais. Je doute qu'il n'y en ait pas eu ailleurs ;-)
Mais en dehors de ce multi-processing extrème, des "gourous" j'en ai
connu d'autres.

... et quand tu codais sur des gros minis à l'époque, les codes étaient
peut-être "moins utilisés", mais par des gens plus exigeants et/ou plus
soucieux de faire du bon boulot.

Non. Par des gens qui bossaient sur des codes plus petits qui faisaient
bien moins de choses, qui n'étaient pas portables, qui utilisaient des
astuces indémerdables par quelqu'un d'autre que leur auteur.
Des codes suffisament petit pour être maintenus par de toutes petites
équipes.

Des codes qui font plus de choses...
Ils en font trop, le découpage en modules, ça existe, et le test
exhaustif, ça n'existe plus.
Un projet se pilote maintenant comme un avion de ligne: on fait des
hypothèses sur les tests à ne pas faire comme les pilotes négocient un
décollage avec un (ou des) organe(s) foireux.

Pas question de répondre "ça marchera peut-être dans laprochaine
version, mais pour l'instant on étudie le pb".

Parce qu'à l'époque on avait des codes simples qui ne dépendaient pas
d'autres codes et qui n'avaient pas de dépendances.

Désolé, mais les dépendances et les outils pour les gérer, ça avait été
absorbé par les "règles de l'art" depuis des années dans le monde mini
en 80.

La gestion de la complexité croissante s'appuie sur des outils également
plus complexes, ça ne devrait pas marcher plus mal.

J'ai l'impression à te lire que tu n'as aucune idée de ce que peut-être
un cycle de production de code.

À l'époque ils ne prenaient pas le temps de faire de tests de régression
par exemple. Là ça prend du temps.

????
J'ai quitté ce monde en 87 pour aller faire une autre informatique
(moins "système") pour changer de région, mais en 87 il y avait
longtemps qu'on intégrait aux jeux de tests et aux plans de tests tout
test ayant servi à vérifier la correction d'un bug, tout ce qui avait
fait l'objet d'une vérif sur une version le faisait dans toutes les
versions qui suivaient.
Si ce n'est pas de la non-régression, je ne sais pas ce que c'est.

A l'époque, les gens qui bossaient sur le système ne laissaient pas un
plantage inexploité :

Aujourd'hui ce ne serait pas UN plantage mais des centaines de miliers.
Donc imagine combien tu payerais ton logiciel si tu devais faire
analyser TOUS les dumps.

Mauvais argument : il y aurait peut-être des millier de plantages, mais
qui peuvent reposer sur les mêmes quelques erreurs élémentaires, le
millier de plantages n'étant dû qu'à la non correction pour cause de
non-analyse du premier.

J'ai connu ce pb, j'étais scié quand je sortais de mon équipe, de voir
que chez certains, un plantage donnait lieu à un fsck, et roule ma poule
: personne ne se demandait pourquoi, d'où forcément récidive avant
longtemps.
Essayer de comprendre était "une perte de temps". Apparemment, les n
reboots, les fsck et éventuellement les pertes de données n'en étaient
pas...

dump de toute la mémoire, et analyse avec les
moyens du bord... analyseur de "core dump" ou analyse "à la main" à
partir de l'état de la pile sysytème au moment du plantage, et en
descendant les tables système comme des grands. La motivation palliait
plus que largement la rusticité des outils, et un bug du noyau ne
trainait pas plus de quelques jours.

Un dump aujourd'hui ce n'est pas 16K comme à l'époque dont tu parles
mais 4Go ou plus.. je te laisse faire le calcul.

16KO dans les années 80 ???

tu étais né, t'es sûr ??
16KO, c'est l'ordre de grandeur (en moins gros) de la mémoire de
certains coupleurs à base de 6809, juste **coupleur**, hein.
Sur un mini multiprocesseur, la mémoire d'une carte processeur pouvait
quand-même se compter en MO, même s'il n'y en avait pas beaucoup:
l'apparition des MMU, c'est le début des années 80 (en fait, c'est
plutôt dès 1978, mais sur des minis à processeur "dispersé", ou
"discret" par opposition au processeur en un seul circuit intégré, et en
82 ou 83 chez Intel et Motorola).

Ne t'en fais pas j'ai AUSSI fait du débuggage sur dump imprimé de la
mémoire, je connais le taf.

Ah.. à l'époque on codait les années sur deux chiffres... preuve que tes
prétendus génies ne pensaient pas à tout :

Pas sûr.

D'une part, le codage de la date est de la responsabilité de ceux qui
ont codé le coeur du noyau, pas d'équipes éloignées qui ajoutent des
extensions.
D'autre part, aucun reproche à faire aux "génies" qui ont pondu Unix: le
temps sous Unix est compté en secondes à partir d'une date de référence,
et ça passe plus que largement l'an 2000 ou 3000 (l'offset ne doit pas
être déclaré en "byte" ;-).
C'est au niveau applicatif (ou chez les visionnaires à lunettes) que de
gros malins ont "allégé" le codage de la date.

Vous avez filtré cet utilisateur ! Consultez son message

FiLH a écrit :

markorki<moicestmarkorkichezorangefr> wrote:

T'as pas de chance, moi j'ai connu de vrais génies dans ces années là,

T'as pas de chance... moi aussi :)

ben ça ne me gène pas...

enfin, des gens qui utilisaient peut-être nettement plus de 10% des
capacités de leur encéphale, des qui codaient proprement,

Tu oublies que la notion de « coder proprement » est devenu bien plus
exigeante depuis.

Maintenant, il faut respecter des normes de programmation, interfaces
standards, normes même sur lenommage des variables, des tas de trucs :
ce genre de trucs j'en ai spécifié dans les années 80 et de-ci de-là
jusqu'en passé 2000.

La seule évolution est la précision des specs qui s'est approfondie, et
les kg de "non papier" que ça engendre.

A l'époque il n'y avait pas de normes (encore qu'il y avait la bande à
Stallman, thompson et autres, et ajouter un perif (un coupleur de comms
par exemple) ou une fonctionnalité dans un Unix supposait déjà
derespecter un certain nombre disons d' "usages".

Par exemple, en 82 ou 83, on faisait du multi-fenétrage sur écran
monochrome, en 1024*768, avec déjà un équivalent X11 (c'est-à-dire des
terminaux textes déplaçables / superposables tous vus comme maintenant
des xterm) mais ce n'était que des "outils" pour des développements qui
touchaient aux télécomms.

Je maintiens que dès cette époque, chez certains, il y a avit des normes
préises, mais évidemment dont la portée était une équipe de
développement, voire un établissement.

devinaient
tout de suite où un autre allait ne pas voir un détail pourtant
important, et pouvaient tenir plusieurs conversations à la fois tout en
débuggant un driver, un dispatcher ou un compilateur...

Et ils cuisaient des pizza à la chaleur de leur front aussi... ahh... le
beau temps d'antan où le lait coulait à flot dans des rivières de
miel...

Des qui aidaient simultanément plusieurs personnes au debug tout en
tapotant sur plusieurs terminaux et en testant leurs modifs, je n'en ai
connu que deux, où j'étais. Je doute qu'il n'y en ait pas eu ailleurs ;-)
Mais en dehors de ce multi-processing extrème, des "gourous" j'en ai
connu d'autres.

... et quand tu codais sur des gros minis à l'époque, les codes étaient
peut-être "moins utilisés", mais par des gens plus exigeants et/ou plus
soucieux de faire du bon boulot.

Non. Par des gens qui bossaient sur des codes plus petits qui faisaient
bien moins de choses, qui n'étaient pas portables, qui utilisaient des
astuces indémerdables par quelqu'un d'autre que leur auteur.
Des codes suffisament petit pour être maintenus par de toutes petites
équipes.

Des codes qui font plus de choses...
Ils en font trop, le découpage en modules, ça existe, et le test
exhaustif, ça n'existe plus.
Un projet se pilote maintenant comme un avion de ligne: on fait des
hypothèses sur les tests à ne pas faire comme les pilotes négocient un
décollage avec un (ou des) organe(s) foireux.

Pas question de répondre "ça marchera peut-être dans laprochaine
version, mais pour l'instant on étudie le pb".

Parce qu'à l'époque on avait des codes simples qui ne dépendaient pas
d'autres codes et qui n'avaient pas de dépendances.

Désolé, mais les dépendances et les outils pour les gérer, ça avait été
absorbé par les "règles de l'art" depuis des années dans le monde mini
en 80.

La gestion de la complexité croissante s'appuie sur des outils également
plus complexes, ça ne devrait pas marcher plus mal.

J'ai l'impression à te lire que tu n'as aucune idée de ce que peut-être
un cycle de production de code.

À l'époque ils ne prenaient pas le temps de faire de tests de régression
par exemple. Là ça prend du temps.

????
J'ai quitté ce monde en 87 pour aller faire une autre informatique
(moins "système") pour changer de région, mais en 87 il y avait
longtemps qu'on intégrait aux jeux de tests et aux plans de tests tout
test ayant servi à vérifier la correction d'un bug, tout ce qui avait
fait l'objet d'une vérif sur une version le faisait dans toutes les
versions qui suivaient.
Si ce n'est pas de la non-régression, je ne sais pas ce que c'est.

A l'époque, les gens qui bossaient sur le système ne laissaient pas un
plantage inexploité :

Aujourd'hui ce ne serait pas UN plantage mais des centaines de miliers.
Donc imagine combien tu payerais ton logiciel si tu devais faire
analyser TOUS les dumps.

Mauvais argument : il y aurait peut-être des millier de plantages, mais
qui peuvent reposer sur les mêmes quelques erreurs élémentaires, le
millier de plantages n'étant dû qu'à la non correction pour cause de
non-analyse du premier.

J'ai connu ce pb, j'étais scié quand je sortais de mon équipe, de voir
que chez certains, un plantage donnait lieu à un fsck, et roule ma poule
: personne ne se demandait pourquoi, d'où forcément récidive avant
longtemps.
Essayer de comprendre était "une perte de temps". Apparemment, les n
reboots, les fsck et éventuellement les pertes de données n'en étaient
pas...

dump de toute la mémoire, et analyse avec les
moyens du bord... analyseur de "core dump" ou analyse "à la main" à
partir de l'état de la pile sysytème au moment du plantage, et en
descendant les tables système comme des grands. La motivation palliait
plus que largement la rusticité des outils, et un bug du noyau ne
trainait pas plus de quelques jours.

Un dump aujourd'hui ce n'est pas 16K comme à l'époque dont tu parles
mais 4Go ou plus.. je te laisse faire le calcul.

16KO dans les années 80 ???

tu étais né, t'es sûr ??
16KO, c'est l'ordre de grandeur (en moins gros) de la mémoire de
certains coupleurs à base de 6809, juste **coupleur**, hein.
Sur un mini multiprocesseur, la mémoire d'une carte processeur pouvait
quand-même se compter en MO, même s'il n'y en avait pas beaucoup:
l'apparition des MMU, c'est le début des années 80 (en fait, c'est
plutôt dès 1978, mais sur des minis à processeur "dispersé", ou
"discret" par opposition au processeur en un seul circuit intégré, et en
82 ou 83 chez Intel et Motorola).

Ne t'en fais pas j'ai AUSSI fait du débuggage sur dump imprimé de la
mémoire, je connais le taf.

Ah.. à l'époque on codait les années sur deux chiffres... preuve que tes
prétendus génies ne pensaient pas à tout :

Pas sûr.

D'une part, le codage de la date est de la responsabilité de ceux qui
ont codé le coeur du noyau, pas d'équipes éloignées qui ajoutent des
extensions.
D'autre part, aucun reproche à faire aux "génies" qui ont pondu Unix: le
temps sous Unix est compté en secondes à partir d'une date de référence,
et ça passe plus que largement l'an 2000 ou 3000 (l'offset ne doit pas
être déclaré en "byte" ;-).
C'est au niveau applicatif (ou chez les visionnaires à lunettes) que de
gros malins ont "allégé" le codage de la date.

abc abc

10/10/2012 à 11:29

On 2012-10-10, markorki <moicestmarkorkichezorangefr> wrote:

FiLH a écrit :
markorki<moicestmarkorkichezorangefr> wrote:

T'as pas de chance, moi j'ai connu de vrais génies dans ces années là,

T'as pas de chance... moi aussi :)

ben ça ne me gène pas...

enfin, des gens qui utilisaient peut-être nettement plus de 10% des
capacités de leur encéphale, des qui codaient proprement,

Tu oublies que la notion de « coder proprement » est devenu bien plus
exigeante depuis.

Maintenant, il faut respecter des normes de programmation, interfaces
standards, normes même sur lenommage des variables, des tas de trucs :
ce genre de trucs j'en ai spécifié dans les années 80 et de-ci de-là
jusqu'en passé 2000.

La seule évolution est la précision des specs qui s'est approfondie, et
les kg de "non papier" que ça engendre.

A l'époque il n'y avait pas de normes (encore qu'il y avait la bande à
Stallman, thompson et autres, et ajouter un perif (un coupleur de comms
par exemple) ou une fonctionnalité dans un Unix supposait déjà
derespecter un certain nombre disons d' "usages".

Par exemple, en 82 ou 83, on faisait du multi-fenétrage sur écran
monochrome, en 1024*768, avec déjà un équivalent X11 (c'est-à-dire des
terminaux textes déplaçables / superposables tous vus comme maintenant
des xterm) mais ce n'était que des "outils" pour des développements qui
touchaient aux télécomms.

Je maintiens que dès cette époque, chez certains, il y a avit des normes
préises, mais évidemment dont la portée était une équipe de
développement, voire un établissement.

devinaient
tout de suite où un autre allait ne pas voir un détail pourtant
important, et pouvaient tenir plusieurs conversations à la fois tout en
débuggant un driver, un dispatcher ou un compilateur...

Et ils cuisaient des pizza à la chaleur de leur front aussi... ahh... le
beau temps d'antan où le lait coulait à flot dans des rivières de
miel...

Des qui aidaient simultanément plusieurs personnes au debug tout en
tapotant sur plusieurs terminaux et en testant leurs modifs, je n'en ai
connu que deux, où j'étais. Je doute qu'il n'y en ait pas eu ailleurs ;-)
Mais en dehors de ce multi-processing extrème, des "gourous" j'en ai
connu d'autres.

... et quand tu codais sur des gros minis à l'époque, les codes étaient
peut-être "moins utilisés", mais par des gens plus exigeants et/ou plus
soucieux de faire du bon boulot.

Non. Par des gens qui bossaient sur des codes plus petits qui faisaient
bien moins de choses, qui n'étaient pas portables, qui utilisaient des
astuces indémerdables par quelqu'un d'autre que leur auteur.
Des codes suffisament petit pour être maintenus par de toutes petites
équipes.

Des codes qui font plus de choses...
Ils en font trop, le découpage en modules, ça existe, et le test
exhaustif, ça n'existe plus.
Un projet se pilote maintenant comme un avion de ligne: on fait des
hypothèses sur les tests à ne pas faire comme les pilotes négocient un
décollage avec un (ou des) organe(s) foireux.

Pas question de répondre "ça marchera peut-être dans laprochaine
version, mais pour l'instant on étudie le pb".

Parce qu'à l'époque on avait des codes simples qui ne dépendaient pas
d'autres codes et qui n'avaient pas de dépendances.

Désolé, mais les dépendances et les outils pour les gérer, ça avait été
absorbé par les "règles de l'art" depuis des années dans le monde mini
en 80.

La gestion de la complexité croissante s'appuie sur des outils également
plus complexes, ça ne devrait pas marcher plus mal.

J'ai l'impression à te lire que tu n'as aucune idée de ce que peut-être
un cycle de production de code.

À l'époque ils ne prenaient pas le temps de faire de tests de régression
par exemple. Là ça prend du temps.

????
J'ai quitté ce monde en 87 pour aller faire une autre informatique
(moins "système") pour changer de région, mais en 87 il y avait
longtemps qu'on intégrait aux jeux de tests et aux plans de tests tout
test ayant servi à vérifier la correction d'un bug, tout ce qui avait
fait l'objet d'une vérif sur une version le faisait dans toutes les
versions qui suivaient.
Si ce n'est pas de la non-régression, je ne sais pas ce que c'est.

A l'époque, les gens qui bossaient sur le système ne laissaient pas un
plantage inexploité :

Aujourd'hui ce ne serait pas UN plantage mais des centaines de miliers.
Donc imagine combien tu payerais ton logiciel si tu devais faire
analyser TOUS les dumps.

Mauvais argument : il y aurait peut-être des millier de plantages, mais
qui peuvent reposer sur les mêmes quelques erreurs élémentaires, le
millier de plantages n'étant dû qu'à la non correction pour cause de
non-analyse du premier.

J'ai connu ce pb, j'étais scié quand je sortais de mon équipe, de voir
que chez certains, un plantage donnait lieu à un fsck, et roule ma poule
: personne ne se demandait pourquoi, d'où forcément récidive avant
longtemps.
Essayer de comprendre était "une perte de temps". Apparemment, les n
reboots, les fsck et éventuellement les pertes de données n'en étaient
pas...

dump de toute la mémoire, et analyse avec les
moyens du bord... analyseur de "core dump" ou analyse "à la main" à
partir de l'état de la pile sysytème au moment du plantage, et en
descendant les tables système comme des grands. La motivation palliait
plus que largement la rusticité des outils, et un bug du noyau ne
trainait pas plus de quelques jours.

Un dump aujourd'hui ce n'est pas 16K comme à l'époque dont tu parles
mais 4Go ou plus.. je te laisse faire le calcul.

16KO dans les années 80 ???

De toute facon, la taille du dump n'a pas grande importance. Ca change
rien, la difficulté à analyser un dump dépend pas de sa taille.

On 2012-10-10, markorki <moicestmarkorkichezorangefr> wrote:

FiLH a écrit :

markorki<moicestmarkorkichezorangefr> wrote:

T'as pas de chance, moi j'ai connu de vrais génies dans ces années là,

T'as pas de chance... moi aussi :)

ben ça ne me gène pas...

enfin, des gens qui utilisaient peut-être nettement plus de 10% des
capacités de leur encéphale, des qui codaient proprement,

Tu oublies que la notion de « coder proprement » est devenu bien plus
exigeante depuis.

Maintenant, il faut respecter des normes de programmation, interfaces
standards, normes même sur lenommage des variables, des tas de trucs :
ce genre de trucs j'en ai spécifié dans les années 80 et de-ci de-là
jusqu'en passé 2000.

La seule évolution est la précision des specs qui s'est approfondie, et
les kg de "non papier" que ça engendre.

A l'époque il n'y avait pas de normes (encore qu'il y avait la bande à
Stallman, thompson et autres, et ajouter un perif (un coupleur de comms
par exemple) ou une fonctionnalité dans un Unix supposait déjà
derespecter un certain nombre disons d' "usages".

Par exemple, en 82 ou 83, on faisait du multi-fenétrage sur écran
monochrome, en 1024*768, avec déjà un équivalent X11 (c'est-à-dire des
terminaux textes déplaçables / superposables tous vus comme maintenant
des xterm) mais ce n'était que des "outils" pour des développements qui
touchaient aux télécomms.

Je maintiens que dès cette époque, chez certains, il y a avit des normes
préises, mais évidemment dont la portée était une équipe de
développement, voire un établissement.

devinaient
tout de suite où un autre allait ne pas voir un détail pourtant
important, et pouvaient tenir plusieurs conversations à la fois tout en
débuggant un driver, un dispatcher ou un compilateur...

Et ils cuisaient des pizza à la chaleur de leur front aussi... ahh... le
beau temps d'antan où le lait coulait à flot dans des rivières de
miel...

Des qui aidaient simultanément plusieurs personnes au debug tout en
tapotant sur plusieurs terminaux et en testant leurs modifs, je n'en ai
connu que deux, où j'étais. Je doute qu'il n'y en ait pas eu ailleurs ;-)
Mais en dehors de ce multi-processing extrème, des "gourous" j'en ai
connu d'autres.

... et quand tu codais sur des gros minis à l'époque, les codes étaient
peut-être "moins utilisés", mais par des gens plus exigeants et/ou plus
soucieux de faire du bon boulot.

Non. Par des gens qui bossaient sur des codes plus petits qui faisaient
bien moins de choses, qui n'étaient pas portables, qui utilisaient des
astuces indémerdables par quelqu'un d'autre que leur auteur.
Des codes suffisament petit pour être maintenus par de toutes petites
équipes.

Des codes qui font plus de choses...
Ils en font trop, le découpage en modules, ça existe, et le test
exhaustif, ça n'existe plus.
Un projet se pilote maintenant comme un avion de ligne: on fait des
hypothèses sur les tests à ne pas faire comme les pilotes négocient un
décollage avec un (ou des) organe(s) foireux.

Pas question de répondre "ça marchera peut-être dans laprochaine
version, mais pour l'instant on étudie le pb".

Parce qu'à l'époque on avait des codes simples qui ne dépendaient pas
d'autres codes et qui n'avaient pas de dépendances.

Désolé, mais les dépendances et les outils pour les gérer, ça avait été
absorbé par les "règles de l'art" depuis des années dans le monde mini
en 80.

La gestion de la complexité croissante s'appuie sur des outils également
plus complexes, ça ne devrait pas marcher plus mal.

J'ai l'impression à te lire que tu n'as aucune idée de ce que peut-être
un cycle de production de code.

À l'époque ils ne prenaient pas le temps de faire de tests de régression
par exemple. Là ça prend du temps.

????
J'ai quitté ce monde en 87 pour aller faire une autre informatique
(moins "système") pour changer de région, mais en 87 il y avait
longtemps qu'on intégrait aux jeux de tests et aux plans de tests tout
test ayant servi à vérifier la correction d'un bug, tout ce qui avait
fait l'objet d'une vérif sur une version le faisait dans toutes les
versions qui suivaient.
Si ce n'est pas de la non-régression, je ne sais pas ce que c'est.

A l'époque, les gens qui bossaient sur le système ne laissaient pas un
plantage inexploité :

Aujourd'hui ce ne serait pas UN plantage mais des centaines de miliers.
Donc imagine combien tu payerais ton logiciel si tu devais faire
analyser TOUS les dumps.

Mauvais argument : il y aurait peut-être des millier de plantages, mais
qui peuvent reposer sur les mêmes quelques erreurs élémentaires, le
millier de plantages n'étant dû qu'à la non correction pour cause de
non-analyse du premier.

J'ai connu ce pb, j'étais scié quand je sortais de mon équipe, de voir
que chez certains, un plantage donnait lieu à un fsck, et roule ma poule
: personne ne se demandait pourquoi, d'où forcément récidive avant
longtemps.
Essayer de comprendre était "une perte de temps". Apparemment, les n
reboots, les fsck et éventuellement les pertes de données n'en étaient
pas...

dump de toute la mémoire, et analyse avec les
moyens du bord... analyseur de "core dump" ou analyse "à la main" à
partir de l'état de la pile sysytème au moment du plantage, et en
descendant les tables système comme des grands. La motivation palliait
plus que largement la rusticité des outils, et un bug du noyau ne
trainait pas plus de quelques jours.

Un dump aujourd'hui ce n'est pas 16K comme à l'époque dont tu parles
mais 4Go ou plus.. je te laisse faire le calcul.

16KO dans les années 80 ???

De toute facon, la taille du dump n'a pas grande importance. Ca change
rien, la difficulté à analyser un dump dépend pas de sa taille.

Vous avez filtré cet utilisateur ! Consultez son message

On 2012-10-10, markorki <moicestmarkorkichezorangefr> wrote:

FiLH a écrit :
markorki<moicestmarkorkichezorangefr> wrote:

T'as pas de chance, moi j'ai connu de vrais génies dans ces années là,

T'as pas de chance... moi aussi :)

ben ça ne me gène pas...

enfin, des gens qui utilisaient peut-être nettement plus de 10% des
capacités de leur encéphale, des qui codaient proprement,

Tu oublies que la notion de « coder proprement » est devenu bien plus
exigeante depuis.

Maintenant, il faut respecter des normes de programmation, interfaces
standards, normes même sur lenommage des variables, des tas de trucs :
ce genre de trucs j'en ai spécifié dans les années 80 et de-ci de-là
jusqu'en passé 2000.

La seule évolution est la précision des specs qui s'est approfondie, et
les kg de "non papier" que ça engendre.

A l'époque il n'y avait pas de normes (encore qu'il y avait la bande à
Stallman, thompson et autres, et ajouter un perif (un coupleur de comms
par exemple) ou une fonctionnalité dans un Unix supposait déjà
derespecter un certain nombre disons d' "usages".

Par exemple, en 82 ou 83, on faisait du multi-fenétrage sur écran
monochrome, en 1024*768, avec déjà un équivalent X11 (c'est-à-dire des
terminaux textes déplaçables / superposables tous vus comme maintenant
des xterm) mais ce n'était que des "outils" pour des développements qui
touchaient aux télécomms.

Je maintiens que dès cette époque, chez certains, il y a avit des normes
préises, mais évidemment dont la portée était une équipe de
développement, voire un établissement.

devinaient
tout de suite où un autre allait ne pas voir un détail pourtant
important, et pouvaient tenir plusieurs conversations à la fois tout en
débuggant un driver, un dispatcher ou un compilateur...

Et ils cuisaient des pizza à la chaleur de leur front aussi... ahh... le
beau temps d'antan où le lait coulait à flot dans des rivières de
miel...

Des qui aidaient simultanément plusieurs personnes au debug tout en
tapotant sur plusieurs terminaux et en testant leurs modifs, je n'en ai
connu que deux, où j'étais. Je doute qu'il n'y en ait pas eu ailleurs ;-)
Mais en dehors de ce multi-processing extrème, des "gourous" j'en ai
connu d'autres.

... et quand tu codais sur des gros minis à l'époque, les codes étaient
peut-être "moins utilisés", mais par des gens plus exigeants et/ou plus
soucieux de faire du bon boulot.

Non. Par des gens qui bossaient sur des codes plus petits qui faisaient
bien moins de choses, qui n'étaient pas portables, qui utilisaient des
astuces indémerdables par quelqu'un d'autre que leur auteur.
Des codes suffisament petit pour être maintenus par de toutes petites
équipes.

Des codes qui font plus de choses...
Ils en font trop, le découpage en modules, ça existe, et le test
exhaustif, ça n'existe plus.
Un projet se pilote maintenant comme un avion de ligne: on fait des
hypothèses sur les tests à ne pas faire comme les pilotes négocient un
décollage avec un (ou des) organe(s) foireux.

Pas question de répondre "ça marchera peut-être dans laprochaine
version, mais pour l'instant on étudie le pb".

Parce qu'à l'époque on avait des codes simples qui ne dépendaient pas
d'autres codes et qui n'avaient pas de dépendances.

Désolé, mais les dépendances et les outils pour les gérer, ça avait été
absorbé par les "règles de l'art" depuis des années dans le monde mini
en 80.

La gestion de la complexité croissante s'appuie sur des outils également
plus complexes, ça ne devrait pas marcher plus mal.

J'ai l'impression à te lire que tu n'as aucune idée de ce que peut-être
un cycle de production de code.

À l'époque ils ne prenaient pas le temps de faire de tests de régression
par exemple. Là ça prend du temps.

????
J'ai quitté ce monde en 87 pour aller faire une autre informatique
(moins "système") pour changer de région, mais en 87 il y avait
longtemps qu'on intégrait aux jeux de tests et aux plans de tests tout
test ayant servi à vérifier la correction d'un bug, tout ce qui avait
fait l'objet d'une vérif sur une version le faisait dans toutes les
versions qui suivaient.
Si ce n'est pas de la non-régression, je ne sais pas ce que c'est.

A l'époque, les gens qui bossaient sur le système ne laissaient pas un
plantage inexploité :

Aujourd'hui ce ne serait pas UN plantage mais des centaines de miliers.
Donc imagine combien tu payerais ton logiciel si tu devais faire
analyser TOUS les dumps.

Mauvais argument : il y aurait peut-être des millier de plantages, mais
qui peuvent reposer sur les mêmes quelques erreurs élémentaires, le
millier de plantages n'étant dû qu'à la non correction pour cause de
non-analyse du premier.

J'ai connu ce pb, j'étais scié quand je sortais de mon équipe, de voir
que chez certains, un plantage donnait lieu à un fsck, et roule ma poule
: personne ne se demandait pourquoi, d'où forcément récidive avant
longtemps.
Essayer de comprendre était "une perte de temps". Apparemment, les n
reboots, les fsck et éventuellement les pertes de données n'en étaient
pas...

dump de toute la mémoire, et analyse avec les
moyens du bord... analyseur de "core dump" ou analyse "à la main" à
partir de l'état de la pile sysytème au moment du plantage, et en
descendant les tables système comme des grands. La motivation palliait
plus que largement la rusticité des outils, et un bug du noyau ne
trainait pas plus de quelques jours.

Un dump aujourd'hui ce n'est pas 16K comme à l'époque dont tu parles
mais 4Go ou plus.. je te laisse faire le calcul.

16KO dans les années 80 ???

De toute facon, la taille du dump n'a pas grande importance. Ca change
rien, la difficulté à analyser un dump dépend pas de sa taille.

Ghost-Rider

10/10/2012 à 12:49

Le 10/10/2012 10:26, jdd a écrit :

Le 09/10/2012 22:48, MELMOTH a écrit :

*2227* à 22H45 le 9 octobre 2012...
Melmothéen, comme Il Se doit...

tu trouve ça comment?

Tu filtres les messages sur le sujet, ça donne à l'instant 2260 messages.

Laszlo Lebrun

10/10/2012 à 12:59

On 10.10.2012 12:49, Ghost-Rider wrote:

Le 10/10/2012 10:26, jdd a écrit :
Le 09/10/2012 22:48, MELMOTH a écrit :

*2227* à 22H45 le 9 octobre 2012...
Melmothéen, comme Il Se doit...

tu trouve ça comment?

Tu filtres les messages sur le sujet, ça donne à l'instant 2260 messages.

j'en vois que 2153.

--
One computer and three operating systems, not the other way round.
One wife and many hotels, not the other way round ! ;-)

Ghost-Rider

10/10/2012 à 13:03

Le 10/10/2012 12:59, Laszlo Lebrun a écrit :

On 10.10.2012 12:49, Ghost-Rider wrote:
Le 10/10/2012 10:26, jdd a écrit :
Le 09/10/2012 22:48, MELMOTH a écrit :

*2227* à 22H45 le 9 octobre 2012...
Melmothéen, comme Il Se doit...

tu trouve ça comment?

Tu filtres les messages sur le sujet, ça donne à l'instant 2260 messages.

j'en vois que 2153.

T'as quoi comme OS, comme UC, comme carte graphique ?

Brrrrr...

10 réponses

Veuillez sélectionner un problème