Re: [PATCH v3 1/6] man2/: use IEC or ISO multiples to clarify long numeric digit strings

[Alex Colomar]

Hi Rob,

On 2/21/23 18:00, Rob Landley wrote:
> If you're going to tell people to learn something new: 1<<10 is a kilobyte,
> 1<<20 is a megabyte, 1<<30 is a gigabyte, and so on. I've sometimes used
> 16*(1<<30) for clarity.

That's nice, and for code it might be a good idea (although you have to 
be careful, since those are all ints, and 16*(1<<30) is going to 
overflow, so you'll need 16L).  For documentation, I don't think I like 
it that much.

> > > Also, for the record, I had no idea what KiB / MiB means and how it's
> > > different from KB/MB until this discussion.
>
> Very few people do. Some people have been trying to make "fetch" happen for many
> years, but it didn't.

What's "fetch"?

> (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).  For talking, 
I say "megs" (or rather the Spanish equivalent "megas"), so being 
colloquial I can't be blamed, since I didn't really say megabytes.  If I 
say the technical term, which is rare, I try to be precise, and say 
mebibytes instead of megabytes.

> > > I googled it before
> > > writing this reply, and found this among the first hits:
> > > https://ux.stackexchange.com/a/13850.
> >
> > That answer was written more than a decade ago.  These days, binary
> > prefixes are more common.  In fact, I'd say most GNU/Linux commands
>
> "First off, I'd suggest printing out a copy of the GNU coding standards,
> and NOT read it.  Burn them, it's a great symbolic gesture." - Linus Torvalds

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.

> (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).  Most Linux distros are GNU/Linux distros, since user space 
is mostly GNU.  Since I was talking about user-space programs, GNU is 
even more appropriate than Linux, although I'm not sure about how much 
GNU conforms to these IEC prefixes, which is why I used GNU/Linux as 
more generic, referring to the entire set of programs that are included 
in such distros (e.g. Debian).

I CCed GNU coreutils so that they feel alluded and maybe improve their 
utils :)

> https://functional.cafe/@tfb/109897415359142549
>
> > respect them (an important exception being GNU coreutils (for example
> > ls(1)).  But many programs use prefixes accurately, such as fdisk(8).
> >
> > In the Linux man-pages we have units(7), which documents these.  Maybe
> > that page should be more known.
>
> FYI Michael Kerrisk last updated https://github.com/mkerrisk in 2021.

That repo is just a mirror of the official repo at
<https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/>,
which I maintain.

> It is now
> 2023. He still posts monthly proof-of-life to
> https://twitter.com/mkerrisk/with_replies but hasn't replied to man-pages email
> in the past year that I am aware of?
>
> Dunno why.

He's busy with his own business, and doesn't have time to continue 
maintaining the project.  It's a voluntary thing, so it's reasonable to 
be able to step out at any time.

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)


> I emailed to ask, but...
>
> > BTW, that answer is inaccurate (at least today): drive manufacturers
> > have the distinction pretty clear, and use it precisely (with lawsuits
> > won thanks to this); they use metric prefixes, because they mean it.
> > They can sell you 1 TB instead of 1 TiB, and most people won't even
> > know, but those who know, will know that 1 TB is 1'000'000'000'000 B,
> > which is what you get.
>
> Remember when the dictionaries gave in on "literally" meaning "an emphatic form
> of figuratively"? What's the "kibybyte" equivalent we all switched to there for
> clarity?
>
> We say "metric ton" and "imperial ton". We say "degrees farenheit" and "degrees
> celsius". The celsius people didn't come up with a different word for degree,
> yet somehow we all survived...

Or you can say Kelvin ;)
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.

> > They have no incentives to sell 1 TiB drives,
> > because they are visually almost the same, but there's around 9.95% more
> > bytes, so it's more expensive to produce.  It's not worth it for them.
>
> "No, a _bud_ lite..."
>
> > > I would say making the docs easy to understand for users is more
> > > important than adhering to some specs users might not be familiar
> > > with.
> >
> > Well, using MiB prompts readers to use their search engine to learn what
> > that is (that's how I learnt it the first time; and that's what one does
> > when reading a book and finding a new word).
>
> "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).

> 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.

> I know that "hacker means computer breakin specialist" is
> something a small number of boomers will resist to the death despite a google
> news search only pulling up one meaning in general usage. And the "two spaces
> after period" thing old hands cling to will only end when they die despite the
> chicago manual of style, the AP stylebook, the MLA handbook, and the APA
> publication manual all agreeing its' been one space after a period for decades
> now.

They'll have to remove the second space from my cold dead fingers.  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.  Let's list their reasons (AFAICS):

-  "It [2 spaces] doesn't look good."
        Subjective, and I disagree.

-  "We don't use monospace anymore, so it's not necessary to recognize 
the end of a sentence."
        It may be less necessary, but that doesn't make it bad.
	BTW, does that implicitly recognize that monospace should _always_ use 
2 spaces?  Thanks.
	Still with proportional font you can confuse sentence endings with 
initials in some cases (depending on the context), so 2 spaces is still 
necessary.

-  "2 spaces only increase reading speed for those used to them, and 
only marginally (according to studies)."
        Having a very small benefit is better than not having it.
        The fact that one-spacers are slower readers should raise questions.

-  "introducing two spaces after a sentence-ending period—and only after 
those periods—causes problems. Absolute consistency is easy to monitor 
when double spaces are never allowed, but less easy when some spaces 
after periods are double and others single"
	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.

-  "Old English used 3-em space after period, but old Spanish or French 
didn't, in fact they often used 0 spaces after punctuation".
        So what?  Were they more readable thanks to that?  No.
        I've had to read old Spanish, and it's pretty painful.
        In fact, 3-em after period old English is quite readable.

-  "2-spacers are just imitating previous writers; they don't know what 
they're doing".
	Imitating wise old customs without knowing the rationale is not bad per 
se.  Deviating from them without a rationale is even worse.

...

Cheers,

Alex

> But maybe "kibibyte" is more than a shibboleth to somebody somewhere...

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

OpenPGP_signature
Description: OpenPGP digital signature