Linux Manual Pages development
 help / color / mirror / Atom feed
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 --]

  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