linux-kernel - Re: [PATCH v3] code-of-conduct: Remove explicit list of discrimination factors

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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Sat, 8 Dec 2018 20:31:53 +0000
From:   Michael Tirado <mtirado418@...il.com>
To:     torvalds@...ux-foundation.org
Cc:     pavel@....cz, gregkh@...uxfoundation.org, geert@...ux-m68k.org,
        corbet@....net, frowand.list@...il.com, tomi.valkeinen@....fi,
        bvanassche@....org, linux-doc@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3] code-of-conduct: Remove explicit list of
 discrimination factors

On Mon, Dec 3, 2018 at 4:52 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Mon, Dec 3, 2018 at 4:15 AM Pavel Machek <pavel@....cz> wrote:
> >
> > Linus, I don't think Greg is doing good job maintaining this. Can you
> > take the patch?
> > (Or explain what is going on here, because I don't
> > think public has full story).
>
> I think Greg is doing a fine job, and I personally will not take
> patches to the CoC without *much* stronger reasons than just some
> random opinion.
>

Oh wow, see this is why I was 50/50 split on if I should still spend my
time working on Linux anymore, glad that's now settled.

I think Greg is doing a fine job dodging questions by saying, "it's
fine, just wait and see if something happens". Who are the $(people)
that choose to put this document into the kernel repo, and most
importantly, WHY? Was it You, Greg, Someone else too? What opinions
lead $(people) to choose the exact wording in this document, are
they not also "random" opinions on a non-technical issue that should
be equally disregarded?

> This is an area where everybody has opinions, and there is no inherent
> technical agreement ...
> ... actual problems caused by real
> issues ...
>

What a nice *professional* reply, you wear your best suit and tie
for sending emails now? We have reached canary status, IM{NR,R}O.
Not that you people care, but FWIW: I'm officially done with upstream
Linux as a bare metal kernel. I won't criticize any awkward patches
people are proposing, or propose any of my own because I've lost
trust in upstream to manage and defend the project adequately from
it's competitors so this is all starting to feel like a waste of
my free time now.

OK, I can't leave you all without letting you the one thing that angered
me nearly every time I updated to a new "stable" kernel over the last 3-4
years. The phrase "we don't break userspace" is misleading at best, unless
you assume all userspaces are running up to date .so's published by the
kernel maintainers. All of my code interfaces directly with the kernel and
not some .so layer that hides API breakage from it's users. Though my opinion
is just some random and absolutely not professional or corporate sponsored
opinion and thus in this newest age of Linux development, must be worthless!

Linux kernel dev's should now have to repeat this mantra "there is no
breakage, your userland just needs updates!" (obviously /s). I was actually
getting nervous about having to update from 4.14 soon and learning about the
fun new undocumented behaviors (sadly not /s).

Sorry if this wording is too harsh, I mean no disrespect just genuinely
DONE with this corporate bullhug[1] AND false sense of stability. AND the
fact that you feel there are no real problems caused by horribly worded
governance related documents with glaringly obvious and probably exploitable
flaws. A document that AFAICT nobody likes except You, Greg, and a few people
getting their paycheck from $(multi-billion-dollar corporation with
questionable motives and history).

[1]: In order to comply with the CoC, replace **** with a hug.

---
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c        | 2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
index 9cc10e438b3d..55a0060881ea 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
@@ -446,7 +446,7 @@ init_ram_restrict(struct nvbios_init *init)
 {
        /* This appears to be the behaviour of the VBIOS parser, and *is*
         * important to cache the NV_PEXTDEV_BOOT0 on later chipsets to
-        * avoid fucking up the memory controller (somehow) by reading it
+        * avoid hugging up the memory controller (somehow) by reading it
         * on every INIT_RAM_RESTRICT_ZM_GROUP opcode.
         *
         * Preserving the non-caching behaviour on earlier chipsets just
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc
b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc
index 3737bd27f74e..ee364c71cc2e 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc
@@ -46,7 +46,7 @@
 #define NV_PPWR_INTR_EN_SET_SUBINTR                                  0x00000800
 #define NV_PPWR_INTR_EN_SET_WATCHDOG                                 0x00000002
 #define NV_PPWR_INTR_EN_CLR                                              0x0014
-#define NV_PPWR_INTR_EN_CLR_MASK                    /* fuck i hate envyas */ -1
+#define NV_PPWR_INTR_EN_CLR_MASK                    /* hug i hate envyas */ -1
 #define NV_PPWR_INTR_ROUTE                                               0x001c
 #define NV_PPWR_TIMER_LOW                                                0x002c
 #define NV_PPWR_WATCHDOG_TIME                                            0x0034