SQLLite ? Par exemple hein, il y en a un paquet d'autres (Pas mal de backends LDAP par exemple)
De façon générale il existe une palanquée de "flat file database" dans lequel le bianire est l'exception plutôt que la règle.
PS : jamais compris pourquoi des gens arrivent à se braquer sur un format "binaire" pour défendre un autre format binaire
Oui en vrai tous les formats sont binaires. Surprise il n'y a pas de petits caractères en fonte dans les processeurs. Et pourtant on fait le distinguo.
Un indice : Lisible facilement par un être humain et éditable facilement avec des outils standards.
Pourquoi c'est pas fait?
Sur les systèmes qui en ont besoin, c'est fait.
Mes logs DNS/Apaches sont indexés par exemple.
Pourquoi rajouter encore plus de volume de données pour faire la même chose? chez vous les disques durs sont gratos?
Parce qu'un meta en INT LE 64 bits ça ne prend pas de place ?
Le format ASCII prend de la place mais le format binaire c'est gratuit ?
Au risque de te surprendre, le fait que les disques durs ne soient pas gratuit est une excellente raison de ne pas mettre :
- 12 000 métas sur des entrées ou ca n'apporte pas grand chose
- Une nouvelle palanquée d'outils pour lire et trier ces métas
- D'autres outils pour gérer la corruption des données (oui en ascii la corruption d'un octet ca peut faire chier mais pas plus que ça, alors qu'en binaire)
- Et bien sur toute la clique de convertisseurs pour les programmes qui ne parlent pas encore le journald couramment (et dont même en cherchant bien on ne voit pas pourquoi ils apprendraient à le faire)
_ Il y a des gens qui ont des Go de log (surtout sur 1 an, minimum légal), et remercie journald et son format "binaire avant c'était pas binaire" _
1) Personnellement j'ai des Go de logs par jour. Avec des scripts baysiens pour foutre à la poubelle ce qui n'a pas d’intérêt et ne stocker que le nécessaire.
2) Je ne connais personne qui a des Go de logs à maintenir et qui dise merci au format binaire. Pourtant du sysadmin j'en connais - mais même ceux qui sont éventuellement intéressés par journald sont rebutés par le fait qu'il faille rameuter systemd et toute la clique pour que ça marche.
sans supprimer un seul avantage du avant
A part la non lisibilité par un humain, le surplus de maintenance, le coté non standard/non fini, la non intégration dans l'existant, les dépendances, la fragilité à la corruption etc.
_ En attendant, il y en a un qui se bouge le cul, lui, et il a l'air de bien répondre à un besoin de beaucoup de monde…_
Tant mieux pour eux. Bon je ne connais pas ce "beaucoup de monde" là. Le beaucoup de monde que je connais est plutôt contre systemd - mais bon il en faut pour tous les gouts. Je ne suis pas développeur système, ni mainteneur de packages. Je suis architecte et sysadmin - et pour l'instant je ne vois que des inconvénients à systemd et les avantages de journald (qui existent c'est clair) ne sont pas suffisant loin s'en faut pour que je reconsidère systemd comme une possibilité.
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 9.
Mais alors, pourquoi personne ne l'a donc fait?
SQLLite ? Par exemple hein, il y en a un paquet d'autres (Pas mal de backends LDAP par exemple)
De façon générale il existe une palanquée de "flat file database" dans lequel le bianire est l'exception plutôt que la règle.
PS : jamais compris pourquoi des gens arrivent à se braquer sur un format "binaire" pour défendre un autre format binaire
Oui en vrai tous les formats sont binaires. Surprise il n'y a pas de petits caractères en fonte dans les processeurs. Et pourtant on fait le distinguo.
Un indice : Lisible facilement par un être humain et éditable facilement avec des outils standards.
Pourquoi c'est pas fait?
Sur les systèmes qui en ont besoin, c'est fait.
Mes logs DNS/Apaches sont indexés par exemple.
Pourquoi rajouter encore plus de volume de données pour faire la même chose?
chez vous les disques durs sont gratos?
Parce qu'un meta en INT LE 64 bits ça ne prend pas de place ?
Le format ASCII prend de la place mais le format binaire c'est gratuit ?
Au risque de te surprendre, le fait que les disques durs ne soient pas gratuit est une excellente raison de ne pas mettre :
- 12 000 métas sur des entrées ou ca n'apporte pas grand chose
- Une nouvelle palanquée d'outils pour lire et trier ces métas
- D'autres outils pour gérer la corruption des données (oui en ascii la corruption d'un octet ca peut faire chier mais pas plus que ça, alors qu'en binaire)
- Et bien sur toute la clique de convertisseurs pour les programmes qui ne parlent pas encore le journald couramment (et dont même en cherchant bien on ne voit pas pourquoi ils apprendraient à le faire)
_ Il y a des gens qui ont des Go de log (surtout sur 1 an, minimum légal), et remercie journald et son format "binaire avant c'était pas binaire" _
1) Personnellement j'ai des Go de logs par jour. Avec des scripts baysiens pour foutre à la poubelle ce qui n'a pas d’intérêt et ne stocker que le nécessaire.
2) Je ne connais personne qui a des Go de logs à maintenir et qui dise merci au format binaire. Pourtant du sysadmin j'en connais - mais même ceux qui sont éventuellement intéressés par journald sont rebutés par le fait qu'il faille rameuter systemd et toute la clique pour que ça marche.
sans supprimer un seul avantage du avant
A part la non lisibilité par un humain, le surplus de maintenance, le coté non standard/non fini, la non intégration dans l'existant, les dépendances, la fragilité à la corruption etc.
_ En attendant, il y en a un qui se bouge le cul, lui, et il a l'air de bien répondre à un besoin de beaucoup de monde…_
Tant mieux pour eux. Bon je ne connais pas ce "beaucoup de monde" là. Le beaucoup de monde que je connais est plutôt contre systemd - mais bon il en faut pour tous les gouts. Je ne suis pas développeur système, ni mainteneur de packages. Je suis architecte et sysadmin - et pour l'instant je ne vois que des inconvénients à systemd et les avantages de journald (qui existent c'est clair) ne sont pas suffisant loin s'en faut pour que je reconsidère systemd comme une possibilité.