MS Win 7 est tellement mauvais...

En électronique, c'est différent, AMHA il faut être bcp plus proche du
hard.

Quand on développe directement sur un µP, on est proche du hard, non ?

Oui. Enfin, je te dis oui parce que je le pense. Maintenant, avec le C, tu
es moins obligé... Et c'est là que ça fait parfois mal, surtout au moment de
la mise au point.

La question n'est pas là. En a-t-on besoin ? Je ne vois pas pourquoi
s'emmerder avec de tels trucs alors qu'on peut faire plus simple et
plus fiable. La _seule_ justification (j'ai un très bon bouquin sur
l'électronique automobile qui a été édité par PSA pour son labo de
recherche), c'est le différentiel de prix entre le câble en cuivre

Je me ferais sûrement mal à le lire, mais ça doit être intéressant.

allant à un système _centralisé_ et un faisceau multiplexé. Ça se
mesure en centimes, sur le prix d'un véhicule, c'est ridicule.

Un problème de faisceau électrique, sur une voiture à peu près moderne, peut
conduire à s'arracher les cheveux. Le mux devrait permettre d'éviter les
incidents de faisceau justement en réduisant le nombre de conducteurs.
Un des inconvénients, c'est qu'on déplace les éventuels soucis vers les
calculateurs, et là on est tout aussi mal.

aussi bien plus faible. Simple exemple : j'ai une DS 23 à _injection
électronique_, avec un calculateur analogique (condensateurs,
résistances, diodes [au germanium], transistors [germanium]) qui a
35 ans d'âge et qui en est toujours à son premier calculateur. Sur

D-Jetronic ?

ma BX, j'en suis à mon troisième calculateur ! Heureusement que je
peux encore le bricoler (c'est du composant discret). Sur la 607 de
fonction que j'avais, c'était retour direct chez Peugeot !

T'as pas eu de bol. On a longtemps eu une 405 à la maison, 20 ans... Aucun
souci avec le calculateur d'origine. Ou alors c'est nous qui avons eu de la
chance ?

Je n'ai eu aucun souci jusqu'à présent. Ce que je considérais comme un
bug
était juste une fonctionnalité particulière - c'est la vitesse variable
de
l'essuie-glace intermittent en fonction de la vitesse de la voiture.

Sur la 2CV, on faisait ça en 1948. Tu parles d'un progrès (je te
fais la même chose avec les phares qui tournent, la suspension à
assiette constante, l'asservissement de la direction assistée sur la
vitesse du véhicule, l'anti-blocage des roues...). Il ne faut surtout
pas croire que c'est l'électronique en général qui a permis cela !

Je ne le crois pas. Suis pas con à ce point (encore que...). Ca a permis de
le faire autrement, sans se servir du câble de compteur, par exemple.

Comprends-moi bien, je ne suis pas rétrograde, mais je ne
_comprends_ pas pourquoi changer des choses qui fonctionnent, qui ne
coûtent pas cher, qui sont parfaitement fiables, par des choses plus
chères et moins fiables.

C'est le progrès... ce qui pourrait être bien si c'était bien fait. Et je ne
pense pas que ce soit forcément le cas.
Compiler, c'est pas gagner. Et je sais que tu comprends ce que je veux dire
par là.

Vrai, il faut écrire ses error handlers soi-même aussi. Dis, ça fait
partie
du boulot, non ?

Le problème n'est pas de savoir si ça fait partie du boulot ou non.
Le problème est de le faire, naturellement ou contraint et forcé !
En plus, en C, tu peux ignorer silencieusement les valeurs de retour
de fonction ce qui est _mal_.

C'est là une des grandes responsabilités du développeur : le faire, et bien.

Si tu veux voir du C/Posix écrit à peu près correctement, va voir
http://www.rpl2.net. Toutes les valeurs des retours de fonctions
sont traités, les seules qui sont ignorées le sont sciemment parce
que d'une manière ou d'une autre, il y aura une autre erreur un peu
après dans le code qui sera traitée. C'est particulièrement
lourdingue et je n'ai pas souvent vu une telle qualité de code (et
ce n'est pas parce que c'est moi qui l'ai écrit, hein !).

J'y passerai, mais je ne connais rien en RPL. Je n'ai jamais pratiqué ces
choses-là. Par contre, j'ai constaté que tu ne manquais pas d'humour !

il n'y a pas d'autres termes avec des modules électroniques qu'il faut
redémarrer parce qu'ils sont buggués jusqu'à la moëlle !

Oui, mais... Je me demande si on laisse vraiment le temps aux
développeurs
de déboguer correctement leurs softs, aussi.

Ce n'est pas le problème. Si tu attaques directement un projet en
assembleur, tu es presque obligé d'écrire du code correct. En

On leur apprend plus l'assembleur.

utilisant des outils de développement plus 'évolués', tu vas plus
vite (encore que), et surtout, tu es beaucoup plus enclin à faire du
code moisi. Philosophiquement, il n'y a aucune raison, c'est juste
une constatation. Maintenant, à mon avis, ça vient surtout du fait
que la mentalité de ceux qui utilisent un IDE évolué et ceux qui
utilisent vim+assembleur n'est pas du tout la même. D'un côté, il y
a ceux qui mettent la main dans le cambouis, de l'autre, ceux qui
survolent le problème.

Une IDE, c'est peinard, tu as tous les outils sous la main (ou presque). Un
bon clicodrôme où tu fais simplement F10 pour lancer un assemblage ou une
compilation. Normalement, c'est pour faire le même boulot, mais plus
confortablement.
Je ne dis pas que ce que tu dis n'est pas vrai, on est du même avis. Je le
déplore aussi.

a+,
--
G.T

JKB a écrit :

Comprends-moi bien, je ne suis pas rétrograde, mais je ne
_comprends_ pas pourquoi changer des choses qui fonctionnent, qui ne
coûtent pas cher, qui sont parfaitement fiables, par des choses plus
chères et moins fiables.

Ce n'est pas compliqué : pour pousser les gens à consommer. Nouvelle
voiture, nouvelle télé, nouvel ordi, ça fait marcher le commerce et ça
engraisse les grands groupes financiers (et leurs actionnaires). Toute
la communication qui nous environne au quotidien n'est centrée que sur
ça : consommer, vite, et changer. Peu importe que ce soit fiable, ça
partira au rebut dans les deux ans, cinq ans maxi, pour plus rapide,
plus luxueux, plus bling-bling... Du coup, pourquoi construire solide?
Autant faire des économies (et donc plus de bénéfice) en choisissan t des
composants de moins bonne qualité.
C'est entré dans les moeurs, au point qu'il devient assez courant de
trouver abandonné sur le trottoir un ordi à peine usé, et qui n'a e u que
la mauvaise idée de ne pas redémarrer un matin, à cause de trois fo is
rien. Ca fait parfois le bonheur de quelqu'un... ;-)


--
/)
-:oo= Guillaume
)
Je nettoyais mon clavier, et le coup est parti tout seul.

Le 12-09-2009, ? propos de
Re: MS Win 7 est tellement mauvais...,
G.T ?crivait dans fr.comp.ordinosaures :

Salut,

JAVA, il n'a d'intérêt QUE parce qu'il est interprété

Pourquoi ?

Parce que *en théorie* tu prends ton fichier Java, tu fais tourner la JVM.
Ca marche. Sous n'importe quel système ou la JVM est disponible.
J'ai bien écrit "en théorie".

Tu peux faire exactement la même chose avec un langage semi-compilé
(comprendre qui n'est pas un binaire interprété dans une machine
virtuelle). Je fais ça depuis des années.

et multi-plateformes.

Ça reste à prouver. Pendant très longtemps, je n'ai pu avoir de JVM

Faut pas trop s'éloigner peut-être :-)
Sur mon ancien téléphone portable, j'avais une application Java (fournie
d'origine) qui est toute simple, un convertisseur de mesures.
Cette application n'existe pas sur mon nouveau téléphone. De la même marque,
d'ailleurs... je suis content, j'ai réussi à l'installer en tapant dans les
archives de mon ancien téléphone. En même temps, ce ne sont que des
opérations mathématiques de base, rien de bien méchant.

Sauf que _théoriquement_, pour être compatible java, il y a un tas
de choses à respecter et que je ne suis pas sûr, mais alors pas du
tout, qu'un téléphone portable (je ne parle pas d'un PDA ni d'un
smartphone) soit capable de les respecter.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le 12-09-2009, ? propos de
Re: MS Win 7 est tellement mauvais...,
G.T ?crivait dans fr.comp.ordinosaures :

En électronique, c'est différent, AMHA il faut être bcp plus proche du
hard.

Quand on développe directement sur un µP, on est proche du hard, non ?

Oui. Enfin, je te dis oui parce que je le pense. Maintenant, avec le C, tu
es moins obligé... Et c'est là que ça fait parfois mal, surtout au moment de
la mise au point.

La question n'est pas là. En a-t-on besoin ? Je ne vois pas pourquoi
s'emmerder avec de tels trucs alors qu'on peut faire plus simple et
plus fiable. La _seule_ justification (j'ai un très bon bouquin sur
l'électronique automobile qui a été édité par PSA pour son labo de
recherche), c'est le différentiel de prix entre le câble en cuivre

Je me ferais sûrement mal à le lire, mais ça doit être intéressant.

allant à un système _centralisé_ et un faisceau multiplexé. Ça se
mesure en centimes, sur le prix d'un véhicule, c'est ridicule.

Un problème de faisceau électrique, sur une voiture à peu près moderne, peut
conduire à s'arracher les cheveux. Le mux devrait permettre d'éviter les
incidents de faisceau justement en réduisant le nombre de conducteurs.

Les problèmes électriques dans une voiture proviennent de deux
choses : les problèmes de fluctuation de la tension (bascule entre
la batterie et l'alternateur ou la dynamo [on trouve encore des
dynamo dans certaines voitures, pour ceux qui ne connaissent pas la
différence, une dynamo donne une tension fonction de la vitesse
alors que l'alternateur donne une tension presque constante en
fonction d'icelle]) et les problèmes de masse. Pour résoudre ces
problèmes, il n'y a que deux solutions : câbler la masse au lieu de
la prendre sur la carrosserie (c'est ce que je fais avec mes
anciennes et je n'ai _plus_ de problème) et utiliser un régulateur
intelligent. Le multiplexage ne rajoute que des merdes à un mauvais
système et ne résout aucun des deux problèmes fondamentaux de
l'électricité auto.

Un des inconvénients, c'est qu'on déplace les éventuels soucis vers les
calculateurs, et là on est tout aussi mal.

aussi bien plus faible. Simple exemple : j'ai une DS 23 à _injection
électronique_, avec un calculateur analogique (condensateurs,
résistances, diodes [au germanium], transistors [germanium]) qui a
35 ans d'âge et qui en est toujours à son premier calculateur. Sur

D-Jetronic ?

Bosch Jetronic, injection indirecte, effectivement.

ma BX, j'en suis à mon troisième calculateur ! Heureusement que je
peux encore le bricoler (c'est du composant discret). Sur la 607 de
fonction que j'avais, c'était retour direct chez Peugeot !

T'as pas eu de bol. On a longtemps eu une 405 à la maison, 20 ans... Aucun
souci avec le calculateur d'origine. Ou alors c'est nous qui avons eu de la
chance ?

Peut-être. Je dois dire que j'ai eu exactement les mêmes problèmes
avec une AX, une Xantia et une 406.

Je n'ai eu aucun souci jusqu'à présent. Ce que je considérais comme un
bug
était juste une fonctionnalité particulière - c'est la vitesse variable
de
l'essuie-glace intermittent en fonction de la vitesse de la voiture.

Sur la 2CV, on faisait ça en 1948. Tu parles d'un progrès (je te
fais la même chose avec les phares qui tournent, la suspension à
assiette constante, l'asservissement de la direction assistée sur la
vitesse du véhicule, l'anti-blocage des roues...). Il ne faut surtout
pas croire que c'est l'électronique en général qui a permis cela !

Je ne le crois pas. Suis pas con à ce point (encore que...). Ca a permis de
le faire autrement, sans se servir du câble de compteur, par exemple.

Comprends-moi bien, je ne suis pas rétrograde, mais je ne
_comprends_ pas pourquoi changer des choses qui fonctionnent, qui ne
coûtent pas cher, qui sont parfaitement fiables, par des choses plus
chères et moins fiables.

C'est le progrès... ce qui pourrait être bien si c'était bien fait. Et je ne
pense pas que ce soit forcément le cas.
Compiler, c'est pas gagner. Et je sais que tu comprends ce que je veux dire
par là.

Vrai, il faut écrire ses error handlers soi-même aussi. Dis, ça fait
partie
du boulot, non ?

Le problème n'est pas de savoir si ça fait partie du boulot ou non.
Le problème est de le faire, naturellement ou contraint et forcé !
En plus, en C, tu peux ignorer silencieusement les valeurs de retour
de fonction ce qui est _mal_.

C'est là une des grandes responsabilités du développeur : le faire, et bien.

Le développeur fait ce qu'on lui demande de faire. Son cahier des
charges est souvent lacunaire et son temps de développement trop
court. Aujourd'hui, on développe un véhicule en assemblant des blocs
fonctionnels qui ont été développés pour d'autres (comme pour Ariane
5 et on a vu le résultat...), par des équipes qui ne se parlent pas
et le tout en moins de 5 ans. On voit le résultat. Il a fallu 17 ans
au bureau d'étude de chez Citroën pour pondre la DS et encore 5 ans
pour la mettre au point, mais à partir de 1960, elle était
parfaitement fiable. Ce qui m'amuse, c'est aussi que la SM était
réputé non fiable en 1970 alors que selon les critères actuels, elle
serait d'une fiabilité à tout épreuve !

Si tu veux voir du C/Posix écrit à peu près correctement, va voir
http://www.rpl2.net. Toutes les valeurs des retours de fonctions
sont traités, les seules qui sont ignorées le sont sciemment parce
que d'une manière ou d'une autre, il y aura une autre erreur un peu
après dans le code qui sera traitée. C'est particulièrement
lourdingue et je n'ai pas souvent vu une telle qualité de code (et
ce n'est pas parce que c'est moi qui l'ai écrit, hein !).

J'y passerai, mais je ne connais rien en RPL. Je n'ai jamais pratiqué ces
choses-là. Par contre, j'ai constaté que tu ne manquais pas d'humour !

Quand on attaque un truc pareil, il faut bien un peu de second degré
;-)

il n'y a pas d'autres termes avec des modules électroniques qu'il faut
redémarrer parce qu'ils sont buggués jusqu'à la moëlle !

Oui, mais... Je me demande si on laisse vraiment le temps aux
développeurs
de déboguer correctement leurs softs, aussi.

Ce n'est pas le problème. Si tu attaques directement un projet en
assembleur, tu es presque obligé d'écrire du code correct. En

On leur apprend plus l'assembleur.

Et c'est un tort. Vu le nombre de bugs que j'ai déjà trouvés dans
des compilos (allant du Turbo basic à gcc et ses dérivés) et qu'on
ne peut comprendre qu'en mettant les mains dans le code généré, je
ne vois pas comment on peut raisonnablement programmer un quelconque
soft dans un langage de haut niveau et le debugguer sans avoir des notions
d'assembleur (sauf à passer sa vie à écrire des 'hello, world!').

utilisant des outils de développement plus 'évolués', tu vas plus
vite (encore que), et surtout, tu es beaucoup plus enclin à faire du
code moisi. Philosophiquement, il n'y a aucune raison, c'est juste
une constatation. Maintenant, à mon avis, ça vient surtout du fait
que la mentalité de ceux qui utilisent un IDE évolué et ceux qui
utilisent vim+assembleur n'est pas du tout la même. D'un côté, il y
a ceux qui mettent la main dans le cambouis, de l'autre, ceux qui
survolent le problème.

Une IDE, c'est peinard, tu as tous les outils sous la main (ou presque). Un
bon clicodrôme où tu fais simplement F10 pour lancer un assemblage ou une
compilation. Normalement, c'est pour faire le même boulot, mais plus
confortablement.
Je ne dis pas que ce que tu dis n'est pas vrai, on est du même avis. Je le
déplore aussi.

a+,

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le 12-09-2009, ? propos de
Re: MS Win 7 est tellement mauvais...,
Le Moustique ?crivait dans fr.comp.ordinosaures :

JKB a écrit :

Comprends-moi bien, je ne suis pas rétrograde, mais je ne
_comprends_ pas pourquoi changer des choses qui fonctionnent, qui ne
coûtent pas cher, qui sont parfaitement fiables, par des choses plus
chères et moins fiables.

Ce n'est pas compliqué : pour pousser les gens à consommer. Nouvelle
voiture, nouvelle télé, nouvel ordi, ça fait marcher le commerce et ça
engraisse les grands groupes financiers (et leurs actionnaires). Toute
la communication qui nous environne au quotidien n'est centrée que sur
ça : consommer, vite, et changer. Peu importe que ce soit fiable, ça
partira au rebut dans les deux ans, cinq ans maxi, pour plus rapide,
plus luxueux, plus bling-bling... Du coup, pourquoi construire solide?
Autant faire des économies (et donc plus de bénéfice) en choisissant des
composants de moins bonne qualité.
C'est entré dans les moeurs, au point qu'il devient assez courant de
trouver abandonné sur le trottoir un ordi à peine usé, et qui n'a eu que
la mauvaise idée de ne pas redémarrer un matin, à cause de trois fois
rien. Ca fait parfois le bonheur de quelqu'un... ;-)

Quand on rajoute un peu de mauvaise foi comme la consommation des
véhicules, on atteint le sublime (je dis ça parce que, chiffres à
l'appui, il n'y a aucune diminution notable de consommation entre un
véhicule haut de gamme de 30 ans d'âge et un véhicule moyen actuel;
alors entendre qu'un véhicule de 7 ans d'âge consomme deux fois plus
qu'un véhicule sortant aujourd'hui des chaînes, je me marre, surtout
lorsqu'on sait comment les consommations sont calculées et comment
les constructeurs font pour les baisser artificiellement !).

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

G.T a écrit :

'Lut,

JAVA, il n'a d'intérêt QUE parce qu'il est interprété

Non, toutes les jvm décentes disposent d'un mécanisme de génération de
code natif à la volée.

et multi-plateformes.

On va dire qu'on le trouve sur les plateformes les plus courantes.

On a toutes les limites de l'interprété, notamment en termes de vitesse
et d'occupation mémoire...

Non plus, au niveau performance, c'est très variable, dans certains cas,
Java peut tailler des croupières à des langages compilés en code natif
et ce au moins depuis Java 1.4

Quand à l'occupation mémoire, ça se règle, mais il faut comprendre ce
que l'on fait (la solution consistant à allouer plus de ram à une jvm
pour augmenter les perfs est souvent le signe d'un problème de
compréhension du fonctionnement de l'appli et de ses interactions avec
la jvm)

L'intérêt de Java, c'est la jvm et ses différentes fonctionnalités : les
vérifications menées sur les classes lors de leur chargement afin de
s'assurer qu'elles ne violent pas les spécifications édictées (c'est la
base de la sécurité de la plateforme), les mécanismes de compilation
JIT, les outils d'analyse de performance et le modèle de sécurité né
avec Java 2, même s'il est peu utilisé.

Pour le langage en lui même, je préfère de loin Python, largement plus
maniable, mais les releases successives évoluent en ce sens, amha (même
si comme tous les langages dérivés du C, la syntaxe est une véritable plaie)

JKB a écrit :

'Lut,

et je ne parle pas des problèmes de trucs multithreadés dans les
JVM, mais sans que jamais on ne parle de mutexes ou de threads !).

L'intérêt de Java est de fournir une abstraction portable des
implémentations utilisées par l'os qui héberge la JVM.
La notion de thread est présente et la primitive synchronized permet la
protection de ressources de la même manière qu'un mutex.

Et pourtant, on en trouve de plus en plus (même dans des lecteurs de
CD de salon où j'aimerais bien qu'on m'explique à quoi ça sert
!...).

A éviter de réinventer la poudre pour une nouvelle application dès lors
qu'une jvm implémentant la norme requise est présente, par exemple
(probablement Java ME dans le cas d'un appareil grand public de salon)

Le 12-09-2009, ? propos de
Re: MS Win 7 est tellement mauvais...,
Emss ?crivait dans fr.comp.ordinosaures :

G.T a écrit :

'Lut,

JAVA, il n'a d'intérêt QUE parce qu'il est interprété

Non, toutes les jvm décentes disposent d'un mécanisme de génération de
code natif à la volée.

Et ? Ça veut simplement dire qu'on compile quelque chose à la volée.
Ça n'a donc un intérêt que relatif pour des trucs qui sont exécutés
en boucle.

et multi-plateformes.

On va dire qu'on le trouve sur les plateformes les plus courantes.

On a toutes les limites de l'interprété, notamment en termes de vitesse
et d'occupation mémoire...

Non plus, au niveau performance, c'est très variable, dans certains cas,
Java peut tailler des croupières à des langages compilés en code natif
et ce au moins depuis Java 1.4

Alors là, je demande à voir comment un code natif écrit par
quelqu'un qui sait _vraiment_ écrire peut être plus lent qu'un code
Java (même recompilé à la volée). À l'extrème limite, une fois que
le Java est chargé et compilé, je veux bien que le code Java arrive
peu ou prou à la même chose (for les problèmes d'allocation de la
mémoire par la JVM). Par exemple une multiplication de
matrices complexes avec d'un côté un code optimisé en Fortran90 et
de l'autre côté un code Java 1.6. Je suis prêt à écrire le code
Fortran.

Au passage, je fais du calcul numérique intense qui prend place dans
un code Java et justement, les calculs se font dans un autre langage
parce en Java, les performances de calcul sont _mauvaises_.

Quand à l'occupation mémoire, ça se règle, mais il faut comprendre ce
que l'on fait (la solution consistant à allouer plus de ram à une jvm
pour augmenter les perfs est souvent le signe d'un problème de
compréhension du fonctionnement de l'appli et de ses interactions avec
la jvm)

L'intérêt de Java, c'est la jvm et ses différentes fonctionnalités : les
vérifications menées sur les classes lors de leur chargement afin de
s'assurer qu'elles ne violent pas les spécifications édictées (c'est la
base de la sécurité de la plateforme),s

Java et sécurité dans la même phrase, ça aurait presque tendance à
me faire rire (surtout lorsqu'on lit les bugs reports de la JVM de
Sun). Les marketeux ont réussi à faire croire que Java, c'est bien.
Java est dans les faits une plaie, tant au niveau de la
programmation si on veut faire les choses proprement que de
l'exécution (aux bugs des OS, on rajoute ceux des JVM et c'est assez
marrant). Maintenant, si on développe sous Windows pour exécuter sur
une JVM sous Windows, autant programmer dans un _vrai_ langage.

les mécanismes de compilation
JIT, les outils d'analyse de performance et le modèle de sécurité né
avec Java 2, même s'il est peu utilisé.

Pour le langage en lui même, je préfère de loin Python, largement plus
maniable, mais les releases successives évoluent en ce sens, amha (même
si comme tous les langages dérivés du C, la syntaxe est une véritable plaie)

Le problème de Python, c'est son indentation _obligatoire_ sans
balise de fin de bloc. C'est un nid à bug lorsqu'on passe d'un
éditeur à un autre, et ça permet des résultats assez amusants. Ils
s'en souviennent encore, chez RedHat, lorsque leur procédure
d'installation se baugeait lamentablement sur un problème pareil.
Bref, Python est le _dernier_ langage que j'utiliserais à cause de
ce problème récurrent.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le 12-09-2009, ? propos de
Re: MS Win 7 est tellement mauvais...,
Emss ?crivait dans fr.comp.ordinosaures :

JKB a écrit :

'Lut,

et je ne parle pas des problèmes de trucs multithreadés dans les
JVM, mais sans que jamais on ne parle de mutexes ou de threads !).

L'intérêt de Java est de fournir une abstraction portable des
implémentations utilisées par l'os qui héberge la JVM.

Mouarf ! Ça, c'est la théorie. Justement, on a une application
maison qui tourne sur des JVM (Sun) et bizarrement, si elle se
comporte de la même façon sous tous les systèmes Posix, on a des
choses aberrantes dès qu'on la fait tourner sous Windows parce que
la gestion des threads par l'OS n'est pas la même et que ça
transparaît au niveau de la JVM.

La notion de thread est présente et la primitive synchronized permet la
protection de ressources de la même manière qu'un mutex.

Ce n'est pas exactement la même chose. Un mutex permet de faire des
choses plus précises (et plus simplement).

Et pourtant, on en trouve de plus en plus (même dans des lecteurs de
CD de salon où j'aimerais bien qu'on m'explique à quoi ça sert
!...).

A éviter de réinventer la poudre pour une nouvelle application dès lors
qu'une jvm implémentant la norme requise est présente, par exemple
(probablement Java ME dans le cas d'un appareil grand public de salon)

Et surtout à être obligé de faire une usine à gaz pour quelque chose
qui n'en vaut franchement pas la peine. Il faut être un minimum
sérieux. Si on veut vraiment mettre un µP dans un truc pareil, le
soft utile doit pouvoir rentrer dans un mémoire ridicule. En collant
une JVM plus tout ce qui faut pour que ça tourne, il faut coller un
processeur beaucoup plus gros, plus puissant et donc consommant
_beaucoup_ plus. Dire qu'on nous bassine avec les économies
d'énergie...

Dans le même style, j'ai vu dans le dernier 'IEEE spectrum' des
cartes à puce embarquant Java ! Là aussi, on va me dire que c'est
utile...

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

JKB a écrit :

'Re,

Et ? Ça veut simplement dire qu'on compile quelque chose à la volée.
Ça n'a donc un intérêt que relatif pour des trucs qui sont exécutés
en boucle.

Ah vi, j'oubliais, il n'y a que ton secteur d'activité qui importe et il
est donc possible de définir la vérité immanente à partir de ton unique
expérience...