IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Linux Discussion :

Le bug de l'an 2000 se reproduira en 2038 dans le monde Linux


Sujet :

Linux

  1. #1
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Data Consultant
    Inscrit en
    Juillet 2013
    Messages
    2 873
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Data Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2013
    Messages : 2 873
    Points : 86 887
    Points
    86 887
    Billets dans le blog
    2
    Par défaut Le bug de l'an 2000 se reproduira en 2038 dans le monde Linux
    Le bug de l'an 2000 se reproduira en 2038 dans le monde Linux
    Mais c'est maintenant qu'il faut s'inquiéter selon Jon Corbet

    Jon Corbet, chroniqueur de longue date du noyau Linux a exprimé son inquiétude par rapport à une menace imminente qui pourrait affecter les systèmes Linux et autres systèmes compatibles avec Unix en 2038.

    Le problème est similaire au bug Y2k ou bug de l'an 2000 qui a affecté les systèmes fonctionnant sur 2 digits. En effet, avant l'an 2000, plusieurs programmes informatiques enregistraient les années sur 2 chiffres à partir de 1900, ce qui donnait par exemple 80 pour 1980. Le problème qui est survenu en 2000 est que les programmes ne pouvaient plus distinguer par exemple l'année 1900 de l'année 2000, puisque les 2 années avaient le même code, soit 00. Ce bug a eu de nombreuses conséquences étant donné que tous les systèmes informatiques s'appuient fortement sur les horloges pour faire marcher presque toutes les fonctions.

    En ce qui concerne le système Linux et les systèmes compatibles avec Unix, les codes temporels "time_t" stockent la date et l'heure comme un entier signé de 32 bits représentant le nombre de secondes depuis le 1er Janvier 1970 (00:00:00 1970). A partir de 2038, plus exactement le 19 Janvier 2038 à 3:14:07 GMT, il n' y aura plus assez de bits pour stocker les dates allant au-delà, d'où un nouveau bug de l'an 2038 pour le monde Linux. Cela affectera tous les systèmes Linux 32 bits.

    Vous direz peut-être que ce n'est pas un problème en soit, puisque d'ici là, de nombreux systèmes seront tournés vers un horodatage 64 bits. Mais le problème est que rien ne prouve que les systèmes 32 bits seront abandonnées, la preuve en est qu’aujourd'hui, beaucoup de systèmes embarqués utilisent encore des processeurs 16 bits ou même 8 bits et un grand nombre de systèmes dits embarqués utilisent Linux 32 bits. En plus, ces systèmes sont rarement remplacés une fois qu'ils sont installés.

    Jon Corbet, voyant la menace s'approcher à grands pas, a déclaré lors du récent sommet de collaboration de la fondation Linux à Santa Rosa en Californie, qu’ « il est temps de commencer à s'inquiéter

    « Les systèmes basés sur Linux sont implémentés dans des voitures, dans la construction de systèmes de contrôle, dans les centrales électriques, et dans, qui sait combien, plusieurs autres endroits où ils y seront tout simplement placer et feront leur travail jusqu'à ce time_t vienne à manquer de bits. Et alors ils ne fonctionneront plus. » A-t-il déclaré.

    Il pense que les développeurs devraient songer à arrêter les expéditions de logiciels avec ce problème et commencer à travailler sur la manière d'éviter la menace avant qu'elle ne nous surprenne car les conséquences seront graves.

    « Si nous continuons à distribuer des logiciels qui ont ce problème en eux, nous mettons en place des problèmes pour l'avenir, et nous ne voulons pas faire cela», a déclaré Corbet. « Le temps de le réparer, c'est maintenant », a-t-il ajouté.


    Source : Kit Guru

    Et vous?


    Que pensez vous de l'avertissement de Jon Corbet ?

    Quelles seraient les conséquences du bug 2038 ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Inactif  

    Homme Profil pro
    NR
    Inscrit en
    Juin 2013
    Messages
    3 715
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : NR
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Juin 2013
    Messages : 3 715
    Points : 1 184
    Points
    1 184
    Billets dans le blog
    9
    Par défaut
    En ce qui concerne le système Linux et les systèmes compatibles avec Unix, les codes temporels "time_t" stockent la date et l'heure comme un entier signé de 32 bits représentant le nombre de secondes depuis le 1er Janvier 1970 (00:00:00 1970). A partir de 2038, plus exactement le 19 Janvier 2038 à 3:14:07 GMT, il n' y aura plus assez de bits pour stocker les dates allant au-delà, d'où un nouveau bug de l'an 2038 pour le monde Linux. Cela affectera tous les systèmes Linux 32 bits.
    Ça provoquerait quel bug exactement ? le système croira que l'on est en 1970 (pas très grave je pense dans 90% des appareils) ou bien on aura un kernel panic ?

  3. #3
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Développeur
    Inscrit en
    Juillet 2013
    Messages
    1 423
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 1 423
    Points : 8 699
    Points
    8 699
    Billets dans le blog
    43
    Par défaut
    Je suis sûr que de nombreuses SSII seront d'accord pour dire qu'il s'agit là d'un problème extrêmement préoccupant.
    Tutoriels et FAQ TypeScript

  4. #4
    Membre extrêmement actif
    Homme Profil pro
    Graphic Programmer
    Inscrit en
    Mars 2006
    Messages
    1 532
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Graphic Programmer
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2006
    Messages : 1 532
    Points : 3 880
    Points
    3 880
    Par défaut
    il y a une multitude de secteur on ça pose portable de ce croire en 1900. les secteurs financiers par exemple

  5. #5
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Développeur
    Inscrit en
    Juillet 2013
    Messages
    1 423
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 1 423
    Points : 8 699
    Points
    8 699
    Billets dans le blog
    43
    Par défaut
    Sauf que la prévalence de Linux dans le domaine financier pur, je suis très sceptique.
    Et dans ce domaine, éloigné du matériel, une migration des applications vers du 64 bits résout simplement le souci.
    Tutoriels et FAQ TypeScript

  6. #6
    Membre éprouvé Avatar de fenkys
    Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2007
    Messages
    376
    Détails du profil
    Informations personnelles :
    Âge : 56
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Octobre 2007
    Messages : 376
    Points : 1 054
    Points
    1 054
    Par défaut
    C'est une erreur dans la traduction ou l'auteur a réellement parlé de Linux. Parce que c'est un problème lié à Unix en général est pas juste à Linux.

    Une petite précision, le passage de 2038 ne fera pas passer le système en 1970 mais plutot en 1902 (le time_t est signé pour pouvoir exprimer des dates antérieures à 1970).

    Personnellement, je pense que la plupart des système embarqué 8, 16 et 32 bits, aujourd'hui seront certainement hors d'usage d'ici 2038. Se préoccuper de cela maintenant alors qu'on ne sait exactement quels seront les systèmes ayant survécu à cette date future me semble un peu prématuré.

  7. #7
    Membre averti
    Profil pro
    Inscrit en
    Mai 2007
    Messages
    192
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2007
    Messages : 192
    Points : 395
    Points
    395
    Par défaut
    Se préoccuper de cela maintenant alors qu'on ne sait exactement quels seront les systèmes ayant survécu à cette date future me semble un peu prématuré
    Bon nombre de programmes doivent gérer des dates "dans le futur". Il faut bien être capable de pouvoir entrer ces dates.

  8. #8
    Expert confirmé Avatar de AoCannaille
    Inscrit en
    Juin 2009
    Messages
    1 409
    Détails du profil
    Informations forums :
    Inscription : Juin 2009
    Messages : 1 409
    Points : 4 713
    Points
    4 713
    Par défaut
    Citation Envoyé par yahiko Voir le message
    Sauf que la prévalence de Linux dans le domaine financier pur, je suis très sceptique.
    Et dans ce domaine, éloigné du matériel, une migration des applications vers du 64 bits résout simplement le souci.
    Pas forcément. sur certains projets où la gestion de la maitrise de la mémoire est à l'octet prêt (type avionique), chaque type est redéfini, et donc on nous interdisait le "int" et on nous imposait une analyse de bornes necessaires par variable et d'utiliser int8 , int16, int32, uint32 etc...
    Donc changer d'architecture ne suffira pas. Pourtant au final on était assez éloigné des limites matérielles, par contre l’important était vraiment la maîtrise réelle et démontrable de la mémoire.

  9. #9
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Développeur
    Inscrit en
    Juillet 2013
    Messages
    1 423
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 1 423
    Points : 8 699
    Points
    8 699
    Billets dans le blog
    43
    Par défaut
    Intéressant... Mais je te "rassure", les applis financières ne sont pas nécessairement programmées par des ingénieurs rigoureux, loin de là
    Tutoriels et FAQ TypeScript

  10. #10
    Inactif  

    Homme Profil pro
    NR
    Inscrit en
    Juin 2013
    Messages
    3 715
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : NR
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Juin 2013
    Messages : 3 715
    Points : 1 184
    Points
    1 184
    Billets dans le blog
    9
    Par défaut
    Une petite précision, le passage de 2038 ne fera pas passer le système en 1970 mais plutot en 1902
    Mais je croyait que c'était impossible de mettre une date inférieure au 1 janvier 1970 ?

    Enfin, quand j'étais étudiant je me suis essayée a mettre la date en 1960 sa n'a jamais marché

  11. #11
    Modérateur

    Avatar de Bktero
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Juin 2009
    Messages
    4 480
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués

    Informations forums :
    Inscription : Juin 2009
    Messages : 4 480
    Points : 13 677
    Points
    13 677
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par fenkys Voir le message
    Personnellement, je pense que la plupart des système embarqué 8, 16 et 32 bits, aujourd'hui seront certainement hors d'usage d'ici 2038. Se préoccuper de cela maintenant alors qu'on ne sait exactement quels seront les systèmes ayant survécu à cette date future me semble un peu prématuré.
    Le problème n'est pas tant celui des systèmes déjà dans la nature (qui ne seront sans doute pas tous morts en 2038). Le problème est qu'il n'y a pas actuellement de solution déjà massivement acceptée (à ma connaissance) et qu'on continue donc à lâcher dans la nature des systèmes avec ce potentiel problème. Certes 23 ans ça parait long, mais c'est la durée de vie de nombreux systèmes embarqués. On pourrait imaginer une solution simple comme une modification du type time_t pour être une valeur sur 64 bits et non 32 bits mais cela impose de recompiler les programmes, les revalider, pour certains les recertifier, et les redéployer. Autrement dit, pour beaucoup de systèmes, c'est mission quasi-impossible. Il faut donc bien traiter à la source et arrêter de déployer des systèmes qui vont nous péter à la figure (ou à celle de nos enfants ^^).

    Remarquez, je dis ça, mais je bosse sur un nouveau système embarqué dont le temps est codé sur 32 bits... Mais, bon, il ne devrait pas vivre 23 ans (j'espère !)

  12. #12
    Membre averti
    Inscrit en
    Octobre 2005
    Messages
    135
    Détails du profil
    Informations forums :
    Inscription : Octobre 2005
    Messages : 135
    Points : 391
    Points
    391
    Par défaut
    Citation Envoyé par fenkys Voir le message
    Personnellement, je pense que la plupart des système embarqué 8, 16 et 32 bits, aujourd'hui seront certainement hors d'usage d'ici 2038. Se préoccuper de cela maintenant alors qu'on ne sait exactement quels seront les systèmes ayant survécu à cette date future me semble un peu prématuré.
    C'est ce que se disait les développeur dans les années 80 et on vu le résultat.
    Il reste en gros 20 ans.
    Certain logiciel dure facilement 20 ans ( faut voir les administrations et les banques).
    Une voiture çà se garde 20 ans et il y a de plus en plus d’électronique a l’intérieur.
    En prenant des mesure maintenant, cela coutera moins d'argent que de le faire plus tard.

  13. #13
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Data Consultant
    Inscrit en
    Juillet 2013
    Messages
    2 873
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Data Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2013
    Messages : 2 873
    Points : 86 887
    Points
    86 887
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par fenkys Voir le message
    C'est une erreur dans la traduction ou l'auteur a réellement parlé de Linux. Parce que c'est un problème lié à Unix en général est pas juste à Linux.
    Dans l'article
    Jon Corbet, chroniqueur de longue date du noyau Linux a exprimé son inquiétude par rapport à une menace imminente qui pourrait affecter les systèmes Linux et AUTRES SYTEMES COMPATIBLES AVEC UNIX en 2038.
    Citation Envoyé par fenkys Voir le message
    Une petite précision, le passage de 2038 ne fera pas passer le système en 1970 mais plutot en 1902 (le time_t est signé pour pouvoir exprimer des dates antérieures à 1970).
    Dans l'article
    les codes temporels "time_t" stockent la date et l'heure comme un entier signé de 32 bits représentant le nombre de secondes DEPUIS le 1er Janvier 1970 (00:00:00 1970).
    Avec time_t , on peut gérer une période totale de 232 secondes, soit à peu près 136 années. La date la plus reculée est 13 décembre 1901, et la plus avancée est 19 janvier 2038.

    Donc avec time_t, on peut passer à 1902 comme tu l'as dit. Mais je crois que l'intervalle de 136 années en centré en 1970 (1970 -136/2 = 1902 et 1970+136/2=2038).

    Corrige moi si je me trompe car je ne suis pas expert en la matière.

    Voir aussi: heure Unix , Year 2038
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  14. #14
    Membre éprouvé Avatar de fenkys
    Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2007
    Messages
    376
    Détails du profil
    Informations personnelles :
    Âge : 56
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Octobre 2007
    Messages : 376
    Points : 1 054
    Points
    1 054
    Par défaut
    Citation Envoyé par sazearte Voir le message
    Mais je croyait que c'était impossible de mettre une date inférieure au 1 janvier 1970 ?

    Enfin, quand j'étais étudiant je me suis essayée a mettre la date en 1960 sa n'a jamais marché
    Pourtant ça fait partie de la norme. Le time_t, dans un environnement 32 bits est un entier signé (pouvant exprimer des dates de 1902 à 2038).

  15. #15
    Membre régulier
    Inscrit en
    Mars 2010
    Messages
    24
    Détails du profil
    Informations forums :
    Inscription : Mars 2010
    Messages : 24
    Points : 71
    Points
    71
    Par défaut
    Le problème vient du langage C et non de Linux en particulier. Il existe le même soucis potentiel sous Windows...

    Le soucis est que la manière de représenter le temps (qui a effectivement une origine POSIX) atteint ces limites sous sa représentation 32 bits en 2038...
    Après effectivement si on utilise une représentation 64 bits, cela donne de la marge...

    Mais le soucis n'est pas forcement du coté du code mais si ce format est utilisé dans une représentation "stocké".... Par exemple le format ZIP a (si je ne m'abuse) une structure utilisant ce type en 32 bits...
    Je vous laisse imaginer l'impact que peut avoir un changement de structure dans un fichier binaire...

  16. #16
    Membre éprouvé

    Homme Profil pro
    Développeur PHP/Symfony // Mentor OpenClassrooms
    Inscrit en
    Octobre 2014
    Messages
    203
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hautes Alpes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur PHP/Symfony // Mentor OpenClassrooms
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Octobre 2014
    Messages : 203
    Points : 1 264
    Points
    1 264
    Billets dans le blog
    3
    Par défaut
    Migrer un majorité de système en 64 bits d'ici là est envisageable, risqué mais envisageable, cela prendra du temps, de l'argent et des ressourcs mais le défis en vaut la chandelle.

    Bon nombre de services se basent sur du 32 bits et on été écrit par des ingénieurs pas franchement rigoureux, on en voit le résultat futur ...

  17. #17
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 549
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 549
    Points : 15 450
    Points
    15 450
    Par défaut
    Citation Envoyé par sazearte Voir le message
    Sa provoquerait quel bug exactement ? le système croira que l'on est en 1970 (pas très grave je pense dans 90% des appareils) ou bien on aura un kernel panic ?
    Ça dépendra totalement des applications. Un plantage n'est pas a exclure, mais pour les applis qui se fichent de la date, il est en effet probable que ça n'aura aucun effet.

    Citation Envoyé par cuicui78 Voir le message
    il y a une multitude de secteur on ça pose portable de ce croire en 1900. les secteurs financiers par exemple
    Citation Envoyé par yahiko Voir le message
    Sauf que la prévalence de Linux dans le domaine financier pur, je suis très sceptique.
    Et dans ce domaine, éloigné du matériel, une migration des applications vers du 64 bits résout simplement le souci.
    Les secteurs financiers sont bien au courant du problème et ont l'habitude de travailler avec des dates notamment dans le futur. Je ne me fait pas trop de soucis pour eux.
    Les financier utilisent beaucoup de serveurs Unix/Linux, mais ça fait un moment qu'ils ont pris l'habitude de travailler avec des date de 64 bit.

    Citation Envoyé par fenkys Voir le message
    C'est une erreur dans la traduction ou l'auteur a réellement parlé de Linux. Parce que c'est un problème lié à Unix en général est pas juste à Linux.
    C'est un abus de langage, de nos jour plus de 90% de ce qu'on appelle des Unix sont des Linux, même si ça ferra raller les puriste qui rappelleront que Linux n'est pas UNIX. Bref on va pas chipoter, il y a de toute façon aussi des application Windows qui utilisent le format de date UNIX et qui seront donc concernées aussi.

    Citation Envoyé par fenkys Voir le message
    Personnellement, je pense que la plupart des système embarqué 8, 16 et 32 bits, aujourd'hui seront certainement hors d'usage d'ici 2038. Se préoccuper de cela maintenant alors qu'on ne sait exactement quels seront les systèmes ayant survécu à cette date future me semble un peu prématuré.
    Bien sur il serait complètement idiot de rendre des a présent compatible des application qui auront certainement disparu en 2038, ce n'est pas du tout ce que le monsieur propose. Il dit juste que ça ne coute presque rien de s'en préoccuper maintenant pour les nouvelles applications et permettra de faire des économies à l'avenir, donc autant le faire.

  18. #18
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    Février 2015
    Messages
    22
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Février 2015
    Messages : 22
    Points : 22
    Points
    22
    Par défaut Rien ne sera fait!
    Comme d'habitude ils vont s'en préoccuper 6 mois avant et tout leur pétera à la gueule

  19. #19
    MikeRowSoft
    Invité(e)
    Par défaut
    Comme c'est drôle. Il n'y a pas la taille et le format de l'information avant d'y accéder, même à base de "goto".

  20. #20
    Membre extrêmement actif
    Homme Profil pro
    Graphic Programmer
    Inscrit en
    Mars 2006
    Messages
    1 532
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Graphic Programmer
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2006
    Messages : 1 532
    Points : 3 880
    Points
    3 880
    Par défaut
    c'est ballot pour la sonde voyager 1. Quand les extraterrestre tomberont dessus, il penseront qu'elle vient d'a coté faisant des boucles de 136 ans....

Discussions similaires

  1. Réponses: 1
    Dernier message: 30/08/2006, 16h09
  2. Bug IE si je rajoute des sauts de lignes dans le CS
    Par Invité dans le forum Balisage (X)HTML et validation W3C
    Réponses: 11
    Dernier message: 14/06/2006, 21h07
  3. [SQL-SERVER 2000] Remplacer l'instruction GO dans requete
    Par Sytchev3 dans le forum MS SQL Server
    Réponses: 3
    Dernier message: 05/04/2006, 15h24
  4. [SQL Server 2000] ajouter une colonne identité dans une vue?
    Par CetTer dans le forum MS SQL Server
    Réponses: 3
    Dernier message: 02/08/2005, 14h43

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo