damaki a écrit 385 commentaires

Le racisme systémique est composés d'un ensemble de facteurs historiques, sociaux et sociétaux, qui ont une fâcheuse tendance à vouloir se reproduire dans le temps, dont effectivement le vocabulaire aussi fait partie. Et là on parle de vocabulaire informatique slave/master voire whitelist/blacklist, mais en français, je peux vous sortir vite fait deux exemples autour d'un seul mot :
- tête de nègre, qui désignait une pâtisserie, désormais tête de chocolat
- nègre, en littérature, ou désormais prête-plume, auteur d'un livre non crédité dans la liste des auteurs
Bizarrement, quand on commence à s'intéresser à notre belle langue qu'est le français, oui, on voit que c'est problématique. Une langue étrangère rajoute une certaine distance avec ces concepts.

La référence à 1984 est totalement déplacée, car les termes anciens du racisme ne sont pas en voie d'extinction ou d'être vidés de leur sens mais de spécialisation et réappropriation. Est-ce un effort si grand que ça d'arrêter de parler de maître/esclave dans un contexte autre que l'esclavage ? Je pense qu'on a bien assez de vocabulaire mieux adapté en français et en anglais pour pouvoir vivre sans.

De mémoire de mes cours de droit informatique, à moins d'être dans le domaine médical, on a pas le droit d'utiliser le numéro de sécurité sociale comme identifiant ou comme clé de recherche et pour pouvoir légalement le stocker, il y a bien peu de cas autorisés (ce que votre déclaration de fichier informatique à la CNIL vous rappellera rapidement).
En passant, ce n'est pas un identifiant unique pour identifier une personne physique :
- Un enfant partage le même numéro de sécurité sociale que les parents jusqu’à ce qu'il ait le sien.
- On peut avoir plusieurs numéros de sécurité sociale associés à une personne, notamment en cas de réassignation de genre.
Donc on a un numéro qui peut être assigné à N personne et une personne qui peut avoir N numéros, une magnifique relation N-N, assez inadaptée comme identifiant unique.

Si l’on voit Qwant comme une tentative de ne pas dépendre uniquement de Google et d’autres moteurs étrangers

C'est dommage, parce que Qwant se base encore actuellement en grosse partie sur Bing. Donc au final on envoie quand même des requêtes sur un moteur de recherche étranger.
Après l'avoir utilisé pendant 1 an et demi, j'ai du me résoudre à retourner à DuckDuckGo, qui a le mérite d'au moins avoir des résultats frais.

Pas convaincu.
La télé n'est pas un loisir passif, tout comme le cinéma n'est pas un loisir passif non plus. Déjà, c'est une source de socialisation, le "t'as vu le dernier épisode de" que tous les férus de séries connaissent bien. Et ça fait découvrir de nouvelles situations, de nouvelles combinaisons de personnages et d'histoires, des nouvelles images, de nouveaux dessins, qui nourrissent l'imagination avec de nouvelles possibilités.
C'est un fait complètement absurde que la génération Club Dorothée, où pour beaucoup la télé était la nounou, qui les biberonnait d'émissions, de séries et de films, dénonce maintenant la télé. Si la télé rendait idiot, nous serions tous complètement stupides, ce qui est probablement difficile à accepter, non ?

Bref, je vois mon gosse qui dessine les personnages qu'il voit, indifféremment que ce soit des images de dessins animés, dans les jeux vidéo, dans les bédés. Et il raconte des histoires avec des mélanges de tous ces éléments, comme tous les gamins.

Le point principal évoqué était le coût à court et long terme, c'est donc l'angle de ma réponse. Je ne cherche pas à dissuader l'auteur de la migration vers une solution open source, juste à expliquer qu'il faut comparer avec une prestation équivalente en open source. Gérer correctement un serveur avec des données critiques pour le commerçant et avoir les assurances adéquates pour l'indemniser en cas de pépin, c'est un métier et c'est pas donné. On ne parle pas ici d'un NAS famillial avec des photos de vacances, mais d'une application qui peut contenir des données comptables, qui si elles sont perdues peuvent donner lieu à des poursuites.
Je ne vais pas conseiller à quelqu'un dont ça n'est pas le métier de devenir un bon sysadmin à mi temps et un bon presta de migration/maintenance d'ERP pour gratter 2000 balles par an et pour la beauté du libre.

200 balles, pardon.

+1
2000€, ça a beau paraître cher, mais genre 20 balles par mois pour un ERP, maintenance et support compris, c'est clairement pas si cher, d'autant plus si c'est du cloud et que l'hébergement est compris. J'ajouterais donc le prix d'un support/hébergement équivalent dans les solutions open source, et d'une prestation de migration. C'est même pas sûr que ça soit moins cher, même si effectivement sur le long terme ça peut être rentable.
Règle numéro 1 de l'open source en entreprise : ça n'est pas gratuit et c'est bien normal.

Comment faites-vous pour sauvegarder la smartcard et /ou les mots de passe ? J'ai vu qu'il y a des exports fichier, mais ils restent très évasifs, ils parlent juste d'exports fichiers dans le cloud, à l'opposé de la sécurité hors-ligne tant vantée.
Est-ce qu'on peut facilement imprimer un listing de mots de passes en clair pour avoir une copie physique en cas de pépin ?
Est-ce que les exports fichiers sont chiffrés ? Si oui, y-a-t’il des détails d'implem là dessus ? Ca pourrait être une source de grosses faiblesses.
Est-ce qu'on peut cloner facilement la smartcard pour en faire une copie de sauvegarde ?

SMBv2 rend l'authentification obligatoire.

+1
Je voulais garder mes comptes Free au cas où une vieille connaissance essaierait de me contacter mais j'ai subi une première suppression il y a de ça 8 ans.

Mais pour me faire l'avocat du diable, j'ai un compte mail créé en 2001 que j'avais configuré pour que Gmail aille picorer ses mails et il fonctionne toujours, depuis 19 ans. Que je sache, aucun autre FAI français ne permet de conserver une boite mail aussi longtemps sans être client.
Dans tous les cas, que ce soit pour les mails ou les sites : achetez-vous un domaine et faite une redirection. Ça coute quasiment rien pour un domaine .ovh (2€ par an) et vous aurez aussi droit à une modeste boite mail gratuite et du stockage pour des petits sites persos.

Comme toute nouvelle techno, il y a un souci, c'est que personne ne l'utilise et qu'elle n'a pas de communauté pour le support. Malheureusement, quand on utilise une techno en entreprise, on a besoin d'avoir une visibilité sur sa durée de vie, ses corrections de bug. Ici on parle d'une techno pour les confs, élément critique par excellence et c'est donc extrêmement compliqué d'utiliser une techno sortie du chapeau pour ce besoin, malgré toutes les belles choses qu'elle peut apporter et même si c'est juste un générateur. L'excellence technique ne suffit pas, il faut une perception de garantie de présence dans l'industrie et de pérennité. J'ai malheureusement plein de technos orphelines dans les placards (dbdeploy et Jelix, petits anges partis trop tôt). Et malheureusement, c'est rare que les entreprises prennent l'initiative de la forker en open source et de prendre le relai de la maintenance.

J'aurais sans doute du en parler dans une autre partie de l'arbre de discussion, parce qu'on est plus dans les mérites techniques, donc hop, je mets la suite dans une autre réponse.

Oui, mais est-ce que ce gain potentiel vaut tous les coûts que l'ajout de complexité va engendrer ? Je parle de coûts de formation des devs et support, de la complexité ajoutée pour installer les livrables, du coût de convaincre les parties prenantes de la boîte d'avoir une techno de plus qui va mettre des années à remplacer les autres (si ça arrive) et du coût d'être juste 100 pèlerins dans le monde à utiliser cette techno et donc que ce sera compliqué pour avoir du support technique en cas de pépins.

Les équipes de support et de sysadmins que j'ai autour de moi adorent ça.

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

Ok, j'ai un peu tiré la définition de cet antipattern. L'explication est qu'on veut que le code soit statique et validé, non modifiable et séparé de la configuration qui elle peut bouger. Si la configuration est dans du code, ça veut dire que toute modification de la configuration peut potentiellement permettre de modifier le reste du code ou d'ajouter du code. Dhall n'est pas un langage de programmation complet et ne rajoutera pas de comportements dans l'appli, donc effectivement mon argument est invalide.

La CI/CD est par définition du code vu que c'est littéralement du scripting. Qu'est-ce qu'il y a de plus code que exécute ça puis ça et si 1 échoue, alors fait ça ? Suffit de regarder Luminar en bash, Buildbot avec python, Jenkins avec Groovy.

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).

Malheureusement, on ne choisit pas entre les formats de conf et les moteurs de templates. On a forcément besoin des deux lors des déploiements d'applis. On a forcément besoin de générer ou de valoriser de la conf et quoi de mieux qu'un moteur de templates pour faire ça. Suffit de regarder les templates de cloud init, par exemple, qui regénèrent la conf des VMs à chaque démarrage, qui en sont un bon exemple.
Donc mon point est que vu qu'on a de toute façon besoin d'un moteur de template pour les déploiements, il vaut mieux que la configuration soit la plus simple possible syntaxiquement afin de faciliter la création des templates et d'éviter de faire des échappements problématiques.

Ce qui me gène aussi avec Dhall, j'insiste, c'est la complexité. Ils appellent ça un language de configuration, pour moi c'est juste un deuxième moteur de template empilé sur le premier et un deuxième langage de programmation. Ça donne de bonnes choses, comme le système de types et de moins bons, la complexité et la diversité du code qu'on peut faire. Peut-être que c'est un super moteur de templating, avec de géniaux outils de validation et de refactoring, mais ça reste juste un moteur de templating pour faire du json ou du yaml, à moins sans doute d'embarquer une lib. Et si vous dites à vos sysadmins que c'est un meilleur moteur de templating que celui intégré à Ansible, je pense que vous obtiendrez juste un lever de sourcil, et que votre sysadmin adoré (j'adore les miens, en tous cas) retournera à ses scripts ansible et ses templates jinja2.

J'en reviens à la même question :
- Quel problème résout cet outil qui n'est pas résolu par des outils ou des process existants, qui marchent déjà ?
Probablement les soucis de structure et de typage de conf, mais de toute façon, vu qu'on a besoin d'un autre moteur de templating pour le déploiement, ça ne résout pas les problèmes générés par cet autre moteur de templating. 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.

Ma conclusion serait donc, pourquoi pas l'utiliser si c'est intégré à Ansible et ses amis pour remplacer partiellement jinja2, mais hormis ce cas d'usage, j'ai du mal à voir les bénéfices réels.

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. Et lorsqu'un humain regarde le fichier de conf, c'est appréciable que ce soit possible d'en comprendre très rapidement la structure et d'avoir peu de doutes sur sa syntaxe, même s'il ne maîtrise pas l'applicatif. L'idéal est donc de prendre un standard de format de conf texte existant. Or un langage de programmation, c'est l'opposé complet d'un langage textuel simple de fichiers de conf. Ça crée tout de suite un ticket d'entrée plus cher puisqu'il faut comprendre ce nouveau language de conf en plus.
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 ;-)

En suite au sujet des bienfaits de Dhall, sur la validation, c'est bien, mais en vrai on s'en fiche dans la plupart des cas. Pour les formats de conf standards, les parseurs pas trop stupides savent déjà éliminer les erreurs syntaxiques, qui sont honnêtement pas celles qui vont arriver en prod le plus souvent. Le cœur du problème, ce qui coûte cher, ce sont les erreurs de format, de type et fonctionnelles, mais je ne vois pas du tout en quoi Dhall aide pour résoudre ce problème. Je pense que Dhall résoud des problèmes qui certes existent, mais avec des confs tellement complexes que leur fonctionnel mérite de s'interroger sur leur pertinence.

Programmer la configuration

C'est à ça que servent les milliards de moteurs de template et les outils de gestion de conf modernes, Ansible, Salt et tous leurs amis. Là, c'est juste un énième format, plus complexe que les autres.. Et ça augmente la complexité de ces déploiements que la conf soit programmatique, je pensais qu'on s'était enfin débarrassés des .conf.php et leurs équivalents.

la valider strictement

Tous les langages de conf pas trop débiles ont des schemas qui les définissent. Problème déjà résolu depuis l'ère des confs en xml.

Les annotations de types sont là pour augmenter la lisibilité.

C'est pas idiot d'auto-documenter la conf, mais ça reste quand même un ajout de complexité. M'enfin avoir un type explicite pour ne pas avoir à donner un nom moche comme timeout-milliseconds sur une clé de conf, j'avoue.

Le YAML n’est ni facile à lire ni à implémenter.

Et les parseurs YAML que j'ai pu voir ces 10 dernières années sont de la grosse merde en général, incapables de donner des infos aussi fondamentales que à quel ligne/colonne commence cette maudite erreur de syntaxe. Oui, même le parseur yaml de ansible. C'est dommage parce que j'aime bien ce format.
Séquence hors-sujet : je m'engueulais déjà il y a plus de 10 ans avec un dev d'un de ces premiers parseurs pour lui dire que les messages d'erreur de son parseur étaient inutilisables.

Ça ne veut rien dire comme métrique. Ça peut être des tonnes d'INSERT pour les données de référence utilisées par l'appli, ou des données de démo/test/exemple. C'est une info trop macro pour être interprétable.

Malgré tout le mal que je pense de Parcoursup, on dirait qu'il ont juste lancé un outil de mesure de qualité du code sur tout le code et regardé les stats en sortie. J'aurais bien aimé voir les détails de cette partie de l'audit, parce que même les annexes sont particulièrement vagues.
Certes c'est un indicateur intéressant, surtout dans le cadre de pratiques de dev moderne, mais ça reste une vision parcellaire.

Je répare au maximum de mes possibilités mes affaires. Par exemple, mon kit d'enceintes de mon PC a 17 ans et j'ai déjà refait 3 fois certaines soudures qui s'usent à force de manipulations.
Je réduis mon usage du cloud au minimum. Je considère que mes données n'ont pas à être répliquées dans des centaines de datacenters et qu'un ou deux est bien assez suffisant. Besoin d'avoir des données partout avec soi ? Une clé USB me permet d'avoir des dizaines de gigas toujours dans mon sac, sans souci.
Je n'ai pas de voiture.

Enfin, je vote pour des candidats qui ont des valeurs écologiques. En effet, faut pas se leurrer, les actions individuelles, même multiples, sont des grains de sable par rapport aux industries les plus polluantes. J'aurais même tendance à penser que nous sommes quelques uns des chiffres à droite de la virgule des stats de la pollution. Et je ne crois pas au en même temps, en ce qui concerne l'écologie.

J'utilise Jetbrains Mono pour le code, avec ses chouettes ligatures. Pour tout le reste, Deja Vu Sans Mono

+1
Solarized light partout, combiné à des luminosités d'écrans finement ajustées selon l'intensité de la lumière ambiante. Vu la quantité de lumière sur mon lieu de travail, c'est quasi impossible de travailler avec un thème dark, de toute façon.
Je n'ai jamais trop compris cette hype des thèmes dark, à part évidemment sur les smartphones où c'est parfaitement logique.

Quel que soit le prix, effectivement c'est un investissement pour sa santé. En entreprise, je rappelle que c'est normalement à l'employeur de vous fournir les outils pour travailler sans douleur.
Sinon, pour les achats perso, ce genre de matos ergonomique est cher, mais souvent ça tient et c'est réparable, car c'est pas produit en grosse quantité. J'ai ma souris verticale depuis 8 ans, une Evoluent, achetée à environ 120-130€. J'ai juste du changer le câble (standard) parce qu'il avait des faux contacts et remettre du lubrifiant pour la molette, mais au bout de 7 ans. Le clavier split depuis bientôt 2 ans, pour 250€.

Bref, le matos ergonomique, faut vraiment le voir comme un investissement médical sur le long terme. Ce qui est pénible c'est que c'est compliqué de tester sans payer un matériel qui ne vous conviendra pas forcément.

Ça se tient d'acheter d'occasion un clavier mécanique avec des switches compatibles cherry MX, vu qu'on peut changer les interrupteurs et les touches, si besoin est. J'avoue.

Effectivement, YMDK ils ont de chouettes kits. Merci !

Et parce que ce sont des standards.
L'intérêt d'un standard, c'est justement de ne pas changer si c'est suffisamment bon pour son usage. Le seul truc qui soit plus fort que les standards, c'est la mode. C'est grâce aux modes du clavier mécanique gaming et du DIY qu'on commence à peine à voir apparaître de la variété dans les claviers. Mais le clavier orthogonal n'est pas encore tellement à la mode.