Re: Du point de vue utilisateur ou mainteneur ?

J'ai toujours trouvé étrange l'histoire des logs « binaires » vs les logs « non binaires ».

Bien, alors.
Je vais faire une citation à un site souvent utilisé en tant que référence, notamment quand ça concerne les trucs de base comme c'est ici le cas:

Binary file:

A binary file is a computer file that is not a text file; it may contain any type of data, encoded in binary form for computer storage and processing purposes. Many binary file formats contain parts that can be interpreted as text; for example, some computer document files containing formatted text, such as older Microsoft Word document files, contain the text of the document but also contain formatting information in binary form. When downloading, a completely functional program without any installer is also often called a program binary, or binaries (as opposed to the source code).

Text file:

A text file (sometimes spelled "textfile": an old alternative name is "flatfile") is a kind of computer file that is structured as a sequence of lines of electronic text. A text file exists within a computer file system. The end of a text file is often denoted by placing one or more special characters, known as an end-of-file marker, after the last line in a text file.

"Text file" refers to a type of container, while plain text refers to a type of content. Text files can contain plain text, but they are not limited to such.

At a generic level of description, there are two kinds of computer files: text files and binary files.[1]

Pourtant, il me semble que c'est assez répandu, que d'opposer les formats binaires, aux formats dits de "texte brut", c'est à dire stockant

Dans tous les cas, c'est binaire. Dans tous les cas, il faut un outil pour les lires.

Tant qu'a faire du mal aux mouches, je te dirais qu'en fait non, rien n'est binaire, puisque ton information n'est jamais exactement une suite de 0 et 1: entre les changements d'états il y à toujours une valeur indéterminée, gérée par l'électronique d'une façon ou d'une autre.

Le problème ici, c'est que pour un fichier ne contenant pas de texte brut, l'outil nécessaire pour lire ton fichier est complexe.

Au passage, chez moi, j'ai plein de logs qui sont compressés

Donc, ce ne sont pas tes logs que tu lis, avec tes outils, mais bien des archives. Et les outils en question font un travail largement différent d'un (oui je sais, version on ne peut plus naïve et bugguée):

FILE *input=fopen("monlog", "r");
while( !feof(input) )
{
 putchar(fgetc(input));
}

Et au final il faut des programmes complexes pour lire des formats qui n'ont aucune fonction standard pour pouvoir les manier.
Sauf que, bien sûr, dans ton cas tu as choisi d'archiver ces journaux pour une raison X ou Y (le manque de place, logiquement?).
C'est là, à mon avis, le problème: si tu choisis de stocker tes fichiers dans un format à la con, ok, mais assumes. Si tu préfères les garder sous une forme triviale, de fichier textes, ok, mais tu assumes aussi les conséquences: les deux ont des avantages.
Dans le cas de systemd, on à un outil qui récupère du texte brut, le rentre dans des structures, puis, si tu le souhaites, recraches éventuellement (oui, je suis au courant qu'il est possible d'avoir à nouveau du texte brut) le contenu en texte brut.
Le problème, c'est que 1) ce n'est pas le comportement par défaut (sauf sur Debian, il semblerait) et 2) quel est l'intérêt de transformer un journal, qui est du texte brut à la base (une grande part des programmes qui font du log, soit écrivent dans des fichiers de texte brut, soit crachent sur stderr ou stdout sous forme de texte brut) en format complexe, puis de le décomplexifier en format texte?
Je sais que quand on parle de performance, de ne pas faire de choses inutiles, on nous rétorque qu'à l'heure actuelle ce n'est pas important, que "le client rachètera de la ram" (bon, ok, un proc plus puissant, ici, mais c'est une réplique d'un prof que j'ai eu et qui m'a vraiment marqué), mais je trouve ce raisonnement stupide. Et pire encore: ajouter des étapes complexes dans du code, ajouter du code qui au final ne sert à rien (puisqu'un peu plus loin on exécute du code qui annule... sans qu'il y ait eu de transformation entre deux!) c'est ajouter de la complexité de maintenance inutilement.
Il existe un mot pour résumer ça: bloatware!