netdev - Re: [RFC] bonding driver terminology change proposal

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: <CAKfmpSdS0Ckm4eA0hKECLNFvQo3nYU93N-oYO_wMeHoVGszA3g@mail.gmail.com>
Date:   Wed, 15 Jul 2020 15:23:37 -0400
From:   Jarod Wilson <jarod@...hat.com>
To:     Edward Cree <ecree@...arflare.com>
Cc:     Stephen Hemminger <stephen@...workplumber.org>,
        Michal Kubecek <mkubecek@...e.cz>,
        Netdev <netdev@...r.kernel.org>
Subject: Re: [RFC] bonding driver terminology change proposal

On Wed, Jul 15, 2020 at 8:57 AM Edward Cree <ecree@...arflare.com> wrote:
>
> Once again, the opinions below are my own and definitely do not
>  represent anything my employer would be seen dead in the same
>  room as.
>
> On 13/07/2020 23:41, Stephen Hemminger wrote:
> > As far as userspace, maybe keep the old API's but provide deprecation nags.
> Why would you need to deprecate the old APIs?
> If the user echoes 'slave' into some sysfs file (or whatever), that
>  indicates that they don't have any problem with using the word.
> So there's no reason toever remove that support — its _mere
>  existence_ isn't problematic for anyone not actively seeking to be
>  offended.
> Which I think is more evidence that this change is not motivated by
>  practical concerns but by a kind of performative ritual purity.
>
> This is dumb.  I suspect you all, including Jarod, know that this
>  is dumb, but you're either going along with it or keeping your
>  head down in the hope that it will all blow over and you can go
>  back to normal.  Unfortunately, it doesn't work like that; the
>  activists who push this stuff are never satisfied; making
>  concessions to them results not in peace but in further demands;
>  and just as the corporations today are caving to the current
>  demands for fear of being singled out by the mob, so they will
>  cave again to the next round of demands, and you'll be back in
>  the same position, trying to deal with bosses wanting you to
>  break uAPI without even a technical reason.
> And next time around, the mob will be bolder and the bosses more
>  pliant, because by giving in this time we'll have signalled that
>  we're weak and easily dominated.  I would advise anyone still in
>  doubt of this point to read Kipling's poem "Dane-geld".
> And we'll all be left wondering why kernel development is so
>  soulless and joyless that no-one, of _any_ colour, aspires to
>  become a kernel hacker any more.
>
> It's not too late to stop the crazy, if we all just stop
>  pretending it's sane.

No, it isn't a practical code concern motivating this change, it's
actually quite impractical from a code standpoint and has no technical
merit. I understand your position, but having seen many emotional
responses to issues surrounding this, I think it's a worthwhile effort
that many people actually do appreciate. Even if I'm not personally
offended by the terminology, as a white male, I don't think I possess
the life experiences to downplay the negative impact ongoing use of
terms like "slave" might have on people that are actual descendants of
slavery. Embracing and helping move forward social change seems like a
responsible thing to do here, as long as we can do it without breaking
the kernel and UAPI.

-- 
Jarod Wilson
jarod@...hat.com