Intel Is Pushing For 1984-Style Revision Of Words Allowed In Linux Kernel Development And Documentation
Intel Corporation has submitted a long documentation proposal for "inclusive-terminology" to the Linux Kernel Mailing List which forbids commonly used terminology like master/slave and blacklist/whitelist. The Intel-proposed new-speak replacements such red/green seem more confusing than the long-used long-established commonly known terms they would replace. A majority of kernel developers seem to be on-board with Intel's new-speak proposals.
The Big Picture
The American branch of the internatinal communist terrorist group Antifa teamed up with the Marxist communist group BlackLivesMatter late May 2020 after a serial criminal named George Floyd died in police custody with large quantities of illegal drugs in his system. The communists seized the George Floyd tragedy and used it as a pre-text to start violent riots and demonstrations in the US and some parts of Europe. All the large multinational corporations invested in globalism and all the media outlets they own were quick to announce their undying support for the revitalized communist movement.
BlackLivesMatter co-founder Patrisse Cullors: "The first thing, I think, is that we actually do have an ideological frame. Myself and Alicia in particular are trained organizers. We are trained Marxists."
Several technology companies, including Twitter, Google and Microsoft, who owns GitHub, seized the opportunity to increase the censorship on their respective user-generated platforms. Microsoft forbade the use of the terms master/slave on their GitHub product and Twitter Engineering did the same on publicly published "internal" guidelines. US-based military industrial complex technology giant Intel is now trying to place similar corporate 白左 rules onto the Linux kernel community.
Dan Williams, Principal Engineer at Intel Corporation, launched Intel's long-planned efforts to impose new-speak rules on the Linux kernel community with a proposed patch titled "CodingStyle: Inclusive Terminology" on July 4th. His justification for why such a documentation addition would be needed is:
"Recent events have prompted a Linux position statement on inclusive terminology. Given that Linux maintains a coding-style and its own idiomatic set of terminology here is a proposal to answer the call to replace non-inclusive terminology."
Intel would like to add the following to
" For symbol names, avoid introducing new usage of the words 'slave' and 'blacklist'. Recommended replacements for 'slave' are: 'secondary', 'subordinate', 'replica', 'responder', 'follower', 'proxy', or 'performer'. Recommended replacements for blacklist are: 'blocklist' or 'denylist'.
Exceptions for introducing new usage is to maintain a userspace ABI, or when updating code for an existing (as of 2020) hardware or protocol specification that mandates those terms. For new specifications consider translating specification usage of the terminology to the kernel coding standard where possible. See process/inclusive-terminology.rst for details."
Intel would also like to add a brand new file named
Documentation/process/inclusive-terminology.rst to the
Documentation/ folder with the following content:
" Linux kernel inclusive terminology
The Linux kernel is a global software project, and 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. This document describes why the 'Naming' section in :ref:`process/coding-style.rst <codingstyle>` recommends avoiding usage of 'slave' and 'blacklist' in new additions to the Linux kernel.
On the triviality of replacing words
The African slave trade was a brutal system of human misery deployed at global scale. Some word choice decisions in a modern software project does next to nothing to compensate for that legacy. So why put any effort into something so trivial in comparison? Because the goal is not to repair, or erase the past. The goal is to maximize availability and efficiency of the global developer community to participate in the Linux kernel development process.
Word choice and developer efficiency
Why does any software project go through the trouble of developing a document like process/coding-style.rst? It does so because a common coding style maximizes the efficiency of both maintainers and developers. Developers learn common design patterns and idiomatic expressions while maintainers can spot deviations from those norms. Even non-compliant whitespace is considered a leading indicator to deeper problems in a patchset. Coding style violations are known to take a maintainer "out of the zone" of reviewing code. Maintainers are also sensitive to word choice across specifications and often choose to deploy Linux terminology to replace non-idiomatic word-choice in a specification.
Non-inclusive terminology has that same distracting effect which is why it is a style issue for Linux, it injures developer efficiency.
Of course it is around this point someone jumps in with an etymological argument about why people should not be offended. Etymological arguments do not scale. The scope and pace of Linux to reach new developers exceeds the ability of historical terminology defenders to describe "no, not that connotation". 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.
Really, 'blacklist' too?
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'. 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."
How People Of Colour In The Technology Community View The Proposal
Response From The Linux Kernel Community
Employees by large US corporations like IBM-owned Red Hat were quick to flag support for Intel's Marxist new-speak proposal. More independent and free-thinking developers were more critical. Those who have lived under authoritarian communist regimes tend to be more sceptical towards Marxist idea than those who have no knowledge of the Soviet gulags where millions of people were either worked to death or starved to death.
Russian developer Pavel Begunkov, well-known for his many excellent contributions to the Linux block sub-system, had this to say about the proposal:
"Code styles also exist to not think about things that doesn't matter, as well as terminologies do -- you see it, and the meaning is apparent. And that betrays the whole idea when you replace well-known terms with some random words.
Well, if you're trying to point people what to say and how to think, could you please __at least__ be consistent? That would be really nice.
Let me outline -- discrimination is an issue. And creating a common vocabulary can be pretty useful. But instead of it being helpful, the only thing I see here is ill-conceived and pretty arrogant essay."
A semi-anonymous person called "opal hart" pointed out that nobody is actually using the technical terms Intel and other mega-corporations wants forbidden out of context:
"Dave Airlie (Red Hat) wrote:
> I don't totally agree on that, because like the CoC discussion, people
> need concrete examples. People need reasons, saying simply "be
> inclusive" doesn't work.
Which people? because so far the only people I've seen take these terminologies out of computing context, are those who are only voicing their "concern" out of bad faith, as well as those who fall for the concern-trolling bait. The meta-discussion serves to stir up noise and waste time that's better spent on other things.
History pains, sure, but I believe it serves no justice to erase every trace of bad things that happened in history. That includes use of words tangentially related to such events."
Daniel Palmer, self-described as "a nobody in the kernel world", pointed out that new-speak will cause problems for those who are not native English-speakers:
"I can imagine that by changing terminology that has been in use for so long that it's been imported into other languages directly or is common enough that non-native speakers know what it means might have exactly the opposite result by excluding people that aren't native English speakers and can't decode synonyms that are obvious to a native speaker."
Belgian video sub-system wizard Laurent Pinchart pointed out that rules that try to turn everyone into a mindless grey mass results in exclusion, not inclusion:
"One of the intellectual rewards I find in working with the kernel is that our community is international and multicultural, allowing me to learn about other cultures. Aiming for the lowest common denominator seems to me to be closer to erasing cultural differences than including them."
Tibor Rosko, based in the Slovak Republic, wrote a very long and thoughtful message explaining how he believes the proposed corporate new-speak regulations would be "Sending the wrong message".
"I'm pretty sure everybody agrees that being inclusive is more than just using the right words. Being truly inclusive means not caring about the origin, birth, age, sex, skin color (amongst other things) at all. This means not judging people based on these factors, and being friendly, inviting and supportive with everybody in everyday life by default.
I'll go out on a limb and claim that nobody who wrote "master-slave" during development of a device driver, or used the word "blacklist" was actually thinking of African people or human slavery. In the context of the Linux kernel (and in computing in general), these words have a long history and have zero bad connotation, no racism, and absolutely null offense. One could argue that recommending to retroactively remove such references (which the original proposal does) assumes that these were offensive, hence suggesting to a certain degree that past developers who have used these words were possibly racists. Retroactively removing those occurrences from code is thus, I honestly think, disrespecting and insulting to the original authors.
The "black" in "blacklist" has nothing to do with African or Afro-American people. No matter how many occurrences of "black" we eradicate from our dictionary, the word "black" will always have bad connotations. This connotation stems from darkness, the absence of beautiful colors, and historically from the coldness, darkness and insecurity of the night.
The patch author goes into detail to "illustrate" how avoiding these words will improve efficiency. I'm sorry to call this out, but this is utterly bogus and distracting from the issue at hand. First of all, not any maintainer has been slowed done or has worked less efficiently because they saw the word "blacklist" or "slave" in the kernel sources. These *technical* phrases are not like bad code formatting where disconformity leads to worse readability or makes the coding intent harder to follow or understand. Quite the contrary, if anybody read the proposed "denylist" instead of "blacklist", they will stop for a second, think "what an odd choice of words...", and if it wasn't for the current black-lives-matter movement, would have a year ago probably even refactored the code (or requested a v2-patch) with the usual terminology of "blacklist". In other words, this argument has zero real-life basis and will, if implemented, achieve the opposite effect of what it is claiming."
We encourage you to read the full very long message from very based (in the Slovak Republic) Tibor Rosko as we have shortened it down dramatically and omitted many good parts. Rosko posted another shorter message later in the discussion thread where he pointed out that
"Nobody has a problem understanding "blacklist" and "whitelist". These are universally understood words even outside of computing. Claiming that we need clearer alternatives is smoke and mirrors."
The proposed Intel 白左 new-speak patch has, as of today, not been merged. It is, as it stands, a mere proposal.
Facebook's Chris Mason, Tesla asset Olof Johansson, Intel's Dan Williams and Greg Kroah-Hartman have signed off on merging this patch. The rest of the kernel developers are still debating if they want to submit themselves to Intel-drafted Marxist new-speak regulations. It seems more likely than not that the new-speak rules will be merged into the mainline kernel tree.