Faut croire qu'en 40 ans, pas foule a réussi à standardiser du texte (déjà que personne n'arrive à se mettre d'accord sur comment on écrit un retour à la ligne entre OS...)
Je retourne la question dans l'autre sens : quel interêt d'un stockage en texte "standard" (à définir)?
mais je crois que plus grand monde a des systèmes équipés de mémoires de stockages pour lesquelles 160Ko n'est pas négligeable (taille de mon dossier de log).
Donc au final, j'en conclue que ça ne te dérange pas de sélectionner l'option permettant de sortir en texte, ça bouffe rien. Finalement, en quoi le fait qu'il y a un stockage binaire (encore plus petit) à côté de ta sortie préférée te dérange?
Un truc que je ne capte pas : vous avez votre sortie texte, tous vos avantages d'une sortie texte sont la, donc quelle est la réélle critique?
Sinon, pour information, tu es sensé stocker tes logs pendant 1 an, et un jour ça passera à 2 ans. tout le monde n'a pas que 2 visiteurs par jour sur son site web et a des loggs à gérer.
Je jette un oeil vite fait sur mon petit site web, access_log d'httpd fait 100 Mo (non compressé ok, ça donne 3 Mo compressé, mais peut-on considérer du compressé comme du texte? Non, un octet quii saute et hop tout est perdu, pile une critique de journald, donc parlons de 100 Mo). Merci le texte (déjà un rapport de 1/30 juste en compressant de manière générique sans optimisation "pour logs"), sur 1 an ça donne 30 Go, et tout ça pour un petit site... Je n'ose pas imagine un site moyen ni gros.
Je tape un peu à côté, mais c'est juste pour dire que la où toi tu n'as pas de problème de place, d'autres en ont. J'ai vu plusieurs projets (dont un dont j'étais chef de projet, c'est moi qui ai pris la gueulate d'avoir fait planter un serveur à cause de lenteur non gérées quand le log a fait x100 d'un coup) se dire "pas grave, on a du CPU, du disque et du réseau" et ensuite exploser en vol à cause des perfs dès que ça montait en charge car succès, et le boss il a pas aprécié que ça se plante le jour où ça a du succès (ou simplement un gros problème qui fait faire de gros logs) avec les clients...
Bref, désolé, mais la taille, la perf, c'est critique pour certains, et le but d'un projet tel que celui dont en parle n'est pas de simples serveurs.
[^] # Re: GNU/SystemD/Linux
Posté par Zenitram (site web personnel) . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 3.
Faut croire qu'en 40 ans, pas foule a réussi à standardiser du texte (déjà que personne n'arrive à se mettre d'accord sur comment on écrit un retour à la ligne entre OS...)
Je retourne la question dans l'autre sens : quel interêt d'un stockage en texte "standard" (à définir)?
Donc au final, j'en conclue que ça ne te dérange pas de sélectionner l'option permettant de sortir en texte, ça bouffe rien. Finalement, en quoi le fait qu'il y a un stockage binaire (encore plus petit) à côté de ta sortie préférée te dérange?
Un truc que je ne capte pas : vous avez votre sortie texte, tous vos avantages d'une sortie texte sont la, donc quelle est la réélle critique?
Sinon, pour information, tu es sensé stocker tes logs pendant 1 an, et un jour ça passera à 2 ans. tout le monde n'a pas que 2 visiteurs par jour sur son site web et a des loggs à gérer.
Je jette un oeil vite fait sur mon petit site web, access_log d'httpd fait 100 Mo (non compressé ok, ça donne 3 Mo compressé, mais peut-on considérer du compressé comme du texte? Non, un octet quii saute et hop tout est perdu, pile une critique de journald, donc parlons de 100 Mo). Merci le texte (déjà un rapport de 1/30 juste en compressant de manière générique sans optimisation "pour logs"), sur 1 an ça donne 30 Go, et tout ça pour un petit site... Je n'ose pas imagine un site moyen ni gros.
Je tape un peu à côté, mais c'est juste pour dire que la où toi tu n'as pas de problème de place, d'autres en ont. J'ai vu plusieurs projets (dont un dont j'étais chef de projet, c'est moi qui ai pris la gueulate d'avoir fait planter un serveur à cause de lenteur non gérées quand le log a fait x100 d'un coup) se dire "pas grave, on a du CPU, du disque et du réseau" et ensuite exploser en vol à cause des perfs dès que ça montait en charge car succès, et le boss il a pas aprécié que ça se plante le jour où ça a du succès (ou simplement un gros problème qui fait faire de gros logs) avec les clients...
Bref, désolé, mais la taille, la perf, c'est critique pour certains, et le but d'un projet tel que celui dont en parle n'est pas de simples serveurs.