Malheureusement, après, quand c'est télévisuel (comme la matinale d'inter) ça montre aux gens que le masque est facultatif pour travailler, exactement le message opposé de ce qu'on s’acharne à diffuser en parallèle. Dans ce sens les journalistes et animateurs ont une responsabilité envers le public.
Cette difficulté n'est pas un luxe, pas pour faire plaisir, mais pour éviter la contagion. En plus on parle d'ici d'un type qui parle avec le postérieur vissé à une chaise, pas d'une commerçante qui se déplace dans son commerce et qui range les rayons.
Et je n'ai jamais dit que c'était facile de porter le masque. Mais si justement certaines personnes, des cas assez restreints, ne peuvent pas le porter, ça renforce l'importance que tous les autres le portent, par responsabilité morale et civique. D'ailleurs, si c'est vraiment un problème physique de le porter, un médecin peut fournir une dispense pour raison médicale.
En passant, il existe différents types de masques avec des niveaux de filtrage différents, et il faut aussi en changer régulièrement, surtout si on parle beaucoup (humidité des postillons). Le tous les 4H est un minimum, dans les hopitaux c'est supposé être 3H pour le confort.
C'est drôle, mal informé (un comble) et égoïste.
À la radio, c'est impossible de travailler comme ça, mais les gens (dont moi) qui font des réunions en entreprise et parlent pendant plusieurs heures y arrivent, même à respirer. Et toutes les distanciations sociales ne changent pas le fait que les aérosols, dont on connait désormais l'importance, sont une part majeur du risque de contagion.
C'est égoïste, car monsieur n'arrive soit disant pas à le supporter, et effectivement, quand on essaie juste 5 minutes, c'est insupportable. Ça prend littéralement des semaines pour s'habituer à porter le masque pendant 9H par jour (travail +transport - quelques pauses sans masque à l'extérieur). Mais les femmes de ménage et les techniciens (pauvres) qui passeront sur le plateau, ils le porteront eux, et risqueront d'être contaminés par les aérosols produits des animateurs (riches), et qui resteront dans l'air pendant des heures.
La dégradation légère du son n'est alors qu'un excuse de plus pour dire qu'on est spécial est qu'en tant que présentateur radio, on devrait ne pas le porter.
Si on rembobine de quelques mois, repensez à la visite d'un certain M. Macron dans une école. Il arrive masqué, mais enlève son masque pour être reconnu par les élèves. C'est le premier facteur, à mon sens, le besoin d'être vu et reconnu, commun à beaucoup de gens connus et/ou célèbres. C'est très désagréable de ne pas être suffisamment vu et reconnu quand on a tout fait pour arriver à ce niveau de reconnaissance et de célébrité.
Le deuxième facteur est social : la sensation de toute puissance et d'immunité. Celui là est fourbe, parce que ça n'est pas faux. Vous être une personne de classe supérieure, au compte en banque bien rempli et avec un ego certain plus ou moins corrélé. Statistiquement, vous avez clairement moins de change d'attraper la COVID qu'un livreur ou qu'une femme de ménage, et si vous l'attrapez, vous pourrez a priori trouver un endroit où vous faire soigner sans trop de problème. Et, l'ego aidant, cette maladie semble lointaine et faiblarde. Comment cet ennemi invisible pourrait-il atteindre quelqu'un qui est monté aussi haut des les échelons ?
C'est un argument fallacieux car ça vient d'écrivains noirs et on appelle ça de la réappropriation. C'est le même principe que le fameux N* word dans le rap US.
La seule technique qui soit objective est celle du CPU, du pur calcul. Du moment que tu mets des algorithmes complexes écrits par des humains là dessus, sur des sujets complexes, les biais apparaissent.
Exemples connus autour du même sujet :
- Les premières implémentations de détection de visage ne détectaient pas les visages à peau sombres, mais juste les visages clairs. Il n'avaient jamais eu l'idée de tester ce cas là
- Les détections de visages et/ou de sourire ne détectaient pas correctement les sourires en fermant les yeux, comme dans certains pays asiatiques, voire affichait un message demandant d'ouvrir les yeux.
- La gestion automatique de couple ouverture/vitesse de nombreux appareils photos numériques et de téléphones a un problème pour photographier les peaux noires, les représente de façon trop sombres.
L'algorithme en soit fait ce qu'on lui demande, il détecte les visages selon certains paramètres. Le problème est que quand on ne le confronte pas à la diversité, on ne se rend pas compte à quel point il est inexact ou mal paramétré.
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.
Posté par damaki .
En réponse au journal Les écrans et nos enfants.
Évalué à 1.
Dernière modification le 10 août 2020 à 15:18.
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.
+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 ?
+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.
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.
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.
[^] # Re: Côté radio aussi
Posté par damaki . En réponse au journal Masques pour lutter contre le Covid : les journalistes disent stop !. Évalué à 6. Dernière modification le 26 août 2020 à 15:50.
Malheureusement, après, quand c'est télévisuel (comme la matinale d'inter) ça montre aux gens que le masque est facultatif pour travailler, exactement le message opposé de ce qu'on s’acharne à diffuser en parallèle. Dans ce sens les journalistes et animateurs ont une responsabilité envers le public.
[^] # Re: Côté radio aussi
Posté par damaki . En réponse au journal Masques pour lutter contre le Covid : les journalistes disent stop !. Évalué à 9. Dernière modification le 26 août 2020 à 15:33.
Cette difficulté n'est pas un luxe, pas pour faire plaisir, mais pour éviter la contagion. En plus on parle d'ici d'un type qui parle avec le postérieur vissé à une chaise, pas d'une commerçante qui se déplace dans son commerce et qui range les rayons.
Et je n'ai jamais dit que c'était facile de porter le masque. Mais si justement certaines personnes, des cas assez restreints, ne peuvent pas le porter, ça renforce l'importance que tous les autres le portent, par responsabilité morale et civique. D'ailleurs, si c'est vraiment un problème physique de le porter, un médecin peut fournir une dispense pour raison médicale.
En passant, il existe différents types de masques avec des niveaux de filtrage différents, et il faut aussi en changer régulièrement, surtout si on parle beaucoup (humidité des postillons). Le tous les 4H est un minimum, dans les hopitaux c'est supposé être 3H pour le confort.
[^] # Re: Côté radio aussi
Posté par damaki . En réponse au journal Masques pour lutter contre le Covid : les journalistes disent stop !. Évalué à 10. Dernière modification le 26 août 2020 à 14:51.
C'est drôle, mal informé (un comble) et égoïste.
À la radio, c'est impossible de travailler comme ça, mais les gens (dont moi) qui font des réunions en entreprise et parlent pendant plusieurs heures y arrivent, même à respirer. Et toutes les distanciations sociales ne changent pas le fait que les aérosols, dont on connait désormais l'importance, sont une part majeur du risque de contagion.
C'est égoïste, car monsieur n'arrive soit disant pas à le supporter, et effectivement, quand on essaie juste 5 minutes, c'est insupportable. Ça prend littéralement des semaines pour s'habituer à porter le masque pendant 9H par jour (travail +transport - quelques pauses sans masque à l'extérieur). Mais les femmes de ménage et les techniciens (pauvres) qui passeront sur le plateau, ils le porteront eux, et risqueront d'être contaminés par les aérosols produits des animateurs (riches), et qui resteront dans l'air pendant des heures.
La dégradation légère du son n'est alors qu'un excuse de plus pour dire qu'on est spécial est qu'en tant que présentateur radio, on devrait ne pas le porter.
# Besoin de reconnaissance et immunité psychologique
Posté par damaki . En réponse au journal Masques pour lutter contre le Covid : les journalistes disent stop !. Évalué à 10. Dernière modification le 26 août 2020 à 14:17.
Si on rembobine de quelques mois, repensez à la visite d'un certain M. Macron dans une école. Il arrive masqué, mais enlève son masque pour être reconnu par les élèves. C'est le premier facteur, à mon sens, le besoin d'être vu et reconnu, commun à beaucoup de gens connus et/ou célèbres. C'est très désagréable de ne pas être suffisamment vu et reconnu quand on a tout fait pour arriver à ce niveau de reconnaissance et de célébrité.
Le deuxième facteur est social : la sensation de toute puissance et d'immunité. Celui là est fourbe, parce que ça n'est pas faux. Vous être une personne de classe supérieure, au compte en banque bien rempli et avec un ego certain plus ou moins corrélé. Statistiquement, vous avez clairement moins de change d'attraper la COVID qu'un livreur ou qu'une femme de ménage, et si vous l'attrapez, vous pourrez a priori trouver un endroit où vous faire soigner sans trop de problème. Et, l'ego aidant, cette maladie semble lointaine et faiblarde. Comment cet ennemi invisible pourrait-il atteindre quelqu'un qui est monté aussi haut des les échelons ?
[^] # Re: Mikrotik et RouterOS
Posté par damaki . En réponse au sondage Utilisez‑vous un pare‑feu dédié à la maison ?. Évalué à 1.
Un injecteur PoE n'est pas très cher ni encombrant.
[^] # Re: Le racisme systémique
Posté par damaki . En réponse au journal GitHub remplace la branche master par main. Évalué à 4.
C'est un argument fallacieux car ça vient d'écrivains noirs et on appelle ça de la réappropriation. C'est le même principe que le fameux N* word dans le rap US.
[^] # Re: De la neutralité de l'informatique !
Posté par damaki . En réponse au journal GitHub remplace la branche master par main. Évalué à 1. Dernière modification le 25 août 2020 à 14:51.
La seule technique qui soit objective est celle du CPU, du pur calcul. Du moment que tu mets des algorithmes complexes écrits par des humains là dessus, sur des sujets complexes, les biais apparaissent.
Exemples connus autour du même sujet :
- Les premières implémentations de détection de visage ne détectaient pas les visages à peau sombres, mais juste les visages clairs. Il n'avaient jamais eu l'idée de tester ce cas là
- Les détections de visages et/ou de sourire ne détectaient pas correctement les sourires en fermant les yeux, comme dans certains pays asiatiques, voire affichait un message demandant d'ouvrir les yeux.
- La gestion automatique de couple ouverture/vitesse de nombreux appareils photos numériques et de téléphones a un problème pour photographier les peaux noires, les représente de façon trop sombres.
L'algorithme en soit fait ce qu'on lui demande, il détecte les visages selon certains paramètres. Le problème est que quand on ne le confronte pas à la diversité, on ne se rend pas compte à quel point il est inexact ou mal paramétré.
[^] # Re: Pas de numéro de sécurité sociale comme clé primaire
Posté par damaki . En réponse à la dépêche Authentification et identité numérique en France. Évalué à 1.
Merci pour l'info !
# Le racisme systémique
Posté par damaki . En réponse au journal GitHub remplace la branche master par main. Évalué à 10. Dernière modification le 25 août 2020 à 06:02.
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.
# Pas de numéro de sécurité sociale comme clé primaire
Posté par damaki . En réponse à la dépêche Authentification et identité numérique en France. Évalué à 6. Dernière modification le 24 août 2020 à 14:06.
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.
# Qwant = bing en moins frais
Posté par damaki . En réponse au journal YaCy, David(s) contre Googliath. Évalué à 4.
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.
[^] # Re: ça dépend selon Papa / Maman
Posté par damaki . En réponse au journal Les écrans et nos enfants. Évalué à 1. Dernière modification le 10 août 2020 à 15:18.
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.
[^] # Re: Attention aux migrations
Posté par damaki . En réponse au journal Comment quitter Odoo Enterprise ?. Évalué à 10.
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.
[^] # Re: Attention aux migrations
Posté par damaki . En réponse au journal Comment quitter Odoo Enterprise ?. Évalué à 2. Dernière modification le 04 août 2020 à 18:06.
200 balles, pardon.
[^] # Re: Attention aux migrations
Posté par damaki . En réponse au journal Comment quitter Odoo Enterprise ?. Évalué à 5. Dernière modification le 04 août 2020 à 18:01.
+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.
# Sauvegardes ?
Posté par damaki . En réponse à la dépêche À la découverte de l’écosystème Mooltipass. Évalué à 4.
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 ?
[^] # Re: Samba ça marche au poil
Posté par damaki . En réponse au journal Partage familial de fichiers (lecture seule, sans mot de passe). Évalué à 4.
SMBv2 rend l'authentification obligatoire.
[^] # Re: solidarité
Posté par damaki . En réponse au journal free.fr tu n'es plus mon ami. Évalué à 10. Dernière modification le 19 juin 2020 à 07:54.
+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.
# Le cimetière des nouvelles technos
Posté par damaki . En réponse au journal Dhall, une réponse au problème de configuration. Évalué à 2. Dernière modification le 27 mai 2020 à 08:38.
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.
[^] # Re: Où est l'intérêt ?
Posté par damaki . En réponse au journal Dhall, une réponse au problème de configuration. Évalué à 1. Dernière modification le 27 mai 2020 à 08:23.
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.
[^] # Re: Où est l'intérêt ?
Posté par damaki . En réponse au journal Dhall, une réponse au problème de configuration. Évalué à 2.
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.
[^] # Re: Où est l'intérêt ?
Posté par damaki . En réponse au journal Dhall, une réponse au problème de configuration. Évalué à 1.
Les équipes de support et de sysadmins que j'ai autour de moi adorent ça.
[^] # Re: Où est l'intérêt ?
Posté par damaki . En réponse au journal Dhall, une réponse au problème de configuration. Évalué à 3.
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.
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.
[^] # Re: Où est l'intérêt ?
Posté par damaki . En réponse au journal Dhall, une réponse au problème de configuration. Évalué à 4.
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.
[^] # Re: Où est l'intérêt ?
Posté par damaki . En réponse au journal Dhall, une réponse au problème de configuration. Évalué à 4.
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.
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.
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.
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.