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/109897415359142549respect 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:
MaintainersAlejandro Colomar <alx@xxxxxxxxxx> <http://www.alejandro-colomar.es/>
2020 - present (5.09 - HEAD)
Michael Kerrisk <mtk.manpages@xxxxxxxxx> <https://man7.org/>
2004 - 2021 (2.00 - 5.13)
Andries Brouwer <aeb@xxxxxx> <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
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
