>>> 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.
>>
>> Actually, as a non-native English speaker, the first time I saw
>> "list", I had to do
On Thu, 2020-07-09 at 17:13 +0100, Mark Brown wrote:
> On Thu, Jul 09, 2020 at 10:01:18AM -0600, Shuah Khan wrote:
> > On 7/9/20 4:43 AM, Mauro Carvalho Chehab wrote:
> > > For coherency, if "blacklist/whitelist" won't be used anymore, an
> > > alternative to graylist should also be provided.
> > W
On 7/9/20 4:43 AM, Mauro Carvalho Chehab wrote:
Em Tue, 7 Jul 2020 01:58:21 +0200
Tibor Raschko escreveu:
Allowlist/denylist terms are intuitive and action based which have a
globally uniform meaning.
Nobody has a problem understanding "blacklist" and "whitelist". These
are universally under
Em Tue, 7 Jul 2020 01:58:21 +0200
Tibor Raschko escreveu:
> > Allowlist/denylist terms are intuitive and action based which have a
> > globally uniform meaning.
>
> Nobody has a problem understanding "blacklist" and "whitelist". These
> are universally understood words even outside of computin
On 08/07/2020 06:42, Stephen Hemminger wrote:
> On Tue, 7 Jul 2020 02:03:36 +0300
> Pavel Begunkov wrote:
>
>> On 07/07/2020 01:28, Steven Rostedt wrote:
>>> On Tue, 7 Jul 2020 01:17:47 +0300
>>> Pavel Begunkov wrote:
>>>
Totally agree with you! But do we care then whether two _devices_
On Tue, 7 Jul 2020 02:03:36 +0300
Pavel Begunkov wrote:
> On 07/07/2020 01:28, Steven Rostedt wrote:
> > On Tue, 7 Jul 2020 01:17:47 +0300
> > Pavel Begunkov wrote:
> >
> >> Totally agree with you! But do we care then whether two _devices_ or
> >> _objects_
> >> are slave-master? Can't see h
> Blacklist most definitely has a negative connotation in technical use.
> You blacklist devices that don't work properly, you blacklist drivers
> that don't work for your hardware, you blacklist domains that are
> sending spam or trying to mount network attacks on your servers. Things
> on the bla
On Tue, Jul 07, 2020 at 02:48:25AM +0200, Tibor Raschko wrote:
> > More generally etymological arguments are just not super relevant here
> > anyway, the issues people have are around current perceptions rather
> > than where things came from.
>
> This is where ignoring etymology in this case fall
On Tue, Jul 07, 2020 at 05:45:42PM +0300, Mike Rapoport wrote:
> On Tue, Jul 07, 2020 at 09:41:47AM -0400, Steven Rostedt wrote:
> > On Tue, 7 Jul 2020 01:54:23 -0700
> > Kees Cook wrote:
> >
> > > "I will whitelist the syscall" -- sounds correct to me (same for
> > > "it is whitelisted" or "it i
> -Original Message-
> From: Steven Rostedt
>
> On Tue, 7 Jul 2020 09:49:21 +0300
> Mike Rapoport wrote:
>
> > > But that's all fine. The change is easy to do and is more descriptive
> > > even if I can't find terms that don't collide with my internal grammar
> > > checker. ;)
> >
> >
> -Original Message-
> From: Steven Rostedt
>
> On Tue, 7 Jul 2020 08:33:33 -0700
> Randy Dunlap wrote:
>
> > >> I was thinking good-list / bad-list.
> > >>
> > >> /me that has been doing a lot of git bisect lately...
> > >
> > > I think it depends on the context. I'd prefer a gramm
On Tue, 7 Jul 2020 08:33:33 -0700
Randy Dunlap wrote:
> >> I was thinking good-list / bad-list.
> >>
> >> /me that has been doing a lot of git bisect lately...
> >
> > I think it depends on the context. I'd prefer a grammatically awkward verb
> > that described
> > the action more specifical
On 7/7/20 8:24 AM, Bird, Tim wrote:
>
>
>> -Original Message-
>> From: Steven Rostedt
>>
>> On Tue, 7 Jul 2020 09:49:21 +0300
>> Mike Rapoport wrote:
>>
But that's all fine. The change is easy to do and is more descriptive
even if I can't find terms that don't collide with my i
On Tue, Jul 07, 2020 at 09:41:47AM -0400, Steven Rostedt wrote:
> On Tue, 7 Jul 2020 01:54:23 -0700
> Kees Cook wrote:
>
> > "I will whitelist the syscall" -- sounds correct to me (same for
> > "it is whitelisted" or "it is in whitelisting mode").
> >
> > "I will allow-list the syscall" -- sound
On Mon, Jul 06, 2020 at 09:08:57PM -0700, Dan Williams wrote:
> On Mon, Jul 6, 2020 at 12:16 PM Mark Brown wrote:
> > This, especially the bit about "revelation of 2020", sounds a little
> > off to me - I think it's that it's worryingly close to the frequently
> > derided pattern where people rec
On Mon, Jul 6, 2020 at 12:16 PM Mark Brown wrote:
>
> On Sat, Jul 04, 2020 at 01:02:51PM -0700, Dan Williams wrote:
>
> > +'blacklist'. Recommended replacements for 'slave' are: 'secondary',
> > +'subordinate', 'replica', 'responder', 'follower', 'proxy', or
>
> I'd second the suggestion of device
On Mon, Jul 6, 2020 at 11:30 AM Shuah Khan wrote:
>
> On 7/4/20 2:02 PM, Dan Williams wrote:
> > 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
> More generally etymological arguments are just not super relevant here
> anyway, the issues people have are around current perceptions rather
> than where things came from.
This is where ignoring etymology in this case falls apart, claiming that the
current meaning is more important than the his
> The suggestions you made will help us adapt inclusive terminology
> for the current times, and also help us move toward terms that are
> intuitive and easier to understand keeping our global developer
> community in mind.
> Allowlist/denylist terms are intuitive and action based which have a
> g
On 07/07/2020 01:28, Steven Rostedt wrote:
> On Tue, 7 Jul 2020 01:17:47 +0300
> Pavel Begunkov wrote:
>
>> Totally agree with you! But do we care then whether two _devices_ or
>> _objects_
>> are slave-master? Can't see how it fundamentally differs.
>
> The term slave carries a lot more meanin
On Tue, 7 Jul 2020 01:17:47 +0300
Pavel Begunkov wrote:
> Totally agree with you! But do we care then whether two _devices_ or _objects_
> are slave-master? Can't see how it fundamentally differs.
The term slave carries a lot more meaning than subordinate. I replied to
someone else but later rea
On 07/07/2020 01:10, Steven Rostedt wrote:
> On Tue, 7 Jul 2020 00:31:49 +0300
> Pavel Begunkov wrote:
>>> diff --git a/Documentation/process/coding-style.rst
>>> b/Documentation/process/coding-style.rst
>>> index 2657a55c6f12..4b15ab671089 100644
>>> --- a/Documentation/process/coding-style.rst
On Tue, 7 Jul 2020 00:31:49 +0300
Pavel Begunkov wrote:
> > diff --git a/Documentation/process/coding-style.rst
> > b/Documentation/process/coding-style.rst
> > index 2657a55c6f12..4b15ab671089 100644
> > --- a/Documentation/process/coding-style.rst
> > +++ b/Documentation/process/coding-style.rs
On Sat, Jul 04, 2020 at 01:02:51PM -0700, Dan Williams wrote:
> +'blacklist'. Recommended replacements for 'slave' are: 'secondary',
> +'subordinate', 'replica', 'responder', 'follower', 'proxy', or
I'd second the suggestion of device as an option here.
> +Of course it is around this point someo
On 7/4/20 2:02 PM, Dan Williams wrote:
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.
Hi Dan,
Thanks
On Mon, Jul 06, 2020 at 01:15:38PM +0200, Michael Kerrisk (man-pages) wrote:
> On 7/5/20 3:10 AM, Kees Cook wrote:
> > On Sat, Jul 04, 2020 at 08:10:33PM -0400, Matthew Wilcox wrote:
> >> Left-right tree makes no sense. It doesn't distinguish the rbtree from its
> >> predecessor the avl tree. I do
On Mon, 6 Jul 2020 11:22:10 -0400
Arvind Sankar wrote:
> Though I'm not sure if blueprint translates literally into other
> languages, it did actually have a logical reason, viz engineering
> drawings used to be blue/white. But logical reasons don't have to exist.
> In the case of colors, for exa
On 7/5/20 3:10 AM, Kees Cook wrote:
> On Sat, Jul 04, 2020 at 08:10:33PM -0400, Matthew Wilcox wrote:
>> Left-right tree makes no sense. It doesn't distinguish the rbtree from its
>> predecessor the avl tree. I don't think it's helpful to rename a standard
>> piece of computing terminology unless
On Sun, 5 Jul 2020 09:39:29 +1000
Dave Airlie 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
terminologie
On Sun, Jul 05, 2020 at 09:39:29AM +1000, Dave Airlie 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.
>
> You say "be inclusive" people don't think about it, they just go "I'
On Sun, 2020-07-05 at 09:39 +1000, Dave Airlie wrote:
> Why haven't they submitted patches
> removing slavery terminology from the kernel before?
Because inhuman devices in a master/slave hierarchy isn't
anything like chattel slavery?
Blacklist/whitelist has nothing to do with skin color?
Are re
On Sun, 5 Jul 2020 at 07:25, James Bottomley
wrote:
>
> On Sat, 2020-07-04 at 13:02 -0700, Dan Williams wrote:
> [...]
> > diff --git a/Documentation/process/inclusive-terminology.rst
> > b/Documentation/process/inclusive-terminology.rst
> > new file mode 100644
> > index ..a8eb26690eb
On 2020-07-04 14:25, James Bottomley wrote:
On Sat, 2020-07-04 at 13:02 -0700, Dan Williams wrote:
[...]
diff --git a/Documentation/process/inclusive-terminology.rst
[]
Could we just lose this entire document?
Yes please.
On Sat, 2020-07-04 at 13:02 -0700, Dan Williams wrote:
[...]
> diff --git a/Documentation/process/inclusive-terminology.rst
> b/Documentation/process/inclusive-terminology.rst
> new file mode 100644
> index ..a8eb26690eb4
> --- /dev/null
> +++ b/Documentation/process/inclusive-terminolo
34 matches
Mail list logo
