Ubuntu Ultimate Edition

Le 21-03-2009, ? propos de
Re: Ubuntu Ultimate Edition,
Jerome Lambert ?crivait dans fr.comp.os.linux.debats :

JKB wrote:

Le 21-03-2009, ? propos de
Re: Ubuntu Ultimate Edition,
Jerome Lambert ?crivait dans fr.comp.os.linux.debats :

JKB wrote:

(...)

Prends un outil au hasard comme Visiodent II et regarde _toutes_ les
entrées rajoutées par ce logiciel dans _toutes_ les branches de la base
de registre, qu'on se marre. Les principales clerfs sont dans
visiodent-40c, mais il en rajoute d'autres un peu partout. Pourquoi
est-ce que tout n'est pas sous visiodent ?

Parce que c'est le principe même et tout l'intérêt d'une base de
registre? Prend l'exemple d'un traitement de texte: il a ses propres
paramètres dans ses propres zones, mais il y a aussi des zones communes,
propres au système, où il doit se déclarer, p.ex. dans la liste des
programmes qui sont capables d'ouvrir du RTF ou du texte brut.

Nous sommes bien d'accord. Sauf qu'en pratique, ce n'est pas du tout
le cas. La configuration est éclatée dans une foutitude d'endroits qui
n'ont aucune logique apparente.

La logique de la base de registre Windows, ça s'apprend. Pour ne pas
aller loin, va sur le forum approprié: régulièrement, des problèmes
posés sont résolus avec un bon gros coup de regedit, et je ne parle même
pas de sites comme ceux de J-C Bellamy qui grouillent de trucs et
astuces à base de coups de regedit bien senti. Comme quoi c'est possible.

Des trucs et astuces. Du bricolage, quoi !...

Et je ne parle pas des clefs qui devraient être associées à la
local_user et qui se retrouvent dans local_machine et les autres
aberrations du même genre.

Si en plus ton programme est moisi...

Montre-moi un seul progiciel Windows qui n'est pas moisi parce que
le début du développement date de W3.1 et que depuis, on patche pour
suivre les évolutions.

C'est la faute de MS si les développeurs sont fainéants, maintenant? Il
leur a fallut combien de temps pour implémenter la gestion du mutli-user
dans les programmes? Ce n'était pas encore le cas lors de la sortie de
XP, alors que tout est en place depuis les premières versions de NT!

Non. Tout n'est pas en place, loin s'en faut. L'utilisateur est
toujours _local_ à une machine, même s'il ouvre une session itinérante
sur un réseau (au moins jusqu'à XP, Vista, je ne touche surtout pas !).
La vision de l'utilisateur réseau de windows, c'est "on copie les
données du serveur sur la machine locale, on copie aussi des clefs dans
la base de registe (là, on atteint le sublime de l'instabilité), puis on
essaye d'ouvrir la session comme si c'était une session locale". Si
jamais ça ne fonctionne pas, on a au mieux une session locale, au pire
un plantage.

Dans la même veine, il y a encore une palanqué de programmes sous MacOS
X (y compris des libres!) qui se basent toujours sur l'API héritée de
MacOS 9 (Carbon), alors que ça fait près de 10 ans qu'on doit faire
autrement. Apple a eu le courage de trancher: cette API ne sera plus
présente dans MacOS X 10.6. Je n'ose imaginer le scandale si Microsoft
faisait de même sous Windows.

Microsoft l'a déjà fait. Sais-tu pourquoi les applications DOS pures
ne tournent plus sous XP ? Simplement parce que l'interruption 21 a été
subtilement changée.

Au passage, pour MacOS, tu viens de prouver que tu ne connais rien à
l'architecture de MacOS, mais passons. Une partie de l'API de MacOS
classic était en ROM (et c'est même pour ça que les Mac oldworld était
assez foireux à utiliser avec autre chose que MacOS). Depuis qu'Apple fait
avec des processeurs Intel, ils ont réécrit tout un tas de choses dans l'API,
donc forcément, un jour où l'autre, l'API de MacOS classic allait tomber,
ne serait-ce qu'avec l'abandon des PPC.

Et si, dans un autre domaine, MS a décidé que dorénavant les drivers non
certifiés ne seraient plus installables sur les version 64 bits de ses
OS alors que sur les versions 32 bits on pouvait outrepasser
l'avertissement, c'est qu'il y a une excellente raison à ça.

Une seule : le fait de vendre à prix d'or des certifications. La
certification en question n'est pas du tout un gage de qualité du code,
mais certifie que le pilote en question est bien conforme à celui qui a
été certifié par Microsoft. J'ai aussi en exemple des pilotes tout à
fait officiel de Microsoft (un truc aussi bête qu'un pilote générique
postscript) qui faisaient rebooter un W2k. Alors la certification...

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 21-03-2009, ? propos de
Re: Ubuntu Ultimate Edition,
Kevin Denis ?crivait dans fr.comp.os.linux.debats :

Le 21-03-2009, JKB <knatschke@koenigsberg.fr> a écrit :

Le slow ssh keyscan, c'est un botnet constitué de beaucoup de machines,
dont _chacune_ demande _un_ mot de passe à ta machine. Je ne vois pas en
quoi fail2ban peut aider, mais si tu as une configuration qui permet
d'être tranquille, je la prends.

Oui, j'ai une configuration qui me permet d'être tranquille parce
que j'utilise mes propres modules dans fail2ban. En particulier je
blackliste toutes les adresses en dehors d'un pool de whitelist dès que
j'ai trop d'erreurs dans les logs.

Ok.
Donc tu es incapable de savoir à l'avance si tu es capable de te logger
depuis une IP qui ne fait pas partie de la whitelist?
Autant limiter directement l'accès au pool d'IP whitelisté.

Ce n'est pas exactement la même chose. D'autant que mes scripts
blacklistent pour des durées aléatoires des plages d'adresses. Mais
comme tu as déjà du mal à lire _et_ à comprendre, je pense que ça va te
passer largement au-dessus de la tête.

[certificat de deux ans]

Dommage.

Oh oui, tu peux le dire.

Non. Je suis paranoïaque et les utilisateurs n'ont généralement
pas à se logguer directement sur mes machines.

Je parle d'utilisateurs sous debian qui se loggent ailleurs. Pas des
utilisateurs qui se loggent sur une debian.

Le problème est le suivant:
J'ai une fedora. Un gars sous debian se logge chez moi.
La faille openssl debian est divulguée. Alors que je suis sous _fedora_ je
dois me dépecher de corriger le problème.

Lorsqu'une faille windows sort, je ne suis pas impacté car je ne suis
pas sous windows. Lorsqu'une faille d'un système autre que le mien me
touche directement, je ne suis pas content.

Imaginons un site web https protégé par fail2ban dont l'accès se
fait via un login/pass. Je sniffe l'échange de trafic, je déchiffre,

Sniffe tant que tu veux.

La confidentialité des informations échangées entre ton site web et ton
client n'est pas importante? Il y a beaucoup d'autres choses à récupérer
qu'un login/password.

Si, elle est importante. Elle est même tellement importante que je
t'ai expliqué plus haut que même si tu avais le couple login/password,
ça ne suffisait toujours pas à te connecter. C'est difficile à
comprendre ? As-tu déjà vu comment les systèmes bancaires fonctionnaient
? J'utilise à peu près le même principe.

Cette faille a touché beaucoup de monde, elle est dramatique, et sa portée
dépasse très largement une faille comme vmsplice qui te permet seulement
de passer root à la condition d'avoir déjà un compte shell sur la
machine..

C'est au contraire _très_ facile vu le nombre de machines
administrées par des pieds

Certes. Donc tu considères la faille debian mineure parceque tu n'es
pas touché car tu es paranoïaque et la faille vmsplice majeure car des
machines mal administrées se sont fait percer, c'est ça?

Je n'ai jamais dit ça. J'essaye simplement de te faire comprendre
(mais j'ai déjà eu des discussions plus intéressantes avec un poteau
télégraphique) que l'erreur est de faire confiance _aveuglément_ à un
système quel qu'il soit. Les emmerdes peuvent venir de n'importe où, de
ton propre fait (configuration foireuse) ou de celle de tiers (logiciels
foireux). Dans le premier cas, tu fermes ta gueule en attendant que
l'orage passe et en t'agrippant à ton bureau. Je prétends juste que
dans le second cas, tu es aussi responsable - au moins en partie - du
problème. Tu es responsable non pas de la bourde qui était dans une
bibliothèque debian, mais de l'utilisation aveugle de la bibliothèque
openssl.

Non, les deux sont emmerdantes et pour les mêmes raisons, à savoir
l'incompétence des administrateurs.

Si tu n'as pas le noyau concerné, tu n'est _pas_ impacté par la faille
vmsplice.
Si tu n'as pas de debian, tu _es_ concerné par la faille debian.
Et pour moi, c'est une énorme différence dans laquelle la compétence
des administrateurs n'a rien à voir.

Si. La compétence des administrateurs est en jeu à partir du moment
où ils ont choisi pour des données sensibles un seul mécanisme de
protection. Mais après, c'est toi qui voit et tu fais ce que tu veux.
Je vais même te donner un scoop. Les données les plus sensibles que je
traite sont sous OpenVMS, simplement parce qu'entre le login et le mot
de passe (par ssh) et l'arrivée du prompt, il y a cinq mécanismes
successifs d'authentification. Le problème, sous Unix, c'est qu'on doit
bricoler pour en arriver là.

Quand Peugeot détecte un problème sur un de ses modèles, il fait revenir
ses voitures. Dans le cas de la faille opensssl, Peugeot aurait du
demander à _tous_ les constructeurs auto de faire revenir leurs
modèles. C'est quand même d'une autre portée.

De plus, cette faille debian s'étale dans le temps. Imagine que tu aies
des captures réseaux chiffrées. Ca ne coûte pas cher de vérifier si elles
ont été faites avec une des clés faibles debian. Alors que la faille
vmsplice, une fois corrigée, c'est fini.

<EOT> pour moi. Cette discussion ne mène vraiment nulle part.

Réponds ce que tu veux. J'espère simplement que tu ne bosses pas dans
la sécurité informatique et que tu ne traites pas de données sensibles.

JKB

PS: tu peux continuer, mais tu seras seul.

--
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.

Nicolas George a écrit :

Jerome Lambert , dans le message
<49c4f5dc$0$2846$ba620e4c@news.skynet.be>, a écrit :

Un Windows *bien géré* ne pose pas plus de problèmes que quoi ce soit
d'autres.

Si, ça pose des problèmes à celui qui le gère.

Ça tombe bien, c'est le cas pour tous les OS...

Le 21-03-2009, Jerome Lambert <jerome.lambert@swing.be> a écrit :

Hugolino a écrit :
> Le 21-03-2009, Jerome Lambert <jerome.lambert@swing.be> a écrit :
>> Les former et leur apprendre à gérer convenablement un OS est amha
>> bien plus payant pour tout le monde.
>
> Et c'est bien sûr avec Windows® que ça va être le plus facile...

Un Windows *bien géré* ne pose pas plus de problèmes que quoi ce soit
d'autres.

Ce que tu viens de dire s'appelle une tautologie, c'est à dire qu'il ne
peut être que vrai, *par définition*, qu'un OS bien géré ne pose pas de
problème (sauf à l'admin, bien sûr).
Mais il était question ici, *d'apprendre* à le gérer correctement, et je
te dis que pour ça aussi, Windows® est une sombre merde.


--

> Tu veux la commande pour me mettre dans ta blacklist ?
Et rater le phénomène de foire le plus célèbre du petit monde
linuxo-useneto-ircien francophone après luc2 ?
Certainement pas.

Professeur Méphisto a exprimé avec précision :

Le Sat, 21 Mar 2009 09:48:45 +0100, *.-pipolin-.* a écrit :

ste misère

C'est votre sainte patronne ?

non, c'est juste ta condition...

--
Toutes les fautes d'orthographes de ce message sont sous copyright et
sont la propriété exclusive de l'auteur de ce message, toutes
reproductions est interdite et donnerais lieu à des poursuites.
© pipolin

JKB a écrit :

Le 21-03-2009, ? propos de
Re: Ubuntu Ultimate Edition,
Jerome Lambert ?crivait dans fr.comp.os.linux.debats :

JKB wrote:

Le 21-03-2009, ? propos de
Re: Ubuntu Ultimate Edition,
Jerome Lambert ?crivait dans fr.comp.os.linux.debats :

JKB wrote:

Et je ne parle pas des clefs qui devraient être associées à la
local_user et qui se retrouvent dans local_machine et les autres
aberrations du même genre.

Si en plus ton programme est moisi...

Montre-moi un seul progiciel Windows qui n'est pas moisi parce que
le début du développement date de W3.1 et que depuis, on patche pour
suivre les évolutions.

C'est la faute de MS si les développeurs sont fainéants, maintenant? Il
leur a fallut combien de temps pour implémenter la gestion du mutli-user
dans les programmes? Ce n'était pas encore le cas lors de la sortie de
XP, alors que tout est en place depuis les premières versions de NT!

Non. Tout n'est pas en place, loin s'en faut. L'utilisateur est
toujours _local_ à une machine, même s'il ouvre une session itinérante
sur un réseau (au moins jusqu'à XP, Vista, je ne touche surtout pas !).

Je m'en fous, ce n'est pas de ça que je te parle, mais p.ex. du fait que
certains antivirus ne mettaient à jour leur base de signatures que si on
ouvrait une session administrateur sur la machine, et ce jusqu'en 2005,
soit bien après la sortie d'XP. De mon point de vue, ça montre juste que
cet éditeur a des employés qui programment avec deux pieds gauches, et
non que l'OS pose problème, d'autant plus que ce comportement idiot a
depuis été corrigé.

Dans la même veine, il y a encore une palanqué de programmes sous MacOS
X (y compris des libres!) qui se basent toujours sur l'API héritée de
MacOS 9 (Carbon), alors que ça fait près de 10 ans qu'on doit faire
autrement. Apple a eu le courage de trancher: cette API ne sera plus
présente dans MacOS X 10.6. Je n'ose imaginer le scandale si Microsoft
faisait de même sous Windows.

Microsoft l'a déjà fait. Sais-tu pourquoi les applications DOS pures
ne tournent plus sous XP ? Simplement parce que l'interruption 21 a été
subtilement changée.

Et après combien de temps? Si j'en crois la roadmap Microsoft, il est
préférable d'utiliser l'API Windows depuis au moins Windows 95.

Au passage, pour MacOS, tu viens de prouver que tu ne connais rien à
l'architecture de MacOS, mais passons. Une partie de l'API de MacOS
classic était en ROM (et c'est même pour ça que les Mac oldworld était
assez foireux à utiliser avec autre chose que MacOS). Depuis qu'Apple fait
avec des processeurs Intel, ils ont réécrit tout un tas de choses dans l'API,
donc forcément, un jour où l'autre, l'API de MacOS classic allait tomber,
ne serait-ce qu'avec l'abandon des PPC.

Et toi tu confonds Carbon et Classic. Carbon tourne sous MacIntel, avec
au hasard des programmes comme Firefox, Thunderbird et autre
OpenOffice.org, Classic non. Mais bon, passons comme tu dis si bien.

Et si, dans un autre domaine, MS a décidé que dorénavant les drivers non
certifiés ne seraient plus installables sur les version 64 bits de ses
OS alors que sur les versions 32 bits on pouvait outrepasser
l'avertissement, c'est qu'il y a une excellente raison à ça.

Une seule : le fait de vendre à prix d'or des certifications.

Et certainement pas parce qu'entre 60 et 70% des écrans bleu sont dûs à
des pilotes non certifiés et méchamment plantogènes, avec Nvidia en
champion toutes catégories.

Jerome Lambert , dans le message
<49c51c08$0$2864$ba620e4c@news.skynet.be>, a écrit :

Ça tombe bien, c'est le cas pour tous les OS...

À différents degrés.

Nicolas George a écrit :

Jerome Lambert , dans le message
<49c51c08$0$2864$ba620e4c@news.skynet.be>, a écrit :

Ça tombe bien, c'est le cas pour tous les OS...

À différents degrés.

Mais ça en pose quand même, merci de ton soutien.

Le 21-03-2009, Jerome Lambert <jerome.lambert@swing.be> a écrit :

Hugolino a écrit :
> Le 21-03-2009, Jerome Lambert <jerome.lambert@swing.be> a écrit :
>> Hugolino a écrit :
(...)
>>> Il n'y a aucune contradiction entre dire que windows est une sombre
>>> merde qui ne peut fonctionner que s'il a été verrouillé par un admin
>>> compétent et dire que *si* on veut verrouiller un poste bureautique,
>>> alors c'est plus facile à faire avec un Linux.
>> En l'occurrence, ce n'est pas ce que tu as écris: tu reproches à
>> Windows de limiter les utilisateurs,
>
> Oui. Windows® est une sombre merde. Quoique tu veuilles faire, tu sais
> que ça va mal se passer...

Du tout, c'est quoi que *tu* veuilles faire, mais à te lire j'ai
l'impression que la limite est située entre la chaise et le clavier.

Je vais aller dans ton sens... Il est tout à fait évident que, vu les
merdes et les crasses causés par cet erzatz d'OS pour techno-crétin, je
ne m'approche plus de la config d'un Windows® que contraint, forcé et à
reculons. Et en général pour arriver à la conclusion que mes tentatives
étaient de toutes manières vaines, car je ne cherchais qu'à contourner
une "feature by design" implantée dans l'OS, et que « désolé, c'est pas
possible ».
Le truc, c'est que Windows® ne permet pas à l'admin de faire ce qu'il
veut.

>> et tu propose une solution qui est la meilleure pour limiter les
>> utilisateurs.
> Oui mais là, on ne parle plus de la même limitation. Et je parlais
> plutôt de verrouillage. Ça t'avait échappé où tu remplaçais juste un mot
> par l'autre pour servir ton troll moisi ?

Pas de réponse à cette remarque ?

> Donc si tu veux verrouiller les utilisateurs
Oh non, je ne veux surtout pas le faire...

C'est toi qui parlais de ta boîte et des utilisateurs de postes XP
verrouillés, hein ?
Si, une fois que je te dis que c'est plus facile à faire avec Linux, tu
préfères changer de sujet de conversation, on dira que c'est parce que
tu ne veux pas t'enfoncer encore plus et passer pour un charlot
complet...

>>> Il m'est impossible de faire confiance à un OS, conçu par des
>>> esprits malades, qui présente des boîtes de dialogue proposant d'«
>>> activer la désactivation ».
>> Tu parles bien de cet OS dont certains services se désactivent par la ligne
>> disable = yes
>> placée dans les bons fichiers de configuration?
> Non, je parlais de cette merde de Windows®.
Pourtant tu fais bien confiance à un OS qui présente des lignes de
fichier de configuration où l'on propose "d'activer la désactivation",
puisque l'extrait ci-dessous vient d'un fichier de conf de xinetd sous
Debian.

Non. « Désactiver = oui » et « activer la désactivation », ça n'est pas
la même chose.
Dans la première, ça me semble évident que l'option considérée est
désactivée même si on aurait pu souhaiter un « enable = no », alors que
dans le deuxième cas il s'agit d'une tentative malheureuse de transcrire
en "bon français" la même chose.

Et c'est ça qui fait peur, lorsque je lis « activer la désactivation »,
ça me choque parce que ça n'est tout simplement pas du "bon français".
Le simple fait que Crimosoft ait laissé passer une horreur sémantique
comme celle-là montre la considération qu'ils ont pour le pauvre abruti
chargé de configurer leur bouze.

Encore une fois tu te contredis...

Bin non, essaie encore :)))


--
Il n'y a que trois sortes de gens : ceux qui savent compter et ceux qui
ne savent pas.
Hugo (né il y a 1 417 111 338 secondes)

Le 21-03-2009, ? propos de
Re: Ubuntu Ultimate Edition,
Jerome Lambert ?crivait dans fr.comp.os.linux.debats :

JKB a écrit :

Le 21-03-2009, ? propos de
Re: Ubuntu Ultimate Edition,
Jerome Lambert ?crivait dans fr.comp.os.linux.debats :

JKB wrote:

Le 21-03-2009, ? propos de
Re: Ubuntu Ultimate Edition,
Jerome Lambert ?crivait dans fr.comp.os.linux.debats :

JKB wrote:

Et je ne parle pas des clefs qui devraient être associées à la
local_user et qui se retrouvent dans local_machine et les autres
aberrations du même genre.

Si en plus ton programme est moisi...

Montre-moi un seul progiciel Windows qui n'est pas moisi parce que
le début du développement date de W3.1 et que depuis, on patche pour
suivre les évolutions.

C'est la faute de MS si les développeurs sont fainéants, maintenant? Il
leur a fallut combien de temps pour implémenter la gestion du mutli-user
dans les programmes? Ce n'était pas encore le cas lors de la sortie de
XP, alors que tout est en place depuis les premières versions de NT!

Non. Tout n'est pas en place, loin s'en faut. L'utilisateur est
toujours _local_ à une machine, même s'il ouvre une session itinérante
sur un réseau (au moins jusqu'à XP, Vista, je ne touche surtout pas !).

Je m'en fous, ce n'est pas de ça que je te parle, mais p.ex. du fait que
certains antivirus ne mettaient à jour leur base de signatures que si on
ouvrait une session administrateur sur la machine, et ce jusqu'en 2005,
soit bien après la sortie d'XP. De mon point de vue, ça montre juste que
cet éditeur a des employés qui programment avec deux pieds gauches, et
non que l'OS pose problème, d'autant plus que ce comportement idiot a
depuis été corrigé.

Ou des employés qui ont des notions de sécurité. Qu'un antivirus
tourne dans une session utilisateur avec les droits de l'utilisateur me
paraît grotesque parce que l'utilisateur peut le désactiver.

Dans la même veine, il y a encore une palanqué de programmes sous MacOS
X (y compris des libres!) qui se basent toujours sur l'API héritée de
MacOS 9 (Carbon), alors que ça fait près de 10 ans qu'on doit faire
autrement. Apple a eu le courage de trancher: cette API ne sera plus
présente dans MacOS X 10.6. Je n'ose imaginer le scandale si Microsoft
faisait de même sous Windows.

Microsoft l'a déjà fait. Sais-tu pourquoi les applications DOS pures
ne tournent plus sous XP ? Simplement parce que l'interruption 21 a été
subtilement changée.

Et après combien de temps? Si j'en crois la roadmap Microsoft, il est
préférable d'utiliser l'API Windows depuis au moins Windows 95.

Dont acte. Il y a juste un truc que tu oublies, c'est que cette API
n'est pas stable.

Au passage, pour MacOS, tu viens de prouver que tu ne connais rien à
l'architecture de MacOS, mais passons. Une partie de l'API de MacOS
classic était en ROM (et c'est même pour ça que les Mac oldworld était
assez foireux à utiliser avec autre chose que MacOS). Depuis qu'Apple fait
avec des processeurs Intel, ils ont réécrit tout un tas de choses dans l'API,
donc forcément, un jour où l'autre, l'API de MacOS classic allait tomber,
ne serait-ce qu'avec l'abandon des PPC.

Et toi tu confonds Carbon et Classic. Carbon tourne sous MacIntel, avec
au hasard des programmes comme Firefox, Thunderbird et autre
OpenOffice.org, Classic non. Mais bon, passons comme tu dis si bien.

Je te parles effectivement de carbon qui est en partie dans la ROM
des Mac dits oldworld et qui n'est plus dans celle des newworld. Je
suppose qu'il t'a échappé le passage de l'un à l'autre et surtout la
raison qui a fait que carbon est passé de la ROM au disque dur.

Et si, dans un autre domaine, MS a décidé que dorénavant les drivers non
certifiés ne seraient plus installables sur les version 64 bits de ses
OS alors que sur les versions 32 bits on pouvait outrepasser
l'avertissement, c'est qu'il y a une excellente raison à ça.

Une seule : le fait de vendre à prix d'or des certifications.

Et certainement pas parce qu'entre 60 et 70% des écrans bleu sont dûs à
des pilotes non certifiés et méchamment plantogènes, avec Nvidia en
champion toutes catégories.

Ce qu'il ne faut pas lire... Comment justifies-tu le fait que des
pilotes estampillés Microsoft et filés avec les CD Windows te provoquent
des écrans bleus ? Je ne vois pas ce que la certification va changer.
Par contre, pour les fabricants qui fournissent des pilotes pour autre
chose que les Windowzeries, cela va peut-être être très dur à obtenir.
La certification n'est pas un gage de qualité, c'est un moyen de
pression. Ton raisonnement tiendrait si la qualité des pilotes d'origine
microsoftienne était irréprochable. Ce n'est pas le cas.

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.