Quand l'encodage UTF-8 a commencé à se démocratiser, combien ont hurlé que UTF-8, c'est pas assez répandu alors que l'ASCII, on peut le lire sur n'importe quelle machine qui nous tombe sous la main?
N’importe quelle machine qui peut lire de l’ASCII peut lire de l’UTF-8, sauf les caractères non-ASCII (mais comme de toute façon ils sont pas représentables OSEF). C’est d’ailleurs cette compatibilité qui a fait la force d’UTF-8 (au début UTF-16 était pas mal poussé et certains pensaient que UTF-8 serait là uniquement pour la transition, mais bizarrement personne n’en voulait...)
Tu mentionnes toute machine qui a moins de 10ans peut le lire. Je te parie que d'ici 10ans il n'existera aucune système sur lequel un lecteur de log journald ne sera pas disponible!
Les langages de programmation? Ils auront leur bibliothèque, tout comme ils ont tous une bibliothèque XML.
Je n’ai pas de boule de cristal, mais ça m’étonnerait énormément. Le format de journald est spécifique à :
Un système (Linux)
Un logiciel (journald)
Un usage (les logs)
quel mainteneur d’une librairie standard d’un langage voudrait prendre du temps pour ça, honnêtement ? La seule raison pour laquelle le format de journald arriverait dans les librairies standard d’un langage serait que ce format soit universellement adopté, de Microsoft à Apple en passant par les BSD. Les chances pour que ça arrive sont proches de 0 à mon avis.
Faire du format binaire spécifique avait du sens quand les librairies standard des langages tendaient à être anémiques et n’apportaient pas grand chose de réutilisable à quelqu’un qui voulait définir un nouveau format. Aujourd’hui l’usage a changé : les librairies standards tendent à essayer de couvrir de plus en plus d’usages avec quelques formats génériques (JSON, XML, zlib) mais qui peuvent couvrir quasiment tous les besoins. Aujourd’hui avec la lib standard de Python je peux gérer facilement des web-services (99% sont en JSON ou XML), des documents bureautiques (les deux formats dominants, OOXML et ODF sont juste des fichiers zip contenant des fichiers XML), des logiciels (idem pour les .jar, .apk, .ipa ou les extensions Firefox). En fait, à part les fichiers multimedia (video/audio/image), à peu près tous les fichiers que je manipule au jour le jour sont facilement « scriptables » (i.e. lisibles facilement en quelques lignes de Python en utilisant juste les outils fournis par sa lib standard). Ce que je ne me prive pas de faire, du reste. Je parle de Python, mais ça s’applique dans à peu près tous les autres langages.
C’est en regard de ces faits là que quand je vois quelqu’un réinventer la roue avec un nouveau format binaire spécifique, je tique. Pourquoi refuser de s’appuyer sur la puissance des librairies standard des langages modernes ? Un nouveau format binaire spécifique en 2014, ça ne m’inspire qu’une chose : un type excentrique sur son îlot qui s’amuse à définir une nouvelle langue à partir d’un mélange d’elfique et de klingon.
Alors bien sûr on peut toujours arguer que tous les usages ne sont pas implémentables avec ces 2-3 formats génériques. Ce qui est parfaitement vrai : je vois mal réécrire InnoDB avec juste zlib+xml par exemple. Mais pour moi ça devrait rester l’exception, une exception soigneusement justifiée, et je n’ai jusqu’ici vu absolument aucun argument convainquant justifiant cette exception dans le cadre de journald.
[^] # Re: Mon avis personnel
Posté par Moonz . En réponse au journal Debian adopte systemd comme init par défaut. Évalué à 4.
N’importe quelle machine qui peut lire de l’ASCII peut lire de l’UTF-8, sauf les caractères non-ASCII (mais comme de toute façon ils sont pas représentables OSEF). C’est d’ailleurs cette compatibilité qui a fait la force d’UTF-8 (au début UTF-16 était pas mal poussé et certains pensaient que UTF-8 serait là uniquement pour la transition, mais bizarrement personne n’en voulait...)
Je n’ai pas de boule de cristal, mais ça m’étonnerait énormément. Le format de journald est spécifique à :
quel mainteneur d’une librairie standard d’un langage voudrait prendre du temps pour ça, honnêtement ? La seule raison pour laquelle le format de journald arriverait dans les librairies standard d’un langage serait que ce format soit universellement adopté, de Microsoft à Apple en passant par les BSD. Les chances pour que ça arrive sont proches de 0 à mon avis.
Faire du format binaire spécifique avait du sens quand les librairies standard des langages tendaient à être anémiques et n’apportaient pas grand chose de réutilisable à quelqu’un qui voulait définir un nouveau format. Aujourd’hui l’usage a changé : les librairies standards tendent à essayer de couvrir de plus en plus d’usages avec quelques formats génériques (JSON, XML, zlib) mais qui peuvent couvrir quasiment tous les besoins. Aujourd’hui avec la lib standard de Python je peux gérer facilement des web-services (99% sont en JSON ou XML), des documents bureautiques (les deux formats dominants, OOXML et ODF sont juste des fichiers zip contenant des fichiers XML), des logiciels (idem pour les .jar, .apk, .ipa ou les extensions Firefox). En fait, à part les fichiers multimedia (video/audio/image), à peu près tous les fichiers que je manipule au jour le jour sont facilement « scriptables » (i.e. lisibles facilement en quelques lignes de Python en utilisant juste les outils fournis par sa lib standard). Ce que je ne me prive pas de faire, du reste. Je parle de Python, mais ça s’applique dans à peu près tous les autres langages.
C’est en regard de ces faits là que quand je vois quelqu’un réinventer la roue avec un nouveau format binaire spécifique, je tique. Pourquoi refuser de s’appuyer sur la puissance des librairies standard des langages modernes ? Un nouveau format binaire spécifique en 2014, ça ne m’inspire qu’une chose : un type excentrique sur son îlot qui s’amuse à définir une nouvelle langue à partir d’un mélange d’elfique et de klingon.
Alors bien sûr on peut toujours arguer que tous les usages ne sont pas implémentables avec ces 2-3 formats génériques. Ce qui est parfaitement vrai : je vois mal réécrire InnoDB avec juste zlib+xml par exemple. Mais pour moi ça devrait rester l’exception, une exception soigneusement justifiée, et je n’ai jusqu’ici vu absolument aucun argument convainquant justifiant cette exception dans le cadre de journald.