On 2013-08-26, Erling Westenvik <erling.westen...@gmail.com> wrote:
> On Mon, Aug 26, 2013 at 11:27:36AM +0000, Stuart Henderson wrote:
>> you will then end up with some of them switching to dreadful MiB etc. ;)
>
> Kinda off topic and I take it you were being sarcastic, but your
> mentioning of the "dreadful MiB" reminded me about the LibreOffice
> spreadsheet I'm using to calculate from GiB/GB to sectors so that I can
> have disklabel(8) partition my harddisks according to standard units.
disklabel(8) already understands standard units, no need for spreadsheets.
The built-in label editor (fourth form) provides a simple interactive
label editor. Some commands or prompts take an optional unit. Available
units are `b' for bytes, `c' for cylinders, `k' for kilobytes, `m' for
megabytes, `g' for gigabytes, and `t' for terabytes. If no unit is
given, the default is to use sectors (usually 512 bytes). Quantities
will be rounded to the nearest cylinder when units are specified for
sizes (or offsets).
> Are there strong opinions against following standards and start
> converting to the proper terms for gigabytes (decimal, base 10, 1GB =
> 1000^3 bytes) and gibibytes (binary, base 2, 1 GiB = 1024^3 bytes)?
>
> After all it's been a while since it was logical (!) to infer that since
> 1024^1 (kibi) is *almost* 1000^1 (kilo), then 1024^3 (gibi) must
> *almost* be 1000^3 (giga).. ;)
>
> Personally I would love to see disklabel(8) default to display sizes in
> base-10 and with something like an optional -i or -2 switch to display
> information in the old (current) base 2 definition. At least it would be
> nice if it were using proper units - like GiB instead of GB.
IMHO: damn the hard drive vendors. Traditional terminology in computing
has always been to use powers of two...
