Tout est une représentation, donc le fait que ce soit une représentation n'est pas une manière de discriminer l'un ou l'autre.
Ainsi j'ai bien compris que 11/12/13 est en fait codé 31 31 2F 31 32 2F 31 33 qui lui même doit être écrit sur le disque dans un truc qui ressemble à 010010100101011 (.....) 0100011100011000110001 de la même manière que 9��6���. doit être codé sur le disque dans un truc qui ressemble à 00100101100110 (...) 10010011001100110010. Ainsi il n'y a aucune différence entre 11/12/13 et 9��6��� puisque in fine c'est une suite de 0 et de 1 (mais pas la même).
J'ai très bien compris cela et j'avoue que cela ne me pose aucun soucis. J'ai donc bien compris ce que tu me raconte.
Ainsi le format binaire texte avec lequel je dois travailler est lu simplement sur ma machine sans avoir besoin de truc bien compliqué. (et je ne considère pas que installer un truc soit compliqué). J'ai même des outils et des process de travail qui savent lire les fichiers en question et en tirer des informations. ET c'est un point important pour moi, car j'aime bien être indépendant, je SAIS que je pourrais lire ces fichiers sur la machine d'un pote ou d'un client ou d'un hôtel si je dois faire face à un soucis et que ma machine ne fonctionne pas. Évidemment tous les outils ne seront pas disponibles (et probablement aucun), mais j'imagine que au pire je pourrais faire "chercher" et que je pourrais lire séquentiellement. JE COMPRENDS tout à fait que ce besoin n'est pas utile pour des personnes ayant des millions de lignes de logs (car ils ne peuvent pas les lire "dans le texte"), mais les millions de lignes c'est pas le cas général. ET le format binaire texte est fait de telle manière c'est que si tu coupes le fichier en deux (avec une scie) chaque partie peut être lue, même si toutes les informations ne sont pas dans les deux moitiés.
C'est 2 avantages résilience à la corruption et très largement lisible sur d'autres os/machine est, pour MOI, un point important. Probablement que demain les grep/sed/awk et j'en passe pourront chercher directement dans journald, probablement que demain il y aura des éditeurs journald installable facilement sur tous les os et toutes les machines (pratiquement tous/toutes) et qu'il y aura un mécanisme pour ne pas perdre le fichier complet de log s'il y a une corruption et ce jour là, je suis intimement persuadé que je serais heureux (si je ne suis pas encore mort) de pouvoir bénéficier de toutes les nouvelles qualités de journald. En attendant je suis pas enchanté de le voir se répandre, même si pour le moment il peut produire du fichier texte.
Ensuite, enfin, plutôt, effectivement je serais chaffouin si mon rotate-log compress en tar.xyz et que je n'ai aucun moyen de lire cette compression sur les machines que j'utilise ou que je suis susceptible d'utiliser. et que 99% des machines que je cotoie ne sont pas capable de lire de tels fichiers, et même si cela me fait gagner 12% d'espace disque. ATTENTION, je ne dis pas qu'il ne faut pas passer à tar.xyz, je dis qu'il faut EN MÊME TEMPS donner des outils installables sur plus de 80% des machines en service.
[^] # Re: Définition
Posté par hervé Couvelard . En réponse au journal Vivent les journaux binaires !. Évalué à 5.
Mais il est la le problème.
Tout est une représentation, donc le fait que ce soit une représentation n'est pas une manière de discriminer l'un ou l'autre.
Ainsi j'ai bien compris que 11/12/13 est en fait codé 31 31 2F 31 32 2F 31 33 qui lui même doit être écrit sur le disque dans un truc qui ressemble à 010010100101011 (.....) 0100011100011000110001 de la même manière que 9��6���. doit être codé sur le disque dans un truc qui ressemble à 00100101100110 (...) 10010011001100110010. Ainsi il n'y a aucune différence entre 11/12/13 et 9��6��� puisque in fine c'est une suite de 0 et de 1 (mais pas la même).
J'ai très bien compris cela et j'avoue que cela ne me pose aucun soucis. J'ai donc bien compris ce que tu me raconte.
Maintenant ce que j'essaie d'expliquer c'est que lorsque le logiciel écrit 11/12/13 afin d'être facilement lu par un être humain, JE trouve dommage qu'on le retrouve sous la forme 9��6��� car il faut AUTRE CHOSE qu'un simple éditeur de texte pour le lire. J'ai bien compris qu'un éditeur de texte c'est un truc qui transforme 01001010010(.....) en 11/12/13. MAIS il y a une foultitude d'éditeur de texte, sous tous les os, qui savent faire la transformation et il y a une foultitude d'outils qui savent rechercher et trouver dans le format binaire qu'est le texte. ainsi même si j'ai 31 31 2F 31 32 2F 31 33 je sort hexedit (que j'utilise seulement sous la torture) et je vois les 11/12/13. Et dans les cas ou c'est mal encodé, cela ne me dérange pas de voir des trucs sous la forme "c'est franchement pas génial". Et J'ai bien compris qu'il y a des tonnes d'encodage que même mon firefox ne sait pas lire, mais je n'ai pas à travailler avec et je n'ai aucune de mes machines qui en produise, ni aucun de mes contacts
Ainsi le format binaire texte avec lequel je dois travailler est lu simplement sur ma machine sans avoir besoin de truc bien compliqué. (et je ne considère pas que installer un truc soit compliqué). J'ai même des outils et des process de travail qui savent lire les fichiers en question et en tirer des informations. ET c'est un point important pour moi, car j'aime bien être indépendant, je SAIS que je pourrais lire ces fichiers sur la machine d'un pote ou d'un client ou d'un hôtel si je dois faire face à un soucis et que ma machine ne fonctionne pas. Évidemment tous les outils ne seront pas disponibles (et probablement aucun), mais j'imagine que au pire je pourrais faire "chercher" et que je pourrais lire séquentiellement. JE COMPRENDS tout à fait que ce besoin n'est pas utile pour des personnes ayant des millions de lignes de logs (car ils ne peuvent pas les lire "dans le texte"), mais les millions de lignes c'est pas le cas général. ET le format binaire texte est fait de telle manière c'est que si tu coupes le fichier en deux (avec une scie) chaque partie peut être lue, même si toutes les informations ne sont pas dans les deux moitiés.
C'est 2 avantages résilience à la corruption et très largement lisible sur d'autres os/machine est, pour MOI, un point important. Probablement que demain les grep/sed/awk et j'en passe pourront chercher directement dans journald, probablement que demain il y aura des éditeurs journald installable facilement sur tous les os et toutes les machines (pratiquement tous/toutes) et qu'il y aura un mécanisme pour ne pas perdre le fichier complet de log s'il y a une corruption et ce jour là, je suis intimement persuadé que je serais heureux (si je ne suis pas encore mort) de pouvoir bénéficier de toutes les nouvelles qualités de journald. En attendant je suis pas enchanté de le voir se répandre, même si pour le moment il peut produire du fichier texte.
Ensuite, enfin, plutôt, effectivement je serais chaffouin si mon rotate-log compress en tar.xyz et que je n'ai aucun moyen de lire cette compression sur les machines que j'utilise ou que je suis susceptible d'utiliser. et que 99% des machines que je cotoie ne sont pas capable de lire de tels fichiers, et même si cela me fait gagner 12% d'espace disque. ATTENTION, je ne dis pas qu'il ne faut pas passer à tar.xyz, je dis qu'il faut EN MÊME TEMPS donner des outils installables sur plus de 80% des machines en service.