Du C ou du Java dans les systèmes embarqués automobile ?
246 réponses
Zeldus
Bonjour,
Les voitures faisant de plus en plus appel à l'électronique pour
fonctionner, même pour les tâches les plus basiques, en quel langage sont
programmés les applications qui gèrent les différentes fonctions
électroniques intégrés aux voitures ?
J'ai pensé à l'assembleur mais vu la aujourd'hui puissance et le prix des
processeurs même les plus basiques, je pense que ce n'est pas le cas et la
tâche serait complexe pour les programmeurs.
Vient ensuite le C, celui qui serait probablement le plus adapté, ancien
mais toujours très efficace ou alors Java, complètement portable mais qui
nécessite une machine virtuelle assez lourde.
Je plussoie vigoureusement à cette analyse (surtout lorsqu'on voit le support des threads absolument approximatif des JVM). La libpthread POSIX est ardue, mais si on ne comprend pas les mécanismes de base, on ne pourra _jamais_ utiliser de façon fiable un outil de plus haut niveau. Bref, lorsqu'on est _incapable_ de formaliser quelque chose en C, en Fortran, en ADA, autrement dit dans un langage fonctionnel ou impératif, il est _illusoire_ de vouloir sortir un code fonctionnel est entièrement débuggué avec un langage objet.
En fait, les langages à objets viennent tous avec un nombre conséquent de bibliothèques et frameworks, et il est nettement plus difficile de ne pas les utiliser. Mais si on voit le nombre important de programmes GTK qui sortent sur stederr des messages "Critical assertion : blabla", on voit que même en C ce genre de programmation est possible. Et qu'elle y fait autant de dégat (on peut d'ailleurs ce demander pourquoi le framework qualifie de critique des violations d'assertions qui n'empêchent pas le code de fonctionner...)
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
JKB <knatschke@koenigsberg.fr> écrivait :
Je plussoie vigoureusement à cette analyse (surtout lorsqu'on voit
le support des threads absolument approximatif des JVM). La libpthread
POSIX est ardue, mais si on ne comprend pas les mécanismes de base, on
ne pourra _jamais_ utiliser de façon fiable un outil de plus haut
niveau. Bref, lorsqu'on est _incapable_ de formaliser quelque chose en
C, en Fortran, en ADA, autrement dit dans un langage fonctionnel ou
impératif, il est _illusoire_ de vouloir sortir un code fonctionnel est
entièrement débuggué avec un langage objet.
En fait, les langages à objets viennent tous avec un nombre conséquent
de bibliothèques et frameworks, et il est nettement plus difficile de ne
pas les utiliser. Mais si on voit le nombre important de programmes GTK
qui sortent sur stederr des messages "Critical assertion : blabla", on
voit que même en C ce genre de programmation est possible. Et qu'elle y
fait autant de dégat (on peut d'ailleurs ce demander pourquoi le
framework qualifie de critique des violations d'assertions qui
n'empêchent pas le code de fonctionner...)
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Je plussoie vigoureusement à cette analyse (surtout lorsqu'on voit le support des threads absolument approximatif des JVM). La libpthread POSIX est ardue, mais si on ne comprend pas les mécanismes de base, on ne pourra _jamais_ utiliser de façon fiable un outil de plus haut niveau. Bref, lorsqu'on est _incapable_ de formaliser quelque chose en C, en Fortran, en ADA, autrement dit dans un langage fonctionnel ou impératif, il est _illusoire_ de vouloir sortir un code fonctionnel est entièrement débuggué avec un langage objet.
En fait, les langages à objets viennent tous avec un nombre conséquent de bibliothèques et frameworks, et il est nettement plus difficile de ne pas les utiliser. Mais si on voit le nombre important de programmes GTK qui sortent sur stederr des messages "Critical assertion : blabla", on voit que même en C ce genre de programmation est possible. Et qu'elle y fait autant de dégat (on peut d'ailleurs ce demander pourquoi le framework qualifie de critique des violations d'assertions qui n'empêchent pas le code de fonctionner...)
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Erwan David
Wykaaa écrivait :
Erwan David a écrit :
JKB écrivait :
J'en ai écrit. Il y en a même en Fortran. C'est très bien que tout soit alloué statiquement. On est _sûr_ que le truc ne va pas échouer bêtement sur une allocation impossible (par ailleurs, la pluart du temps, ça tourne dans des systèmes minimaux qui n'ont pas d'allocation dynamique).
Par ailleurs j'ai écris un allocateur dynamique pour de l'embarqué...
Oui mais dans quel contexte, pour faire quoi ?
Terminaux de paiement (bancaire) et middleware sécurisé sur téléphones mobiles.
Avec une VM java (STIP, http://www.globalplatform.org/specificationsdevice.asp) à l'intérieur.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Wykaaa <wykaaa@yahoo.fr> écrivait :
Erwan David a écrit :
JKB <knatschke@koenigsberg.fr> écrivait :
J'en ai écrit. Il y en a même en Fortran. C'est très bien que tout
soit alloué statiquement. On est _sûr_ que le truc ne va pas échouer
bêtement sur une allocation impossible (par ailleurs, la pluart du
temps, ça tourne dans des systèmes minimaux qui n'ont pas d'allocation
dynamique).
Par ailleurs j'ai écris un allocateur dynamique pour de l'embarqué...
Oui mais dans quel contexte, pour faire quoi ?
Terminaux de paiement (bancaire) et middleware
sécurisé sur téléphones mobiles.
Avec une VM java (STIP,
http://www.globalplatform.org/specificationsdevice.asp) à l'intérieur.
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
J'en ai écrit. Il y en a même en Fortran. C'est très bien que tout soit alloué statiquement. On est _sûr_ que le truc ne va pas échouer bêtement sur une allocation impossible (par ailleurs, la pluart du temps, ça tourne dans des systèmes minimaux qui n'ont pas d'allocation dynamique).
Par ailleurs j'ai écris un allocateur dynamique pour de l'embarqué...
Oui mais dans quel contexte, pour faire quoi ?
Terminaux de paiement (bancaire) et middleware sécurisé sur téléphones mobiles.
Avec une VM java (STIP, http://www.globalplatform.org/specificationsdevice.asp) à l'intérieur.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Mickaël Wolff
Marc Espie a écrit :
Bref, moins je verrai de java dans un contexte critique, mieux je me porterai.
Il semblerait que le problème ne soit pas technologique : <https://linuxfr.org//comments/1000177,1.html>
En fait, les langages à objets viennent tous avec un nombre conséquent de bibliothèques et frameworks, et il est nettement plus difficile de ne pas les utiliser. Mais si on voit le nombre important de programmes GTK qui sortent sur stederr des messages "Critical assertion : blabla", on voit que même en C ce genre de programmation est possible. Et qu'elle y fait autant de dégat (on peut d'ailleurs ce demander pourquoi le framework qualifie de critique des violations d'assertions qui n'empêchent pas le code de fonctionner...)
Bon, a cote de ca, gtk, c'est objectivement de la merde. Reecrire un modele objet dynamique entier en C, juste parce que C++ c'est mal, et arriver a tout faire pourri a ce point, faut le faire expres. Le nombre d'assertion au kilometre dans gtk+ est hallucinant. Je prefere tres largement qt, qui lui au moins assume pleinement son cote objet, est ecrit dans un langage adapte, et plantouille infiniment moins en pratique (sans compter que le code resultant est moins verbeux et plus efficace).
In article <86vdm9vpd3.fsf@nez-casse.depot.rail.eu.org>,
Erwan David <erwan@rail.eu.org> wrote:
En fait, les langages à objets viennent tous avec un nombre conséquent
de bibliothèques et frameworks, et il est nettement plus difficile de ne
pas les utiliser. Mais si on voit le nombre important de programmes GTK
qui sortent sur stederr des messages "Critical assertion : blabla", on
voit que même en C ce genre de programmation est possible. Et qu'elle y
fait autant de dégat (on peut d'ailleurs ce demander pourquoi le
framework qualifie de critique des violations d'assertions qui
n'empêchent pas le code de fonctionner...)
Bon, a cote de ca, gtk, c'est objectivement de la merde. Reecrire un
modele objet dynamique entier en C, juste parce que C++ c'est mal, et
arriver a tout faire pourri a ce point, faut le faire expres. Le nombre
d'assertion au kilometre dans gtk+ est hallucinant. Je prefere tres
largement qt, qui lui au moins assume pleinement son cote objet, est ecrit
dans un langage adapte, et plantouille infiniment moins en pratique (sans
compter que le code resultant est moins verbeux et plus efficace).
En fait, les langages à objets viennent tous avec un nombre conséquent de bibliothèques et frameworks, et il est nettement plus difficile de ne pas les utiliser. Mais si on voit le nombre important de programmes GTK qui sortent sur stederr des messages "Critical assertion : blabla", on voit que même en C ce genre de programmation est possible. Et qu'elle y fait autant de dégat (on peut d'ailleurs ce demander pourquoi le framework qualifie de critique des violations d'assertions qui n'empêchent pas le code de fonctionner...)
Bon, a cote de ca, gtk, c'est objectivement de la merde. Reecrire un modele objet dynamique entier en C, juste parce que C++ c'est mal, et arriver a tout faire pourri a ce point, faut le faire expres. Le nombre d'assertion au kilometre dans gtk+ est hallucinant. Je prefere tres largement qt, qui lui au moins assume pleinement son cote objet, est ecrit dans un langage adapte, et plantouille infiniment moins en pratique (sans compter que le code resultant est moins verbeux et plus efficace).
espie
In article <4a4e13bc$0$422$, Mickaël Wolff wrote:
Marc Espie a écrit :
Bref, moins je verrai de java dans un contexte critique, mieux je me porterai.
Il semblerait que le problème ne soit pas technologique : <https://linuxfr.org//comments/1000177,1.html>
Ca correspond a une part de mon impression: c'est dommage qu'il n'y ait pas un site sncf qui vende du billet de train. A vouloir peter plus haut que leur cul, et en ayant un tres fort trafic entretenu par la confusion (les gens VEULENT acheter du billet de train en ligne, et il n'y a pas d'alternative reelle), on se retrouve avec les grotesquitudes actuelles.
Mais bon, j'ai un peu tendance a assimiler marketing/management "fort"/site technologiquement mal adapte/technologie tres clinquante super-modulaire vendable sur appel d'offre qui fait plus joli aux yeux du manager qui n'y comprend rien a qui on fait miroiter le mythe du mois-homme, et les SSII qui font leur beurre la-dessus.
J'avoue que je ne comprend pas trop pourquoi personne ne s'est incruste dans la breche pour vendre juste du train en ligne, je subodore que meme si SNCF n'y est pour rien, il y a entente et monopole de fait...
In article <4a4e13bc$0$422$426a74cc@news.free.fr>,
Mickaël Wolff <mickael.wolff@laposte.net> wrote:
Marc Espie a écrit :
Bref, moins je verrai de java dans un contexte critique, mieux je me
porterai.
Il semblerait que le problème ne soit pas technologique :
<https://linuxfr.org//comments/1000177,1.html>
Ca correspond a une part de mon impression: c'est dommage qu'il n'y ait pas
un site sncf qui vende du billet de train. A vouloir peter plus haut que leur
cul, et en ayant un tres fort trafic entretenu par la confusion (les gens
VEULENT acheter du billet de train en ligne, et il n'y a pas d'alternative
reelle), on se retrouve avec les grotesquitudes actuelles.
Mais bon, j'ai un peu tendance a assimiler marketing/management "fort"/site
technologiquement mal adapte/technologie tres clinquante super-modulaire
vendable sur appel d'offre qui fait plus joli aux yeux du manager qui n'y
comprend rien a qui on fait miroiter le mythe du mois-homme, et les SSII
qui font leur beurre la-dessus.
J'avoue que je ne comprend pas trop pourquoi personne ne s'est incruste dans
la breche pour vendre juste du train en ligne, je subodore que meme si SNCF
n'y est pour rien, il y a entente et monopole de fait...
Ca correspond a une part de mon impression: c'est dommage qu'il n'y ait pas un site sncf qui vende du billet de train. A vouloir peter plus haut que leur cul, et en ayant un tres fort trafic entretenu par la confusion (les gens VEULENT acheter du billet de train en ligne, et il n'y a pas d'alternative reelle), on se retrouve avec les grotesquitudes actuelles.
Mais bon, j'ai un peu tendance a assimiler marketing/management "fort"/site technologiquement mal adapte/technologie tres clinquante super-modulaire vendable sur appel d'offre qui fait plus joli aux yeux du manager qui n'y comprend rien a qui on fait miroiter le mythe du mois-homme, et les SSII qui font leur beurre la-dessus.
J'avoue que je ne comprend pas trop pourquoi personne ne s'est incruste dans la breche pour vendre juste du train en ligne, je subodore que meme si SNCF n'y est pour rien, il y a entente et monopole de fait...
JKB
Le 03-07-2009, ? propos de Re: Du C ou du Java dans les systèmes embarqués automobile ?, Erwan David ?crivait dans fr.comp.lang.c :
JKB écrivait :
Je plussoie vigoureusement à cette analyse (surtout lorsqu'on voit le support des threads absolument approximatif des JVM). La libpthread POSIX est ardue, mais si on ne comprend pas les mécanismes de base, on ne pourra _jamais_ utiliser de façon fiable un outil de plus haut niveau. Bref, lorsqu'on est _incapable_ de formaliser quelque chose en C, en Fortran, en ADA, autrement dit dans un langage fonctionnel ou impératif, il est _illusoire_ de vouloir sortir un code fonctionnel est entièrement débuggué avec un langage objet.
En fait, les langages à objets viennent tous avec un nombre conséquent de bibliothèques et frameworks, et il est nettement plus difficile de ne pas les utiliser. Mais si on voit le nombre important de programmes GTK qui sortent sur stederr des messages "Critical assertion : blabla", on voit que même en C ce genre de programmation est possible. Et qu'elle y fait autant de dégat (on peut d'ailleurs ce demander pourquoi le framework qualifie de critique des violations d'assertions qui n'empêchent pas le code de fonctionner...)
Bon, on ne va pas non plus disserter du côté granguignolesque des moutures de GTK. Personnellement, je code du Motif dans le texte sans avoir de souci. Ce n'est peut-être pas beau, mais c'est efficace.
Sérieusement, GTK (1, 2, +, enfin toutes les versions) sont des trucs inutilisables si on devait les utiliser à la main. Rien que ça, ça me fait dire que ce sont de mauvais produits. Qu'on utilise un générateur de code pour les systèmes de fenêtrage, pourquoi pas. Mais encore faut-il que le système de base soit sain, clair et qu'on puisse y mettre le nez q'il le faut.
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 03-07-2009, ? propos de
Re: Du C ou du Java dans les systèmes embarqués automobile ?,
Erwan David ?crivait dans fr.comp.lang.c :
JKB <knatschke@koenigsberg.fr> écrivait :
Je plussoie vigoureusement à cette analyse (surtout lorsqu'on voit
le support des threads absolument approximatif des JVM). La libpthread
POSIX est ardue, mais si on ne comprend pas les mécanismes de base, on
ne pourra _jamais_ utiliser de façon fiable un outil de plus haut
niveau. Bref, lorsqu'on est _incapable_ de formaliser quelque chose en
C, en Fortran, en ADA, autrement dit dans un langage fonctionnel ou
impératif, il est _illusoire_ de vouloir sortir un code fonctionnel est
entièrement débuggué avec un langage objet.
En fait, les langages à objets viennent tous avec un nombre conséquent
de bibliothèques et frameworks, et il est nettement plus difficile de ne
pas les utiliser. Mais si on voit le nombre important de programmes GTK
qui sortent sur stederr des messages "Critical assertion : blabla", on
voit que même en C ce genre de programmation est possible. Et qu'elle y
fait autant de dégat (on peut d'ailleurs ce demander pourquoi le
framework qualifie de critique des violations d'assertions qui
n'empêchent pas le code de fonctionner...)
Bon, on ne va pas non plus disserter du côté granguignolesque des
moutures de GTK. Personnellement, je code du Motif dans le texte sans
avoir de souci. Ce n'est peut-être pas beau, mais c'est efficace.
Sérieusement, GTK (1, 2, +, enfin toutes les versions) sont des
trucs inutilisables si on devait les utiliser à la main. Rien que ça, ça
me fait dire que ce sont de mauvais produits. Qu'on utilise un
générateur de code pour les systèmes de fenêtrage, pourquoi pas. Mais
encore faut-il que le système de base soit sain, clair et qu'on puisse y
mettre le nez q'il le faut.
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 03-07-2009, ? propos de Re: Du C ou du Java dans les systèmes embarqués automobile ?, Erwan David ?crivait dans fr.comp.lang.c :
JKB écrivait :
Je plussoie vigoureusement à cette analyse (surtout lorsqu'on voit le support des threads absolument approximatif des JVM). La libpthread POSIX est ardue, mais si on ne comprend pas les mécanismes de base, on ne pourra _jamais_ utiliser de façon fiable un outil de plus haut niveau. Bref, lorsqu'on est _incapable_ de formaliser quelque chose en C, en Fortran, en ADA, autrement dit dans un langage fonctionnel ou impératif, il est _illusoire_ de vouloir sortir un code fonctionnel est entièrement débuggué avec un langage objet.
En fait, les langages à objets viennent tous avec un nombre conséquent de bibliothèques et frameworks, et il est nettement plus difficile de ne pas les utiliser. Mais si on voit le nombre important de programmes GTK qui sortent sur stederr des messages "Critical assertion : blabla", on voit que même en C ce genre de programmation est possible. Et qu'elle y fait autant de dégat (on peut d'ailleurs ce demander pourquoi le framework qualifie de critique des violations d'assertions qui n'empêchent pas le code de fonctionner...)
Bon, on ne va pas non plus disserter du côté granguignolesque des moutures de GTK. Personnellement, je code du Motif dans le texte sans avoir de souci. Ce n'est peut-être pas beau, mais c'est efficace.
Sérieusement, GTK (1, 2, +, enfin toutes les versions) sont des trucs inutilisables si on devait les utiliser à la main. Rien que ça, ça me fait dire que ce sont de mauvais produits. Qu'on utilise un générateur de code pour les systèmes de fenêtrage, pourquoi pas. Mais encore faut-il que le système de base soit sain, clair et qu'on puisse y mettre le nez q'il le faut.
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.
Mickaël Wolff
Marc Espie a écrit :
J'avoue que je ne comprend pas trop pourquoi personne ne s'est incruste dans la breche pour vendre juste du train en ligne, je subodore que meme si SNCF n'y est pour rien, il y a entente et monopole de fait...
Si on regarde tout les sites qui sont en marque blanche (pour idtgv par exemple), on s'aperçoit que le bousin utilisé est l'horreur de voyages-sncf.com. Je suspecte fortement la SNCF de sous-traité tout ce qui à trait au Web à leur filiale. Du coup, je vois mal comment on pourrait imaginer un concurrent réel révolutionner le marché.
J'avoue que je ne comprend pas trop pourquoi personne ne s'est incruste dans
la breche pour vendre juste du train en ligne, je subodore que meme si SNCF
n'y est pour rien, il y a entente et monopole de fait...
Si on regarde tout les sites qui sont en marque blanche (pour idtgv
par exemple), on s'aperçoit que le bousin utilisé est l'horreur de
voyages-sncf.com. Je suspecte fortement la SNCF de sous-traité tout ce
qui à trait au Web à leur filiale. Du coup, je vois mal comment on
pourrait imaginer un concurrent réel révolutionner le marché.
J'avoue que je ne comprend pas trop pourquoi personne ne s'est incruste dans la breche pour vendre juste du train en ligne, je subodore que meme si SNCF n'y est pour rien, il y a entente et monopole de fait...
Si on regarde tout les sites qui sont en marque blanche (pour idtgv par exemple), on s'aperçoit que le bousin utilisé est l'horreur de voyages-sncf.com. Je suspecte fortement la SNCF de sous-traité tout ce qui à trait au Web à leur filiale. Du coup, je vois mal comment on pourrait imaginer un concurrent réel révolutionner le marché.
Erwan David a écrit : Je pense qu'il faut un peu relativiser. Ça, c'est juste un peu moins critique que du guidage de missile ou la gestion des commandes électroniques d'une voiture.
La notion d'embarqué devient plus large avec l'arrivée des téléphones, PDA, etc. C'est pourquoi je parles plutot d'embarqué critique. D'ailleurs, dans des avions, il y a de la VoD, donc c'est du code embarqué. Mais il est dans l'espace "cabine", pas avec les mêmes contraintes que le "critique".
Pour ma part, j'ai une fois discuté avec un type qui était sur les systèmes de navigation des avions de lignes. Il m'a assuré que cela se faisait en assembleur, sur PC... Les choses ont sans doute changé depuis, car c'était il y a une bonne huitaine d'années, mais le constat est le même : plus l'application est critique, plus on cherche à être proche de la machine.
Autre info dans le genre: ensuite, à partir d'un modèle du processeur et du code assembleur généré (ou écrit, mais je crois que ça se fait de moins en moins), ils calculent les pires temps d'exécution, pour chaque tache.
Marc Boyer -- Au XXIème siècle, notre projet de société s'est réduit à un projet économique...
On 2009-07-03, Hamiral <hamiral@hamham.com> wrote:
Erwan David a écrit :
Je pense qu'il faut un peu relativiser. Ça, c'est juste un peu moins
critique que du guidage de missile ou la gestion des commandes
électroniques d'une voiture.
La notion d'embarqué devient plus large avec l'arrivée des
téléphones, PDA, etc. C'est pourquoi je parles plutot d'embarqué
critique.
D'ailleurs, dans des avions, il y a de la VoD, donc c'est
du code embarqué. Mais il est dans l'espace "cabine", pas
avec les mêmes contraintes que le "critique".
Pour ma part, j'ai une fois discuté avec un type qui était sur les
systèmes de navigation des avions de lignes. Il m'a assuré que cela se
faisait en assembleur, sur PC... Les choses ont sans doute changé
depuis, car c'était il y a une bonne huitaine d'années, mais le constat
est le même : plus l'application est critique, plus on cherche à être
proche de la machine.
Autre info dans le genre: ensuite, à partir d'un modèle du processeur
et du code assembleur généré (ou écrit, mais je crois que ça se fait
de moins en moins), ils calculent les pires temps d'exécution,
pour chaque tache.
Marc Boyer
--
Au XXIème siècle, notre projet de société s'est réduit
à un projet économique...
Erwan David a écrit : Je pense qu'il faut un peu relativiser. Ça, c'est juste un peu moins critique que du guidage de missile ou la gestion des commandes électroniques d'une voiture.
La notion d'embarqué devient plus large avec l'arrivée des téléphones, PDA, etc. C'est pourquoi je parles plutot d'embarqué critique. D'ailleurs, dans des avions, il y a de la VoD, donc c'est du code embarqué. Mais il est dans l'espace "cabine", pas avec les mêmes contraintes que le "critique".
Pour ma part, j'ai une fois discuté avec un type qui était sur les systèmes de navigation des avions de lignes. Il m'a assuré que cela se faisait en assembleur, sur PC... Les choses ont sans doute changé depuis, car c'était il y a une bonne huitaine d'années, mais le constat est le même : plus l'application est critique, plus on cherche à être proche de la machine.
Autre info dans le genre: ensuite, à partir d'un modèle du processeur et du code assembleur généré (ou écrit, mais je crois que ça se fait de moins en moins), ils calculent les pires temps d'exécution, pour chaque tache.
Marc Boyer -- Au XXIème siècle, notre projet de société s'est réduit à un projet économique...
Hamiral
Marc Boyer a écrit :
Alors que Tetris ou mégaman sur NES, c'était plutôt en année.
Tetris beaucoup moins qu'un an, mégaman certainement plus :)
Ham
Marc Boyer a écrit :
Alors que Tetris ou mégaman sur NES, c'était plutôt en année.
Tetris beaucoup moins qu'un an, mégaman certainement plus :)
