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?
a) Moins pratiques : il faut lire les logs sur un ordinateur qui a systemd et toute la clique installé. Si on essaye de lire les logs justement parceque le serveur plante/se comporte bizarrement il faut donc une autre machine avec systemd et toute la clique installée. A comparer avec des logs que ej peux lire sur n'importe quel machine ou presque et traiter avec le logiciel de mon choix.
b) Moins puissantes : avec des formats en texte pur je peux TOUT indexer si je veux, ou ne rien indexer si je veux aussi. Avec systemd si je veux utiliser les index en place je dois passer par l'API C, si je veux d'autres index tout le temps il faut soit que je passe par les USER_JOURNAL_FIELDS en les dénaturant soit que je fasse des exports et que je les indexe à la main (mais du coup je perd les index de base). Donc par exemple si je veux debugguer une phase initialisation SIP à la volée - ben je peux plus. Comme l'export ne fonctionne pas en continu ou en temps réel je suis obligé de faire un test, puis d'exporter, puis de lire le log et de recommencer. On dira ce qu'on voudra mais j'aimais tail -f moi.
c) Moins performant : Sur les choses qui sont prévus comme telle, il ne dervait pas y avori de soucis de performance avec journald. Il sera probablement plus rapide sur certains cas et moins rapide sur d'autres (Un format binaire normé peut difficilement battre de l'append de base sur de gros évènement genre crash java avec trois page de détails - par contre sur une flopée de petites insertion il devrait être meilleur.) Ceci étant j'attend une version stable pour faire des tests et voir le résultat.
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 6.
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?
a) Moins pratiques : il faut lire les logs sur un ordinateur qui a systemd et toute la clique installé. Si on essaye de lire les logs justement parceque le serveur plante/se comporte bizarrement il faut donc une autre machine avec systemd et toute la clique installée. A comparer avec des logs que ej peux lire sur n'importe quel machine ou presque et traiter avec le logiciel de mon choix.
b) Moins puissantes : avec des formats en texte pur je peux TOUT indexer si je veux, ou ne rien indexer si je veux aussi. Avec systemd si je veux utiliser les index en place je dois passer par l'API C, si je veux d'autres index tout le temps il faut soit que je passe par les USER_JOURNAL_FIELDS en les dénaturant soit que je fasse des exports et que je les indexe à la main (mais du coup je perd les index de base). Donc par exemple si je veux debugguer une phase initialisation SIP à la volée - ben je peux plus. Comme l'export ne fonctionne pas en continu ou en temps réel je suis obligé de faire un test, puis d'exporter, puis de lire le log et de recommencer. On dira ce qu'on voudra mais j'aimais tail -f moi.
c) Moins performant : Sur les choses qui sont prévus comme telle, il ne dervait pas y avori de soucis de performance avec journald. Il sera probablement plus rapide sur certains cas et moins rapide sur d'autres (Un format binaire normé peut difficilement battre de l'append de base sur de gros évènement genre crash java avec trois page de détails - par contre sur une flopée de petites insertion il devrait être meilleur.) Ceci étant j'attend une version stable pour faire des tests et voir le résultat.