GNU bug report logs - #17505
Interface inconsistency, use of intelligent defaults.

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Pádraig Brady <P <at> draigBrady.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#17505: closed (Interface inconsistency, use of intelligent
 defaults.)
Date: Fri, 16 May 2014 09:39:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Fri, 16 May 2014 10:37:55 +0100
with message-id <5375DC73.9030005 <at> draigBrady.com>
and subject line Re: bug#17505: Interface inconsistency, use of intelligent defaults.
has caused the debbugs.gnu.org bug report #17505,
regarding Interface inconsistency, use of intelligent defaults.
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
17505: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17505
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Linda Walsh <coreutils <at> tlinx.org>
To: bug-coreutils <at> gnu.org
Subject: Interface inconsistency, use of intelligent defaults.
Date: Thu, 15 May 2014 18:24:11 -0700

On programs that allow input and output by specifying computer-base2 powers
of K/M/G  OR decimal based powers of 10,

If the input units are specified in in powers of 2 then the output should be
given in the same units.

Example:

dd if=/dev/zero of=/dev/null bs=256M count=2
... So 512MB, total -... but what do I see:
536870912 bytes (537 MB) copied, 0.225718 s, 2.4 GB/s

Clearly 256*2 != 537.

At the very least this violates the design principle of 'least surprise'
and/or 'least astonishment'.

The SI suffixes are a pox put on us bye the disk manufacturers because
they wanted to pretend to have 2GB or 4GB drives, when they really
only have 1.8GB, or 1907MB.

Either way, disks are created in powers of 512 (or 4096) byte sectors,
, so while you can exactly specify sizes in powers of 1024, you can't
do the same with powers of 1000  (where the result mush be some multiple of
or 4096 for some new disks).

If I compare this to "df", and see my disk taking 2G, then I should
be able to xfer it to another 2G disk but this is not the case
do to immoral actions on the part of diskmakers.  People knew, at the time,
that 9600 was a 960 character/second -- it was a phone communication speed
where decimal was used, but for storage, units were expressed in multples
of 512 (which the power-of-10 prefixes are not).

(Yes, I know for official purposes, and where the existing established
held sway before the advent of computers, metric-base-10 became understood
as power of 10 based, but in computers, there was never confusion until
disk manufacturers tried to take advantage of people.

Memory does not come in 'kB' mB or gB (kmg=10^(3*{1,2,3}).. it comes
in sizes of KB/MB/GB or (KMG=2^10**{1,2,3}).

But this isn't about changing all unit everywhere... but maintaining
consistency with the units the user used on input (where such can be
verified).

Reasonable?  Or are inconsistent results more reasonable?

;-)

[Message part 3 (message/rfc822, inline)]

From: Pádraig Brady <P <at> draigBrady.com>
To: Linda Walsh <coreutils <at> tlinx.org>
Cc: 17505-done <at> debbugs.gnu.org
Subject: Re: bug#17505: Interface inconsistency, use of intelligent defaults.
Date: Fri, 16 May 2014 10:37:55 +0100

[Message part 4 (text/plain, inline)]

On 05/16/2014 02:24 AM, Linda Walsh wrote:
> On programs that allow input and output by specifying computer-base2 powers
> of K/M/G  OR decimal based powers of 10,
> 
> If the input units are specified in in powers of 2 then the output should be
> given in the same units.
> 
> Example:
> 
> dd if=/dev/zero of=/dev/null bs=256M count=2
> ... So 512MB, total -... but what do I see:
> 536870912 bytes (537 MB) copied, 0.225718 s, 2.4 GB/s
> 
> Clearly 256*2 != 537.
> 
> At the very least this violates the design principle of 'least surprise'
> and/or 'least astonishment'.

I agree that the units representation is unfortunate,
but an accident of history.
POSIX species 'k' and 'b' to mean 1024 and 512 respectively.
Standards wise 'k' should really mean 1000 and 'K' 1024.
Then extending from that we now have (which we can't change for compat reasons):

  k=K=kiB=KiB=1024
  kb=KB=1000
  M=MiB=1024^2
  MB=1000^2
  ...

However when _outputting) the stats line we could use the
least ambiguous and most standard unit, which would be the IEC unit.
The attached patch changes the output to:

  $ dd if=/dev/zero of=/dev/null bs=256M count=2
  2+0 records in
  2+0 records out
  536870912 bytes (512 MiB) copied, 0.152887 s, 3.3 GiB/s

thanks,
Pádraig.

[dd-stats-units.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.