As part of the conscious language efforts, NetworkManager is not writing offensive terms into keyfiles anymore.
Alors, je m'attendais à une liste de gros mots bien salés.
src/libnm-core-impl/nm-keyfile.c
/* Don't write offensive terms that are already deprecated as the new inclusive terms
* are being written.
*/
if (NM_IN_STRSET(key,
NM_SETTING_CONNECTION_AUTOCONNECT_SLAVES,
NM_SETTING_CONNECTION_MASTER,
NM_SETTING_CONNECTION_SLAVE_TYPE,
NM_SETTING_WIRED_MAC_ADDRESS_BLACKLIST))
return;
Ça me rappelle qu'à une époque OpenSSL avait une option FascistLogging. Il paraît que des anciens cadres de la Stasi se sentaient exclus, du coup l'option a été renommée.
L'histoire de la terminologie master/slave/blacklist/whitelist versus main/primary/secondary/blocklist/allowlist est un vrai marronnier, avec plus ou moins de valeur historique et d'émotion.
Le fait est qu'il y a souvent un meilleur mot que "esclave" pour désigner un rôle d'interface agrégée. Par contre bond j'aimerais bien que ça reste encore un peu :-# s'il vous plaît.
Une équipe de dev choisit de renommer une variable dans une version. Puis de retirer l'ancien nom dans une version ultérieure. Quelle audace, quelle nouveauté, quelle surprise, quelle absence d'intérêt pour une actu.. ça arrive extrêmement fréquemment dans plein de logiciels.
Bon donc là le but est juste d'avoir une indignation sur les termes concernés mais sans le dire pour ne pas créer un débat boomer passéiste contre ultra-wokiste ? Ben je dirais que ça reste peu intéressant, voire inutile. Et qualifier les gens de lourdingues pour ça (rien), c'est cela qui me semble lourdingue.
Oui, c'est inutile mais ils ont jugé bon de l'annoncer et de se donner un genre avec le côté lutte de l'offense lourdingues wokistes.
Est-ce que t'as eu l'impression d'exploiter un champ de coton en branchant ton dvd rw en slave ou en clonant un dépôt git?
Changer des variables pour y apporter plus de précision, de correction, pourquoi pas, je rejoins Cg pour la notion d'aggrégation mais se pavaner de vertue ostentatoire en annonçant une changement bénin de cette manière, je dis merdezut!
D'annoncer un changement d'API quelle drôle d'idée ? Il ne faut surtout pas dire ce qu'on fait sinon il y a des gens qui vont s'offusquer sans comprendre
Oui bien sûr, le racisme c’est à cause des noms de variables en informatique.
D’ailleurs au boulot on nous a demandé de remplacer les mots whitelist et bkacklist par allowlist et denylist et le racisme a totalement disparu du jour au lendemain.
Je suis d’accord que c’est bien de contribuer à faire évoluer les mentalités, mais si la compatibilité avec l’existant est cassée, c’est pas génial.
Ce n'est pas en ne changeant rien pour ne pas casser la compatibilité que l'on va évoluer… par définition pour changer de façon pérenne, il faut modifier quelque chose et ne pas conserver ce qui était avant. Ça nécessite un effort de changer.
Au XXe siècle il a fallu modifier la variable électeur parce que les femmes ont obtenu (en France) le droit de vote. Puis on a eu le vrai pays vs les colonies, le vrai pays vs les territoires outremer, le vrai centre/la capitale vs l'outrepériph, etc., etc. Bref qui on inclut/exclut suivant l'origine, la nationalité, la religion, l'argent, la santé, le sexe, le statut, etc. C'est la vie en société, l'évolution de la nation, la vraie politique, blabla.
Il faut aussi noter une certaine dissonance cognitive mise en valeur ici : soit renommer des choses est mineur sans effet (ironie sur le racisme a totalement disparu du jour au lendemain.), alors on s'en fiche un peu, le coût est finalement assez faible. Soit renommer des choses est suffisamment important pour venir s'en outrer (le premier commentaire) et la vraie raison semble plus le refus du changement du vocabulaire que le minime changement de configuration impliqué. Pas de souci sur les opinions de chacun/chacune, mais faut pas essayer d'emballer ça dans une attaque sur les autres / les développeurs qui font des gigantesques changements apocalyptiques avec l'outrecuidance de le mentionner en petit dans une annonce…
Et maintenant mon avis perso dont on se fout sur le vocabulaire :
allowlist/blocklist est plus clair/explicite que whitelist/blacklist. Les couleurs c'est "mignon" mais pas explicite, surtout qu'on en ajoute, genre greylist (ou blue/red/purple/… teams en sécu où il faut juste tout connaître par coeur parce que la couleur n'est pas vraiment informative)
master/main pour git: master est très polysémique et plus long que main. Je conçois plus ma branche par défaut comme la principale que comme la référence. Donc je préfère main. (divulgachage : et on fait le changement pour LinuxFr.org…)
maître/esclave : difficile de ne pas voir un lien de domination. Mais je préfère primaire/secondaire(s) par exemple, ça me semble plus logique de changer de place/ordre que de changer celui qui tient le fouet. Probablement lié au fait que ça peut qualifier des personnes (comme si on avait contrôleur/contremaître vs ouvrier, ou patron / salarié, ou roi / sujet).
Dernier point sur l'empathie : ce n'est pas parce moi je m'en foutrais de ce changement de vocabulaire que je peux nier/mépriser le ressenti des autres. Au minimum je suis capable d'en discuter s'en mettre des noms d'oiseaux sur l'autre.
# purée, les lourdingues
Posté par pas_de_bol . Évalué à 0 (+6/-6).
Alors, je m'attendais à une liste de gros mots bien salés.
src/libnm-core-impl/nm-keyfile.c
[^] # Re: purée, les lourdingues
Posté par cg . Évalué à 5 (+3/-0).
Ça me rappelle qu'à une époque OpenSSL avait une option FascistLogging. Il paraît que des anciens cadres de la Stasi se sentaient exclus, du coup l'option a été renommée.
L'histoire de la terminologie master/slave/blacklist/whitelist versus main/primary/secondary/blocklist/allowlist est un vrai marronnier, avec plus ou moins de valeur historique et d'émotion.
Le fait est qu'il y a souvent un meilleur mot que "esclave" pour désigner un rôle d'interface agrégée. Par contre bond j'aimerais bien que ça reste encore un peu :-# s'il vous plaît.
[^] # Re: purée, les développeurs
Posté par Benoît Sibaud (site web personnel) . Évalué à 6 (+5/-2).
Une équipe de dev choisit de renommer une variable dans une version. Puis de retirer l'ancien nom dans une version ultérieure. Quelle audace, quelle nouveauté, quelle surprise, quelle absence d'intérêt pour une actu.. ça arrive extrêmement fréquemment dans plein de logiciels.
Bon donc là le but est juste d'avoir une indignation sur les termes concernés mais sans le dire pour ne pas créer un débat boomer passéiste contre ultra-wokiste ? Ben je dirais que ça reste peu intéressant, voire inutile. Et qualifier les gens de lourdingues pour ça (rien), c'est cela qui me semble lourdingue.
[^] # Re: purée, les développeurs
Posté par pas_de_bol . Évalué à -2 (+2/-4).
oh t'es du genre: "Ooooh ça vaaaa" non ? :)
Oui, c'est inutile mais ils ont jugé bon de l'annoncer et de se donner un genre avec le côté lutte de l'offense lourdingues wokistes.
Est-ce que t'as eu l'impression d'exploiter un champ de coton en branchant ton dvd rw en slave ou en clonant un dépôt git?
Changer des variables pour y apporter plus de précision, de correction, pourquoi pas, je rejoins Cg pour la notion d'aggrégation mais se pavaner de vertue ostentatoire en annonçant une changement bénin de cette manière, je dis
merdezut!Bref. bonne soirée.
[^] # Re: purée, les développeurs
Posté par barmic 🦦 . Évalué à 7 (+5/-0).
D'annoncer un changement d'API quelle drôle d'idée ? Il ne faut surtout pas dire ce qu'on fait sinon il y a des gens qui vont s'offusquer sans comprendre
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: purée, les développeurs
Posté par dyno partouzeur du centre . Évalué à 1 (+0/-0).
Oui bien sûr, le racisme c’est à cause des noms de variables en informatique.
D’ailleurs au boulot on nous a demandé de remplacer les mots whitelist et bkacklist par allowlist et denylist et le racisme a totalement disparu du jour au lendemain.
Je suis d’accord que c’est bien de contribuer à faire évoluer les mentalités, mais si la compatibilité avec l’existant est cassée, c’est pas génial.
[^] # Re: purée, les développeurs
Posté par Pol' uX (site web personnel) . Évalué à 2 (+0/-0).
Et du coup là ça casse quoi et où ?
Adhérer à l'April, ça vous tente ?
[^] # Re: purée, les développeurs
Posté par Benoît Sibaud (site web personnel) . Évalué à 6 (+3/-0).
Ce n'est pas en ne changeant rien pour ne pas casser la compatibilité que l'on va évoluer… par définition pour changer de façon pérenne, il faut modifier quelque chose et ne pas conserver ce qui était avant. Ça nécessite un effort de changer.
Au XXe siècle il a fallu modifier la variable électeur parce que les femmes ont obtenu (en France) le droit de vote. Puis on a eu le vrai pays vs les colonies, le vrai pays vs les territoires outremer, le vrai centre/la capitale vs l'outrepériph, etc., etc. Bref qui on inclut/exclut suivant l'origine, la nationalité, la religion, l'argent, la santé, le sexe, le statut, etc. C'est la vie en société, l'évolution de la nation, la vraie politique, blabla.
Il faut aussi noter une certaine dissonance cognitive mise en valeur ici : soit renommer des choses est mineur sans effet (ironie sur le racisme a totalement disparu du jour au lendemain.), alors on s'en fiche un peu, le coût est finalement assez faible. Soit renommer des choses est suffisamment important pour venir s'en outrer (le premier commentaire) et la vraie raison semble plus le refus du changement du vocabulaire que le minime changement de configuration impliqué. Pas de souci sur les opinions de chacun/chacune, mais faut pas essayer d'emballer ça dans une attaque sur les autres / les développeurs qui font des gigantesques changements apocalyptiques avec l'outrecuidance de le mentionner en petit dans une annonce…
Et maintenant mon avis perso dont on se fout sur le vocabulaire :
Dernier point sur l'empathie : ce n'est pas parce moi je m'en foutrais de ce changement de vocabulaire que je peux nier/mépriser le ressenti des autres. Au minimum je suis capable d'en discuter s'en mettre des noms d'oiseaux sur l'autre.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.