barmic 🦦 a écrit 5213 commentaires

Si Ubuntu pousse autant Snap que ça, alors oui il y a peut-être motif à se plaindre…

Bof. Chaque distribution crée choisit son système de packaging. Si les développeurs d'ubuntu font ce choix c'est les premiers concernés. Pour moi c'est comme reprocher à Debian d'utiliser les .deb, à mageia les rpm, à nixos nix,… C'est pas comme s'il n'y avait pas du choix.

De plus il est difficile de distinguer ce qui est un problème de snap de ce qui vient d'un paquet mal fait.

Tout comme flatpak, ils tentent non seulement d'être un système de paquet mais aussi un environnement d'exécution et l'un comme l'autre mette du temps à arriver à maturité.

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

Tu vises quoi ? C’est quoi ton but ? C’est quoi ta proposition ?

De ce que je comprends de ton commentaire. Tu dis que si tu n'a pas écris ton propre contrat de travail c'est que tu ne sais pas dire non, que tu as accepté sans broncher ce qui t'était proposé. C'est simpliste.

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

Ma première phrase de mon premier commentaire du thread :

Contrairement à ce que tu semble avancer le réalisme scientifique est largement débattu.

Tu avais fais un long commentaire présentant le réalisme scientifique et renvoyant tout le reste à de l'idéalisme. C'est je trouve bien réducteur pour parler d'un débat plusieurs fois centenaire et qui est toujours en cours. Ignorer les anti-réalistes, c'est vraiment ne voir qu'une toute petite partie du sujet.

Je n'aurais probablement pas réagit et laissé le sujet là où il était si tu ne te servais de cette dichotomie biaisée pour faire un parallèle politique douteux.

C'est probablement agaçant, mais quand on utilise des arguments fallacieux pour avancer des idées politiques on s'expose à des discussions longues.

Le fait ou non de confirmer ta citation n'a rien d'intéressante pour moi. Tu aurais jugé plus simple de pouvoir avancer tes idées sans contradiction. Ce n'est pas le cas.

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

C'est bizarre tu ne dit pas que c'est faux juste un équivalent de "j'aimerais bien t'y voir".

Bref, toute personne qui aurait déjà signé une fois dans sa vie un contrat de travail sans l’amender, juste une fois, ne peut faire de critique sur ce qui m’est arrivé : son bien être ne dépendait que de la bienveillance d’autrui, et pas de lui. ;-)

Contrairement à ce que tu semble présenter le choix ne se résume pas à signer ou amender. Tu peux refuser de signer, tu peux ne pas vouloir être employé,… Des options autres où tu es acteur de ce qui t'arrive.

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

PrivateBin C'est un peu différent, ils font du chiffrement côté client pour que le serveur n'est jamais la donnée en clair. TLS ne sécurise que le canal de communication les données sont en clair une fois sur le serveur.

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

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