yAroTweet (ou le topic des pensées à la con) - Page 372

je connais quelqu'un qui écrivait du Java pour l'informatique intégrée des voitures, et, je cite, "je vous souhaite de ne jamais acheter de voiture avec le logiciel qu'on écrit dans la boîte"

Une voiture qui fait le café, pas étonnant.

warpten: possibilité d'en savoir plus sur les modèles ou marques concernées? C'est plutot sérieux

Oui et non, c'est pas ici qu'on avait lu/vu une expertise pour une voiture Toyota qui décrétait que c'était bon pour la poubelle direct® ?

Si, c'est moi qui l'avait postée.

Mais bon c'est pas une raison : il y a plus d'une façon de faire du mauvais boulot, et je maintiens que le Java (ou le C#) est une absurdité en embarqué, en tout cas dès que le système a un minimum de criticité.

Je pense que le problème de ./11131 n'est pas le java mais que ce soit codé par des mauvais.
Et je suppose qu'il s'agit des éléments périphériques de la voiture, pas du code de l'ECU.
(au passage, java a commencé pour de l'embarqué )

Ouais enfin, tu peux marketer un langage pour n'importe quelle utilisation, c'est pas pour autant que c'est forcément adapté

Et puis y'a embarqué et embarqué : une borne interactive c'est de l'embarqué, mais ça n'a pas du tout les mêmes contraintes qu'un système de déclenchement d'air-bag.

Si tu as des contraintes fortes de gestion mémoire et de réactivité et que tu choisi un langage comme Java, ça part mal...

squalyl (./11133) :
warpten: possibilité d'en savoir plus sur les modèles ou marques concernées? C'est plutot sérieux

Il n'a jamais voulu me le dire ^^

Je crayonne zero²

Sinon j'ai trouvé l'autre jour un interpréteur python pour un processeur dédié au spatial, quand j'ai interrogé les gens on m'a dit que c'est surtout pour scripter des tests... J'attends de voir

Zerosquare (./11137) :
Si tu as des contraintes fortes de gestion mémoire et de réactivité et que tu choisi un langage comme Java, ça part mal...

https://en.wikipedia.org/wiki/Real_time_Java ? (je ne connais pas le sujet)
Concernant l'air bag, je pense que c'est purement mécanique/électronique, je ne crois pas que ce soit géré par le calculateur.

Pen^2 (./11136) :
Je pense que le problème de ./11131 n'est pas le java mais que ce soit codé par des mauvais.
Et je suppose qu'il s'agit des éléments périphériques de la voiture, pas du code de l'ECU.
(au passage, java a commencé pour de l'embarqué )

Oui c'est plus une question de qualité de code : le Java en soi est bien plus sur que le C/C++, ce qui peut avoir du l’intérêt sur du code ou la sécurité est plus importante que la réactivité au millième de seconde. Le langage Rust est vraiment sympa sur ce point vu qu'il est a la fois assez sécurisé tout en restant bas niveau.
Mais après si ton logiciel est mal architecturé et que la logique est boguée, aucun langage ne pourra rien pour toi.

Le java plsu sur?

Je ne suis pas d'accord, et ce n'est pas parceque c'est Java, mais parceque java, comme tout language a VM, tu n'a que peu de control sur ce qui se passe.

En C, oui il faut de la rigueur, mais en C je peux te dire "oui c'est sur il va se passer ceci ou cela car il n'y a aucune couche entre le hardware et le code.

Ah, tu es sûr de ce que ton compilateur fait ? Tu relis vraiment l'assembleur généré ?
Franchement je trouve que c'est du même niveau même si c'est vrai qu'il y a un niveau intermédiaire supplémentaire.

Il y a des compilateurs certifiés pour l'embarqué, qui sont testés de manière bien plus approfondie que les compilateurs C standards.

Les protections du Java (et des autres langages similaires) c'est une bonne chose sur le papier, mais il faut voir les "coûts" associés :

- c'est interprété, donc c'est lent et peu économe en énergie (pas la peine d'espérer utiliser du JIT : les performances ne sont pas déterministes, et le risque d'avoir des bugs est trop grand)

- le Java n'est pas prévu pour faire du bas niveau (y'a pas de pointeurs, etc.), or c'est un truc fondamental en embarqué. Donc au mieux, ce sera un mix de Java et de C (ou autre langage bas niveau).

- en cas de bug, mieux vaut une exception qu'un buffer overflow, mais de toute façon si tu en arrives là c'est qu'il y a un problème sérieux. Un plantage logiciel en embarqué, même géré "proprement", c'est beaucoup plus grave que pour une appli desktop.

(enfin bref, c'est une discussion pour "mon langage est mieux que le tien")

- Interprété, c'est un peu beaucoup exagéré, franchement (et https://en.wikipedia.org/wiki/PicoJava )
- Si tu certifies un compilateur (C), je suppose que tu peux en certifier un autre (Java) et une jvm
- Pointeurs : admettons ^^

Pen^2 (./11146) :
- Interprété, c'est un peu beaucoup exagéré, franchement

Bah non : à moins d'avoir un processeur capable d'exécuter le bytecode Java nativement (et c'est vraiment rare), c'est soit interprété, soit compilé à la volée. Et la compilation à la volée, comme je l'ai expliqué, c'est pas viable dès que tu as des contraintes de déterminisme (et bonjour la complexité et le risque de bugs qui va avec, aussi). Donc c'est interprété.

Ximoon (./11122) :

Nhut (./11118) :
LE SAVIEZ-VOUS?
Mars est la seule planète connue des humains à être peuplée exclusivement de robots.

Et Venus? Ça ne compte pas les robots morts?

Hé non, si aucun n'a survécu...

il faut arrêter de tirer autant sur java. les problèmes de sécurité ne viennent PAS du langage mais de la VM.

des miyards de CB contiennent des applis java, codées par des experts suivant des règles de qualité précises vérifieées par audit, et n'ont jamais eu de problème.

le bytecode généré est vérifié par un outil spécial qui vérifie que le code ne fait pas n'importe quoi.

Quand gemalto a eu un souci récemment, c'était un bug de la VM, pas du langage. et c'est plutot rare dans la vie totale des VM javacard. Et pour y arriver, ils ont du faire des bidouilles qui n'arrivent pas quand on compile du source java.

./11147 > J'ai pas dit que c'était faux, mais exagéré. OK, c'est de l'"assembleur interprété" dans le pire des cas, mais on est loin d'un langage interprété de base, faut pas déconner (et ./11146 dans je parle effectivement de processeurs exécutant du bytecode )

topics/164999-f-moved-mon-langage-est-mieux-que-le-tien
Au bout de 20 posts de suite, je pense qu'un recadrage est nécessaire quand il existe un sujet dédié pour ça (qui en plus trouve son origine au sujet du Java)

Godzil (./11143) :
Le java plsu sur?

Je ne suis pas d'accord, et ce n'est pas parceque c'est Java, mais parceque java, comme tout language a VM, tu n'a que peu de control sur ce qui se passe.

Oui, le langage Java est clairement plus sur : tu n'as pas d’arithmétique des pointeurs, de débordement mémoire, d'utilisation après libération, double libération ... Les failles Java qui ont fait parler d'elles récemment étaient plutôt dans l'implémentation du plugin des navigateurs et de la bibliothèque standard de JavaSE qui est en effet plus vulnérable car bien plus complète.

Et au niveau du contrôle de ce qui se passe, je dirais au contraire que Java est nettement meilleur. Il n'a pas les innombrables comportements indéfinis laissés par les spécifications de C et C++. Ils laissent le compilateur libre de faire tout et n'importe quoi.

Après oui dans le cas de Java, cette sécurité coûte en matière de prédictibilité des performances, mais il y a des cas où, même dans l'embarqué on peut se permettre de supporter ces coûts.

Godzil (./11143) :
En C, oui il faut de la rigueur, mais en C je peux te dire "oui c'est sur il va se passer ceci ou cela car il n'y a aucune couche entre le hardware et le code.

En C moderne aussi, tu n'es pas à l’abri de ce que va faire ton optimiseur.

Zerosquare (./11147) :
Bah non : à moins d'avoir un processeur capable d'exécuter le bytecode Java nativement (et c'est vraiment rare), c'est soit interprété, soit compilé à la volée. Et la compilation à la volée, comme je l'ai expliqué, c'est pas viable dès que tu as des contraintes de déterminisme (et bonjour la complexité et le risque de bugs qui va avec, aussi). Donc c'est interprété.

Le Java peut aussi se compiler en AOT. Après oui la contrainte du GC fait qu'on n'a pas un déterminisme aussi bon qu'en C, mais il y a beaucoup d'applications embarquées qui n'ont pas de contrainte temps réel trop forte, pour lesquelles c'est tout a fait acceptable.

C'est moi ou aliexpress c'est un bordel monstres?...

Ah parce que tu découvres ça seulement maintenant ?

Ben je compte m'offrir le clone de kossel de la marquer "flsun" mais a vrai dire mais leur catalogue est bordelique au possible avec 50 fois la meme et des prix differents sans raison precises :/

Si, le vendeur. N'oublie pas que Aliexpress est la vitrine "publique" d'Alibaba, un broker.

http://m.ina.fr/video/I10257139/la-television-oeil-de-demain-video.html
Je suis très impressionné, d'avoir imaginé ça il y a 70 ans !

C'est bien vu en effet

Mais ce n'est pas si rare que ça, si tu lis les auteurs de SF par exemple, de trouver des prédictions qui tombent vraiment juste.

Oui et le double ou le tripple qui tombent faux

Effectivement ^^