L’un des reproches fait au journal, l’outil de journalisation système — log — de systemd, est l’utilisation d’un format binaire initialement non documenté et pour lequel aucune promesse de stabilité n’avait été faite.
Une partie de ces reproches est maintenant caduque, puisqu’un document apparu hier sur le wiki de systemd documente en profondeur le format du journal. Le comportement que doit avoir un logiciel souhaitant lire ou écrire le journal sans passer par l’interface de programmation de journald est également décrit.
L’équipe s’est même engagée à garantir la stabilité, tant pour le format binaire que pour le format texte d’exportation.
NdM : merci à Mjules pour son journal.
Aller plus loin
- Journal à l’origine de la dépêche (228 clics)
# Documenté ou pas, ce sera non!
Posté par FantastIX . Évalué à -8.
Désolé pour ce commentaire négatif mais en plus de huit ans d'utilisation de Linux, c'est la première fois que je vois un outil système, c-à-d un composant critique, imposer un journal au format binaire! N'en déplaise à ses concepteurs, (puisque j'ai encore le choix, pourvu que ça dure…) je me passerai de ce truc infâme tant qu'il exposera son journal au format binaire. Et qu'il permette de l'exporter n'y changera rien.
[^] # Re: Documenté ou pas, ce sera non!
Posté par claudex . Évalué à 8.
J'espère que tu ne compresse pas tes logs.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Documenté ou pas, ce sera non!
Posté par barmic . Évalué à 6.
Ni qu'il les encode en autre chose que de l'ASCII.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Documenté ou pas, ce sera non!
Posté par FantastIX . Évalué à 3.
tail -f /var/log/messages | egrep -i 'error|sd?' ?
Entre avoir tous tes logs au format binaire ou au moins celui, en cours, qui te donne les infos en temps réel en un format lisible sans transformation, *je* vois une différence. L'autre grosse différence est que, si mes logs sont compressés (donc en binaire) c'est *moi* et personne d'autre qui l'ai décidé.
C'est drôle comme les arguments d'hier, qui faisaient la force et le mérite de UNIX sont aujourd'hui aussi contestables que les machines à laver qui duraient trente ans.
[^] # Re: Documenté ou pas, ce sera non!
Posté par CrEv (site web personnel) . Évalué à 4.
hum…
et si tu avais un
jtail -f /var/log/messages | egrep -i 'error|sd?'ça changerait quoi ?A part le fait de respecter l'adage "un programme qui fait une seule chose"
nope.
Avoir des fichiers, des systèmes de pipe, des outils simples qui font des choses simples ne me semble pas disparaître. Après qu'il manque un outil
jtailpar exemple, ben il ne reste qu'à le faire, je ne vois pas vraiment le problème.En fait je vois pas très bien le problème. Que tu ne puisses utiliser exactement les mêmes outils qu'avant, ok, je comprend que ça puisse sembler dommage. Mais je ne vois pas en quoi ça serait un vrai problème si tu as un équivalent.
[^] # Re: Documenté ou pas, ce sera non!
Posté par GnunuX (site web personnel) . Évalué à 4.
En fait c'est journalctl -f | egrep -i 'error|sd?' (même j'ai mal a comprendre le "?").
[^] # Re: Documenté ou pas, ce sera non!
Posté par CrEv (site web personnel) . Évalué à 3.
Ok, donc en fait l'argument "je ne peux pas faire un tail" est réellement bidon et c'est juste que les gens ne veulent pas du tout apprendre le nom d'une nouvelle commande (planqué derrière "l'héritage d'unix" ça ressemble beaucoup plus à un bon gros poil dans la main)
(et pour le ? j'en sais rien j'ai juste repris le message du dessus ;) )
[^] # Re: Documenté ou pas, ce sera non!
Posté par Zenitram (site web personnel) . Évalué à 3.
La communauté Linux devient vraiment exactement pareille que les stats générales sur l'ensemble de la population : dans chaque domaine, des gens qui essayent d'avancer, et des gens qui ne veulent rien changer à leurs habitudes "parce qu'on n'a toujours fait comme ça" et qui freinent de tout leur poids pour le principe de ne rien changer. C'est la communauté qui vieillit, l'âge, tout simplement… L'histoire n'est qu'un éternel recommencement!
[^] # Re: Documenté ou pas, ce sera non!
Posté par Anonyme . Évalué à 1.
https://linuxfr.org/nodes/96099/comments/1401998
[^] # Re: Documenté ou pas, ce sera non!
Posté par didg . Évalué à -1.
Et:
jtail /dev/sda| …
Ca marche aussi?
parce que des fois c'est vraiment la m…
[^] # Re: Documenté ou pas, ce sera non!
Posté par Anonyme . Évalué à 0.
Ça fait que je ne pourrait pas lire les logs sur Mac OS puisqu'il faut
systemdpour avoir les outils dejournald.[^] # Re: Documenté ou pas, ce sera non!
Posté par CrEv (site web personnel) . Évalué à 4.
Et qu'est ce qui empêche d'avoir un outil sous mac pour lire le format de journald ?
Parce que là ça commence à être pas mal comme argument, après "je peux pas faire de tail sur mon linux" ça devient "je peux pas faire de tail sur un autre système ne supportant pas systemd".
Et désolé mais de mon point de vue ça n'a pas vraiment à rentrer en ligne de compte, d'autant plus que les sources de l'outil de lecture du format de journald sont dispo, et que le format est aussi publique et documenté.
Et comment je fais sous multideskos ?
[^] # Re: Documenté ou pas, ce sera non!
Posté par Batchyx . Évalué à 2.
Et qu'est ce que te dit que au moment ou tu aura la merde jusqu'au cou, tu pourra facilement l'obtenir ? On voit bien la différence entre ceux qui ont toujours grandi avec un accès à Internet à proximité et les autres.
Si mon système d'init ou mon noyau se vautre lamentablement, je peux toujours regarder les logs avec un cat depuis grub2. Point bonus, si les machines le permettent, je peux dumper ça sur le port série, et lire ça sur une autre machine, quelque soit la nullité de l'OS de merde qu'il y à dessus. Est ce qu'il va falloir mettre journald dans grub pour avoir la même chose ?
[^] # Re: Documenté ou pas, ce sera non!
Posté par ckyl . Évalué à 5.
Et ca te choque pas tout le bloat dans grub2 qui devient un mini OS ? Un cat dans un bootloader ! ;)
[^] # Re: Documenté ou pas, ce sera non!
Posté par Zenitram (site web personnel) . Évalué à 4.
Tant qu'à mettre cat dans un boot loader, autant y mettre journald aussi, on est est plus à violer une règle qu'on dit vouloir respecter (parce que bon, avoir cat dans grub, c'est pas vraiment rendre grub "une commande pour une action", hein, et après on critique systemd/journald…)
[^] # Re: Documenté ou pas, ce sera non!
Posté par Moonz . Évalué à 4.
Sauf que si tous les logiciels doivent gérer tous les formats binaires inventés depuis le début de l’informatique, on est pas sorti de l’auberge…
[^] # Re: Documenté ou pas, ce sera non!
Posté par Zenitram (site web personnel) . Évalué à 2.
Il y a déjà ce troll sur le journal correspondant…
[^] # Re: Documenté ou pas, ce sera non!
Posté par pikapika . Évalué à -1.
considérer qu'une sortie texte n'a rien à faire en binaire n'est pas du troll, c'est une simple question de logique
[^] # Re: Documenté ou pas, ce sera non!
Posté par Zenitram (site web personnel) . Évalué à 3.
L'argument d'autorité, quelle argument! Ce n'est pas une des définitions de troll?
[^] # Re: Documenté ou pas, ce sera non!
Posté par pikapika . Évalué à -6.
on peut surement te faire confiance sur le sujet, côté troll basique et répété à l'infini, tu es au top
[^] # Re: Documenté ou pas, ce sera non!
Posté par barmic . Évalué à 8.
Tu enchaine arguments d'autorité puis attaque personnelle. Ça ressemble quand même de plus en plus à du troll de bas étages.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Documenté ou pas, ce sera non!
Posté par barmic . Évalué à 2.
Tout les trolleurs savent que ça n'en est pas une ؟
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Documenté ou pas, ce sera non!
Posté par GnunuX (site web personnel) . Évalué à 10.
En 8 ans tu n'as jamais pris le temps dans le répertoire /var/log ? Il faut arrêter Gcompris …
Aller, un petit lien … : https://fr.wikipedia.org/wiki/Wtmp . Le pire c'est qu'il y en a d'autres, mais on ne va pas trop en dire d'un coup.
[^] # Re: Documenté ou pas, ce sera non!
Posté par Marc Quinton . Évalué à 4.
effectivement, pour voir les connexions sur ta machine préférée (fichier de log /var/log/wtmp), il faut au choix, savoir décoder du binaire, soir passer par une commande (last), soit … ce que tu veux. Mais ce n'est pas un accès direct.
Est-ce un mal ou un bien. Il me semble difficile d'y répondre, mais cela semble acceptable depuis des lustres. Et puis, un format un peu rigide (binaire) permet d'instrumenter un fichier, ce qui peut être un peu plus complexe sur un fichier ASCII complètement libre.
A quand des logs en XML :-) après tout, pourquoi pas.
[^] # Re: Documenté ou pas, ce sera non!
Posté par Anonyme . Évalué à 3.
On peut deja les avoir en json: journalctl -o json
[^] # Re: Documenté ou pas, ce sera non!
Posté par FantastIX . Évalué à 0.
Ma foi, à quoi servent grep, sed, awk, troff…? Et puis, complexe ne signifie pas que c'est impossible. Ah oui, il faut réfléchir un peu plus au départ. Peut-être. Ou pas. La belle affaire.
Je me rappelle ceci: http://theody.net/elements.html … Désormais obsolète, sans doute.
[^] # Re: Documenté ou pas, ce sera non!
Posté par Zenitram (site web personnel) . Évalué à 2.
Il serve à défaire le bordel fait avant.
Maintenant, on s’attaque à la base (le bordel fait avant), mais quelques personne veulent continuer à faire du bordel puis le défaire plutôt que de faire propre dès le départ.
Un peu comme creuser un trou et le reboucher ensuite, d'autres prennent l'information directement à la source.
C'est toujours aussi impressionnant de voir le nombre d'excuses bidons pour attaquer journald et/ou systemd. La résistance au changement démontre que l'informatique vieillit…
[^] # Re: Documenté ou pas, ce sera non!
Posté par Moonz . Évalué à 9. Dernière modification le 23 octobre 2012 à 12:25.
Moi ce que je remarque, c’est qu’il y a quinze ans, je pouvais explorer absolument tout le système en connaissant juste
ls,catetcd. C’est ça qui m’a amené à m’intéresser à l’informatique en tant qu’autre chose que de la science vaudoue, et j’oserai même dire que c’est peut-être un des points les plus importants dans la construction de ma personne (sans ça, j’aurai sûrement étudié dans un autre domaine, fait un autre travail, rencontré des personnes différentes). Et ce qui me désole c’est qu’on est en train de détruire ça au nom de… je sais pas quoi en fait. Je ne comprend toujours pas l’intérêt d’un format binaire relativement à du texte.Alors oui, c’est pas la mort de Linux, c’est pas la mort du Libre, c’est pas la destruction de l’esprit Unix. Pour moi c’est plus grave que ça, c’est la destruction d’un système dont les rouages internes sont accessibles à toute personne possédant un minimum de curiosité, d’un système dont la courbe d’apprentissage permet à n’importe qui de partir de quasiment 0, d’un système possédant des qualités didactiques en plus de techniques.
Sous Windows, t’as pas le logiciel pour lire ton fichier, t’es dans la merde, sous Linux, souvent
catsuffit, parce que le texte, s’il n’est pas totalement omniprésent, est tout de même bien plus représenté.Aujourd’hui je m’en fiche pour moi. J’ai suffisamment d’expérience pour suivre les évolutions, pour savoir qu’il faut
journalctlpour lire les fichiers de/var/log,sqlite3pour une bonne partie de la configuration de Firefox, etc.Par contre, quand je vois les évolutions qu’on nous « propose », et quand je pense à ceux qui sont aujourd’hui dans la situation dans laquelle j’étais il y a 15 ans, j’ai envie de pleurer.
Le pire c’est que le monde plus traditionnellement binaire commence doucement mais sûrement à se diriger vers des formats textes (PDF -> ebook, doc -> docx,…).
Et non, pour répondre à l’objection plus haut, tu ne peux pas comparer texte compressé et binaire proprio (proprio dans le sens spécifique à un soft, pas dans le sens non-libre) : dans le premier cas tu peux utiliser des commandes génériques donc plus susceptibles d’être maitrisées et connues (avec unzip+cat je peux observer le contenu un .jar, un .docx, un .odt, j’ai pas besoin de jopen, docopen et odtopen), dans le second cas tu as un logiciel = un format = un outil. Si ça c’est pas de la duplication d’efforts et de la multiplication d’emmerdes inutile…
N’importe quoi.
(je met mon argumentation au niveau de la tienne)
[^] # Re: Documenté ou pas, ce sera non!
Posté par FantastIX . Évalué à 2.
Je partage entièrement ton avis, même si mon expérience n'est pas aussi étendue.
[^] # Re: Documenté ou pas, ce sera non!
Posté par claudex . Évalué à 4.
Explique-moi comment tu explorais /var/log/wtmp il y a 15 ans avec cat ?
Pour les logs (ceux qui ne sont pas binaire), sans tail et grep c'est inutilisable actuellement.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Documenté ou pas, ce sera non!
Posté par Anonyme . Évalué à 3.
Marrant, y a une personne qui a pris cette exemple et tous ceux qui était en manque d'arguments se sont jeté dessus.
Mais à ce que je sache, personne n'a dit qu'il appréciait que
/var/log/wtmpsoit un fichier binaire.[^] # Re: Documenté ou pas, ce sera non!
Posté par claudex . Évalué à 2.
Personne ne s'en est plains non plus. Et les gens qui explique tout lire en texte depuis 50 ans ont un beau contre-exemple.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Documenté ou pas, ce sera non!
Posté par Moonz . Évalué à 2.
C’est vrai que wtmp contient des informations absolument vitales pour comprendre comment fonctionne ton système.
[^] # Re: Documenté ou pas, ce sera non!
Posté par GnunuX (site web personnel) . Évalué à 3.
Perso je commence toujours par faire un "last" et "history" avant de regarder les logs.
[^] # Re: Documenté ou pas, ce sera non!
Posté par Zenitram (site web personnel) . Évalué à 1.
[^] # Re: Documenté ou pas, ce sera non!
Posté par jyes . Évalué à 3.
Autant, je ne suis pas absolument contre ni systemd, ni journald, mais ça ce n’est pas une réponse…
[^] # Re: Documenté ou pas, ce sera non!
Posté par Anonyme . Évalué à 1.
C’est là où je voulais en venir dans mon commentaire : personne n’a jamais dit qu’il fallait absolument que
wtmpsoit binaire.[^] # Re: Documenté ou pas, ce sera non!
Posté par Zenitram (site web personnel) . Évalué à 1.
Mais personne n'a râlé qu'il l'est, ce qui casse l'argument "il faut que ce soit binaire car on a toujours fait comme ça" (ce qui est déjà un argument ressemblant aux singes dans une cage dont la porte s'ouvre plus tard mais dont les singent restent par habitude). C'est tout ce qui est dit.
A quand des arguments sérieux?
[^] # Re: Documenté ou pas, ce sera non!
Posté par Anonyme . Évalué à 2. Dernière modification le 23 octobre 2012 à 21:45.
Tu te souviens des débuts de UNIX ? Parce que moi j’étais même pas encore né, donc savoir qui a râlé sur quoi m’est impossible.
J’imagine que si
systemdetjournalddeviennent des standards et vivent aussi longtemps que UNIX a vécu, personne ne se souviendra de nos discussion.C’est très facile, 40 ans après, de dire que personne n’a jamais râlé.
[^] # Re: Documenté ou pas, ce sera non!
Posté par Zenitram (site web personnel) . Évalué à 1.
Si tu préfères : pas suffisamment pour que ça ai saigné et/ou qu'il y en ai un qui est proposé autre chose et que ça ai marché.
Et effectivement, je pense que dans 40 ans, systemd et journald (ou d'autres plus modernes car ça aura évolué) seront "normaux" et les gens se poseront à la limite une bonne tranche de rigolade sur l'idée même d'une telle "résistance". Ils auront sans doute la bataille de ceux qui veulent garder systemd et journald ("on a toujours fait comme ça") contre les nouveaux venus!
[^] # Re: Documenté ou pas, ce sera non!
Posté par Anonyme . Évalué à 2.
Le fait que personne n'est proposé autre chose, je n'en sais rien, je n'étais pas là.
Le fait que ça n'ai pas marché (dans le cas ou quelqu'un a proposé quelque chose) dépend de tellement de facteur que l'utiliser comme argument est idiot. Si ça se trouve les développeurs des UNIX originaux ne voulait pas de texte pour wtmp, ont préféré un format binaire et, ayant la main mise sur le système, ont imposé leur solution.
Je n'en sais rien et toi non plus. Mais la différence entre toi et moi c'est que toi tu te sers de ça comme d'un argument que tu considère ultime.
C'est pas une question de « on a toujours fait comme ça », c'est une question de « est-ce qu'on veut, aujourd'hui, un logiciel qui n'est pas stable et qui occupe la place la plus importante (pour
systemd) ou au moins une place très importante (pourjournald) dans nos système ».[^] # Re: Documenté ou pas, ce sera non!
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 23 octobre 2012 à 19:27.
Ben oui, en fait le "tout est fichier" est un mythe, c'est tout ce qu'il y a à conclure.
Du coup, c'est un peu difficile à accepter ça comme "argument" pour dire que journald a un défaut. A la limite expliquer pourquoi il faut un fichier texte absolument (en expliquant le besoin par autre chose que "on fait ça depuis 30 ans") plutôt qu'une sortie texte (que journald ou un autre logiciel peut produire) par exemple.
Donc, maintenant, si on se concentrait sur de vrais défauts potentiel de la chose en évitant le bruit ambiant qui ne fait que cacher de vrais défauts si il y en a?
[^] # Re: Documenté ou pas, ce sera non!
Posté par Moonz . Évalué à 5.
Comme exactement TOUS les formats et outils propriétaires (dans le sens spécifiques, pas dans le sens non-libre) depuis l’invention de l’informatique : impossibilité de réutiliser des outils existants et testés sur une bien plus large échelle, obligation de créer du code spécifique forcément moins testé et donc plus sujet à des bugs que des outils génériques, moins de chances d’avoir la possibilité d’y accéder dans son langage/environnement de prédilection, augmentation de la complexité du système total et donc 1. courbe d’apprentissage plus raide (forcément, apprendre deux outils qui peuvent tout faire, quitte à apprendre au fur et à mesure des outils plus spécifiques qui se greffent au-dessus pour faire des choses plus complexes, c’est plus simple que d’en apprendre directement 150 différents d’un coup), ce qui se traduit directement en coûts (bah oui, la formation c’est pas gratuit) ; 2. du risque d’erreur humaine (oups, -r pour journal c’est remove, -r pour mon autre outil c’est recursive) (idem, une erreur humaine ça a un coût en général), et le plus important, flexibilité moindre (avec les logs actuels je peux faire un
mount --bind /var/log /mnt/mychroot/var/logpuis lire les logs à partir de mon chroot qui ne possède passyslogctl, avecjournalctlje pourrai pas. Exemple capillotracté certes, mais c’est le principe de la flexibilité, de pas savoir à l’avance de quoi on aura besoin, donc la flexibilité vaut mieux en avoir trop que pas assez).Si on répète « le texte c’est bien », c’est pas parce qu’on est endoctriné dans une église bizarroïde hein, mais parce que le remplacement du texte par du binaire proprio a TOUJOURS posé ces problèmes et le posera TOUJOURS, « le texte c’est bien » c’est juste un raccourci pour ce que j’ai listé au dessus (et certainement d’autres que j’ai oublié).
[^] # Re: Documenté ou pas, ce sera non!
Posté par GnunuX (site web personnel) . Évalué à 3.
En même temps j'ai précisé que j'en connaissais d'autres …
Aller un deuxième exemple … regarde le nom de l'exécutable que l'on retrouve en installant … mysql (un serveur pas du tout dans l'esprit Unix) :
https://dev.mysql.com/doc/refman/5.0/fr/mysqlbinlog.html
[^] # Re: Documenté ou pas, ce sera non!
Posté par Zenitram (site web personnel) . Évalué à 0.
L'avantage c'est que tu peux utiliser ton Linux pour faire autant de chose qu'avant, si tu as envie.
Mais bon, d'autres personnes ont envie de faire autre chose, le monde évolue.
Non, parce que autant c'est sympa le cat il y a 20 ans, autant j'aimerai bien voir de l'audio et de la vidéo en format texte… Oui, il y a des abrutis qui ont décidé d'avoir de l'audio et de la vidéo sous Linux, sans faire du "compatible cat", les hérétiques!
[^] # Re: Documenté ou pas, ce sera non!
Posté par Moonz . Évalué à 2. Dernière modification le 23 octobre 2012 à 18:29.
Tes logs sont en vidéo avec une piste audio chez toi ?
Évidemment que tu ne vas pas utiliser un format texte pour un contenu qui n’a pas de représentation textuelle…
[^] # Re: Documenté ou pas, ce sera non!
Posté par Zenitram (site web personnel) . Évalué à -1. Dernière modification le 23 octobre 2012 à 18:46.
Ca va peut-être t'étonner, mais oui, j'ai des log audio : à chaque démarrage, mon BIOS fait un petit bip. Si il y a un problème, il communique par audio, genre du morse. Alors le "tout est texte", ça fait un peu sourire.
(presque) Plus sérieusement, le "tout est texte" (pas que les logs) était juste peut-être gérable avec ce qui était demandé à une machine il y a 30 ans, maintenant le monde a changé, le "tout est texte", ça fait longtemps que Linux l'a oublié, par exemple pour une vidéo. Ben oui, à écouter les gens, Linux n'aurait jamais du savoir lire une vidéo autre que de l'ASCII art, puisque c'est incompatible avec le "tout est texte". Bref, un journal en "binaire" n'a rien de choquant, dans tous les cas (actuel ou journald), il faut des commandes pour lire les logs.
Le "Tout est texte" d'il y a 30 ans, ce n'est pas un argument, ça montre juste un blocage 30 ans avant sans regarder l'évolution des machines.
[^] # Re: Documenté ou pas, ce sera non!
Posté par Anonyme . Évalué à 2.
Un programme en C a une representation textuelle. Pourquoi on utilise les sources compilés dans un binaire comme programmes alors qu'on pourrait garder ca sous forme textuelle et le compiler à la volée à chaque execution ?
[^] # Re: Documenté ou pas, ce sera non!
Posté par Misc (site web personnel) . Évalué à 2.
Avec tcc ( http://bellard.org/tcc/ )
[^] # Re: Documenté ou pas, ce sera non!
Posté par Moonz . Évalué à 1.
Parce que l’exécutable et le code source ne sont pas deux représentations différentes d’une même entité mais deux entités différentes, la preuve tu peux pas faire de conversion binaire -> source.
[^] # Re: Documenté ou pas, ce sera non!
Posté par Anonyme . Évalué à 2.
Pour l’audio, c’est faux, c’est cat compatible.
Pour cela il suffit d’avoir OSS et on peut faire :
cat <fichier> > /dev/dsp.[^] # Re: Documenté ou pas, ce sera non!
Posté par GnunuX (site web personnel) . Évalué à 2.
Oui tout est fichier, mais tout n'est pas ascii. Si tu fais un cat fichier_ascii.txt > /dev/dsp, je ne suis pas sûr qu'une oreille non expert en comprenne le sens.
[^] # Re: Documenté ou pas, ce sera non!
Posté par Zenitram (site web personnel) . Évalué à 2.
En texte? ;-)
[^] # Re: Documenté ou pas, ce sera non!
Posté par Anonyme . Évalué à 2.
Un
cat fichier.ogg > /dev/dspne fonctionne pas si bien que ca.[^] # Re: Documenté ou pas, ce sera non!
Posté par Anonyme . Évalué à 1.
Parce que
fichier.oggn’est pas écrit correctement.Mais je te parie qu’on peut faire
cat fichier.txt > /dev/dspet jouer la 42e symphonie.[^] # Re: Documenté ou pas, ce sera non!
Posté par ookaze . Évalué à 5.
Ce débat est complètement inutile et uniquement par des gens qui résistent au changement sans jamais lire ce qu'on leur explique ou chercher à se documenter.
Parce qu'en fait, on peut tout à fait avoir à la fois journal et un autre système de log sur son système.
Mon rsyslog fournit toujours les logs comme avant (fournies via journal), et journal fonctionne en parallèle. Journal fournit simplement plus d'infos que mon rsyslog, et la seule raison pour laquelle je ne l'ai pas encore jeté (rsyslog) c'est uniquement parce que journal ne gère pas le protocole réseau syslog.
Donc où est le problème ?
[^] # Re: Documenté ou pas, ce sera non!
Posté par Misc (site web personnel) . Évalué à 6.
Le souci, c'est que les gens savent pas lire, ou prenne pas le temps ( ou simplement n'ont pas le temps )
.
D'un coté, on a un système qui évolue vite, au point que ça dépasse presque la capacité d'absorption d'un humain, sauf si il passe son temps à faire de la veille. De l'autre, on a des gens dont le temps libre diminue ( famille, travail ), et qui applique face au changement la stratégie de survie classique de "si ça marche, faut pas toucher, j'ai investi du temps".
Personnellement, je pense que les gens semblent oublier les racines du libre, la recherche en informatique. Stallman était chercheur, et son but était de faire en sorte que le savoir ne soit pas privatisé, certes, mais ne soit pas privatisé pour qu'il puisse continuer à faire son taf, qui était la recherche. Et la recherche, ça vient par l'expérimentation, l'essai de nouvelles choses. Et c'est sur la base de ce genre d'éclairage qu'on voit que le bazar est l'expression du bouillonnement créatif autour du libre.
Et que donc oui, les changements, y en aura encore d'autres, et si le but est d'avoir un système qui ne bouge plus, y a pas de souci, c'est du logiciel libre, vous pouvez le garder comme vous voulez. Si ensuite, le souci est de se retrouver tout seul, alors faut se dire "mais pourquoi pas assez de monde m'a suivi".
[^] # Re: Documenté ou pas, ce sera non!
Posté par rewind (Mastodon) . Évalué à 2.
Déjà, c'est pas bien de caricaturer ceux qui ne veulent pas de systemd et toutes ses extensions comme de vilains réactionnaires qui veulent vivre dans le passé. C'est une généralisation abusive. Rien ne dit qu'ils ne sont pas passés à Gnome Shell (pour reprendre un autre troll poilu).
Ensuite, je pense que le point important, c'est pas le changement ou pas, c'est surtout que Lennart nous a habitué à nous fournir des trucs pas finis qui gère certains cas particuliers mais pas des cas généraux (PulseAudio toussa). Et que son entreprise est une spécialiste des «révolutions» de technologies qui finalement finissent à la poubelle quelques années après (*Kit toussa), ou qui restent bugguées ou incomplètes pendant des années (NetworkManager toussa).
Il y a sans doute un juste milieu entre vouloir «révolutionner», surtout quand la révolution a lieu tous les 3-4 ans et vouloir une évolution soutenable (notamment par des admins qui gèrent des systèmes critiques dans certaines entreprises).
[^] # Re: Documenté ou pas, ce sera non!
Posté par claudex . Évalué à 6.
Ce que je ne comprend pas, c'est pourquoi (presque) toutes les distributions suivent si c'est si buggé que ça ? (ça marche pour PA, *Kit, NM, Systemd…)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Documenté ou pas, ce sera non!
Posté par barmic . Évalué à 2.
C'est aussi une question que je me pose.
Personnellement j'ai tendance à faire confiance aux mainteneurs de la distribution que j'ai choisi. S'ils font un choix, il y a probablement de bonnes raisons même si pour mon cas ça complique un peu et que je ne vois pas forcément de mon point de vu l'intérêt.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Documenté ou pas, ce sera non!
Posté par rewind (Mastodon) . Évalué à 2.
Personnellement (j'insiste sur ce mot, c'est mon avis et je le partage, je ne sais pas si c'est exact), je pense que la cause principale est RedHat. Redhat a une telle emprise sur une quantité non-négligeable de projets libres, dont GNOME, qu'elle peut «imposer» les technos qu'elle veut. Je met imposer entre guillemets parce que c'est plutôt proposer mais comme en face, il n'y a personne avec la même puissance (notamment le même nombre de développeurs), il n'y a pas d'autres propositions.
Si on prend l'exemple de NM, au départ, ça part d'une bonne idée et d'un besoin réel du desktop. Puis ça grandit, ça s'intègre à GNOME, et du coup, les distribs sont obligés de suivre, ainsi que les autres DE. Y a-t-il des alternatives ? Oui, il y a wicd, et il me semble qu'à une époque, on pouvait utiliser wicd sur KDE à la place de NM, mais maintenant, je crois qu'on ne peut plus, tout le monde s'aligne parce qu'un des DE (par défaut sur de nombreuses distribs) a fait un choix unique et donc, pour simplifier la maintenance des autres, on abandonne les alternatives.
Et pour systemd, ça a l'air de se diriger vers la même chose : RH participe à GNOME, utilise des fonctionnalités propres à systemd (oui, c'est qu'une interface DBus qui peut être implémentée par d'autres, n'empêche que systemd est pour l'instant la seule implémentation), et du coup, les distribs se retrouvent obligées de suivre.
On pourrait aussi reparler de FreeDesktop qui n'est qu'une grosse blague sachant que toutes les technos venant de KDE sont rejetés (ou pas implémentées par GNOME) et toutes les technos venant de GNOME sont imposés (et implémentées dans KDE, même s'il y avait un existant mieux).
Bref, personne n'est menacé à coup de fusil, c'est beaucoup plus subtil que ça. À mon sens, c'est juste de la stratégie industrielle (toujours être le premier sur les technos pour avoir une longueur d'avance sur les concurrents), rien de plus.
[^] # Re: Documenté ou pas, ce sera non!
Posté par xcomcmdr . Évalué à 4.
Non, upstart l'implémente aussi dans Ubuntu.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Documenté ou pas, ce sera non!
Posté par Anonyme . Évalué à 1.
Peut-être qu'il y a un manque à combler quelque part et que les solutions qui sont proposés paraissent miraculeuses.
[^] # Re: Documenté ou pas, ce sera non!
Posté par Zenitram (site web personnel) . Évalué à 1.
Je t'en prie, aide les autres à remettre à leur place ceux qui balancent des "arguments" des plus grossiers.
Parce qu'il peut bien y avoir des arguments qui posent réellement problèmes, mais aujourd'hui, ils sont noyés dans des bizarreté, dommage.
[^] # Re: Documenté ou pas, ce sera non!
Posté par rewind (Mastodon) . Évalué à 2.
Il y a des admins qui ont des problèmes très concrets qu'ils ont exposés ici et dans d'autres article précédemment et qui n'ont jamais eu de réponse. Et j'ai vraiment la flemme de me replonger dans cet océan de trolls pour les retrouver.
[^] # Re: Documenté ou pas, ce sera non!
Posté par FantastIX . Évalué à 0. Dernière modification le 22 octobre 2012 à 20:41.
Dans ce cas, je me demande pourquoi les concepteurs de UNIX n'ont pas foutu tous leurs logs en binaire depuis le début? Cette discussion stérile serait moins gonflante d'hyprocrisie et on en serait quitte. Enfin, c'que j'en dis moi…
J'ai dit "critique" aussi. Ta déduction est un peu hâtive; lastlog (par exemple) est pas aussi critique que messages. Mais bon, je te l'accorde, YMMV.
[^] # Re: Documenté ou pas, ce sera non!
Posté par wismerhill . Évalué à 8.
Par facilité. C'est beaucoup plus simple de balancer du texte quelconque dans un fichier (en ajoutant le timestamp en début de ligne quand on a de la chance) que de faire les logs dans un format bien contraint qui oblige à anticiper ce qu'on voudra y mettre.
[^] # Re: Documenté ou pas, ce sera non!
Posté par Misc (site web personnel) . Évalué à 4.
En fait, visiblement, syslog vient de sendmail, donc des années 80 ( cf wikipedia ).
Par contre, utmp semble être la depuis le début :
http://man.cat-v.org/unix-1st/5/utmp
( issue du projet "Unix First Edition Manuals" http://man.cat-v.org/unix-1st/ )
Donc je pense que les concepteurs d'unix au début n'ont pas prévu de faire des logs dans des fichiers textes, qui sont arrivés après. Donc oui, soit c'était pas prévu, soit c'était prévu en binaire.
Ensuite, peut être que les sacro-saints 40 ans d'héritages d'Unix, ça commence dans les années 80 et je sais pas compter. Peut être aussi qu'on devrait rajouter sendmail et m4 dans l'héritage Unix, et bruler les impies comme Wietse Venema et Philip Hazel.
[^] # Re: Documenté ou pas, ce sera non!
Posté par barmic . Évalué à 10.
Pourquoi les logiciels ont des bugs et pourquoi est-ce qu'on sort sans cesse de nouvelle version ? Il suffirait de coder toutes les fonctionnalités sans bug dès le début.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Documenté ou pas, ce sera non!
Posté par Zenitram (site web personnel) . Évalué à 1.
Mais pourquoi donc le monde évolue? Faudrait le figer (mais pas sûr qu'on ai Internet avec les personnes qui se posent la question de savoir pourquoi changer… Ni un ordinateur "pourquoi les concepteur du papier n'ont pas inventé avant l'ordinateur?")
[^] # Re: Documenté ou pas, ce sera non!
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 7.
unsigned char address[4], et roule ma poule"[^] # Re: Documenté ou pas, ce sera non!
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 6.
Même en plus de 25 ans d'utilisation d'Unices divers, je découvre en permanence de nouvelles choses.
[^] # Re: Documenté ou pas, ce sera non!
Posté par Maclag . Évalué à 4.
Ben quoi? Je lis ça fastoche et je résous tous les problèmes en patchant directement les binaires à la main avec un éditeur hexa. Suffit d'avoir le coup d'oeil, voilà tout!
[^] # Re: Documenté ou pas, ce sera non!
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 2.
Miranda, elle, c'est une wargirl du binaire, elle ré-écrit les bits sur le disque dur avec une aiguille de boussole : pôle nord -> 1, et pôle sud -> 0.
[^] # Re: Documenté ou pas, ce sera non!
Posté par Michaël (site web personnel) . Évalué à 2.
J'ai aussi essayé plusieurs et le plus pratique reste tout de même synchroniser la rotation de l'aiguille de boussole au spindle motor au moyen d'un bracelet de caoutchouc de bonne qualité.
# Journal en fichier binaire vs fichier plat
Posté par azerttyu (site web personnel) . Évalué à 2.
Bonjour
Petite question suite à la lecture de la dépêche et de ses commentaires, je ne vois que personne n'explique ou ne s'interroge sur les avantages et inconvénients entre les 2 formats.
Je comprends, en tant qu'humain, qu'un fichier plat est facile à relire (relativement) et je comprends, en tant qu'application, qu'un fichier binaire peut faciliter l'intégrité de l'information saisie mais bon je pense que cela va plus loin.
Et encore sur le terme binaire j'ai des doutes sur sa nature au vu des commentaires qui ne parlent au final que d'une archive.
Enfin si vous pouviez éclairer ma lanterne, je suis preneur.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par rewind (Mastodon) . Évalué à 4.
Avant le fichier texte était la norme et le fichier binaire l'exception. D'ailleurs, les formats binaires n'avait pas trop la cote (GConf toussa). Et puis il y a eu XML et on s'est aperçu qu'un format texte pouvait être aussi dégueulasse qu'un format binaire. Du coup, maintenant, les (nouveaux) tenants des fichiers binaires conchient les défenseurs du vénérable fichier texte à coup d'argument moraux du genre «vous ne voulez pas évoluer». Ces derniers se défendant à coup d'arguments moraux du genre «vous ne comprenez rien à Unix». Mais à mon avis, toute cette histoire texte/binaire, c'est juste pour renouveler les sujets à troll.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par barmic . Évalué à 2.
Puis c'est sympa de voir tout le monde grimper sur leurs grands chevaux pour te regarder de haut avec un ton dédaigneux.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par GnunuX (site web personnel) . Évalué à 3.
En admettant que l'ascii ne soit pas du binaire (même si mon disque dure me dit qu'il ne sait stocker que du binaire … mais admettons ce n'est qu'un disque dur), sur quoi tu te bases pour dire que les concepteurs Unix avaient comme précepte fondateur "tout est ascii" ?
Par contre, trouver que le XML Gconf (qui fait du gconf encore aujourd'hui d'ailleurs ?) est moins lisible que les macro M4 du fichier de configuration de Sendmail (à moins que sendmail ne soit pas une application suffisamment Unix pour toi) … ca me laisse songeur.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par barmic . Évalué à 2.
Trompé de bouton ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par rewind (Mastodon) . Évalué à 3.
Je vais juste répondre sur ce point, je laisse le reste aux trolls genre Zenitram que je trouve très très en forme sur cet article :D
Historiquement, il existait une différence entre texte et binaire. On en trouve des traces dans deux endroits (au moins) :
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par GnunuX (site web personnel) . Évalué à 3.
Comme tout les sous-ensembles, il est possible de transférer un fichier ASCII en BINARY mais pas l'inverse. Donc cela n'invalide rien.
En fait ce qui est le plus génant dans la polémique "BINAIRE" <> "TEXTE" c'est qu'en réalité c'est ASCII <> NON-ASCII.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Zenitram (site web personnel) . Évalué à 1.
Et du coup ton texte n'est plus texte (ben oui, le "format" texte de l'OS de destination n'est pas le même, donc c'est du binaire maintenant vu que le format texte n'est pas respecté! :) )
Oh si… ton client FTP ne te prévient pas que tu fais une grosse connerie, du coup ton fichier binaire est pourri, et avant que tu comprennes pourquoi il ne marche plus, tu y passes un moment.
Zenitram, qui s'est amusé à débugger un fichier vidéo, et qui a passé du temps à comprendre que ce qui faisait "sauter" la vidéo, c'était des octets dédoublés à cause d'un transfert FTP en mode texte pour un fichier MPEG. Que du bonheur ce genre de truc vicieux, ça donne des envies de meurtre de celui qui a eu l'idée de mettre ce genre de chose dans un protocole de transfert de fichier.
Si il n'y avait que ça de génant!
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par ckyl . Évalué à 1.
Le plus étonnant c'est qu'il y ait encore des gens qui prennent la peine de lui répondre. Ca ça m’impressionne !
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à 1.
Y a pas mieux pour un entraînement personnel ;-) .
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à 0.
On pourrait en dire autant (le ton dédaigneux) de tout ceux qui rejettent sans vergogne des concepts fondamentaux, qui ont fait la base de notre système préféré. Je pars du principe que si troll il y a, c'est qu'il y a matière à discussion et que le sujet est loin de faire l'unanimité.
La plupart des concepteurs et des utilisateurs se sont accordés sur les bienfaits du texte et, aujourd'hui, dans des cas précis comme celui-ci, ça génère visiblement de lourdes discussions et des prises de tête. Ce que j'en conclus c'est que s'il y a matière à discuter (à ce point-là, surtout), c'est que la mise en œuvre n'est ni optimale ni mûre.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Thomas Douillard . Évalué à 4.
Il y a tellement de matière qu'on en est rendu à discuter sur la discussion, c'est dire :)
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à 0.
Disons que le bruit que tout ceci génère est autant de signaux qui donnent à réfléchir sur le projet dans sa globalité, non? La résistance au changement (ou, disons, la contestation pour la contestation) ne doit pas être la seule et unique raison de protester.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Zenitram (site web personnel) . Évalué à 2.
J'attend des arguments. Des vrais, pas ceux d'une résistance au changement uniquement.
Parce que désolé, mais la, dans les journaux LinuxFr, je n'ai pas vu un seul argument qui ne vient pas de la résistance au changement, ils se font tous descendre avec des contre-exemples en bonne et due forme (et non, ces réactions avec démonstration ne viennent pas de mon imagination, d'autres se font plaisir aussi).
Alors : de vrais arguments s'il vous plait, merci d'avance.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à 1.
Je confirme: t'es vraiment en pleine forme :D .
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par barmic . Évalué à 3. Dernière modification le 23 octobre 2012 à 14:04.
Ne te sens pas visé particulièrement je parlais des deux parties.
Tu es un adepte du consensus ? Tu n'a jamais entendu parler des « gentils dictateurs » (comme Linux Torvald par exemple) ? Je ne parle pas pour ce cas précis, je parle d'une manière générale.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à 1.
Tracasse, je ne parlais qu'en général, me sentais pas visé. ;-)
Oui. Enfin, oui, c'est ce que je souhaiterais. Mais ce n'est pas exactement ce qui doit ressortir de mon jugement ici. Ce qui m'intéresse ici, c'est ce que j'observe, en plus de la “poussée” de systemd. Ce que j'observe de la situation dans le cas de systemd est qu'une aussi grosse discussion avec autant de désaccords ne peut pas se résumer aussi simplement que par une phrase assassine jugeant les contestataires. À partir du moment où un tel projet génère autant de controverse, on ne peut raisonnablement n'écouter qu'un seul côté et rejeter l'autre. Wayland, par exemple, constitue une vraie révolution en soi et je pense (c'est mon avis aussi, je peux me tromper) que l'opposition, si elle existe, est bien plus discrète, qu'on ne fait pas autant de bruit là-dessus.
Bien sûr. Et comme j'ai mon opinion là-dessus aussi, je préfère me ranger du côté d'un dictateur bienveillant… que je considère éclairé, ce qui est le cas, pour moi, de Linus Torvalds, par exemple. Mais a) ce n'est encore une fois qu'une opinion, b) la définition de “éclairé” varie d'une personne à l'autre et c) … je sais plus.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par claudex . Évalué à 5.
Tu réagis comme s'il y a avait un consensus sur les autres systèmes d'init (il n'y en a pas qu'un d'ailleurs). Ce qui n'est pas le cas car il n'y avait pas d'article régulièrement pour dire "breakng news: les init sont toujours les mêmes". La preuve que les init précédents ne faisait pas consensus était les piques que se lançait les utilisateurs des distributions sur le sujet (je pense aux archer notamment).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à 2.
Non. Je réagis par rapport aux commentaires que j'ai pu voir. Le sujet est visiblement sujet à trollerie, c'est ce que je constate. Je n'imaginais pas qu'il y avait consensus dans les autres systèmes.
Non, ma réaction est uniquement sur les réactions… face aux réactions. Ce que je lis est relativement tranché (c'est encore mon opinion) et j'ai l'impression qu'on a vite fait, par exemple, de ranger les contestataires du côté de ces personnes qui sont réfractaires au changement quel qu'il soit. Point.
Ce que je perçois des commentaires est tout autre. Le passage à systemd, générant beaucoup de bruit et parmi les arguments des contestataires, j'en lis qui sont fondés, selon moi. Il s'agit ici d'un débat de fond, visiblement. Et dans un débat de fond, ce ne peut être qu'opinion et point de vue contre opinion et point de vue.
Tu m'apprends qu'il n'y avait pas consensus. Ça ne me surprend pas outre mesure mais je suis bien incapable d'avoir la moindre opinion là-dessus. Par contre, ce qui en a résulté non seulement me convient mais ce que j'en connais me paraît logique et bien fondé, notamment en ce qui concerne l'utilisation du texte.
Mais tu sais, l'utilisation du texte n'est pas quelque chose que j'ai appris avec UNIX. C'est un principe que j'ai appris et défendu peu à peu au fil des ans, principalement pendant mes longues années sous Windows. UNIX n'a tout simplement fait que mettre des définitions et des standards par rapport à mes attentes. Aujourd'hui ces standards répondent à des valeurs que je me suis forgées et le binaire, dans le cas particulier de journaux, me paraît une énormité en raison de l'utilité de ces journaux.
L'argumentation «pour le binaire» que je lis dans les commentaires sur LinuxFR ne me convainc pas et ne me convaincra jamais en raison de ce que l'on est censé faire avec des journaux. Si on parlait de bases de données, passe encore (et d'ailleurs c'est déjà fait). Mais dans le cas d'archives d'événements consignés que sont les journaux, l'argumentation autour des avantages du format binaire me paraît surdimensionnée par rapport aux besoins.
Et dans mon cas personnel, comparant Windows et Linux, les journaux de Linux m'ont aidé bien plus que ne l'ont jamais fait ceux de Windows. Les journaux UNIX pourraient sans doute être améliorés mais je suis convaincu que cette amélioration pouvait se faire sans passer par le binaire.
Ceci dit, je suis bien conscient qu'une seule personne ne peut pas nécessairement maîtriser tout les aspects. Et on a aussi tendance à voir le tableau par le petit bout de sa lorgnette personnelle. Je ne pense pas faire exception.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par claudex . Évalué à 3.
Tu parle du format texte d'Unix mais il y a des logs binaires depuis longtemps avec /var/log/wtmp et je n'ai pas vu beaucoup de critique sur le sujet.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à 2.
Personnellement, je placerais wtmp plutôt dans /var/cache que /var/log . Et s'il se trouve dans /var/cache, je n'ai pas d'objection quant à son format.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par wismerhill . Évalué à 2.
Non, /var/cache c'est, comme le nom l'indique, pour des données qu'il est couteux de re-générer ou re-télécharger, mais il est possible de le faire si les données sont supprimées.
Si tu supprime wtmp, l'information est perdue.
/var/lib serait éventuellement un emplacement acceptable (c'est pour les données persistantes).
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Zenitram (site web personnel) . Évalué à 2.
Je t'en prie, démontre.
Oups, dès qu'il faut prouver ses préjugés, plus personne… Il y a en a qui code et démontre que ça peut marche, lui.
En attendant ta démo, ben il faut seulement considéré ton préjugé comme une idée à démontrer, rien d'autre.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à 2.
J'aime bien ta tactique :D . Si je ne réponds pas dans les cinq minutes, c'est que je manque d'arguments, c'est bien ça? Ça t'ennuie si LinuxFR et répondre à tes attaques personnelles en particulier ne sont pas mes préoccupation principales?
Si tu veux que je te réponde, vu que tu as l'air convaincu du bien fondé des journaux en binaire, expose-moi ton argumentation et je tâcherai d'y répondre point par point. Ça te conviendrait?
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Anonyme . Évalué à 3.
Tout simplement journalctl qui utilise des journaux en binaire existe et fonctionne. L'equivalent de journalctl qui fournirait le meme type de fonctionnalités en utilisant des journaux en texte pur n'existe pas à l'heure actuelle.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à 1.
Mais … et syslogd?
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Anonyme . Évalué à 2.
"qui fournirait le meme type de fonctionnalités". Donc pas syslogd.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par jyes . Évalué à 3.
J’aime bien la comparaison avec Wayland, elle résume bien l’état des lieux. Wayland est très critiqué aussi (enfin Weston plus que Wayland) mais ses développeurs le présentent comme le futur et pour le moment personne ne pousse à son adoption massive. Du coup, ses limitations sont acceptables et il est permis d’espérer qu’elles soient résolues avant la migration totale depuis X vers Waylang. Maintenant, la version 1.0 vient juste de sortir, elle a mis un certain temps et a évolué en fonction des critiques.
À mon avis Systemd est le futur aussi. Sauf qu’il est déjà proposé comme une solution magique qui résout tous les problèmes du passé alors qu’il n’arrive pas encore à rivaliser avec les solutions du passé. Le chiffrement, les partitions séparées, le bricolage comme des gorets dans les scripts d’init, ça a ses limitations et une uniformisation autour d’outils puissants comme les cgroups est très bienvenue, mais Lennart a beau être un génial génie, son jouet aurait fait couler moins de bits s’il avait été proposé d’abord comme une alternative en développement et alléchante avant de vouloir révolutionner l’usage d’une dizaines d’outils hérités de dizaines d'années d’Unix.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par claudex . Évalué à 3.
Systemd est utilisé par les distribution bleeding edge (Fedora, Arch) ou proposé de manière alternative (Debian). Et, grosse différence avec Wayland, il ne casse pas les applications fournies par la distribution (raison pour laquelle Wayland ne peut pas être utilisé tout de suite).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à 1.
Sans doute. Mais en tous cas, l'adoption se fait en douceur et il y a une prise en compte des critiques reçues, visiblement et le produit évolue en fonction de ça.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Misc (site web personnel) . Évalué à 7.
Et pour systemd, y a pas ?
Va voir le bugzilla, regarde les RFE.
Par exemple, quelqu'un a demandé le format du journal, la doc a été écrite ( heck, c'est même le titre de la dépêche ). L'option --until/--since a été proposé sur les listes fedora. Le fait de faire une rotation par date et pas par taille de fichier, ça a été demandé sur les listes Fedora.
Je vais pas faire la liste des choses ou les demandes ont été prises en compte, mais je pense que tu confonds "ma demande n'a pas été accepté" avec "personne n'a été écouté". Les gens peuvent dire non.
Et si la demande est "journal devrait faire des logs en ascii", c'est le boulot de rsyslog. C'était très clair dans la première annonce, et ça me semble parfaitement logique d'un point de vue de l'architecture. A la base, journald n'était la que pour servir systemd ( les lignes de logs qu'on voit quand on fait systemctl status, ça vient de la ). Ensuite, l'idée a été d'exposer ça pour que les utilisateurs puissent le lire. Puis des gens se sont dit "tiens, on peut faire des tas de trucs qu'on fait pas facilement avec du texte". Comme par exemple, afficher la date dans la timezone local sans avoir à passer des tonnes de regexp pour parser et convertir la date, ou afficher les couleurs sur la base de la sévérité du message dans la sortie. Ou le fait d'afficher les données de 2 unités systemd mais pas des autres ( genre bind et dhcp ), correctement mélés ( chose un chouia plus compliqué avec des fichiers et avec des corners cases moisi, comme "oups, le tri lexical fait de la merde entre "Oct 30" et "Nov 01" ).
C'est comme git vs svn/cvs, le fait d'avoir un moyen rapide de faire certains traitements change la donne et offre des possibilités. Faire un svn rebase, ça serait vachement plus long et couteux. Faire un svn grep serait difficilement envisageable. Avoir changer a donne et fait un truc ultra rapide rends les choses différentes.
Avec journald, c'est pareil. C'est rien de différent, mais le fait d'avoir un fichier binaire, ça rends certains algos possibles alors que ça serait couteux autrement.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à 0.
Difficile de le croire en raison de tout le bruit, déjà rien que ce journal en mode binaire génère… Et ce n'est que sur un point.
Je suis d'accord avec toi. Toutefois je n'ai pas fait de demande spécifique à ce sujet. Le fait est que, selon moi et je ne suis pas le seul, le binaire pour un journal n'est pas approprié.
Ce n'est pas parce que le format de date du journal est inadéquat qu'il faut passer au binaire. Il suffisait de changer le format de cette date.
Et au fait, dans le fichier binaire, little ou big endian? (Si on se pose la question du jeu de caractères avec le texte on peut aussi se poser la question de l'orientation des données binaires. Avec toutes les conséquences que ça a aussi… Je dis ça simplement pour illustrer que si le binaire apporte ses avantages par rapport au texte, il apporte aussi ses inconvénients, que le texte n'a pas.)
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Anonyme . Évalué à 2.
Oui oui, il suffirait de faire autrement. Sauf que personne ne le fait. Quel dommage que ces gens qui savaient parfaitement mieux que tout le monde ce qui devrait etre fait ne soient pas eux meme developeurs ou n'aient pas le temps de s'en occuper !
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Misc (site web personnel) . Évalué à 4.
Au vue des cris d'orfraie poussé à l'idée de mettre un système de log à coté de syslog ( car comme dit partout à commencer dans l'annonce, journald passe les logs à syslog pour compatibilité et ne compte pas retirer ça ), j'ose pas imaginer les cris si on touche directement à syslog au point de rendre son format incompatible avec les outils existants.
"The on disk format uses exclusively 64bit LE (little endian) offsets," cf l'annonce
https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3MSTs
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à -1.
Je ne vois toujours pas pourquoi syslog n'aurait pas pu être forké, repris ou n'importe quoi d'autre, par exemple, toujours dans le même but et, comme on dit, dans l'esprit du libre: ajouter les fonctionnalités qui lui manqu[ai]ent et modifier ce qui devait être modifié. Il ne s'agit pas de toucher à syslog mais de créer un nouveau gestionnaire de journal avec du code qui s'en inspire.
Je savais ça. J'ai posé la question, pas pour qu'on me donne la réponse mais pour attirer l'attention sur le fait que, si le texte et sa mise en forme passent par des questions du genre de ce qui a été discuté, le binaire a *aussi* son lot d'interrogations. (Je n'ai parlé que sur l'ordre des octets dans mon commentaire précédent.)
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Zenitram (site web personnel) . Évalué à 0.
L'avantage du libre, c'est que tu peux garder tes vieux trucs qui marchent au poil, en forkant.
L'inconvénient du libre, c'est que tu ne peux pas obliger les gens à maintenir ton truc bordélique.
Bref : tu es libre, et les autres aussi!
J'ai l'impression que ce qui gène le plus, c'est de se rendre compte que les "la base de notre système", c'est foireux, et que plus personne n'a envie de se faire chier à maintenir la chose… Je trouve rigolo de voir que des "utilisateurs" râlent, mais pas foule pour maintenir. Étonnant… Libre, libre, libre!
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à 1. Dernière modification le 23 octobre 2012 à 15:06.
Si tous les utilisateurs étaient aussi des développeurs, cette remarque paraîtrait moins sournoise à mes yeux. Mais c'est, je le reconnais, ce qu'on lit le plus souvent: “tu es libre de forker si tu veux”. Le fait est qu'il y a beaucoup plus d'utilisateurs que de développeurs. Cette remarque me paraît donc un rien hypocrite (ce n'est que mon avis, bien sûr). Il serait plus juste/correct de dire: “n'importe quel développeur a la possibilité de faire un fork s'il le désire… si toutefois il s'en sent capable ou à la hauteur de la tâche.” Je ne discute pas les principes du logiciel libre, loin de là. J'essaie juste d'être précis.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par claudex . Évalué à 4.
Les utilisateurs peuvent s'unir pour payer (ou trouver un moyen de motiver) un développeur qui ferra le boulot à leur place.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Zenitram (site web personnel) . Évalué à 2.
Soyons précis : tu veux que des mecs fassent un boulot qu'ils ne veulent pas faire.
Tu es libre, ça ne veut pas dire libre seulement de développer. Tu peux aussi te cotiser pour payer un mainteneur. Une limite à la chose toutefois : il faut que ton vieux truc super-utile soit utile à suffisamment de personnes. Mais ce n'est pas la faute des autres, juste de toi qui ne veut pas t'adapter…
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à -1.
Non. J'ai dit que l'affirmation « si t'es pas d'accord, tu peux forker » revient à supposer que tous ceux qui manifestent leur désaccord sont soit des développeurs soit capables de coder. Ce que tu me racontes là n'a absolument rien à voir avec ce que j'ai exposé. Et il y a autant à discuter sur l'affirmation « tu peux aussi bien trouver des développeurs qui le feront pour toi ». Si c'est pas foncièrement faux, ça soulève encore d'autres questions qui n'ont rien à voir avec ce que j'ai dit.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Zenitram (site web personnel) . Évalué à 0.
Il peuvent payer un développeur.
Ils peuvent apprendre.
etc…
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par ckyl . Évalué à 2.
Non. Il en suffit d'un. Un seul.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Zenitram (site web personnel) . Évalué à 0.
Même pas : il suffit d'une seule personne même non développeur (elle paiera un dev, rien de bien méchant si c'est réellement utile).
Bref : tout le monde peut le faire, si c'est utile.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Misc (site web personnel) . Évalué à 4.
En même temps, soyons clair, si on t'a vendu le logiciel libre comme étant la liberté pour les utilisateurs, on t'a mal vendu le truc.
Sur les 4 libertés de la GPL et de la FSF, tu as :
- la liberté d'étudier ( pour contributeur )
- la liberté d'utiliser ( pour contributeur et pour non contributeur )
- la liberté de distribuer ( pour contributeur et pour non contributeur )
- la liberté d'améliorer et de distribuer ( pour contributeur )
On note quand même que la moitié des 4 libertés sont juste pour les contributeurs, et donc que sur les fondements du libre, les non contributeurs profitent moins du libre.
Donc oui, ceux qui utilisent sans contribuer, ils sont dépendant des autres. Mais c'est uniquement leur faute, car la seule chose qui les retient, c'est eux mêmes.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par rewind (Mastodon) . Évalué à 1.
C'est vrai ça, pourquoi tout le monde ne contribue pas ? Vraiment les gens, je me demande bien ce qu'ils peuvent faire d'autre dans leur vie ? C'est un scandale !
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Anonyme . Évalué à 3.
Ben y a pas de problème à pas contribuer. Mais dans ce cas la on va pas expliquer à ceux qui contribuent que ce qu'ils font est nul et qu'on sait mieux qu'eux ce qui devrait etre fait et comment ca devrait etre fait, en restant les bras croisés.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Misc (site web personnel) . Évalué à 3.
Si je veux corriger sun/oracle java truc ( la version proprio ), c'est de l'ordre du peu probable, car oracle fait tout pour que je puisse pas, notamment via la license.
Si je veux corriger openjdk, les codeurs sauf erreur de ma part ne m’empêchent pas de le faire. Les seules choses qui l’empêche, c'est de mon coté. Comme tu dit, le fait de pas avoir de temps, de pas avoir les compétences, et que ça soit ma faute directement ( genre j'ai passé mon temps au bar au lieu d'aller en cours de C, ou j'ai passé mon temps dans un assoce qui sauve des bébés phoques au lieu d'apprendre le C ) ou indirectement ( je me suis fait rouler dessus et j'ai passé 20 ans dans le coma ), ça reste que dans une relation codeur/demandeur, les soucis restent du coté du demandeur, d'ou "sa faute". Certes, j'aurais pu trouver sans doute mieux comme formulation.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à 3. Dernière modification le 23 octobre 2012 à 14:26.
Le format texte est effectivement universel. Quelle que soit la plateforme, le fichier peut être lu tel quel, sans interpréteur … à condition de respecter le jeu de caractères, bien sûr, mais même sans ça un fichier texte dont les accents, par exemple, apparaissent "bizarrement" reste lisible par n'importe quel humain sur n'importe quelle machine.
Un format binaire demande un outil pour le codage, un pour l'affichage, un pour l'édition. Parfois ce sont trois outils distincts, parfois ils sont combinés. Mais sans outil, pas de lecture possible. Sans compter que le format du fichier doit être documenté et, pour être lu sur n'importe quelle plateforme et être à égalité avec le texte, il faudrait que le même outil soit disponible sur toutes les plateformes en même temps.
Le texte garanti la transparence de l'information: une modification est visible directement. Un fichier binaire rend opaques l'information et les transformations de sa structures.
Avec du texte, la probabilité de trouver un éditeur ou simplement un outil pour le visualiser sur n'importe quelle plateforme est proche de, peut-être même égale à 100%. (Commande cat sous UNIX, type sous Windows etc.) Pour un format binaire, arbitraire qui plus est, on en est loin. À moins de porter l'outil de visualisation sur toutes les plateformes, ce qui demande malgré tout quelques efforts. À chaque format binaire particulier son outil de visualisation et/ou d'édition. Avec le format texte, on est déjà dans cette situation, aucun effort supplémentaire n'est requis.
Le format binaire apparaît peut-être plus structuré de nature mais il est aussi facile d'avoir un fichier binaire mal foutu qu'un fichier texte bien structuré. De plus, dans le cas du fichier binaire, la structure est opaque, invisible ou non évidente à la personne qui le visualise.
Il n'est pas difficile non plus de structurer les fichiers texte. Le CSV en est un exemple. XML aussi mais largement conspué en raison du bruit qu'il introduit à travers ses balises. Ce type de fichier est plus adapté aux transfert entre machines, en plus de son avantage à pouvoir être lu et corrigé par un être humain si c'est nécessaire. Les fichiers .ini en sont un autre exemple, tout comme les fichiers .desktop. Ces derniers sont à comparer avec les raccourcis .lnk de Windows (qui ne font pas que ça, bien sûr mais leur structure opaque les rend peu confortable à la manipulation manuelle). De plus, la structure particulière du fichier .ini le rend avantageux pour des relations entre sections, de sorte qu'il est possible d'arriver, comme avec un fichier XML, à un niveau infini d'imbrications logiques.
C'est tout ce que j'ai en tête pour le moment.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par wismerhill . Évalué à 2.
Essaie de lire des fichiers texte codés dans une table de caractère (un truc obscur comme UTF-8) sans avoir l'interpréteur de cette table de caractère (ton système est installé en ISO-8859-1 et rien de plus), ton terminal ne va pas apprécier ce que cat va lui balancer…
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Batchyx . Évalué à 1.
N'importe quel système d'il y a moins de 10 ans possède un navigateur web, et un navigateur web, c'est capable de lire l'UTF8, l'ISO-8859-1 et même des codepage de merde du genre cp850 pour certains.
Va falloir te mettre à jour, un peu.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Zenitram (site web personnel) . Évalué à 1.
yep, surtout quand le code page est annoncé dans le header HTTP.
Attend… Ah oui, dans un fichier texte, pas de code page annoncé! Fail.
Va falloir te mettre à jour sur comment ça marche dans la vraie vie (oui, j'ai beaucoup de code pages différents dans mes fichiers, et l'UTF-8 a été une révolution, pas encore partout par contre, et avec une évolution dans la douleur avec les BOM/pas BOM et le manque d'info de code page), un peu.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Batchyx . Évalué à 0.
Tu le sélectionne dans le menu, l'encodage à utiliser. Même la merde propriétaire de Microsoft peut fait ça, sans parler des navigateurs modernes qui savent detecter l'encodage d'un fichier texte sans autre headers que
Content-Type: plain/text. De toute façon, si tu connais pas l'encodage de ton fichier de log, c'est que ce n'est pas du texte.Et sinon, juste comme ça, je répondait spécifiquement à :
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par wismerhill . Évalué à 3.
Ah oui, les outils Unix standards, cat, grep et un navigateur web …
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Zenitram (site web personnel) . Évalué à 1.
Ah ah ah… conneries.
Allez : quel est le code page? quel est la langue d'écriture? Quel est le code de retour à la ligne (rappel : il y a 3 formes qui se baladent dans le monde)? Quel délimiteur? Quel format pour la date (10/04/2012, c'est 10 avril ou 4 octobre)? avec ou sans BOM qui va planter quelques logiciels si présent mais aussi si pas présent (ça dépend du logiciel)?
Toi, tu n'as pas dû sortir bien loin pour oser sortir une telle énormité sur les fichiers texte.
Les fichiers texte, j'en soupe souvent, et c'est juste la grosse merde (d'une à lire surtout quand c'est dans une langue que je ne comprend pas du tout, de deux c'est impossible à automatiser facilement)
cat, more, n'importe quel lecteur de texte interprètent… Tu as toujours un interpréteur. Plus ou moins doué (par exemple, la plupart des intépréteurs ne sont pas capables de te garantir que la date est correcte, cf JJ/MM vs MM/JJ)
Bref, tu racontes n'importe quoi. Juste que tu n'as pas l'envie de changer d'interpréteur pour un qui sache réellement interpréteur, pas juste te laisser deviner (et tu pries pour bien deviner)
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à 3.
Épargne-moi tes attaques personnelles s'il te plaît.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Zenitram (site web personnel) . Évalué à 0. Dernière modification le 24 octobre 2012 à 10:55.
Elles ne sont pas contre toi, mais ce que tu racontes, qui est faux, je t'ai posé des questions pour te démontrer pourquoi c'est faux.
Alors réponds aux questions sur le format de ton fichier texte, facile si c'est si universel que tu le dis, tu devrais avoir une seule réponse par question.
Pourquoi ne pas répondre aux questions?
Tu as dis un truc faux, j'y réagis, c'est tout.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à 2.
Je dis quelque chose avec lequel tu n'es pas d'accord ou contre lequel tu as une argumentation, rien de plus. Rien ne te permet de supposer quoi que ce soit sur ce que je sais ou ne sais pas. Quant à affirmer que ce que je dis est faux, ça reste malgré tout une opinion. Restons-en aux faits, veux-tu?
Je répondrai à tes questions. Je t'ai d'ailleurs proposé une manière d'y arriver dans un de mes commentaires. Je t'ai suggéré de lister tous les points que tu défendais, auxquels je répondrai un par un. Sois patient, par contre, je bosse, aussi.
En ce qui concerne l'universalité du texte, en quoi est-ce faux? En quoi, par exemple, le jeu de caractères entre-t'il en ligne de compte dans le fait que le texte fait partie des outils que l'humain manipule le mieux pour transmettre de l'information? Le texte est associé à l'écriture, apparue bien après les peintures, je te l'accorde. Mais l'humain a utilisé le texte massivement depuis pour transmettre l'information. Le texte est donc universel d'utilisation et le moyen le plus naturel aujourd'hui.
Admettons. jeu de caractères, codage, retour à la ligne… c'est le foutoir. Bon.
Mais en quoi journald apporte-t'il une solution par rapport à ça? Un bloc de texte reste un bloc de texte, non? Est-ce que journald convertit tout en ascii pur et dur? Ou bien a-t'on encore le choix de la langue dans les messages? Parce que, si c'est le cas, journald doit bien définir un jeu de caractère par défaut, non? Tiens, UTF8 sans doute? Donc si le journal, format texte, est en UTF8, il n'a pas plus d'inconvénients par rapport à ce qui est stocké en binaire dans journald, exact?
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Zenitram (site web personnel) . Évalué à 1.
C'est normé, déjà.
Et en binaire, si poussé au bout, une erreur n'est pas du texte, mais un nombre (avec table de traduction à côté pour qui veut faire du texte).
Tu as oublié de parler de la date (alors, 4 octobre ou 10 avril?)
bref, le binaire permet plein de choses, comme fournir des information localisées, et d'avoir un truc très précis. LE texte, c'est un fourre-toi quand tu veux reculer pour mieux sauter.
Ce qui me fait réagir est de voir autant de blocage sur "un log doit être texte", quand ce texte est absolument pas normé et et un bordel sans nom.
Alors, si le texte vous suffit, ok, corrigez donc tous les problèmes qui vont avec, ou alors journald répond aux besoins avec du bianire certes mais on s'en fout, c'est autant la merde binaire ou texte de toutes manières.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à 3.
Ce n'est pas pour te contrer par plaisir mais ce que tu exposes n'est que détails pour moi. Pourquoi? D'abord parce que, même si c'est un foutoir sans nom (je peux le concevoir), l'utilité des journaux (par rapport à ceux de Windows) est incontestable. Même si c'est un foutoir innommable, les informations qu'il contient sont précieuses et pertinentes, elles aident au dépannage, faut pas perdre ça de vue.
Le jeu de caractères? le journal binaire doit aussi en utiliser un, ça ne règle pas la question, comme je l'ai exposé. La date n'est pas dans un format stable et précis ou exploitable? Ok, pourquoi pas définir une API, dans ce cas? Les standards aussi, ça sert à ça.
Il n'est pas plus facile de «normer» du binaire que du texte. Tous tes arguments (pour le binaire) sont recevables mais s'appliquent aussi au texte. Le texte n'empêche pas sa normalisation. (Sinon quid de XML, des fichiers INI, qui sont déjà des exemples de formats texte normés?) Tout ce que le journal demande pour répondre à ces exigences est une normalisation, comme tu l'as dit. Fallait-il vraiment passer au binaire pour ça?
Il existe de nombreux formats de date, par exemple, dont ISO. Un format "YYYY-MM-DD hh:mm:ss[.ms]" n'aurait-il pas répondu à cette exigence? Et s'il faut faire des recherches plus sophistiquées, par exemple filtrer par intervalle de temps, on peut quand même y arriver avec sed ou gawk, même si c'est plus un casse-tête qu'autre chose. Mais c'est déjà faisable avec du texte, pas besoin de passer au binaire pour ça. Avec un fichier texte bien structuré, bien formaté, pas besoin de binaire. D'autant plus qu'il existe des versions de syslog qui permettent de stocker des lignes de journal dans une base de données, pour «des trucs très précis». Je ne me souviens plus si la date fait partie des arguments par contre. Mais quand bien même, faire une API pour ça me paraît plus sage que ce passage brutal et méchant au binaire.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 24 octobre 2012 à 13:25.
admettons face à cet argument de poids…
Pourquoi. Mais c'est pas fait. Je ne fais que constater.
Sinon, 20 octets à la place de 4, c'est d'un optimal (compressable, mais quand même)
Avec des si, on mettrait Paris en bouteille.
La, on a un truc qui a l'air de tenir la route, face à une théorie "on peut utiliser ISO"…
Et encore une fois, rien n'empèche de faire ta sortie texte avec journald… On fait, rien ne change vraiment pour toi.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à 2.
Tu m'as demandé de justifier mes arguments, ce que j'ai fait. J'ai renforcé mon raisonnement sur le fait que tout était possible sans passer par le binaire, c'était ça ta demande. Maintenant tu fais ce que tu veux de mon argumentation mais je pense avoir répondu à la plupart de tes questions. Que tu ne sois pas convaincu, soit. Je ne t'ai pas convaincu, tu ne m'as pas convaincu non plus. Alors restons-en là.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à 1.
Facile, hors contexte!
Exemple:
2012-10-21 12:33:43 solo kernel: scsi 9:0:0:0: Direct-Access Hitachi HTS541616J9AT00 SB4O PQ: 0 ANSI: 0
ça fait 110 caractères, dont 20 pour la date. Tu crois que 90 + 4 ou 90 + 20, ça fait une grande différence? Tu passes de 500% (avec une argumentation biaisée) à seulement 15-25% d'augmentation (avec une argumentation objective)…
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Zenitram (site web personnel) . Évalué à 3.
Pour info, ta data n'est pas ISO (ISO serait 2012-10-21T10:33:43Z note le T et le Z).
Donc un parser automatique échouerait (bon, un humain supporterait certes, mais aurait quand même un doute sur le time zone)
Dur de suivre les normes quand on veut faire du texte… D'où l’intérêt de faire la différence entre le vu et le stocké.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à 1.
Quand cesseras-tu de regarder le doigt au lieu de la lune?
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Zenitram (site web personnel) . Évalué à 2.
Ce qui te dérange, c'est de te rendre compte que le joli texte n'est pas si universel?
Car c'est bien la tout le sujet du thread : l’argument que le texte est génial car universel (alors qu'il ne l'est pas).
quand cesseras-tu de ne pas accepter la réalité du "format" texte pas mieux (voir pire pour pas mal d'utilisations) que le binaire de journald?
Quand cesseras-tu de regarder le doigt au lieu de la lune? (que journald avec des fichiers binaires, on s'en fout complet ça ne change rien au problème de lecture du fichier)
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par barmic . Évalué à 2.
À minima il manque la timezone. Puisqu'on parle de norme autant utiliser l'ISO 8601, redécrite par la RFC 3339 ou alors utiliser la convention décrite dans la RFC 2822. Par contre non elle ne m'ont pas l'air simple à parser mais en utilisant la commande date on peut s'en sortir.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Zenitram (site web personnel) . Évalué à 0.
Si tu t'arrêtes à ce genre de détail… ;-)
Mais clair que son exemple est l'exemple typique pour ne pas savoir du tout à quelle heure (on est à +/- 12 heures quand même… Pour avoir plus préciser, il faut une information externe, qu'on a assez souvent mais pas toujours, surtout à notre époque où les serveurs peuvent être sur différents time zones) s'est passé l’évènement, comme quoi, dur d'avoir du texte "universel" qui fournit des information utile ;-).
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par barmic . Évalué à 2.
Tu peut toujours établir que toutes les dates sont en UTC, voir mieux en Temps atomique international.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à 1.
Exact, j'ai oublié la zone. Si on l'inclut, ça fait 2 ou trois, voire 4 caractères en plus. On est tout de même loin des 500% d'inflation de Zenitram… De toutes façons, les dates, si on veut s'en servir, les systèmes de bases de données comme Postgres savent très bien interpréter ces formats de date. On peut/pourrait/aurait pu très bien importer ces journaux dans une table et c'est le moteur SQL qui se charge de l'interprétation des dates.
Ceci dit, dans le cadre des journaux, est-ce vraiment nécessaire d'avoir la zone? Le journal ne le fait pas aujourd'hui. Faut-il modifier le format pour inclure cette information à chaque ligne…?
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Zenitram (site web personnel) . Évalué à 1.
si pas de time zone, c'est une bug, la date ne veut pas dire grand chose (à moins que le time zone soit spécifié ailleurs, mais dangereux, info qui peut se perdre…)
Si, c'est UN exemple, on peut avoir d'autres exemples.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à -1.
Tu le fais exprès, c'est ça?
En quoi la timezone est-elle capitale *pour un journal*, hein? Qu'est-ce que t'en as à f*** si ton journal te raconte que tel jour, telle heure, tel endroit, tel fuseau horaire un disque de ton serveur (dont tu connais parfaitement l'endroit géographique, du moins je le suppose) a commencé à faire des erreurs SMART de plus en plus nombreuses et qu'à la suite de ça faudrait le remplacer? C'est quoi l'info la plus importante? Le fuseau horaire, c'est ça?
Je te renvoie au commentaire de Moonz, pour ça: http://linuxfr.org/nodes/96099/comments/1402502 . Quand j'ai pas le fuseau horaire, par exemple. j'arrive très bien à extrapoler que la date dont on parle concerne un appareillage dans le même fuseau horaire que moi ou bien celui par défaut, quand il y en a un. Et, franchement, pour un journal système, le fuseau horaire, on s'en tape! Ce qui compte ce sont les événements et leur déroulement, pas leur localisation dans l'espace.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Zenitram (site web personnel) . Évalué à 1.
Faudrait enlever la date alors… Bizarre, une info inutile qui est dedans.
Certains ont certes des besoins très très limités, d'autres travaillent avec d'autres besoins. journald répond à un besoin, sans emmerder le tiens, mais faut surtout pas laisser les autres avoir des besoins différents… Ben les autres, ils disent juste "va te faire voir, maintiens ta merde toi même"!
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par barmic . Évalué à 6.
Donc parce que dans ton cas particulier ça ne te sert pas, tu pense que ça ne sert à rien ?
Certains administrent pas mal de serveurs dans plusieurs points du globe et quand ils ont un problèmes il veulent pouvoir créer un diagnostique avec la chronologie des évènements, c'est utile autant en phase de test, que pour faire un diagnostique après une erreur ou une analyse post-mortem d'une attaque.
Donc on ne garde que la plus importante ? On ne met que le message du développeur alors, parce que toutes les méta données (le pid, le port, le niveau de gravité, etc) ne servent à rien si tu ne sais pas ce qui s'est passé.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à 0.
Non, je pense qu'il faut rester raisonnable. Le fuseau horaire n'est important que dans certains cas particuliers, comme tu viens de l'expliquer, pas dans *tous* les cas. Et pourquoi pas rendre le format de date configurable, tiens, par exemple?
Dans le cas où les journaux sont recyclés sur base journalière, à l’extrême, seul le jour et l'heure ont de l'importance. Par contre, dans le cas où la séquence des événements doit être mise en parallèle avec d'autres machines, de localisation et fuseau horaire différents, rien n'empêche d'utiliser un format plus complet, incluant date, heure et fuseau horaire; on importe le tout dans une base de données avec la date correctement formatée au départ. Si mes souvenirs sont exacts, PostgreSQL, par exemple, accepte des dates avec information de fuseau horaire et avec des données horaires jusqu'à la milliseconde.
Dans toutes mes argumentations, j'ai tenté de montrer que tous les reproches que l'ont fait à la mise en œuvre de données au format texte ont une solution qui ne passe pas nécessairement par le binaire.
Il y a une différence entre retirer ce qui n'est pas pertinent (pour le cas d'utilisation considéré) et ne garder que l'information la plus pertinente. Je parlais du premier cas.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par barmic . Évalué à 4.
Ça reviens à laisser un gros bordel, tout de même.
J'aime bien le principe. Certains beuglent contre l'usage d'un exécutable, journalctl, pour consulter les logs et proposent de passer par un serveur de base de données dès que les usages deviennent un chouïa compliqué.
On peut très bien gérer les dates au format texte avec des outils cli. La commande date est faite pour ça, alliée à awk ou perl tu peut convertir les informations à peut près comme tu le souhaite. Par contre il va falloir être un peu compétent en expressions rationnelles pour bien faire les choses. Utiliser quelque chose qui est fait pour ira quelques fois plus vite.
Ce qu'il en est actuellement c'est qu'avec un format texte et syslog on a un gros bordel et que l'on doit avoir un convertisseur par type de fichier de log pour pouvoir les manipuler (que ce soit en CLI ou en SGBD). L'utilisation d'un log binaire est une solution qui apporte d'autres avantages et inconvénients. Ce que je remarquais c'est que la date c'est loin d'être simple et avoir peu d'information en demandant à ceux qui ont des besoins complexent de se débrouiller et à peut prêt aussi pertinent que de faire l'inverse. Personnellement, je suis plutôt pour faire l'inverse, mettre le maximum d'information et voir après coup pour ceux qui ont des besoins minimalistes de diminuer d'eux même. Tout simplement parce que si je suis développeur MySQL et que je reçois des bug qui me disent que la base consomme 100% CPU je veux pouvoir voir dans les log que l'on me reporte que ça c'est passé au moment d'une seconde intercalaire. On ne sait pas forcément à quoi va servir un log avant que celui-ci ne soit créé.
Pour ce qui est du binaire ou non, je vois pas pourquoi faire autant de bruit. Pourquoi ne pas essayer ? C'est une expérimentation comme une autre. Changer ces habitudes n'est jamais vraiment un mal.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par barmic . Évalué à 5.
Il faudra juste choisir un SGBD, parce qu'ils ont chacun leur petites manies sur la gestion des dates.
Oui. Tout du moins si tu souhaite utiliser grep derrière. Sinon si tu n'utilise tes log que via un logiciel spécifique tu peut le mettre en entête et ainsi que les changements de timezone (oui, ça peut changer1). Il faudra que ce dernier vérifie qu'elle ligne correspond à quel timezone.
1 : au cas où changer de timezone ça peut se faire parce que la zone géographique où on est change de timezone, parce que tu es sur un terminal mobile qui se déplace et synchronise sa date, parce que tu reconfigure la date de tes VM après clonage et déplacement de celle-ci à bout ou l'autre du monde et probablement un tas de raisons que je n'imagine pas.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Moonz . Évalué à 4. Dernière modification le 24 octobre 2012 à 17:45.
J’ai un outil un peu magique que tu devrais essayer et qui s’appelle cerveau, qui sait que si « é » s’affiche c’est que c’est pas le bon encodage ; idem pour le BOM et le retour à la ligne ; quant à la langue, si les données sont en russe, la question du format du fichier contenant ces données est absolument orthogonal, je comprendrai rien. Malheureusement, il a énormément plus de difficultés sur le binaire chez moi (après, peut-être est-il défectueux, mais je peux pas le changer)
Tu approches le format texte comme tu approches le format binaire, c’est à dire comme une machine qui plante au premier bit qui lui plait pas, alors que la force du format texte c’est précisément qu’il peut être lu, interprété et corrigé par un humain qui a un cerveau.
J’ai déjà eu des problème d’encodage d’un système à l’autre sur des fichiers LaTeX. Un coup d’iconv est c’est passé.
J’ai déjà eu des problèmes d’encodage de Microsoft Office pour Windows à Microsoft Office pour Mac sur un .doc. J’ai jamais pu le corriger.
Quelle est la différence entre les deux situations ? Laquelle est préférable ? (ne me dit pas un format binaire sans bug, l’informatique sans bug ça n’existe pas, pas dans le monde réel, l’alternative que je te propose c’est une informatique avec bugs facilement corrigeables humainement et bugs quasiment impossibles à corriger par celui qui n’est pas dans les arcanes du format binaire spécifique)
cat et more plantent si l’encodage n’est pas bon ? Si le format de date leur plaît pas ? Je sais pas sur quel OS tu tournes, mais il est vachement bizarre.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par xcomcmdr . Évalué à 2. Dernière modification le 23 octobre 2012 à 20:02.
Le jeu de caractères (UTF-x, n-ième truc ISO ou ascii ? BOM ou pas BOM pour l'UTF-8 ?), et les histoires de CRLF (windows, dont le notepad ne reconnaît pas LF seul comme une nouvelle ligne : ça fait des textes illisibles du coup!), LF (*nix), ou CR (Mac OS), youpi !
edit : grillé par Zenitram (en plus j'avais oublié les histoires de dates et sûrement d'autres choses…)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à 3.
Réponds à cette question: le codage du retour à la ligne t'empêche-t'il de lire le fichier? Même si les accents et les caractères spéciaux ne sont pas codés directement, le texte devient-il illisible pour autant? Qu'on s'entende sur le sens du terme "illisible": ça ne rend pas le texte impossible à lire. Plus difficile, sans doute mais impossible, non. Un "a" reste un "a", un "b" un "b", bref, les mots restent des mots et tu peux malgré ta difficulté à lire, toujours percevoir la phrase car elle apparaît en clair en totalité ou pour la plupart de ses constituants.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à 1.
s/directement/correctement
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par xcomcmdr . Évalué à 5.
Quand le fichier de plusieurs milliers de lignes se transforme en une seule ligne, oui. Ça ne m'empêche pas de chercher dedans, mais c'est clairement pas lisible.
Quand le texte est en ISO-2022-JP, et qu'il devient uniquement des points d'interrogations sous Windows parce que y'a pas la police pour, amuse toi à le lire. ;-)
Bref, pour en revenir à journald, j'ai syslog-ng qui tourne en parallèle, et qui est écouté par journald (c'est même requis par journald au démarrage d'avoir syslog-ng sur ma Arch sinon j'ai une belle ligne du genre "[FAILED] Cannot connect to syslog-ng" au boot), donc y'a le binaire et le texte, tout le monde est content.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Zenitram (site web personnel) . Évalué à 1.
Si je n'ai pas d'interpréteur binaire, mais qu'un afficheur de texte (avec le format local), ça se transforme en une ligne ingérable.
Comme quoi, tu as besoin d'un interpréteur sous peine d'avoir des problèmes…
Oui. Pour toi en français c'est encore gérable, mais si tu décode du chinois, l'UTF-8 montré en ASCII ne veut rien dire.
En pratique si.
Après, merci l'est interpréteur, qui convertissent… cOmme journald en fait.
Binaire/texte, même combat, faut un interpréteur.
Tu es très fort pour réussir à lire quelques chose avec ça :
предоÑ.тавÑ. подробна техничеÑ.ка информациÑ. и инфромазиÑ. за таговете на даден видео или аудио файл
(si, ça veut dire quelque chose… Avec le bon interpréteur)
Ah oui, le franco-français métropolitain, avec un seul time zone (pour info, la France a plus d'un time zone), une seule langue… Linux est utilisé aussi par d'autres.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Moonz . Évalué à 2.
[mode Zenitram] De toute façon, les problèmes d’encodage, c’est pour les vieux de 30 ans qui veulent pas évoluer, on a inventé l’utf-8, faut vivre avec son temps les vieux râleurs
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Zenitram (site web personnel) . Évalué à 1.
Exact, ça devrait être UTF-8 partout (d'ailleurs mon exemple est de l'UTF-8 ;-) ), ça vient ça vient… Reste la date!
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à 2. Dernière modification le 25 octobre 2012 à 12:15.
Tu sais, en restant objectif, tout ce qu'on est en train de raconter sur la problématique du jeu de caractère reste valable avec journald. Ça ne sert à rien de s'esquinter là-dessus: tout texte stocké dans ce fameux fichier binaire doit être aussi encodé avec le jeu de caractère approprié. Donc les inconvénients que tu soulèves pour le texte ne sont pas propres au fichier texte; ce problème doit aussi être résolu quand on inclut du texte dans un fichier binaire. Ton argumentation ne plaide donc pas en faveur du binaire.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Misc (site web personnel) . Évalué à 5.
Mais le format des données n'a rien de standard :
Y a quoi d'universel dans tout ça ? Tantôt j'ai la date a un format, tantôt à un autre, tantôt j'ai le hostname, parfois non, j'ai des commentaires. Et j'ai pas du chercher longtemps pour montrer que c'est le merdier.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à -1.
Tu mélanges tout ici.
Universel est le texte parce que l'écriture est *un* moyen universel que les humains utilisent pour communiquer. Toi, tu me parles du *format* du journal.
Tu as raison, le format du journal n'a rien d'universel. Mais ce n'est pas de ça que je parlais. Le *texte* est universel ou, si tu veux, l'expression sous la forme de texte est universelle. L'expression au format binaire, non: l'homme n'écrit pas en binaire mais avec des lettres de l'alphabet. (Dont le contenu et la représentation visuelle est fonction de la langue, c'est vrai mais ça n'a rien à voir avec le débat qui nous occupe, à savoir la pertinence du stockage des journaux système en binaire par défaut.)
Ce que tu confirmes avec ton exemple, c'est que le journal a besoin d'un effort de standardisation au niveau de sa présentation. Le format binaire ne représente pas la seule et unique méthode pour y arriver.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Zenitram (site web personnel) . Évalué à 1.
On t'a démontré que non, il n'est pas universel. Forcément, en commençant à se tromper la dessus, tu ne risques pas de rendre tes arguments contre journald un peu crédibles.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à -1.
Non! Et encore une fois non! On m'a juste démontré que le "format" ou l'encodage du texte n'est pas universel. Pas que le texte ne l'est pas.
Oh et puis merde à la fin.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Zenitram (site web personnel) . Évalué à 0.
Forme : démontré que ça merde
Fond : tu parles 200 langues, c'est cool, pas moi.
Fail partout.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à 0.
Au moins je suis d'accord. Tu as perdu et moi aussi.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par xcomcmdr . Évalué à 2.
Non pas forcément, ça peut être en sinogrammes ou un alphabet qui t'es inconnu. Et puis les chiffres, ça aide aussi.
Même sans les histoires de CRLF, ou d'UTF-8, ou de dates, ça fait déjà un sacré bordel pas universel du tout.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Zenitram (site web personnel) . Évalué à 1.
Yep.
Et ton fichier "texte", c'est que du binaire, juste avec un formatage donné (pas très précis du tout, du coup c'est un peu le bordel, et le logiciel peut te transformer ça en texte lisible par un humain, mais faut pas lui demander d'automatiser grand chose avec).
Et tu peux avoir exactement le même type de sortie entre ton log actuel (qui est du binaire de chez binaire, que tu lis avec un logiciel qui le transforme en pixels) que le log de journald (qui est du binaire de chez binaire, que tu lis avec un logiciel qui le transforme en pixels, la différence est juste que ce n'est pas le même logiciel)
Tu donnes toi-même des arguments pour dire qu'en fait, journald ou avant, ben ça revient au même en fait.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Moonz . Évalué à 2.
Moui, et ya aucune différence entre les vivaldi_4_saisons.wav et /dev/urandom, après tout les deux c’est une suite d’octets qui produit des ondes sonores à l’aide d’un certain dispositif quand tu les envoie sur /dev/dsp.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Misc (site web personnel) . Évalué à 6.
Pour standardiser, tu as 2 choix. Soit tu va dire à tout le monde "maintenant, c'est ça" et tu t'assures que tout le monde le fait. Soit tu mets un truc entre les logs et le programme qui va se charger de faire ça. Notamment dans le cas de la date, c'est flagrant. C'est ce 2eme cas que journald a choisi.
Ensuite, journald a le choix entre stocker ça en binaire ou en texte. En texte, soit tu prends un format ad-hoc ( ce qui est actuellement mis dans les logs ), soit tu reprends un truc existant ( genre du json, du xml, du yaml ) avec une grammaire. Les auteurs de journald se sont orienté vers le binaire et fait de tout mettre dans une base de données directement pour éviter de faire du parsing sans arrêt.
Les avantages sont multiples. Comme c'est indexé, l'accès aux données est peu couteux et ça permet de voir les logs avec systemctl status. Comme c'est indexé, les recherches sur la date peuvent se faire de manière précise.
Comme les champs sont souvent répétés ( hostname, boot_id, etcetc ), il y a moyen de compresser ça de manière efficace, ce qui permet de logger plus d'info sans pour autant prendre plus de place. Et d'utiliser les informations. Par exemple, plus besoin de regarder la date d'un truc pour savoir si un log correspond au boot courant ou pas, l'information est stocké dans boot_id. L'utilisateur et le service sont enregistré, plus de magouille avec la commande logger. Donc c'est pas "on rajoute des champs pour rien". De plus, la compression a mon avis peut jouer dans le cas de l'embarqué ( embarqué qui inclue aussi les tablette ), et on peut râler ce qu'on veut sur Apple, si on veut pas avoir un futur ou ils deviennent le microsoft d'hier, faut prendre en compte ce cas.
Ouais, on aurait pu faire autrement. Guess what, au lieu de troller sur linuxfr, y a des gens qui ont commencés le boulot :
https://fedorahosted.org/lumberjack/
L'origine est expliqué ici : http://bazsi.blogs.balabit.com/2012/02/project-lumberjack-to-improve-linux-logging/
Donc tu va pouvoir maintenant défendre le fait d'utiliser xml :
https://fedorahosted.org/lumberjack/wiki/sampleXml#ExamplelumberjackLogEventsinXMLFormat
ou json :
https://fedorahosted.org/lumberjack/wiki/sampleJson#ExamplelumberjackLogEventsinJSONFormat
Tu peux même trouver des choses comme https://github.com/deirf/libumberlog pour faire ce que tu veux, à savoir un format texte standardisé pour les logs. Je te propose donc de compiler la lib chez toi, de l'utiliser et de nous dire après 2 mois comment ça a trop changé ta vie. Moi, j'utilise le journal et systemd, et j'ai déjà expliqué pourquoi je trouve que le résultat est pratique.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par claudex . Évalué à 4.
Dans le cas de journald, il y a un accès plus rapide au données (quand on recherche, on est pas obligé de parcourir toutes les données car elles sont organisées.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à 3.
C'est vraiment crucial pour des journaux? Le format binaire était la seule réponse à ça? Même en faisant des rotation de journaux ou, que sais-je, en utilisant syslog pour envoyer les journaux vers une base de données en plus de conserver les journaux au format texte?
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par claudex . Évalué à 4.
Il y a des gens qui ne font pas des rotations quand ils ont des logs conséquents ? (mais ça ne répond pas au problème)
Et magie, c'est ce que fait journald, il envoie le texte à syslog qui le stocke au format texte et garde le format binaire.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Anonyme . Évalué à 2.
Tu veux parler d'une base de données qui stock ses infos dans des fichiers en binaire ?
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à 1.
Oui. [Pour illustrer qu'avant systemd/journald, si on voulait vraiment utiliser du binaire et ses avantages, alors que le format de base du journal est le texte, on pouvait déjà y arriver.]
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par Michaël (site web personnel) . Évalué à 6.
Des données stockées en fichier texte c'est facilement
1. modifiable dans un éditeur de texte;
2. lisible par un programme ad-hoc même si on n'a besoin que d'un bout de la donnée;
3. produisible par un programme ad-hoc;
en revanche
En gros le format texte a l'intérêt qu'on peut accéder à ou produire de tels fichiers sans passer par une psychothérapie avec l'API d'une quelconque bibliothèque — qui au passage n'a aucune raison d'exister pour le langage que tu as décidé d'employer.
Par exemple sox peut convertir des fichiers sonores dans un format texte, dans n'importe quel langage de programmation il ne faut pas plus de 20 minutes pour écrire une procédure de lecture pour ce genre de fichiers.
Idem pour les images avec les formats PNM et PPM.
Ensuite par exemple, si tu veux modifier un document TeX ou HTML dans un traitement par lot c'est très facile (tant que tu sais bien décire la modification à faire).
Des données stockées dans un format binaire…
1. c'est impossible à lire ou écrire sans un composant logiciel spécialisé
2. le format est bien défini
3. il est possible d'accéder aux données aléatoirement.
En ce qui concerne
systemdje pense que le choix du binaire pour les logs n'est pas utile: pour le stockage et la lecture occasionnelle les fichiers texte conviennent, pour les manipulations complexes il vaut sûrement mieux déplacer les logs dans une base de données relationnelle que de les stocker dans un format de fichier binaire.[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . Évalué à 0.
:D
C'est un peu ça.
Je m'attends ici à ce que quelqu'un rétorque que cat et type sont tous les deux des composants logiciels spécialisés… ;-)
Exactement!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.