Sylvain Blandel a écrit 258 commentaires

le truc ou faut avoir un OS fonctionnel pour réécrire le boot à chaque changement de config.

D'après mon expérience, ce n'est pas vrai. Il suffit d'éditer le fichier /boot/grub/grub.cfg et de le sauvegarder. Les modifications seront prises en compte au prochain démarrage. Ce fichier est évidemment accessible même si on démarre depuis un live-CD (je reconnais en revanche que la syntaxe du fichier est peu lisible).

Plusieurs distributions ont une politique regrettable de mise-à-jour de Grub2 : à chaque mise-à-jour, le script grub-mkconfig -o /boot/grub/grub.cfg est exécuté automatiquement, ce qui re-crée le fichier grub.cfg, et efface les modifications apportées par l'utilisateur. En conséquence, Grub2 se traîne une réputation déplorable : « les fichiers de conf sont à refaire à chaque mise-à-jour, c'est nul ! ». En réalité, c'est la politique de la distribution qui provoque ces ré-écritures du fichier grub.cfg.

Ce n'est pas le cas sur la distribution que j'utilise (et que je ne nommerai pas, tu m'accuserais de faire de l'auto-suggestion 😊 ). Lors des mises-à-jour de Grub2, le fichier grub.cfg n'est pas ré-écrit. L'unique moyen de modifier ce fichier de conf est une intervention manuelle et volontaire de l'utilisateur. Ainsi, les modifications que j'ai apportées à ce fichier ne sont pas écrasées lors des mises-à-jour.

LILO :)

Arf ! 😄

tu cites cron. Très bien, mais sur mes machines je n'utilise pas cron, je n'en ai pas l'utilité.

Il me semble que, sous Debian, cron (et son copain anacron) sont installés par défaut, et lancés lorsqu'on démarre dans le runlevel par défaut. Dans le répertoire /etc, pourrais-tu vérifier que les fichiers crontab et anacrontab ne sont pas vides ? De même, pourrais-tu vérifier que les répertoires cron.d, cron.hourly, cron.daily, cron.weekly et cron.monthly ne sont pas vides ?

Les logs de cron et d' anacron devraient être lisibles avec :

bibi@machine:$ grep -i cron /var/log/syslog*

Si je ne me trompe pas sur tous ces points, ça signifie que le fonctionnement d'une Debian nécessite le lancement de tâches selon des contraintes temporelles (que cette Debian soit utilisée comme serveur toujours allumé, ou comme machine de bureau). Ce lancement de tâches selon des contraintes temporelles, nécessaire au bon fonctionnement du système d'exploitation, peut être fait avec cron, ou avec systemd.

Nous parlons d'une surconsommation de RAM (de systemd par rapport à sysvinit) de 30 ou 40 Mo.

Sur la citation que tu as faite, je parlais d'une tendance générale dans l'industrie du logiciel, et pour être précis d'une tendance qui tends à m'exaspérer fortement, pas de systemd en particulier.

J'ai compris ton propos, et je disais juste que la surconsommation de RAM causée par systemd me semble raisonnable, vu le matériel moderne. Si un jour systemd consomme 400 Mo de RAM, je changerais d'opinion. 😄

quand j'utilisais GCC pour compiler autorealm, si je voulais utiliser mon CPU à fond (avec 4 thread donc) ma machine devenais complètement hors de contrôle pendant près de 15 minutes

Ce problème ne peut-il pas être réglé avec nice et son copain ionice ? Les deux sont cumulables, ça donne :

bibi@machine:$ nice -n19 ionice -c3 /usr/bin/processus-très-gourmand

De cette façon, les autres processus ne seront pas gênés pour accéder aux ressources, et ta machine ne sera pas hors de contrôle.

---

Il est possible d'économiser de la RAM grâce à systemd, en utilisant l'activation des services par socket ! Le principe est le suivant : un service est lancé uniquement lorsqu'on fait appel à lui, pas avant. L'opération est transparente pour l'utilisateur.

Une illustration : le service d'impression cups n'est lancé que lorsqu'une tâche d'impression est demandée (c'est un résumé, le lien donne plus d'explications).

Une autre illustration : les différents terminaux virtuels tty2 à tty6 sont lancés uniquement lorsque l'utilisateur appuie sur les touches Ctrl+Alt+F2 (ou Ctrl+Alt+F3, ou Ctrl+Alt+F4 …). Je l'ai vérifié sur ma machine, on peut voir les terminaux virtuels déjà lancés avec :

bibi@machine:$ ps -C agetty

Tant que je n'appuie pas sur Ctrl+Alt+F5, le tty5 n'est pas lancé. Pareil pour les autres.

Avec le traditionnel sysvinit, plusieurs services sont lancés au démarrage. Ces services ne seront peut-être pas utilisés aujourd'hui, mais ils sont lancés, et consomment des ressources, notamment de la RAM. Avec systemd et l'activation des services par socket, les services sont lancés uniquement s'ils sont appelés (par l'utilisateur, par un autre service, par un événement matériel …).

Attention : je doute que tous les services puissent être lancés en utilisant cette méthode, il existe certainement des cas où ce n'est pas possible ou souhaitable. Mais, dans les cas où c'est possible, cela permet d'économiser de la RAM. ;-)

Heu… faut juste que je trouve comment booter directement en runlevel 1 et je te dis ça :)

Si tu utilises grub, il faut rajouter single à la ligne kernel (lien).

Je ne sais pas trop interpréter ces résultats, mais si ton 72Mo viens de la 2nde ligne, alors je suis à 46Mo.

Oui, c'est bien ça. Pour interpréter le résultat de la commande free.

Je viens d'essayer sur une petite machine (un netbook) équipée d'un Go de RAM, et sur laquelle sont installés les deux systèmes d'exploitation :

• Debian Squeeze (32 bits, noyau 2.6.32),
• Archlinux (32 bits, noyau 3.7, systemd 202).

Debian démarrée en runlevel 1 consomme 14 Mo de mémoire vive, Archlinux démarrée en rescue.target consomme 28 Mo (tout ça sur la même machine).

tu es mieux à ce que ton système d'init ne bouffe pas 50 Mo inutilement

Systemd est plus qu'un système d'init : il gère en permanence les processus lancés. Contrairement à sysvinit, systemd est « actif » tout le temps (par exemple, pour remplacer cron et lancer des services selon des contraintes temporelles). Systemd consomme plus de mémoire vive que sysvinit ; c'est normal, il fait plus de choses.

qui consiste à dire qu'on se fiche de l'occupation mémoire des logiciels qu'on écrit parce que le client bah "il a qu'a acheter de la ram".

Nous parlons d'une surconsommation de RAM (de systemd par rapport à sysvinit) de 30 ou 40 Mo. Ce magasin en ligne propose 110 ordinateurs à l'achat. Parmi ces 110 machines, le minimum de mémoire vive est de 1024 Mo (ça ne concerne qu'une seule machine). Pour du matériel moderne, ça ne parait pas exubérant de remplacer sysvinit par un logiciel qui fait plus de choses, et qui ne consomme que 30 ou 40 Mo de plus.

Cette surconsommation de RAM pourra éventuellement poser problème sur certaines machines aux capacités très limitées (comme celle-ci). Dans ces cas-là, il faudra effectivement garder l'ancien sysvinit, ou utiliser un système d'exploitation plus léger, comme NetBSD ou FreeBSD.

De ce que j’ai compris : Debian/kFreeBSD était vaguement fonctionnel en 2004 mais n’était l’œuvre que de quelques développeurs isolés ; depuis 2011 ils profitent de l’infrastructure du projet Debian (machines de build et de test, etc…)

Si c'est bien le cas, ça signifierait que Debian/kFreeBSD est sur une pente ascendante : d'abord un projet confidentiel en 2004, puis une présentation au public en 2011. Et peut-être un support complet et officiel à la sortie de Wheezy ?

On dirait que la surcharge de travail de maintenir 3 kernels différents ne leur fait pas peur en tout cas.

J'ignorais que les contributeurs Debian maintenaient trois noyaux différents ! Effectivement, maintenir plusieurs systèmes d'init devrait leur être possible. 😄

Systemd est un logiciel trop complexe pour qu'on lui confie des tâches critiques

Je n'ai pas dis ça, ou en tout cas n'ai pas voulu le dire. J'ai voulu dire que systemd dépend de trop de logiciels,

En comparant la liste des dépendances de systemd et celles de sysvinit, on constate qu'effectivement systemd a bien plus de dépendances que sysvinit (sous Archlinux).

il semble aussi y avoir du monde pour l'utiliser dans l'embarqué, par exemple, et dans ces situations les ressources sont critiques: ajouter dbus (je garde cet exemple) juste pour pouvoir démarrer le système ne me semble pas trop acceptable.

Je viens de démarrer mon ordinateur sur la cible rescue.target de systemd (c'est l'équivalent du runlevel 1 de Debian : le strict minimum de service est lancé, et un unique terminal virtuel permet d'interagir avec la machine). Combien le système utilise-t-il de mémoire vive ?

bibi@machine:$ free -m

              total       used       free     shared    buffers     cached
Mem:          2005        115       1889          0         19         24
-/+ buffers/cache:         72       1932
Swap:          999          0        999

Le système utilise 72 Mo de mémoire vive après un démarrage en rescue.target. Il faudrait comparer avec la consommation mémoire d'une Debian en runlevel 1.

Concernant le manque de ressources sur les systèmes embarqués : aujourd'hui, même des appareils grand public comme des smartphones sont équipés de plusieurs centaines de Mo de mémoire vive, et de plusieurs Go de mémoire de stockage (un exemple). J'imagine que les appareils embarqués professionnels ont, au minimum, des caractéristiques techniques similaires. Si c'est bien le cas, ils n'auront pas de souci à utiliser systemd, malgré ses nombreuses dépendances.

Je pense que seul le fait de ne maintenir que systemd permets de réduire la charge de travail.

Oui. Tu exprimes ma pensée mieux que moi. 😊

Systemd me semble un outil très intéressant (sérieux, les scripts d'init sont horribles pour un néophyte) pour la facilité qu'il offre aux utilisateurs de contrôler leur système.

Oui, je suis parvenu à écrire un fichier .service pour systemd (lien), alors que je suis incapable de faire un script d'init. Les options de systemd ont des noms très explicites, ce qui facilite leur compréhension.

[Debian] est une distribution qui s'adresse à des gens qui aiment bidouiller eux-même ET qui visent la liberté et le choix. J'inclus la liberté par rapport aux licences, mais aussi par rapport aux tendances générales: les utilisateurs utilisant LILO ou n'ayant pas de DE ne sont pas rares sur la ml internationale.

C'est parfaitement exact : les utilisateurs de Debian aiment le choix, les utilisateurs de Debian sont heureux d'avoir des milliers de logiciels à leur disposition. Et les mainteneurs de Debian, qu'en pensent-ils ? Jusqu'à quel point autoriseront-ils le choix entre plusieurs solutions, sachant que cette multitude de solutions complique leur travail de maintenance ?

kFreeBSD est encore un peu jeune, mais j'ai bien l'impression qu'il attire pas mal de monde.

Oui, ça serait intéressant d'avoir le nombre d'utilisateurs de kFreeBSD. Peut-être est-il possible d'avoir une estimation en regardant les statistiques des serveurs qui distribuent les mises-à-jour ?

si systemd continue de rajouter des palanquées d'options, il sera devenu un bloatware. Pour Debian, se baser sur un bloatware ne sera pas acceptable: la distro qui se veut l'OS universel doit pouvoir marcher sur de vieilles machines.

C'est un argument qu'on entend souvent concernant systemd : « systemd est un logiciel trop complexe pour qu'on lui confie des tâches critiques ». Il se trouve que le noyau Linux est encore plus complexe que systemd. Avez-vous compté les lignes de code qui composent Linux ? Avez-vous compté les options de compilation d'un noyau Linux ? Linux est un logiciel beaucoup plus compliqué que systemd, et pourtant vous l'utilisez tous les jours ; chaque fois que vous allumez votre ordinateur, vous confiez au noyau Linux des tâches absolument critiques dans le fonctionnement du système d'exploitation. Et ça se passe bien. Il est donc tout-à-fait possible de confier des missions critiques à un logiciel extrêmement complexe : vous le faites tous les jours.

Puisque Debian utilise sur un logiciel aussi complexe que le noyau Linux (et que ça se passe bien), ça ne parait pas incohérent que Debian puisse également utiliser un autre logiciel complexe (systemd).

La mise par défaut n'augmentera donc pas la charge de travail.

Sur ce point, effectivement, je me suis mal exprimé. Disons plutôt que, pour une distribution, choisir systemd comme solution par défaut diminue le travail de maintenance de la distribution.

kFreeBSD existait déjà en 2004 : lien

Heu … cette page indique que Debian GNU/kFreeBSD a été publiée avec Debian 6.0 (Squeeze), c'est-à-dire en février 2011. Du coud, je ne sais pas quoi penser : de quand date la naissance de kFreeBRSD ?

Non, c'est la même charge de travail qu'avant systemd puisque plus ou moins chaque distribution importante a un init propre.

Effectivement, je me suis mal exprimé. Disons plutôt que, pour une distribution, passez à systemd (par défaut) diminue le travail de maintenance de la distribution.

il n'y a plus que Gentoo, Ubuntu et Debian qui résistent.

Et Slackware, pour l'instant.

utiliser un outil qui transforme automatiquement les « unité » systemd en script SysVinit quand c'est possible et de faire du travail spécifique uniquement quand c'est nécessaire.

Les fichiers .service de systemd proposent une palanquée d'options, qui sont listées dans les manuels de systemd.exec, de systemd.unit et de systemd.service.

Créer un tel outil (de conversion des fichiers .service en scripts SysVinit) sera un sacré travail. Sans oublier la maintenance de cet outil : systemd évolue vite, de nouvelles options apparaissent fréquemment.

Il faudra également compter sur « le travail spécifique » d'écriture et de maintenance des scripts SysVinit, pour les cas où l'outil de conversion sera inopérant.

Il me semble qu'aujourd'hui, pour les mainteneurs d'une distribution Linux, refuser l'utilisation de systemd par défaut implique une importante augmentation de leur charge de travail.

J'estime que systemd va gagner la partie, c'est-à-dire que, d'ici quelques années, il sera utilisé dans une écrasante majorité des distributions Linux. Pourquoi ? Pas forcément parce que systemd est mieux que l'existant, mais parce qu'il simplifie la vie de ceux qui ont le pouvoir : les mainteneurs des distributions.

Les utilisateurs de distributions auront beau avoir un avis différent des mainteneurs, ils ne sont que … des utilisateurs. Ce sont les mainteneurs qui décident de l'avenir de la distribution. Et systemd leur simplifie considérablement la vie.

Rendez-vous dans quelques années ! 😄

Qu'est-ce que tu appelle les distributions dérivée de Red Hat ? Si tu parle des clones, ça me semble une évidence.

Oui, c'est bien de ça que je parlais.

J'ai préféré faire une supposition, des fois qu'un clone de Red Hat choisisse de ne pas supporter systemd (ça me semble extrêmement improbable, mais sait-on jamais).

Une fois systemd utilisé par défaut sur Red Hat, il nous restera à voir le positionnement des contributeurs de Debian vis-à-vis de systemd :

• Accepteront-ils de maintenir les scripts relatifs au démarrage et à l'arrêt de l'ordinateur, alors que tout ce travail est mutualisé upstream par systemd, ce qui diminue la charge de travail des mainteneurs de distribution ?

• Accepteront-ils de maintenir les scripts (propres à Debian) de lancement des services, alors que systemd se propose de remplacer ces scripts par des fichiers .service (communs entre les distributions utilisant systemd), ce qui, là aussi, diminue la charge de travail des mainteneurs de distribution ?

• Le très jeune projet « Debian GNU/kFreeBSD » (sorti avec Debian Squeeze, en février 2011) justifiera-t-il de rejeter systemd comme solution par défaut ? Ce choix impliquerait, pour les contributeurs Debian, une plus grande quantité de travail : il faudrait en effet maintenir SysVinit/initscripts.

Bref, on verra. 😊

À ma connaissance, à part Arch et Fedora, peu d'autres distribs majeures proposent systemd par défaut ?

Listes des distributions utilisant systemd par défaut.

L'utilisation de systemd par défaut dans la version 7 de Red Hat Enterprise Linux est confirmée sur redhat.com. Il me semble probable que les distributions dérivées de Red Hat suivent le même chemin.

Je n'ai pas encore fini de lire l'article mais je ne peux m'empêcher de commenter.

C'est une attitude malsaine

Ça me semble malsain également. À mes yeux, ça s'apparente (de très loin) aux gens qui coupent la parole : « Je voudrais que vous m'écoutiez attentivement, mais je ne fais pas l'effort de vous écouter attentivement. »

Et parfois je réagis non pas aux détails de l'article lui même , mais aux sentiments et aux impressions que me donnent ledit article à la lecture des points clés

Avec une lecture « rapide », comment être certain d'avoir repéré tous les points clés ?

mon banquier […] vient de me commander une nouvelle carte sans ça.

C'est une chance que ta banque propose encore des cartes bancaires dépourvue de la technologie de paiement sans contact ! Je crains que, bientôt, la totalité des cartes soit équipée de cette technologie (pour les entreprises fabriquant les cartes bancaires, produire un seul type de carte est moins coûteux que d'en produire plusieurs). 😞

je documenterai cette expérience, ça pourra toujours servir.

Effectivement, ça intéressera du monde. 😊

Je n'arrive pas à accéder à un site internet  !
Est-ce ma connexion qui est défaillante, ou bien le site est-il inaccessible ?

Pour le savoir : Down for everyone or just me ?

[Hors sujet]
Une astuce pour éviter l'utilisation d'une carte perdue ou volée.

Pour valider une commande sur beaucoup de sites marchands, il suffit d'avoir les 16 chiffres de la carte bancaire, sa date de péremption et les 3 derniers chiffres au verso. Ainsi, si votre carte est perdue ou volée, elle reste utilisable pour faire des achats.

Une parade : rendre illisibles les 3 derniers chiffres au verso de la carte, par exemple avec un poinçon ou une pointe de couteau. Parfois, ces 3 chiffres sont devinables au recto de la carte, il convient alors de gratter également le recto de la carte.

Bien évidemment, avant de les effacer, vous aurez pris soin de noter ces 3 chiffres ailleurs. Et il faudra quand même faire opposition auprès de votre banque si votre carte est perdue ou volée.
[/Hors sujet]

Tiens, aujourd'hui j'ai ceci en faisant les mises-à-jour :

$ yaourt -Syu
[…]
Remplacer kdesdk-kioslave par extra/kdesdk-kioslaves ? [O/n]
[…]

Là encore, les noms des deux paquets ne diffèrent que par un « S » final. Il y a vraiment de quoi se tromper ! :-)

Ta feuille de style donne un très bon affichage sur les smartphones. Merci et bravo !

Le journal n'est pas très clair. L'auteur ne nomme pas le paquet en question.

Quoiqu'il en soit, j'ai, moi aussi, failli me faire avoir. Plusieurs minutes me furent nécessaires pour remarquer que les paquets portaient des noms différents. :-)

pacman refuse de faire quoi que ce soit s'il a détecté un conflit pendant la mise-à-jour.

Je n'ai pas observé ce comportement chez moi. En cas de conflit, pacman propose de supprimer le paquet déjà installé, et d'installer le nouveau paquet.

Du coup pas d'upgrade, et pas de machine inutilisable pendant plusieurs jours…

Proposition : supprime manuellement le paquet déjà installé, puis ré-essaie de mettre à jour.

est-ce qu'il y a un système de rollback lors de la mise à jour des paquets sous Arch ?

Le comportement (par défaut) du gestionnaire de paquets est de conserver sur le disque dur tous les paquets téléchargés. Ce sont des fichiers .pkg.tar.xz stockés dans le répertoire /var/cache/pacman/pkg/.

Tous les paquets téléchargés sont stockés, y compris les différentes versions d'un même paquet. Par exemple, j'ai actuellement 6 versions du noyau linux :

$ cd /var/cache/pacman/pkg
$ ls linux-3*

linux-3.7.10-1-x86_64.pkg.tar.xz
linux-3.7.5-1-x86_64.pkg.tar.xz
linux-3.7.6-1-x86_64.pkg.tar.xz
linux-3.7.7-1-x86_64.pkg.tar.xz
linux-3.7.9-1-x86_64.pkg.tar.xz
linux-3.7.9-2-x86_64.pkg.tar.xz

Il est ensuite possible de réinstaller ces paquets avec :

$ pacman -U /var/cache/pacman/pkg/paquets-version.pkg.tar.xz

Remarque : évidemment, tous ces paquets s'accumulent, ça finit par prendre de la place. Il faut faire du ménage de temps en temps. 😊

Bonjour.

J'ai également remarqué cette bizarrerie en mettant à jour mon Archlinux hier soir, il me semble toutefois que les 2 paquets avaient des noms légèrement différents.

Malgré le message signalant un conflit, j'ai accepté la mise-à-jour. Voici un extrait du fichier de log de pacman :

$ grep kdesdk-strigi-analyzer /var/log/pacman.log

[2013-03-05 23:00] removed kdesdk-strigi-analyzer (4.10.0-2)
[2013-03-05 23:03] installed kdesdk-strigi-analyzers (4.10.1-1)

Pacman a retiré le paquet kdesdk-strigi-analyzer pour le remplacer par kdesdk-strigi-analyzerS
Notez le « S » final.

Malgré le message signalant un conflit, la mise-à-jour s'est bien déroulée. Je n'ai pas constaté de dysfonctionnement depuis.

la fac où j'irais l'année prochaine (à une heure en voiture de nantes) propose un Master orienté libre ( Master Système Informatique Libre pour les intéressés ;) )

😄

Je ne comprends pas l'ironie de ton commentaire.

Dans les dépendances matériels, il y a toujours la nécessité d'avoir un i7 bi quad core 8Go de Ram ?

Non. Archlinux fraîchement installée n'a même pas d'interface graphique, les prérequis matériels sont donc très faibles. Bien évidemment, si on souhaite utiliser son ordinateur pour des activités « lourdes » (virtualisation, retouche de vidéos, etc.), une machine puissante est nécessaire. C'est valable quelque soit le système d'exploitation choisi.

Le gnome-shell il est livré de base avec tous les plugins […] ?

Ça fait longtemps que je n'ai pas essayé Gnome, mais une caractéristique d'Archlinux est de livrer des logiciels le moins retouchés possible. J'imagine que l'installation de gnome-shell donne une version « minimale » du logiciel. Les utilisateurs ont ensuite la liberté d'ajouter les plugins et extensions qu'ils souhaitent.

Le firefox […] est livré de base avec ses 20 plugins privacy++ ?

Même réponse qu'au-dessus : Archlinux fournit un Firefox « de base », ensuite les utilisateurs rajoutent ce qui leur plaît.

Bref : j'ai bien saisi que le propos est exagéré et ironique, mais les éventuels sous-entendus m'échappent.

quand tu updates tes packages avec Ubuntu/Fedora/Debian, tous les fichiers de conf que t'as modifié sont écrasé

Ce n'est pas le cas avec Archlinux.

Lorsque la mise à jour d'un logiciel apporte une nouvelle version d'un fichier de configuration, il y a deux cas de figure :
– tu n'as jamais modifié l'ancien fichier de conf (celui qui est présent sur ton ordinateur) → le fichier de conf est automatiquement écrasé par la nouvelle version.
– tu avais modifié le fichier de conf → la nouvelle version du fichier est installée avec le suffixe .pacnew et aucun fichier n'est écrasé. C'est à toi de fusionner les deux versions du fichier de conf : l'ancienne que tu as modifiée, et la nouvelle .pacnew

Pour comparer les deux versions du fichier, j'utilise le sympathique outil graphique Meld.

(j'ai contacté les modérateurs pour faire corriger la partie « Lennart qualifie d'obsolètes les composants suivant … »)

Pour la phrase :

sysvinit will most likely remain the default for most installations.

(attention, mon anglais n'est pas terrible) Je la traduirais par « Sysvinit restera certainement le choix par défaut pour la plupart des installations ». J'en déduis qu'il existera quelques installations où sysvinit ne sera pas utilisé par défaut. C'est-à-dire que, pour quelques installations de Debian Jessie, c'est systemd qui sera utilisé par défaut.

J'espère que les ambiguïtés seront levées lorsque cette conférence sera disponible en ligne. Si vous êtes meilleur que moi en anglais 😄 vous pouvez contacter les auteurs de la conférence, Tollef Fog Heen et Michael Biebl. Leurs adresses de courriel figurent en haut à gauche de leurs pages respectives.

Visiblement, l'auteur du journal n'était pas à la conférence de Lennart à FOSDEM. […] il interprète mal les slides de Lennart.

Effectivement, je n'ai pas assisté à la conférence, et mon anglais laisse à désirer. Je contacte les bénévoles de Linuxfr pour corriger l'article.

Désolé pour cette mauvaise interprétation de ma part. 😊