I second that emotion.
> 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.
I'd vote for that.
> 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.
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.
> 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.
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!- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/