barmic 🦦 a écrit 5940 commentaires

Donc, on en revient à l'attente des utilisateurs. S'ils ne cherchent pas à comprendre, le système le plus efficace est celui dont ils ne s'occupent pas, tant pis pour les quelques pertes. Au contraire, si on veut être dans un système maitrisé, il doit s'adapter aux réalité du fonctionnement du cerveau.

Le meilleur outil n'est-il pas celui dont on a pas besoin de savoir qu'il est là ?

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

tmp : répertoire éphémère qui ne contient pas beaucoup de fichiers et que je recycle de temps en temps, ça peut être des videos choppées du web et que j'ai la flemme de mettre dans media (ce qui témoignerait alors de ma volonté de les conserver, ce qui n'est pas forcément le cas)

Je gère ça avec un alias gotmp=$(mktemp -d) (j'utilise autocd). Quand j'ai besoin de me retrouver quelque part je lance gotmp, je fais ce que je veux et je sais qu'au redémarrage tout sera détruis (j'éteins ma machine tous les soirs).

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

Super comme réponse sur un site dédié à Linux.

C'est toujours bien de s'intéresser à comment font les autres.

Sous Linux aussi ce genre de truc existe depuis longtemps. Les plus connus sont Baloo (KDE), Tracker (plutôt Gnome), et Recoll (plutôt agnostique).

Je ne crois pas que ce soit ce qu'il décrit. Tu parle d'indexer (qui analyse le contenu des fichiers) et lui parle de tag (qui sont des métadonnées des fichiers). Ça existe aussi sur mac, c'est spotlight mais je ne suis pas certains que ce soit ce dont il parle.

Un problème c'est que ces solutions ne sont pas compatibles et pas toujours super stable. L'idéal ce serait quelque chose basé sur le système de fichiers mais d'après ce que je comprends, ce n'est pas possible d'implémenter ça correctement car les FS POSIX copient par une création de nouveau fichier et copie du contenu et non un appel système dédié qui permettrait au FS de gérer tout ça proprement.

La question n'est pas syscall vs autre chose, mais que le VFS l'API de filesystem que tout système de fichiers doivent implémenter pour être un système de fichier contient la sémantique de fichier/dossier (en fait c'est la définition de fichier/dossier/etc). De manière très simple quand un programme fais un `int fd = open("/foo/bar/file.ext");" il faut que ton système de fichier sache quoi en faire.

Tu peux très bien faire un mapping de la hiérarchie vers les tags. Les dossiers sont des tags, un fichier dans le dossier t1 a le tag t1. Tu trouvera dans t1/t2 tous les fichiers qui ont à la fois le tag t1 et t2. Donc tous les fichiers dans t1/t2 sont les même que ceux qui sont dans t2/t1. Il faut voir comment tu gère la copie et le déplacement pour ajouter/supprimer un tag (ou plusieurs) sur un fichier. Tout ça implique des décisions qui ne font pas forcément consensus.

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

La gestion du stockage est pénible si l'on veut garder un contrôle sur l'organisation du contenu.

Tu veux dire que si tu veux une arborescence sur un système fais pour ne pas présenter d'arborescence ça marche pas très bien ? Étonnant :)

Je ne trouve pas ça très agréable moi non plus, mais de plus en plus de personne n'utilisent que ça et on va bientôt commencer à voir une génération de personne qui n'ont que très peut utilisé d'ordinateur personnel et beaucoup plus de périphériques android/ios. Des gens qui n'auront pas le biais que nous avons : être biberonné au système de fichier hiérarchique depuis des dizaines d'années.

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

Ç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