Configure.help editorial policy

I guess it's a pretty quiet week in kernel-hacker land. Must be, otherwise people would have better things to do than argue over KB vs. KiB. The alternative would be to conclude that significant portions of the lkml population prefer flaming to coding, and that couldn't possibly be the case, could it?

Let me make a couple of things clear:

I am by no means in love with the new abbreviations described at
<http://physics.nist.gov/cuu/Units/binary.html>. I have the same reflexes as the rest of you -- they kind of make me want to gag.

If there is a clear consensus from lkml, I will be happy to back out this change. Perhaps this terminological standard does not meet a real need, perhaps it will be rejected by most engineers and deserves to wither on the vine. It's happened before.

However. In the *absence* of a clear consensus, I will follow best practices. Best practice in editing a technical or standards document is to (a) avoid ambiguous usages, seek clarity and precision; and (b) to use, follow and reference international standards.

In fact, the first time David Woodhouse submitted this change, some months ago, I rejected it. I have since, reluctantly, concluded that I was wrong to do so. So when he re-submitted, I merged in the patch.

My personal esthetic distaste for the new terminology (gack! "kibi" sounds like something I would feed my cat!) is less important than following best practices. I'm hoping it will seem less ugly as it becomes more familiar.

I don't like my duty much in this instance. But my duty is clear.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"As to the species of exercise, I advise the gun. While this gives [only]
moderate exercise to the body, it gives boldness, enterprise, and independence
to the mind.  Games played with the ball and others of that nature, are too
violent for the body and stamp no character on the mind. Let your gun,
therefore, be the constant companion to your walks."
        -- Thomas Jefferson, writing to his teenaged nephew.

I second that emotion.

I'd vote for that.

Perhaps if we could be so bold as to back Donald Knuth's KKB,MMB,GGB proposal (of which I learned here:
http://www.linuxdoc.org/HOWTO/Large-Disk-HOWTO-3.html ). I understand that muddying the waters is not the way to see clearly into the depths of computer science for the unwashed masses, but the ambiguity that currently exists is very real. I try to explain these issues on what seems like a daily basis to many and the duplicitous terms are not helpful.

It certainly rated high on my kibbles'n'bits meter as well :-)

Whatever we do with the abbreviations, I would strongly recommend we spell out documention to help educate ( and ease the transition if we switch terms) wherever possible. For example:

4 binary kilobyte pages
1024 decimal kilobyte disk
8.4 decimal gigabyte disks
4 binary gigabytes of memory
10 decimal gigabits of bandwith

or if that offends the sensibilities:

4 kilobytes (binary)
1024 kilobytes (decimal)
8.4 gigabytes (decimal)

I know that they are long on keystrokes, but in lieu of an accepted and aesthetically pleasing standard, they are clear and unambiguous.

Regards,
Reid
--
Protect your rights, Geeks with Guns!

Reid Hekman <[email protected]>:

Hm. Attractive, but it doesn't have an ISO standard behind it.

Good idea. I will make appropriate changes.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Government should be weak, amateurish and ridiculous. At present, it
fulfills only a third of the role.	-- Edward Abbey

KKB looks a million times better than KiB. maybe it's the lowercase letter, i don't know.

i will agree that the ambiguity sucks and something needs to be done about it, but i really do find the SI units for binary plain ugly. i doubt that anyone would be willing to type as much text for referencing simple sizes as you explained above.

perhaps simply a base suffix:

	4KB(2) == 4 * 2^10
	4MB(2) == 4 * 2^20
	4KB(10) == 4 * 10^3
	4MB(10) == 4 * 10^4

it's definitely wierd to look at, but it seems to get the point across easier. it defines the base, instead of referencing a name (kibi? please, i don't think enough people will start using these grossly-sounding prefixes enough to make it the de facto standard). or perhaps a (d) or (b) qualifier to refer to decimal or binary.

perhaps everybody should just suck it up and go with what's standard?

-mike

--------------------------------------------------------------------------

   /~\  The ASCII                       all that is gold does not glitter
   \ /  Ribbon Campaign                 not all those who wander are lost
    X   Against HTML                          -- jrr tolkien
   / \  Email!

radiusd+mysql: http://www.cafes.net/~diz/kiss-radiusd
--------------------------------------------------------------------------

The kb versus KB versus KiB versus whatever may come next was always a very flammable cause.

Now my opinion on this would be: By sticking KiB everywhere nothing is helped. To the knowledgeable, it's nothing new that memory is measured in binary units, while ethernet speed in decimal ones. To the newbie, KiB is about as cryptical as KB and he'll never know which is which, because as a newbie (s)he didn't read the standards.

And of course, every search-and-replace cleanup will always upset many people regardless which direction it goes.

On the other hand, making documentation less ambiguous is always a good thing. I'd suggest a more careful approach, adding descriptive wording in places where bits and bytes may be confused, and where binary or decimal prefixes may be.

And speaking of the 1 Mbps connection - I fear that in many cases that'll be 1024000 bytes per second. What M is that? Binary or decimal? Who does care?

Vojtech Pavlik
SuSE Labs

[email protected] (Vojtech Pavlik) wrote on 20.12.01 in <[email protected]>:

Well, considering that I had to look at half a dozen web pages via Google to make sure that ethernet did, indeed, use decimal, despite having been in the industry for about a decade, I'd say that this *would* help.

And the newbie would at least recognize that there is something going on, learning about which just might be a good idea. And the answer would presumably come not out of a standard, but out of a FAQ.

A lied-about one. These abominations deserve to die, yesterday. Preferrably messily.

If you're selling it to me, I certainly do.

MfG Kai

Another option: maybe the choice of KB vs KiB vs KKB should be a configuration choice.

--David Garfield

David Garfield <[email protected]>:

You *must* be joking.

Please tell me you're joking.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

According to the National Crime Survey administered by the Bureau of
the Census and the National Institute of Justice, it was found that
only 12 percent of those who use a gun to resist assault are injured,
as are 17 percent of those who use a gun to resist robbery. These
percentages are 27 and 25 percent, respectively, if they passively
comply with the felon's demands. Three times as many were injured if
they used other means of resistance.
        -- G. Kleck, "Policy Lessons from Recent Gun Control Research,"
		Law and Contemporary Problems 49, no. 1. (Winter 1986.): 35-62.

No, I'm serious. I will understand if CML2 does not support meta-configuration. A configuration choice as I described above could be viewed as a minor facet of a language configuration choice. (Should kernel configuration be internationalized or at least internationalizable?)

Choice of kB vs KB vs KiB vs KKB could also be used in some places in the kernel. For instance, /proc/meminfo currently shows "kB".

--David

Hopefully. Here's a serious one tho. Why don't we say at the bottom:
1 kB (or KB or KiB or ...) is 2^10 bytes. Like we do for code that can be compiled as a module... As long as we're consistant in the suffix, and we define it, it doesn't matter what it is.

Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Surely not?

"Best" practice? That's the *only* practice! Guesswork and assumption has no place in technical documentation!

Mike

Um, you know, all due repect to Knuth, the God, I think that
someof his ideas are downright silly. Now, my suggestion
is different, namely, inserting a 2 in the unit such as "K2B"
meaning Kilo (base2) Byte. It's not like we don't have a
precendent from the chemistry and physics fields.

[email protected].

"decimal" is implied when using SI prefixes.

Matthias Andree

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."         Benjamin Franklin

David Garfield <[email protected]>:

What, and *encourage* non-uniform terminology? No, I won't do that. Better to have a single standard set of abbreviations, no matter how ugly, than this.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The American Republic will endure, until politicians realize they can
bribe the people with their own money.
	-- Alexis de Tocqueville

Valid argument. I will point out that the current version is non-uniform. Quoting from Configure.help :

Note "3GiB/1GiB" and "4GB".

--David

That's because the config option is named like that, and wasn't corrected when the help text was. Maybe the following would be better:

If the machine has between 1 and 4 Gigabytes physical RAM, then answer "4GB"(sic) here.

--
dwmw2

Last I checked the purpose of language was _communication_.

Better use words people understand.

Also, the kB vs KiB mess is so ambiguous and complex that it virtually guarantees that the _writers_ of documentation will get it wrong occasionally and only confuse the readers more.

As a last point, we shouldn't forget about the inconsistent way in which the marketing departments of hardware vendors apply these units to their products. In many cases binary and decimal units are mixed, leading to something which is impossible to "get right". Disk space would be one example of this, but I'm sure there are more.

regards,

Rik

DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/

http://www.surriel.com/		http://distro.conectiva.com/

[email protected] (Rik van Riel) wrote on 21.12.01 in <Pine.LNX.4.33L.0112211913360.28489-100000@duckman.distro.conectiva>:

People in general *don't* understand the current so-called "established practice", because not only is it inconsistent with all of the rest of the world, it's also inconsistent with itself.

A few specialists such as you or me understand those terms in those few areas we are familiar with.

What is ambiguous or complex about it?

Do you know of *any* case where KiB and friends have been applied inconsistently? You may not be arguing the side you seem to want to be arguing here ...

I have no idea why you think it is impossible to get right. It is fairly easy to get right. Of course, that means using different numbers, but then I've been saying for more than a decade that those numbers are a lie.

MfG Kai

Stephen Satchell <[email protected]>:

That's right, kids. And furthermore, we had to walk to the computer center uphill. Both ways. In the snow. Empty out the chad buckets twice a day. And crimp backplane wires with our teeth, while the machine was *on*!

Alas, this is not a solution -- because expanding all the abbrevs would just get us into the argument over "kilobytes" vs. "kibibytes". And, while I can just barely make myself choke down "KiB" for the sake of clarity, "kibibytes" is beyond my tolerance. Aaarrggghhh....

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

All governments are more or less combinations against the
people. . .and as rulers have no more virtue than the ruled. . .
the power of government can only be kept within its constituted
bounds by the display of a power equal to itself, the collected
sentiment of the people.
	-- Benjamin Franklin Bache, in a Phildelphia Aurora editorial 1794

While pure reason suddenly made me realize that we really shouldn't use abbreviations in docs, thus rendering MiB vs MB moot, this still leaves us with another problem:

Gigs or Gibs? Kibbles or Kilos? You're still going to end up with confusion, because outside of the (limited number of) people who heard about this "international" standard, nobody knows what the heck a kibibyte is.

After reading this longish thread, or waste of bandwidth as you may look
at it, I wonder if people have realized how familiar this entire argument is. Seams like we have another bunch of elitist snobs trying to tell the common folk what is or isn't standard. Wasn't that long ago that teachers were punishing students for using the word "ain't" because it wasn't standard Engish despite it being used by virtually everyone else out in the real world. Now last I heard a few years back, from an Engish teacher at that, was that "ain't" was now fully allowed. Guess it became standard. Perhaps some people should come off of their high horse and hang around with the common people for a bit. For virtually everybody, including my grandma, KB == kilobytes, MB == megabytes, and GB == Gigabytes. Memory-wise, at least, kilos == 1024, Megas == 1024 * 1024. And as far as network speeds I've always seen Kbits, Mbits, or Gbits (with lowercase or uppercase 'B'). For all practical purposes its always been like that. And while computers haven't been around for ages yet its been around long enougth that the new standards complient kernel source will be out of sync with the countless amounts of documentation (of all kinds) out there as well as the standard operating procedure in the real world.

Now aren't there better things to do in the world rather that going
around confusing and chastizing people with more talk of "Kibbles and Bits" and "Men In Black". Not that pointless flamewars aren't always fun.

I already gotta put up with Python just to configure my kernel, now
this, and I read he's going after my symbols next.

Sorry if this seams a bit terse (I did tone it down a lot), however I
was hoping to get some help debugging my lockup problem on the VP6 instead of corrections from language nannies informing me that the common folk and I have been speaking and writing incorrectly all this time. Yes baby, there is such a thing as a kiwibit.

On Fri, Dec 21, 2001 at 07:17:45PM -0200, Rik van Riel <[email protected]> wrote:

| On Fri, 21 Dec 2001, Eric S. Raymond wrote:
| > What, and *encourage* non-uniform terminology?  No, I won't do that.
| > Better to have a single standard set of abbreviations, no matter how
| > ugly, than this.
| 
| Last I checked the purpose of language was _communication_.
| Better use words people understand.

Well, what we have is KB, which people _think_ they understand, but do not. And KiB, which is ugly but well defined, albeit less known (at present).

| Also, the kB vs KiB mess is so ambiguous and complex that
| it virtually guarantees that the _writers_ of documentation
| will get it wrong occasionally and only confuse the readers
| more.

KiB is not ambiguous. KB demonstrably is.
And therefore KB is NOT useful for communication, _especially_ technical communication.

| As a last point, we shouldn't forget about the inconsistent
| way in which the marketing departments of hardware vendors
| apply these units to their products. In many cases binary
| and decimal units are mixed, leading to something which is
| impossible to "get right".  Disk space would be one example
| of this, but I'm sure there are more.

You're just making the case for KB weaker you know...

For all that KiB is ugly, at least it is not ambiguous. I'll take "precise" over "vague" in technical documentation any time.

Using KB in places where precision matters puts us all into case #4 below, because people think they know what KB means, but it means different things to different people, and so people don't realise they are using a vague term. Which is very bad.
--
Cameron Simpson, DoD#743 [email protected] http://www.zip.com.au/~cs/

Men are four:
He who knows and knows that he knows; he is wise, follow him. He who knows and knows not that he knows; he is asleep, wake him. He who knows not and knows that he knows not; he is ignorant, teach him. He who knows not and knows not that he knows not; he is a fool, spurn him!

I take it this is your way of volunteering to always keep all kernel documentation accurate as well as answer questions from newbies who've never seen 'KiB' before ? ;)

Rik

Shortwave goes a long way:  irc.starchat.net  #swl

http://www.surriel.com/		http://distro.conectiva.com/

Rik van Riel <[email protected]>:

One of the arguments for the KiB declaration, despite the ugliness of "kibibytes", is that a newbie seeing "32KiB" is quite likely to deduce what's meant from context. Let's not exaggerate the difficulties here.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Where rights secured by the Constitution are involved, there can be no
rule making or legislation which would abrogate them.
        -- Miranda vs. Arizona, 384 US 436 p. 491

Hi Eric, Rik.

Alternatively, deal with this problem the same way the "This may also be built as a module..." comment is - either include it several thousand times in Configure.help or (better still) have the configuration tools spit it out automatically every time the need for it crops up. The following ruleset could easily be implemented even in the make config and make menuconfig parsers, and should be just as easy in CML2. Applying rule (1) will result in a considerable reduction in the size of the file Documentation/Configure.help as it currently stands.

Comments, anybody?

Best wishes from Riley.

===============8<=============== CUT ===============>8===============

RULE 1: If a particular symbol is defined using a command that
allows it to be selected as "Modular", then tack the following to the end of the help description for that symbol when a user requests help:

This driver is also available as a module( = code which can be inserted in and removed from the running kernel whenever you want). If you want to compile it as a module, say M here and read Documentation/modules.txt in the kernel source.

RULE 2: If the help text for a particular symbol includes a word
matching either of the egrep patterns '[KkMmGgTt][Bb]' or '[KkMmGgTt]i[Bb]' then tack the following to the end of the help description for that symbol when a user requests help:

Differing standards are used for the numeric designators in the computing and engineering worlds. For the purposes of this document, the following designators are used with the stated values:

Symbol Designation Number of Bytes
~~~~~~ ~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~
KiB Decimal Kilobyte 1,000
KB Binary Kilobyte 1,024

MiB Decimal Megabyte 1,000,000
MB Binary Megabyte 1,048,576

GiB Decimal Gigabyte 1,000,000,000
GB Binary Gigabyte 1,073,741,824

TiB Decimal Terabyte 1,000,000,000,000
TB Binary Terabyte 1,099,511,627,776

This difference has arisen as a direct consequence of the fact that computers naturally talk in a binary (base 2) number system rather than the decimal (base
10) system preferred by mere mortals.

RULE 3: If more than one of the above rules apply, all configuration
systems shall agree on a common order in which to apply them.

[email protected] (Riley Williams) wrote on 26.12.01 in <[email protected]>:

Uh, that's all wrong. The "i" versions are *binary*, the non-"i" versions are *decimal*. Completely backward.

MfG Kai

Hi Kai.

No problem. Just swap the relevant labels over in the first column.

As far as the tweak I proposed (and which I've finished creating for make config and have nearly finished for make menuconfig as well), the whole entry, along with that for any other "Technical Acronyms" (TM) that one wishes to define in the same way, are simple entries at the top of Configure.help and can easily be edited by anybody willing to apply fingers to keycaps.

The only question I'm really interested in hearing answers to is this:

What other acronyms used in Configure.help could use defining in this manner for kernel newbies?

Any takers willing to supply both the acronym and a definition thereof?

Best wishes from Riley.

On Wed, Dec 26, 2001 at 05:44:36PM +0000, Riley Williams <[email protected]> wrote:

| >> I take it this is your way of volunteering to always keep all
| >> kernel documentation accurate as well as answer questions from
| >> newbies who've never seen 'KiB' before ? ;)
| 
| > One of the arguments for the KiB declaration, despite the ugliness
| > of "kibibytes", is that a newbie seeing "32KiB" is quite likely to
| > deduce what's meant from context.  Let's not exaggerate the
| > difficulties here.
| 
| Alternatively, deal with this problem the same way the "This may also be
| built as a module..." comment is - either include it several thousand
| times in Configure.help or (better still) have the configuration tools
| spit it out automatically every time the need for it crops up. The
| following ruleset could easily be implemented even in the `make config`
| and `make menuconfig` parsers, and should be just as easy in CML2.
| Applying rule (1) will result in a considerable reduction in the size of
| the file Documentation/Configure.help as it currently stands.
| 
| Comments, anybody?

I like this!

Cameron Simpson, DoD#743        [email protected]    http://www.zip.com.au/~cs/

It was a joke, OK?  If we thought it would actually be used, we wouldn't have
written it!	- Marc Andreessen on the creation of a <blink> tag

I second this. Being a translator of the file in question, I have to deal with ten slightly different versions of "You may also compile this as a module...". So I have ten slighlty different translations of this text, too, in the name of accuracy.

Although I thought there was an agreement that decimal kilobyte is kB, and binary kilobyte is KiB, decimal megabyte is MB, binary megabyte is MB and so on, wasn't there?

"The Universe doesn't give you any points for doing things that are easy."
        -- Sheridan to Garibaldi in Babylon 5:"The Geometry of Shadows"
Dominik 'Rathann' Mierzejewski <rathann(at)we.are.one.pl>

Hi Dominik.

I have to admit that I hadn't considered translators, but perhaps it could be made even simpler for you. How about having the help file start with a set of standard definitions, such as the following...

===8<=== CUT ===>8===

DEFINE_MODULAR
This driver is also available as a module ( = code which can be inserted in and removed from the running kernel whenever you want). If you want to compile it as a module, say M here and read Documentation/modules.txt in the kernel source.

DEFINE_UNITS
Differing standards are used for the numeric designators in the computing and engineering worlds. For the purposes of this document, the following designators are used with the stated values:

Symbol Designation Number of Bytes
~~~~~~ ~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~
KiB Decimal Kilobyte 1,000
KB Binary Kilobyte 1,024

MiB Decimal Megabyte 1,000,000
MB Binary Megabyte 1,048,576

GiB Decimal Gigabyte 1,000,000,000
GB Binary Gigabyte 1,073,741,824

TiB Decimal Terabyte 1,000,000,000,000
TB Binary Terabyte 1,099,511,627,776

This difference has arisen as a direct consequence of the fact that computers naturally talk in a binary (base 2) number system rather than the decimal (base 10) system preferred by mere mortals.

===8<=== CUT ===>8===

The rules would then reduce to "If the relevant condition applies, append the text associated with the relevant DEFINE_ symbol to the help text to be issued" and this could be done with an additional call to the routine to extract the appropriate help text from the file. In addition, your translation efforts would be restricted to just the COnfigure.help file, and you wouldn't have to tweak the various configuration scripts at the same time - and this would also ensure that the various config scripts all used exactly the same help text.

That's the standard that the IEC has defined, and what this thread is all about. Whether it'll get anywhere remains to be seen - ask Ted T'so about the dangers of early adoption of proposed standards, and he'll probably explain where his surname came from...

Best wishes from Riley.

[snip]

[cut indeed :-)]

Nice, but - as Eric pointed out - there are many options where the "available as module" text actually contains a module name, which causes problems and makes your proposition insufficient for our needs. A complete solution would require serious changes which Eric doesn't want to introduce into a stable version.

Perhaps I will. But I still don't understand why you insist on choosing an opposite notation - that is xiB for decimal and xB for binary. If at all, I would change the traditional convention to something exactly opposite, i.e. xiB for binary and xB for decimal, because M(mega),G(giga), etc. are standard SI units.

PS. Don't Cc: me next time you reply, ok? I'm subscribed to lkml.

"The Universe doesn't give you any points for doing things that are easy."
        -- Sheridan to Garibaldi in Babylon 5:"The Geometry of Shadows"
Dominik 'Rathann' Mierzejewski <rathann(at)we.are.one.pl>

Hi Dominik.

8-)

Curiously enough, the changes I proposed are ones that I have already implemented for make config and have nearly implemented for make menuconfig at the moment, and I expect to have make xconfig ready early in the new year. The module name part of it is trivially easy to implement once the code to add the basic DEFINE_MODULAR text is there, and the only change will be that the module name is always appended to the end of the boilerplate rather than sometimes being in the middle and sometimes at the end as it is now.

Because of this, I have no respect for this objection at all, and I have to say that I would have expected a much better argument from Eric (for or against this proposal) considering his progranmming skills.

He explained that to me some time ago, and it's a similar story to this.

{Shrug} The exact text is an entry in Configure.help (under the symbol DEFINE_UNITS as it happens) so in that sense, the fact that I made a mistake as a result of misunderstanding the proposal is irrelevant.

No problem - just edit the entries in Configure.help to say whatever is consistent with the usage of the acronyms elsewhere in that file.

Blame the SysAdmin for that - if I choose (R)eply to a message, it always addresses it to whoever posted it, and CC's anybody listed elsewhere. I don't get the ability to change the "To" field, only the "Cc" field, so you will always get a copy of any reply I send to an email you've posted.

Best wishes from Riley.

Hi!

That "module" help text deserves to *die*. Explanation of modules should be provided *once* in CONFIG_MODULES.
Pavel

(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

Riley Williams <[email protected]>:

I have said before; I am *not* going to make KB vs. KiB a metaconfiguration option -- that would defeat the whole purpose of having standard terminology. That decision is final, and this subject is closed.

The other is not a bad idea in principle. I've thought before about adding a feature that would add specified boilerplate to the help a tristate symbol, for exactly the reasons you suggest. Three things make it a bit messy in practice.

One is that it would have to be expressed in the rulebase, ruther than wired into the code. I will not hardwire specific knowledge about the Linux-specific properties of tristate symbols into the CML2 engine. CML2 is already being used by at least two projects other than the kernel and I know of a third that has it under consideration. Therefore I must preserve its generality.

The second problem is that the module boilerplate is not all boilerplate. Most instances contain the name of the generated module object file. Thus, ypo do this right, I would have to declare module names in the rulebase, one for each tristate entry. This implies a significant extension to the CML2 language, which I'm reluctant to do right now. The design is stable. I want it to stay that way until (at least) well after CML2 achieves acceptance.

Third, I don't want to do major surgery on Configure.help until after CML2 enters the tree. Were I to do so, I would then have to maintain two different versions of Configure.help. That would be too big a pain.

Therefore, I'm going to defer consideration of this feature for now. I certainly will not consider it until after CML2 goes into the 2.5 tree, and may not consider it until there is some kind of final decision on a 2.4 backport.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

When only cops have guns, it's called a "police state".
        -- Claire Wolfe, "101 Things To Do Until The Revolution" 

With all due respect, Eric, I think you misunderstood. The way I understand it, Riley is simply proposing to automatically _attach_ an explanation of the KB/KiB confusion to help text of every option that uses these units.

Fair enough. I don't think anyone would want you to make it Linux-specific.

Again, these are all valid points. I guess you could just put this idea far on the TODO list for now. :-)
Same thing applies to the first part of Riley's proposition, it would seem.

"The Universe doesn't give you any points for doing things that are easy."
        -- Sheridan to Garibaldi in Babylon 5:"The Geometry of Shadows"
Dominik 'Rathann' Mierzejewski <rathann(at)we.are.one.pl>

Hi Dominik, Eric.

No such suggestion has come from me.

That is exactly what I'm proposing Dominik - and the patches to do this for make config are all ready for distribution, as are the basic patches for Configure.help itself. I'm working on the patches for make menuconfig at the moment, and will be doing those for make xconfig once those are complete. Once that's done, CML2 will be the only config tool not supporting it - and that's Eric's decision, not mine.

I'm certainly not planning on doing so. The changes to make config are on the basis that help requests from the "tristate" or "dep_tristate" commands automatically adds whatever is attached to the help variable DEFINE_MODULAR to the end of the help text for the option named. There's absoultely nothing in that logic that has any more relevance to Linux than to any other project using the same config toolsets.

This is already dealt with in the design I'm using. It requires that the statement naming the module appears as the last line of the boilerplate after the standard text, but that is already the case for several of the uses of the "I can be a module" text, and the others can easily be converted to use the same.

You may soon be in the position of having to maintain two different versions of Configure.help if you don't implement this feature, rather than if you do, as the code to implement it in the existing config tools is well under way, and make config is ready for testing.

Alternatively, you could have a look at what is actually required. Here is a summary of the requirements that proved necessary for make config to add boilerplate text to those options that can be selected as being modular in the current tree:

1. The help function is split up into three...

extract_help help-var

This extracts the help text associated with the help variable specified.

extract_all_help help-var...

This extracts the help text associated with all of the help variables named, and appends it all end to end in the order specified. It does so by calling extract_help for each argument in turn.

help help-var...

This passes its arguments to extract_all_help and then arranges for the resulting text to be shown to the user.

2. The places in the tristate and dep_tristate functions where the help function is called get an extra fixed parameter of DEFINE_MODULAR in each case.

3. The relevant help text is added to the Configure.help file.

That's it - the sum total changes required. Essentially the same changes are needed to get make menuconfig to do the same thing, but step (2) is a little more tricky in this case. I haven't looked at make xconfig yet, but that is unlikely to differ much from the above.

Once these changes are made, the additions to deal with adding other boilerplate for technical acronyms appropriate to the project in question are restricted to the Configure.help file itself and the extract_all_help function included above, and nothing else will need changing.

Incidentally, the changes to Configure.help in the current patches use empty boilerplate text, so the addition of the relevant lines in Configure.help to prevent it spewing out error messages results in a Configure.help file compatible with both the old and revised system.

Best wishes from Riley.

Not in my book. As far as I'm concerned, somebody who tells me that one KB of memory or disk is 1,000 bytes is a liar. When a disk manufacturer chooses to interpret KB in such a way as to make their disk seem bigger, I just say to myself "ok, they lied, that's what they do, they're in business and they don't care". Now could we just ignore the self-serving doublespeak promulgated by greedy manufacturers, and continue using KB please?

Kilo, as in memory -> 1024
Kilo, as in distance or weight -> 1,000

Difficult?

/me wonders when the kibblebytes thread is going to end

--
Daniel

/me wonders when people will learn to read more carefully (no offense intended) :-)

If you look at my post more closely, you'll see I used kB' (that's small k and capital B) for decimal kilobyte. I would never suggest using KB' (that's capital K and capital B) for it. I do agree that `KB' is traditionally used for binary kilobytes, but what about MB, GB and so on? These _are_ ambiguous. I am in favour of using Ki, Mi and Gi for binary quantities.

"The Universe doesn't give you any points for doing things that are easy."
        -- Sheridan to Garibaldi in Babylon 5:"The Geometry of Shadows"
Dominik 'Rathann' Mierzejewski <rathann(at)we.are.one.pl>

Hello!

Yes, the current MB/GB units are awfully ambiguous, but using Mi/Gi won't cure the confusion as nobody will know whether MB/GB in that text means the old-fashioned name of binary megabyte or the decimal megabyte according to the new standard. Yes, the confusion might die out after a long period of time of everybody switches to the new system, but I seriously doubt it will happen in the near future.

It seems that the only way which is going to work is to create a new decimal prefix for units of information as well. Not a particularly nice solution, but probable the only working one.

Have a nice fortnight

Martin `MJ' Mares   <[email protected]>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Every program in development at MIT expands until it can read mail.

So would you be happy with kB -> 1,000 bytes, and KB -> 1024 bytes? Likewise mB for 1,000,000 bytes and MB for 1048576 bytes?

Look, there's some precedent for it here:

http://www.unc.edu/~rowlett/units/dictK.html
"K - an informal abbreviation for one thousand used in expressions where the unit is understood, such as "10K run" (10 kilometers) or "700K disk" (700 kilobytes or kibibytes). Note that "K" is also the symbol for the kelvin (see below). Also note that the symbol for the metric prefix kilo- (1000) is actually k-, not K-."

If you believe that, then we don't have a problem, we never did:

kB -> 1,000 bytes
KB -> 1024 bytes

So, KiB is a silly fix for a problem that doesn't exist. Let's not have that silliness creeping into our documentation, making it look silly too.

--
Daniel

No way. m is the SI prefix for milli, one thousandth. (1/1000). K is the SI unit Kelvin (absolute temperature). Add to the confusion...

Matthias Andree

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."         Benjamin Franklin

On Sun, Dec 23, 2001 at 08:53:41PM -0200, Rik van Riel <[email protected]> wrote:

| On Mon, 24 Dec 2001, Cameron Simpson wrote:
| > Using KB in places where precision matters puts us all into case #4
| > below, because people think they know what KB means, but it means
| > different things to different people, and so people don't realise they
| 
| I take it this is your way of volunteering to always
| keep all kernel documentation accurate as well as
| answer questions from newbies who've never seen
| 'KiB' before ? ;)

Hmm. Not my plan at the time of typing, no.
But KB _is_ ambiguous. KiB is not (and it's ugliness is actually an advantage here - it's less likely to be misused by people who've not seen the definition).

Just out of curiosity, is there anywhere in the kernel space where KB (et al) is _not_ used to mean a power of 2 value?

Cameron Simpson, DoD#743        [email protected]    http://www.zip.com.au/~cs/

When you're all dressed up and no place to go.	- B.H. Burt (19th cent)

Now replace 'misused' by 'used'. I can guarantee you that half the documentation will go on using KB while the other half (if that) has KiB.

It doesn't help anything if there are more precise terms when they're used inconsistently. Somebody will have to check and fix this, continuously.

regards,

Rik

Shortwave goes a long way:  irc.starchat.net  #swl

http://www.surriel.com/		http://distro.conectiva.com/

Rik van Riel <[email protected]>:

The situation is not as bad as you think, Rik. I grepped; the Documentation subtree only has 17 instances of KB, of which about 6 clearly don't need correcting as they really are referring to disk capacities. The patch to fix these references would not be large.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

...Virtually never are murderers the ordinary, law-abiding people
against whom gun bans are aimed.  Almost without exception, murderers
are extreme aberrants with lifelong histories of crime, substance
abuse, psychopathology, mental retardation and/or irrational violence
against those around them, as well as other hazardous behavior, e.g.,
automobile and gun accidents."
        -- Don B. Kates, writing on statistical patterns in gun crime

Grep around in your RFC directory, and apply your argument. The KiB definition will _create_ ambiguity in technical communication which did not exist before.

-Mike

Agreed. I think almost technical guys assumed that 'KB' (or kB, or kb, or something ;-) IS 1024 bytes. Know even they starting to loose their belief about old one, and that new and 'strange' 'KiB'. Imho '1000 bytes = 1 kbytes' was only used by some tricky hardware vendors to trick their costumers (they could show bigger values ...). But even my sister knows that when someone's speaking about computers, 'kilo' means 1024, not 1000.

It's like when we declared that direction of electrical current is from positive to negative. Yes, we CAN change it now, because we know that it's not the right direction of electrons in real.

So, if the 'technical world' already assumed (imho) that 'kilo' is 1024 in computer technology then we shouldn't change it now ...

- Gabor

Whatever the choice ends up being, KB is always incorrect, unless you intend to specify some strange formula where the number of bytes (B) combined with the temperature in Kelvin (K) has anything to do with things.

/David Weinehall
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\

//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

The KB unit has been reserved for the temperature of a linux-kernel flamewar multiplied by the number of bytes of network traffic wasted on that flame-war.

:)

So, encouraging non-uniform terminology, breaking applicates *and* confusing the hell out of everyone is better? Face it, the only people trying to confuse things are the disk vendors. DRAM is sold by the MB, everyone talks about MB == 1024*1024... I'm having a hard time giving a sympathetic ear to anyone try to change the well established, and consistent (barring the storage venduhs), standard.

-ben

Fish.

Not true. Bandwidth is measured in metric. Pixels are measured in metric. Basically anything but RAM is measured in metric. RAM is the exception because of its intimate relation to bus width and that's an obvious anachronism. There's no reason anyone but a systems programmer should give a damn about powers of two.

 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

And disk vendors aren't even consistant! At least my 30 GB and 40 GB drives have 60036480 and 80418240 sectors, respectively (512 bytes each).

That computes to 30.7*10^9 and 41.2*10^9 or 28.6*2^30 and 38.3*2^30 bytes.

If you want numbers near 30 and 40 you need to calculate 30.0*10^6*2^10 and 40.2*10^6*2^10!

And as somebody else pointed out, 1 Mbit/s line is't 10^6 bit/s nor 2^20 bit/s line, either, a but 1024000 bit/s line.

=> Even if Configure.help would use kiB, MiB, GiB etc. it wouldn't remove many of the ambiguities. Is it worth the pain?

// /
....................................Timo Jantunen .......................
ZZZ (Used to represent :Kuunsäde 8 A 28: Email: jeti @iki.fi :
the sound of a person snoring.) :02210 Espoo : http://iki.fi/jeti :
Webster's Encyclopedic Unabridged :Finland : GSM +358-40-5763131 :
Dictionary of the English Language :...............:.....................:

Also sprach Oliver Xymoron

If by this you mean that in networking, a megabit per second is equal to 1000^2, or a gigabit per second is 1000^3, then my response consists of:

Uhm, no.

If your response (I haven't followed this whole thread, so I'm not up on all of the discussion here) is concerning the capitalization and such used for it, then I really don't care which it is as the purpose is to communicate, and strict adherence to capitalization just isn't that important to communication. *shrug*

This makes me think you're concerned about powers of 2 versus powers of
10. In which case, reference my response above.

Jeff McAdams                            Email: [email protected]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

[email protected] (Jeff Mcadams) wrote on 21.12.01 in <[email protected]>:

Well, 64 kBit/s is certainly equal to 64000 bits per second. (That's ISDN.)

And from a quick look through Google, Ethernet - in 10M, 100M, and G variants at least - also uses decimal powers.

So I'd say that's "Uhm, yes".

MfG Kai

If someone sells you 16MB of RAM and it turns out to be 16,000,000 bytes, not only would it be appropriate use of units, it would be quite reasonable as far as I can see to say it was in accordance with labelling of products.

The world did not begin in 1970, A-Za-z is not English collate order and M is 1,000,000. When computing meets the rest of planet earth usages for the odd hundred years its hard to see any reason to believe we are "right"

Eric using MiB seems the right thing. Its an ugly but appropriate unit, its at least recommended as a solution by a standards body. We can either redefine SI units ("You cannot change the laws of physics") or find a better label. What better than a recommended one others use.

Alan

Ok, then how *you* would call the abovementioned link that has 4096000 bits per second bandwidth? Yes, it's possible to say 4096 kbit, but then you'll also have 32768 kbit links and 8388608 kbit links ...

But how do you avoid something that *exists*? I mean - physically. The devices that are described by these numbers are being produced and used.

Vojtech Pavlik
SuSE Labs

The only problem is that M = 10^6 plus Mi = 2^20 don't cover the usages ...

4Mbit bandwidth is usually 4 * 10^3 * 2^10 bits per second. 20GB harddrive is usually 20 * 10^6 * 2^10 bytes.

The confusion is there. It can't be erradicated by adding Mi's and Gi's, because they don't cover the whole spectrum.

Well, maybe we could have a 4 kKib/s connection and a 20 MKiB drive, but that'd be even more confusing than what we have now.

Vojtech Pavlik
SuSE Labs

[email protected] (Vojtech Pavlik) wrote on 22.12.01 in <[email protected]>:

There's a simple answer. "These people lie."

We don't *want* something that covers that part of the spectrum. We want that part to be *avoided*.

MfG Kai

Please, please dont add more confusion.. Fortunatly people how sell harddisk and bandwidth are both very consistent.
4Mbit bandwith IS always 4 x 10^9 bits per second
20GB harddrive IS always 20 x 10^20 bytes.

The confusion starts by saying a Mbit is only 1000 Kbit.. Well it is but the Kbit here is 1000bit/s
And a GB is only 1000,000 kB, but these kB is only 1000 bytes.

Dont confuse the matter anymore, I am sure someone does, but they are wrong!

regards
Allan

This is fantastic!

Your confusion seems to start when you are many orders of magnitude out with both your previous examples.

whoohooo

--
ABeet.

I've changed my mind. K2B would seem to imply
2**3 Bytes, which is 8 Bytes.

I think that way to solve the issue is to just byte
the bullet and stop equating 1024 with K. It's
just such an inconsistant and ad hoc hack.

The only truly logical way to do this would be to base everything on bits and powers of two. But, since we run out of common prefixes at 2**6 (exa), we should just stick to decimal
and scientific format. 1024 = 2**10.

[email protected].

On Fri, Dec 21, 2001 at 02:18:47PM -0500, Benjamin LaHaise wrote:

So, encouraging non-uniform terminology, breaking applicates *and* confusing the hell out of everyone is better? Face it, the only people trying to confuse things are the disk vendors. DRAM is sold by the MB, everyone talks about MB == 1024*1024... I'm having a hard time giving a sympathetic ear to anyone try to change the well established, and consistent (barring the storage venduhs), standard.

And disks by the GB where GB == 1000^3 so I don't see any problem in moving from KB to KiB and friends ESPECIALLY AS THEY ARE STANDARDIZED BEYOND THE KERNEL and nothing will change this.

--CW

If you think GB == 1000^3, then please go "correct" all the DRAM manufacturers out in the world. They just sent me 1GB of ram and it's coming up as 1073741824 bytes. Please help! They have no option for GiB!!!

-ben

Fish.

Also, a GB of disk space really is 2^10 * 10^6 ...

Better make sure we get it consistent ... *runs like hell*

Rik

DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/

http://www.surriel.com/		http://distro.conectiva.com/

I always thought they'd like to count the size of disks in bits... man, don't you really want on of those new 240Gbit disks? I hear they can pull in a sustained 200Gbit/s on reads!

-ben

Fish.

On Fri, Dec 21, 2001 at 03:47:50PM -0500, Benjamin LaHaise wrote:

On Fri, Dec 21, 2001 at 06:36:22PM -0200, Rik van Riel wrote:

> Also, a GB of disk space really is 2^10 * 10^6 ... >
> Better make sure we get it consistent ... *runs like hell*

I always thought they'd like to count the size of disks in bits... man, don't you really want on of those new 240Gbit disks? I hear they can pull in a sustained 200Gbit/s on reads!

But what Rik points out shows that right now there is ambiguity BECAUSE OF LACK OF STANDARDIZATION --- because GB is vague at the very best, disk manufactures get to claim nice marketing numbers.

As for bits/second sort of thing, this is common in networking of course, especially when they talk about raw data rate and ignore framing overhead and such like.

--cw

Actually, I was more trying to ridicule the people who believe we have any chance in hell of "getting it right".

Personally I believe we should stick to tradition. Better let people be confused about the last 10% of capacity than confused about the meaning of the text ...

cheers,

Rik

DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/

http://www.surriel.com/		http://distro.conectiva.com/

GiB is not a useful standard because NOBODY USES IT. When it's in common use, then consider applying it to the kernel, but please, not before then.

-ben

Fish.

To summarize: don't use it widely until it's widely used.

Let's apply that standard to aio, shall we? :P

 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Actually, I just find it the most gratingly ugly thing I've ever seen, and pointless as everyone already knows the meaning by context.

-ben

Fish.

If you think GB == 1024^3, then please go "correct" all the disk manufacturers out in the world. They just sent me 1GB of disk and it's coming up as 1000000000 bytes. Please help! They have no option for GiB!!!

It's already clear that the terminology is internally inconsistent, now we can either clarify it or live with the existing confusion.

 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

[email protected] (Oliver Xymoron) wrote on 21.12.01 in <[email protected]>:

You've been defrauded. Typical disk GB come up as 1024,000,000 bytes.

Which is bloody awful.

MfG Kai

What better place to start "common use" then the kernel source. Let's lead the way, not wait around to follow others.

Somebody has to be first, why not us?
Then once it get more common, we will have
been a leader forging into a brave new world :)

-Thomas

Just my 2.8 KiB worth :)

Maybe because there's strong resistance to the change in the very place you'd evidently like to START the change? That's generaly a clue that it'd be best NOT to try and make the change.

On Fri, Dec 21, 2001 at 04:10:30PM -0500, Benjamin LaHaise <[email protected]> wrote:

| On Sat, Dec 22, 2001 at 10:00:17AM +1300, Chris Wedgwood wrote:
| > But what Rik points out shows that right now there is ambiguity
| > BECAUSE OF LACK OF STANDARDIZATION --- because GB is vague at the very
| > best, disk manufactures get to claim nice marketing numbers.
| 
| GiB is not a useful standard because NOBODY USES IT.  When it's in 
| common use, then consider applying it to the kernel, but please, 
| not before then.

This is poor motivation.

s/GiB/linux/

We can all go to using Windows then... Thus is progress made.

Cameron Simpson, DoD#743        [email protected]    http://www.zip.com.au/~cs/

On Fri, Dec 21, 2001 at 03:31:36PM -0500, Benjamin LaHaise wrote:

If you think GB == 1000^3, then please go "correct" all the DRAM manufacturers out in the world. They just sent me 1GB of ram and it's coming up as 1073741824 bytes. Please help! They have no option for GiB!!!

I don't want to get dragged into this silly debate; the point I was making is that we already have considerable inconsistency and choosing STANDARDS BASED tokens might not be a bad thing.

The nomenclature in use here is bigger than Linux (yes, believe it or not such a thing is possible!), and like it or not people should just get over it.

Standards exist to make peoples lives easier, the fact the hard drive and memory vendors currently don't use these phrases right now doesn't make the standard wrong --- this world is full of clue-less marketing people and nothing will change this.

Accept that KB and GB are *wrong* (this isn't a statement of opinion but rather of fact [1]) and then choose whether or not Linux documentation should be wrong or right.

--cw

[1] IMO anyhow :)

[email protected] (Chris Wedgwood) wrote on 22.12.01 in <[email protected]>:

Oh, it can be changed. Just the way car advertising has been changed to use kW. (Well, it has over here.) And the way monitor size advertising is in the process of being changed to use SI units, not US ones.

Fair advertising laws can be rather effective.

MfG Kai

They're defacto standards that have been in use for well over a decade. If the same could be said about GiB, maybe I could agree with you.

Hmmm, all of the advertising, computer media and electrical engineering related material I've read recently seems to be using GB. In fact, there was one very article about the whole issue that found the computer industry to be remarkably consistent in using terms like "10GB" with no space between the number and the measuring unit. Oh wait, sorry, that's not formally approved by any standards bodies.

Many standards bodies are examples of confusopolies. Take a look at the POSIX threading standards. Do they make people's lives easier under Linux? Should we accept every standard at face value and follow it obediently wherever it takes us?

Can you send me replacements for all the documentation I've got that mentions GB or KB then? I wouldn't want to be non-compliant.

-ben

And how about my 17 M-KiByte disk ?

(yes, 17 million kibibytes, plus or minus whatever the amount of disk space is the factory's low-level format found ... probably as much as an error as getting the exact word in the manual)

cheers,

Rik

DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/

http://www.surriel.com/		http://distro.conectiva.com/

[email protected] (Benjamin LaHaise) wrote on 21.12.01 in <[email protected]>:

And it's been wrong for all of that decade, because the rest of the world
- *all* of it - has been using a different version for quite a bit longer than that.

Unfortunately, while the typesetting may be consistent, the *meaning* isn't. You cannot swap out 10GB RAM to a 10GB hard disk, it will overflow.

Well, this particular "de facto standard" certainly is a confusopoly.

MfG Kai

David Garfield <[email protected]>:

Yeah, that's because I can't touch the symbol namespace. Not yet, anyway.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

He that would make his own liberty secure must guard even his enemy from
oppression: for if he violates this duty, he establishes a precedent that
will reach unto himself.	-- Thomas Paine

Two words: "Posix threading."

Somebody had to say it.

How many successful real-world networks have been designed around the OSI 7 layer burrito networking model?

ISO standards do not define reality much on the internet. RFCs define reality quite often on the internet. Most RFCs come well after the fact, and an amazing number of RFCs are ignored or quickly replaced. Several of them ADMIT to being jokes. Are you saying an ISO pronouncement has MORE weight than an RFC?

ISO got into the computing world largely by rubber-stamping existing standards from ANSI, CCITT, IEEE, and elsewhere. Not by making good decisions. The ISO will happily standardize sugar cube sizes and pencil lead density. They don't HAVE to know anything about the subject in question.

The best standards are the ones that either document practices that already exist or define a draft interoperability procol hammered out by the parties who are going to implement it (preferably with sample code which ends up being worth more than the standards document).

Do you expect Microsoft to start using the term "mebibyte" any time soon? Or hard drive manufacturers (who largely use decimal megabytes anyway for marketing reasons)? Or ram manufacturers who obviously want end users to learn a new term to buy their products? It would be a stupid marketing move.
(Sheesh, AMD's launching a major campaign to get away from "megahertz". And
failing at it, I might add.) How long did it take for end users to stop referring to the "baud rate" of their modem, which hasn't been technically true since the 300 baud days. (A "2400 baud" modem was actually 600 baud, 4 symbol if I remember correctly...)

In the short term, this change to the help files (which people look at when they DON'T know stuff) is GUARANTEED to confuse WAY more people than it even hopes to help over at least the next two years. Almost everybody who sees it is going to have to ask "what's a mebibyte" and go look it up. Does this really make the help file more helpful?

If the term goes into widespread use, THEN switch. If you want to make a policy about it, we currently use binary measures when we measure memory or storage in the linux kernel unless otherwise specified. Always have done.

Rob

find . -name "*.?" | xargs grep MiB | wc
46 lines, half of which seem to live in "jedec_probe.c".

find . -name "*.?" | xargs grep -w MB | wc
302 lines. And that's just upper case, whole word, not "MBs" or "Mb" or
any other fun little variation...

find . -name "*.?" | xargs grep -i MEGABYTE | wc

     31 lines.

find . -name "*.?" | xargs grep -i MEBIBYTE | wc
1 line, and it's a comment saying it's NOT being used (along with one
of the MiB hits).

If you're going with a uniform terminology argument, you should drop MiB altogether. Unless you want to submit a patch to the kernel to standardize all the other occurences everywhere else? :)

Rob

This may be why Andrea Arcangelli refuses to write any documentation at all, Linus seems to have a prediliction for dropping documentation-only patches, why the stuff in /linux/documentation has fallen up to two years out of date at times, and why "Rusty's Unreliable Guides" (the best source of documentation on the netfilter code, made available by the author himself at "http://netfilter.samba.org/unreliable-guides/") says, and I quote:

-----

The Linux Documentation Project has the noble goal to `create the canonical set of free Linux documentation'.

The Open Source Writer's Group wants `to put together a comprehensive "card catalogue" of Open Source and Open Source-related documentation'.

On the other hand, my pet hamster dressed up in a penguin suit, and appeared to me in a dream, telling me to write documentation for random stuff, and include lots of obscenities.

The LDP guys no longer return my EMails (from me or my hamster).

-----

On the net, the way to get information isn't to ask questions, but to post errors. Questions get ignored more often than errors go unflamed. Perfect documentation, like perfect code, isn't something you wait until you have before proceeding.

Rob

Send them to the maintainers not to Linus generally helps. Or to Marcelo because he seems to understand its important.

[Thats out of date btw - OSWG is gone]

Ah so aio would be perfect code - thats the problem 8)

No doubt. The file drivers/block/loop.c has about 21 comments, although most of them are useless. The file is over 1700 lines long.

It would be a lot easier to grok this code if it didn't look like an entry for the IOCCC :) Comments would be nice.

--
Eric Windisch
http://bwbohh.net

Rob Landley <[email protected]>:

Rob, you haven't looked at the actual changes I made, have you?

If you had, you'd realized that I have not introduced "kibibyte", or "mebibyte" or any of those terms anywhere. The Configure.help changes involve only the IEC-standard abbreviations KiB, MiB, and GiB.

Try criticizing what I actually did, as opposed to what you merely *assume* I did. You'll be more convincing that way.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"The best we can hope for concerning the people at large is that they be
properly armed."
        -- Alexander Hamilton, The Federalist Papers at 184-188

It will. The resistance to the new terminology simply on the grounds that it's new and not yet widely familiar _will_ pass.

The correctness and the lack of ambiguity will remain.

--
dwmw2

I looked at the patch, which was actually fairly small. But it didn't seem to be the only potential change along these lines, and I thought I'd object now and avoid the rush. (Yeah I know, "too late"...)

Maybe not in this patch, but I got the impression it signified a policy decision to change terminology and stick with the new one uniformly, at least in the help files.

Since then, another part of the thread has indicated (and the help file now says at the top) that the help file will say "binary megabytes" instead of mebibytes. "mebibytes" for binary megabytes? If this policy was there in the original patch, I missed it.

I didn't know the ISO was merely rubber-stamping somebody else's standard, but I can't say I'm suprised. Well, I suppose I'm all for "catalyzing progress in the information-industry and university communities", as the IEC's web page says (isn't google fun). Gee, we'd never be able to figure out what to call things if these guys weren't around to make decisions for us...

Specifically, it seems they adpoted it as amendment 2 to IEC 60027-2, standardizing kibi, mebi, gibi, tebi, pebi, and exbi, with symbols Ki, Mi, Gi, Ti, Pi, and Ei. (A PiB obvioiusly and unambiguously being the number of bytes required to hold an accurate floating point representation of Pi. :)

This does not, in fact, remove the term "mebibytes" to the discussion. It means the current policy is to selectively follow part of the standard, and explicitly ignore the rest of the standard as too ugly to live. The prefix "mebi" is, in fact, explicitly part of the IEC standard the ISO AOLed, thus "mebibytes" is what "MiB" is short for. (I wasn't even the one to introduce the term mebibytes into this thread.)

Ooh, why start now? :)

What you did was announce a new editorial policy. Look at the subject line of the thread. That's noticeably larger than a single patch.

My objection is that this switch does not seem to be based on improving the understandability of the documentation to that documentation's intended users (who, on the whole, consider "7K RAM" to be sufficiently unambiguous without even a B). We've always used domain based differentiation (ram is binary, networking is decimal, disk needs to be specified because manufacturers lie for marketing reasons). This seems to be a solution in search of a problem.

Now I agree that as numbers get bigger the distinction matters more (2% per kilobyte, 5% per megabyte, 7% per gigabyte, and almost 10% per terabyte). But the binary or decimal nature of the measurement has always been application specific up until now, and I'm curious why that's suddenly not good enough anymore. The new method is a much more fine-grained level of detail which is, in fact, easier to screw up.

Is the help file even currently accurate with this extra distinction made? Look at NCR53c8xx SCSI support, which says the transfer rate is 80 MB/s. Is that really, accurately a million decimal megabytes per second? Is it 80.3 or 80.7? Has anyone ever cared to confirm this who was not capable of looking in the code to determine the answer? Is there a POINT in specifying "Men in Black" units everywhere that is currently generally accepted practice to default to binary (although using i for bInary makes as much sense as using i for decImal, if you ask me)?

The switch appears to be based on the assumption that conformance to a standard issued by a bureaucratic body is arbitrarily better than established practice. And yet that's not what it does, because it refuses to use the long form...

The help file STILL uses the prefix "mega" without specifying binary or decimal in at least these sections:

Synchronous transfer frequency in MHz
Enable kernel debugging symbols
Virtual memory file system support
Remote GDB kernel debugging
GDB Stub kernel debug

Just looking at the first, do you really think saying "binary mega-transfers" is going to be less confusing? How about "mebi-transfers", people will know right off what THAT means without having to look it up...

And you've already implied you want to change the symbol set for CONFIG_NINO_4MB and such. How deeply into the kernel will these changes go?

The patch is a can of worms, and abandoning the current domain-based defaults (ram is binary, network is decimal, disk needs to pick one) is not something I see as an improvement. But you're the maintainer...

Rob

[email protected] (Rob Landley) wrote on 23.12.01 in <20011223174227.NCJM25224.femail12.sdc1.sfba.home.com@there>:

Would you want to live in a world where 1 litre milk was either more or less than 1 litre water?

Why, then, do you think it was *ever* "good enough"?

I certainly never thought that 1 GB disk being a different number of usable bits than 1 GB RAM was ever "good enough". *I* considered that to be plain old fraud.

"Established practice" is that these prefixes are decimal. It has been established practice before the first electronic computer was even built.

I see it as an unequivocal improvement, even though I don't like the actual choice of prefix. But then, I never liked "Exa" or "Peta" either
...

MfG Kai

Rob Landley <[email protected]>:

Not completely, but that's because in some cases I don't know whether decimal or binary multiples are involved. Where that is the case I have left the ambiguous terminology in place.

I don't know yet. I can only clean up the bits for which I am maintainer.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The spirit of resistance to government is so valuable on certain occasions, 
that I wish it always to be kept alive.  It will often be exercised when 
wrong, but better so than not to be exercised at all. I like a little 
rebellion now and then.	-- Thomas Jefferson, letter to Abigail Adams, 1787

You can't kill ISDN that easily. And not just ISDN, actually most phone lines are based on 2048000 bit per second links ...

Vojtech Pavlik
SuSE Labs

Beg to differ. E1 is only 2048000 bits/second if you never send 5 consecutive 1 bits. The actual data rate on an E1 is in fact variable

Alan Cox <[email protected]> remarked:

To the best of my recollection, the line bit (symbol) rate is fixed at, ideally, 2048000 bps. At least with HDB3 line coding, a sequence of 4 consecutive zeroes is replaced with three midscale values one the line, and a mark that violates the normal mark alternation scheme. I.e. 1,0,0,0,0 might be replaced with +,0,0,0,+

Thus, the "payload" data rate of 2048000 equals the line symbol rate of 2048000 symbols/sec. (Of course, this isn't really the "payload" data, since it includes the framing slots and all that, but...)

Dan