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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.