Re: the Linux man-pages as an educational tool

--sxzbalvdwtiuwivq
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
From: Alejandro Colomar <[email protected]>
To: "G. Branden Robinson" <[email protected]>
Cc: Collin Funk <[email protected]>, 
	Arsen =?utf-8?Q?Arsenovi=C4=87?= <[email protected]>, "Maciej W. Rozycki" <[email protected]>, 
	Paul Eggert <[email protected]>, [email protected], [email protected], 
	[email protected]
Subject: Re: the Linux man-pages as an educational tool
Message-ID: <anCAeQ5YNwXwSTWA@devuan>
References: <am6X32HkGdm2xTd7@devuan>
 <[email protected]>
 <am-2d02e1qq78Asv@devuan>
 <[email protected]>
 <20260802231058.o7gud4bd7co2nbhv@illithid>
 <[email protected]>
 <am_TTjDLlAI68zkp@devuan>
 <am_VUE1SzxqRkTAo@devuan>
 <am_V3bvOiH9TaJQW@devuan>
 <20260803020908.efqt5ilkcjq4z3yz@illithid>
MIME-Version: 1.0
In-Reply-To: <20260803020908.efqt5ilkcjq4z3yz@illithid>

Hi Branden,

> Date: 2026-08-02 21:09:08-0500
> From: "G. Branden Robinson" <[email protected]>
>
> At 2026-08-03T01:42:57+0200, Alejandro Colomar wrote:
> > > > > Date: 2026-08-02 16:27:21-0700
> > > > > From: Collin Funk <[email protected]>
> > > > > 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?
> > >=20
> > > > > Or will we slowly watch them document personal
> > > > > preferences instead of existing standards?
> > >=20
> > > 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.
> >=20
> > Oh, and while at it, please also read my review of glibc's own
> > opinionated and bogus documentation about string truncation.
>=20
> 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.
>=20
> 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 <[email protected]>
	Message-ID: <[email protected]>

	Date: Sun, 2 Aug 2026 22:31:59 +0200
	From: Alejandro Colomar <[email protected]>
	Message-ID: <am-eAGL6OWqP9Yah@devuan>

	Date: Sun, 02 Aug 2026 16:27:21 -0700
	From: Collin Funk <[email protected]>
	Message-ID: <[email protected]>

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 <[email protected]>
	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.
>=20
> 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

--=20
<https://www.alejandro-colomar.es>

--sxzbalvdwtiuwivq
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEES7Jt9u9GbmlWADAi64mZXMKQwqkFAmpwh7cACgkQ64mZXMKQ
wqlaLg/+Le5oUdebsuYB1KcLoqlFRmmBLaHHA/g1iaoW1MjtkSuVUGvpr+kVb3Rt
lPruB0yaGBY6M63JD7LVdRCisULYWKS+STnULk1QltOGbz43VmufA4RaqxGB8Alp
LpzJuXiC7clqVFijo2QHi+sMiezgyYWySmODnfseS9jyJYZP/bm6myCLqunGcbzE
6xYIL1E6JXP2AsWuNpVAlg4DPO6HK4E23ivt9IS4HcsSWQn5z0GsHacoSCty5EUd
XzyQ2mMSKdFVNrxVAADOfm1KJyP2MfZAKD6c6NIvGiFStHDHG+Jt1fyUAKvmO8CZ
7bHd1rr47QIyTDiGarNV8iZqvNnOiKvKh2OnDjaFJfdXuBu4dWy1xfxQ5n4Igy9A
m+yz7pCqmmTW5SxPpknfvSUPtYoFCqMyjhjoT63439gEVUdZI7uDb+qaNE29miip
4Lult7B2+Y3UWld7zcAYWCEao9KC2DjEaXna56BMRQdPSUIY9FXHvRbG1shVqN3I
2cU2RLtcn/nZQNO6WVdWlLVvFiv0alHPkbA7gVteP4gShu+DFQfLoqwwN+tvE1A/
anmWxUWwI26teMtSIczTzmSCpfc/1bJpW7yZYwFAnVrTuSyQl5i0NlfmlGNgJ72S
9g5FOHTpmpRa9D8J5vF4PKubOxOOz9d/R93ycMVbchWMqY37P8k=
=HGhF
-----END PGP SIGNATURE-----

--sxzbalvdwtiuwivq--