barmic 🦦 a écrit 5783 commentaires

C'est typiquement le genre de ticket, si ça arrive, sera fermé dans la foulée. Parce-que le souci n'est pas Ansible mais YAML. Les points problématiques ont été listés

Parce qu'il est interdit de discuter des bonnes pratiques conseillées et appliquées par le projet ? Si c'est un sujet troll dans le projet, c'est dommage que la description des bonnes pratiques soient péremptoire plutôt que de refléter l'indécision (ce qu'elle fait au sujet de l'arborescence d'un playbook).

C'est un vrai sujet qui concerne le projet qui comme tu le dit ça pose régulièrement des difficultés sur les forums.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tout comme Fabric, y a des noms qui ne sont pas trop amicaux avec les moteurs de recherche. Voici : https://doc.bearstech.com/nuka/ (avait été déjà évoqué dans un autre commentaire.)

Merci. Je recherche pas trop la performance donc je resterais peut être sur fabric.

Tu peux regarder aussi TakTuk et Kanif : http://taktuk.gforce.inria.fr/

Tiens c'est un de mes anciens prof qui travaille dessus, mais le lien est mort. Je ne sais pas si c'est transitoire, mais je ne trouve rien ailleurs.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Et l'alternative que tu préconises, indique que tu as plutôt besoin de Fabric ou Nuka ou similaire.

Je ne connais pas nuka et je réfléchis à utiliser fabric en ce moment(pour des usages , tu as un lien ? Mon moteur de recherche ne m'aide pas beaucoup.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

bien sûr, quand on veut faire portable on se retient d'utiliser des choses qui ne le sont pas, mais de là à conclure que la norme dit que ça ne doit pas exister ça me laisse sans voix.

Personne n'a dit ça. La norme dit uniquement ce qui correspond à ces préceptes ou non. Si tu utilise -W ta toolchain n'est pas compatible posix. Il y a je présume un mal entendu entre "ce comportement ne doit pas changer parce que tout ce que je fais est posix (notamment ma toolchain)" et "l'outil se veut posix donc ça casserai sa compatibilité".

Par contre gcc par exemple n'est pas posix par défaut sans que ça ne pose plus de problème que ça (il compile en gnu89).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

On peut faire le même parallèle pour DocBook et d'autres comparé à XML au sens générique. J'ai des collègues qui ont du mal parce-que n'ayant pas de syntaxe spécifique alors que moi non.

Oui si ce n'est que l'outillage pour en faire avec xml est bien plus simple. Tu n'a pas besoin d'implémenter un parser, tu te contente de décrire ta grammaire et tu as une coloration, une autocompletion, une validation dans tout ce qui sait manipuler du xml. Tu peux avoir ton templating en xml ce qui va se marier ensemble et pas se marcher sur les pieds.

On peut faire le même parallèle pour tous les DSL (aussi bien celui de Puppet que celui de Structurizr avec lequel je travaille actuellement.)

Le fait d'avoir un bout de d'outils existant à fait qu'on a mis 10 ans à prendre le sujet ça n'aurait pas mis autant de temps sinon.

Ça revient au même pour moi. Si tu utilises lsp, bah il faut créer les fichiers de syntaxe lsp (ou attendre que quelqu'un fasse le tripatouillage pour toi.)

On ne parle pas de la même chose. Ansible a mis 10 ans à s'occuper d'avoir un outillage sympa pour ses playbooks. Ce qui rendait pénible tout usage de jinja ou qui pouvait te planter si tu n'échappe pas des choses qui ont du sens pour celui-ci. Le fait que tu puisse te créer ton outillage pour ne change pas. C'est comme dire que si tu sais faire tu ne fait pas d'erreur.

La « bonne habitude » est de « juste mettre les quotes pour les chaînes de caractères. » Beaucoup d'erreurs auxquels j'ai répondu sur le forum étaient juste liées à ça : on a pris le raccourci autorisé par YAML et on n'a pas compris ce qui a merdé. Que de temps perdu en n'ayant pas fait les choses correctement dès le départ ?

Ça n'a l'air partager par personne dans la communauté. Je ne suis pas allé voir s'il y a eu un ticket ou un mail là dessus. Mais c'est, je trouve significatif de difficultés avec le format que tu trouve si problématique les règles suivi par la communauté.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je reviens au point qui préoccupe. Comme les éditeurs font de la coloration syntaxique pour du YAML c'est donc du YAML pur qui est vu et mis en évidence. Pour répondre à ton/ta besoin/demande, il faudrait rajouter une déclinaison qui serait la prise en compte du DSL… Pour faire une analogie, quand tu ouvres un document XHTML dans un éditeur qui le voit comme du XML, ça va certes reconnaitre qu'il y a des balises et des attributs et pouvoir indiquer les imbrications etc. Mais contrairement à un éditeur HTML pur, ça ne reconnait pas la sémantique qui lui permettrait de distinguer les balises valides des balises farfelues, et reconnaître proprement JS et CSS dedans. C'est exactement ce qu'il manque avec la prise en compte de Jinja2 dans du YAML (et c'est valable aussi si on utilise quelque autre mécanisme : j'ai perso déjà eu à faire des modèles YAML avec des variables shell mais les éditeurs ne savaient pas mettre ces intrus en évidence.)

C'est un long paragraphe pour me paraphraser. Je sais très bien ce qu'il manque et je l'ai dis dans mon commentaire. Comme tu le souligne il faudrait les mots clefs d'ansible le support de jinja2, voir une compréhension de la structure, des mots-clef, de jinja pour avoir de l'autocomplétion. Un linter qui va avec ça. Bref quand on superpose des syntaxes existantes, on obtiens pas le meilleur de chaque monde, mais le pire. On crée un nouveau format qui n'est que partiellement pris en charge un peu partout et cette prise en charge partielle et par effet goodenought ralenti fortement l'émergence d'outils agréables à utiliser.

Et non la solution n'est pas de tripatouiller les fichiers de syntaxes de ton éditeur, tu va avoir un truc qui marchote plus ou moins. La solution c'est d'utiliser le LSP proposé par le projet, mais voila son développement n'a commencé que l'an dernier pour un projet qui a 10 ans.

Le « FAST » dans le titre indique que les petites violations des bonnes pratiques sont assumées et ça me va : vite fait ne peut être toujours 100% bien fait…

Tu veux dire qu'ils veulent que ce soit tellement rapide qu'ils ont viré les quotes non nécessaires ? En tout cas si je regarde les playbook les mieux notés d'ansible galaxy, ils appliquent tous la règles "on ne quotes que les chaines pour les quel c'est nécessaire". Bon est pour aller plus loin encore c'est aussi la règle qui est utilisée dans le dépôt de playbooks servant à illustrer les bonnes pratiques pointées par la doc d'ansible comme quoi.

Avoir une indentation correcte et cohérente est, comme avec Python, plus facile à lire et limite les erreurs.

Quel est le problème avec l'indentation ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

L'outil se dit simple parce-que n'imposant rien

Il n'impose pas d'architecture, mais il est tout de même opiniated (rien que pour le côté déclaratif par exemple).

sa syntaxe (coder en yaml… faut être maso),

Cette mécompréhension fait qu'on appréhende l'outil de la plus mauvaise manière qui soit.

Pas besoin de chercher à faire des choses procédurales pour souffrir. Si je prends le premier playbook en suivant les liens dans la doc officielle (getting started → administrator getting started → playbook) on arrive ici : A system administrator's guide to getting started with Ansible - FAST!

et on nous montre ça (je garde que ce qui est nécessaire à mon exemple) :

---
- hosts: webservers
 become: yes
 tasks:
   - name: install Apache server
     yum:
       name: httpd
       state: latest
#...
   - name: set content directory group/permissions 
     file:
       path: /var/www/html
       owner: root
       group: web
       state: directory
       mode: u=rwx,g=rwx,o=rx,g+s

   - name: create default page content
     copy:
       content: "Welcome to {{ ansible_fqdn}} on {{ ansible_default_ipv4.address }}"
       dest: /var/www/html/index.html
       owner: webadm
       group: web
       mode: u=rw,g=rw,o=r

Et voila jinja2. Je comprends le choix (c'est LE moteur de template de python), mais tu as 2 syntaxe dans un même fichier, je n'ai jamais trouvé d'éditeur en mesure de représenter correctement les 2 syntaxes (comme ça existe pour html/js/css) et tu as un moteur de template complet (on manipule des structures de données fréquement) dans un langage de description qui est plutôt subtile (indentation, multiline, etc).

Tiens d'ailleurs la documentation redhat (qui est pointée par le site officiel d'ansible) ne respecte pas ce que tu décrit comme bonne pratique sur un getting started donc sur quelque chose qui est prévu pour être simple.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Scientologie quantique ?

Toute la discussion parle d'épistémologie des sciences. C'est un troll dans le sens original du terme : ça fait des siècles que c'est débattu et ce n'est pas 3 moules qui vont mettre tout le monde d'accord.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C’est pour cela que j’emploie le terme d’héliocentrisme car il décrit bien l’état des connaissances de l’époque.

Tu dis que c'est réel que ça existe indépendamment de l'état des connaissances humaines, que ce soit conscient ou pas. Ce n'était pas comme cela que les astres se déplaçaient même à leur époque et on découvrira peut-être que ce n'est pas autour du barycentre. Ces modèles décrivent une façon de représenter les comportements observés. Mais certains en parlent comme réalité, d'autres comme des outils mathématiques. La mécanique quantique est souvent avancée pour cela, on tente de décrire des phénomènes et leur plaquer des noms comme particule, spin, etc peut être vu comme plus proche d'une métaphore que d'une réalité.

Formuler une hypothèse ce n’est pas « modeler le réel », c’est proposer une explication en permettant la contradiction. La fraude ce serait de maintenir l’hypothèse face à la contradiction. Par exemple l’hypothèse du géocentrisme ne pouvait pas être une fraude en soi, mais la façon dont elle a été préférée a été entachée de fraude.

Mon usage du mot « modeler » apporte peut-être une confusion, je vois que tu parles de « modélisation ». Ici « modeler » est une métaphore pour exprimer le fait d’essayer de changer la forme d’une chose à sa convenance, je ne parle pas de modélisation ni de formulation d’hypothèse.

Mais c'est précisément ce qui se passe. On avait une théorie, on fait des observations qui ne correspondent pas, on a inventé un truc inobservable (c'est pour ça qu'on parle de noir) qui permet de continuer à faire coller la théorie aux observations. C'est une construction au même titre que l'éther d'Einstein. Ta formule ne correspond pas aux observations ? Ajoute un facteur et donne lui un nom.

Bien sûr la matière noire ou l'énergie noire ont ça de plus qu'ils tiennent bien plus longtemps aux observations. Mais c'est bien plus compliqué que ton assertion, les scientifiques passent leur temps à formuler ce genre d'hypothèses. C'est le rasoir d'ockham qui fait le tri.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ah au fait tu réagis sur mon emploi du mot « wokisme ». Je l’ai fait pour plusieurs raisons. L’une d’entre elles c’est que le mot « woke » signifie « éveillé », et ce type de langage est assez typique des dérives sectaires : les éveillés d’un côté, les non-éveillés de l’autre (wokisme), les sachant, les non-sachants (gnosticisme/occultisme), ceux qui éclairent, ceux qui doivent être éclairés (les lumières), etc. Ce genre de vocabulaire permet de soumettre les hommes à une hiérarchisation des personnes (qui peut mécaniquement se reporter en formation et hiérarchisation de classe), permet de justifier les relations de dominations entre personnes et permet de soumettre la raison à l’opinion. L’éveil devient alors premier et soumet le jugement. Il devient alors possible de soumettre même la description de l’observation physique, ce qui construit une illusion qui, puisqu’elle s’entretient elle-même et se développe au sein de la pensée, se brise par le contact avec le réel (souvent brutal : cf. l’image du loup qui peut attaquer même si l’on ne le voit pas).

C'est intéressant de la part de quelqu'un qui soutient le faut dilemme réaliste/idéaliste. Surtout en expliquant bien que la science ne peut être que réaliste et l'idéalisme c'est le créationnisme. L'antiréalisme existe est des scientifiques y adhèrent.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Plus kiss, mais sans idempotence ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ainsi donc, le réalisme suppose que si l’héliocentrisme est réel, il existe indépendamment de la connaissance éventuelle de l’homme. Si l’héliocentrisme est réel, le réalisme suppose qu’un calendrier cohérent avec l’héliocentrisme est cohérent parce qu’il est cohérent avec le réel, et non parce qu’il est cohérent avec un schéma de pensée. Le réalisme suppose que c’est la représentation que l’on ajuste pour faire coller au mieux avec le réel, et non pas le réel que l’on tente de faire coller à la représentation.

En ce sens, la méthode scientifique est aussi fondamentalement réaliste : la contradiction de l’expérience oblige à préciser la représentation du réel, et le réel ne peut être modelé pour satisfaire la représentation (sinon il y a fraude).

Contrairement à ce que tu semble avancer le réalisme scientifique est largement débattu. Mais c'est particulièrement cocasse de le défendre avec l'héliocentrisme. En effet contrairement à tes assertions très sûr d'elles, en l'état actuel de nos connaissances, la Terre ne tourne pas autour du soleil, mais autour du barycentre du système solaire (tout comme le soleil d'ailleurs). Il se trouve que la masse du soleil par rapport au reste des astres place le barycentre proche de son centre, mais c'est conceptuellement très différent et ça explique une partie des difficultés à construire un calendrier stable par rapport aux phénomènes solaires observable.

En ce sens, la méthode scientifique est aussi fondamentalement réaliste : la contradiction de l’expérience oblige à préciser la représentation du réel, et le réel ne peut être modelé pour satisfaire la représentation (sinon il y a fraude).

Ce sont loin d'être les seuls, mais la matière noire et l'énergie noire sont 2 exemples contemporains de modélisation arbitraire pour faire coïncider la représentation, les modèles, la théorie et l'observation. Parler de fraude me semble osé.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Quand tu en es à ce contexte de maintenance est-ce que ça ne fais pas longtemps que tu as garder en local une vm qui fait le taff et que tu garde précieusement parce qu'il est difficile d'affirmer que tu n'a pas un outil qui va t'exploser à la figure à la prochaine mise à jour ?

D'autant plus que ça me paraît cohérent avec la démarche. Si tu veux maintenir en mode "on ne touche plus à rien" ton livrable ou ton service, pourquoi ne pas le faire avec l'environnement de développement ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

De ce que je comprends, ils utilisent les API de dessins bas niveau. Ça permet de faire des formes géométriques etc, mais pour tout ce qui est composant graphiques ils ont leur propre composants qui tentent de singer ceux du système. C'est un enfer à faire car chaque composant a un comportement bien à lui (je parle pas de mac en particulier tous les composants graphiques sont un trésor de complexité). Ajoute à ça que plus tu t'approche du composant que tu singe plus tu entre dans une uncanny valley.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

La question ici, c'est vraiment : à quoi ressemblerai un framework correct pour manipuler des dates et des durées calendaires ?

J'utilise pas mal la bibliothèque standard de java pour ça qui est assez cool pour autant que ça puisse être, mais c'est assez gros.

Principalement on utilise 3 types :

• Instant : qui se comporte comme un timestamp (c'est un timestamp avec une précision à la nanosecond)
• LocalDateTime : qui est une date avec heure sans timezone (et qui est composée d'une LocalDate et d'une LocalTime)
• ZonedDateTime : qui est une date avec timezone à noter que la timezone peut être une ZoneOffset (+1, -4, etc) ou une ZoneId (Europe/Paris) très important pour gérer les changements d'heure (

Bon en plus de ça tu as pleins de types à coté :

• Month et DayOfWeek qui énumèrent la liste des possibilités
• MonthDay qui représente le jour d'un mois
• Duration en secondes + nanosecond

Bien sûr il y a aussi le formatage et le parsing qui sont des sujets à part entière avec leur propre erreurs possible (tu ne peux pas afficher la timezone d'un timestamp par exemple).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

J'ai encore un petit soucis par contre. Les unités temporelles :

• une minute c'est 60 secondes : FAUX, parfois c'est 61
• un mois c'est 30 jours : FAUX, parfois c'est 30, parfois c'est 31, parfois c'est 29, parfois c'est 28
• un an c'est 365 jours : FAUX, parfois c'est 366, parfois c'est 355

Ce ne sont pas des unités temporelles. C'est un calendrier.

La seule unité temporelle reconnue par le système international est la seconde, mais je crois qu'elle peut admettre l'utilisation des minutes/heures/etc. Mais quand on exprime une durée 1 jour = 24h = 1 440 min = 86 400s.

C'est quand on se place dans le calendrier que ça devient complexe, mais c'est pas une unité et ça ne se gère pas du tout de la même façon. Le problème n'est pas qu'une question de règles un peu compliquées, mais qu'il y a des conventions totalement arbitraires. Dans ce cadre la seconde ne fait même pas tout le temps 1s, ton ordinateur peut décider la réduire ou l'allonger pour s'aligner via ntp tout en gardant un temps monotone.

Je ne connais pas de langage qui gère le calendrier dans le langage. Ça fait plutôt parti de la bibliothèque standard. Le seul intérêt que je vois à l'ajouter au langage serait de faire des validations statiques de dates.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

• eMail : l’e-mail à tester en envoi/réception
• TimeOutMs : Time out in millisecondes, par défaut =30000
• ServerName : le nom du serveur ou son IP
• Login : nom d’utilisateur pour l’authentification
• EncryptedPassword : utiliser la commande -a pour le créer
• ImapPort : le port IMAP, par défaut =993
• ImapSSL : pour utiliser SSL/TLS, par défaut =true
• SmtpPort : le port SMTP, par défaut =465
• SmtpSSL : pour utiliser SSL/TLS, par défaut=true

Je comprends qu'utiliser EMail t'a gêné mais je trouve du coup le nommage moins cohérent. Est-ce que Target, Recipient ou Mail n'aurait pas était mieux ?

Sinon l'IETF n'utilise jamais cette convention, mais bien email/Email (par exemple dans le RFC5321).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

ce qui peut vite devenir assez moche en fonction du code que t’écrit

Pour utiliser abondamment les autres approches (try/catch, résultat genre optional monadique sur le quel tu fais des map/filter/flatmap/etc), je trouve le pattern matching très élégant.

Il est d'une part bien plus souple, tu ne discrimine pas forcément les erreurs/résulats, mais les résultats vides par exemple.

En terme de performance ça peut devenir génial avec de l'inline de code et si le compilateur a le droit de supprimer cette structure et tu peux te retrouver avec des appels sans gestion d'erreur si le compilateur a pu déduire que l'erreur n'était pas possible (ou simplement que le cas n'est pas possible) dans cet appel là. Dans le pire cas c'est une if très simple.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Oui mais ces 3 clicks étaient violents. Les souris s'en souviennent !

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Les critiques de ce genre de démarche parlent du trust du build, de ce qui pourrait être ajouté ou non au binaire.

L'exemple le plus connu c'est vscode. Il y a du code libre accessible à tous, mais de ce que j'ai lu le binaire fourni par ms, ne contient pas que du code libre.

Encore une fois moi je m'en fous, mais c'est un choix personnel de ce que je considère acceptable ou pas et il peut varier selon d'autres critères (par exemple est-ce que le non libre des binaires autorise la décompilation pour étude).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Il y a un fort biais des gens aimant le libre communautaire à vouloir croire que c'est le seul libre possible et le seul long terme

Je n'aime pas le copyleft, mais le copyleft partagé est, il me semble, le moyen le plus fiable de garantir que le développement ne deviendra pas fermé.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Peut-être ma sélectivité subjective[…]

Moi je m'en fou, mais certains se sentent concernés et j'en ai vu s'en plaindre entre autre pour vs code.

je trouve limite RH par rapport à Mozilla par exemple est que le rebranding est rendu volontairement complexe

Ainsi que de prédater leurs alternatives en te demandant de pas mixer du alma/rocky avec du RHEL.

Et sinon vendre du support est un business model du libre, oui.

Mais il ne s'agit plus de « commercialiser du logiciel libre ».

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ou RHEL pour une distro complète. Pareil, il y a des versions sans la marque qui pullulent (gratuite) car il y a une demande, mais ça n’empêche pas l'entreprise d'être rentable sans pour autant faire du non libre (les binaires en soit sont certes non libres mais on peut tous recompiler et avoir en libre la même fonctionnalité, RH ne faisant pas de code lié à la distro en non libre à ma connaissance).

Donc ils vendent du non libre au final et du support, non ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Les utilisateur aiment se plaindre pour un tout et pour un rien.

Avec ce genre d'état d'esprit on va pas très loin, non ?

De mon expérience, les plateformes habituent ou pas à avoir des interfaces hétéroclites. Moi j'utilise awesome chez moi, i3 au boulot, je lance des applications en Qt, Gtk (différentes version), java swing ou tk j'm'en fou. Utilisateur qui a l'habitude (comme ça semble être le cas sur mac) d'avoir une cohérence bien plus forte, des détails vont être vu comme très désagréables. Ce n'est pas de la faute de l'utilisateur et le lui reprocher ne fait avancer personne.

Après à voir comment vous vous positionnez par rapport à ça. Est-ce que votre valeur est avant tout dans le multiplateforme ou un niveau d'intégration solide ? Etc Ça dépend de ce que vous voulais faire et de ce qui est demandé par votre cible d'utilisateurs.

Mais au final, le résultat avec Qt est pas trop mal. (Et je pense que un des problème avec Qt est que les plateformes de bureau sont un peu délaissées en ce moment.)

Ou alors c'est que c'est pas si bien que ça. Perso j'en sais rien (et j'm'en fou en soit), c'est juste que tes remarques se valident entre elles dans un cycle que je voulais faire remarquer.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C'est pas un boilerplate c'est in cas d'erreur supprimé car vérifié par le compilateur. Ce n'est pas une question de verbosité mais de fiabilité.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll