Anonyme a écrit 62289 commentaires

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?

Tu veux parler d'une base de données qui stock ses infos dans des fichiers en binaire ?

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.

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.

Un cat fichier.ogg > /dev/dsp ne fonctionne pas si bien que ca.

Évidemment que tu ne vas pas utiliser un format texte pour un contenu qui n’a pas de représentation textuelle…

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 ?

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é.

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.

Ils auront sans doute la bataille de ceux qui veulent garder systemd et journald ("on a toujours fait comme ça") contre les nouveaux venus!

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 (pour journald) dans nos système ».

Mais personne n'a râlé qu'il l'est

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 systemd et journald deviennent 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é.

Bah, c’est bien dommage justement, et ce contre-exemple non représentatif ne suffit pas à justifier n’importe quoi par la suite.

C’est là où je voulais en venir dans mon commentaire : personne n’a jamais dit qu’il fallait absolument que wtmp soit binaire.

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.

Explique-moi comment tu explorais /var/log/wtmp il y a 15 ans avec cat ?

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/wtmp soit un fichier binaire.

Ok, donc en fait l'argument "je ne peux pas faire un tail" est réellement bidon

https://linuxfr.org/nodes/96099/comments/1401998

et si tu avais un jtail -f /var/log/messages | egrep -i 'error|sd?' ça changerait quoi ?

Ça fait que je ne pourrait pas lire les logs sur Mac OS puisqu'il faut systemd pour avoir les outils de journald.

tu as oublié une série de 9 vers la fin

nolife est un site fonctionnant par abonnement: pour exaucer ton vœui, offre un abonnement à un dev weboob et demande lui de mettre à jour le module nolife avec les formules de politesse adéquates

Si il n'y a pas un systemd qui tourne, journalctl n'est même pas capable de trouver les logs tout seul. Il va essayer de se connecter à DBus pour parler à systemd. Et si il n'y a pas, ben il s'arrête là.

Je ne parle pas de journalctl, mais de l'API C qui permet de lire les fichiers. Exactement ce dont tu parlais dans le message auquel j'ai répondu, ou tu disais: "l'API C (qui nécessite bien sur d'avoir tout systemd installé)".

Si la ligne est trop longue journalctl -f la tronque, et puis certains metas donnés par systemd n'apparaissent pas.

Il suffit de faire :

COLUMNS=50000 journalctl -f

Et voila, journalctl ne tronque plus les lignes, à moins qu'elles fassent plus de 50000 caracteres.

Et pour les metas donnés qui n'apparaissent pas, tu parles de quoi exactement ?

A quand des logs en XML :-) après tout, pourquoi pas.

On peut deja les avoir en json: journalctl -o json

Idéalement il faudrait que le lecteur de log émule un comportement de fichier, ce qui implique à son tour de faire un FS user space (petit et en user space), et donc d'installer des cochonneries sur la machine qui reçoit les logs.

Oui, par ce qu'il est bien connu que grep, sed, awk, perl et autres ont obligatoirement besoin d'un fichier, ils ne savent pas utiliser l'entrée standard qu'on leur donne avec un pipe.

Ca doit être parce que c'est "super simple" que la première chose que dit la page freedesktop est "Faites pas les cons, utilisez l'API C (qui nécessite bien sur d'avoir tout systemd installé) sinon vous allez vous vautrer".

Faux. Il suffit de libsystemd-id128.so et libsystemd-journal.so, pas besoin du reste de systemd. Sur ma machine ca prend environ 332ko.

On dira ce qu'on voudra mais j'aimais tail -f moi.

Et t'aimes pas journalctl -f qui fait exactement la meme chose ?

journalctl et un pipe

Donc en en revient au commentaire 4 crans plus haut : pour traiter les logs de Journald, il faut un Linux avec systemd.

C'est très amusant comme démonstration… Effectivement, je n'y connais rien en base de donnée, et je l'ai en plus écrit au début de mon billet.

L'idée de mon billet était avant tout de donner le point de vu de l'accessibilité aux base de données d'un point de vu purement profane, et là je me sens particulièrement insulté par ce que tu as écrit.

Ça m'apprendra à la ramener.

un log ça peut être gros (tu peux chercher sur plusieurs semaines si tu as envie)

Mauvais admin, changer admin !

Aller, tiens, c’est cadeau :

$ < /etc/logrotate.conf 
daily
create
dateext
dateformat -%Y-%m-%d
olddir archives
rotate 366
[…]

Et journald c'est quoi ? C'est des données en texte, plus des trucs en binaire pour indexer ces données.

Après avoir écouté quelle est la difference entre le bon et le mauvais chasseur …

http://www.youtube.com/watch?v=vH2GdDrJpKg#t=2m59

voila maintenant quelle est la difference entre le bon et le mauvais format de données: Le bon format de données comme sqlite, il stocke ses données texte et les indexe avec du binaire. Rien à voir avec le mauvais comme journald, qui stocke ses données texte et indexe ca avec du binaire.

Pour une image finale, effectivement, le 16 bits ne sert à rien, par contre, lorsqu'il s'agit de travailler sur une image brut, il est absolument indispensable d'avoir une environnement de travail 16 bits.

Les outils pour faire développer les images raw permettent le plus souvent de se passer de ça, mais alors gimp dans ce cas ne sert plus à rien du tout…

Bref, même si gimp dépanne, il ne fait rien d'autre, et d'ailleurs la dernière version a apporté plus de régression que d'amélioration.

en dessous de 0 le commentaire sera caché pour la plupart des lecteurs (sauf la minorité qui a baissé son seuil).

La plupart des utilisateurs inscrits.

et ensuite les gens sont venus râler qu'ils n'étaient pas au courant et qu'ils trouvaient ça révoltant

Non, les gens sont venu râler parce que tu proposais une modification dont ils ne voulaient pas.

D'ailleurs, je trouve toujours que cette modification c'est de la merde !

en fait je soupçonne que la plupart des gens moinssent juste parce qu'ils sont rageux

Non, les gens moinsent parce que ta proposition n'est pas pertinente et parce que tu te sent obligé de créer un journal pour troller sur tes entrées de suivi, etc.