Faut-il opérer le retrait de termes comme master ou slave au motif de ce qu’ils véhiculent des stéréotypes raciaux ? Microsoft, qui a déjà étendu ses contributions au noyau Linux au-delà de son focus initial sur le support Hyper-V et d’autres besoins pour Azure, continue de s’impliquer dans des domaines plus généraux. Récemment, des ingénieurs de Microsoft ont travaillé sur des améliorations du langage Rust pour le noyau Linux. Maintenant, ils ont envoyé des correctifs pour rendre le langage du noyau Linux plus inclusif.Microsoft contribue activement au noyau Linux depuis un certain temps, et l’introduction du support du langage de programmation Rust en est un exemple. Cette fois-ci, Wedson Almeida Filho, un ingénieur de Microsoft impliqué dans l’initiative Rust pour Linux, a révélé que des correctifs ont été envoyés pour révolutionner l’initialisation des modules au sein du noyau.
Les derniers correctifs de Filho montrent l’engagement de Microsoft à faciliter la croissance de Rust au sein de l’écosystème Linux. Ces correctifs affinent les API d’allocation pour le code du noyau Rust et introduisent un nouveau concept : l’initialisation des modules directement à leur emplacement mémoire prévu. Cela élimine le besoin d’allocations de mémoire inutiles et permet aux modules de gérer efficacement des structures de données complexes telles que les verrous.
En résumé :
- Suppression de la bifurcation de la bibliothèque alloc.
- Utilisation de paramètres de drapeau d’allocation (par exemple, GFP_KERNEL, GFP_ATOMIC) lors de l’allocation.
- Élimination de la dépendance à la fonctionnalité instable allocator_api.
Ces efforts continus pour intégrer Rust au noyau Linux témoignent de l’importance croissante de ce langage dans le développement des systèmes d’exploitation. Microsoft, en tant qu’acteur majeur, contribue activement à cette évolution.
Des contributions qui vont au-delà de l'objectif commercial initial
Avec le temps, les contributions de Microsoft au noyau Linux se sont étendues au-delà de l'objectif commercial initial, à savoir la prise en charge d'Hyper-V et d'autres besoins pour Azure, ainsi qu'autour du sous-système Windows pour Linux (WSL), pour devenir des contributions plus générales. Microsoft a également embauché d'autres contributeurs clés à Linux, tout en s'intéressant à d'autres projets tels que systemd. Au début de la semaine dernière, un ingénieur de Microsoft a apporté des correctifs pour améliorer le langage Rust pour le noyau Linux, tandis qu'à la fin du week-end, des correctifs ont été apportés pour rendre le langage du noyau Linux plus inclusif.
Easwar Hariharan, ingénieur Linux chez Microsoft, a soumis un ensemble de quatorze correctifs visant à nettoyer le langage du code source du noyau Linux. Easwar travaille sur la plomberie Linux d’Azure, l’activation du silicium cloud comme Azure Cobalt et les affaires de virtualisation. Cette contribution de Microsoft, qui ne se limite pas à son cœur de métier, vise à rendre le langage du code plus respectueux et inclusif. En particulier, il s'agit de s'adapter aux dernières spécifications I2C, SMBus et I3C en amont afin d'utiliser les termes appropriés.
Concrètement, ces correctifs ajustent le vocabulaire utilisé dans le code et les commentaires pour adopter des termes plus appropriés. Par exemple, ils remplacent les termes « maître » et « esclave » par « contrôleur » et « cible » (ou « client »). Mais même pour ces correctifs, certaines questions ont été soulevées car les spécifications de l'industrie ont tendance à se référer à la nouvelle terminologie contrôleur/cible par opposition à client qui est utilisée dans la plupart de ces nouveaux correctifs du noyau. Parmi les développeurs du noyau en amont, il n'y a apparemment pas encore de consensus clair sur la distinction entre client et cible.
Ces modifications touchent près de quatre cents lignes de code, allant des sous-systèmes principaux aux pilotes graphiques AMD et Intel, en passant par divers pilotes multimédias et FBDEV, et d'autres codes I2C/I3C/SMBus.
Ces correctifs, qui visent à promouvoir un langage plus inclusif, sont disponibles sur la liste de diffusion du noyau Linux. Il est encourageant de voir Microsoft s’engager activement dans l’amélioration du noyau Linux, même au-delà de ses propres intérêts commerciaux.
Des changements qui s'opèrent depuis des années sur divers écosystèmes
Des projets comme Django (2014), CouchDB (2014), Drupal (2014), Redis (2017) et Python (2018) se sont déjà opposés à l'utilisation des termes master/slave. Tous ont le même argument : bien que ces termes aient été utilisés depuis des décennies, ils peuvent avoir des significations à caractère raciste, entre autres, pour les utilisateurs. Il serait donc bon de les éviter.
« Le mot "slave" a des connotations négatives (bien que cela puisse ou non être pertinent dans la dénomination d'un terme technique), y compris l'histoire de l'esclavage sur plusieurs siècles au bénéfice des puissances coloniales européennes, les travailleurs pénitentiaires aujourd'hui forcés de travailler dans des conditions parfois similaires à l'esclavage, les jeunes filles vendues dans l'esclavage sexuel dans de nombreuses régions du monde aujourd'hui », expliquait le projet Drupal. La connotation sexiste de ces termes avait particulièrement été citée lorsque la question était débattue pour le projet Django. Une ingénieure DevOps s'était en effet plainte que ses collègues lui faisaient souvent des blagues en utilisant les termes "master" et "slave".
Chez Python, il a été suggéré que la paire "master/slave" soit remplacée par des terminologies comme "leader/follower" ou "primary/replica". Dans le cas de Python, l'idée est venue de Victor Stinner, un développeur travaillant pour Red Hat. Il a publié cinq pull requests, ciblant plusieurs domaines, pour changer "master" et "slave" dans la documentation et le code Python par des termes comme "parent", "worker", "child" ou autres termes similaires.
« Pour des raisons de diversité, il serait bon d’essayer d’éviter la terminologie "master" et "slave" pouvant être associée à l’esclavage », a-t-il expliqué dans son rapport de bogue. Ses propositions n'ont pas du tout fait l'unanimité parmi les développeurs Python. « Est-il vraiment nécessaire de polluer la base de code Python avec l'idéologie/terminologie SJW ? Qu'est-ce qui viendra près cela ? » Demanda un développeur. Pour information, SJW (ou Social Justice Warrior) est un terme désignant un individu défendant, d'une manière outrée selon ses détracteurs, des causes sociales jugées progressistes (comme le féminisme, la lutte pour les droits civiques, le multiculturalisme, etc.).
« Pour autant que je sache, il n’y a pas un seul cas où les docs utilisent "master" pour faire référence à l’esclavage humain. Il n'y a pas non plus de cas où l’utilisation pourrait être considérée comme une approbation de [l'esclavage humain] », lance un autre développeur qui a demandé s'il y avait un préjudice démontrable causé par l'utilisation de ces termes.
GitHub a aussi pris part au bal en décidant en septembre 2020 de faire usage du terme « main » en lieu et place de « master » pour désigner la branche par défaut des projets. Voici l’explication que des responsables de la plateforme ont fourni : « main est le remplacement de master le plus populaire que l'on rencontre sur GitHub. Nous l'aimons parce qu'il est court, qu'il garde la mémoire musculaire intacte et qu'il se traduit bien dans la plupart des langues. »
Par défaut, GitHub utilisait le terme « master » pour désigner la version primaire d'un dépôt de code source. Les développeurs faisaient des copies de cette dernière sur leurs ordinateurs et y ajoutaient leur propre code, puis fusionnaient les modifications dans le dépôt master. « Dès le premier octobre 2020, tous les nouveaux dépôts que vous créerez utiliseront main plutôt que master pour désigner la branche par défaut », a alors annoncé GitHub.
Cette année de 2020 a été particulière pour le monde informatique. Suite au meurtre de Georges Floyd, qui a provoqué une vague d’indignations collectives laissant place à de violentes manifestations dans plusieurs villes du pays. Le monde de l'informatique n'a pas été en reste : des développeurs souhaitaient débarrasser l'industrie de termes jugés racistes ou violents comme "whitelist-blacklist", "master-slave" et "kill".
Aussi, début juin 2020, c’était au tour de l’équipe du langage de programmation Go de Google de se prononcer sur la question. Dans une publication, elle a annoncé le retrait des termes "whitelist" (liste blanche), "blacklist" (liste noire), "master" (maître) et "slave" (esclave) de sa documentation et de sa base de code. À la place de "whitelist" et "blacklist", elle annonce l’introduction des termes "allowlist" (liste d’autorisation) et "blocklist" (liste de refus) jugés plus explicites.
« Il est clair que certaines personnes sont blessées par ces termes et que leur utilisation suscite chez elles un sentiment de malaise, non pas pour des raisons techniques, mais en raison de leur contexte historique et social », a déclaré Google, en estimant qu'il s'agissait d'arguments suffisants pour les faire disparaître. « Master-slave est une métaphore oppressive qui ne sera et devrait jamais être totalement détachée de notre histoire », souligne un développeur de Microsoft, qui appelle à leur remplacement.
Puis, le même mois, les développeurs de la base de données MySQL ont annoncé leur intention de cesser d'utiliser et de remplacer des termes tels que master, slave, blacklist et whitelist dans le code source et la documentation de la base de données.
Dans un billet de blog, l’équipe Oracle MySQL a expliqué :
« Cela fait 20 ans que la réplication MySQL a été introduite dans MySQL 3.23.15 (sortie en mai 2000). Depuis lors, pratiquement tous les déploiements de bases de données MySQL en production utilisent la réplication afin d'atteindre une haute disponibilité, une reprise après sinistre, une évolutivité en lecture et divers autres objectifs.
« Quiconque utilise la réplication MySQL connaît les termes : ‘master’ et ‘slave’. Les origines de ces mots sont négatives. C’est clair. Chez MySQL, nous avons pris la décision de changer cette terminologie. Déjà, beaucoup d'entre nous ont changé la façon dont nous nous référons à ces rôles dans les billets de blog et les présentations - en utilisant généralement des termes comme ‘primaire’, ‘secondaire’, ‘source’ et ‘réplique’. Nous avons maintenant commencé le processus de modification de la syntaxe MySQL dans notre code source et notre documentation pour faire correspondre tout cela ».
Source : liste de diffusion Linux (1, 2)
Et vous ?
Quelle est votre opinion sur l’utilisation de Rust dans le noyau Linux ? Certains soutiennent que c’est une avancée majeure, tandis que d’autres craignent que cela puisse introduire des vulnérabilités inattendues. Qu’en pensez-vous ? Quels avantages voyez-vous à utiliser Rust par rapport à d’autres langages de programmation dans le noyau Linux ? Est-ce que la sécurité, la performance ou la lisibilité du code sont des facteurs décisifs pour vous ? Comment pensez-vous que l’adoption de Rust pourrait affecter la communauté open source ? Y a-t-il des préoccupations concernant la fragmentation ou la complexité accrue du développement ? Pensez-vous que ces modifications de terminologie sont importantes pour rendre le code source du noyau Linux plus respectueux et inclusif ? Pourquoi ou pourquoi pas ? Quelles autres expressions ou termes pourraient être révisés pour promouvoir une meilleure inclusion dans le développement logiciel en général ? Comment pouvons-nous encourager davantage d’entreprises et de contributeurs à s’engager activement dans des initiatives similaires pour améliorer la diversité et l’inclusion dans les projets open source ? Avez-vous déjà rencontré des problèmes de langage ou de terminologie dans d’autres projets open source ? Comment cela a-t-il été résolu ?Voir aussi :
Microsoft Word propose par défaut d'adopter l'écriture inclusive et le politiquement correct, que pensez-vous de cette fonctionnalité ? 
Envoyé par Ti-Slackeux
), lent à compiler etc... mais en tant qu'expert seriez-vous capable de me citer des langages libres (compilateur inclu) qui sont à la fois memory-safe, null-safe, thread-safe et qui ne requirent pas une VM que l'on doit installer et qui doit gérer un système de ramasse-miettes ?