Re: Kernel 2.4 The kernel of pain? slashdot article

2002-01-22 Par sujet Marc SCHAEFER

On Sat, 19 Jan 2002, Philippe Strauss wrote:

 N'empeche qu'a chaque noyau c'est une nouvel fin du monde: quel horreur
 il est moins stable que la version stable d'il y a deux ans.
 J'y vois rien d'autre qu'un processus normal, naturel: une version
 stable d'il y a deux ans est plus stable que la version stable
 qui vient d'etre appelee stable. On s'habitue a la stabilite

Non: il ne s'agit pas de cela.  2.4.x, x = 9 était une version tout à
fait utilisable, sans crashes, sans les problèmes de `oops, no
memory, killing XXX' de 2.2.x. Dans un certain sens elle était `meilleure'
que 2.2.x, du moins pour les serveurs.

 Mais rien n'empeche d'appliquer un patch 2.4.18-pre3-ac2 (alan cox)
 qui utilise la VM de rik van riel (celle de 2.4.9)

Ou de faire le contraire, soit prendre 2.4.9 et ajouter les patches de
sécurité ou de fonctionnalité nécessaires. Pour l'instant c'est ce que je
fais.

 Maintenir des kernel patches ca prend du temps, et c'est un de ces
 trucs qui pourrait faire l'objet d'une cooperation entre utilisateurs
 avances (qui s'amuse a compiler des noyau patches) et moins avances.

Les distributions le font.




--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se désabonner aussi.



Re: Kernel 2.4 The kernel of pain? slashdot article

2002-01-22 Par sujet Philippe Strauss

On Tue, Jan 22, 2002 at 12:09:44PM +0100, Marc SCHAEFER wrote:
 On Sat, 19 Jan 2002, Philippe Strauss wrote:
 
  N'empeche qu'a chaque noyau c'est une nouvel fin du monde: quel horreur
  il est moins stable que la version stable d'il y a deux ans.
  J'y vois rien d'autre qu'un processus normal, naturel: une version
  stable d'il y a deux ans est plus stable que la version stable
  qui vient d'etre appelee stable. On s'habitue a la stabilite
 
 Non: il ne s'agit pas de cela.  2.4.x, x = 9 était une version tout à
 fait utilisable, sans crashes, sans les problèmes de `oops, no
 memory, killing XXX' de 2.2.x. Dans un certain sens elle était `meilleure'
 que 2.2.x, du moins pour les serveurs.

ok, mais si linus a change la VM dans 2.4.10, meme si il a reconnu
par la suite que ce n'etait pas du tout le bon moment, ce n'est pas
pour agasser tout ces utilisateurs.
C'est parce que le design de la nouvelle est a son gout, meilleur
que la precedentes.
Creer un peu de bronx pour remplacer qqchose par une reecriture
mieux concue, c'est, en terme de creation, toute la force du libre.
au niveau timing je ne dit pas, c'etait pas bon :)

mais vu que je ne gere pas de machine chargee ces temps, j'ai pas
d'experience de serveur instable en 2.4.x avec x  9,
stable en 2.4.9 et pas tres stable en 2.2.19 ou .20
T'as raporte cet experience sur linux-kernel? ca les interesserait
peut-etre.

  Mais rien n'empeche d'appliquer un patch 2.4.18-pre3-ac2 (alan cox)
  qui utilise la VM de rik van riel (celle de 2.4.9)
 
 Ou de faire le contraire, soit prendre 2.4.9 et ajouter les patches de
 sécurité ou de fonctionnalité nécessaires. Pour l'instant c'est ce que je
 fais.
 
  Maintenir des kernel patches ca prend du temps, et c'est un de ces
  trucs qui pourrait faire l'objet d'une cooperation entre utilisateurs
  avances (qui s'amuse a compiler des noyau patches) et moins avances.
 
 Les distributions le font.

oui, mais choisir les options du kernel, c'est toujours qu'un enorme
compromis, pour les cas ou les compromis des distrib ne conviennent
plus, c'est une possiblite. une sous-distribution du kernel au niveau
regional, pour slalomer entre les 'speciales' de compaq et
autres fabriquants de PC pas vraiment PC :)

-- 
Philippe Strauss
http://philou.ch/

L'indifférence est le plus grand risque de notre temps,
la forme civilisée de la cruauté.  -- Zenta Maurina
--
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se désabonner aussi.



Re: Kernel 2.4 The kernel of pain? slashdot article

2002-01-22 Par sujet Dominique Lovy

Salut a tous,

Ca n'a peut etre pas grand-chose a voir avec ce thread,
mais bon : il existe un bug dans la plupart des Athlon/Duron
concernant l'extended paging (4Mb). Ce bug peut affecter
le fonctionnement de l'AGP sous un kernel 2.4 compile pour
Pentium.

Un workaround rapide est de rajouter la ligne
append mem=nopentium
dans lilo.conf

Voir
http://slashdot.org/articles/02/01/21/0750226.shtml
http://www.vnunet.com/News/1128504


Dom

--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se désabonner aussi.



Re: Kernel 2.4 The kernel of pain? slashdot article

2002-01-21 Par sujet Daniel Cordey

On Saturday 19 January 2002 09:10, Marc SCHAEFER wrote:

- mais de toute manière entre temps on peut espérer que le 2.5.x
  sera utilisable ... ce qui ne sera pas vrai avant 1 à 2 ans dans
  les faits :(

J'ai trouvé cette petite annonce chez Transtec.

 Linux, pour la première fois avec USB 2.0 
Linus Torvalds a lancé une nouvelle version 2.5.2 du noyau Linux, qui 
pour la première fois supporte le standard USB 2.0. Ce standard, qui avait 
été adopté en 2000, mais jusqu'à présent adapté avec réticence, atteint des 
taux de transfert maximal de 480 Mbit/s. Même le système d'exploitation 
Windows XP de Microsoft ne devrait le supporter que dans l'une des prochaines 
mises à jour. 

Donc, il y a déjà un 2.5.2... mais dans quel état ?-)

Daniel

--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se désabonner aussi.



Re: Kernel 2.4 The kernel of pain? slashdot article

2002-01-19 Par sujet Philippe Strauss

On Sat, Jan 19, 2002 at 09:10:13AM +0100, Marc SCHAEFER wrote:
 On Fri, 18 Jan 2002, Francois Deppierraz wrote:
 
  On Fri, Jan 18, 2002 at 03:30:14PM +0100, Marc SCHAEFER wrote:
  
   Une moins efficace VM (2.4.9-pristine) vaut mieux que deux VM de m*rde (=
   2.4.10-pristine).
  
  Houla, plus ça va plus je me dis que mon futur kernel s'appellera plutôt
  /bsd...
 
 Résumons:
 
- 2.4.9 semble être une version très fiable, mais pas forcément
  toujours très efficace en interactif. [ j'en ai en production ]
 
- 2.4.10-2.4.15 semblent inutilisables.
 
- 2.4.17 semble utilisable, mais crashe de temps en temps même en
  `workstation load'. [ je n'en ai pas en production ]
 
 En bref, le changement de VM de 2.4.9 à 2.4.10 était une catastrophe.
 Comme déjà dit, c'est clair que s'ils avaient appliqué leurs propres
 règles (pas de changement majeur dans une version stable) cela ne serait
 pas arrivé. On a déjà vécu la même chose en 2.0.x, de 2.0.14 à 2.0.35.
 
 Maintenant, que va-t-il se passer ?
 
- les bugs restant dans la 2.4.17 vont au fur et à mesure être
  corrigés, si bien qu'il sortira un jour une 2.4.42 qui sera
  aussi fiable que 2.4.9 et aussi performante que 2.4.10.
 
- mais de toute manière entre temps on peut espérer que le 2.5.x
  sera utilisable ... ce qui ne sera pas vrai avant 1 à 2 ans dans
  les faits :(
 
 Solution:
la seule que je vois:
 
   - implémenter un système de contrôle de version stable/instable
 à la Debian, *mais avec des cycles de développement assez courts*.
 
 Apparemment, l'engagement d'un nouveau mainteneur (le jeune Brésilien) qui
 semble comprendre les implications des problèmes de qualité logiciel va
 dans la bonne direction.
 
 PS: peut-être que ton futur kernel s'appellera /hurd ? :)

Note qu'a chaque noyau recemment 'stable' c'est la meme histoire.
Bon la effectivement linus a change ca trop tard (ou trop tot).
N'empeche qu'a chaque noyau c'est une nouvel fin du monde: quel horreur
il est moins stable que la version stable d'il y a deux ans.
J'y vois rien d'autre qu'un processus normal, naturel: une version
stable d'il y a deux ans est plus stable que la version stable
qui vient d'etre appelee stable. On s'habitue a la stabilite
de la version qui prend le temps de devenir mur et on a peur
du probleme restant a ajuste dans la derniere toute fraiche.
Oh c'est sain comme reaction, au moins la communaute d'utilisateur
reste critique.

Mais bon, depuis 2.4.0, je n'ai pas reboote ma machine en 2.2, jamais
eu de crash, sur ma station de travail qui c'est vrai n'a pas trop de
charge et 384 MB de ram.
Si j'avais des serveur charges a maintenir, sans doute bien qu'il serait
encore en 2.2.
Mais rien n'empeche d'appliquer un patch 2.4.18-pre3-ac2 (alan cox)
qui utilise la VM de rik van riel (celle de 2.4.9)
Rien n'empeche non plus de s'organiser au niveau local pour gerer des versions
de kernel patchees en fonctions de certaines contraintes applicatives
pour les serveurs charges.
Maintenir des kernel patches ca prend du temps, et c'est un de ces
trucs qui pourrait faire l'objet d'une cooperation entre utilisateurs
avances (qui s'amuse a compiler des noyau patches) et moins avances.

Heureusement que le developpement du noyau est encore un bazaar
bordelique, ca ne serait pas linux autrement.
Les *BSD semble avoir un model de developpement plus stricte,
faudra que j'en installe un une fois pour voir ce que ca donne comme
resultat, mais je me dit que le model un peu bordelique de linux
est gage de plus de creativite.


un interview d'Alan Cox qui parle de la VM et de Marcello Tosatti:
http://kerneltrap.org/article.php?sid=490


aplus


-- 
Philippe Strauss
http://philou.ch/

L'indifférence est le plus grand risque de notre temps,
la forme civilisée de la cruauté.  -- Zenta Maurina
--
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se désabonner aussi.



Re: Kernel 2.4 The kernel of pain? slashdot article

2002-01-19 Par sujet Philippe Strauss

On Fri, Jan 18, 2002 at 09:21:33PM +0100, Francois Deppierraz wrote:
 On Fri, Jan 18, 2002 at 01:54:39PM +0100, Philippe Strauss wrote:
 
  ohh ksymoops is gonna be your friend :))
 
 Jan 17 21:29:45 gollum kernel:  1Unable to handle kernel paging request at virtual 
address 10627759
 Jan 17 21:29:45 gollum kernel: c01367c0
 Jan 17 21:29:45 gollum kernel: *pde = 
 Jan 17 21:29:45 gollum kernel: Oops: 
 Jan 17 21:29:45 gollum kernel: CPU:0
 Jan 17 21:29:45 gollum kernel: EIP:0010:[link_path_walk+1408/1760] Not tainted
 Jan 17 21:29:45 gollum kernel: EFLAGS: 00010202
 Jan 17 21:29:45 gollum kernel: eax: 10627731   ebx: c5264340   ecx: c18143f0   edx: 

 Jan 17 21:29:45 gollum kernel: esi: c63d7f70   edi: c63d7fa4   ebp: cb950479   esp: 
c63d7f54
 Jan 17 21:29:45 gollum kernel: ds: 0018   es: 0018   ss: 0018
 Jan 17 21:29:45 gollum kernel: Process navigator-smoti (pid: 7018, 
stackpage=c63d7000)
 Jan 17 21:29:45 gollum kernel: Stack: d6a9c000  c63d7fa4 0009 0001 
0009 d6a9c021 c5264340 
 Jan 17 21:29:45 gollum kernel:d6a9c01f 0002 00019b4c c013693a c0136cc5 
c63d6000 c63d7fa4 08f9a8c0 
 Jan 17 21:29:45 gollum kernel:bfffe30c c0133f79 c63d6000 087cbc60 c7085b40 
dffeb340 c63d6000 087cbc60 
 Jan 17 21:29:45 gollum kernel: Call Trace: [path_walk+26/32] [__user_walk+53/80] 
[sys_stat64+25/112] [system_call+51/56] 
 Jan 17 21:29:45 gollum kernel: Code: 83 78 28 00 0f 84 87 00 00 00 be 00 e0 ff ff 21 
e6 83 be 54 
 
 Code;   Before first symbol
  _EIP:
 Code;   Before first symbol
0:   83 78 28 00   cmpl   $0x0,0x28(%eax)
 Code;  0004 Before first symbol
4:   0f 84 87 00 00 00 je 91 _EIP+0x91 0090 Before
 first symbol
 Code;  000a Before first symbol
a:   be 00 e0 ff ffmov$0xe000,%esi
 Code;  000e Before first symbol
f:   21 e6 and%esp,%esi
 Code;  0010 Before first symbol
   11:   83 be 54 00 00 00 00  cmpl   $0x0,0x54(%esi)
 
 Je crois que j'ai un peu de peine avec l'assembleur :)

moi non plus, mais c'est pas grave, le Call Trace est deja tres informatif,
meme en fait la premiere ligne 1Unable to handle kernel paging request
at virtual address 10627759
est tres informative: c'est bien la VM qui aurait du etre capable de
trouver une page memoire (c'est son boulot), et le Call Trace
indique dans quel appel systeme cette famine c'est passee.
un stat64, soit l'appel systeme pour avoir le contenu
d'un repertoire ou les metadata d'un fichier (sauf erreur), lui
meme declanche par netscrap.

-- 
Philippe Strauss
http://philou.ch/

L'indifférence est le plus grand risque de notre temps,
la forme civilisée de la cruauté.  -- Zenta Maurina
--
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se désabonner aussi.



Re: Kernel 2.4 The kernel of pain? slashdot article

2002-01-19 Par sujet Philippe Strauss

http://www.uwsg.indiana.edu/hypermail/linux/kernel/0201.2/0395.html

rapide historique de la VM sous 2.4

-- 
Philippe Strauss
http://philou.ch/

L'indifférence est le plus grand risque de notre temps,
la forme civilisée de la cruauté.  -- Zenta Maurina
--
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se désabonner aussi.



Re: Kernel 2.4 The kernel of pain? slashdot article

2002-01-18 Par sujet Philippe Strauss

On Thu, Jan 17, 2002 at 10:04:36PM +0100, Francois Deppierraz wrote:
 On Thu, Jan 17, 2002 at 01:42:41PM +0100, Slava Zimine wrote:
 
  Est-ce qu'il y a des gens ici  qui ont eu des problemes serieux  avec
  2.4.x  sur les serveur sous des stress importants? 
 
 J'ai pas (encore ?) eu de problèmes sur des serveurs mais par contre sur
 ma station de travail j'ai des trucs de ce genre et des freezes de
 temps en temps avec 2.4.17.

ohh ksymoops is gonna be your friend :))

 Unable to handle kernel paging request at virtual address 10627759
  printing eip:
 c01367c0
 *pde = 
 Oops: 
 CPU:0
 EIP:0010:[c01367c0]Not tainted
 EFLAGS: 00010202
 eax: 10627731   ebx: c5264340   ecx: c18143f0   edx: 
 esi: da473f70   edi: da473fa4   ebp: cb950479   esp: da473f54
 ds: 0018   es: 0018   ss: 0018
 Process navigator-smoti (pid: 6736, stackpage=da473000)

ah netscape.
ouai ca peu bien etre un bug de memoire virtuelle :))

 Stack: d2c75000  da473fa4 0009 0001 0009 d2c75021
 c5264340 
d2c7501f 0002 00019b4c c013693a c0136cc5 da472000 da473fa4
 0a75b340 
bfffe30c c0133f79 da472000 087cbc60 c7085b40 dffeb340 da472000
 087cbc60 
 Call Trace: [c013693a] [c0136cc5] [c0133f79] [c0106c4b] 
 
 Code: 83 78 28 00 0f 84 87 00 00 00 be 00 e0 ff ff 21 e6 83 be 54 

-- 
Philippe Strauss
http://philou.ch/

L'indifférence est le plus grand risque de notre temps,
la forme civilisée de la cruauté.  -- Zenta Maurina
--
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se désabonner aussi.



Re: Kernel 2.4 The kernel of pain? slashdot article

2002-01-18 Par sujet Francois Deppierraz

On Fri, Jan 18, 2002 at 01:54:39PM +0100, Philippe Strauss wrote:

 ohh ksymoops is gonna be your friend :))

Jan 17 21:29:45 gollum kernel:  1Unable to handle kernel paging request at virtual 
address 10627759
Jan 17 21:29:45 gollum kernel: c01367c0
Jan 17 21:29:45 gollum kernel: *pde = 
Jan 17 21:29:45 gollum kernel: Oops: 
Jan 17 21:29:45 gollum kernel: CPU:0
Jan 17 21:29:45 gollum kernel: EIP:0010:[link_path_walk+1408/1760] Not tainted
Jan 17 21:29:45 gollum kernel: EFLAGS: 00010202
Jan 17 21:29:45 gollum kernel: eax: 10627731   ebx: c5264340   ecx: c18143f0   edx: 

Jan 17 21:29:45 gollum kernel: esi: c63d7f70   edi: c63d7fa4   ebp: cb950479   esp: 
c63d7f54
Jan 17 21:29:45 gollum kernel: ds: 0018   es: 0018   ss: 0018
Jan 17 21:29:45 gollum kernel: Process navigator-smoti (pid: 7018, stackpage=c63d7000)
Jan 17 21:29:45 gollum kernel: Stack: d6a9c000  c63d7fa4 0009 0001 
0009 d6a9c021 c5264340 
Jan 17 21:29:45 gollum kernel:d6a9c01f 0002 00019b4c c013693a c0136cc5 
c63d6000 c63d7fa4 08f9a8c0 
Jan 17 21:29:45 gollum kernel:bfffe30c c0133f79 c63d6000 087cbc60 c7085b40 
dffeb340 c63d6000 087cbc60 
Jan 17 21:29:45 gollum kernel: Call Trace: [path_walk+26/32] [__user_walk+53/80] 
[sys_stat64+25/112] [system_call+51/56] 
Jan 17 21:29:45 gollum kernel: Code: 83 78 28 00 0f 84 87 00 00 00 be 00 e0 ff ff 21 
e6 83 be 54 

Code;   Before first symbol
 _EIP:
Code;   Before first symbol
   0:   83 78 28 00   cmpl   $0x0,0x28(%eax)
Code;  0004 Before first symbol
   4:   0f 84 87 00 00 00 je 91 _EIP+0x91 0090 Before
first symbol
Code;  000a Before first symbol
   a:   be 00 e0 ff ffmov$0xe000,%esi
Code;  000e Before first symbol
   f:   21 e6 and%esp,%esi
Code;  0010 Before first symbol
  11:   83 be 54 00 00 00 00  cmpl   $0x0,0x54(%esi)

Je crois que j'ai un peu de peine avec l'assembleur :)

-- 
Francois Deppierraz [EMAIL PROTECTED]
Nimag Networks Sàrl - www.nimag.net
PGP Key ID: 9D283BC9
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se désabonner aussi.



Re: Kernel 2.4 The kernel of pain? slashdot article

2002-01-18 Par sujet Francois Deppierraz

On Fri, Jan 18, 2002 at 03:30:14PM +0100, Marc SCHAEFER wrote:

 Une moins efficace VM (2.4.9-pristine) vaut mieux que deux VM de m*rde (=
 2.4.10-pristine).

Houla, plus ça va plus je me dis que mon futur kernel s'appellera plutôt
/bsd...

-- 
Francois Deppierraz [EMAIL PROTECTED]
Nimag Networks Sàrl - www.nimag.net
PGP Key ID: 9D283BC9
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se désabonner aussi.



Re: Kernel 2.4 The kernel of pain? slashdot article

2002-01-18 Par sujet Anne Possoz

Vendredi 17 janvier 2002 François Depierraz a écrit:

 On Fri, Jan 18, 2002 at 03:30:14PM +0100, Marc SCHAEFER wrote:
 
  Une moins efficace VM (2.4.9-pristine) vaut mieux que deux VM de m*rde (=
  2.4.10-pristine).
 
 Houla, plus ça va plus je me dis que mon futur kernel s'appellera plutôt
 /bsd...

L'idée n'est peut-être pas mauvaise, mais je peux témoigner:

 - que mon pc au travail tourne le kernel 2.4.3 sans problème
   depuis le 28 juin 2001 (les arrêts ne sont que des changements
   de hardware)
 - que mon portable à la maison tourne le kernel 2.4.9 depuis le 18
   novembre sans problème non plus

Cela ne veut pas dire qu'il n'y a pas de problèmes, car je ne fais
pas de gros calculs, vit avec 512/256 MB de mémoire ...
Ce ne sont que des kernels redhat non patchés par moi.
(celui que j'ai patché pour un test d'une tablette graphique
a bien fonctionné mais ne m'est plus nécessaire).

Je dois aussi dire que je n'ai pas entendu de drames à l'EPFL,
mais nous n'avons pas pour habitude d'upgrader des serveurs qui
fonctionnent.

Un de nos serveurs (peu stressé) a un uptime de 221 jours (2.4.2)

Anne

--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se désabonner aussi.



Kernel 2.4 The kernel of pain? slashdot article

2002-01-17 Par sujet Slava Zimine

Une article et une discussion sur slashdot

http://slashdot.org/articles/02/01/17/0240242.shtml

http://www.linuxworld.com/site-stories/2002/0114.kernel.html  l'article

Est-ce qu'il y a des gens ici  qui ont eu des problemes serieux  avec
2.4.x  sur les serveur sous des stress importants? 

Je n'ai rien a dire de particulier a propos de ma home machine qui run
2.4.4  standard de suse 7.2  bp de daemons, tomcat, apache, mysql  mais
le load n'est pas important. 

Jamais eu des system freeze. 

Regards,
Slava

--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se désabonner aussi.



Re: Kernel 2.4 The kernel of pain? slashdot article

2002-01-17 Par sujet Marc SCHAEFER

On Thu, 17 Jan 2002, Slava Zimine wrote:

 Est-ce qu'il y a des gens ici  qui ont eu des problemes serieux  avec
 2.4.x  sur les serveur sous des stress importants? 

En 2.4.9 sur une machine parfois assez chargée (indexation de deux ans de
la hiérarchie fr.* par exemple :-) avec un style de travaux plutôt
`batch' (à opposer à une utilisation interactive, ou WWW avec plein de
serveurs/servlets et autres), j'ai remarqué:

   - une tendance à swapper plus que `normale'.

   - une tendance à une interactivité plus que moyenne

par contre, pas de comportement finalement dérangeant: l'augmentation du
swap est relativement modérée et le temps user-space reste bon.

Avec deux processus I/O intensifs en fonction (dans ce cas un benchmark
Bonnie++, pas une indexation), c'est déjà beaucoup moins bien. 

Exemples de graphes en fonctionnement:
   http://www-internal.alphanet.ch/~schaefer/some_files/temp/search/

mais jamais de freeze, crashs ou de OOM (ok, machine avec 640 MB de
mémoire, swap 2 GB). 

Je n'ai pas encore essayé avec la nouvelle VM (dès 2.4.10) car jusqu'en
2.4.15 c'était assez inutilisable AFAIK. J'essaierai 2.4.17 à l'occasion,
mais pour l'instant rien ne m'y pousse.

NB: dans tous les cas lorsque je donne une version de kernel il s'agit
d'une versiond de base sans patches concernant la VM ou le scheduling.


--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se désabonner aussi.