barmic 🦦 a écrit 5926 commentaires

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

je ne leur jete pas trop la pierre, si c'est une boite privée qui l'avais pondu, ca aurait couté plus chère ET ca ne fonctionnerais pas.

Bien sûr on montre les exemples qui marchent le moins, mais les logiciels de l'état ne se limite pas à quelques exemples comme louvois. service-public.fr et ces prédécesseurs fonctionnent bien par exemple.

peut etre faire un logiciel libre sur gitlab avec des domaines attribué au université informatique/ministère + les contributeurs bénévole, un peu comme linux.

1. ce serait bien de rétribuer les développeurs seul l'état en a un intérêt donc ça se rapprocherait beaucoup de l'existant
2. c'est quoi le modèle de gouvernance du projet ? il peut y avoir des pressions fortes de la part de contributeurs pour pousser des idées dans le code (ça existe potentiellement déjà, mais c'est exacerbé en acceptant des contributions extérieures)

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

Du point de vu dev oui, c'est la stack de déploiement qui me donne l'impression de se chercher. Éventuellement la configuration (ce qui est fait avec helm ou kustomize par exemple). L'état de l'art de la manière d'empiler orchestrateur + runtime + dépôt + configurateur évolue évolue pas mal (je dis pas qu'il n'a pas à évoluer, je dis que se tenir à jour demande un travail conséquent et une compréhension relativement approfondie). Et il faut séparer les annonces des réalités, beaucoup d'entreprises font des annonces ou des gens publient des articles, mais sans forcément qu'il y ai quelque chose derrière ou que ça prenne (kubernetes pour des machines virtuelles, il y a plus de gens qui en parlent que de gens qui en utilisent par exemple, IBM annonce des fois des outils pour orchestrer des orchestrateurs,…).

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

swarm en prod

On utilisait ça pendant pas mal de temps, le passage à un orchestrateur plus complet est assez salvateur. En tout cas quand tu déploie sur plusieurs machines. Rien que la répartition des instances sur les serveurs n'est pas folles avec swarm. Le passage à docker stack ou une alternative, ça demande un effort de s'y mettre mais le retour sur investissement et plutôt pas mal je trouve.

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

Pour en ajouter une couche :)

Le paradigme "tout est fichier" commun aux unix est une base sur la quelle les différents unix ce sont construit.

La base c'est de considérer toutes les entrées/sorties des programmes comme des fichiers (donc la sortie standard aussi, les pipes, les sockets,…).

Du coup je suis allé vérifier les pseudo systèmes de fichiers sont apparu dans unix himself et là il s'agit d’interagir avec un programme au travers d'un système de fichier. On utilise le fait de voir des dossiers/fichiers et lire le contenu d'un fichier comme les sorties d'un programme et le déplacement dans un dossier, la création de dossier/fichier et l'écriture dans un fichier comme les entrées du programme.

L'intérêt est évident pour les programme qui ne peuvent que difficilement avoir des interfaces comme le noyau, mais c'est aussi très intéressant car les gestionnaires de fichiers et éditeur de texte peuvent naturellement interagir avec ce type de programme.

Sur linux tu trouvera 3 pseudo systèmes de fichiers classiques : udev (monté sur /dev et qui représente le hardware de la machine), procfs (monté sur /proc qui représente tous les processus de la machine (c'est une mine d'or d'aller s'y balader quand on ne connait pas)) et cgroup de plus en plus qui représente des limitations et quotas données aux processus. Mais fuse en possède pleins pour faire pleins de choses rigolotes : liste de filesystem de fuse.

Dernier point hurd avait un concept de translator pour faire ça qui a l'air plutôt cool.

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

Tu n'a même pas forcément besoin de remplaçant tu peut juste utiliser containerd si tu le souhaite (ça évite d'avoir le deamon docker que certains n'aiment pas).

J'ai l'impression que l'écosystème docker/k8s n'est pas encore arrivé à son niveau de maturité pour être stable (dans le sens ne pas changer l'état de l'art architectural tous les 2~3 ans).

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

C’est un problème qui s’apparente au problème des mariages stables qui s’attaque relativement bien vu comme un problème de satisfaction de contraintes, donc dans un cadre ensembliste.

Pour ceux qui préfèrent une vidéo explicative il y en a une sympa sur la chaine de ScienceEtonnante (j'ai découvert en recherchant cette vidéo, qu'il y a un mouvement de vidéos « réaction aux résultats ParcourtSup' »)

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

Les ERP utilisent pas mal de requêtes complexes comme les requêtes OLAP. Je n'ai pas rencontré d'ORM qui savaient en faire.

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

Le jour ou tu dois ajouter un champs ou gérer une liaison supplémentaire tu comprends très vite que d'avoir des INSERT en dur c'est une très grosse connerie.

Tu peut avoir des problèmes similaire avec des données structurée. Si ta modification est simple et qu'il s'agit d'ajouter une colonne ou une liaison sur du SQL correctement formaté ça n'est pas très compliqué à faire. C'est moins souple, moins performant, etc

En plus ça peut être tout à fait être ce que tu dis sauf qu'ils n'ont pas intégré l'outil à leur build pour de bonnes ou de mauvaises raisons même si c'est une bonne pratique qu'il soit intégré.

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

Ça ne va pas de poser des problèmes pour la relecture ?

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

J’espère qu'il y a des droits plus fin, genre --allow-net:domain.net

Tu gère comment la transitivité ? Tu as une bibliothèque sur un domaine A qui tire une dépendance sur le domaine B (et pour le fun dans la version suivante cette dernière passer sur le domaine C ou A).

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