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?
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/log puis lire les logs à partir de mon chroot qui ne possède pas syslogctl, avec journalctl je 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 Moonz . En réponse à la dépêche Documentation du format du Journal. É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é).