emlwks999

Test de jrnl

2026-07-08T23:05:29+02:00

Test de jrnl

Palaiseau, le mercredi 8 juillet 2026.

Cher Journal,

Comme promis dans mon article du 30 juin 2026 au sujet de carnet 1.10.0, j'ai fini par mettre au propre mes notes de test du programme jrnl. J'ai découvert ce projet au détour du bug Debian « Intent To Package » numéro 1139264. Il s'agit d'un logiciel libre qui facilite la tenue d'un journal de bord. Il est diffusé sous licence Gnu GPL version 3 ou plus. À ce titre, il est très proche de ce que j'ai pu implémenter avec mon carnet. Le programme n'est pour l'instant pas disponible dans Debian sid, l'ITP étant toujours ouverte. Toutefois l'application est disponible en tant que module Python dans le Python Package Index et s'installe très bien avec pipx(1) :

$ pipx install jrnl
  installed package jrnl 4.3, installed using Python 3.14.6
  These apps are now available
    - jrnl
done! ✨ 🌟 ✨

Présentation

Tout comme carnet, jrnl permet de saisir une entrée de journal à la volée depuis la ligne de commande :

$ jrnl
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃  Journal 'default' created at /home/emollier/.local/share/jrnl/journal.txt  ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃  Writing Entry                                     ┃
┃  To finish writing, press Ctrl+d on a blank line.  ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
hello, world

Contrairement à carnet, jrnl ne nécessite pas d'éditeur de texte préalablement configuré ; encore que carnet fait ce qu'il peut pour déterminer des éditeurs par défaut décents et il est toujours possible de configurer ed comme éditeur ligne à ligne, ce qui est utile pour préserver le contexte des résultats de commandes tapées dans le terminal et de leurs sorties. Pour récupérer les entrées du jour :

$ jrnl -on today
┏━━━━━━━━━━━━━━━━━┓
┃  1 entry found  ┃
┗━━━━━━━━━━━━━━━━━┛
2026-06-29 08:17:26 PM hello, world

La saisi de commentaires directement en ligne de commande est également possible, ce que carnet ne sait pas faire aujourd'hui :

$ jrnl bonjour tout le monde.

$ jrnl -on today
┏━━━━━━━━━━━━━━━━━━━┓
┃  2 entries found  ┃
┗━━━━━━━━━━━━━━━━━━━┛
2026-06-29 08:17:26 PM hello, world

2026-06-29 08:23:12 PM bonjour tout le monde.

Les entrées peuvent être anti-datées sans efforts :

$ jrnl last week: what did I do?

$ jrnl last week: Oh, right, now I remember

Pour sortir toutes les entrées, l'option -on admet la valeur « all » :

$ jrnl -on all
┏━━━━━━━━━━━━━━━━━━━┓
┃  4 entries found  ┃
┗━━━━━━━━━━━━━━━━━━━┛
2026-06-22 09:00:00 AM what did I do?

2026-06-22 09:00:00 AM Oh, right, now I remember

2026-06-29 08:17:26 PM hello, world

2026-06-29 08:23:12 PM bonjour tout le monde.

Il y a quelques subtilités sympathiques, comme la première ligne d'une entrée, qui ne se comporte pas comme les autres :

$ jrnl
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃  Writing Entry                                     ┃
┃  To finish writing, press Ctrl+d on a blank line.  ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
Test de jrnl

Je suis en train de tester jrnl.  La première ligne  
qui est spécifiée dans l'entrée est spéciale et sera
mise en surbrillance lors des retours de commandes.
Par ailleurs, c'est la seule ligne affichée lors de 
certaines situations, comme la sélection d'entrées à
effacer d'un journal.

$ jrnl -contains test
┏━━━━━━━━━━━━━━━━━┓
┃  1 entry found  ┃
┗━━━━━━━━━━━━━━━━━┛
2026-06-29 08:32:34 PM Test de jrnl
Je suis en train de tester jrnl.  La première ligne
qui est spécifiée dans l'entrée est spéciale et sera
mise en surbrillance lors des retours de commandes.
Par ailleurs, c'est la seule ligne affichée lors de
certaines situations, comme la sélection d'entrées à
effacer d'un journal.

$ jrnl --delete -on today
┏━━━━━━━━━━━━━━━━━━━┓
┃  3 entries found  ┃
┗━━━━━━━━━━━━━━━━━━━┛
Delete entry '2026-06-29 08:17:26 PM hello, world'? [y/N]
Delete entry '2026-06-29 08:23:12 PM bonjour tout le 
monde.'? [y/N] 
Delete entry '2026-06-29 08:32:34 PM Test de jrnl'? [y/N]
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃  No edits to save, because nothing was changed  ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

À titre de comparaison, la première ligne dans carnet se trouve être une ligne contextuelle. Elle donne potentiellement une information sur quelque chose qui pouvait se passer au moment de la rédaction du feuillet. Toutefois, elle n'est pas prise en compte lors d'une recherche avec l'option --search. Quelque part, c'est une sorte d'anti-titre, ce qui n'est pas forcément évident de prime abord.

Ce qui m'a déplu

J'ai identifié plusieurs choses qui m'irritent un peu avec jrnl. La plus grosse lacune pour moi, c'est qu'il n'y a rien d'implémenté pour faire de la gestion de tâches. Il est donc nécessaire de bricoler de nouveau avec des motifs de recherche. Je ne pense pas que ce soit une si grosse lacune que ça dans jrnl en pratique pour d'autres personnes que moi. C'est juste que, pour ma façon de prendre des notes, j'ai besoin de ce genre de choses. Il est possible de faire des choses avec des motifs de recherche bien choisis :

$ jrnl -contains '[ ]'
┏━━━━━━━━━━━━━━━━━┓
┃  1 entry found  ┃
┗━━━━━━━━━━━━━━━━━┛
2026-06-29 09:14:21 PM [ ] À l'occasion il faudra que je gère mes tâches.

mais ça fait toujours tout un tas de lettres à taper, qui ne sont pas forcément évidentes en fonction de la façon de définir des tâches. Tandis que dans carnet, la détection de tâches est encodée dans l'option -t, ou --todo :

$ carnet -t
[…]
48 feuillets found.

J'ai du mal avec les problèmes d'homogénéités entre l'usage des tirets simples « - » et doubles « -- », variable en fonction des commandes de jrnl, mais pas interchangeables. Plus généralement, j'ai un peu de mal avec le nom des options, mais je pense que c'est parce que j'ai passé trop de temps à utiliser mon carnet.

Si l'idée d'avoir un fichier de configuration est bonne, après tout je n'ai toujours rien implémenté de tel dans mon carnet, j'ai plus de mal avec le format de fichier YAML, que je trouve particulièrement compliqué pour faire des choses à peu près simples. Je trouve notamment un peu trop facile de corrompre un fichier YAML par accident en se mélangeant les pinceaux, par exemple entre les espaces et les tabulations, ou s'il faut ou non mettre un tiret.

Je trouve le temps de réaction de la commande pour faire des choses simples un peu irritant. Elle excède presque toujours les 250ms, ce qui est suffisamment long pour être sensible, même si ça reste très rapide en comparaison de certains programmes prenant plusieurs secondes à réagir. J'ai relevé par exemple beaucoup d'overhead pour afficher la version ou bien l'aide :

$ time jrnl --version
jrnl v4.3

Copyright © 2012-2023 jrnl contributors

This is free software, and you are welcome to redistribute it under certain
conditions; for details, see: https://www.gnu.org/licenses/gpl-3.0.html

real    0m0.285s
user    0m0.244s
sys     0m0.033s

$ time jrnl --help | wc -l
124

real    0m0.226s
user    0m0.170s
sys     0m0.057s

En comparaison, carnet est un ordre de grandeur plus rapide pour ces tâches simples :

$ time carnet --version
carnet 1.10.0
Copyright (C) 2024-2026, Étienne Mollier <emollier@emlwks999.eu>

This program is free software: you can redistribute it and/or modify it
under the terms of the GNU Affero General Public License as published by
the Free Software Foundation, either version 3 of the License, or (at
your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU Affero General Public License for more details.

You should have received a copy of the GNU Affero General Public License
along with this program.  If not, see <https://www.gnu.org/licenses/>.

real    0m0.011s
user    0m0.008s
sys     0m0.003s

$ time carnet --help | wc -l
209

real    0m0.012s
user    0m0.004s
sys     0m0.017s

Un détail amusant, j'ai voulu sortir l'intégralité des entrées de journaux de mon carnet et de mon jrnl de test. Les deux programmes ont pris le même temps. Toutefois, pendant que jrnl a sorti 16 lignes en 197ms :

$ time jrnl -on all | wc -l
┏━━━━━━━━━━━━━━━━━━━┓
┃  5 entries found  ┃
┗━━━━━━━━━━━━━━━━━━━┛
16

real    0m0.197s
user    0m0.173s
sys     0m0.024s

carnet a sorti 74607 lignes dans le même intervalle de temps :

$ time carnet -s | wc -l
74607

real    0m0.197s
user    0m0.255s
sys     0m0.059s

Pour référence, le carnet en question comporte plus de huit mille entrées rédigées dans un intervalle de bientôt deux ans :

$ carnet --activity | tail -n-3
Apparent size: 3470.8kiB  raw: 3616kiB  density: 95.99%
Average apparent size per week: 38.6kiB  raw: 40.2kiB
Number of entries: 8213  of weeks: 90

Les temps passés en mode système et utilisateur sont néanmoins plus longs avec carnet dans les deux cas. Il y eu des fichiers à lire et il n'y a pas de miracles. La raison pour laquelle les temps ne s'additionnent pas dans carnet, c'est que le script shell peut faire usage de la parallèlisation pour les tâches effectuées par des commandes distinctes. Ce n'est pas forcément facilement le cas pour un script écrit en Python.

Du côté de l'ergonomie, je pense que j'ai un problème avec l'encadré qui compte les entrées de journal. Je trouve qu'il détourne trop l'attention du contenu des entrées proprement dites.

J'ai sinon noté quelque fonctionalités que je ne trouve pas utiles, mais peut-être qu'il y a des situations auxquelles je n'ai pas pensé dans lesquelles elles deviennent inestimable. Je pense notamment à la fonctionalité qui permet de chiffrer un journal. Je ne suis pas convaincu que ce genre de fonctionalité soit une bonne idée à implémenter au niveau de l'application, parce qu'implémenter correctement du chiffrement sur disque est compliqué sans fuiter des informations à divers endroits, comme des fichiers temporaires, ou dans de la swap. Selon moi, il est bien plus prudent d'implémenter le chiffrement total du disque avec un outil comme cryptsetup LUKS. Peut-être que c'est utile dans le cadre d'un système de fichier partagé, en plus des disques chiffrés, mais pas à la place des disques chiffrés.

Ce qui m'a plu

jrnl implémente une fonction de filtrage des recherches dans une fenêtre de temps, avec les options -from et -to, ainsi que -until :

$ jrnl -contains r
┏━━━━━━━━━━━━━━━━━━━┓
┃  3 entries found  ┃
┗━━━━━━━━━━━━━━━━━━━┛
2026-06-22 09:00:00 AM Oh, right, now I remember

2026-06-29 08:17:26 PM hello, world

2026-06-29 08:23:12 PM bonjour tout le monde.

$ jrnl -from 2025-01-01 -to 2026-06-28 -contains r
┏━━━━━━━━━━━━━━━━━┓
┃  1 entry found  ┃
┗━━━━━━━━━━━━━━━━━┛
2026-06-22 09:00:00 AM Oh, right, now I remember

Je pense que le manque d'une telle fonctionnalité est une lacune dans carnet et je pense qu'il ne se passera pas longtemps avant que je l'implémente, pour une raison ou pour une autre ; je pense que je peux avoir des gains de temps de recherche en filtrant les recherches à une fenêtre de temps. En revanche, je n'ai pas noté de support pour les expressions rationnelles. Non pas que la fonctionnalité me semble essentielle, mais quand il y en a besoin, elle peut devenir très utile :

 $ jrnl -contains remember
┏━━━━━━━━━━━━━━━━━┓
┃  1 entry found  ┃
┗━━━━━━━━━━━━━━━━━┛
2026-06-22 09:00:00 AM Oh, right, now I remember

$ jrnl -contains r.\*r
┏━━━━━━━━━━━━━━━━━━━━┓
┃  no entries found  ┃
┗━━━━━━━━━━━━━━━━━━━━┛

Par ailleurs, j'ai bien aimé le format de fichier utilisé par jrnl. Il est bien plus simple que celui de carnet. J'avais voulu le format de fichier de carnet relativement lisible par un être humain sans nécessiter d'outils particuliers, mais je pense que ça a rendu l'analyse des feuillets compliquée, notamment pour l'implémentation du moteur de recherche intégré. Pour jrnl, le format est un ensemble de timestamps précédés d'un saut de ligne :

$ cat .local/share/jrnl/journal.txt 
[2026-06-22 09:00:00 AM] what did I do?

[2026-06-22 09:00:00 AM] Oh, right, now I remember

[2026-06-29 08:17:26 PM] hello, world

[2026-06-29 08:23:12 PM] bonjour tout le monde.

[2026-06-29 08:32:34 PM] Test de jrnl
Je suis en train de tester jrnl.  La première ligne
qui est spécifiée dans l'entrée est spéciale et sera
mise en surbrillance lors des retours de commandes.
Par ailleurs, c'est la seule ligne affichée lors de
certaines situations, comme la sélection d'entrées à
effacer d'un journal.

[2026-06-29 09:14:21 PM] [ ] À l'occasion il faudra que je gère mes tâches.

Tout est dans un seul fichier, qui n'est pas édité directement par l'utilisateur de jrnl, contrairement à carnet. jrnl fournit une option --edit pour ouvrir le fichier journal.txt avec un éditeur de texte, mais ce n'est pas la manière normale d'interagir avec le journal. La seule chose qui me chiffonne dans ce format, c'est le marqueur Ante et Post Meridiem, au lieu d'utiliser une horloge de vingt-quatre heures conformément à la RFC 3339 [6]. Ceci dit, les deux formats me semblent suffisamment simples pour permettre des transformations de l'un vers l'autre, en admettant la perte des informations stockées dans les zones indéfinies du format de fichier du carnet, c'est-à-dire partout où il est possible d'insérer du texte qui n'appartient pas à un feuillet, mais qui n'interfère pas avec l'exécution de la commande carnet non plus : la ligne de contexte, l'en-tête de la semaine, mais aussi la possible en-tête de la journée.

Je pense enfin à la capacité à marquer les entrées d'intérêt. Il est possible de marquer ses entrées favorites avec une astérisque « * ». J'avais initialement classé cette option comme étant quelque chose pour lequel je trouvais peu d'intérêt, mais je dois reconnaitre que j'ai deux catégories d'entrées dans mon carnet : des entrées intéressantes d'une part, et de nombreuses entrées de routine d'autre part. Ceci étant, j'aurais tendance à penser que les entrées d'intérêt devraient être davantage reconnaissables de par le fait qu'elles pointent vers des ressources externes, ou bien qu'elles sont la cibles de références depuis d'autres entrées de carnet. C'est pourquoi j'ai eu du mal à me convaincre que cette option est utile. Je pense néanmoins que cette option peut avoir un intérêt pour les très grosses bases de connaissances auxquelles sont adjointes des entrées de journal intersticielles provoquant beaucoup de bruit dans les recherches.

Conclusions

Après avoir testé jrnl, je me suis permis ces quelques critiques. La plupart sont très subjectives et se rapportent à mon ergonomie plus ou moins tordue. De toutes façons, de ce point de vue là, tout le monde est différent. En l'état, sans nécessairement avoir passé en revue tout le code source de jrnl, je ne dissuaderais personne de s'en servir. Au contraire, j'ai même suggéré à un collègue qui a travaillé avec carnet pendant un temps d'utiliser plutôt jrnl, puis de voir ce qui lui convient le mieux. Me concernant, j'ai passé trop de temps avec carnet désormais, et je pense qu'il me sera désormais difficile de m'en passer. Ça me fait également un logiciel à bricoler et je pense que ça me manquerait si j'utilisais les outils préparés par quelqu'un d'autre.

carnet 1.10.0 et le futur

2026-06-30T23:13:48+02:00

carnet 1.10.0 et le futur

Palaiseau, le mardi 30 juin 2026

Cher Journal,

En écrivant au sujet d'un possible projet concurrent à mon carnet, j'ai réalisé que cela fera bientôt un an que je n'ai pas fait la publicité des petites évolutions que j'ai pu apporter dans mon logiciel, au moins depuis la sortie de la version 1.6 en aout dernier. J'eus craint d'être saoulant avec mes histoires de logiciel pour organiser mes idées, mais il semble que je suis en réalité resté assez laconique sur le sujet. Il est probablement temps que je me rattrape.

Changements dans la série 1.6

J'avais déjà parlé des nouveautés de la version 1.6 en août dernier. Cette branche de versions a connu depuis de multiples corrections de problèmes mineurs. On y notera pêle-mêle des changements comme les suivants :

J'ai implémenté une modification du comportement de la peinture des caractères pour les situations où le programme est lancé dans un multiplexeur de terminal.
J'ai aussi désormais une option permettant de déclencher l'alerte sur les heures supplémentaires après un temps spécifié en heures et minutes hh:mm. Le comportement initial où seule l'heure est spécifiée avec un nombre entier est conservé. Cela aurait peut-être justifié une mise à jour du numéro de version mineure, soit dit en passant, comme c'est presque une nouvelle fonctionnalité.
J'ai sinon implémenté une tentative de limiter les risques d'écritures concurrentes dans un même fichier de semaine par plusieurs invocations. C'est utile pour les situations où de multiples personnes peuvent vouloir travailler dans le même carnet. Une autre solution aurait pu être de rédiger chaque feuillet dans un fichier temporaire à part, avant de l'intégrer au fichier de semaine, mais je préfère être en mesure de voir, et peut-être d'ajuster, ce que j'ai pu faire avant mon entrée courante pendant la saisie.

Nouveautés dans carnet 1.7

Cette version ajoute l'option -lm, ou --list-modules, qui permet de lister les modules installés dans le répertoire d'un carnet. Pour rappels, les modules sont des exécutables qui peuvent être invoqués avec l'option -m, ou --module, de carnet, pour faire des choses dans ledit carnet. Ces scripts peuvent par exemple faciliter les recherches avec des motifs spécifiques, ou faciliter l'implémentation de statistiques personnalisées. Pour les publications, comme pour l'instant je ne publie pas le dépôt git, j'ai à la place implémenté un moyen de déployer les archives tarball contenant des métadonnées comme le fichier CHANGES dans un format intermédiaire pour publication. De cette manière, j'ai également retiré le besoin d'invoquer la commande help2man pour produire le manuel : il fait partie de la publication, il n'y a plus qu'à le compresser avec gzip et à le déployer dans $PREFIX/share/man/man1 pour l'installer.

Je réfléchis encore à la manière de publier le dépôt git via mon site web, en sachant que j'ai déjà abandonné l'idée de permettre un git clone, au prétexte que cela nécessite un serveur web spécialisé ou l'activation de modules apache2 compliqués que je n'ai pas l'envie de déployer. Je pense que c'est une situation dans laquelle je paie le coût de vouloir faire des choses trop simples.

Nouveautés dans carnet 1.8

J'ai rajouté un moyen d'afficher et d'éditer un message du jour, avec les options --motd et --edit-motd respectivement. Le Message Of The Day apparait à chaque invocation du carnet. C'est utile pour lui donner une sorte de personnalité, ou des rappels qu'on ne veut oublier sous aucun prétexte, ou juste lui faire une couverture sympathique en art Ascii :

$ carnet  # Dans exemple, l'éditeur `ed` illustre la saisie d'une entrée.
41501
i
Je travaille à illustrer le fonctionnement de la couverture d'un carnet
stylisée en utilisant de l'art ascii.  J'ai à dessein ajusté le motd
pour avoir quelque chose de très visuel, mais d'autres usages sont
possibles, comme par exemple avoir à portée de main les références vers
ses feuillets favoris.
.
w
41825
q
	━┏┓━┏┓━┏┓━┏┓┏━━━━━━━━━━━━━━━━┏┓━┏┓━┏┓━┏┓┌┐
	┃┣┛┃┣┛┃┣┛┃┣┛┃  C A R N E T  ┃┣┛┃┣┛┃┣┛┃┣┛││┌─ ─
	┛┛━┛┛━┛┛━┛┛━━━━━━━━━━━━━━━━━┛┛━┛┛━┛┛━┛┛━┙└┘
feuillet 2026-06-30T22:00 recorded in /home/emollier/doc/carnet/2026-27.txt.

Les dernières versions de la série 1.8 implémentent par ailleurs le support de mpc, le Media Player Client, comme alternative à mocp, le Music On Console Player.

Nouveautés dans carnet 1.9

Le seul changement de la version 1.9.0 est que la fonction de recherche --search se comporte désormais comme une vraie fonction de recherche, telle qu'on peut la trouver dans n'importe quelle application. Au lieu de bricoler avec des expressions rationnelles pour concaténer les motifs à rechercher dans les différents feuillets, le moteur de recherche implémenté en awk traite désormais chaque motif indépendamment pour afficher uniquement les feuillets qui contienne tous les motifs passés en argument, peu importe leur ordre d'apparition dans la ligne de commande. Ce changement s'est avéré essentiel pour améliorer l'ergonomie des recherches dans le carnet de manière substantielle. Elle se fait désormais de manière beaucoup plus intuitive. Les commandes suivantes sont désormais strictement équivalentes :

$ carnet -s mot1 mot2 mot3
$ carnet -s mot3 mot2 mot1

Auparavant, l'ordre des mots était important. À noter, passer ces mots comme un seul argument est toujours considéré comme un seul motif correspondant strictement à la chaine de caractères « mot1 mot2 mot3 ». « mot3 mot2 mot1 » est toujours une recherche différente. Ces deux commandes ne sont toujours pas équivalentes, et elles n'auront pas vocation à le devenir :

$ carnet -s 'mot1 mot2 mot3'
$ carnet -s 'mot3 mot2 mot1'

Nouveautés dans carnet 1.10

Dans la série 1.10, j'ai modifié les options --feuillet et --edit-feuillet. Elles prennent désormais aussi bien des références au format YYYY-MM-DDThh:mm, comme toujours, que des dates pour afficher des journées complètes au format YYYY-MM-DD. Par exemple la commande :

$ carnet -f 2026-06-29

affichera l'ensemble des feuillets que j'ai saisi pendant la journée du 29 juin 2026. J'ai poussé jusqu'à ajuster --feuillet pour accepter les semaines au format YYYY-WW, ce qui est pratique quand la semaine constitue une unité de travail avec une certaine cohérence dans le monde de l'entreprise. La commande suivant ouvrira en édition le fichier correspondant à la semaine 27 de 2026 :

$ carnet -ef 2026-27

Et après ?

Je n'ai pas eu à retoucher à carnet depuis mi-mai et la sortie de la version 1.10.0, ce qui suggère que l'outil est désormais assez stable pour mes cas d'usage.

Je pense que je pourrais étendre la logique de sélection des feuillets à une année entière, mais il faut que je décide de la façon dont je veux me risquer à gérer la transition autour du jour de l'an. Est-ce que je veux tolérer de la marge de quelque jours afin d'afficher ce qu'il se passe pendant la semaine avant le nouvel an, ou après ? Le problème est qu'un jour comme le 31 décembre 2025 se trouve faire partie de la semaine 1 de 2026, donc utiliser un joker sur 2025-*.txt va sortir les dernier jours de l'année du résultat de recherche. Je ne pense pas que ce soit insurmontable, mais ça demandera de réfléchir un petit peu pour implémenter quelque chose d'efficace. Il faut par ailleurs que je garde en tête que je ne peux pas vraiment étendre cette logique à l'édition du texte de l'année entière, à moins que je considère par défaut d'ouvrir l'éditeur au premier de l'an, ce qui simplifierait grandement les choses.

Pour carnet 2, j'aimerais adopter un format de fichier un peu plus rationnel. L'idée serait qu'il puisse me servir à la fois de représentation pour le stockage du carnet, ainsi que de représentation intermédiaire pour faciliter le chaînage des recherches avec tout un tas de différents critères, parfois pas forcément adaptés aux expressions rationnelles, comme filtrer des informations dans période de dates. Je pense avoir vu quelque chose d'intéressant dans le projet concurrent jrnl. J'en reparlerais peut-être plus en détail un peu plus tard.

Serveur web Apache en IPv6

2026-06-14T22:37:26+02:00

Serveur web Apache en IPv6

Palaiseau, le dimanche 14 juin 2026

Cher Journal,

Je pense que je suis arrivé à m'assurer de toujours démarrer le serveur web à la fois sur l'interface IPv4 et l'interface IPv6 sans me retrouver à perdre l'écoute sur IPv6 après un redémarrage. Depuis le 13 mai 2024, j'étais poursuivi par le besoin de redémarrer le service apache2 afin qu'il écoute correctement sur l'IPv6 en plus de la v4. J'ai essayé pas mal de choses, comme de retarder le démarrage du serveur apache2 en jouant sur les dépendances de l'unité systemd apache2.service, sans arriver à grand chose.

Finalement, la solution a été de faire comme n'importe quel internaute aurait fait à ma place : j'ai ouvert un moteur de recherche pour me renseigner sur les spécificités d'apache2 en IPv6. Il se trouve qu'il est recommandé de configurer explicitement le seveur web en IPv4 et v6 avec une directive Listen pour la v4 :

Listen 0.0.0.0:80

et une autre directive Listen pour la v6 :

Listen [::]:80

J'ai donc appliqué ce réglage dans mon fichier /etc/apache2/ports.conf pour m'assurer que les modes http et https soient tous deux pris en compte correctement :

Listen 0.0.0.0:80
Listen [::]:80

<IfModule ssl_module>
	Listen 0.0.0.0:443
	Listen [::]:443
</IfModule>

<IfModule mod_gnutls.c>
	Listen 0.0.0.0:443
	Listen [::]:443
</IfModule>

J'ai également dupliqué toutes les sections VirtualHost dans les sites définis dans mon répertoire sites-enabled/, dont voici un court extrait mettant en valeur le changement :

<VirtualHost 0.0.0.0:443>
[…]
</VirtualHost>

<VirtualHost [::]:443>
[…]
</VirtualHost>

Je ne m'explique pas vraiment pourquoi le problème est désormais corrigé. Je soupçonne un détail dans l'implémentation du serveur web apache2, faute de meilleure explication. Si un jour j'en ai la patience, je regarderais peut-être de plus près. En attendant, je n'ai plus besoin de recharger le serveur web après chaque redémarrage de ma machine et je m'en accomode très bien. :)

Thème sombre en CSS

2026-05-26T23:32:49+02:00

Thème sombre en CSS

Palaiseau, le 26 mai 2026

Cher Journal,

En navigant dans le code CSS de quelque site web, en l'occurrence le CSS du weblog de Greg Kroah-Hartman, j'ai identifié comment appliquer un thème sombre à mon site web pour les navigateurs préférant spécifiquement un tel thème. Le principe est de surcharger attributs définissant les couleurs de la palette en utilisant une classe @media et de vérifier l'état du paramètre prefers-color-scheme dans le cas où il est réglé sur « dark ». Je l'ai injecté dans le CSS du site pour rajouter un thème dans le plus pur style du VT220 « ambre ». Il s'agit du morceau de CSS qui ressemble à :

@media (prefers-color-scheme: dark) {
	body {
		background: black;
		color: orange;
	}
	a {
		color: yellow;
	}
	a:visited {
		color: orange;
	}
}

Dans un environnement où les thèmes sombres sont explicitement préférés, le site devrais désormais ressembler à quelque chose comme :

J'ai hésité contacter Ellane W, qui est à la recherche de la façon d'effectuer cette bascule pour son propre site web, mais comme elle utilise Blot, je ne suis pas convaincu d'être en mesure de déterminer si mes suggestions seront adaptées. Ceci dit, en cherchant dans la base de support utilisateur de Blot, j'ai vu plusieurs occurrences d'autres utilisateurs cherchant à résoudre ce problème, par exemple dans le cadre du ticket de support Blot numéro 1142. J'ai bien l'impression que l'approche pourrait être pertinente.

Lanceur automatique d'agent ssh éphémère

2026-01-08T22:46:54+01:00

Lanceur automatique d'agent ssh éphémère

Palaiseau, le 8 janvier 2026

Cher Journal,

J'ai régulièrement besoin de travailler avec un agent ssh par machine, mais en ayant simultanément de multiples terminaux sur ladite machine, histoire de mieux profiter de l'agent sur toutes mes connexions. Au fur et à mesure du temps qui est passé, j'ai raffiné mon approche afin de m'assurer que je n'accumule pas d'agents oubliés jusqu'au prochain redémarrage de la machine, que j'ai bien accès au même agent depuis de multiples connexions simultanées, ou que je sois en mesure d'arrêter un agent immédiatement après m'être déconnecté d'un système, sans attendre une expiration de la clé privée en mémoire. Le résultat est deux morceaux de code répartis dans les scripts de login et de logout de mon shell, en l'occurrence bash.

Mon fichier ~/.profile contient le segment de code suivant, qui consiste essentiellement à essayer de retrouver dans la table des processus, un ssh-agent que je puisse utiliser pour stocker et récupérer mes clés SSH privées après les y avoir stockées avec ssh-add, la dernière étape du script consistant à vérifier que le ssh-agent est bien installé et à le démarrer s'il n'y en avait aucun en route :

# start up an SSH agent, or try to hook to an existing one if any
SSH_AGENT_PATTERN='(([/]usr)?[/]bin[/])?ssh-agent'
SSH_AGENT_CMDLINE="$( \
	grep -El "$SSH_AGENT_PATTERN" /proc/*/cmdline 2> /dev/null || true
)"
if [ -n "$SSH_AGENT_CMDLINE" ]
then
	SSH_AGENT_PID="$( \
		echo "$SSH_AGENT_CMDLINE" \
		| sed -n 's@/proc/\(.*\)/cmdline@\1@p' \
	)"
	SSH_AUTH_SOCK="$( echo $HOME/.ssh/agent/s.*.agent.* )"
	# Check for old style ssh-agent socket if new style is not found.
	if [ "$SSH_AUTH_SOCK" = "$HOME/.ssh/agent/s.*.agent.*" ]
	then SSH_AUTH_SOCK="$( echo /tmp/ssh-*/agent.* )"
	fi
	if [ -r "$SSH_AUTH_SOCK" ]
	then
		export SSH_AGENT_PID SSH_AUTH_SOCK
		printf 'Existing agent running with PID %s at %s\n' \
			"$SSH_AGENT_PID" \
			"$SSH_AUTH_SOCK"
	else
		printf 'WARNING: ssh-agent running with PID %s, but without\n' \
			"$SSH_AGENT_PID"
		printf '         a usable socket.  Please investigate!\n'
			
	fi
elif command -v ssh-agent > /dev/null
then
	printf 'ssh-agent: '
	eval $(ssh-agent)
fi
unset SSH_AGENT_PATTERN
unset SSH_AGENT_CMDLINE

L'intérêt de mettre ce segment de code dans le fichier ~/.profile est que je peux également m'en servir tel quel pour les situations où j'utilise un Bourne Shell classique, comme le Debian Alquimst Shell « dash ». J'ai par ailleurs un script de nettoyage dans mon fichier ~/.bash_logout qui va compter le nombre de sessions qui me restent sur la machine. S'il ne reste plus de sessions, alors l'agent est arrêté ; il faut noter que le comptage a lieu dans un sous-shell comptant comme une session à part :

# Don't run when ps is not available, this mostly means we are just leaving
# a minimal schroot at the moment.
if ! command -v ps > /dev/null 2>&1
then return
fi

# Check whether there are still some login shells running, and if not, then
# shutdown all agents (and not just the one recorded in the environment).
NRSHELLS="$(
	ps aux \
	| grep '^'"$USER"' .* \([-]bash\|bash  *[-]l\|bash  *[-]-login\)$' \
	| wc -l
)"

printf 'login shells left: %s\n' "$NRSHELLS"

# Remark one needs to accout for the running subshell.  Note also that
# some operating systems may dupplicate the number of occurrences of
# bash, due to leftover `sh -c bash` processes, so the figure needs to
# be set to three under such circumstances.
if [ "$NRSHELLS" -le 2 ]
then
	SSH_AGENT_PATTERN="^$USER"' .* \(\(\/usr\)\?\/bin\/\)\?ssh-agent'
	SSH_AGENT_PIDS="$(
		ps aux \
		| sed -n "/$SSH_AGENT_PATTERN/ s/^$USER"' \+\([^ ]\+\) .*/\1/ p'
	)"
	for PID in $SSH_AGENT_PIDS
	do
		printf 'killing ssh-agent %s\n' "$PID"
		kill "$PID"
	done
	unset SSH_AGENT_PATTERN SSH_AGENT_PIDS PID
fi
unset NRSHELLS

Je ne crois pas qu'il y ait d'équivalent au ~/.bash_logout en Bourne Shell, mais c'est mieux que rien. Le mécanisme exposé est suffisamment robuste pour capturer des service ssh-agent ayant été démarrés par des services systemd ou bien par des environnements de bureau. Il peut être nécessaire de raffiner un peu le SSH_AGENT_PATTERN en fonction des situations, par exemple si ssh-agent est invoqué pour lancer l'environnement graphique lui-même : longtemps la commande générique a été x-session-manager, puis depuis que j'utilise Sway pour bénéficier de Wayland, l'agent ssh se trouve lancer directement sway. Je ne garantis pas de la robustesse de l'ensemble à toutes les situations qui pourraient se présenter dans la nature, mais jusqu'à présent je n'ai jamais eu à m'en plaindre. Ou alors, si j'ai eu à m'en plaindre, je me suis dépêché de faire les ajustements nécessaires pour que ce ne soit plus le cas.

Corrections du 10 janvier : j'ai initialement rédigé cette entrée pour reporter ces segments de code dans un environnement professionnel et noté quelque problèmes qui n'ont pas survécu aux subtiles variations d'environnement avec ce que j'ai implémenté à la maison. D'une part, la socket (chaussette ? Merci Vincent Bernat…) peut apparaitre dans un sous-répertoire du home correspondant au glob ~/.ssh/agent/s.*.agent.* ou bien /tmp/ssh-*/agent.* pour les implémentations plus anciennes ; j'avais initialement oublié le second glob, mais c'est corrigé. D'autre part, j'ai commis une erreur de débutant en inversant les chevrons des scripts au moment de la conversion en HTML préformaté. Une fois ces deux soucis corrigés, j'ai pu utiliser mes agents ssh comme j'en ai l'habitude.

Mises à jour de « carnet »

2025-08-03T20:07:37+02:00

Mises à jour de « carnet »

Palaiseau, le dimanche 3 août 2025

Cher Journal,

Faisant suite à ma publication de carnet à la fin du mois de juin, j'ai continué à produire des mises à jour à intervalles réguliers, pour corriger des bogues et rajouter des fonctionnalités qui se sont avérées utiles pour moi. Dans ma précédente entrée de blog, le carnet était mis à disposition en version 1.1.2. Il est désormais disponible en version 1.6.1. Je suis la nomenclature de version sémantique, c'est-à-dire que le numéro majeur n'est changé que quand j'introduis des changements cassants, par exemple je sortirais carnet en version 2 quand j'aurais décidé de changer le format des entrées pour faciliter certaines tâches. Les numéros de version successives suggèrent donc l'introduction de nombreuses nouveautés.

1.2.y : limite de temps

En version 1.2, j'ai introduit une variable d'environnement CARNET_OVERTIME, permettant de configurer un mécanisme d'alerte quand le temps passé à remplir des entrées de carnet devient excessif par rapport à l'heure de la première entrée. C'est utile pour limiter le temps d'écran dans une journée, dans une certaine mesure, mais comme le suggère le nom de la variable, la fonctionnalité est avant tout prévue pour limiter le risque d'entrer dans un régime d'heures supplémentaires. La détection de temps excessif ne tourne pas par défaut. Elle est activée quand CARNET_OVERTIME contient un entier décrivant le temps standard à passer entre la première et la dernière entrée de carnet sur une journée. Quelqu'un travaillant en trois huit peut ainsi avoir un tel export dans ses fichiers de configuration du shell :

CARNET_OVERTIME=8
export CARNET_OVERTIME

Quelqu'un ayant un temps de travail de sept heures trente quotidienne avec une pause déjeuner d'une heure trente pourrait ajuster la variable à :

CARNET_OVERTIME=9
export CARNET_OVERTIME

Les alertes se matérialisent alors dans le champs libre après l'horaire. Voici un exemple tiré de la page d'accueil révisée de carnet :

________________________________________________________________________
Date : Wednesday (2025-07-09)

09:23 :
Starting the day,

[…]

18:42 : warning: overtime for 19m.
Ouch, I'm running late, it's time to go.

Pour l'instant, le détecteur d'heures supplémentaires ne prend que les heures entières, mais je serais bien inspiré d'inclure le support des minutes en plus des heures afin de permettre un grain plus fin pour ajuster le temps de travail.

1.3.y : feuillets

La série 1.3.y de carnet a introduit la notion de feuillets. Chaque entrée saisie dans le carnet est un feuillet, qui peut être référencé par sa date et son heure dans un format rappelant la RFC 3339, à savoir : AAAA-MM-JJThh:mm. Par exemple, j'ai gardé la référence d'un feuillet enregistré le 5 juillet dernier à 23:34 et je souhaite m'y référer :

$ carnet -f 2025-07-05T23:34
/home/emollier/doc/carnet/2025-27.txt:560
23:34 : sur fond de : Oddland - Skylines
Je viens d'implémenter le système de navigation dans les feuillets.  Le
mécanisme se compose de multiples modifications.  La plus évidente est
l'ajout de l'option --feuillet, que je mentionne déjà dans mon entrée du
2025-07-05T18:23.  J'ai quelque craintes que l'option ne soit confuse au
premier abord, […]

Le mécano est accompagné d'un subtil ajustement de l'affichage des feuillets, qui met visuellement en valeur les références à d'autre feuillets dans le format spécifié ci-dessus. Cela facilite la navigation d'un feuillet à l'autre, ce qui peut amener à des résultats intéressants dans les carnets densément référencés entre feuillets :

$ carnet -f 2025-07-05T18:23
/home/emollier/doc/carnet/2025-27.txt:499
18:23 :
J'ai passé un petit coup de balai.  Pour l'idée de faire un Zettelkasten
en utilisant le carnet (Cf: 2025-07-05T11:25), il me faut deux choses :

  * construire facilement un marqueur pour référencer un ticket par sa
    date et son heure, ce que je peux faire très simplement en ajustant
    le format de sortie de la fonction de recherche ; manifestement je
    pars sur un format YYYY-MM-DDThh:mm, parce que c'est ce qui me
    semble le plus évident ;
  * ajouter une option pour référencer une entrée par son marqueur ;
    j'hésite sur le nom de l'option, peut-être quelque chose comme
    --feuillet ?

On voit ainsi un début de navigation de référence en référence dans une base de connaissances. Le mécanisme vient en complément du moteur de recherche, qui est ajusté pour l'occasion pour indiquer les références des feuillets ressortis lors de la recherche :

$ carnet --search sauvegarde | head -n5
2024-42.txt : vendredi (2024-10-18T18:33) :
Le mécano de surveillance de mes sauvegardes manuelles sur mes disques
externes me signale que je n'ai pas lancé de `backup` depuis plus de
vingt-quatre heures.  Je viens de corriger ça, la sauvegarde devrait
être terminée dans quelque minutes.

$ carnet -f 2024-10-18T18:33
/home/emollier/doc/carnet/2024-42.txt:357
18:33 :
Le mécano de surveillance de mes sauvegardes manuelles sur mes disques
externes me signale que je n'ai pas lancé de `backup` depuis plus de
vingt-quatre heures.  Je viens de corriger ça, la sauvegarde devrait
être terminée dans quelque minutes.

J'ai accompagné cette fonctionnalité d'un fichier de registre nommé register.txt, à placer dans le répertoire contenant le carnet (par défaut ~/Documents/carnet). Il s'agit d'un texte de forme libre, mais dans lequel il est encouragé de noter des références vers des feuillets d'intérêt, qui sont par exemple fortement connectées à des sujets d'intérêt stockés dans le carnet. Le fichier peut être récupéré automatiquement si l'on passe l'option --feuillet sans préciser de référence Mon fichier de registre correspond à peu près à ceci, quoique pour la brièveté les références et les mots clés sont limités à un exemple, et enregistre d'une part des références et d'autre part des mots clés pour le moteur de recherche :

$ carnet --feuillet
Registre des entrées d'intérêt
==============================

Notice
------

        $ carnet -f YYYY-MM-DDThh:mm  # références
        $ carnet -s YYYY-MM-DDThh:mm  # références inverses
        $ carnet -s '<motif>'       # mots clés


Références
----------

2025-07-27T17:02 : jalons pour carnet version 2.


Mots clés
---------

<debian>
        Le système d'exploitation, contient les références à mon
        activité au sein du projet Debian.

Comme toujours, les références seront en surbrillance pour faciliter le copiage et le collage, facilitant du même coup la navigation entre les entrées.

1.4.y : gestion de tâches

J'ai essayé tant bien que mal d'examiner un certain nombre d'outils de gestion de tâche pendant un certain nombre d'années. Fort de l'expérience des systèmes de suivi de ticket professionnel, j'ai cherché pendant longtemps quelque chose d'assez léger pour être utilisable machinalement, mais en même temps suffisamment tolérant pour qu'une simple tâche en apparence puisse se transformer en véritable projet. À ce titre, j'ai essayé cil pendant plusieurs années, alors même que le projet est archivé par son auteur en amont, depuis 2018. Bien que l'outil ait été presque approprié à mon cahier des charges, il y a quelque chose qui n'est jamais passé, quelque chose que je n'ai toujours pas réussi à déterminer, mais qui a à voir avec la fluidité d'utilisation de l'outil. J'ai fini par remarquer que j'avais tendance à laisser des notes dans mes cahiers, sous forme de choses à faire marquées par un TODO en début de ligne ou par un carré blanc, à remplir pour matérialiser une tâche résolue. J'ai pu éventuellement retrouver ce genre de marques dans mon carnet dans des feuillets datant de 2024. J'ai donc fini par implémenter un raccourci pour retrouver les tickets associés à des tâches en cours, via l'option de carnet --todo, dont voici un exemple de sortie avec une tâche que j'ai noté à faire pendant la rédaction de la présente entrée de journal :

$ carnet --todo | tail -n8
2025-31.txt : dimanche (2025-08-03T18:21) : on air: Thought Chamber - Kerakryps
[ ] Il faudrait que CARNET_OVERTIME supporte les heures partielles,
c'est-à-dire que je permette de passer une heure au format « hh:mm »,
au lieu d'un entier décrivant une simple heure « h ».


________________________________________________________________________
34 feuillets found.

Avec l'option de recherche --search, je peux retrouver les références inverses à un feuillet, ce qui fait un suivi de ticket à peu de frais :

$ carnet --search 2025-08-03T18:21
2025-31.txt : dimanche (2025-08-03T18:56) : on air: Jon Anderson and The Band Geeks - Still A Friend
Je réfléchis à 2025-08-03T18:21 pour rajouter le support des minutes.  À
vue de nez, mon code raisonne déjà en minutes, donc il me suffirait
d'isoler les minutes si un caractère deux-points ':' est présent et de
les rajouter au total.


________________________________________________________________________
1 feuillet found.

Quand j'aurais fini avec la tâche enregistrée dans le feuillet 2025-08-03T18:21, je rajouterais une astérisque entre les crochets pour marquer la tâche comme résolue. L'option --todo admet un argument pour spécifier les tâches qui ne sont ni vierges ni résolues, par exemple je peux avoir des tâches dans un état pending, pour indiquer qu'elles sont en attente d'un évènement, par exemple d'une date ou de la résolution d'une autre tâche.

$ carnet --todo pending | head -n5
2025-28.txt : samedi (2025-07-12T22:46) :
[pending] Je suis en train de travailler sur l'implémentation de la
gestion de tâches du carnet, et cette entrée représente un exemple de
tâche en pause.

Comme il est pénible de taper l'expression rationnelle complète permettant de trouver les tâches résolues, notamment par mon usage de l'astérisque pour les marquer comme telles, il y a également une option --done qui sert de raccourci pour ressortir les tâches dans un état résolu :

$ carnet --done
[…]
________________________________________________________________________
2025-28.txt : samedi (2025-07-12T22:49) :
[*] Ce marqueur représente une tâche terminée.

[…]

1.5.y : édition de feuillet ciblé

Sur un grand nombre de feuillets et de semaines, j'ai commencé à avoir des difficultés à aller éditer les tâches ouvertes depuis pas mal de temps pour aller les résoudre. J'ai donc introduit l'option -ef, ou --edit-feuillet, pour immédiatement démarrer l'éditeur de texte à l'emplacement du feuillet sélectionné. Par exemple, une fois que j'aurais résolu le problème de gestion des minutes dans la fonctionnalité de gestion du temps, je lancerais directement l'éditeur au bon endroit à partir de la référence du feuillet avec :

$ carnet -ef 2025-08-03T18:21

Ce complément est essentiel pour la gestion de tâches, afin de les changer d'état, mais également pour la création de connexions entre feuillets. Les feuillets passés ne sont pas statiques, il peuvent être édités dans le futur s'il semble intéressant de les relier à de nouvelles entrées. Par exemple ce feuillet de 2024 fait référence à des entrées de 2025 :

$ carnet -f 2024-10-27T10:24
/home/emollier/doc/carnet/2024-43.txt:418
10:24 :
J'ai un problème de longue date avec Apache httpd […]

J'ai tenté de renforcer les dépendances au 2025-04-10T20:02, mais sans
succès au 2025-04-11T19:54.

1.6.y : modules utilisateurs

J'ai commencé à parler de mon script de gestion de carnet, ou de journal de bord, ou peu importe, à mes collègues au bureau, et il y a eu comme un semblant d'intérêt pour l'outil. Ce qu'il se passe est que je suis pris de cours avec les cas d'usage qu'on a pu me présenter. Du coup, pour compenser, j'ai implémenté un petit mécanisme d'exécution de module personnalisé à stocker dans le répertoire du carnet, et à exécuter avec l'option -m, ou --module. J'ai un petit module de type hello world dans mon carnet, à fins de démonstration :

$ carnet -m hello world
hello, world!
arguments passed were:
  - world
my carnet environment is:
CARNET_EDITOR=vi
CARNET_DIR=/home/emollier/doc/carnet
CARNET_LANG=fr_FR.UTF-8

$ cat doc/carnet/hello 
#! /bin/sh
set -e
printf -- 'hello, world!n'
test -z "$*" || printf -- 'arguments passed were:n'
for arg in "$@"
do printf -- '  - %sn' "$arg"
done
printf -- 'my carnet environment is:n'
env | grep ^CARNET_

Des collègues ont pu ainsi implémenter un système de recherche personnalisé basé sur autre chose que des expressions rationnelles. Me concernant, je compte également me servir de ce système pour évaluer la faisabilité de futures fonctionnalités ou d'efforts de portage.

Conclusions

Ça fait beaucoup d'un coup, je ne sais pas trop s'il vaut mieux que je fasse des mises à jour fréquentes sur le sujet. Je ne vois pour l'instant pas de fonctionnalités supplémentaires à rajouter. Ce qu'il me manque, c'est une référence de feuillet à facilement copier et coller depuis un fichier ouvert avec un éditeur de texte. Un tel changement nécessiterait de modifier le format du fichier d'entrées pour exposer directement la date au format AAAA-MM-DDThh:mm. Une fois que je serais confiant que c'est la bonne approche et que j'aurais mis en place l'outillage pour manipuler le nouveau format de fichier, alors il sera temps de basculer carnet en version 2.

L'autre détail qui me chiffonne avec carnet est qu'il s'agit d'un script shell de plus de huit cent lignes :

$ wc -l carnet
832 carnet

C'est excessif de près d'un ordre de grandeur pour un script Shell. J'ai rationalisé tant bien que mal un découpage des éléments compliqués en fonctions, en gardant à l'esprit de m'assurer que chaque fonction soit autant que possible constituées de primitives indépendantes, gardant en tête l'Art of Unix Programming, où il est question de préserver la finesse de la couche de glu, à la conjonction entre les fonctions de bas niveau et les fonctions de haut niveau ; je présume que ça contribue à préserver la complexité du code source sous contrôle. Et encore, une grosse portion du code, celle qui couvrait l'affichage des statistiques, a été isolée dans son script en Perl :

$ wc -l carnet_activity.pl 
435 carnet_activity.pl

Je ne sais pas trop comment consolider le tout. Chaque fonctionnalité dépend d'outils très précis et un certain nombre de choses se passe moyennement bien quand il y a de légères différences d'implémentation, ce qui suggère que le portage de carnet vers d'autres distributions que Debian pourrait être un problème. J'ai tenté de limiter la casse en faisant en sorte que carnet fonctionne correctement sur NetBSD 10 ; carnet 1.6.1 n'y montre pas de problèmes évidents, exception faite des difficultés à digérer les espaces insécables dans son terminal système wsvt25.

Rafraichissement du Réveil matin

2025-07-26T11:26:22+02:00

Rafraichissement du Réveil matin

Palaiseau, le samedi 26 juillet 2025

Cher Journal,

J'ai récemment apporté des ajustement à mon ancien article Réveil matin avec MOCP. Les ajustements ont été motivés pendant que j'étais en déplacement à la DebConf25 à Brest la semaine dernière, et que j'ai eu besoin de me réveiller tôt à plusieurs reprises pour diverses raisons, mais que j'ai eu des difficultés à configurer correctement le mécanisme sur la machine que j'avais apporté avec moi. La machine en question tournait en Debian 13 trixie, un pré-version du système qui doit sortir le 9 août prochain, et mes premières tentatives de mise en route du réveil n'ont pas fonctionné comme je m'y attendais. Après avoir un peu cherché et expérimenté, j'ai éventuellement pu déterminer qu'il me manquait la définition de la variable d'environnement XDG_RUNTIME_DIR dans le contexte d'exécution de cron(1). J'ai donc rajouté une note à ce sujet dans l'article et j'en ai profité pour effectuer une relecture.

L'article tirait son origine d'une ancienne machine qu'un utilisait mutuellement avec des copains vers la fin de l'École d'Ingénieurs. À ce titre, il a déjà plus de douze ans. Lors de la relecture, j'ai cru bon de devoir en mettre à jour un certain nombre de portions. L'article est resté quasiment inchangé depuis sa rédaction sur dismorphia.info, abstraction faite du segment manquant qui avait été ajouté en 2018, peu après que je mette en place emlwks999 en tant que successeur de mes pages personnelles. J'ai par là même eu l'occasion de constater l'évolution de mon style d'écriture en une décennie : par exemple mon style passé, relativement haché, est devenu apparemment beaucoup plus homogène. Je sens également l'influence de mon expérience à la rédaction de textes à fins de publications, notamment sur les listes de diffusion : mon style est moins directif tout en étant aussi informatif, du moins c'est l'impression que j'en ai en comparant mon texte sur le réveil matin avant et après relecture. Je pense qu'il reste encore pas mal de coquilles à gauche et à droite, mais je me sens mieux avec l'état dans lequel se trouve l'article si je le compare à son ancienne version.

Je suis un peu surpris de constater le temps que j'ai pu passer à utiliser une telle manière de me réveiller. Au départ, ce ne devait être qu'une geekerie passagère, mais le mécanisme a tendance à se faire oublier assez facilement. En tout et pour tout, je ne touche aux réglages qu'une fois par mise à jour majeure de système d'exploitation, si nécessaire, ou quand je suis en déplacement avec une machine non configurée, par exemple la semaine dernière pour la DebConf25, ou occasionellement en cas de transition entre heure d'été et heure d'hiver. J'ai une légère tendance à vouloir lisser la transition entre les deux horaires en effectuant un décalage d'une demi heure en avance de phase, et un recalage à l'heure initiale une semaine après le changement, quand je ne suis pas tout bonnement en train d'ignorer le changement d'heure en décalant le réveil d'une heure pour ne rien changer à mon cycle de sommeil par rapport au réveil. Bref, tout ça pour dire que cette façon de se réveiller n'a rien de particulièrement contraignante.

Publication de « carnet »

2025-06-30T23:49:14+02:00

Publication de « carnet »

Palaiseau, le lundi 30 juin 2025

Cher Journal,

Je n'ai rien publié depuis le mois d'octobre, 2024, mais voyons tout de même si je sais encore comment rédiger des entrées de weblog publiques. Bien que je sois resté silencieux pendant des mois, je ne suis pas resté non plus inactif. Le gros de mon emploi du temps a été dédié à continuer d'apporter des contributions au projet Debian Med, dans la dynamique dans laquelle je me suis lancé depuis la crise Covid. Il a pu y avoir bien sûr des périodes avec plus ou moins d'activité ; j'ai aussi perdu beaucoup de temps précieux à tester, pardon à jouer à, Minetest, renommé depuis Luanti ; avec des greffons bien choisis, ça m'est assez irrésistible.

Mais j'ai aussi passé un peu de temps à un petit projet sans grande envergure, afin de me faciliter la vie pour enregistrer des notes prises sur des sujets pêle-mêle, sans avoir à réfléchir de ce que je vais en faire, où je fais les ranger, et ainsi de suite.

Ce projet est carnet : un logiciel facilitant la prise de note dans une sorte de journal de bord. Pour prendre une note, je tape juste dans mon invite de commande :

$ carnet

et je me retrouve avec mon éditeur de texte préféré à taper directement au bon endroit, dans le bon fichier, avec un marqueur indiquant la bonne heure.

Ce besoin a fait suite à une tentative de mise en place d'un Zettelkasten qui, quoique étant un outil éminemment puissant pour l'organisation des idées par leur mise en réseau, nécessite suffisamment de méthodologie pour rendre la création et l'intégration de notes assez consommatrice de temps libre ; par ailleurs, certains problèmes que je pouvais me poser par rapport à la prise et l'archivage de notes n'avaient pas leur place dans un Zettelkasten, comme par exemple comment se compare le temps que je passe à contribuer à Debian par rapport au temps que je passe sur les jeux vidéos. Une motivation supplémentaire a été que, à titre professionnel, je dois enregistrer mes activités dans un outil de pointage qui a une ergonomie discutable, mais surtout dans lequel j'ai graduellement injecté de plus en plus d'informations, sans être en réelle mesure de pouvoir un jour les en déterrer. À partir de ce qui devait initialement être un petit script enrobant quelque commandes pour lancer un éditeur de texte et permettant de retrouver des notes, j'ai fini par me retrouver avec un petit projet logiciel à part entière.

Le script s'est graduellement étoffé pour intégrer un petit moteur de statistiques montrant divers histogrammes d'activité, accessibles en lançant :

$ carnet -a

Cette fonctionnalité toute secondaire s'est retrouvée à créer une boucle de rétroaction dans laquelle j'ai eu davantage envie de rajouter des notes et d'écrire des choses. La fonction s'est tellement complexifiée qu'il est arrivé un point où je l'ai complètement réécrite en Perl. Pourquoi le Perl a-t-on pu me demander ? J'ai pu trouver plein de raisons plus ou moins bonne, mais je crois que la réponse la plus honnête que je puisse fournir est que j'avais envie de m'amuser, et j'ai trouvé l'écriture en Perl plus amusante que d'autre langages de script similaires. Avec le temps, j'ai même pu commencer à identifier des motifs d'activité, en fonction des vacances, des activités auxiliaires impliquant ou non de passer du temps sur l'outil informatique, et cætera.

Curieusement, la fonctionnalité de recherche d'entrées n'est arrivée que plus tard, quand la taille de mon carnet a commencé à être suffisamment excessive pour rentre les recherches manuelles assez pénibles. Intégrer une fonction au carnet pour les recherches m'a permis de faciliter la récupérations d'entrées correspondant à des motifs d'expressions rationnelles arbitraires :

$ carnet -s '<dar>'
2025-26.txt : mercredi (2025-06-25) : 09:27 :
Je suis en train de me rafraichir les idées dans la documentation de
l'outil d'archivage sur disque dar(1)[1].  Je m'en sers comme une
commande tar un peu plus évoluée pour avoir un accès plus rapide à mes
index de fichiers, mais je pourrais faire plus, comme par exemple baser
ma stratégie de sauvegardes dessus (ce que je ne fais pas pour
l'instant, parce que mes sauvegardes peuvent tout à fait tenir sur un
seul medium de stockage).

[1] : http://dar.linux.free.fr/doc/presentation.html

Je rajouterais très probablement d'autre fonctionnalités au fur et à mesure que le besoin s'en fera sentir ; par exemple, j'ai en tête une option pour alerter sur le risque de saisir des heures supplémentaires, dans un contexte professionel, signalant donc la fin de la journée. Le projet est loin d'être fini, même si le numéro de version, aujourd'hui 1.1.2, suggère un programme sorti de publication bêta.

Initialement, j'avais appelé le projet « journal », mais j'ai eu quelque craintes d'entrer en collision avec des outils réels contemporains ou futurs. Parce que « journal » est beaucoup plus commun que « carnet », j'ai fini par adopter ce dernier nom ; l'adaptation n'a pas été immédiate, car ça faisait déjà quelque semaines que je me servais de mon script. Je ne m'étendrais pas plus dessus. J'ai déjà commenté, avec largesse, à propos de son fonctionnement sur sa page d'accueil, quoiqu'en langue Anglaise.

Fermeture du serveur IRC

2024-10-22T22:38:15+02:00

Fermeture du serveur IRC

Palaiseau, le mardi 22 octobre 2024

Cher Journal,

Cette entrée de journal est pour annoncer que je coupe le service IRC sur emlwks999.eu, car il n'est plus utilisé que par des robots scanneurs à la recherche de vulnérabilités à exploiter. Le pair avec lequel on avait monté une fédération est également éteint depuis un certain temps. C'est donc effectivement la fin de notre mini réseau.

Depuis le lundi 15 juillet 2019, ce serveur IRC est déployé sur emlwks999.eu, alors emlwks999.hd.free.fr. Il avait eté déployé afin d'implémenter une mini fédération IRC pour discuter avec les copains, et j'avais ainsi appris quelque rudiments du fonctionnement en détail d'un réseau IRC, son administration, et la notion d'opérateur, qui en IRC est différente et plus puissante que la notion d'administrateur, sous entendu « de canal ». Bref, j'ai trouvé cela d'un intérêt qui m'avait agréablement surpris. La fédération elle même avait été implémentée le vendredi 19 juillet 2019, c'est à dire à la fin de la même semaine.

Le temps a passé, et un certain nombre de choses ont changé. Comme je l'écrivais dans mon article sur IRC il y a une décennie, déjà, IRC est un protocole qui date de 1988, je n'étais même pas né, et internet avait une population très différente à ce moment là, moins hostile en termes de menaces informatiques mais encore très exclusive à cause des moyens nécessaires pour mettre en œuvre un accès à internet. D'une part, la criminalité informatique a explosé dans les années 90 et 2000, pour atteindre une échelle industrielle décrite par Edward Snowden en 2013. Cet évènement a provoqué un essor du développement de plateforme de discussions et d'échange de messages chiffrés, dont je pense aujourd'hui que l'exemple le plus emblématique est l'écosystème d'outil de discussions basés sur matrix.org. Ces outils sont devenus matures à la fin des années 2010, avec les dernières fonctionalités ajoutées à marche forcée en 2020 au plus fort de la crise Covid. Le protocole IRC, bien qu'il ait pu évoluer avec assez de modifications pour au moins chiffrer les données en transit, n'a jamais été adapté pour du chiffrement de messages de bout en bout, mettant les serveurs IRC dans une position de concentration des échanges d'information.

Malgré tout, le protocole IRC est toujours utilisé aujourd'hui, et on a vu il y a seulement trois ans la création du réseau IRC Libera Chat sur les cendres de FreeNode suite à un échec critique de gouvernance. Je suis moi-même présent sur le réseau OFTC (lui même fondé en 2001) afin de discuter sur quelques uns des canaux Debian qui y sont hébergés. Je n'y suis que rarement de près ce qu'il s'y passe, quoique je peux être un peu plus actif en cas de conférence ; dans ces circonstances, IRC reste un outil puissant et léger pour se coordonner. Mais IRC reste inadapté pour échanger des messages confidentiels.

Une autre chose a changé et que j'ai du mal à m'expliquer, mais j'en touchais deux mots à un collègue pas plus tard que cet après midi : j'ai du mal à suivre une conversation au format clavardage. Le courriel me pose beaucoup moins de problèmes curieusement : les messages arrivent à un seul endroit que j'ai à surveiller, ils ne se mélangent que de la manière dont je demande à mon client mail des les trier, et je peux ranger chaque message comme je souhaite une fois que j'en ai pris connaissance et ai éventuellement répondu. Le clavardage fournit une granularité au niveau d'une discussion, ce qui résulte tout de suite en de multiples canaux distinct. Peut-être que je n'ai simplement pas trouvé de client de clavardage adapté à ma façon de traiter les messages ?

Site web rétabli en IPv6

2024-05-13T21:17:39+02:00

Site web rétabli en IPv6

Palaiseau, le lundi 13 mai 2024

Cher Journal,

En procédant à ma vérification mensuelle des certificats TLS pour les domaines emlwks999.hd.free.fr et emlwks999.eu, j'ai dû procéder à un renouvellement manuel du domaine fourni par Free. Seulement, mes tentatives ont fini en échec répétés pour cause de connexions refusées par mon serveur web, d'après le message d'erreur renvoyé par le certbot. En grattant dans le fichier de journal indiqué dans le message d'erreur, j'ai noté que le cerbot côté Let's Encrypt rebondit sur de multiple domaines pour résoudre emlwks999.hd.free.fr, avant de finalement tenter une connexion via l'adresse IP en version 6. Pour une raison qui m'échappe, mon serveur Apache a cessé d'écouter les requêtes sur les ports IPv6 : toutes mes tentatives de connexion avec n'importe quel client web (Firefox, GET, etc) se sont soldées par des connexions refusées.

Visiblement, j'ai dû avoir cassé quelque chose à un moment dans la configuration des écoutes sélectives par ports. J'ai essayé de voir si je n'ai pas manqué quelque chose dans mon fichier /etc/apache2/ports.conf, mais il n'y a rien de particulier à y signaler :

# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default.conf

Listen 80

<IfModule ssl_module>
	Listen 443
</IfModule>

<IfModule mod_gnutls.c>
	Listen 443
</IfModule>

Après quelque tentatives de raccorder le service explicitement sur les interfaces IPv6, et essuyer des erreurs de port déjà en cours d'utilisation, j'ai fini par rétablir le fichier de configuraton dans son état que je pensais initial, et redémarré le service :

$ sudo systemctl restart apache2

Les interfaces IPv6 étaient alors de nouveau disponibles. J'ignore pourquoi ou comment le service des addresses IP modernes a cessé, pendant que le schéma historique a continué à fonctionner. Ma conjecture est que ma machine pourrait avoir démarré le serveur web avant que l'interface ne soit disponible en IPv6. J'ai ajouté une configuration SLAAC explicite dans mon fichier d'interface pour m'assurer de bien avoir une configuration IPv6 pour considérer l'interface comme disponible, au format interfaces(5), en vue d'hypothétiquement faciliter les prochains redémarrages :

iface enp1s0 inet6 auto

Après arrêt et redémarrage de l'interface, la déclaration statique en IPv4 est revenue tout de suite, mais la déclaration automatique en SLAAC a pris de l'ordre d'une dizaine de secondes pour revenir, après que l'activation des interfaces réseau ait rendu la main. J'ignore depuis combien de temps le problème est présent, mais si c'est deux jours, alors ça coïnciderait avec le dernier redémarrage de la machine, ce qui validerait la conjecture.

Il y a probablement plusieurs morales à cette histoire. La première est de surveiller activement l'expiration de ses certificats TLS Let's Encrypt, au cas où quelque chose ne se passe pas comme prévu. La deuxième est que bien que techniquement supérieure, l'implémentation d'IPv6 reste manifestement très marginale, et donc il peut s'écouler du temps avant de se rendre compte d'un problème n'affectant que le circuit IPv6. La troisième est qu'il reste probablement quelque points à améliorer pour que le suivi des cibles réseau ne soit pas surprenant, notamment au vu des interfaces qui démarrent à différentes vitesses, et qui peuvent potentiellement affecter le démarrage des services qui dépendent du réseau si ce dernier n'est activé que partiellement.

Disque en panne et intégrité des sauvegardes

2023-07-22T15:43:37+02:00

Disque en panne et intégrité des sauvegardes

Palaiseau, le samedi 22 juillet 2023

Cher Journal,

C'est après presque quatorze ans de bons et loyaux services que mon premier disque dur externe a rendu son dernier octet. Il s'agissait d'un Verbatim M7519 de 640 Go acheté fin 2009, disque rotatif de 3”½ avec une carte d'alimentation dédiée de 24 W, contrastant avec l'usage contemporain qui veut que les volumes de stockage externes soient maintenant directement alimentés par leur port USB. Le bouton d'allumage et arrêt avait quelque ratés sur la fin : j'ai dernièrement eu du mal à éteindre le disque après avoir effectué dessus des sauvegardes mensuelles. C'est en voulant effectuer un test de restauration des dites sauvegardes que je me suis rendu compte de la panne.

Je présume que le bouton d'allumage a finalement lâché. Si j'ai du temps pour bricoler, peut-être que je pourrais découpler le disque de son boitier pour m'en resservir dans une machine, par exemple. Je n'utilisais plus ce disque que pour des sauvegardes mensuelles en cas de gros pépins avec mes volumes de stockage plus récents. Comme le disque était déjà ancien, mon idée était de ne plus avoir à compter dessus que en cas de situation invraisemblable qui impliquerait la destruction de mes autres archives régulières et irrégulières. J'avais pu donc m'en servir pour quelque expériences risquées, comme tester le support du bit bigtime, introduit dans le système de fichier XFS afin de permettre le support des partitions existantes au delà de l'an 2038.

L'incident souligne l'importance de vérifier régulièrement l'état de ses sauvegardes et archives.

Sortie de Debian 12 bookworm

2023-06-11T14:32:27+02:00

Sortie de Debian 12 bookworm

Palaiseau, le dimanche 11 juin 2023

Cher Journal,

Debian 12 bookworm est sortie hier soir.

L'annonce officielle a été envoyée par courriel le samedi 10 juin à 19:56:04… heure de New York, donc suffisamment tard hier soir pour ce que ce soit ce matin à Palaiseau. L'annonce de la publication est disponible sur le site web du projet Debian. Je ne détaille pas les changements car c'est déjà fait dans les notes de publications, et je ne veux pas gâcher les surprises. Pour les éléments qui m'intéressent, le noyau natif est Linux 6.1, et le compilateur système est Gcc 12. Merci à l'équipe de publication, qui a eu un samedi assez chargé !

Détail amusant : la date correspond jour pour jour à la validation de ma candidature en tant que Développeur Debian, le 10 juin 2021, comme un fait exprès. À noter que j'ai été officiellement DD à partir du 23 juin 2021, comme rapporté par le site des nouveaux mainteneurs.

Ça fait un bon bout de temps que je n'ai plus envoyé de paquets dans l'archive, mais de ce que je vois de mes manipulations de ce matin, j'ai encore une vague idée de comment m'y prendre. :)

Garder les journaux systèmes sous contrôle dans Debian 11

2022-07-23T19:34:59+02:00

Garder les journaux systèmes sous contrôle dans Debian 11

Palaiseau, le 23 juillet 2022

Cher Journal

Je note ici dès fois que ça serve à quelqu'un : depuis Debian 11, les journaux systèmes sont configurés pour grossir indéfiniment. Bien que l'intention de départ ne soit honorable, à savoir conserver des informations de dépannage et autres sortes d'enquêtes aussi longtemps que possible, l'espace disque n'est pas extensible à l'infini (n'en déplaise aux professionnels de l'infonuagique).

Une investigation avec du, ou bien ncdu qui est davantage adapté à la recherche de fichiers goinfres dans une arborescence, devrait montrer que beaucoup d'espace est consommé par /var/log/journal, en comparaison avec le reste des journaux systèmes :

$ sudo du -sh /var/log/* | sort -hr | head -n3
1.1G	/var/log/journal
17M	/var/log/apt-cacher-ng
16M	/var/log/installer

Je fais du ménage relativement régulièrement, donc la consommation ne file pas, mais 1,1 Gio de consommé, c'est déjà particulièrement excessif pour du journal système. En comparaison, les fichiers de journaux historiques n'excèdent que rarement les quelque dizaines de mébioctets de taille ; bien entendu ces valeurs dépendent aussi beaucoup de l'usage de la machine :

$ sudo du -sh syslog* kern.log* auth.log*
2.8M	syslog
3.5M	syslog.1
620K	syslog.2.gz
664K	syslog.3.gz
592K	syslog.4.gz
36K	syslog.6.gz
24K	syslog.7.gz
168K	kern.log
48K	kern.log.1
8.0K	kern.log.2.gz
28K	kern.log.3.gz
24K	kern.log.4.gz
1.9M	auth.log
2.8M	auth.log.1
232K	auth.log.2.gz
188K	auth.log.3.gz
188K	auth.log.4.gz

Le répertoire /var/log/journal contient l'intégralité des journaux systèmes dans un format de base de donnée binaire. Ce format n'est pas sans intérêt puisqu'il permet de retrouver facilement des informations diverses en fonction de nombreux paramètres, l'exemple typique étant de lister les évènements qui se sont produit sur une plage de temps quelque part dans le passé. On se référera avantageusement au manuel de journalctl(1) à ce sujet.

Historiquement, les journaux sont gardés sous contrôle au moyen d'outils comme logrotate(8). Les archives des journaux sous /var/log/journal sont gérées différemment, de part leur nature de base de données, qui se prête moins bien à rsyslog, mais mieux à d'autre formes de manipulations. La commande journalctl comprend un ensemble de commandes pour effacer les archives les plus anciennes, en fonction de la stratégie que tout un chacun voudrait appliquer. Il y a des stratégies pour conserver au moins un certain intervalle de temps, ou bien une certaine quantité de journaux, tout dépend des besoins de conservation des journaux. Typiquement, sur une machine sur laquelle je ne m'inquiète pas plus que ça des enregistrements de journaux, un bon ménage peut être fait avec :

$ sudo journalctl --vacuum-size=10M
[…]

$ sudo du -sh /var/log/* | sort -hr | head -n3
33M	/var/log/journal
17M	/var/log/apt-cacher-ng
16M	/var/log/installer

Comme on peut le voir, la taille est légèrement supérieure après ménage. C'est parce que le répertoire contient différent types de bases de données. Il y a les journaux en cours d'écriture, et les journaux archivés. La partie des journaux archivés est la seule éligible à être nettoyée à coups d'aspirateur à données (vacuum), le reste étant en cours d'utilisation. Ça vaudrait probablement le coup de faire un ménage régulier pour éviter les incidents du type « disque plein ». Je me demande s'il y a une option de configuration pour désactiver la conservation ad vitam des journaux ? Autrement, passer un coup de d'aspirateur une fois tous les mois peut tout à fait se faire dans /etc/cron.monthly/.

Ça fait un bon bout de temps que je n'ai plus écrit grand chose dans ce journal. Quelque part, comme l'écrivait Soljénitsyne, c'est bon signe, ça veut dire que le reste avance. Ceci étant, la faute reposait probablement en bonne partie sur un clavier trop usé ; j'ai fini par en changer après avoir étudié de près les mécanismes disponibles sur le marché, de bonne réputation, et confortables à utiliser. Ce sera peut-être un sujet pour plus tard.

Retombées de l'éruption M4 du 28 mars

2022-03-31T23:03:18+02:00

Retombées de l'éruption M4 du 28 mars

Palaiseau, le jeudi 31 mars 2022

Cher Journal,

L'éruption M4 de lundi dernier s'est manifestée ce matin en provoquant une tempête géomagnétique mineure, avec un indice K_p de 5. Il y a éventuellement eu quelque faibles fluctuation dans le réseau électrique, et quelques oiseaux migrateurs ont pu être déviés de leur trajectoire. La NOAA fournit un graphe combiné de l'évolution de l'intensité des éruptions, du flux de protons et de l'activité géomagnétique, ainsi qu'une échelle qui permet d'interpréter l'amplitude des trois phénomènes en fonction de leur impact sur les activités humaines. Ça m'a grandement facilité la lecture des graphiques, et en plus maintenant je comprend mieux les annonces du SIDC qui, pour des raisons évidentes, expose essentiellement des grandeurs physiques : K_p, flux de protons, classification des éruptions, intensité du champ magnétique…

Par ailleurs, flaremail a rapporté une nouvelle éruption pendant que je rédigeais cette entrée, il devrait donc y avoir encore quelques choses à dire dans les jours à venir :

A class M9.6 solar X-ray flare occurred on 2022/03/31 with peak time 18:35UT

Si je commence à rédiger une entrée par jour en me substituant au SIDC, je risque de ne plus mettre grand chose d'autre dans le journal dans les mois qui viennent. Comme dirait Arka'an, dont c'est le métier :

avec un max du pic prévu pour 2025, y a des chances …

Éruption de classe X1.3

2022-03-30T22:01:14+02:00

Éruption de classe X1.3

Palaiseau, le mercredi 30 mars 2022

Cher Journal,

Décidément, il y a de l'activité solaire dernièrement. Un EMC classée X1.3 s'est produite vers 19:37. La magnitude est supérieure à l'éruption de classe M4 enregistrée lundi. Je serais curieux de voir l'image résultante, mais la vidéo SWAP couvrant cet horaire n'est pas encore disponible à l'heure où j'écris ces lignes.

Le pic causé par l'éruption M4 d'avant hier est encore visible, mais l'éruption X1.3 a collé bonne baffe dans la courbe d'émission de rayons X du jour. L'outil d'alerte flaremail rapporte :

A class X1.3 solar X-ray flare occurred on 2022/03/30 with peak time 17:37UT

À suivre… Comme c'est excitant !

Première suite à l'EMC du 28 mars 2022

2022-03-29T22:46:54+02:00

Première suite à l'EMC du 28 mars 2022

Palaiseau, le mardi 29 mars 2022

Cher Journal,

Cette entrée se voulait initialement un simple relai des nouvelles du SIDC. Pour faire court, la vitesse des matériaux de l'éruption d'hier est estimée par les astronomes à la baisse, à environs 735 km/s, et devraient arriver le 31 mars aux aurores. Une éjection de masse coronale supplémentaire a été enregistrée un peu plus tard hier et semble se propager à une vitesse d'environs 784 km/s, ce qui la ferait arriver le 31 mars en soirée. Dans les deux cas, les éruptions solaires proviennent de la tâche NOAA 2975.

Pour ce qui est de l'état d'alerte des systèmes les plus exposés aux vents solaires, je ne sais pas pour sûr, mais j'ai cru comprendre que les appareils en production en ont vu d'autres au cours des dernières décennies. Par ailleurs, l'éruption n'a pas explosé les échelles des indices servant à quantifier la force des éruptions solaires, donc je présume qu'on est encore assez loin d'un éventuel nouvel évènement de Carrington. Ceci étant, il est vrai qu'au début du mois dernier, une tempête géomagnétique a provoqué la perte d'une quarantaine de satellites Starlink qui étaient en cours de mise en orbite.

Pour ce qui est des atténuations radio mentionnées hier, elles ne sont nullement causées par du rayonnement X mais bien évidemment par des ondes radio ; les fréquences entre ces deux classes d'ondes électromagnétiques ne sont pas tout à fait les mêmes. Mon clavier a dû fourcher…

Les prochaines nouvelles à ce sujet devraient être pour le 31 mars. Qui sait, peut-être que des amateurs enregistreront des images d'aurores polaires ? Il est aussi très possible que j'oublie tout bonnement le sujet d'ici là.

Sur un autre sujet, toujours en lien avec le soleil, Guru Meditation rapporte que l'analyse des 24 dernières années de données relatives au soleil suggère la présent de vortex rétrogrades dont la vitesse n'est pas facilement expliquée par la physique solaire telle qu'on la conçoit pour le moment.

EMC du 28 mars 2022

2022-03-28T23:28:26+02:00

EMC du 28 mars 2022

Palaiseau, le lundi 28 mars 2022

Cher Journal,

Ça fait quelque mois que je n'ai plus rien écrit de sérieux ici, la faute à l'hibernation cet hivers, sans doute. Voyons si je sais encore taper du texte en html sans me mélanger les pinceaux.

Depuis l'EMC de novembre dernier, documentée entre autres locations chez Stéphane Bortzmeyer, je jette régulièrement un petit coup d'œil au site du SIDC pour voir comment évolue le soleil au jour le jour, par curiosité. Je n'ai pas fait les études d'astrophysique adéquates pour bien comprendre, et encore moins correctement interpréter, toutes les grandeurs qui sont publiées au jour le jour sur leur site, mais j'essaie de me documenter.

Peu après le déjeuner, j'ai jeté un œil sur les derniers enregistrements vidéo du SWAP, qui montrait très clairement une éjection de masse coronale en direction de la terre aujourd'hui à 11:29 temps universel. La vidéo devrait être mise à disposition dans les archives du de mars 2022 à la fin du mois. À l'instant t l'outil d'alertes presto affiche :

The proton flux of >10MeV exceeded the 10pfu threshold on 13:25UT. This is
a result of the M4.0 class flare for region NOAA 2975, peak time March 28th
11:29UT, in combination with the radio bursts of type II (11:23UT) and type
IV (11:37UT) that followed. The event is ongoing.

Un message antérieur indiquait que la vitesse d'éjection des matériaux solaires était d'un peu plus de 1200 km/s, mais je n'arrive pas à le retrouver ; cela représente 300 km/s de plus que l'éruption du mois de novembre dernier. S'il n'y a pas de ralentissement du vent solaire, comme l'éruption a eu lieu dans l'axe en direction de la terre, j'imagine que l'accroissement du vent solaire devrait nous atteindre demain dans la soirée. Évidemment, si le flux ralentit d'ici là, j'ai toutes les chances de me tromper.

Ailleurs sur le web, en cherchant des éléments via Wikipedia au sujet de la météo spatiale, j'ai fini par tomber sur un site vraisemblablement basé en Espagne, qui rassemble l'ensemble des graphiques liés à la météo solaire sur un seul panneau de contrôle, et de ce que j'en comprends, les éruptions sont classées par quantité d'émission de rayons X, et peuvent être de type A, B, C, M ou X. L'éruption d'aujourd'hui a été catégorisée M4. Sur un autre site, spaceweather.com, j'ai pu lire que le rayonnement X a causé des interférences très nettes aux opérateurs radios, un peu partout en Afrique, dans la partie du sud de l'atlantique, et probablement en Espagne aussi.

Je pense essayer de suivre ça de prêt demain, du moins si mon emploi du temps me le permet. En tout cas, de ce que je vois sur un forum dédié à l'observation et aux prévisions de la météo spatiales, les passionnés sont excités comme des puces. Je ne sais pas dans quel état d'alerte sont les opérateurs des différents réseaux, électrique et Internet, par contre.

Hibernation

2022-02-24T12:04:06+01:00

Hibernation

Zzzz…quoi ?