Re: Patchset pertaining to --si option of df, du, ls

[L A Walsh]

On 9/8/2020 9:27 AM, Glenn Golden wrote:
> The attached patchset addresses a minor issue with program behavior vs.
> documentation of the df, du, and ls tools from coreutils-8.32, when using
> the --si option.
>
> It resurrects an issue that was brought up in 2014 [3] and eventually closed
> in 2018 [4] with a wontfix (after minimal discussion in the intervening time).
>
>
> Summary
> -------
>
> Output from df, du, ls tools with the --si option display results using 
> single-letter units suffixes "k", "M", "G", etc., rather than "kB", "MB", "GB".
>   
----
   With or without --si?

   If you want to change 'si' output, I'm not against that, however
I am very much against changing default or -h format.

   I don't need to know 'B' as a suffix when talking about disks.
Disks under an OS report space in base-2 multiples of bits (2**3 bits=1B).

   In memory and disk utils used in operating systems, the assumed unit is
the base-2 unit, the Byte and base-2 multiples thereof.  You cannot and
should not try to mix bases when reporting sizes -- if you use Bytes (as
on a computer), then K,M,G,... are base-2 multiples of a base-2 unit.

   If you are talking 'b'its, it seems that is the closest practical unit
for measurement of information.  With a single unit, base10 kbit, gbit, mbit
or kb,gb,mb seem fine.  There is no possibility of confusion with prefixes
for fractional values as you can't have a milli-bit or such.

   I find kB confusing, since it is using the lower case 'k' as used for
km (kilometer) and shouldn't be used where 1024 is meant.

   I.e. when measuring values of space -- standard hard disks require
512B.  Various utils also use 1K as a disk space size and recent hard disks
have a 4K sector size.  When reporting space, you can't allocate fractional
sectors so they have to be a multiple of 512, 1K or 4K and --si should have
no place among base-2 machines regarding disk space.  Memory is the same.
It isn't allocated in numbers that are multiples of 10.  Anyone using
nomenclature suggesting such, is demonstrating how little they know  about
computers -- and those who use computers should listen to them about how
to describe space?


That said, since metric more famous usage for prefixes >1 has been
'k', I prefer lower case for metric to be consistent with long standing
usage of 'km' = kilometer.  Larger values, _I_ feel should be consistent
with metric's largest usage: How often do you see a sign showing anything
in mega-meters or giga-meters.  You ever see anything measured in
mega-liters (let alone giga or tera liters).

Metric has standard units where the prefixes apply to the singular unit.
A Byte isn't a singular unit of information, a 'bit' is.  Therefore standard
's.i.' units shouldn't really be used with non-singular units (is there
a counter example, like where one talks about mega-[some non unary unit],
like a gross of eggs being 1.2 deka-dozen eggs (I think)?

The main problem is that base-10 isn't a good fit for a base-2 environment,
though I would regularly accept base-10 prefixes with bits.

So can you reserve lower case for SI, since they use lowercase 'k' for
1000-m and leave Uppercase (with or without B) for base-2?

It may not be what's authoritative, but it is what makes sense.

It would also allow scripts that use existing behavior in non-base10 to
continue working.  Though might break scripts using --si.  But how many
scripts would use that?