From: Alejandro Colomar <alx@kernel.org>
To: "G. Branden Robinson" <g.branden.robinson@gmail.com>
Cc: linux-man@vger.kernel.org
Subject: Re: [PATCH] man7, man2: document SCHED_EXT policy
Date: Wed, 22 Apr 2026 20:08:24 +0200 [thread overview]
Message-ID: <aekK3aPO7fegzeC0@devuan> (raw)
In-Reply-To: <20260422172328.q65i3pge46mpaj6m@illithid>
[-- Attachment #1: Type: text/plain, Size: 3796 bytes --]
Hi Branden,
On 2026-04-22T12:23:28-0500, G. Branden Robinson wrote:
[...]
> > 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?
Off-topic, but in case you have the doubt, it can be settled:
There are as many levels as subclauses under 6.5 ("Expressions")
--I don't know the number of subclauses from the top of my head, though,
of course--, excluding of course 6.5.1 ("General").
In C23 (n3220), that is documented in footnote 82:
The syntax specifies the precedence of operators
in the evaluation of an expression,
which is the same as the order of
the major subclauses of this subclause,
highest precedence first.
[...]
Checking the number of subclauses, it happened to be 17 (18 - 1) in C23,
and remains the same number in C2y. That number seems to have stayed
stable: we already had 17 categories in C89 (but "Expressions" was then
3.3).
:)
> ")--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).
Here we exclusively use the spelling \f[] and \[bu]. That's why \(bu
was suspicious. I could expect it from an expert in the matter who
didn't know our style, but the author didn't seem one.
>
> > 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?
I haven't heard of any, but I suspect there is. I've seen some good
amount of LLM crap that I think I have a good eye for catching it (even
if sometimes I may not say it explicitly, especially when the author
knows it's not allowed --I may prefer to wait for the author to disclose
it voluntarily; that has the benefit of allowing me to evaluate the
limits of the honesty of the human--).
Cheers,
Alex
> Regards,
> Branden
>
> [1] https://en.wikipedia.org/wiki/Object_permanence
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2026-04-22 18:08 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
2026-04-22 18:08 ` Alejandro Colomar [this message]
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=aekK3aPO7fegzeC0@devuan \
--to=alx@kernel.org \
--cc=g.branden.robinson@gmail.com \
--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