Linux Manual Pages development
 help / color / mirror / Atom feed
From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
To: Alejandro Colomar <alx@kernel.org>
Cc: linux-man@vger.kernel.org
Subject: Re: [PATCH] man7, man2: document SCHED_EXT policy
Date: Wed, 22 Apr 2026 12:23:28 -0500	[thread overview]
Message-ID: <20260422172328.q65i3pge46mpaj6m@illithid> (raw)
In-Reply-To: <aej9PG3FsVRGaR3W@devuan>

[-- Attachment #1: Type: text/plain, Size: 2617 bytes --]

Hi Alex,

At 2026-04-22T18:59:01+0200, Alejandro Colomar wrote:
> I've seen several other clues in the patch.  This was the once that
> confirmed it to me.  At first I thought that maybe the contributor
> could not know that BR exists, and thus try that naively (I've seen
> that done in other patches).

Oh yes.  Ignorance of man(7)'s font alternation macros is regrettably
widespread.

All of the best people get along just fine with BR, let me assure you.

> However, 2 lines below there the patch introduced a line using BR
> perfectly.  That very much read like random LLM stuff.

Nice catch.  I like the way you sussed that out.  While humans are not
immune from this class of error (forgetting something you "knew" 60
seconds ago--maybe more like 60 nanoseconds in LLM time), it's uncommon
among mentally healthy people who haven't been hitting the "substances".

I'm reminded of how toddlers acquire object permanence.[1]  Not _quite_
the same thing, as abstract knowledge is more easily lost ("what are the
conventional units of the ideal gas constant?  how many operator
precedence levels does C have, again?")--but it seems close.

A course for people red-teaming LLMs to pursue, maybe.

> There was also the arbitrary combined use of .P and .PP.  I suspect no
> human would use both in a document, unless the surrounding style
> already uses both (which could confuse).  Since we only have .P, the
> .PP came out of nowhere.

Another good catch.  As you note, the domain is limited.  In documents
with long histories and multiple contributors, the pointless profusion
of paragraphing macros with identical semantics is sadly common.

> And then there's the extensive use of \f (without brackets)

Still _really_ common in the global man page corpus.  But yeah, a hard
mistake to make for someone who's a total n00b to man page writing in
general _and_ to the Linux man-pages project.  People don't think up
that syntax, they crib it from somewhere.  Or an LLM does it for them.

> and \(bu, of which we have no cases anymore.

Unlike `\f`, I regard `\(bu` [preferably spelled `\[bu]`] as cromulent
usage.  We need not be afraid of bullet characters.  They degrade to
US-ASCII perfectly well in groff (and mandoc(1) too) and I'm confident
that this special character will work everywhere the Linux man-pages are
likely to be formatted.  See groff_char(7).

> All of this was very suspicious, so I had to ask.

Is there a resource that collects "here's how I caught an LLM-generated
software patch/research paper/court filing" stories?

Regards,
Branden

[1] https://en.wikipedia.org/wiki/Object_permanence

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2026-04-22 17:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-12 18:16 [PATCH] man7, man2: document SCHED_EXT policy Cheng-Yang Chou
2026-04-22 16:02 ` Alejandro Colomar
2026-04-22 16:13   ` Cheng-Yang Chou
2026-04-22 16:36     ` G. Branden Robinson
2026-04-22 16:59       ` Alejandro Colomar
2026-04-22 17:23         ` G. Branden Robinson [this message]
2026-04-22 18:08           ` Alejandro Colomar
2026-04-22 16:46   ` Cheng-Yang Chou
2026-04-22 17:04     ` Alejandro Colomar
2026-04-22 17:04     ` G. Branden Robinson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260422172328.q65i3pge46mpaj6m@illithid \
    --to=g.branden.robinson@gmail.com \
    --cc=alx@kernel.org \
    --cc=linux-man@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox