public inbox for linux-man@vger.kernel.org
 help / color / mirror / Atom feed
From: Alex Colomar <alx.manpages@gmail.com>
To: Rob Landley <rob@landley.net>,
	coreutils@gnu.org,
	Debian Install System Team <debian-boot@lists.debian.org>
Cc: Brian Inglis <Brian.Inglis@shaw.ca>,
	Linux Man Pages <linux-man@vger.kernel.org>,
	1031275@bugs.debian.org, Stefan Puiu <stefan.puiu@gmail.com>
Subject: Re: [PATCH v3 1/6] man2/: use IEC or ISO multiples to clarify long numeric digit strings
Date: Fri, 24 Feb 2023 02:05:19 +0100	[thread overview]
Message-ID: <3fee22ab-42dc-120d-ee17-ecd43c3a254f@gmail.com> (raw)
In-Reply-To: <bd6e1c74-c597-b516-19b0-4aa9598fd2b4@landley.net>


[-- Attachment #1.1: Type: text/plain, Size: 9160 bytes --]

Hi Rob,

On 2/22/23 23:18, Rob Landley wrote:
> 16LL on 32 bit systems, but from an "explain what the number is" perspective it
> neatly avoids needing to specify a base or units. :)

Right.

>> What's "fetch"?
> 
> A pop culture reference: https://www.youtube.com/watch?v=Pubd-spHN-0

:p

>>> (Part of the reason is kibybyte/mebibyte/gibibyte are
>>> minor tongue twisters, they're physically harder to say, so nobody does.)
>>
>> I rarely talk about this stuff; more often, I write about it.  When I
>> write, the shorthand MiB is nice (I never write mebibyte).
> 
> I always read that TLA as "Men in Black", but I know what you mean.
$ wtf is TLA
TLA: three letter acronym
true love always

:)

> 
> I say "binary megabytes"

That's valid, I think.  And if it's not, everyone would understand.

 > the same way I say "degrees celsius".


>> The GNU coding standards for writing C programs are horrible.  But they
>> have very nice things in their standards.  Their standardization of
>> Makefile targets and variables is quite nice, and I try to follow it
>> closely.
> 
> Hence cmake and ninja and so on.

Uhh, no, thanks!

> 
>>> (Still there in Documentation/process/coding-style.rst.)
>>>
>>> GNU has nothing to do with Linux, and never did. Stallman has a history of
>>> taking credit for other people's work:
>>
>> I never said so. GNU is a set of userspace programs, Linux is a kernel,
>> and GNU/Linux is the entire OS (or more precisely a relatively important
>> part of it).
> 
> A busybox system isn't gnu, which means alpine linux isn't. Android using toybox
> with a "no GPL in userspace policy" and built with llvm to avoid even the FSF's
> compiler isn't gnu. So Linux on phones, and one of the standard docker distros,
> actively _avoid_ using gnu. (These days, "systemd/linux" is probably at least as
> accurate as "gnu/linux".

Yeah, any of them is fine IMO.  I write from a GNU/Linux distro, but I 
admit that I should have maybe said "most programs in Unix-like systems 
these days use IEC prefixes".

> I type that from devuan...)

Me too :)

>> I CCed GNU coreutils so that they feel alluded and maybe improve their
>> utils :)
> 
> I'm still on that mailing list until they merge cut -DF.

What would that do?


> You've taken over from Michael Kerrisk then? I should inform
> https://www.openwall.com/lists/musl/2022/11/30/2#:~:text=biggest%20problem and
> friends...

I guess many should already know.  But yes, feel free to inform.

>> Since 2020, I comaintained the project with Michael, and now I'm the
>> only maintainer of the project.  To be more precise, let's quote the README:
>>
>> Maintainers
>>          Alejandro Colomar <alx@kernel.org>
>> <http://www.alejandro-colomar.es/>
>>                2020 - present (5.09 - HEAD)
>>          Michael Kerrisk <mtk.manpages@gmail.com> <https://man7.org/>
>>                2004 - 2021 (2.00 - 5.13)
>>          Andries Brouwer <aeb@cwi.nl> <https://www.win.tue.nl/~aeb>
>>                1995 - 2004    (1.6  - 1.70)
>>          Rik Faith <https://www.cs.unc.edu/~faith/>
>>                1993 - 1995    (1.0  - 1.5)
> 
> Good to know. (I just randomly stopped getting the emailed updates...)
> 
> Ah, there you are on https://www.kernel.org/doc/man-pages/maintaining.html

Yep :)


>> Or you can say Kelvin ;)
> 
> And when the weather reports start giving temperatures in kelvin... they would
> still say "degrees", wouldn't they? It's 267 degrees in Minneapolis today...

To be pedantic, and quoting the SI brochure v9: "* The unit name “degree
kelvin” was changed to “kelvin” in 1967 by the 13th CGPM (Resolution 3,
see p. 169)."

So you should say kelvins, not degrees kelvin.

<https://www.bipm.org/documents/20126/41483022/SI-Brochure-9-EN.pdf/2d2b50bf-f2b4-9661-f402-5f9d66e4b507?version=1.11&t=1671101192839&download=true#%5B%7B%22num%22%3A372%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22Fit%22%7D%5D>
Page 163 (49 in the PDF).

> 
> Gigabytes can be in base 10 or base 2. They're still gigabytes.
> 
>> In colloquial texts, or more appropriately in colloquial talking,
>> degrees (without specifying), tons (same), or "megs", are fine, but for
>> a manual, where we want precision (especially since we do mix decimal
>> and binary multipliers often), I would strongly avoid misusing terms.
> 
> *shrug* If you're maintainer, it's your call. I've said my piece.
> 
>>> "They'll google it" is the modern version of "they'll read the documentation".
>>> They will not, you're just delegating blame.
>>
>> I can't imagine someone reading MiB in a manual page and not searching
>> what that means (unless the reader doesn't care about that specific value).
> 
> It's _possible_ the man page maintainer is not, in isolation, a fully rounded
> representative sample on this issue?

It's possible, but I have my doubts in this case.

By chance, I was having a look at a computer that had RedHat Openshift 
open, and the system resources usage view used IEC multipliers (men in 
black units).

`free -h` also uses them.  The top(1) manual page also uses "kibibytes" 
and other such expanded words.

> 
>>> Rob
>>>
>>> P.S. Maybe this is a generational thing? Are the kids saying "kibibyte" in high
>>> school these days?
>>
>> I don't think so.  Teachers usually don't know these prefixes either, I
>> guess.
> 
> Do you expect to change global language usage patterns or just make the man
> pages less relevant to their intended audience?

Honestly, I expect the former.  Not single-handedly, but rather I feel 
supported by a lot of (very common) software out there.  I understand 
it's not everywhere, but also it's not as if it didn't exist prior to me.

As for the Linux man-pages, at least a few already use these (prior to 
me, I believe, since I don't remember changing that):

$ grep -rl -e KiB -e MiB -e GiB man*/
man2/ioctl_getfsmap.2
man2/process_vm_readv.2
man2/add_key.2
man2/execve.2
man2/getrlimit.2
man2/ioctl_fideduperange.2
man2/kexec_load.2
man2/alloc_hugepages.2
man3/btree.3
man4/fd.4
man4/loop.4
man5/proc.5
man7/pipe.7
man7/keyrings.7
man7/units.7

$ grep -rn kibi
man5/tmpfs.5:60:suffix for Ki, Mi, Gi (binary kilo (kibi), binary mega 
(mebi), and binary giga
man2/msgctl.2:216:    int msgpool; /* Size in kibibytes of buffer pool
man7/units.7:58:Ki	kibi	2^10 = 1024
man7/units.7:104:the MB are megabytes and the KiB are kibibytes.

>> They'll have to remove the second space from my cold dead fingers.
> 
> That's exactly how the change will happen, yes. This was published 9 years ago:
> 
> https://www.cultofpedagogy.com/two-spaces-after-period/

It's funny, I'm still in my twenties.  :p

> 
>> All
>> those style guides are plain wrong.  I've read their rationales, and
>> they make no sense at all.  Using one space is discarding information,
>> and that is bad.
> 
> Blame Tim Berners-Lee. The cultural shift started when HTML rendered all runs of
> whitespace as a single space back in 1991. People write what they read.

Actually, it comes from much earlier than that.  Have a look at
<https://web.archive.org/web/20171107164742/http://www.heracliteanriver.com/?p=324>

The real reason seems to be that single spaces lowered the quality of 
required editors, and thus prices.  It's all about the money.

>> 	I guess the "problems" are the consistency thing referred in the second
>> sentence...  Well, it's not inconsistency, it's just that different
>> things are different.  I don't like oranges and tomatoes because they're
>> inconsistent; one fruit is red and the other is orange...  Nonsense.
> 
> I got an english minor in college, and one of the things it drilled into me is
> if it's correct and nobody does it, it's not correct.

I do agree with that.  The thing here is that I disagree about it not 
being used.  If you look at many commonly-used programs, you'll see it 
all over the place: top(1), free(1), fdisk(1), ...

> 
> English! It's a mess. We jettisoned the second person singular because british
> nobility started copying the queen (who spoke for the nation, thus always in the
> "we are not amused" plural) and it moved downhill until eventually addressing
> someone else as thou was fighting words because it meant you considered the
> person you were addressing your social inferior (yes the Amish got physically
> attacked for this, it's part of the reason they moved). This is also one of
> those subtleties in shakespeare, the way he uses "thou" as an insult, because
> the transition was ongoing in his time:

Ahhh, thou is 2nd singular!  That explains many things :).  I learnt 
something new today.

> 
> https://drmarkwomack.com/engl-3306/handouts/shakespeares-language/thou-and-you-in-shakespeare/

> 
> But do I expect kibibytes to take off? Not really, no. Could be wrong, but...

I hope you're wrong in this one.  ;)

> 
> Rob

Cheers,

Alex

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2023-02-24  1:05 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-15 20:15 [PATCH v3 0/6] man2/: use C digit separators, IEC, or ISO multiples to clarify long numeric digit strings Brian Inglis
2023-02-15 20:17 ` Brian Inglis
2023-02-15 20:17 ` [PATCH v3 1/6] man2/: use IEC " Brian Inglis
2023-02-15 21:05   ` Alejandro Colomar
2023-02-16 21:06   ` Stefan Puiu
2023-02-16 23:01     ` Alejandro Colomar
2023-02-16 23:40       ` Brian Inglis
2023-02-16 23:51         ` Alejandro Colomar
2023-02-17 14:05       ` Stefan Puiu
2023-02-19 21:10         ` Alejandro Colomar
2023-02-19 21:12           ` Alejandro Colomar
2023-02-20 14:29           ` Stefan Puiu
2023-02-20 15:35             ` Alex Colomar
2023-02-21 17:00               ` Rob Landley
2023-02-22  1:34                 ` Alex Colomar
2023-02-22 22:18                   ` Rob Landley
2023-02-24  1:05                     ` Alex Colomar [this message]
2023-02-16 21:40   ` Jakub Wilk
2023-02-15 20:17 ` [PATCH v3 2/6] man2/keyctl.2: use IEC or ISO multiples or add C digit separators " Brian Inglis
2023-02-15 21:06   ` Alejandro Colomar
2023-02-15 20:17 ` [PATCH v3 3/6] man2/: add C digit separators to clarify POSIX feature release dates Brian Inglis
2023-02-15 21:08   ` Alejandro Colomar
2023-02-16 21:11   ` Stefan Puiu
2023-02-16 23:04     ` Alejandro Colomar
2023-02-17 14:16       ` Stefan Puiu
2023-02-15 20:17 ` [PATCH v3 4/6] man2/select.2: add C digit separators to clarify POSIX feature release dates or use IEC or ISO multiples to clarify long numeric digit strings Brian Inglis
2023-02-15 21:09   ` Alejandro Colomar
2023-02-15 20:17 ` [PATCH v3 5/6] man2/chmod.2: add C digit separators to clarify POSIX feature release dates and " Brian Inglis
2023-02-15 21:10   ` Alejandro Colomar
2023-02-18 17:42     ` Tom Schwindl
2023-02-18 18:08       ` G. Branden Robinson
2023-02-18 18:31         ` Tom Schwindl
2023-02-18 19:03           ` G. Branden Robinson
2023-02-18 23:32             ` Brian Inglis
2023-02-19 11:50             ` ADA and base prefix for numbers Alejandro Colomar
2023-02-18 18:41       ` [PATCH v3 5/6] man2/chmod.2: add C digit separators to clarify POSIX feature release dates and long numeric digit strings Brian Inglis
2023-02-15 20:17 ` [PATCH v3 6/6] man2/: add C digit separators to clarify " Brian Inglis
2023-02-15 21:14   ` Alejandro Colomar
2023-02-15 22:51 ` [PATCH v3 0/6] man2/: use C digit separators, IEC, or ISO multiples " Brian Inglis

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=3fee22ab-42dc-120d-ee17-ecd43c3a254f@gmail.com \
    --to=alx.manpages@gmail.com \
    --cc=1031275@bugs.debian.org \
    --cc=Brian.Inglis@shaw.ca \
    --cc=coreutils@gnu.org \
    --cc=debian-boot@lists.debian.org \
    --cc=linux-man@vger.kernel.org \
    --cc=rob@landley.net \
    --cc=stefan.puiu@gmail.com \
    /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