Pour avoir les deps et packages requis, tu peut t'aider des ebuilds Gentoo (très lisibles, avec des patchs interessants, sur le CVS) ou du BLFS-cvs.
Je te mets en lien le résultat d'un "emerge -epo kde" (RTFM) ; une fois avec des packages instables et une autre avec des stables. Ça devrais au moins te donner la liste des dependances correspondant à mes USEFLAGs. Les besoins de KDE 3.2 en packages stables sont ceux de KDE 3.1+ QT 3.2.
Par contre.. soyez pas trop rudes avec mon FTP, je suis pas vraiment un pro en matière de sécurité -_^. ftp://82.67.45.113/pub/kde_stable_deps(...) ftp://82.67.45.113/pub/kde_unstable_deps(...)
Pour ce qui est du temps de compilation... je me permet de rappeler l'existence de logiciels tels que ccache (cache pour GCC, indispensable si tu compile plusieurs fois des versions semblables d'un même logiciel) et distcc (compilation en clusters, pas très sûr mais efficace). http://ccache.samba.org/(...) http://distcc.samba.org/(...)
Sinon moi, du temps où je compilais KDE à la main, je préferrais utiliser BLFS que Konstruct (vu que je le connaissais pas lol).
Fait gaffe: artsdp se contente de désactiver arts pour le temps durant lequel le programe artdspisé joue du son. Il permet pas à un programe conçu pour Alsa/OSS de se connecter à Arts (ni de béneficier de la transparence réseau).
Sinon, t'as regardé JACK ? Je me suis pas bien renseigné, mais il me semble que ce soit un serveur de son temps réel qui, non seulement se connecte à Alsa, mais permet aussi à Alsa de s'y connecter. De telle sorte que tu puisse faire App(Alsa)->Alsa->JACK(réseau?)->Alsa ou même App(OSS)->Alsa-OSS->Alsa->JACK(réseau?)->Alsa
mais je suis tout sauf sûr, et j'ai pas le temps de bien regarder -_-... c'est là: http://www.alsa-project.org/alsa-doc/doc-php/asoundrc.php3#jackplug(...) http://jackit.sourceforge.net/(...)
Bein c'est vrai que maintenant qu'on a Alsa pour le mixage et les effets marrants... les serveurs de son ça fait un peu doublon -_- (sauf pour ceux qui utilisent la transparence réseau (mais oùkisont?))
Je suis pas sur que ça soit abusif: ça correspond juste à un transfert de copyright non ? J'avais lu sur ce site un post qui racontait comment ce genre de choses permettait d'interdire à des employés de réutiliser ce qu'ils avaient crée au boulot (à un tel que ça revenait à s'approprier leur expèrience professionelle)
Ceci dit, et sauf erreur de ma part, l'auteur garde en France le droit de demander la destruction de son oeuvre, de la rectifier et autres trucs de ce genre. M'enfin j'imagine mal qu'un geek français arrive à faire plier une boite amèricaine ... (je suis même pas sûr qu'il puisse demander à appliquer ce droit sur le sol amèricain)
Ah... mais non... Pas la peine d'aller chercher le troll à 14 heures. Y'en a déjà un joli sur le format packages. Et comme ça on est sur d'être HS !
Franchement, c'est facile de critiquer les tbz2. Alors que les .debs c'est à peine mieux, que les packages Redhat c'est la cata (rpm est inutilisable sans urpmi). Et que de toutes manières les packages binaires ça sux: on perds à l'utilisation le temps CPU que ça aurais pris une nuit de compilation. En plus on peut pas les personnaliser et là c'est des binaires i386! Déjà que c'était du C++... autrement dit un truc qui rame le cake, probablement autant que Redhat, voir que Debian. Surtout si on utilise un plugin Java: là on est partit pour mouliner des heures.
...
À moins qu'ils aient eu la bonne idée d'utiliser ICC ?
Parce qu'après tout, Opera c'est le seul à avoir innovés ces dernières années: ils géraient les onglets, les skins et tout ça bien avant les autres. Et en prime avec une empreinte mèmoire extremement réduite. En gros, c'est ce que Mozilla aurais du être (paske là c'est une usine à gaz, pire que KDE (mais lui c'est normal, il est trop orienté objet)).
Surtout qu'à la rigueur on s'en fout que ce soit libre: ce qui compte c'est que ça respecte les standards.
À ce propos, vous saviez qu'Nvidia venait de mettre à jour ses pilotes (1.0-4496) ?
... tu crois que quelqu'un irais mettre en place un tel serveur pour 5 clients ?
Pour être fixé, il faudrais faire une comparaison en utilisant des simples PC.
Et puis de toutes manières, l'écart de performances dans ce cas n'est pas suffisant pour qu'on le prefère à la possibilité d'evoluer (un jour il risque d'y avoir plus de 5 clients). Et probablement que, dans le cas d'une aussi petite boite, le facteur déterminant seras les goûts du type qui se chargeras de gèrer le truc.
Et de toute manière Macromedia ne propose pas de viewer standalone, rien que des plug-in, donc pour w3m ça le fait moins bien, tout de suite.
Si, "gflashplayer", un binaire d'1,32 mega, basé sur GTK, traduit en français et qui permet même de créer des "projections" (fichiers flash encapsulés dans un ELF).
Par contre, ça s'arrête à la version 6. Comme le plugin d'ailleurs -_-.
http://www.swift-tools.net/Flash/(...)
Pas testé, la descripton du paquet dans Gentoo (net-www/gplflash) nous informe qu'ils n'est compatible qu'avec les fichiers de versions infèrieures ou égales à la 4.
Les binaires Linux proposés par Mozilla.org sont maintenant compilé
avec GCC 3.2. Si vous utilisez ces binaires les plugiciels populaires
comme RelaPlayer, compilés avec une anicenne version de GCC, ne
fonctionneront pas.
T'est sûr ? Parce que moi j'ai compilé Mozilla 1.4 avec GCC 3.2 (Gentoo), et ces plugins marchent (apparement les devs Gentoo ont juste appliqué un petit patch d'une dizaine de lignes).
Le problème vient peut être d'ailleurs ?
Sauf que le "^H" à l'avantage de plus de crédibilité: personne (enfin pas moi lol -_^) ne pense au "^W", mis à part lors de la n-ième réedition de cette vieille (antique) blague de geeks.
Je viens de perdre une bonne partie de ma partoche... ça m'était jamais arrivé avec le XFS que je m'était habitué à mettre à mal sur mon précedent PC (un onduleur? c'est pour les bourges!)
Sans oublier son système de surveillance de fichier (FAM http://oss.sgi.com/projects/fam/(...)) et bien entendu leur apport à OpenGL (intègration dans XFree 86 nottement (GLX)).
Parce que les dirigeants de Gentoo ont déjà démontrée leur aptitude à ne pas écoutter la comunautée, et que mon post ne changerais rien.
Et aussi parce que je prefère pointer du doigt les défaut de l'organisation actuelle, et ainsi pousser à un changement un profondeur, que d'essayer de l'aider à se rendre crédible.
Mais surtout parce que je parle très mal anglais. -_^
Je viens de faire un "emerge sync".
emerge -p openssl
[ebuild UD] dev-libs/openssl-0.9.6j [0.9.6k]
... http://www.gentoo.org/cgi-bin/viewcvs.cgi/dev-libs/openssl/openssl-(...)
...
Si je suis de mauvaise fois, les mirroirs sont plus à jour que le CVS.
Mais non! L'histoire est encore plus drôle.
Lis l'historique du CVS: ils avaient oublié de spécifier que le package était disponible aussi pour sparc, et du coup ils ont rajoutté le mot clef "sparc" après coup.
Sans penser à mettre le "~sparc" qui aurait indiqué que c'est une version instable (sur cette architecture) !
Au passage, notte que tu as approuvée l'idée de Gentoo de ne pas mettre à jour la librairie, jusqu'à ce que tu crois qu'elle avait été mise à jour (alors qu'elle l'est par erreur, et seulement sur cette architecture). Dans ces conditions, m'accuser de mauvaise fois...
Est-ce-qu'il existe des exploits publics pour ces failles ? Non, aucun à ma connaissance.
Merveilleux: on est à l'abris des scripts kiddies ! (à priori)
Je serais très surpris que personne n'arrive à exploiter cette faille dans les trois prochains jours.
Est-ce-que l'on peut être surs, 5 minutes après l'annonce de la nouvelle version, qu'elle peut être immédiatement installée sur tous les serveurs en prod sans rien casser ? Non.
Passer de la version 0.9.6j à la 0.9.6k, sachant que cette dernière consiste juste en 4 correctifs de sécurité... disons que c'est moins risqué que de garder une version vérolée.
C'est d'ailleurs ce que se sont dit les mainteneurs des autres distros, semble-t'il.
Si tu tiens à passer immédiatement à la nouvelle version sur ta Gentoo, tu peux, le paquetage est prêt. Il suffit d'admettre que tu souhaites installer quelque chose qui n'a pas encore été complétement testé. Un délai de quelques jours avant de marquer ces paquetage "stable" me paraît tout à fait raisonnable.
Le fait est qu'un type qui fait confiance aux gestionnaires de sa distro (comme moi jusqu'à recement) se trompe.
Un type qui installe un matin une gentoo avec la dernière version des packages doit en plus lire la liste des failles récentes et appliquer les mises à jour manuellement. Ceci requierant la modification/restauration du fichier de conf, pour evitter de se faire jetter comme quoi le package est experimental (ou alors il est habitué aux errements de Gentoo, et il a des scripts ou alias à portée de main).
Et après, chaque mise à jour automatique essaieras en plus de passer tous ses packages en stable ou instable. Reste la (contraignante) possibilité d'afficher la liste les packages à mettre à jour, puis de les installer un par un. Mais alors ces packages ne seront pas supprimés par depclean, et ce même si ils ne ne sont plus utiles à aucun programe, car ils seront considérés comme utiles par eux mêmes. Jusqu'au prochain formatage.
Pour moi, cet exemple, celui du kernel, et d'autres (pas seulement au niveau des packages) ne relèvent pas de la prudence mais plutôt d'un grave problème d'organisation. Il n'y a même pas de règles régissant le passage d'un package instable en stable !
Gentoo est encore à la traine: l'ebuild de la 0.96k est distribué, et depuis hier. Mais marqué instable: pour l'utiliser, il faut l'éditer à la main ou alors spécifier son numèro de version demander à utiliser une version instable... sur le bugzilla ils prévoient le passage à la 0.97c dans quelques jours. Et en attendant, rien.
Je me rappelle que lors des dernières failles du noyau, ils avaient mis 1 mois pour intègrer les patchs à leur noyeau.
Et après il viennent parler d'une "hardened Gentoo"... ça me fait rire, même en tant qu'adepte de cette distrib.
Vivement Zynot ! (bon, oké, ça à pas l'air d'avancer trop vite en ce moment)
C'est à peu près pareil: tant que t'est pas en mode nostub, tu peut faire plein de choses sympas.
(3eme troll lancé: Qui parviendras à être encore plus lourd?)
[^] # Re: Konstruct, essayez KDE dans votre répertoire
Posté par un_brice (site web personnel) . En réponse à la dépêche Konstruct, essayez KDE dans votre répertoire. Évalué à 1.
Je te mets en lien le résultat d'un "emerge -epo kde" (RTFM) ; une fois avec des packages instables et une autre avec des stables. Ça devrais au moins te donner la liste des dependances correspondant à mes USEFLAGs. Les besoins de KDE 3.2 en packages stables sont ceux de KDE 3.1+ QT 3.2.
Par contre.. soyez pas trop rudes avec mon FTP, je suis pas vraiment un pro en matière de sécurité -_^.
ftp://82.67.45.113/pub/kde_stable_deps(...)
ftp://82.67.45.113/pub/kde_unstable_deps(...)
http://www.hu.linuxfromscratch.org/blfs/view/test/kde/core.html(...)
(BLFS-5.0-test, pour KDE 3.1.x à la base)
http://developer.kde.org/build/compile_cvs.html(...)
(au cas où tu l'aurais pas déjà vue)
Pour ce qui est du temps de compilation... je me permet de rappeler l'existence de logiciels tels que ccache (cache pour GCC, indispensable si tu compile plusieurs fois des versions semblables d'un même logiciel) et distcc (compilation en clusters, pas très sûr mais efficace).
http://ccache.samba.org/(...)
http://distcc.samba.org/(...)
Sinon moi, du temps où je compilais KDE à la main, je préferrais utiliser BLFS que Konstruct (vu que je le connaissais pas lol).
[^] # Re: Et arts dant tout ça?
Posté par un_brice (site web personnel) . En réponse à la dépêche KDE : On ferme ! (les bugs). Évalué à 1.
Sinon, t'as regardé JACK ? Je me suis pas bien renseigné, mais il me semble que ce soit un serveur de son temps réel qui, non seulement se connecte à Alsa, mais permet aussi à Alsa de s'y connecter. De telle sorte que tu puisse faire App(Alsa)->Alsa->JACK(réseau?)->Alsa ou même App(OSS)->Alsa-OSS->Alsa->JACK(réseau?)->Alsa
mais je suis tout sauf sûr, et j'ai pas le temps de bien regarder -_-... c'est là:
http://www.alsa-project.org/alsa-doc/doc-php/asoundrc.php3#jackplug(...)
http://jackit.sourceforge.net/(...)
[^] # Re: Et arts dant tout ça?
Posté par un_brice (site web personnel) . En réponse à la dépêche KDE : On ferme ! (les bugs). Évalué à 1.
[^] # Re: Support du Centrino sous Linux
Posté par un_brice (site web personnel) . En réponse à la dépêche Support du Centrino sous Linux. Évalué à 1.
Hein?
Second degré?
Ha ...
[^] # Re: La femme du patron de Vivendi fait sa cuisine au parlement européen
Posté par un_brice (site web personnel) . En réponse à la dépêche Nouvelle directive européenne sur le droit d'auteur dite « IP Enforcement ». Évalué à 3.
Si ça peut te rassurer, y'a pas que les connes qui se font tapper dessus: les couillons aussi ^_^.
http://linuxfr.org/2003/04/28/12249.html(...)
http://linuxfr.org/2003/07/08/13173.html(...)
Pis d'ailleurs je vois pas de remarque sexistes... pourtant je peut te jurer ne pas l'être. À moins que tu considère chaque allusion au fait qu'elle soit une femme comme du sexisme ? (ex: http://linuxfr.org/comments/288240.html(...))
[^] # Re: Relic Entertainment libère le code source de Homeworld
Posté par un_brice (site web personnel) . En réponse à la dépêche Relic Entertainment ouvre le code source de Homeworld. Évalué à 1.
Ceci dit, et sauf erreur de ma part, l'auteur garde en France le droit de demander la destruction de son oeuvre, de la rectifier et autres trucs de ce genre. M'enfin j'imagine mal qu'un geek français arrive à faire plier une boite amèricaine ... (je suis même pas sûr qu'il puisse demander à appliquer ce droit sur le sol amèricain)
[^] # Re: GCC 3.3.2 dans les bacs
Posté par un_brice (site web personnel) . En réponse à la dépêche GCC 3.3.2 dans les bacs. Évalué à 1.
La poule ou l'oeuf ?
[^] # Re: Forum PHP Licence GNU ?
Posté par un_brice (site web personnel) . En réponse au journal Forum PHP Licence GNU ?. Évalué à 2.
D'ailleurs Free propose ce service ^_^ (et un nom de domaine dynamique à ceux qui n'en veulent pas).
[^] # Re: Sortie de Opera 7.21 pour GNU/Linux
Posté par un_brice (site web personnel) . En réponse à la dépêche Sortie de Opera 7.21 pour GNU/Linux. Évalué à 1.
(en plus je suis malade alors faut pas m'embêter)
[^] # Re: Sortie de Opera 7.21 pour GNU/Linux
Posté par un_brice (site web personnel) . En réponse à la dépêche Sortie de Opera 7.21 pour GNU/Linux. Évalué à 6.
Franchement, c'est facile de critiquer les tbz2. Alors que les .debs c'est à peine mieux, que les packages Redhat c'est la cata (rpm est inutilisable sans urpmi). Et que de toutes manières les packages binaires ça sux: on perds à l'utilisation le temps CPU que ça aurais pris une nuit de compilation. En plus on peut pas les personnaliser et là c'est des binaires i386! Déjà que c'était du C++... autrement dit un truc qui rame le cake, probablement autant que Redhat, voir que Debian. Surtout si on utilise un plugin Java: là on est partit pour mouliner des heures.
...
À moins qu'ils aient eu la bonne idée d'utiliser ICC ?
Parce qu'après tout, Opera c'est le seul à avoir innovés ces dernières années: ils géraient les onglets, les skins et tout ça bien avant les autres. Et en prime avec une empreinte mèmoire extremement réduite. En gros, c'est ce que Mozilla aurais du être (paske là c'est une usine à gaz, pire que KDE (mais lui c'est normal, il est trop orienté objet)).
Surtout qu'à la rigueur on s'en fout que ce soit libre: ce qui compte c'est que ça respecte les standards.
À ce propos, vous saviez qu'Nvidia venait de mettre à jour ses pilotes (1.0-4496) ?
[^] # Re: Samba 3 plus rapide que Windows Serveur 2003 ?
Posté par un_brice (site web personnel) . En réponse à la dépêche Samba 3 plus rapide que Windows Serveur 2003 ?. Évalué à 1.
Pour être fixé, il faudrais faire une comparaison en utilisant des simples PC.
Et puis de toutes manières, l'écart de performances dans ce cas n'est pas suffisant pour qu'on le prefère à la possibilité d'evoluer (un jour il risque d'y avoir plus de 5 clients). Et probablement que, dans le cas d'une aussi petite boite, le facteur déterminant seras les goûts du type qui se chargeras de gèrer le truc.
[^] # Re: Sur l'ensemble des ordis que vous utilisez plus ou moins régulièrement, Flash(TM)(R)(C) est installé sur :
Posté par un_brice (site web personnel) . En réponse au sondage Sur l'ensemble des ordis que vous utilisez plus ou moins régulièrement, Flash(TM)(R)(C) est installé sur :. Évalué à 1.
Si, "gflashplayer", un binaire d'1,32 mega, basé sur GTK, traduit en français et qui permet même de créer des "projections" (fichiers flash encapsulés dans un ELF).
Par contre, ça s'arrête à la version 6. Comme le plugin d'ailleurs -_-.
[^] # Re: Sur l'ensemble des ordis que vous utilisez plus ou moins régulièrement, Flash(TM)(R)(C) est installé sur :
Posté par un_brice (site web personnel) . En réponse au sondage Sur l'ensemble des ordis que vous utilisez plus ou moins régulièrement, Flash(TM)(R)(C) est installé sur :. Évalué à 3.
Pas testé, la descripton du paquet dans Gentoo (net-www/gplflash) nous informe qu'ils n'est compatible qu'avec les fichiers de versions infèrieures ou égales à la 4.
[^] # Re: Mozilla 1.5 disponible aujourd'hui
Posté par un_brice (site web personnel) . En réponse à la dépêche Mozilla 1.5 disponible aujourd'hui. Évalué à 1.
T'est sûr ? Parce que moi j'ai compilé Mozilla 1.4 avec GCC 3.2 (Gentoo), et ces plugins marchent (apparement les devs Gentoo ont juste appliqué un petit patch d'une dizaine de lignes).
Le problème vient peut être d'ailleurs ?
[^] # Re: Premier cours
Posté par un_brice (site web personnel) . En réponse à la dépêche la MJC de Castelnau(34) accueille le Logiciel Libre. Évalué à 1.
[^] # Re: Benchmarks 'compréhensibles' des systèmes de fichiers sous Linux
Posté par un_brice (site web personnel) . En réponse à la dépêche Benchmarks 'compréhensibles' des systèmes de fichiers sous Linux. Évalué à 1.
[^] # Re: SCO vs tout le monde : SGI mets son grain de sel
Posté par un_brice (site web personnel) . En réponse à la dépêche SCO vs tout le monde : SGI mets son grain de sel. Évalué à 10.
-> SGI, c'est des gentils ^_^
(Liste de projets Libres sponsorisés par SGI:
http://oss.sgi.com/projects/(...))
[^] # Re: SCO Vs Reste du monde Libre : IBM Contre-attaque (encore)
Posté par un_brice (site web personnel) . En réponse à la dépêche SCO Vs Reste du monde Libre : IBM Contre-attaque (encore). Évalué à 1.
[^] # Re: Verisign jette l'éponge ?
Posté par un_brice (site web personnel) . En réponse à la dépêche ICANN vs. Verisign ?. Évalué à 0.
[^] # Re: Export en Flash
Posté par un_brice (site web personnel) . En réponse à la dépêche Sortie d'OpenOffice.org 1.1 finale. Évalué à 1.
En tous cas, c'est dans le prochain KDE! ^_^
[^] # Re: Gentoo, ça criant
Posté par un_brice (site web personnel) . En réponse à la dépêche Vulnérabilités dans OpenSSL. Évalué à 0.
Et aussi parce que je prefère pointer du doigt les défaut de l'organisation actuelle, et ainsi pousser à un changement un profondeur, que d'essayer de l'aider à se rendre crédible.
Mais surtout parce que je parle très mal anglais. -_^
[^] # Re: Gentoo, ça criant
Posté par un_brice (site web personnel) . En réponse à la dépêche Vulnérabilités dans OpenSSL. Évalué à 3.
Je viens de faire un "emerge sync".
emerge -p openssl
[ebuild UD] dev-libs/openssl-0.9.6j [0.9.6k]
...
http://www.gentoo.org/cgi-bin/viewcvs.cgi/dev-libs/openssl/openssl-(...)
...
Si je suis de mauvaise fois, les mirroirs sont plus à jour que le CVS.
Mais non! L'histoire est encore plus drôle.
Lis l'historique du CVS: ils avaient oublié de spécifier que le package était disponible aussi pour sparc, et du coup ils ont rajoutté le mot clef "sparc" après coup.
Sans penser à mettre le "~sparc" qui aurait indiqué que c'est une version instable (sur cette architecture) !
Au passage, notte que tu as approuvée l'idée de Gentoo de ne pas mettre à jour la librairie, jusqu'à ce que tu crois qu'elle avait été mise à jour (alors qu'elle l'est par erreur, et seulement sur cette architecture). Dans ces conditions, m'accuser de mauvaise fois...
[^] # Re: Gentoo, ça criant
Posté par un_brice (site web personnel) . En réponse à la dépêche Vulnérabilités dans OpenSSL. Évalué à 3.
Merveilleux: on est à l'abris des scripts kiddies ! (à priori)
Je serais très surpris que personne n'arrive à exploiter cette faille dans les trois prochains jours.
Passer de la version 0.9.6j à la 0.9.6k, sachant que cette dernière consiste juste en 4 correctifs de sécurité... disons que c'est moins risqué que de garder une version vérolée.
C'est d'ailleurs ce que se sont dit les mainteneurs des autres distros, semble-t'il.
Le fait est qu'un type qui fait confiance aux gestionnaires de sa distro (comme moi jusqu'à recement) se trompe.
Un type qui installe un matin une gentoo avec la dernière version des packages doit en plus lire la liste des failles récentes et appliquer les mises à jour manuellement. Ceci requierant la modification/restauration du fichier de conf, pour evitter de se faire jetter comme quoi le package est experimental (ou alors il est habitué aux errements de Gentoo, et il a des scripts ou alias à portée de main).
Et après, chaque mise à jour automatique essaieras en plus de passer tous ses packages en stable ou instable. Reste la (contraignante) possibilité d'afficher la liste les packages à mettre à jour, puis de les installer un par un. Mais alors ces packages ne seront pas supprimés par depclean, et ce même si ils ne ne sont plus utiles à aucun programe, car ils seront considérés comme utiles par eux mêmes. Jusqu'au prochain formatage.
Pour moi, cet exemple, celui du kernel, et d'autres (pas seulement au niveau des packages) ne relèvent pas de la prudence mais plutôt d'un grave problème d'organisation. Il n'y a même pas de règles régissant le passage d'un package instable en stable !
[^] # Gentoo, ça criant
Posté par un_brice (site web personnel) . En réponse à la dépêche Vulnérabilités dans OpenSSL. Évalué à 2.
Gentoo est encore à la traine: l'ebuild de la 0.96k est distribué, et depuis hier. Mais marqué instable: pour l'utiliser, il faut l'éditer à la main ou alors spécifier son numèro de version demander à utiliser une version instable... sur le bugzilla ils prévoient le passage à la 0.97c dans quelques jours. Et en attendant, rien.
Je me rappelle que lors des dernières failles du noyau, ils avaient mis 1 mois pour intègrer les patchs à leur noyeau.
Et après il viennent parler d'une "hardened Gentoo"... ça me fait rire, même en tant qu'adepte de cette distrib.
Vivement Zynot ! (bon, oké, ça à pas l'air d'avancer trop vite en ce moment)
[^] # Re: Ma console préférée
Posté par un_brice (site web personnel) . En réponse au sondage Ma console préférée. Évalué à 1.
(3eme troll lancé: Qui parviendras à être encore plus lourd?)