MS Win 7 est tellement mauvais...

"JKB" <knatschke@koenigsberg.fr> a écrit dans le message de news:
slrnhakvlo.5ad.knatschke@rayleigh.systella.fr...
|
| Ouaips, enfin, ben, euh... Il y a vraiment longtemps que je n'ai
| plus vu autre chose qu'un dinosaure pour coder en assembleur.
| Personnellement, je me suis fait les dents sur le 8080, le 6809 (et
| le merveilleux 6309) m'ont paru géniaux à côté. J'ai fait des trucs
| indescriptibles dans 1 Mo de mémoire avec un 63C09 et sa MMU. Cela
| doit faire pas loin de dix ans que je n'ai plus vu en école
| d'ingénieurs un élève attaquer un microcontrôleur avec autre chose
| qu'un environnement de debug complet sous Windows avec compilo C
| (alors que pour moi, c'était éditeur de texte sous DOS, assembleur,
| claqueur d'EEPROM et test à l'analyseur logique). Pour attaquer un
| 68HC11 ou un PIC, ces IDE sont tout de même utiliser un marteau-pilon pour
| écraser une mouche ! Sans compter que j'ai fait à l'époque un codeur
| de Reed-Muller (1,6) qui tenait dans une ROM de 8 Ko et une RAM
| surdimensionnée de 2 Ko (avec gestion multitâche des entrées et des
| sorties !) et que les gus actuels n'arrivent pas à faire rentrer
| dans un EEPROM de 64 Ko !
|
| J'attends avec beaucoup d'espoir l'arrivée de Java dans les modèles
| de développement des PIC. On va enfin rigoler un peu !
|
| JKB, qui a fait ses armes en assembleur sur PDP et VAX, ça ne nous
| rajeunit pas...
|
| --
D'accord sur toute la ligne... jusqu'à ton évocation de JAVA : jamais vu un
truc JAVA optimisé, et encore moins fiable. Faut dire que ça fait longtemps
que j'évite ces trucs comme la peste, les choses ont donc peut-être changé
(le IOBA est optimiste de nature, il ne peut rien contre ça). Pour moi, JAVA
ne se limite plus qu'aux modules incontournables mis à tour de bras sur des
sites web par des concepteurs incompétents qui ne savent pas coder en HTML
et nous infligent le JAVA et le FLASH essentiellement parce que la toile
pullule de modules tout prêts (d'où ma crise, en constatant que le site
"sécurisé" d'une de mes banques était bourré de JAVA !!)
Bref, tel que je le vois, il n'y a qu'Adobe pour faire des trucs plus lourds
et nazes que les logiciels en JAVA que j'ai eu l'occasion de tester. Si tu
mets ça dans un PIC de pilotage d'appareil, tu pourras juste commander le
ON/OFF, et encore...

--
IOBA

"JKB" <knatschke@koenigsberg.fr> a écrit dans le message de news:
slrnhaml3e.v34.knatschke@rayleigh.systella.fr...
|
| Le problème, ce n'est pas l'IDE en tant que tel, c'est le fait de
| masquer tout le fonctionnement intrinsèque de la bête. Ce n'est pas
| pareil de se palucher l'écriture d'un vecteur d'interruption en
| assembleur et de le générer automatiquement. Après, on trouve des
| types qui ne font plus la différence entre un processeur vectorisé
| et un auto-vectorisé et on va très rapidement dans le mur. On ne
| peut pas avoir le cul assis entre deux chaises, soit on touche au
| matériel, soit on a une couche d'abstraction entre les deux (style
| carte de développement). Utiliser directement un composant quel
| qu'il soit en collant pour les développements une couche
| d'abstraction telle qu'un IDE avec un compilo C est une connerie
| sans nom et aboutit à tous les problèmes qu'on a actuellement avec
| les développements pas chers et rapides. Je te donne simplement un
| exemple : dans l'automobile, il y a des tas de modules à base de
| microcontrôleurs pour gérer des bus (oui, le câble est devenu trop
| cher et est trop fiable, on colle des multiplexages partout !). Ces
| modules tournent sur des µC de compétition, avec du code écrit en C.
| Manque de bol, le C n'a pas assez de granularité pour assurer un
| truc fiable à temps réel (au sens informatique tu terme). En
| assembleur, on pourrait le faire, sur des processeurs largement
| moins puissants et plus éprouvés. Je passe aussi sur le fait que le
| C n'est pas un bon langage (il faut récupérer les erreurs à la main
| et surtout _savoir_ programmer proprement, parce que je ne compte
| plus les bouts de codes où on voit des sendto() sans vérification
| d'erreur !). Résultat des courses, on est continuellement emmerdés,
| 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 !
|
|
Je plussoie avec ferveur !

--
IOBA

Salut,

Le problème, ce n'est pas l'IDE en tant que tel, c'est le fait de
masquer tout le fonctionnement intrinsèque de la bête. Ce n'est pas

Charge au développeur d'ouvrir les fenêtres... Il a souvent une option "save
workplace" qui n'est pas inutile.

carte de développement). Utiliser directement un composant quel
qu'il soit en collant pour les développements une couche
d'abstraction telle qu'un IDE avec un compilo C est une connerie
sans nom et aboutit à tous les problèmes qu'on a actuellement avec
les développements pas chers et rapides. Je te donne simplement un

Sais pas... J'ai toujours considéré (et je n'ai pas changé d'avis) qu'on
pouvait faire de l'abstraction si on tournait à haut niveau, sur un
ordinateur moderne ou carrément dans un système de scripts comme SAP. Pour
faire de l'ABAP, tu t'en fous de savoir comment fonctionne ton serveur.
En électronique, c'est différent, AMHA il faut être bcp plus proche du hard.

exemple : dans l'automobile, il y a des tas de modules à base de
microcontrôleurs pour gérer des bus (oui, le câble est devenu trop
cher et est trop fiable, on colle des multiplexages partout !). Ces

Le mux c'est pas mal quand c'est bien conçu. L'ennui, c'est qu'entre les
conceptions des équipementiers (comme le CAN) et celles des BE, ça coince
parfois.
J'ai une voiture multiplexée, c'est pas marqué en gros dessus, mais je le
sais. Il y a quelques étiquettes "T1 MUX" et quelques indices si on est
attentif :-)
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.

assembleur, on pourrait le faire, sur des processeurs largement
moins puissants et plus éprouvés. Je passe aussi sur le fait que le
C n'est pas un bon langage (il faut récupérer les erreurs à la main
et surtout _savoir_ programmer proprement, parce que je ne compte
plus les bouts de codes où on voit des sendto() sans vérification
d'erreur !). Résultat des courses, on est continuellement emmerdés,

Vrai, il faut écrire ses error handlers soi-même aussi. Dis, ça fait partie
du boulot, non ?
Tu vois, des fois je me sens vieux : j'ai eu l'occasion de croiser des
jeunes qui sont aujourd'hui soit sur du hard, soit sur du soft chez un
équipementier automobile.
J'ai dû leur expliquer l'intérêt d'écrire un pilote d'affichage LCD (par
exemple) et de faire en sorte que le programme envoie directement son texte
au pilote.

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.

a+,
--
G.T

"Khanh-Dang" <khanh-dang@w.fr.invalid> a écrit dans le message de news:
slrnhamnrq.9ne.khanh-dang@calysse.pamplemousse.homeunix.org...
|
| Je code en assembleur bizarre et je ne suis pas un dinosaure.

Ne perds pas de vue que l'on parle d'informatique : si tu as plus de 22
ans, tu es un dino (bien fait, na!)
Et puis il y a aussi une différence entre l'âge physique, et l'état d'esprit
: sûr que pour écrire une merdouille, si tu me proposes un truc où je
n'aurai qu'à cliquer sur des boutons pour que des sous-modules de codes
s'assemblent automatiquement pour me donner grosso-modo le résultat que
j'attends, je vais trouver cela plus pratique que mes premiers contacts avec
l'informatique, où je codais en établissant des liaisons booléennes avec des
bouts de câbles, pour lire le résultats sur des ampoules allumées ou
éteintes... Mais si cette conversation continue à me donner follement envie
de me lancer à nouveau dans la programmation, je sens que je le ferai de la
façon le plus dino qui soit, alors que je suis encore jeune beau et grand
(le premier qui se marre, je luis fais casser son gueule par un copain plus
jeune !)

--
IOBA

Salut,

D'accord sur toute la ligne... jusqu'à ton évocation de JAVA : jamais vu
un
truc JAVA optimisé, et encore moins fiable. Faut dire que ça fait
longtemps

JAVA, il n'a d'intérêt QUE parce qu'il est interprété et multi-plateformes.
On a toutes les limites de l'interprété, notamment en termes de vitesse et
d'occupation mémoire... et je pense que c'est peu stratégique sur un PIC. Ce
sont des bestioles supposées aller vite :-)

tcl/tk était aussi interprété et multi-plateformes. Lui n'a pas décollé,
arrivé trop tôt sans doute.

a+,
--
G.T

"Jean-Marc DURO" <jean-marc.duro@orange.fr> a écrit dans le message de news:
4aaa8040$0$12661$ba4acef3@news.orange.fr...
|
| Analyse Gedcom, j'ai déjà. La base de données aussi, que ce soit sous
| une forme propriétaire ou en SQL. J'ai eu le temps de bien penser çà.
| C'est après, la mise en musique qui s'avère ardue: là où j'en suis, je
| peux juste visualiser une partie d'un arbre et le remonter, pas le
| descendre ni le modifier.
|
| J'aurais peut-être dû le faire en Basic sur un Amstrad 6128. Je m'étais
| fait un beau logiciel de comptes bancaires à l'époque mais j'ai paumé
| les sources.
|
La "faiblesse" des Amstrad de l'époque dans ce domaine précis, c'était
l'absence de bons scanners, pour conserver les actes et photos (fonction qui
semble primordiale, à en croire les logiciels actuels). Le reste n'est que
de la "bête" gestion de données.
Par exemple, pour tes problèmes de modification, le seul point est qu'il ne
faut pas perdre de vue que toute modification doit être chaînée, afin de
faire les mises à jour dépendantes ; un tableau de chaînage des balises
devrait te permettre de faire très facilement un module de modification
récurrente.

--
IOBA, pas sûr d'avoir compris ce qui te pose problème

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

"JKB" <knatschke@koenigsberg.fr> a écrit dans le message de news:
slrnhakvlo.5ad.knatschke@rayleigh.systella.fr...
|
| Ouaips, enfin, ben, euh... Il y a vraiment longtemps que je n'ai
| plus vu autre chose qu'un dinosaure pour coder en assembleur.
| Personnellement, je me suis fait les dents sur le 8080, le 6809 (et
| le merveilleux 6309) m'ont paru géniaux à côté. J'ai fait des trucs
| indescriptibles dans 1 Mo de mémoire avec un 63C09 et sa MMU. Cela
| doit faire pas loin de dix ans que je n'ai plus vu en école
| d'ingénieurs un élève attaquer un microcontrôleur avec autre chose
| qu'un environnement de debug complet sous Windows avec compilo C
| (alors que pour moi, c'était éditeur de texte sous DOS, assembleur,
| claqueur d'EEPROM et test à l'analyseur logique). Pour attaquer un
| 68HC11 ou un PIC, ces IDE sont tout de même utiliser un marteau-pilon pour
| écraser une mouche ! Sans compter que j'ai fait à l'époque un codeur
| de Reed-Muller (1,6) qui tenait dans une ROM de 8 Ko et une RAM
| surdimensionnée de 2 Ko (avec gestion multitâche des entrées et des
| sorties !) et que les gus actuels n'arrivent pas à faire rentrer
| dans un EEPROM de 64 Ko !
|
| J'attends avec beaucoup d'espoir l'arrivée de Java dans les modèles
| de développement des PIC. On va enfin rigoler un peu !
|
| JKB, qui a fait ses armes en assembleur sur PDP et VAX, ça ne nous
| rajeunit pas...
|
| --
D'accord sur toute la ligne... jusqu'à ton évocation de JAVA : jamais vu un
truc JAVA optimisé, et encore moins fiable.

C'était du second degré. L'arrivée de Java partout est une calamité.
C'est d'autant pire que le compilo râle à tous les coins de rue et
cela permet à n'importe qui de bricoler quelque chose en étant
absolument convaincu que lorsque ça passe à la compilation, le
résultat sera forcément bon (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 !).

Faut dire que ça fait longtemps
que j'évite ces trucs comme la peste, les choses ont donc peut-être changé
(le IOBA est optimiste de nature, il ne peut rien contre ça). Pour moi, JAVA
ne se limite plus qu'aux modules incontournables mis à tour de bras sur des
sites web par des concepteurs incompétents qui ne savent pas coder en HTML
et nous infligent le JAVA et le FLASH essentiellement parce que la toile
pullule de modules tout prêts (d'où ma crise, en constatant que le site
"sécurisé" d'une de mes banques était bourré de JAVA !!)
Bref, tel que je le vois, il n'y a qu'Adobe pour faire des trucs plus lourds
et nazes que les logiciels en JAVA que j'ai eu l'occasion de tester. Si tu
mets ça dans un PIC de pilotage d'appareil, tu pourras juste commander le
ON/OFF, et encore...

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
!...).

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 :

Salut,

D'accord sur toute la ligne... jusqu'à ton évocation de JAVA : jamais vu
un
truc JAVA optimisé, et encore moins fiable. Faut dire que ça fait
longtemps

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

Pourquoi ?

et multi-plateformes.

Ça reste à prouver. Pendant très longtemps, je n'ai pu avoir de JVM
sous Linux/sparc (un comble). Sous Linux/ppc, la JVM que j'ai réussi
à installer est un méchant hack d'une J9M d'IBM pour je ne sais plus
quel OS IBM. Sous VMS, ça merdoie joyeusement (Java a été conçu en
pensant à Solaris, donc un OS case sensitive avec une arborescence
de fichiers unique et des séparateurs du type '/'. Sous VMS, on a
très souvent des surprises !...). Les JVM Linux 64 bits ne se
comportent pas vraiment comment les JVM Windows 32 ou 64 bits, et je
ne parle pas encore des fuites mémoire de cette usine à gaz (ni de
bugs sournois d'une sous-révision à une autre) !

Bref, Java est moins multi plate-forme que ne l'est un code Fortran
ou C/Posix pour peut qu'on se limite à la norme. Prétendre le
contraire prouve qu'on n'a jamais été confronté aux limites de la
portabilité de la chose.

On a toutes les limites de l'interprété, notamment en termes de vitesse et
d'occupation mémoire... et je pense que c'est peu stratégique sur un PIC. Ce
sont des bestioles supposées aller vite :-)

tcl/tk était aussi interprété et multi-plateformes. Lui n'a pas décollé,
arrivé trop tôt sans doute.

M'en fiche. Moi, pour mes besoins propres, j'ai développé un vrai
truc portable sur tout système Posix, semi-compilé, et même
fonctionnant en cluster. Un machin qui en terme de vitesse de calcul
explose littéralement Java en assurant une portabilité _complète_
d'un système à un autre.

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 :

Salut,

Le problème, ce n'est pas l'IDE en tant que tel, c'est le fait de
masquer tout le fonctionnement intrinsèque de la bête. Ce n'est pas

Charge au développeur d'ouvrir les fenêtres... Il a souvent une option "save
workplace" qui n'est pas inutile.

Le développeur est d'une paresse crasse. S'il peut éviter de faire
quelque chose, il le fera.

carte de développement). Utiliser directement un composant quel
qu'il soit en collant pour les développements une couche
d'abstraction telle qu'un IDE avec un compilo C est une connerie
sans nom et aboutit à tous les problèmes qu'on a actuellement avec
les développements pas chers et rapides. Je te donne simplement un

Sais pas... J'ai toujours considéré (et je n'ai pas changé d'avis) qu'on
pouvait faire de l'abstraction si on tournait à haut niveau, sur un
ordinateur moderne ou carrément dans un système de scripts comme SAP. Pour
faire de l'ABAP, tu t'en fous de savoir comment fonctionne ton serveur.
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 ?

exemple : dans l'automobile, il y a des tas de modules à base de
microcontrôleurs pour gérer des bus (oui, le câble est devenu trop
cher et est trop fiable, on colle des multiplexages partout !). Ces

Le mux c'est pas mal quand c'est bien conçu.

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
allant à un système _centralisé_ et un faisceau multiplexé. Ça se
mesure en centimes, sur le prix d'un véhicule, c'est ridicule.

Je ne dis pas que le multiplexage n'est pas utile dans certains cas,
mais sur une voiture, c'est un truc qui se discute. Ce qui est
surtout amusant, c'est que les véhicules anciens que je connais
bien, bien entretenus, roulent toujours (j'ai un modèle de 1938 dans
mon garage). Un véhicule moderne sera mis au rebut dès que le bidule
électronique sera en panne et impossible à réparer parce que plus de
pièces. Les contraintes sur la durée de vie de ces composants est
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
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 !

L'ennui, c'est qu'entre les
conceptions des équipementiers (comme le CAN) et celles des BE, ça coince
parfois.
J'ai une voiture multiplexée, c'est pas marqué en gros dessus, mais je le
sais. Il y a quelques étiquettes "T1 MUX" et quelques indices si on est
attentif :-)
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 !
On savait même faire des systèmes de suspension pendulaire dans les
années 50 (pour transporter des explosifs liquides).

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.

assembleur, on pourrait le faire, sur des processeurs largement
moins puissants et plus éprouvés. Je passe aussi sur le fait que le
C n'est pas un bon langage (il faut récupérer les erreurs à la main
et surtout _savoir_ programmer proprement, parce que je ne compte
plus les bouts de codes où on voit des sendto() sans vérification
d'erreur !). Résultat des courses, on est continuellement emmerdés,

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_.

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 !).

Tu vois, des fois je me sens vieux : j'ai eu l'occasion de croiser des
jeunes qui sont aujourd'hui soit sur du hard, soit sur du soft chez un
équipementier automobile.
J'ai dû leur expliquer l'intérêt d'écrire un pilote d'affichage LCD (par
exemple) et de faire en sorte que le programme envoie directement son texte
au pilote.

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
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.

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.

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".

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.

a+,
--
G.T