Il serait intéressant de savoir si d'avoir choisi VDPAU est purement fortuit (seule API disponible au début du développement) ou s'il y a une véritable raison (bonne ou mauvaise)…
Mais ça me semble quand même dommage d'avoir 3 API (une soutenue par chaque constructeur) pour faire la même chose… le choix, c'est parfois bien, parfois non… et là je crois que c'est non.
Bon newbie que je suis en openVZ, je viens de découvrir les commandes vztop et vzps qui te permettent justement de faire le trie entre les process hôtes et ceux de tes conteneurs…
Donc voilà, c'est bien ça : il faut utiliser ces nouvelles commandes à la place des traditionnelles top et ps non prévues pour fonctionner sur un noyau openVZ.
Est-ce que quelqu'un sait ce que va faire proxmox avec la sortie prochaine (disons 1er semestre 2013) de debian wheezy ? Abandon de openVZ au profit de LXC ? Bascule sur wheezy avec toujours un noyau 2.6.32 ? Rien ?
Proxmox, ce n'est qu'une surcouche à KVM et OpenVZ, pour les "manager", ce n'est pas un système de virtualisation à proprement parler.
Pour l'exemple 1 : avec OpenVZ, c'est exactement pareil, tu vois sur l'hôte avec top ou ps les process de tes conteneurs, avec les propriétaires de l'hôte.
Je pense que c'est plus les commandes top ou ps qui ne sont adaptés à ce système de conteneur.
En général pourtant l'état de l'art veut justement que tu aies un "réseau" dédié de tes noeuds vers le stockage des VM : interfaces réseaux dédiées en NFS ou iscsi dans un plan d'adressage différent ou bien idéalement du SAN…
Mais sinon, c'est sûr que tu fais avec les moyens que tu peux avoir… et proxmox se débrouille assez bien avec de petits moyens.
Cette plate-forme est attrayante car sensiblement plus puissante que le Raspberry, mais aussi plus cher (tout en restant, je te l'accorde, très abordable).
Mais en ce qui concerne l'open source, de ce que j'en lis, je crois qu'elle a encore pas mal à prouver.
(Aucun support du GPU Mali pour Linux, semble plus orientée Android, sans pour autant être officiellement supporté par CyanogenMod…).
Aller, je ne vais pas voir le verre à moitié vide, mais pour l'instant : à suivre !
Je comprends les arguments et le fait que l'annonce de rpi fait buzz commercial.
Mais je trouve un peu rabat-joie de ne pas vouloir admettre que c'est tout de même une avancée d'avoir un morceau propriétaire en moins.
Oui, il reste un "firmware" fermé et visiblement incontournable, mais c'est déjà le cas pour beaucoup de matériels.
Je me souviens de l'époque des modems USB Fast800 ADSL : Baud123 avait fait un bon lobbing sur Sagem pour obtenir les source et libérer la partie driver du modem. Ca m'avait changé la vie : certes le firmware chargé sur le modem était toujours fermé et l'API en plus opaque (Baud123 a pesté pas mal dessus), mais sur la partie driver, cela avait permis de corriger beaucoup de choses (notamment des fuites mémoire) et d'obtenir au final un périphérique très utilisable (même très stable chez moi) sous linux… Et le kernel linux restait "propre".
Pour une carte graphique d'un PC, si je prends l'exemple de mon chipset avec une radeon HD4200, certes il y a un pilote complétement libre (encore que, il y a tout de même un bout de firmware, je ne connais pas sa licence), avec la possibilité pour qui voudrait d'améliorer ce qu'il souhaite… mais au final, les performances de ce pilote libre sont toujours très loin derrière celles du pilote proprio. Il faudrait que cela soit ce dernier qui soit libéré pour être 100% gagnant pour l'utilisateur finale. Donc je ne considère pas que amd fait mieux que broadcom par exemple.
Je ne lancerais pas de troll avec NVIDIA.
Le raspberry me semble donc être un des matériels les plus libres qui existent : je ne vous dis pas d'en être un fanatique extrémiste incapable d'aucun esprit critique. Mais avoir constamment l'esprit chagrin et dénigrer les bonnes volontés qui font avancer le shmilblik, ça n'est pas top non plus.
Ton truc ressemble fortement à une guruplug : http://www.globalscaletechnologies.com/t-guruplugdetails.asp(...)
Les performances du kirkwood 1,2 Ghz associé à de la DDR 2 16 bits ne sont tout de même pas extraordinaires, on peut trouver des bench openssl qui montrent qu'on atteint environ un PIII 800 Mhz. Bon, dans l'absolu, ça peut être largement suffisant pour de l'auto-hébergement, mais perso, je trouve ça trop cher pour ce que c'est.
Un "gadget" (sans mépris) de ce genre ne devrait pas coûter plus de 150 €.
En plus attention, le kernel utilisé est souvent un peu spécifique, du coup tu n'es pas en 100% debian, et les updates de sécurité ne sont pas toujours bien suivis.
Pour le même prix, voire un peu moins, tu peux avoir un mini pc ou un netbook à base d'Atom, permettant un usage beaucoup plus classique, avec une consommation électrique qui reste à mon avis raisonnable.
Difficile d'avoir un vrai recul sur l'état de santé des différents unix proprios, mais HP a sorti son HPUX 11iV3 il y a à peine 3 ans (ce qui est récent compte tenu des cycles de vie de ces OS, du temps mis par toutes les éditeurs tiers de certifier/adapter leur applis, et donc après des clients finaux de l'adopter...) et il apportait aussi pas mal de nouveautés par rapport à la V2...
Quant à Solaris, ça vivote toujours autour des évolutions d'opensolaris, non ?
Bref tu enterres un peu vite les autres, même si c'est dûr de savoir où chacun en est vraiment. Il y a des secteurs d'activités (banques, administrations...) où on ne jure que par AIX, mais d'autres où c'est HPUX (certaines industries...) et d'autres Solaris (bon, pour ce dernier, j'ai le sentiment que ça sent le sapin, mais je ne suis pas en contact avec tous les secteurs d'activités. J'avais une expérience d'il y a 7/8 ans où il était encore assez utilisé en CAO).
J'ai pas d'info par rapport à ZFS et à ce portage, mais tu peux très bien utiliser un module noyau non GPL, mais le kernel sera alors marqué tainted.
Si la licence n'a pas changé, ce portage ne sera donc jamais inclus directement dans les sources officielles du noyau, ce qui semble largement limiter son intérêt... mais bon, pourquoi pas. Ca va encore troller sur ZFS (fanboys et anti ou pro autre chose...). De toute façon vim ça roxor plus !
imho, mieux vaut éviter le RAID 1, mais plutôt monter un système de backup automatique (rsnapshot, rsync, backuppc...) d'un disque sur l'autre 1 fois par jour, si c'est juste pour s'affranchir de la mort d'un disque...
Si c'est pour lenny donc sans troll inside, il te faut donc un dongle USB supporté sur un noyau 2.6.26 qui a plus de deux ans... il doit pas y avoir beaucoup de n ..., voire plus beaucoup de modèles encore commercialisés.
A voir dans les boutiques d'occasions, car justement plus commercialisé, le dongle usb wifi nintendo officiel fonctionne avec le module rt2x00 out of the box et sans firmware, en client et en AP, avec possibilités de forger des trames... bref accès complet.
Mais le mieux pour toi si tu veux rester en lenny, c'est sans doute de basculer vers un noyau 2.6.32 de backports.org qui lui te supportera comme suggéré la plupart des chipsets atheros, assez courant et avec firmware libre pour les plus récents (la plupart des n).
Le module e100 existe depuis très longtemps (à mon avis sur tous les 2.6.x, il existe au moins depuis 2.4). e100 et eepro100 existaient en parallèle, mais depuis déjà un moment plus c'était déjà e100 qui était recommandé. Tu ne pourrais pas voir si sur ton ancien kernel tu l'as et ou le compiler tout simplement ?
Pourquoi pas.
Pour les packages que tu souhaites mettre à jour, utiliser le dépot de dag/rpmforge ou EPEL. Mais choisir définitivement l'un ou l'autre, mélanger les dépots, c'est une mauvaise idée.
Soit en récupérant/installant les rpm à la main.
Soit en configurant yum sur ces dépots et en configurant yum d'une manière qui va bien.
Désolé, je n'ai plus d'exemple sous la main, mais de mémoire, il faut avoir un exclude=* (pour ne rien prendre par défaut) et derrière un include=liste des packages qu'on souhaite mettre à jour.
J'utilisais ça à une époque, et ça permet en effet de garder un environnement stable, nécessitant peu de maintenance et de faire évoluer juste quelques packages (n'ayant pas trop de dépendances, sinon, c'est une mauvaise idée).
Question subsidiaire : il y a-t-il une différence entre expressions rationnelles et expressions régulières ?
Oui, « expression régulière » est une traduction pas très heureuse de l'anglais « regular expression ». C'est plus correct en français d'utiliser « expression rationnelle ». Mais à part cela, c'est la même chose.
Oui, encore que sur cette somme, c'est à peu près juste si tu n'oublies pas la TVA. Tes 99 $ sont HT. Les 99 € sont TVA incluses (soit environ 20%) : 72,4 + 20% = 86,88 €. L(es) 'importateur(s) les achètent surement un peu en dessous de 99$ et se font surement plus que 13€ de marge (surement autour de 20 ou 25€), mais cela me semble tout à fait normal.
corkscrew is a simple tool to tunnel TCP connections through an HTTP proxy supporting the CONNECT method
Comme dit plus haut, l'utilisation de corkscrew suppose que le proxy accepte un CONNECT. Même si c'est seulement sur le port 443, les proxy qui acceptent celà restent assez friendly. Ce n'est pas le cas de tous les proxies, comme évoqué plus haut. Dans ce cas, corkscrew n'est d'aucune utilité et il faut encapsuler sa connexion dans des requêtes HTTP...
Être dégroupé, même que partiellement, suffit normalement, si ta ligne n'est pas trop longue, pour avoir la télé.
En fait tu n'es pas dégroupé du tout : l'offre freebox only, c'est que tu ne payes pas l'abonnement à FT, tu n'as pas de ligne téléphonique FT, mais ton ADSL est relié à un équipement de FT qui ensuite part sur un équipement Free. Et effectivement dans ce cas, pas de télé.
En dégroupé partiel : tu payes l'abonnement à FT, tu as une ligne téléphonique FT, mais au niveau ADSL tu es directement relié à Free (ou SFR, ou Bouygues, etc...) et là tu peux avoir la télé.
Et en fait, quand tu es dégroupé partiel, c'est par choix ou ignorance, car la migration en dégroupé total est toujours possible.
Hypothèse personnel : pour que les mises-à-jours de sécurité soient disponibles en même temps pour tout le monde ? (esprit d'égalité ?).
Même si c'est vrai, les mirroirs principaux sont mis à jours toutes les 4 heures...
Enfin bref, j'ai expliqué la philosophie, pour en trouver les fondements faut googliser... après de toute façon, comme pour beaucoup de choses, il y avait toujours plusieurs manières possibles de faire, il faut en choisir une, et c'est souvent affaire de goût.
Yep, on peut aussi expliquer que lors de la publication d'une nouvelle release (mineure) stable, les upgrades de securité passées sont publiées dans le depot stable, avec un numéro de version supérieur à celui de security. De la sorte, pour une nouvelle machine, le téléchargement des corrections de failles se fait depuis les mirroirs de dépots de stable au lieu de l'unique dépot centralisé security. Et oui, les postes déjà à jour re-téléchargent/installent plus ou moins la même version, mais c'est comme ça, ce n'est plus de l'upgrade de security, mais de l'upgrade de la nouvelle stable.
Bref, on peut troller sur cette manière de faire, mais c'est celle qui a été choisie par debian. Moi je la trouve assez logique et simple, après chacun son avis...
# VDPAU, VA API, XvBA
Posté par rictus (site web personnel) . En réponse à la dépêche Décodage matériel des vidéos avec le pilote libre AMD. Évalué à 5.
Il serait intéressant de savoir si d'avoir choisi VDPAU est purement fortuit (seule API disponible au début du développement) ou s'il y a une véritable raison (bonne ou mauvaise)…
Mais ça me semble quand même dommage d'avoir 3 API (une soutenue par chaque constructeur) pour faire la même chose… le choix, c'est parfois bien, parfois non… et là je crois que c'est non.
[^] # Re: Comparaison des solutions
Posté par rictus (site web personnel) . En réponse à la dépêche Proxmox, la virtualisation facile. Évalué à 1.
Bon newbie que je suis en openVZ, je viens de découvrir les commandes vztop et vzps qui te permettent justement de faire le trie entre les process hôtes et ceux de tes conteneurs…
Donc voilà, c'est bien ça : il faut utiliser ces nouvelles commandes à la place des traditionnelles top et ps non prévues pour fonctionner sur un noyau openVZ.
# Avenir proche de proxmox
Posté par rictus (site web personnel) . En réponse à la dépêche Proxmox, la virtualisation facile. Évalué à 1.
Est-ce que quelqu'un sait ce que va faire proxmox avec la sortie prochaine (disons 1er semestre 2013) de debian wheezy ? Abandon de openVZ au profit de LXC ? Bascule sur wheezy avec toujours un noyau 2.6.32 ? Rien ?
[^] # Re: Comparaison des solutions
Posté par rictus (site web personnel) . En réponse à la dépêche Proxmox, la virtualisation facile. Évalué à 2.
Proxmox, ce n'est qu'une surcouche à KVM et OpenVZ, pour les "manager", ce n'est pas un système de virtualisation à proprement parler.
Pour l'exemple 1 : avec OpenVZ, c'est exactement pareil, tu vois sur l'hôte avec top ou ps les process de tes conteneurs, avec les propriétaires de l'hôte.
Je pense que c'est plus les commandes top ou ps qui ne sont adaptés à ce système de conteneur.
[^] # Re: question sur la HA justement.
Posté par rictus (site web personnel) . En réponse à la dépêche Proxmox, la virtualisation facile. Évalué à 1.
En général pourtant l'état de l'art veut justement que tu aies un "réseau" dédié de tes noeuds vers le stockage des VM : interfaces réseaux dédiées en NFS ou iscsi dans un plan d'adressage différent ou bien idéalement du SAN…
Mais sinon, c'est sûr que tu fais avec les moyens que tu peux avoir… et proxmox se débrouille assez bien avec de petits moyens.
[^] # Re: Pétard mouillé
Posté par rictus (site web personnel) . En réponse à la dépêche Broadcom libère la pile graphique du Raspberry Pi. Évalué à 1.
Cette plate-forme est attrayante car sensiblement plus puissante que le Raspberry, mais aussi plus cher (tout en restant, je te l'accorde, très abordable).
Mais en ce qui concerne l'open source, de ce que j'en lis, je crois qu'elle a encore pas mal à prouver.
(Aucun support du GPU Mali pour Linux, semble plus orientée Android, sans pour autant être officiellement supporté par CyanogenMod…).
Aller, je ne vais pas voir le verre à moitié vide, mais pour l'instant : à suivre !
[^] # Re: Pétard mouillé
Posté par rictus (site web personnel) . En réponse à la dépêche Broadcom libère la pile graphique du Raspberry Pi. Évalué à 9.
Je comprends les arguments et le fait que l'annonce de rpi fait buzz commercial.
Mais je trouve un peu rabat-joie de ne pas vouloir admettre que c'est tout de même une avancée d'avoir un morceau propriétaire en moins.
Oui, il reste un "firmware" fermé et visiblement incontournable, mais c'est déjà le cas pour beaucoup de matériels.
Je me souviens de l'époque des modems USB Fast800 ADSL : Baud123 avait fait un bon lobbing sur Sagem pour obtenir les source et libérer la partie driver du modem. Ca m'avait changé la vie : certes le firmware chargé sur le modem était toujours fermé et l'API en plus opaque (Baud123 a pesté pas mal dessus), mais sur la partie driver, cela avait permis de corriger beaucoup de choses (notamment des fuites mémoire) et d'obtenir au final un périphérique très utilisable (même très stable chez moi) sous linux… Et le kernel linux restait "propre".
Pour une carte graphique d'un PC, si je prends l'exemple de mon chipset avec une radeon HD4200, certes il y a un pilote complétement libre (encore que, il y a tout de même un bout de firmware, je ne connais pas sa licence), avec la possibilité pour qui voudrait d'améliorer ce qu'il souhaite… mais au final, les performances de ce pilote libre sont toujours très loin derrière celles du pilote proprio. Il faudrait que cela soit ce dernier qui soit libéré pour être 100% gagnant pour l'utilisateur finale. Donc je ne considère pas que amd fait mieux que broadcom par exemple.
Je ne lancerais pas de troll avec NVIDIA.
Le raspberry me semble donc être un des matériels les plus libres qui existent : je ne vous dis pas d'en être un fanatique extrémiste incapable d'aucun esprit critique. Mais avoir constamment l'esprit chagrin et dénigrer les bonnes volontés qui font avancer le shmilblik, ça n'est pas top non plus.
[^] # Re: clone de guruplug mieux conçu ?
Posté par rictus (site web personnel) . En réponse au journal Excito B3: un serveur basse conso sous debian très joli et très ouvert !. Évalué à 1.
# clone de guruplug mieux conçu ?
Posté par rictus (site web personnel) . En réponse au journal Excito B3: un serveur basse conso sous debian très joli et très ouvert !. Évalué à 6.
Les performances du kirkwood 1,2 Ghz associé à de la DDR 2 16 bits ne sont tout de même pas extraordinaires, on peut trouver des bench openssl qui montrent qu'on atteint environ un PIII 800 Mhz. Bon, dans l'absolu, ça peut être largement suffisant pour de l'auto-hébergement, mais perso, je trouve ça trop cher pour ce que c'est.
Un "gadget" (sans mépris) de ce genre ne devrait pas coûter plus de 150 €.
En plus attention, le kernel utilisé est souvent un peu spécifique, du coup tu n'es pas en 100% debian, et les updates de sécurité ne sont pas toujours bien suivis.
Pour le même prix, voire un peu moins, tu peux avoir un mini pc ou un netbook à base d'Atom, permettant un usage beaucoup plus classique, avec une consommation électrique qui reste à mon avis raisonnable.
# erreur de ta part (!)
Posté par rictus (site web personnel) . En réponse au journal Qui a dit qu'AIX était mort ?. Évalué à 4.
Quant à Solaris, ça vivote toujours autour des évolutions d'opensolaris, non ?
Bref tu enterres un peu vite les autres, même si c'est dûr de savoir où chacun en est vraiment. Il y a des secteurs d'activités (banques, administrations...) où on ne jure que par AIX, mais d'autres où c'est HPUX (certaines industries...) et d'autres Solaris (bon, pour ce dernier, j'ai le sentiment que ça sent le sapin, mais je ne suis pas en contact avec tous les secteurs d'activités. J'avais une expérience d'il y a 7/8 ans où il était encore assez utilisé en CAO).
[^] # Re: licence ?
Posté par rictus (site web personnel) . En réponse au journal ZFS natif sous linux.... Évalué à 1.
Si la licence n'a pas changé, ce portage ne sera donc jamais inclus directement dans les sources officielles du noyau, ce qui semble largement limiter son intérêt... mais bon, pourquoi pas. Ca va encore troller sur ZFS (fanboys et anti ou pro autre chose...). De toute façon vim ça roxor plus !
[^] # Re: Question subsidiaire
Posté par rictus (site web personnel) . En réponse au message Recommandations pour un NAS. Évalué à 2.
[^] # Re: Hercule hwgusb2-54
Posté par rictus (site web personnel) . En réponse au message Carte wifi usb. Évalué à 1.
Oui, la HWGUSB2-54, c'est un rt2570 (version USB du rt2500), comme le dongle nintendo cité ci-dessus.
# Debian lenny ?
Posté par rictus (site web personnel) . En réponse au message Carte wifi usb. Évalué à 1.
A voir dans les boutiques d'occasions, car justement plus commercialisé, le dongle usb wifi nintendo officiel fonctionne avec le module rt2x00 out of the box et sans firmware, en client et en AP, avec possibilités de forger des trames... bref accès complet.
Mais le mieux pour toi si tu veux rester en lenny, c'est sans doute de basculer vers un noyau 2.6.32 de backports.org qui lui te supportera comme suggéré la plupart des chipsets atheros, assez courant et avec firmware libre pour les plus récents (la plupart des n).
# Utiliser e100 tout le temps ?
Posté par rictus (site web personnel) . En réponse au message kernel >2.6.29 et pilote eepro100. Évalué à 1.
[^] # Re: RH Desktop ?
Posté par rictus (site web personnel) . En réponse à la dépêche Red Hat Enterprise Linux 5.5 : Virtualisation et interopérabilité. Évalué à 2.
Pour les packages que tu souhaites mettre à jour, utiliser le dépot de dag/rpmforge ou EPEL. Mais choisir définitivement l'un ou l'autre, mélanger les dépots, c'est une mauvaise idée.
Soit en récupérant/installant les rpm à la main.
Soit en configurant yum sur ces dépots et en configurant yum d'une manière qui va bien.
Désolé, je n'ai plus d'exemple sous la main, mais de mémoire, il faut avoir un exclude=* (pour ne rien prendre par défaut) et derrière un include=liste des packages qu'on souhaite mettre à jour.
J'utilisais ça à une époque, et ça permet en effet de garder un environnement stable, nécessitant peu de maintenance et de faire évoluer juste quelques packages (n'ayant pas trop de dépendances, sinon, c'est une mauvaise idée).
[^] # Re: Bon, résultat ?
Posté par rictus (site web personnel) . En réponse à la dépêche Google libère la bibliothèque d'expressions rationnelles RE2. Évalué à 2.
Oui, « expression régulière » est une traduction pas très heureuse de l'anglais « regular expression ». C'est plus correct en français d'utiliser « expression rationnelle ». Mais à part cela, c'est la même chose.
[^] # Re: 99 USD != 99 EUR
Posté par rictus (site web personnel) . En réponse à la dépêche Le Ben NanoNote de Qi Hardware est en vente en Europe. Évalué à 3.
[^] # Re: Excellent.
Posté par rictus (site web personnel) . En réponse à la dépêche OpenSSH v5.4 : Certificat et Révocation. Évalué à 2.
corkscrew is a simple tool to tunnel TCP connections through an HTTP proxy supporting the CONNECT method
Comme dit plus haut, l'utilisation de corkscrew suppose que le proxy accepte un CONNECT. Même si c'est seulement sur le port 443, les proxy qui acceptent celà restent assez friendly. Ce n'est pas le cas de tous les proxies, comme évoqué plus haut. Dans ce cas, corkscrew n'est d'aucune utilité et il faut encapsuler sa connexion dans des requêtes HTTP...
[^] # Re: Au moins tu peux t'en servir ...
Posté par rictus (site web personnel) . En réponse au journal La télécommande de la freebox. Évalué à 2.
En fait tu n'es pas dégroupé du tout : l'offre freebox only, c'est que tu ne payes pas l'abonnement à FT, tu n'as pas de ligne téléphonique FT, mais ton ADSL est relié à un équipement de FT qui ensuite part sur un équipement Free. Et effectivement dans ce cas, pas de télé.
En dégroupé partiel : tu payes l'abonnement à FT, tu as une ligne téléphonique FT, mais au niveau ADSL tu es directement relié à Free (ou SFR, ou Bouygues, etc...) et là tu peux avoir la télé.
Et en fait, quand tu es dégroupé partiel, c'est par choix ou ignorance, car la migration en dégroupé total est toujours possible.
[^] # Re: stoa qui perds les pédales
Posté par rictus (site web personnel) . En réponse au journal Debian perd les pédales ?. Évalué à 2.
Hypothèse personnel : pour que les mises-à-jours de sécurité soient disponibles en même temps pour tout le monde ? (esprit d'égalité ?).
Même si c'est vrai, les mirroirs principaux sont mis à jours toutes les 4 heures...
Enfin bref, j'ai expliqué la philosophie, pour en trouver les fondements faut googliser... après de toute façon, comme pour beaucoup de choses, il y avait toujours plusieurs manières possibles de faire, il faut en choisir une, et c'est souvent affaire de goût.
[^] # Re: stoa qui perds les pédales
Posté par rictus (site web personnel) . En réponse au journal Debian perd les pédales ?. Évalué à 2.
Bref, on peut troller sur cette manière de faire, mais c'est celle qui a été choisie par debian. Moi je la trouve assez logique et simple, après chacun son avis...
[^] # Re: A quand une bécane ARM Cortex+RadeonHD?
Posté par rictus (site web personnel) . En réponse à la dépêche Open-PC l'ordinateur compatible avec le Libre. Évalué à 3.
[^] # Re: Livecd
Posté par rictus (site web personnel) . En réponse au message Lecteur CD/DVD lit plus que CD. Évalué à 1.
[^] # Re: Maj de TableOfHardware dans le nouveau wiki ?
Posté par rictus (site web personnel) . En réponse à la dépêche Sortie d'OpenWrt Kamikaze 8.09.2. Évalué à 3.