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.
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.
[^] # Re: Traduction approximative
Posté par barmic 🦦 . En réponse à la dépêche GIMP 2.10.14 et 2.10.18 : sans limites. Évalué à  3.
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
[^] # Re: Traduction approximative
Posté par barmic 🦦 . En réponse à la dépêche GIMP 2.10.14 et 2.10.18 : sans limites. Évalué à  4.
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 :)
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
[^] # Re: Incompréhensible
Posté par barmic 🦦 . En réponse à la dépêche Audit du code source de Parcoursup par la Cour des comptes. Évalué à  3.
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
[^] # Re: Bien démarrer avec GnuPG
Posté par barmic 🦦 . En réponse au journal Bien démarrer avec GnuPG. Évalué à  9.
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
[^] # Re: container compatible OCI ?
Posté par barmic 🦦 . En réponse à la dépêche Harbor 2.0. Évalué à  2.
Ç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.
C'est un gros, vieux et long débat :)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: container compatible OCI ?
Posté par barmic 🦦 . En réponse à la dépêche Harbor 2.0. Évalué à  2.
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).
Ç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
[^] # Re: container compatible OCI ?
Posté par barmic 🦦 . En réponse à la dépêche Harbor 2.0. Évalué à  2.
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
[^] # Re: container compatible OCI ?
Posté par barmic 🦦 . En réponse à la dépêche Harbor 2.0. Évalué à  2.
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
[^] # Re: container compatible OCI ?
Posté par barmic 🦦 . En réponse à la dépêche Harbor 2.0. Évalué à  3.
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
[^] # Re: container compatible OCI ?
Posté par barmic 🦦 . En réponse à la dépêche Harbor 2.0. Évalué à  3.
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
[^] # Re: container compatible OCI ?
Posté par barmic 🦦 . En réponse à la dépêche Harbor 2.0. Évalué à  2.
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
[^] # Re: Traduction approximative
Posté par barmic 🦦 . En réponse à la dépêche GIMP 2.10.14 et 2.10.18 : sans limites. Évalué à  6.
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
[^] # Re: Analyse statique
Posté par barmic 🦦 . En réponse à la dépêche Audit du code source de Parcoursup par la Cour des comptes. Évalué à  3.
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
[^] # Re: Où est l'intérêt ?
Posté par barmic 🦦 . En réponse au journal Dhall, une réponse au problème de configuration. Évalué à  2.
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
[^] # Re: Analyse statique
Posté par barmic 🦦 . En réponse à la dépêche Audit du code source de Parcoursup par la Cour des comptes. Évalué à  6.
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
[^] # Re: Usine Ă gaz
Posté par barmic 🦦 . En réponse à la dépêche Audit du code source de Parcoursup par la Cour des comptes. Évalué à  5.
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.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: container compatible OCI ?
Posté par barmic 🦦 . En réponse à la dépêche Harbor 2.0. Évalué à  2.
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
[^] # Re: container compatible OCI ?
Posté par barmic 🦦 . En réponse à la dépêche Harbor 2.0. Évalué à  2.
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
[^] # Re: Perte d'infos ?
Posté par barmic 🦦 . En réponse à la dépêche Utiliser une des LED d’un Raspberry Pi comme témoin d’enregistrement TV. Évalué à  6.
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
[^] # Re: container compatible OCI ?
Posté par barmic 🦦 . En réponse à la dépêche Harbor 2.0. Évalué à  4.
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
[^] # Re: Usine Ă gaz
Posté par barmic 🦦 . En réponse à la dépêche Audit du code source de Parcoursup par la Cour des comptes. Évalué à  6. Dernière modification le 20 mai 2020 à 11:50.
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
[^] # Re: Usine Ă gaz
Posté par barmic 🦦 . En réponse à la dépêche Audit du code source de Parcoursup par la Cour des comptes. Évalué à  2.
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
[^] # Re: Usine Ă gaz
Posté par barmic 🦦 . En réponse à la dépêche Audit du code source de Parcoursup par la Cour des comptes. Évalué à  1.
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
[^] # Re: Commentaire additionnel
Posté par barmic 🦦 . En réponse à la dépêche Blender 2.8x : la consécration. Évalué à  2. Dernière modification le 20 mai 2020 à 08:38.
Ç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
[^] # Re: Trolldi, on peut ?
Posté par barmic 🦦 . En réponse à la dépêche Sortie de Deno 1.0. Évalué à  4.
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