OK merci. Donc question syntaxe c’est kifkif, la différence de yq par rapport à jq c’est le support de plus de format que seulement le YAML, mais moins de fonctionnalités (qui sont prévues si je me fie au README), et le langage dans lequel il est implémenté (Go vs. C pour jq).
Tout ça pour dire que yb m’intéresse fortement. Le seul inconvénient (pas négligeable d’après-moi), en rapport avec la discussion que nous avions sur Bash, c’est que yb n’est forcément packagé forcément par les ditributions (il l’est pas sur Bookworm en tous cas). Est-ce que le fait qu’il soit natif (ie: en Bash) ne résout pas forcément tout les problèmes de « de simplification de l’environnementdontt til a besoin ».
si on le copie dans son propre projet il faut suivre ses mises à jour. Ce qui est plutôt simple avec les sous modules git, ça déporte toujours la gestion de l’environnement pour son propre au projet lui-même au lieu de se reposer sur les distributions qui font tourner son projet, et qui gèrent toutes les mises à jour de jq.
pour l’installation, si Ansible (ou autre outil de ce type) peut aussi bien gérer l’installation d’un RPM/DEB que le déploiement d’un script ça nécessite quand même toujours de considérer le premier point.
<blocktype=spam category=biography interest=0.0032 >
Clairement, je chipote grave et c’est peut-être moi qui ne travaille pas de la bonne manière (surtout que je dois parfois me résoudre à travailler de manières que je sais plus nulles que les miennes). Je ne suis pas chef et j’ai un certain nombre de collègue, ingénieurs comme moi (et pas des anciens à un ou deux ans de la retraite...), ingénieurs d’exploitation, des opérationnels donc, qui assument sans réserve, de ne pas savoir utiliser git/Github et de tenir à une gestion des opérations basée sur des documents Word, comme ils font depuis des dizaines d’année. Ils n’ont pas le temps de se former à git/Github vu leur charge de travail quotidien. Ajoutant qu’il faut également du temps pour étudier que la pertinence de passer de leur mode de gestion actuel à git/Github est vraiment réelle. Quand tu as un management qui a pas la volonté et la capacité à imposer ce genre de changement. Et bien... tu fais du devops/gitops surtout sur le papier et ça reste à l’état de projet. Mois qui suis fataliste et assez versatile (je ne fais rien vraiment bien mais rien non plus vraiment mal ) je me fais une raison. Mais quand je vois un collègue qui lui s’impose à lui même, et pousse pour, une gestion devops/gitops à la pointe de la discipline (ce qu’on ne peut pas lui reprocher, à moins d’un manque flagrant de pragmatisme sur un point, ce qui est très rare), je suis sûr que ça participe pas à sa satisfaction dans son travail. </block>
[^] # Re: Intéressant
Posté par Marotte ⛧ . En réponse au journal yb : enfin la v0.9. Évalué à 4.
OK merci. Donc question syntaxe c’est kifkif, la différence de
yqpar rapport àjqc’est le support de plus de format que seulement le YAML, mais moins de fonctionnalités (qui sont prévues si je me fie au README), et le langage dans lequel il est implémenté (Go vs. C pourjq).Tout ça pour dire que
ybm’intéresse fortement. Le seul inconvénient (pas négligeable d’après-moi), en rapport avec la discussion que nous avions sur Bash, c’est queybn’est forcément packagé forcément par les ditributions (il l’est pas sur Bookworm en tous cas). Est-ce que le fait qu’il soit natif (ie: en Bash) ne résout pas forcément tout les problèmes de « de simplification de l’environnementdontt til a besoin ».si on le copie dans son propre projet il faut suivre ses mises à jour. Ce qui est plutôt simple avec les sous modules git, ça déporte toujours la gestion de l’environnement pour son propre au projet lui-même au lieu de se reposer sur les distributions qui font tourner son projet, et qui gèrent toutes les mises à jour de jq.
pour l’installation, si Ansible (ou autre outil de ce type) peut aussi bien gérer l’installation d’un RPM/DEB que le déploiement d’un script ça nécessite quand même toujours de considérer le premier point.
<block type=spam category=biography interest=0.0032 >
Clairement, je chipote grave et c’est peut-être moi qui ne travaille pas de la bonne manière (surtout que je dois parfois me résoudre à travailler de manières que je sais plus nulles que les miennes). Je ne suis pas chef et j’ai un certain nombre de collègue, ingénieurs comme moi (et pas des anciens à un ou deux ans de la retraite...), ingénieurs d’exploitation, des opérationnels donc, qui assument sans réserve, de ne pas savoir utiliser git/Github et de tenir à une gestion des opérations basée sur des documents Word, comme ils font depuis des dizaines d’année. Ils n’ont pas le temps de se former à git/Github vu leur charge de travail quotidien. Ajoutant qu’il faut également du temps pour étudier que la pertinence de passer de leur mode de gestion actuel à git/Github est vraiment réelle. Quand tu as un management qui a pas la volonté et la capacité à imposer ce genre de changement. Et bien... tu fais du devops/gitops surtout sur le papier et ça reste à l’état de projet. Mois qui suis fataliste et assez versatile (je ne fais rien vraiment bien mais rien non plus vraiment mal ) je me fais une raison. Mais quand je vois un collègue qui lui s’impose à lui même, et pousse pour, une gestion devops/gitops à la pointe de la discipline (ce qu’on ne peut pas lui reprocher, à moins d’un manque flagrant de pragmatisme sur un point, ce qui est très rare), je suis sûr que ça participe pas à sa satisfaction dans son travail.
</block>