Parce que Lennart n'a toujours pas comprit l'intérêt d'Unix. L'interface texte toussa …
Les mauvaises langues me diront qu'il y a une commande grepd, catd, cutd, … Ou encore une commande pour traduire le format de journald en texte. Mais ou est l'intérêt, ou ??
Il y a effectivement toutes les commandes nécessaires pour parcourir et trouver rapidement ce qu'on cherche dans les logs. Je ne vois pas en quoi c'est de la mauvais foi que de le dire?!
A moins que tu ne puisses démontrer que ces commandes sont moins performantes ou moins puissantes que leurs homologues sur fichier texte. Tu peux?
Tu dis plus loin que tu as lu un article de Lennart où il explique les raisons, donc l'intérêt, tu le connais déjà.
Après si tu n'es pas d'accord, tu peux argumenter (un peu comme en-dessous, sauf que… voir plus bas!)
La place ? Les logs chez moi ne font même pas 50Mo, et journald est inutilisable sur un serveur car il est dépendant de systemd.
Chez moi, (Debian Sid, avec tous les réglages de log par défaut), le répertoire /var/log fait 416Mo.
Mais "chez moi c'est comme ça", c'est rarement un argument pertinent pour justifier ou invalider une décision technique sur le développement d'outils de production. Le répertoire ferait 300ko, je ne verrais toujours pas en quoi les logs binaires sont un problème, à défaut d'être un progrès.
On ne peut pas stocker des données binaires ? Normal, ce n'est pas leur place. Le reste, c'est comme un code source : il faut faire un choix entre maintenabilité/lisibilité et rapidité.
Je ne comprends pas ce que tu veux dire par "on ne peut pas stocker des données binaires".
J'ai l'impression qu'on y arrive très bien au contraire:
-exécutables
-documents bureautique, fichiers pdf
etc.
En fait, tout ce qui n'est pas en texte clair peut être considéré comme étant en binaire, et la différence est uniquement pour nous, humains, la machine ne la voit pas. (ou alors faut m'expliquer en quoi l'anglais est plus compréhensible que du code "binaire" en Unix).
Même le format texte dépend d'un encodage, et on le décode avec les outils texte.
Donc vraiment, non, je ne vois pas.
S'il avait dit "format texte optimisé avec un nouvel encodage" et au lieu de catd, il avait un patch sur cat sans en parler, tu n'aurais peut-être même pas vu la différence…
je vous recommande de la lire : elle montre que l'approche de Lennart manque de recul sur l’existante.
Je pense qu'on attend avec impatience plus de détails…
[^] # Re: Pourquoi du binaire
Posté par Maclag . En réponse au journal Documentation du format du Journal. Évalué à 4.
Il y a effectivement toutes les commandes nécessaires pour parcourir et trouver rapidement ce qu'on cherche dans les logs. Je ne vois pas en quoi c'est de la mauvais foi que de le dire?!
A moins que tu ne puisses démontrer que ces commandes sont moins performantes ou moins puissantes que leurs homologues sur fichier texte. Tu peux?
Tu dis plus loin que tu as lu un article de Lennart où il explique les raisons, donc l'intérêt, tu le connais déjà.
Après si tu n'es pas d'accord, tu peux argumenter (un peu comme en-dessous, sauf que… voir plus bas!)
Chez moi, (Debian Sid, avec tous les réglages de log par défaut), le répertoire /var/log fait 416Mo.
Mais "chez moi c'est comme ça", c'est rarement un argument pertinent pour justifier ou invalider une décision technique sur le développement d'outils de production. Le répertoire ferait 300ko, je ne verrais toujours pas en quoi les logs binaires sont un problème, à défaut d'être un progrès.
Je ne comprends pas ce que tu veux dire par "on ne peut pas stocker des données binaires".
J'ai l'impression qu'on y arrive très bien au contraire:
-exécutables
-documents bureautique, fichiers pdf
etc.
En fait, tout ce qui n'est pas en texte clair peut être considéré comme étant en binaire, et la différence est uniquement pour nous, humains, la machine ne la voit pas. (ou alors faut m'expliquer en quoi l'anglais est plus compréhensible que du code "binaire" en Unix).
Même le format texte dépend d'un encodage, et on le décode avec les outils texte.
Donc vraiment, non, je ne vois pas.
S'il avait dit "format texte optimisé avec un nouvel encodage" et au lieu de catd, il avait un patch sur cat sans en parler, tu n'aurais peut-être même pas vu la différence…
Je pense qu'on attend avec impatience plus de détails…