Alex G. a écrit 654 commentaires

Oui tu es d'abord censé "retirer la ligne" (state absent au lieu de present) puis retirer la tâche.

On est d'accord, et je n'ai jamais dit que ce devait être magique, mais vraiment il y a des commandes où cet état présent/absent n'est pas géré par la commande. (bon en tout cas à l'époque où je l'utilisais).
C'est peut être aussi les rôles qui manquent parfois de maturité (et n'ont pas de vrai désinstallation).

Au final je trouve en tout cas que la promesse de "déclarer un état" n'est que très peu tenue.

Bravo pour votre projet. Monkeyble est sûrement tout à fait utile pour améliorer les playbook, mais ça ne me semble pas suffisant.

les ressources Ansible sont des "modèles d'états souhaités"

Perso ce qui m'a éloigné de Ansible c'est justement que cette phrase est fausse ! Rare sont les modules Ansible vraiment écrits comme ça.

(attention, mon expérience date un peu, si des choses ont changé c'est super)

Un des manques criant, par exemple, est le nettoyage des tâches supprimées (si j'enlève une tâche qui ajoute une ligne dans un fichier de conf, cette ligne restera là où elle a été mise), il faudrait plutôt que Ansible gère un état on/off.

Pour assurer sa maxime, Ansible devrait drastiquement limiter les modules à ceux capable de gérer ces cas là, mais ce n'est pas vrai de la plupart des modules de base même…

J'ai beaucoup souffert à déverminer des playbook qui avait fait l'objet de maintenance, qui pouvait run sur la machine de prod, mais était incapable de ré-installer une machine à partir de zéro… ou le contraire !

Bref perso je suis bien plus content de l'approche Docker pour le moment: rebâtir tout de zéro à chaque fois, sans arrêt ! (mais oui, ok, Docker ne va pas faire l'install du système sosu jacent, donc il faut un truc, mais je le limite au maximum)

Si je devais faire du déploiement automatisé je chercherais autre chose que Ansible, peut être pyinfra pour éviter le cauchemar des yaml imbriqués les uns dans les autres (et qui s'appellent tous "main.yml" ;-) ).

Déjà savoir qu'un playbook qui run jusqu'au bout c'est un bon signe, car le playbook peut lui même contenir les tests que l'environnement déployé fonctionne (c'est mieux en général !) par exemple avec un check sur une url publique, ou une petite requête BDD, etc.

Il me semble que c'est pas mal écrit.

1. Ça me semble vraiment une piste intéressante pour développer des apps décentralisées sans trop changer de paradigme de programmation.
   Décentralisé à la https://scuttlebutt.nz/ ou tu te connecte aux autres occasionnellement (capacité d'être off-grid, très intéressant pour une décentralisation jusqu'au niveau de l’ordinateur personnel).

2. Pareil pour le monde mobile où tu veux pouvoir fonctionner en off-line puis push tes modifications. (je sais que c'était un des cas d'utilisation de couchDB sur mobile).

Le serveur d'Open Food Facts est en perl :-)
https://github.com/openfoodfacts/openfoodfacts-server/

La différence quand même c'est que tu peux auditer le code du client Signal, et voir par exemple que ta clé privé reste sur ton téléphone. Sur whatsapp tu n'as aucune garantie qu'il n'ont pas ta clé privée…

Comme on pouvait s'y attendre j'ai eu une fin de non recevoir: https://github.com/neo4j/neo4j/issues/12920#issuecomment-1226941038

Yes, cf le commentaire ci-dessus :-D

Quand j'ai regardé Arango j'ai eu l'impression que ce n'était pas très spécialisé graph mais que l'accent était plus mis sur le coté "document". Or dans mon cas il me semblait que c'était l'aspect graph qui était plus présent. (On y allait déjà à reculons de prendre un nouveau type de database sachant qu'on a déjà du mongodb, elasticsearch, postgresql…). Mais bon c'est sur c'était un choix un peu à l'intuition…

Maintenant on est un peu engagé avec du code Cypher (le language de Neo4j), mais oui à voir !

En fait tu as peut être raison et c'est cool de creuser.

Bon, pour le futur, car dans l'immédiat on est engagé avec du code historique (coté Perl) et un projet bien démarré (côté Python) !

Le problème du monde des ontologies est peut être la complexité perçue de l'extérieur (je m'y suis un peu intéressé déjà).
L'autre chose pour moi est qu'il me semble qu'on ne définit pas tant des concepts au niveau ontologiques (des classes de concepts) mais plus des instances (un catalogue).

Ce qui me fait dire ça:
1. on instancie des propriétés (par exemple le lien avec une instance de wikidata)
2. on a pas des relations différentes à décrire à chaque fois, c'est très simple on a juste la notion d'héritage, mais les propriétés, ce qui est définit etc se répète partout pareil.
3. si tu regardes bien tu verras qu'un des intérêt majeur pour nous est de traduire en plein de langue et de construire les "synonymes" (en les listant mais également grâce à une liste de synonymes généraux qui sont utilisés par inférence), je vois mal comment mettre ça simplement dans une ontologie.

À noter d'ailleurs que ce n'est pas une hiérarchie au sens "arbre" mais plutôt un Graphe orienté acyclique

Du coup, je ne vois bien qu'on pourrait définir une ontologie des composant d'une taxonomie (dire qu'il y a des synonymes, des parents, des propriétés) et définir la taxonomie comme un RDF, mais je ne vois pas bien ce que ça apporte ici (ça met juste un schéma sur ce qui existe, et ça n'apporte pas un fichier facile à éditer, alors que le format actuel est vraiment pensé pour une édition à la mano, donc compacte et assez facile à lire).

En tout cas je trouve ça intéressant et un premier pas pourrait être de montrer à quoi ça pourrait ressembler une petite taxonomy en mode ontologie et voir quels outils éventuels ça unlock. Tu viens contribuer :-D ?

Oh là là quelle bonne nouvelle !

On sait au moins qu'on a un backup :-)

C’est déjà complètement le cas avec la preuve de travail, concrètement.

Oui et en gros l'auteur dit que même en changeant le modèle, les blockchain on complètement échoué dans leur aspiration initiale (la décentralisation).

https://blog.dshr.org/2022/02/ee380-talk.html est un article hyper-intéressant.

Je l'avais lu il y a quelques temps et ce que j'en ai retenu (de mémoire), c'est que si le proof of stake (preuve de participation) règle le problème énergétique, il ne va pas changer un problème qui est pourtant celui qu'est censé résoudre la chaîne des bloques, celui du contrôle du réseau par très peu de monde…

Selon l'auteur c'est un des points faible du proof of stake, il va y avoir mécaniquement un effet d'accumulation sur quelques acteurs (ceux qui ont les moyens d'investir, de mobiliser de la monnaie en participation), ce qui est déjà un peu le cas avec la preuve de travail (où on a quelques grosses fermes car il y a des économies d'échelles). Bref on ne va pas favoriser un vrai participation "répartie".

Comme souvent en cryptographie ce n'est pas le cœur "théorique" de l'algorithme d'où vient le danger mais plus les contingences matérielles, ce qui vient autour (cf. par exemple les Attaque par canal auxiliaire).

Juste pour info, pour créer des connexions distantes et chiffrées entre machine, il y a aussi stunnel.org qui est pas mal (et dans l'esprit de tunnels ssh).

On peut le configurer avec des clés ssh, mais également avec un simple token partagé (psk). Voir ici: https://www.stunnel.org/auth.html

Malgré les réponses de CrEV (qui n'est clairement pas neutre, et c'est normal) je suis complètement de ton avis, et ça m'attriste. On voit clairement que Linux est le parent pauvre / n'est pas la cible des décideurs de chez Docker.

Ce ne sont pas les perfs qui me chagrinent si je mets docker dans une VM, c'est le fait que je dois réserver par avance la mémoire et l'espace disque… et ça vraiment, surtout pour la mémoire, c'est un grosse perte en pratique (docker a fait sa pub comme étant beaucoup plus rapide / flexible que les VM, c'est quand même marrant de le voir se justifier d'être dans une VM, même si c'est pour les développeurs…).

Bref j'ai l'impression que Docker n'a pas trop levé le petit doigt pour les développeurs sous Linux. Ça me chagrine, car je suis sûr qu'ils vont concentrer beaucoup d'effort sur la version desktop, qui en soit aurait été sympa à avoir, mais moi dans ces conditions, ce sera clairement non.

Moi j'ai bien aimé le projet pyinfra (sans l'avoir testé sur de gros projets).

C'est KISS là aussi, et perso mon expérience (plusieurs années) avec Ansible, m'a fait penser qu'à la fin c'est mieux de pouvoir programmer… (avec Ansible je me retrouvais souvent à utiliser les boucles, et des siouxeries de manipulation des variables, qui auraient été bien plus simple en python).

Je plussoie pour dire que Ansible se dit idempotent et souvent on lit que l'on décrit l'état plus que le processus, mais en pratique ce n'est pas vrai du tout. Quelques briques font effectivement ça, mais plein de brique ne le font pas du tout. Par exemple la suppression d'une ligne ajouté par un run précédent du programme n'est pas forcément géré (suivant la directive utilisé).

Je ne jette pas la pierre à Ansible, ça reste un outil correct, mais en pratique il faut tester les scripts ansible, tout comme le code, et Docker, avec son redémarrage de la feuille blanche à chaque fois, est plus prédictible (ce n'est toutefois pas le même scope que ansible, on est d'accord).

Perso je trouve ça juste. On parle de projets privés importants qui utilisent un produit "gratuit".

Je me rappelle il y a cinq ans, on avait discuté en équipe de passer sur gitlab.com (jusque là on avait un git self hosted) et j'avais proposé à l'équipe (et au patron) de payer, car ça semblait plus juste et que le prix était vraiment raisonnable, et ce même si on pouvait créer des projets "privés" gratuitement. C'était une question de soutenabilité. Et ça a fait facilement consensus. (la boite était aussi basé sur un modèle freemium, donc on savait bien ce que ça voulait dire !)

Ouais mais tu peux imaginer avoir fait des 1kg de plomb une grande feuille de quelque nano-mètres et du coup ça fait moins mal :-)

Te faire insulter, espèce de moule bigleuse ! ;-)

En effet, le calcul de l'éco-score reste un peu approximatif dans certains cas, car nous manquons parfois de données et devons utiliser le produit le plus proche de la base Agribalyse. Nous avons justement un projet en cours (pas loin de la publication) qui permet d'évaluer la recette pour essayer d'avoir un éco-score plus précis.

Mais dans le cas que tu pointes, c'est la catégorie qui n'était pas bonne: couscous préparés --> coucous à la viande. J'ai corrigé (mais on voit bien le travail de qualité que peut faire la communauté). On veut notamment faire des systèmes de règles pour corriger ce genre de problème. Genre : coucous préparés avec ingrédient viande --> couscous à la viande

Pour ce que le sujet intéresse, j'avais rapidement testé https://scuttlebutt.nz/ et trouvé ça très intéressant (le seul truc que je n'avais pas trouvé encore abouti était l'utilisation disque un peu haute, mais ça pourra s'améliorer).

L'idée est d'un réseau où chacun à sa chaînes de notes. De temps en temps on peut se connecter en allant au "café" (virtuel, où imaginons aussi un endroit) et synchroniser nos notes et du coup synchroniser aussi les flux de nos amis communs.

Dans un interview vidéo de veritasium à Bill Gates (lien youtube), il admet lui même qu'il a dit à Oxford de plutôt faire un partenariat avec une entreprise pharmaceutique plutôt que de donner la formule du vaccin. Et il se justifie en disant qu'un vaccin doit être réalisé par des laboratoires de confiance. (à chacun de juger…).

Il me semble que tu fais un jugement d'intention sur toute la ligne (sur mes intentions et sur leurs intention).

En quoi je suis "fan" des non libristes, au contraire, j'aimerais que la communeauté travaille à convaincre qu'il y a un chemin possible avec le libre.