On Fri 20 Oct 2006 at 10:27AM, Eric Lowe wrote:
> >>There is an easy way out of the suffix problem: use 'b?' for K, M, etc.
> >>and 'b?i' for Ki, Mi, ... so I don't see why there is so much debate
> >>about this. Forcing KiB, MiB, etc. will forcibly change the output of
> >>tools which currently display KB, MB, etc. using 2**(10**n) which may be
> >>undesirable.
> >
> >No, it is desirable. Are there tools which have declared that their
> >output with scaled numbers is stable? Even if there are, they don't
> >have to be converted to use this function. All new code should be
> >forced to use suffixes which indicate the base. Let's fix the world.
>
> I figured out that with the 'u' modifier you CAN use the old method,
> except with %A, which seems OK.. I have updated the spec to make
> the IEEE/IEC prefix the default for binary conversion since it sounds
> like everyone is converging toward following the new standard by
> default.
Is this case still open? I have a couple of thoughts here.
Please forgive me if I've misunderstood, but I want to make sure
we're implementing something which actually reflects what we need
for the commands we're building.
> >No, it is desirable. Are there tools which have declared that their
> >output with scaled numbers is stable? Even if there are, they don't
> >have to be converted to use this function. All new code should be
> >forced to use suffixes which indicate the base. Let's fix the world.
Basically, I want to come out diametrically against what Bustos is
arguing here. The job here is to meet the needs of customers, not to
"fix the world."
Looking at the commands we have, and our current style of usage,
it looks like this:
"To use the SI prefix for binary output, use the 'u'
modifier and append the appropriate prefix. It is
highly recommended that new software use the
IEEE 1541-2002 standard for expressing binary
numbers."
Means that we're not going to be able to easily drop this into the
output of commands without forcing all such commands to change.
I think what this means is that you are advising people that instead
of this:
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
531 dp 37M 30M sleep 1 0 0:00:48 0.2% Xsun/1
480 root 6992K 4528K sleep 59 0 0:01:15 0.1% intrd/1
That the command should emit:
VVVVVVVVVVVVV
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
531 dp 37Mi 30Mi sleep 1 0 0:00:48 0.2% Xsun/1
480 root 6992Ki 4528Ki sleep 59 0 0:01:15 0.1% intrd/1
This:
/dev/dsk/c0t1d0s6 7.9G 1.9G 5.9G 25% /opt
dp_stuff 17G 9.0G 7.6G 55% /dp_stuff
Should emit:
/dev/dsk/c0t1d0s6 7.9Gi 1.9Gi 5.9Gi 25% /opt
dp_stuff 17Gi 9.0Gi 7.6Gi 55% /dp_stuff
For applications like this, this is silly and useless--- human beings are
pretty damn good at understanding things in context-- and 30M and 17G
have real meaning here. To me the two character prefix is just wasting
precious columns-- a significant consideration in the UNIX world.
%A needs more examples and I think more thought. In the
world of Solaris commands and humanized output, you're going to
prinicipally use 'A' since you want to adapt to the user's workload. If
we can't do %uA (or is it %ubA? I'm not sure), then we can't use this for
any of the commands we have without altering their output (and adding
columns).
Leave "fix the world" to the zealots. The argument that commands which
don't embrace your routine can just go it alone indicates that you're not
interested in solving the problem in a way that meets the needs of the
primary consumers.
Mi, Ki, Ti, etc. may be very clear to those with degrees in physics, but
they don't in my experience reflect current real world usage and I think
they are not very consumer friendly. That is to say, my Dad might be able
to work out what 128MB means, but 128MiB might well be meaningless to him.
If in 5 or 10 years that changes, we can come back and revisit this.
Early on this case decided not to solve the "dehumanize" problem-- but I
think it's central here. By the logic of "fix the world", it seems like
you might also suggest that programs which ask the user to input values in
a human way will force the human to use "128Ki" to mean 2^10? And
otherwise the human will get 128,000? Certainly there are a lot of times
and cases when either the programmer or the human has enough context to
know how to interpret "K", and the routines here need to accomodate that.
-dp
--
Daniel Price - Solaris Kernel Engineering - dp at eng.sun.com - blogs.sun.com/dp
