From: Alejandro Colomar <alx@kernel.org>
To: "G. Branden Robinson" <g.branden.robinson@gmail.com>
Cc: "Collin Funk" <collin.funk1@gmail.com>,
"Arsen Arsenović" <arsen@aarsen.me>,
"Maciej W. Rozycki" <macro@orcam.me.uk>,
"Paul Eggert" <eggert@cs.ucla.edu>,
linux-man@vger.kernel.org, bug-gnulib@gnu.org,
libc-alpha@sourceware.org
Subject: Re: the Linux man-pages as an educational tool
Date: Mon, 3 Aug 2026 14:21:17 +0200 [thread overview]
Message-ID: <anCAeQ5YNwXwSTWA@devuan> (raw)
In-Reply-To: <20260803020908.efqt5ilkcjq4z3yz@illithid>
[-- Attachment #1: Type: text/plain, Size: 5073 bytes --]
Hi Branden,
> Date: 2026-08-02 21:09:08-0500
> From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
>
> At 2026-08-03T01:42:57+0200, Alejandro Colomar wrote:
> > > > > Date: 2026-08-02 16:27:21-0700
> > > > > From: Collin Funk <collin.funk1@gmail.com>
> > > > > I can't help but wonder of what happens in WG 14 rejects this
> > > > > controversial, as obvious by this thread, change. Will the
> > > > > man-pages changes be reverted?
> > >
> > > > > Or will we slowly watch them document personal
> > > > > preferences instead of existing standards?
> > >
> > > BTW, as I showed in another subthread, strncpy(3) did contain
> > > opinionated comments well before I was involved. If you're really
> > > going to accuse me of that, better make sure you get the history
> > > right.
> >
> > Oh, and while at it, please also read my review of glibc's own
> > opinionated and bogus documentation about string truncation.
>
> I don't think this rhetorical tactic is a sound one. You are implying
> that because Collin (and perhaps others) are not on record as having
> already consistently opposed editorializing in the glibc manual, or in
> the Linux man-pages prior to your stewardship, that they are hypocrites.
>
> First, that's not necessarily true. Who's read every word of either
> work? Who had already done so 5, 10, or 20 years ago?
He doesn't need to have read every word of the glibc manual, but this
precise text he could have read it, because it was mentioned by Paul in
this thread (different subthread) prior (19:28 UTC) to his message, and
reviewed by me also prior (20:31 UTC) to his message (23:27 UTC).
Date: Sun, 2 Aug 2026 14:28:33 -0500
From: Paul Eggert <eggert@cs.ucla.edu>
Message-ID: <8715af47-867c-417a-8ef5-7b4b7ceb2c31@cs.ucla.edu>
Date: Sun, 2 Aug 2026 22:31:59 +0200
From: Alejandro Colomar <alx@kernel.org>
Message-ID: <am-eAGL6OWqP9Yah@devuan>
Date: Sun, 02 Aug 2026 16:27:21 -0700
From: Collin Funk <collin.funk1@gmail.com>
Message-ID: <875x1sp0h2.fsf@gmail.com>
Also relevant is the fact that he accused me of "slowly" documenting
"personal preferences". His wording implies that it wasn't there
before. Maybe I misunderstood, though. I'd be happy to rectify if I
was wrong.
While he didn't need to know whether it was there before, it would be
good to make some effort to learn whether that was the case, before
making such a serious accusation.
In this specific case, again, the relevant text had been shown by me in
this thread (different subthread), prior to (13:17 UTC) his message, and
thus again he should have known.
Date: Sun, 2 Aug 2026 15:17:04 +0200
From: Alejandro Colomar <alx@kernel.org>
Message-ID: <am8_MfPmud43naU-@devuan>
> A charge of hypocrisy can only stick well if you can establish that your
> interlocutors _endorsed_ the editorializing contemporaneously when it
> was done by someone else, but are refusing to endorse yours.
I believe the timestamps above, and the fact that he's been (obviously)
aware of this thread, are sufficient for this charge in this case.
I do agree that in general we shouldn't attribute hypocrisy without
proof, when it might actually be just lack of information.
> But there are more fundamental reasons to conduct this struggle on
> different grounds, which are that (1) people get to change their minds;
Oh, indeed; I've done plenty of times, and it's good. I certainly
welcome that.
> and (2) people get to raise defects even if they are old ones.
>
> Thus, if you feel justified in "relitigating", in Joseph's term, the
> ANSI C Committee's decision in the late 1980s to scotch the memory.h
> header file, then Collin gets to "relitigate" past editorializing by
> (I guess?) Michael Kerrisk in the Linux man-pages, or by the glibc
> authors in their Texinfo manual.
Certainly.
> Thus, here you have handed Collin an easy annulment of your point: he
> can simply say, "well I object to those, too".
I'd welcome that as being consistent, and would then apologize, if for
some reason he really wasn't aware of the messages whose timestamps are
shown above.
If he was aware, then I wouldn't apologize, because the offense and
hypocrisy would have happened, but still, I'd welcome a positive change
of mind, and leave both my and his words in the past.
> Every generation of engineers bears a responsibility to remake the world
> anew. That which endures does so because its quality is re-tested and
> re-proved by successive cohorts of humans growing up and running
> straight at it with their freshly trained minds and novel phenomena of
> recent invention. When an artifact persists because it's protected from
> the bratty young philistines by older people who, as William F. Buckley
> put it, stand athwart history and yell "stop!", it fails to prove its
> continued utility: it stops being an engineered product and becomes an
> antiquarian one.
Have a lovely day!
Alex
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2026-08-03 12:21 UTC|newest]
Thread overview: 134+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-31 21:18 [PATCH 0/2] alx-0097r1 - <memory.h>, the legitimate header for memcpy(3) et al Alejandro Colomar
2026-07-31 21:18 ` [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h> Alejandro Colomar
2026-07-31 21:23 ` Joseph Myers
2026-07-31 21:28 ` Alejandro Colomar
2026-07-31 21:54 ` Sam James
2026-07-31 22:18 ` Alejandro Colomar
2026-08-01 0:12 ` Alejandro Colomar
2026-08-01 14:43 ` Sam James
2026-07-31 21:51 ` on the irresponsibility of pursuing C language reform (was: [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h>) G. Branden Robinson
2026-07-31 21:59 ` on the irresponsibility of pursuing C language reform Sam James
2026-07-31 22:24 ` G. Branden Robinson
2026-07-31 23:19 ` Alejandro Colomar
2026-08-01 14:52 ` Sam James
2026-08-01 12:01 ` Alejandro Colomar
2026-08-01 12:04 ` Alejandro Colomar
2026-08-01 14:38 ` Sam James
2026-08-01 15:15 ` Alejandro Colomar
2026-08-01 16:10 ` Sam James
2026-08-01 17:09 ` Alejandro Colomar
2026-08-01 21:34 ` G. Branden Robinson
2026-08-01 22:22 ` Alejandro Colomar
2026-08-01 22:26 ` Alejandro Colomar
2026-08-03 13:42 ` Joseph Myers
2026-08-03 14:22 ` Alejandro Colomar
2026-08-03 14:38 ` on glibc forking/reclaiming its man pages (was: on the irresponsibility of pursuing C language reform) G. Branden Robinson
2026-08-03 14:44 ` Joseph Myers
2026-08-03 15:18 ` G. Branden Robinson
[not found] ` <CAETFuj2OwoyK9J85r2f0RoXbHbXKA4gQJ=JZ-7=QoqGcMwk0+Q@mail.gmail.com>
2026-08-01 22:44 ` on the irresponsibility of pursuing C language reform Alejandro Colomar
2026-08-01 23:24 ` Alejandro Colomar
2026-08-01 23:53 ` proposed revision to memory.h(3head) (was: on the irresponsibility of pursuing C language reform) G. Branden Robinson
2026-08-02 0:27 ` Alejandro Colomar
2026-08-02 1:03 ` Alejandro Colomar
2026-08-03 0:47 ` proposed revision to memory.h(3head) Alejandro Colomar
2026-08-03 17:58 ` Mark Harris
2026-08-03 18:47 ` Alejandro Colomar
2026-08-03 20:14 ` Mark Harris
2026-08-03 23:36 ` Alejandro Colomar
2026-08-04 3:25 ` Mark Harris
2026-08-03 14:10 ` proposed revision to memory.h(3head) (was: on the irresponsibility of pursuing C language reform) Joseph Myers
2026-08-03 14:31 ` Alejandro Colomar
2026-08-02 12:52 ` on the irresponsibility of pursuing C language reform Steve Summit
2026-08-02 13:17 ` Alejandro Colomar
2026-08-02 13:45 ` Steve Summit
2026-08-02 14:11 ` Alejandro Colomar
2026-08-02 19:28 ` Paul Eggert
2026-08-02 20:31 ` Alejandro Colomar
2026-08-03 3:28 ` Paul Eggert
2026-08-03 11:39 ` Alejandro Colomar
2026-08-03 13:23 ` Joseph Myers
2026-08-01 20:18 ` G. Branden Robinson
2026-08-01 20:42 ` Alejandro Colomar
2026-08-01 20:45 ` Alejandro Colomar
2026-08-01 20:52 ` G. Branden Robinson
2026-08-01 21:12 ` Alejandro Colomar
2026-07-31 22:10 ` on the irresponsibility of pursuing C language reform (was: [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h>) Joseph Myers
2026-07-31 22:21 ` Alejandro Colomar
2026-07-31 22:28 ` [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h> G. Branden Robinson
2026-07-31 22:42 ` on the irresponsibility of pursuing C language reform (was: [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h>) Joseph Myers
2026-07-31 22:52 ` Alejandro Colomar
2026-07-31 23:11 ` Joseph Myers
2026-07-31 23:32 ` G. Branden Robinson
2026-08-01 12:39 ` Alejandro Colomar
2026-08-01 14:26 ` Christopher Bazley
2026-08-01 15:29 ` Alejandro Colomar
2026-07-31 23:45 ` on the irresponsibility of pursuing C language reform (was: " Alejandro Colomar
2026-08-01 12:39 ` Douglas McIlroy
2026-08-01 19:54 ` G. Branden Robinson
2026-08-01 20:35 ` Alejandro Colomar
2026-07-31 23:08 ` [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h> G. Branden Robinson
2026-07-31 23:28 ` Joseph Myers
2026-07-31 23:57 ` G. Branden Robinson
2026-08-01 0:06 ` Alejandro Colomar
2026-07-31 22:05 ` Alejandro Colomar
2026-07-31 22:16 ` Joseph Myers
2026-07-31 22:33 ` Alejandro Colomar
2026-07-31 23:48 ` [PATCH 1/2] man/man3/{mem, strn}*(): " Collin Funk
2026-07-31 23:52 ` Alejandro Colomar
2026-08-01 0:01 ` Alejandro Colomar
2026-08-04 2:35 ` Thorsten Glaser
2026-07-31 21:19 ` [PATCH 2/2] man/man*/{string.3,memory.h.3head}: Move functions to a new page memory.h(3head) Alejandro Colomar
2026-07-31 21:20 ` [PATCH 0/2] alx-0097r1 - <memory.h>, the legitimate header for memcpy(3) et al Alejandro Colomar
2026-08-01 0:25 ` [PATCH v2] man/man3/mem*(): SYNOPSIS: Document non-standard mem*() functions as provided by <memory.h> Alejandro Colomar
2026-08-01 22:22 ` Bruno Haible
2026-08-01 22:38 ` Alejandro Colomar
2026-08-01 22:55 ` Bruno Haible
2026-08-01 23:10 ` Alejandro Colomar
2026-08-01 23:26 ` Collin Funk
2026-08-01 23:34 ` Alejandro Colomar
2026-08-01 23:29 ` Paul Eggert
2026-08-01 23:36 ` Alejandro Colomar
2026-08-02 0:08 ` the Linux man-pages as an educational tool (was: [PATCH v2] man/man3/mem*(): SYNOPSIS: Document non-standard mem*() functions as provided by <memory.h>) G. Branden Robinson
2026-08-02 0:45 ` Alejandro Colomar
2026-08-02 1:04 ` the Linux man-pages as an educational tool Collin Funk
2026-08-02 1:15 ` G. Branden Robinson
2026-08-02 1:15 ` Alejandro Colomar
2026-08-02 1:49 ` Collin Funk
2026-08-02 11:29 ` Alejandro Colomar
2026-08-02 11:47 ` Alejandro Colomar
2026-08-02 12:04 ` Alejandro Colomar
2026-08-02 21:23 ` Maciej W. Rozycki
2026-08-02 21:34 ` Alejandro Colomar
2026-08-02 23:08 ` Arsen Arsenović
2026-08-02 23:10 ` G. Branden Robinson
2026-08-02 23:27 ` Collin Funk
2026-08-02 23:37 ` Alejandro Colomar
2026-08-02 23:41 ` Alejandro Colomar
2026-08-02 23:42 ` Alejandro Colomar
2026-08-03 1:12 ` Alejandro Colomar
2026-08-03 2:09 ` G. Branden Robinson
2026-08-03 12:21 ` Alejandro Colomar [this message]
2026-08-03 14:05 ` Sam James
2026-08-03 14:40 ` Alejandro Colomar
2026-08-03 15:34 ` G. Branden Robinson
2026-08-03 16:11 ` Alejandro Colomar
2026-08-03 16:15 ` Sam James
2026-08-03 16:43 ` Alejandro Colomar
2026-08-03 10:28 ` the Linux man-pages as an educational tool... and a bit about C Αγαθοκλής Χατζημανίκας
2026-08-03 14:03 ` the Linux man-pages as an educational tool Sam James
2026-08-03 14:28 ` Alejandro Colomar
2026-08-04 2:39 ` Collin Funk
2026-08-03 16:09 ` on project management (was: the Linux man-pages as an educational tool) G. Branden Robinson
2026-08-03 19:46 ` enh
2026-08-03 21:09 ` on project management Arsen Arsenović
2026-08-02 23:30 ` the Linux man-pages as an educational tool Alejandro Colomar
2026-08-03 11:00 ` Arsen Arsenović
2026-08-03 16:07 ` Jeffrey Walton
2026-08-03 16:17 ` Alejandro Colomar
2026-08-03 19:31 ` Joseph Myers
2026-08-03 19:47 ` Alejandro Colomar
2026-08-03 13:51 ` When and why realloc(,0) was broken in glibc in 1999 Alejandro Colomar
2026-08-03 12:35 ` the Linux man-pages as an educational tool Bruno Haible
2026-08-03 13:07 ` Alejandro Colomar
2026-08-03 19:45 ` Joseph Myers
2026-08-03 19:50 ` Alejandro Colomar
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=anCAeQ5YNwXwSTWA@devuan \
--to=alx@kernel.org \
--cc=arsen@aarsen.me \
--cc=bug-gnulib@gnu.org \
--cc=collin.funk1@gmail.com \
--cc=eggert@cs.ucla.edu \
--cc=g.branden.robinson@gmail.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-man@vger.kernel.org \
--cc=macro@orcam.me.uk \
/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.