En quoi, est-ce plus compréhensible ? On a la moité des champs qui sont du texte (paths, messages, ...), un grand nombre de champs qui sont des très petits nombre, quelques timestamps.
D’une part, le volume d’informations pour une entrée est tel que ça ne me paraitrait pas très pratique de tout stocker sur une ligne. Je note au passage qu’au moins deux de ces champs peuvent contenir des espaces (MESSAGE et CMDLINE), ce qui introduit la nécessité de trouver un séparateur dont on soit sûr qu’il ne figurera jamais dans le contenu d’un champ (ou de permettre des échappements).
On pourrait certes stocker une entrée sur plusieurs lignes, mais cela rendrait le journal sensiblement plus difficile à exploiter avec les outils Unix classiques qui sont typiquement conçus pour travailler sur des lignes (comment récupérer deux champs différents d’une même entrée à coups de grep|cut|sed|awk|etc. s’ils sont sur deux lignes différentes ? c’est possible, certes, mais certainement pas pratique).
D’autre part, avec systemd-journald la composition d’une entrée de journal n’est pas constante (par exemple, toutes les entrées n’auront pas de champ _SYSTEMD_UNIT, seules celles provenant d’un processus faisant partie d’une unité systemd). Et ce d’autant plus que systemd-journald veut offrir aux programmes la possibilité de créer leurs propres champs en plus des champs définis par défaut (même si je doute personnellement que cette fonctionnalité sera beaucoup utilisée). Encore une fois, gérer ça me paraît malaisé dans un format texte à la syslog (qui est facile à utiliser notamment parce que tous les champs sont à des positions connues d’avance sur une ligne).
Après, je n’ai pas dit que le format binaire était le meilleur choix (franchement, je n’ai pas d’opinion tranchée sur la question) : je dis juste que compte tenu des ambitions de systemd-journald (qui veut un journal plus riche), ça se défend.
C'est ce que j'ai dit [...] non ?
Si. Ce passage s’adressait plus à Zenitram, à qui tu répondais.
[^] # Re: GNU/SystemD/Linux
Posté par gouttegd . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 5.
D’une part, le volume d’informations pour une entrée est tel que ça ne me paraitrait pas très pratique de tout stocker sur une ligne. Je note au passage qu’au moins deux de ces champs peuvent contenir des espaces (MESSAGE et CMDLINE), ce qui introduit la nécessité de trouver un séparateur dont on soit sûr qu’il ne figurera jamais dans le contenu d’un champ (ou de permettre des échappements).
On pourrait certes stocker une entrée sur plusieurs lignes, mais cela rendrait le journal sensiblement plus difficile à exploiter avec les outils Unix classiques qui sont typiquement conçus pour travailler sur des lignes (comment récupérer deux champs différents d’une même entrée à coups de grep|cut|sed|awk|etc. s’ils sont sur deux lignes différentes ? c’est possible, certes, mais certainement pas pratique).
D’autre part, avec systemd-journald la composition d’une entrée de journal n’est pas constante (par exemple, toutes les entrées n’auront pas de champ _SYSTEMD_UNIT, seules celles provenant d’un processus faisant partie d’une unité systemd). Et ce d’autant plus que systemd-journald veut offrir aux programmes la possibilité de créer leurs propres champs en plus des champs définis par défaut (même si je doute personnellement que cette fonctionnalité sera beaucoup utilisée). Encore une fois, gérer ça me paraît malaisé dans un format texte à la syslog (qui est facile à utiliser notamment parce que tous les champs sont à des positions connues d’avance sur une ligne).
Après, je n’ai pas dit que le format binaire était le meilleur choix (franchement, je n’ai pas d’opinion tranchée sur la question) : je dis juste que compte tenu des ambitions de systemd-journald (qui veut un journal plus riche), ça se défend.
Si. Ce passage s’adressait plus à Zenitram, à qui tu répondais.