lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <798B0FBF-D7A8-4631-8581-5D199DA50FF9@fb.com>
Date:   Mon, 6 Jul 2020 12:45:34 +0000
From:   Chris Mason <clm@...com>
To:     Willy Tarreau <w@....eu>
CC:     Dan Williams <dan.j.williams@...el.com>,
        "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
        Jonathan Corbet <corbet@....net>,
        Kees Cook <keescook@...omium.org>, Chris Mason <clm@...clm>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "ksummit-discuss@...ts.linuxfoundation.org" 
        <ksummit-discuss@...ts.linuxfoundation.org>,
        "tech-board-discuss@...ts.linuxfoundation.org" 
        <tech-board-discuss@...ts.linuxfoundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] CodingStyle: Inclusive Terminology

On 5 Jul 2020, at 0:55, Willy Tarreau wrote:

> On Sat, Jul 04, 2020 at 01:02:51PM -0700, Dan Williams wrote:
>> +Non-inclusive terminology has that same distracting effect which is 
>> why
>> +it is a style issue for Linux, it injures developer efficiency.
>
> I'm personally thinking that for a non-native speaker it's already
> difficult to find the best term to describe something, but having to
> apply an extra level of filtering on the found words to figure whether
> they are allowed by the language police is even more difficult.

Since our discussions are public, we’ve always had to deal with 
comments from people outside the community on a range of topics.  But 
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.

> *This*
> injures developers efficiency. What could improve developers 
> efficiency
> is to take care of removing *all* idiomatic or cultural words then. 
> For
> example I've been participating to projects using the term 
> "blueprint",
> I didn't understand what that meant. It was once explained to me and
> given that it had no logical reason for being called this way, I now
> forgot. If we follow your reasoning, Such words should be banned for
> exactly the same reasons. Same for colors that probably don't mean
> anything to those born blind.
>
> For example if in my local culture we eat tomatoes at starters and
> apples for dessert, it could be convenient for me to use "tomato" and
> "apple" as list elements to name the pointers leading to the beginning
> and the end of the list, and it might sound obvious to many people, 
> but
> not at all for many others.
>
> Maybe instead of providing an explicit list of a few words it should
> simply say that terms that take their roots in the non-technical world
> and whose meaning can only be understood based on history or local
> culture ought to be avoided, because *that* actually is the real
> root cause of the problem you're trying to address.

I’d definitely agree that it’s a good goal to keep out non-technical 
terms.  Even though we already try, every subsystem has its own set of 
patterns that reflect the most frequent contributors.

-chris

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ