FantastIX a écrit 1338 commentaires

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.

Sinon, 20 octets à la place de 4, c'est d'un optimal (compressable, mais quand même)

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)…

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

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.

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.

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?

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

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.

s/directement/correctement

Épargne-moi tes attaques personnelles s'il te plaît.

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 !

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.

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.

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?

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.

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?

Soyons précis : tu veux que des mecs fassent un boulot qu'ils ne veulent pas faire.

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.

Tu réagis comme s'il y a avait un consensus sur les autres systèmes d'init […]

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.

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

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.

Il y a tellement de matière qu'on en est rendu à discuter sur la discussion, c'est dire :)

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.

Ne te sens pas visé particulièrement je parlais des deux parties.

Tracasse, je ne parlais qu'en général, me sentais pas visé. ;-)

Tu es un adepte du consensus ?

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.

Tu n'a jamais entendu parler des « gentils dictateurs » (comme Linux Torvalds par exemple) ?

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.

Je trouve rigolo de voir que des "utilisateurs" râlent, mais pas foule pour maintenir. Étonnant… Libre, libre, libre!

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.

Enfin si vous pouviez éclairer ma lanterne, je suis preneur.

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.

Puis c'est sympa de voir tout le monde grimper sur leurs grands chevaux pour te regarder de haut avec un ton dédaigneux.

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.

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 cat suffit, parce que le texte, s’il n’est pas totalement omniprésent, est tout de même bien plus représenté.

Je partage entièrement ton avis, même si mon expérience n'est pas aussi étendue.

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.

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.

En 8 ans tu n'as jamais pris le temps dans le répertoire /var/log ? Il faut arrêter Gcompris …

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.

tail -f /var/log/messages | egrep -i 'error|sd?'  ?

J'espère que tu ne compresse pas tes logs.

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.

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.

Comme a répondu Thomas DEBESSE, deux applications s'exécutant sous deux comptes séparés. J'ai «bricolé» ainsi un site Joomla en interdisant l'accès administratif via http et en le forçant via https. Ça demande de peaufiner les droits d'accès fichier/répertoire à la mano (donc de savoir où l'interface d'admin doit avoir accès en écriture ou pas, en plus des répertoires où Joomla doit écrire aussi, genre ./logs et ./tmp…) car Joomla n'est pas du tout prévu pour ce mode de fonctionnement. Heureusement, ça reste faisable et, jusqu'à présent, j'ai toujours réussi à trouver une parade. Le processus principal peut être un Apache, le second un lighttpd (c'est mon cas) ou un xinetd, n'importe quoi.

Je l'ai faite mais je considère que ces bidouilles (noatime…) tiennent plus du ramassage de miettes que du gain réel.

Plutôt qu'un gain en performance, j'ai cru comprendre que ça (le noop) évitait de stresser inutilement le CPU.