barmic 🦦 a écrit 5211 commentaires

Ça permet d'associer des tag, mais il faut tout de même avoir un index à coté.

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

Tous les logiciels n'ont pas les même contraintes. Il y en a un paquet qui ont une configuration très spécifique. Si on omet vim&emacs qui utilisent leur propre langage pour se configurer tu peux trouver des logiciels comme awesome qui utilise lua ou i3 qui a un format bien à lui.

En tant que lead tech plus intéressant que de savoir s'il faut remplacer tout ce que tu as avec ça, ce qui me semble plus intéressant c'est :

• de comprendre l'intérêt/la philosophie/l'objectif pour envisager comment est-ce que c'est actuellement pris en compte (ou non) dans ton quotidien. S'intéresser est toujours plus enrichissant que de démonter
• avoir potentiellement une nouvelle techno si un jour le besoin se fait sentir

Après tu aura tous pleins de cabinets de conseil qui te sortiront des graphe de techno classées comme "expérimentale", "bleeding edge", "stable" et "deprecated". C'est à mon avis plus intéressant de regarder ce qui se fait et d'avoir son propre avis.

Tiens c'est marrant il y a un super fonctionnalité : il peut générer un sha256 de la configuration, mais il le fait sur la sémantique de la configuration et pas sur le fichier. Ça peut être super utile.

Après il y a effectivement la confiance que tu fais en vers les développeurs de dhall, c'est à toi de voir de la même manière que tu fait confiance à d'autres projets. Il n'y a pas que la pérennité qui soit importante. Pour m'avoir fait sauter ma configuration dans une version micro je suis méfiant d'haproxy par exemple.

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

Mais la réalité reprend vite le pas. Pour s y retrouver dans ses fichiers il faut bien savoir où ils sont. Pour en faire un backup par exemple.

Je ne pense pas que ce soit par qualité intrinsèque que la hiérarchie survie, mais plus par l’absence de convergence des solutions plus récentes. L'arborescence est l'organisation qui est la plus interopérable.

Alors on peut imaginer des solutions pour indexer etc mais en complément d'une bonne vieille hiérarchie, on ne peut pas opposer les deux.

L'utilisation de plus en plus répandue de iOS et Android semble montrer que l'on peut vivre sans arborescence.

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

Je pensais éventuellement développer un script python pour stocker les tags liés à mes fichiers mais cela me semble difficile en repartant de zéro (de faire quelque chose de bien en pensant à l'ensemble des cas d'utilisation et sans y passer des heures et des heures).

Ce n'est probablement pas la bonne approche. Il ne faut pas tenter de tout faire et monter un cahier des charges complets, puis implémenter un truc, mais plutôt faire quelque chose de très simple qui te soit déjà utile. En l'utilisant tu en verra les limites et tu améliorera.

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

Ça c'est autre chose. C'est des choix de techno que tu fais et qui ne sont pas intrinsèque aux techno. Mais reprocher à une techno qui se présente qu'elle n'est connue de personne, c'est dommage. D'autant que c'est un point qui a un minimum était envisagé puisqu'il peut générer du yaml et du json. Ça ne fait pas tout bien sûr. Mais disons que si c'est pour dire que personne connait, on était au courant je pense.

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

Je dois avoir un peu trop en tête l'organisation d'un serveur d'application web, avec le backend contrôlé par API REST, et un serveur frontend qui sert du HTML plus ou moins statique.

Même avec du REST tu as un certain couplage entre la manière dont tu fait ton UI et la manière dont tu fait tes API. Il faut aller voir du coté de GraphQL pour voir des choses ou ça commence à être pas mal découplé.

D'ailleurs, je ne sais pas si il existe des frameworks de dev lourd qui arrive à avoir cette séparation claire entre interface et backend.

C'est un design d'architecture, tu n'a pas forcément besoin d'un framework pour le faire. C'est le genre de séparation que tu pourra trouver dans le privilege separation chère aux développeurs OpenBSD. Eux implémentent ça sous la forme de 2 processus le parent a des droits en plus et le fils va tourner avec le minimum de privilège.

L’intérêt est aussi d'utiliser des technos différentes. En général, les techno d’affichages vieillissent bien plus vite que les règles métiers.

Le mieux est sans doute de construire une bibliothèque, non ? C'est ce qu'il y a de plus simple et ce qui entraine le plus faible surcoût.

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

Et de toute façon, même si la validation de Dhall dit que tout va bien, ça ne veut pas dire que l'appli va fonctionner avec cette conf, donc ça ne dispense pas de tester en pré-prod ou de faire du A/B testing.

Alors oui, mais c'est pas pour ça que ça n'a pas de valeur. Attraper un problème un problème de conf en CI et l'attraper lors de ton A/B testing n'a pas du tout le même coût. Tu as beau avoir polis ton process autant que tu veux la boucle de feedback n'est pas du tout la même.

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

J'ajouterais que ça n'est pas une solution originale, parce qu'utiliser un language de programmation pour la conf, ça a déjà été testé dans plein de domaines (sites PHP, Chef, …) et que c'est désormais un antipattern notoire. Oui, Configuration As Code, il ne faut pas le prendre littéralement ;-)

Notoire ? Faudra en parler à la plupart des gens qui font de la CI/CD.

D'ailleurs tu commence par :

Au sujet de la complexité, les formats de fichiers de conf devraient avoir les plus simples possibles, parce que c'est commode de pouvoir les générer automatiquement lors de déploiement automatisés sur un parc de machine.

Donc tu montre bien que tu l'a cette complexité. La mettre dans un moteur de template ou dans le fichier de configuration c'est relativement subtile en fin de compte, il y a des arguments pour les 2. D'autant que les moteurs de templates sont généralement bien plus complexes que dahll. Le mettre dans la configuration simplifie drastiquement les déploiements, mais il ne marche pas avec tous les outils, l'utilisation d'un template permet de capitaliser, mais laisse passer des erreurs (si tu as déjà fais des templates yaml tu as déjà eu la contrainte par exemple sur le typage).

Au lieu d'essayer d'affirmer que ton point de vu est la norme (d'une je suis pas convaincu que ce soit la norme de deux c'est un appel à la population pas forcément intéressant) pourquoi ne pas juste présenter les avantages/inconvénients et ouvrir la discussion plutôt que la fermer ?

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

C'est une unité de calcul dédiée à la sécurité. Il implémente différentes fonction de sécurité. L'intérêt c'est qu'il est possible de séparer physiquement (quand il s'agit d'un véritable circuit) les données sensibles du reste. Dans l'exemple décrit la clef privée déchiffrée ne sort jamais du TPM. En cela ça se rapproche d'un HSM (il en est peut être un d'ailleurs ?).

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

Merci pour ton article c'est super intéressant

Le moteur est donc effectivement bien installé, et donne accès aux fonctions relatives à RSA ainsi qu’au générateur de nombres aléatoires.

Il est pris automatique comme source d'entropie par le noyau ? Est-ce qu'il lui fait particulièrement confiance ?

Je ne connais pas trop TPM, j'ai lu que souvent c'était implémenté dans les CPU en firmware, mais mon nouveau CPU dernier cris de chez AMD ne semble rien avoir pour ça.

Utilisons cette dernière pour chiffrer un fichier (le TPM n’est pas impliqué ici, le chiffrement ne faisant appel qu’à la clef publique) :

J'imagine que pour cet usage, il faut faire attention car, je présume qu'il n'est impossible de sortir la clef privée. Donc le document chiffré est indéchiffrable ailleurs. C'est ça ?

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

Par contre clairement au final, pinailler sur ce point va faire perdre beaucoup de temps à beaucoup de gens si on fait un rapport de bug et qu'on se met à discuter dessus. Donc si je devais lever les yeux au ciel, ce serait plutôt pour cette raison.

Je suis plutôt d'avis que c'est l'absence de choix qui fasse perdre du temps. La règle aujourd'hui dans gimp c'est d'avoir les 2 points ? Très bien établissaient le coller une règle et indiquez que pour remettre en cause ces règles il faut de solides arguments (plus qu'une apparente inutilité ou un esthétique subjective).

Le changement paraît anodin, l'établir comme règle permet de mettre en évidence que c'est un choix qui a un impact.

Je ne dis pas de le faire pour le cas présent, vous gérez le projet comme vous me voulais et vous faites ça très bien. C'est plutôt pour éventuellement donner des idées.

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

J'y jetterai sûrement un œil plus tard.

Souvent quand il y a des remarques faites sur gimp. Tu nous explique que tu t'en occupera. C'est super, mais ça me donne l'impression que tu prends les remarques comme des demandes personnelles. Ça peut très bien être quelqu'un d'autres. Je serais moins surpris qu'au lieu de généralement finir sur toi qui dit « je l'ajoute à ma todo liste » la conclusion soit « il faut l'ajouter à la todo list du projet aka il faut rapporter un bug ». Après je dis ça pour toi, hein :)

Personnellement je trouve cela tellement mineur que j'ai pas envie de perdre du temps dessus. Et j'ai pas trop d'opinion sur le sujet. Mais si quelqu'un trouve cela absolument primordial et que personne dans l'équipe n'est contre, j'accepterais un patch faisant le changement sans problème.

J'ai presque l'impression de te voir lever les yeux au ciel en levant les épaules en parlant de primordial. C'est un travaille de finition c'est toujours bon à prendre même si ça n'est pas le cœur GEGL/algorithmique de gimp. Ça pourrait avoir sa place dans les bugs Newcomers du projet.

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

Les commentaires juste au dessus du tiens pointent des algos de mariages stables et décrivent les propriétés des résultats.

Comme indiqué par rewind, ils ne peuvent plus être utilisés par choix politique.

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

Il me semble que toutes les solutions « modernes » sont surtout moins fortes. Elles nécessites de faire confiance à une entité sur la quelle tu n'a aucun contrôle. Que ce soit utile pourquoi pas, mais il est nécessaire d'avoir une solution qui ne porte pas ces problèmes.

De plus il faut remettre en contexte. Cette technologie que vous jugez désuète, vous vous appuyez probablement dessus. C'est un outil de travail nécessaire pour signer ses commits git et c'est ce que les gestionnaires de paquets utilisent pour vérifier les paquets avant installation par exemple. En parler comme d'un truc inutile, je trouve ça un peu rude.

Je ne vois pas en quoi le fait que vous n'en voyez pas l'usage et que vous ne savez pas vous en servir en fait une technologie désuète ?

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

Avoir un postgresql géré à coté, c'est un peu l'inverse des préconisations microservices, non ? Tu ne peux pas avoir un soft qui se créait sa propre base de donnée et l'utilise (par exemple avec helm).

Ça se discute, mais en principe tu ne va pas laisser un service manipuler helm ou même manipuler ton cluster comme ça, ne serais-ce parce que ça pose des problèmes d'un point de vu sécurité. L'idée dans les microservices c'est qu'un service soit seul maitre de sa données. Le fait qu'il crée dynamiquement sa base ne me semble pas être une nécessité et il n'est pas obligé d'avoir sa propre instance de base de données, je ne vois personnellement pas de problème majeure à ce que plusieurs services utilisent des bases de données différentes au sein du même postgres. Bien sûr il y a un niveau de couplage du coup (si tu as des configurations transverse à tes bases postgre elles impactes tout le monde, la charge n'est pas forcément segmentée,…) c'est un choix à arbitrer.

Si tu veux complètement découper, tu va utiliser un controller. C'est un type de container particulier qui est là pour manager des pod. Au déploiement ton service va aller demander une base à ton controller qui va créer la base si nécessaire et te répondre avec les accès qui vont bien. Tu peux même jouer à donner un utilisateur différent à chacun des pods de ton service. Ce qui est particulièrement cool d'un point de vu sécurité. Ça peut te donner des possibilités sympas comme le fait d'utiliser effectivement des instances différentes en prod, mais d'utiliser un seul cluster dans des environnements de dev/test qui sont généralement moins gros.

En tout cas, je note que l'on est loin d'avoir une solution pérenne et performante pour gérer les données persistantes dans k8s.

C'est un gros, vieux et long débat :)

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

C'est vrai. Mais je suis très stressé sur la pérennité des données que je reçois.

Effectivement ça a l'air assez complexe. Nous les stockage qu'on veut fiables sont hors k8s et je pousse pour qu'on fasse quelque chose d'assez simple là dessus : quand les données arrivent on les prends et on les envoie dans un cassandra tel quel. Ensuite on en fait les calculs qu'on veut et on peut reconstruire les données calculées à partir de leur sources (je n'aurais pas la prétention de dire que c'est de l'event sourcing parce que ça ne respect pas tous les concepts qui y sont associés, mais ça s'en approche).

Celui dans ceph permet de faire des snapshots de postgres pour démarrer une stack de dev avec les même données que dans la prod et alimenté par le kafka. Stack qui est démarré automatiquement quand je pousse une nouvelle branche dans gitlab.

Ça c'est cool ! Nous on l'a pas et ce serait difficile à mettre en place (il faut une étape de changement des données pour ne pas faire n'importe quoi d'une part et être respectueux des données utilisateurs d'autre part). On est en mesure de rediriger le flux de prod (avec justement les filtres qui vont bien, vers l'environnement que l'on souhaite).

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

On utilise la réplication d'es pour ça chez nous.

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

Ceph c'est plus pour les disques de elastiksearch, prometheus, pour notre owncloud et comme object storage.

Je ne connais pas les autres ('fin non je connais owncloud et je vois très bien l'intérêt), mais elasticsearch gère sa propre réplication ça n'est pas dommage d'avoir un cluster es sur un cluster ceph ? Ça réplique de la réplication avec des logiques très différentes et des niveaux de garanties très différents.

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

Ceph n'est pas une obligation mais avoir un stockage partagé oui.

Nous on en utilise pas. En quoi c'est une obligation ?

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

j'ai juste vu passé le nom "Helm"

helm c'est l'un des outils qui est là pour générer des configurations k8s et les appliquer. Il permet de faire des templates et de les versionner (et donc de les rollback par exemple). C'est probablement le plus sophistiqué (il gère son propre versionnement, permet d'envoyer ça dans des dépôts,…). Mais il y a un paquet d'alternatives kustomize, pulumi, crossplane, kompose,…

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

Ensuite il faut aussi installer et donc maintenir un cluster Ceph pour le stockage ce qui rajoute de la complexité et du temps pour faire l’exploitation.

C'est pas une obligation. Nous on ne déploiement pas nos bases de données sur kubernetes. L'intérêt est très faible pour nous, on a très peu de mouvement sur nos config de db, ce sont des machines spécifiquement taillées pour des bases. Les mettre dans un k8s apporterait quelques trucs, mais pas suffisamment pour qu'on ai envi d'aller se battre avec les volumes et déployer un service comme ceph ou autre. On s'appuie sur les mécanismes natifs des bases pour avoir une haute disponibilité.

Par contre on a un déploiement kubernetes en multimaster ce qui demande un peu de travail en plus de config et de test (ne serais-ce que pour voir comment ça se comporte).

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

En plus de ce genre de communication (qui n'existe pas que pour krita), il y a aussi je pense un coté grégaire : si tu n'utilise pas le même outil que moi il faut que je t'explique pourquoi le miens est meilleur. C'est très dommage, ça crée des clivages artificiels. Je comprends qu'on veuille valider et faire valider nos choix et aussi qu'on crée un affect avec les logiciels que l'on utilise, mais c'est dommage d'aller jusqu'à faire de l'entrisme ou au dénigrement.

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

Je ne dis pas le contraire (c'est je trouve très bien expliqué dans le lien que je donne dans un autre commentaire), je dis que la distinction entre un algorithme classique et un algorithme d'apprentissage est totalement ignoré par le béotien. On médiatise beaucoup sur les dangers des algorithmes et de la gouvernance par les algorithmes. C'est normal de faire le cheminement pour parcourtsup. Il aurait était probablement mieux d'expliquer plutôt que d'acquiescer.

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

Le côté « programmable » des fichiers de configuration est apporté avec jinja dans ansible, et complètement dissocié du langage dudit fichier.

Et c'est bien daubé. Ansible utilise jinja, helm utile gotemplate c'est un enfert à lire à écrire, à parser,… Parce que tu as justement 2 langages complètement dissocié. Ils ont un typage différent, ta coloration syntaxique est aux fraises selon les outils que tu utilise,…

Définir séparément les langages de description et de template pourquoi pas ne pas regarder l'un quand tu utilise l'autre ça amène pas mal de problème. On vit avec, mais ça n'a vraiment pas le goût de « la bonne solution ».

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

Le ministère a voulu «remettre de l'humain dans la procédure» mais au final, on a introduit la sélection et le bouzin met des plombes à converger et les critères sont devenus totalement opaques et on n'a plus aucune garantie que l'affectation est optimale.

Pas que le ministère c'est aussi une pression publique. De ne pas vouloir de gouvernance par les algorithmes sans distinguer (ce qui est véritablement complexe pour le non initié) des algo de mariage stable d'un réseau de neurones profond.

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