Linux kernel developers: This new BLM coding style avoids words like blacklist
Key Linux kernel maintainers have largely welcomed a new proposal by Intel engineer and fellow kernel maintainer Dan Williams to introduce inclusive terminology in the kernel's official coding-style document.
The first to sign off on Williams' proposal were Chris Mason and Greg Kroah-Hartman. But other maintainers have approved the proposal too, which requires kernel developers to avoid using the words 'slave', for development trees and branches, and 'blacklist'.
Developer
Williams argues that non-inclusive terminology distracts maintainers and "injures developer efficiency".
SEE: Diversity and Inclusion policy (TechRepublic Premium)
The recommended replacements for 'slave' are 'secondary', 'subordinate', 'replica', 'responder', 'follower', 'proxy', or 'performer'. Instead of blacklist, developers should use 'blocklist' or 'denylist'.
"In 2020 there was a global reckoning on race relations that caused many organizations to re-evaluate their policies and practices relative to the inclusion of people of African descent," Williams argues.
"The revelation of 2020 was that black voices were heard on a global scale and the Linux kernel project has done its small part to answer that call as it wants black voices, among all voices, in its developer community."
Microsoft-owned GitHub is also planning to drop master/slave and blacklist/whitelist terminology from the site as part of its response to the BLM protests.
Williams also deals with the expected opposition to a ban on the term blacklist, which has racial connotations when used today even if the term wasn't created with race in mind – compared with 'slave', which is tied to a history of human misery.
And he's against the idea of replacing blacklist/whitelist with different colors because understanding the meaning of colors always comes from a particular social or historical context, and this runs counter to the goal of inclusion.
"While 'slave' has a direct connection to human suffering, the etymology of 'blacklist' is devoid of a historical racial connection. However, one thought exercise is to consider replacing 'blacklist/whitelist' with 'redlist/greenlist'," he writes.
"Realize that the replacement only makes sense if you have been socialized with the concepts that 'red/green' implies 'stop/go'. Colors to represent a policy requires an indirection. The socialization of 'black/white' to have the connotation of 'impermissible/permissible' does not support inclusion."
Kernel maintainer Dave Airlie agreed that using colors to represent a policy is just a bad idea, even if there is no racist connotation or intent.
"I'd totally submit that red/black trees while in no way racist, are a horrible indirection, as it means nothing if you've never interacted with gambling culture, (and maybe James Bond movies)," wrote Airlie.
"Left/right trees make naturally more sense and translate into more languages, so yes I think removal of color naming is a good thing even for non-racist reasonings."
SEE: GitHub to replace "master" with alternative term to avoid slavery references
Willy Tarreau, a veteran kernel maintainer, was concerned that as a non-native English speaker, he may need to apply more filtering on words and that "to figure whether they are allowed by the language police is even more difficult".
"*This* injures developers' efficiency," he argued.
Mason suggested to Tarreau that among kernel developers there's little reason to be concerned about language police.
"Inside the kernel, it's just a group of developers trying to help each other produce the best quality of code. We've got a long history together and in general I think we're pretty good at assuming good intent," wrote Mason.
Tarreau also thinks that instead of a blocklist of words to be avoided, the project should avoid all words taken from the non-technical world. Mason agreed with this point.