En résumé, et d'après ce que j'ai compris, le 2.6 n'est plus considéré comme une vrai branche stable, mais une branche ou on peut expérimenter.
La stabilisation du 2.6 sera donc maintenant confié au distribution.
http://kerneltrap.org/node/view/3513(...)
J'ai pas fait de dépêche, mon niveau en anglais et en histoire du noyau sont trop faible pour ça. Si quelqu'un en a envie, qu'il le fasse :^)
Journal Le noyau linux change de mode de développement
22
juil.
2004
# heu
Posté par Alexandre . Évalué à 1.
[^] # Re: heu
Posté par Alexandre . Évalué à 1.
# Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Utilisation du noyau d'origine
Posté par totof2000 . Évalué à 2.
Il vaut mieux également quand on a une distribution (sauf pour Slackware à ma connaissance qui utilise les source officiels du noyau) récupérer les sources sur le site de la distribution pour recompiler son noyau, car chaque distribution apporte déjà ses modifs.
Ca ne changera donc pas grand chose en pratique pour beaucoup de monde (sauf pour ceux qui passent leur temps à recompiler leur noyaiu en prenant des bouts de code à droite et à gauche ...).
[^] # Re: Utilisation du noyau d'origine
Posté par Guillaume Knispel . Évalué à 10.
Si chaque distributeur est incité à mettre ses propres patchs et si un 2.6.42 fonctionne totalement differement et est completement incompatible avec un 2.6.43, alors on court déplorablement vers un système de plus en plus fermé ou les distribution ne pourront plus fonctionner qu'avec un noyeau précis et sous un control unique. A ce niveau la autant achetter du windows. De plus la disponibilité pereine des noyeau des distributeurs est bien moins assurée que celle des noyeaux officiels (sur kernel.org tu peux recuperer a peu près tous les noyeaux officiels qui ont existé).
Bref je ne vois pas ca d'un très bon oeil. D'autant que meme si les utilisateurs ne s'en rendent pas forcement compte, les changement d'API peuvent etre desastreux dans le user space et certaine applications sont aujourd'hui cassées en partie à cause de ca.
[^] # Re: Utilisation du noyau d'origine
Posté par Elrik de Melnibone . Évalué à 3.
Bof !
Les noyaux des distribs sont déjà patchés dans tous les sens.
Je pense que les mainteneurs du noyau se sont dit que maintenir un noyau stable avec les distribs qui patchent comme des folles ne servaient à rien.
[^] # Re: Utilisation du noyau d'origine
Posté par totof2000 . Évalué à 2.
Ce que j'espère quand même c'est que les différentes distribs feront un retour des paths appliqués de façon à les intégrer au noyau officiel (et qu'elles n'attendront pas que ce soien les mainteneurs du noyau qui aillent chercher les modifs).
[^] # Re: Utilisation du noyau d'origine
Posté par Prae . Évalué à 0.
Meme si Linus s'est déjà exprimé sur ce sujet, je trouve cela regrettable d'avoir à recompiler certains modules pour switcher de version (meme minime)
Selon Linus, si on a les sources cela ne devrait pas poser de problème... mais pour ceux qui ne les ont pas; et bien ils sont obligés d'installer une version du kernel compatible avec le module en question (le monde à l'envers quoi !)
Je sais que Dell ou IBM ont crée une couche d'abstraction pour cela.
Pour éviter ce genre de problème de compatibilité kernel/modules
[^] # Re: Utilisation du noyau d'origine
Posté par Pooly (site web personnel) . Évalué à 5.
compatible RedHat 9.0 (ou autre), au lieu d'un compatible Noyau 2.6.4,....
# Numéro deux
Posté par farib . Évalué à -4.
# c'est complétement n'importe quoi
Posté par zebul666 . Évalué à 10.
Il y est dit que linux et andrew ne voit pas le besoin de se presser à créer une branche 2.7. Pas avant que divers choses soit merger d'abord dans la branche -mm puis eventuellement dans le 2.6 (comme MODULE_PARM etc...) ET puis seulement à ce moment là créer une branche 2.7 en laissant au fabriquant de distrib produire des patchs (qui seront mergés dans la branche stable 2.6) pour le stabiliser ....
[^] # Re: c'est complétement n'importe quoi
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
[^] # Re: c'est complétement n'importe quoi
Posté par Rin Jin (site web personnel) . Évalué à 5.
http://slashdot.org/article.pl?sid=04/07/22/0138244(...)
Les deux liens sont relativement différents et j'avoue ne pas trop suivre:
/. dit "le 2.6 sera expérimental... le coup du pair=stable, impair=instable c'est fini"
KT dit "on va tester (patch mm) avant de les refiler au 2.6 si ça marche (eventually).
J'ai l'impression que l'auteur du journal a découvert ça sur /., a traduit puis a donné le lien vers KT, en oubliant le lien vers /.
[^] # Re: c'est complétement n'importe quoi
Posté par Thomas Maurin (site web personnel) . Évalué à 2.
tant que ça peut faire progresser le kernel je vois pas trop où est le mal
et puis on finira sans doûte par retomber sur l'alternance pair/impair lorsqu'il y aura la première release du 2.7
mais tant que le duo Andrew/Linus fonctionnera bien ils ne verront pas l'intérêt d'appliquer une nouvelle fois la contraignante division en une branche dév et une branche stable
[^] # Re: c'est complétement n'importe quoi
Posté par ccomb (site web personnel) . Évalué à 3.
Attention, "eventually" est un faux-ami, ça veut pas dire "eventuellement", mais "finalement", ou "par la suite".
# Re:
Posté par 007 . Évalué à 0.
C'était déjà le cas depuis un bon moment.
L'upstream fait le travail de fond et les distributeurs corrigent les petits bobo qui restent. Corrections qui sont reportés à la version suivante de Linux.
Ça fait déjà depuis longtemps qu'une nouvelle version de Linux n'est pas sortie uniquement pour corriger un trou de sécurité ou un bug. Ce sont les distributeurs qui font ça.
Je trouve ça normal. Puis qui compile depuis les sources ?
A part quelques "rebelles".
Par contre, les fantasmes de fork par distribution, restent ...
des fantasmes.
[^] # Re: Re:
Posté par Fabio Parisi (site web personnel) . Évalué à 2.
A part quelques "rebelles".
Moi, et je pense pas être un rebelle ni être le seul.
<sondage a 2 balles> Et vous ? </sondage a 2 balles>
[^] # Re: Re:
Posté par beagf (site web personnel) . Évalué à 2.
Etant sous Nasgaïa qui est basée sur le noyau officiel sans aucune modif, je maintient mon noyau a jour avec les noyeau officiel, je suis encore au noyau 2.4 (j'ai essayée 2.6 mais pour l'instant je suis revenu au 2.4) et à chaque fois qu'une nouvelle version sort je dl le patche et je recompile. Jamais eu de problème avec.
[^] # Re: Re:
Posté par lezardbreton . Évalué à 2.
Cela dit, nous sommes d'accord pour dire que Nasgaïa est une exception de ce côté puisque nous n'avons pas encore fait d'outils permettant facilement les mises à jour de paquetages.
Je rappelle quand même que Slackware ne patche pas les noyaux (à part failles de sécu).
Pour rejoindre le file de discussion, je ne compile mon noyau que pour les distributions non-binaires et sur Nasgaia. Sinon, je prends les noyaux officiels de la distribution. Mandrake par exemple inclut dans les noyaux le driver eagle-usb sous forme de module, ce qui est extrêmement pratique.
Par contre, j'ai un gros coup de gueule à faire sur les distributions (pas de nom, faites une recherche sur kerneltrap) pour lesquelles des patchs sont obligatoires pour pouvoir booter. C'est une connerie manifeste et je ne vois pas quelle pourrait être la raison ultime.
[^] # Re: Re:
Posté par beagf (site web personnel) . Évalué à 2.
[^] # Re: Re:
Posté par totof2000 . Évalué à 1.
J'avais tenté il y a longtemps avec une RedHat .... LA machine ramait à mort ...
[^] # Re: Re:
Posté par MsK` . Évalué à 1.
[^] # Re: Re:
Posté par mcjyc (site web personnel) . Évalué à 1.
regarde le merveilleux travail du projet fedora legacy.
c'est vraiment un projet que j'admire (pas seulement parce qu'il me retire une sacree epine du pieds...)
pour le dernier kernel, je ne peux pas attendre la longue phase de test.
je compille depuis kernel.org.
autre exemple.
si tu veux monter un firewall transparent, il faut patcher un noyau en accord avec le patch en rapport avec le projet ebtables...
ta distrib ne l'inclu pas forcement (je ne connais pas l'ensemble des kernels des differente distrib...)
donc, encore une fois...
je suis pas un rebelle moi ?
[^] # Re: Re:
Posté par ckyl . Évalué à 2.
Des rebels utilisant fedora et qui aimerai bien que leur noyau n'Oops pas sur des cp massif sur de l'ext3 (2.6.6) ou qui trouve ridicule d'activer le 4:4 par defaut sur une distrib (je suis sur que 99% des gens utilisant fedora ont plus de 16GB de RAM ce qui justifie le cout a l'execution...) etc.
J'ai jamais autant de problèmes qu'en utilisant le noyau des distribs qui "reparent les ptits bobo". C'est bizarre mais les vanillas ne m'ont jamais posés de problèmes...
[^] # Re: Re: Re:
Posté par 007 . Évalué à 1.
ok ok ok.
Les vanillas sont nickels et ce sont que les méchants distributeurs qui ajoutent des bugs dedans. C'est connu... D'ailleur dès qu'il y a un bug dans Linux une nouvelle version sort. Mais oui...
Voir ça par exemple :
http://linuxfr.org/2004/06/15/16537.html(...)
Mais redevenons sérieux.
Avant de vous énerver encore plus, je recompile aussi mon noyau car REGPARM ne marche pas avec un driver que j'utilise. Mais sinon je garderai celui par défaut.
Tu vois quoi sur les forum :
- Comment on recompile un noyau ?
- tu copies /boot/config-.... /usr/src/linux, puis "make install"
La majorité c'est ça. L'autre grande majorité ne recompile pas.
Il m'arrive aussi de me tromper dans la configuration de mon noyau "customiser" alors que je compile linux depuis 1.2 (et à l'époque c'était pratiquement obligatoire).
Cette "histoire" de recompiler le noyau, c'est comme pour apache. Avant il fallait recompiler apache, maintenant c'est plus nécessaire et ceux qui recompile apache sont rares. Avant il fallait recompile mplayer (obligatoire) et maintenant presque tout le monde fait "apt/yum install mplayer". C'est une tendance lourde et qui est absolument normale. Je me trompe ?
Ce qui est arrivé aux autres (apache, mplayer, mod_ssl, etc) va arriver à Linux.
> Des rebels utilisant fedora et qui aimerai bien que leur noyau n'Oops pas sur des cp massif sur de l'ext3 (2.6.6)
T'as un rapport de bug ? C'était sûrement un noyau de développement (rawhide). J'ai utilisé tous les noyau FC2 depuis la FC2T2 et j'ai pas vu ce problème.
Fedora est un peu particulier. Fedora est là pour "imposer" des nouvelles techno (dont 4kstack qui ne marche pas avec NVidia).
Pour l'"esprit" Fedora, relire :
http://fedora.redhat.com/about/(...)
Si tu me trouves une distribution grand public ou entreprise qui dans le manuel d'installation ou d'administration indique "il faut recompiler le noyau", tu me fais signe.
[^] # Re: Re: Re:
Posté par ckyl . Évalué à 2.
Oui parmis la tonne de patch appliqués par mdk, rh ou SuSE y'en a qui merdent et d'autre merdes aussi dans le vanilla.
J'ai eu des problemes avec ces trois distribs et repasser sur un vanilla reglait le problème. Maintenir de tels patchs n'est clairement pas evident, moi ce que je constate c'est qu'il y en a au moins un qui m'emmerde et qui fait se vautrer ma machine lors d'un bete cp (de quelque GO quand meme) ou mount.
> http://linuxfr.org/2004/06/15/16537.html(...(...))
Le problème c'est que tu mélange tout. Faire une update de sécu ce n'est pas grave, c'est normal et il y a peu de risque de pourrir la chose avec.
> Tu vois quoi sur les forum :
Je m'en fou je lis pas les forums des apprentis compileurs de kenelle.
> C'est une tendance lourde et qui est absolument normale. Je me trompe ?
Oui c'est une tendence lourde. On a tous debuter et cru qu'on gagnait 13,30495% de perf en compilant (et en cassant tout au passage). Je ferais un apt-get install de kernel-vanilla ca me derange pas non plus si les options sont pas débiles :-)
> T'as un rapport de bug ?
non pas le temps d'investiguer je pars en vacance demain. On verra au retour 'il est toujours present. Mais c'est 100% reproductible et peut probable que ce soit materiel vu que j'ai fait 5 x 20Go en XFS et 4 x 20Go en reiserfs et ca n'a jamais explosé (avec md5 pour verifier)
> Si tu me trouves une distribution grand public ou entreprise qui dans le manuel d'installation ou d'administration indique "il faut recompiler le noyau", tu me fais signe.
A aucun moment je n'ai parle de recompiler son noyau. Personellement j'en compile un paquet par ce que je m'interesse a certaines parties en devel ou fait de petites exprerimentations mais sur une machine de desktop je demande juste que ca fonctionne rien de plus rien de moins. Par contre quand tu vois des choix absurdent tel que 4:4 de base ca ne va pas inciter les gens a moins recompiler...
[^] # Re: Re: Re:
Posté par 007 . Évalué à 0.
Des fichiers de plusieurs Go, mon PC en bouffe. J'utilise mon PC pour enregistrer la TV et je te garanti que ça bouffe cette "saloperie" quand tu veux une bonne définition.
J'ai un uptime tout frais car j'ai mis à jours (trou de sécurité qui n'est pas en upstream...). Mais avant j'avais plus de 30 jours. A 10 Go par jours (minimum) ça fait dans les 300 Go de donnée de brassé (ext3 avec 4:4 :-)). Chaque fichier fait dans les 2 à 6 Go.
> Oui parmis la tonne de patch appliqués par mdk, rh ou SuSE y'en a qui merdent et d'autre merdes aussi dans le vanilla.
Oui. Mais ...
Si Mdk, etc ajoutent ces patchs, c'est pas pour rien. Globalement l'objectif est d'améliorer l'expérience de l'utilisateur. Si globalement ça ne fait qu'emmerder l'utilisateur, tu penses pas bien qu'ils ne vont pas se faire chier à maintenir ces patchs.
Puis il y a une différence entre Linux upstream (le développement) et les distributions. Les distributions peuvent fait une patch "moche" mais qui corrige un bug très génant pour l'utilisateur.
Linux (upstream) ajoutera ce patch lorsqu'il sera propre. Il ne faut pas qu'un hack "moche" soit la base des autres développements.
C'est un élément important et même très important.
Il faut bien différencier le développement (mettre en place une infrastructure solide) et la maintenance (corriger les petits bobo même si c'est fait de façon immonde).
> Le problème c'est que tu mélange tout. Faire une update de sécu ce n'est pas grave, c'est normal et il y a peu de risque de pourrir la chose avec.
Tu parles en "rebelle" (je suis un "rebelle", ne vous énervez pas). Tu trouves normal de demander à l'utilisateur final de suivre les failles de sécurité, de patcher un noyau, de recompiler ? Normal pour un "rebelle". Pas normal pour un utilisateur lambda.
Depuis longtemps (au moins le 2.4), le Linux vanilla n'est plus un noyau "out of the box". C'est un noyau qu'il faut utiliser en étant abonné à la lkml (faille de sécurité, gros bug (genre le dernier ext3)).
> non pas le temps d'investiguer je pars en vacance demain.
Bonne vacance (enfoiré :-)).
> Personellement j'en compile un paquet par ce que je m'interesse a certaines parties en devel ou fait de petites exprerimentations
Le "rebelle touch". C'est respectable. J'utilise Fedora, donc je vais pas critiquer l'attitude.
> Par contre quand tu vois des choix absurdent tel que 4:4 de base ca ne va pas inciter les gens a moins recompiler...
Pssss...
C'est pour Fedora ( relis http://fedora.redhat.com/about/(...) ).
Puis ce patch est limite "vieux" (devait "trainer" dans FC1 (peut-être RH9 ?), est dans RHEL 3 depuis longtemps).
Tu ne te sers pas de 4:4 et moi non plus. Mais ça interressent des gens. Pour les clients de Red Hat c'est important (sinon pourquoi Red Hat ce fait chié avec ça ?).
Il faut que Red Hat sorte un noyau avec 4:4, un sans 4:4, un avec usb, un sans usb, un autre avec SeLinux, un autre sans SeLinux, etc...
Non, c'est ingérable.
Il faut que le noyau "de base" supporte le maximum de configuration sinon c'est l'enfer à maintenir, tester (trouver des testeurs pour 50 configurations de noyau différente pour chaque correction de bug/sécurité, c'est dure...).
Tu fais une fixation sur le noyau mais je suis sûre que si tu regardais d'autres programmes tu verrais plein de truc que tu n'utilises pas non plus.
Installes une Gentoo.
btw, les patchs Red Hat se retrouvent très souvent dans le vanilla. Donc c'est débile pour toi quand c'est Red Hat "only" et c'est bien quand c'est dans vanilla.
4kstack dans FC2 c'est nul. Mais maintenant que c'est dans 2.6.7 c'est bien. Logique... (tu peux m'expliquer ?).
Pour que ça rentre en upstream (et fasse ton bonheur) et faut faire du travail en amont. Linus ne va pas accepter des patch intrusifs sans un minimum de test et de feedback des utilisateurs. Et Fedora est fait aussi pour ça.
J'insiste, relis ça :
http://fedora.redhat.com/about/(...)
[^] # Re: Re: Re:
Posté par ckyl . Évalué à 2.
Il faut que Red Hat sorte un noyau avec 4:4, un sans 4:4, un avec usb, un sans usb, un autre avec SeLinux, un autre sans SeLinux, etc...
Le problème c'est que ca sert a 0.000001% des utilisateurs de fedora (tu connais beaucoup de personnes assez debiles pour avoir 16..64Go de RAM sur un x86) et que ca plombe les perfs de tout le reste de facon non negligeable (ca depend surtout du type d'applis en fait). Dans ce cas oui ca me parait plutot approprie de proposer un noyau special pour les 3 personnes qui vont utiliser la chose.
Les mecs de RH font de tres bonne choses, plus ou moins utile (mais toujours utiles pour certains de leurs clients :-). Ce que je remet en cause c'est de faire manger a tout le monde des patches "degeulasses" sur le plan esthetiique/technique alors que le besoin n'est pas la.
[^] # Re: Re: Re:
Posté par 007 . Évalué à 0.
Ah bon. Si tu le dis...
N'empêche que des gens installent Fedora sur du 64 bits car 32 ça commence a être un peu limité.
> tu connais beaucoup de personnes assez debiles pour avoir 16..64Go de RAM sur un x86
Beaucoup non mais j'en connais. D'ailleur Windows a un équivalent de 4g/4g.
> et que ca plombe les perfs de tout le reste de facon non negligeable
Un bench ?
> Dans ce cas oui ca me parait plutot approprie de proposer un noyau special pour les 3 personnes qui vont utiliser la chose.
Rererererererererelire : http://fedora.redhat.com/about/(...)
Red Hat fait une distribution gratos et en profite pour faire RHEL avec. Les utilisateurs de Fedora sont contents car c'est gratos et ça aide le logiciel libre et Red Hat est content car ça leur permet de développer RHEL qui rapporte du pognon et qui permet de développer le logiciel libre.
Comme d'habitude, les gens veulent tout de Red Hat et sans contre partie. Ben faut pas rèver.
http://fedora.redhat.com/(...)
What is The Fedora Project?
The Fedora Project is a Red-Hat-sponsored and community-supported open source project. It is also a proving ground for new technology that may eventually make its way into Red Hat products.
C'est sur la homepage et au tout début. Tu es prévenu. Si ça te plait, tu passes ton chemin.
Merci au revoir.
[^] # Re: Re: Re:
Posté par ckyl . Évalué à 2.
Tiens le bon sens parle :-)
> Un bench ?
http://lkml.org/lkml/2004/4/6/84(...)
y'a eu d'autre discutions sur le sujet. A partir du moment ou tu as des applis qui syscall a fond ca fait assez mal.
[^] # Re: Re: Re:
Posté par 007 . Évalué à 0.
Merci. Instructif.
Pour un usage desktop ça change rien (au pire 1 %).
> y'a eu d'autre discutions sur le sujet.
Pour ma part, Linux (upstream) n'a pas a intégrer ce patch. Ce patch est une optimisation temporaire car il y a encore beaucoup de système 32 bits.
Dans 3 ans tous les serveurs seront en 64 bits et ce patch ne sera plus nécessaire.
Le prix d'un système 64 bits a dramatiquement (dans le sens positif :-)) baissé.
[^] # Re: Re: Re:
Posté par totof2000 . Évalué à 1.
Il est normal a mon avis que l'utilisateur suive les failles de sécurité. Par contre effectivement, il est du ressort de la distribution de mettre à disposition les outils qui permettent de pallier à ces problèmes de la façon la plus simple possible.
[^] # Re: Re:
Posté par Yusei (Mastodon) . Évalué à 2.
[^] # Re: Re:
Posté par Olivier Serve (site web personnel) . Évalué à 2.
Suis en 2.6.8-rc2 pas pour le fun mais juste pour avoir la 3D ET le réseau en même temps.
[^] # Re: Re:
Posté par 007 . Évalué à 1.
Oui il faut profiter des sources pour se sortir de "la merde".
Oui à toussa.
Mais n'empêche que dans la grande majorité des cas, c'est plus un "workaround", un "pis-allé" que la solution définitive.
Je dis ça et des programmes j'en ai compilé des tonnes. Mais il faut être honnète. C'est actuellement une faiblesse de Linux (en grande parti du au manque de support des contructeurs de périphérique) d'être parfois obligé de compiler un noyau.
La compilation d'un noyau ne doit pas être considéré comme la procédure "normal". C'est aussi pour ça que Linux a les modules. Pour ne pas avoir a compiler systématiquement un noyau.
# C'est grave...
Posté par Pascal . Évalué à -1.
En effet, le travail es distributions n'est certainement pas de stabiliser le noyau.
Si les devellopeurs du kernel font bien leur boulot, celui sur kernel.org doit etre stable.
Le boulot des distributions est de compiler un version stable du noyau (avec eventuellement quelques patches qui doivent aussi etre considérés comme stable), de packager celui-ci et de faire agancer tous les autres programmes autour. Mais leur rôle s'arrête là. Il ne faut pas confondre le rôle des devellopeurs avec celui des distributeurs.
# Situation périlleuse....
Posté par Rafael (site web personnel) . Évalué à 3.
Je veux revenir à comme on a toujours fait, une version impaire en test surfing on the top of the wave et une version paire stable au possible.
Laisser de l'instabilité en version paire, laisser les distributions "finir" le travail de stabilité, c'est livrer le kernel aux distribs, leur laissant toute latitude d'offrir une valeur ajoutée derrière leurs contrat de maintenance.
La mission des dev noyau n'a a mon point de vue pas changé, elle doit poursuivre la voie dictée par linus.
Jusqu'içi ça a parfaitement fonctionné qualitativement, aucune raison de changer.
Linus doit parler pour clarifier le sujet
Rafael
[^] # Re: Situation périlleuse....
Posté par 007 . Évalué à 1.
Final stabilization is to be done by distributors (as happens now, really)
Ça va s'accélérer.
Je trouve ça assez bien. Par contre, le problème c'est pour les petits distributions. Il faudra plus de ressources maintenant.
Par exemple devfs va être viré et Mdk utilise devfs. C'est maintenant à Mdk de maintenir devfs pour ses produits qui l'utilisent.
[^] # Re: Situation périlleuse....
Posté par Olivier Serve (site web personnel) . Évalué à 3.
Ils ne sont pas masos au point de maintenir un truc deprécié si une meilleure alternative existe.
[^] # Re: Situation périlleuse....
Posté par 007 . Évalué à 2.
Certe. Mais tu ne comprends.
Mdk pour maintenir la 10.0 devrait maintenir devfs. Pas le chois.
Je sais bien que les prochaines Mandrake ne font pas utiliser devfs.
# option de compilation: pas de code experimental
Posté par free2.org . Évalué à 3.
donc est-ce vraiment un problème ?
[^] # Re: option de compilation: pas de code experimental
Posté par lezardbreton . Évalué à 3.
[^] # Re: option de compilation: pas de code experimental
Posté par free2.org . Évalué à 3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.