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.
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.
"The on disk format uses exclusively 64bit LE (little endian) offsets,"
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 FantastIX . En réponse à la dépêche Documentation du format du Journal. É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.)