Ubuntu Policy: prefixes for multiples of units

[Neal McBurnett]

On Wed, Sep 24, 2008 at 08:28:36PM +0100, Scott James Remnant wrote:
> On Wed, 2008-09-24 at 12:16 -0600, Neal McBurnett wrote:
> 
> > On Wed, Sep 24, 2008 at 06:26:12PM +0100, Scott James Remnant wrote:
> > I've never heard of this sort of unofficial policy - where has it been
> > documented?
> > 
> That's kind of the point of an unofficial policy, it's never been
> documented, we've just practised it.

Yeah - I could have been clearer there.  In the absense of a written
policy, e.g., listing documented examples of that practice, where
Ubuntu has previously tread in this area, would be very helpful.  That
is why I brought some bug reports into the conversation.

In general I think grounding ourselves in specific cases is pretty
important.  I worry about adopting a policy without having a sense for
most of the sorts of circumstances it might be applied, and how it
might conflict with other policies and practices we have (like the
question of when we find it important to differ with upstream or
Debian).

> > > First we should have the discussion.
> > 
> > Note the existing discussions: 
> >  https://bugs.launchpad.net/ubuntu/intrepid/+source/net-tools/+bug/240073
> >  https://bugs.edge.launchpad.net/ubuntu/+source/net-tools/+bug/119998
> > 
> Indeed, and your comments on those discussions were right in front of me
> as I attempted to write this up.
> 
> Unless I'm mistaken, the following largely agrees with you?

I'm glad to see the way those bugs were resolved - thanks!  But I
think we still disagree on when it is appropriate to use binary
multiples, and on standards vs marketing as motivators.

> > > Since a byte is not divisble by 10, and a bit is inherently indivisible,
> > > the divisor prefixes: deci(d), centi(c), milli(m), micro(µ), nano(n),
> > > pico(p), femto(f), atto(a), zepto(z) and yocto(y) are *not* valid and
> > > must never be used in Ubuntu.
> > 
> > Not true. There are statistical circumstances in which these terms
> > make sense, in the same way that we talk about fractions of a person.
> > 
> Given that we're attempting to convey information to the user, and that
> very few users would be familiar with the term "nanobyte" or the
> implications of it, is it really worth allowing?

I see no reason to say something like that in an Ubuntu policy - who
knows which of our tens of thousands of packages deal with statistical
information theory, etc?

> > > Confusion has often reigned as to the exact values of these multiples;
> > > since computing has often used factors as powers of 2, rather than
> > > powers of ten.  Thus a kilobyte may be considered 1x2^10 bytes (1024) or
> > > 1x10^3 bytes (1000) depending on the system in use.
> > > 
> > > Efforts have been made in the standardisation world to address this
> > > problem.  The International Electrotechnical Commission (IEC), in IEC
> > > 60027-2 A.2, invented a new set of "binary" prefixes.  These include the
> > > kibibit, mebibit and gibibit.
> > > 
> > > Despite their attraction to the standards world, these have not yet seem
> > > adoption in the industry.
> > 
> > On the contrary, in addition to support from multiple international
> > standards bodies (IEEE, ISO, IEC, NIST and CENELEC), there are many
> > software applications that use these prefixes - see:
> > 
> >  http://en.wikipedia.org/wiki/Binary_prefix#Software
> > 
> You realise that almost none of those are outside of the FLOSS world, or
> anywhere else that the user may have come across before?

That may reflect the attention to standards given in the FLOSS
community, or the prevalence of FLOSS folks among wikipedia editors,
or something else.  But I'm glad and proud to see FLOSS documented as
using good standards.

> > > Ubuntu policy is to use the prefix and factor that matches a user's
> > > expectation based on their purchase.
> > 
> > Abandoning sensible international standards, and basing our software
> > instead on the whims of marketing people writing advertising copy for
> > packaging, which varies by manufacturer and time and culture, will
> > cause us much chaos.
> > 
> The great thing about standards is that there as so many to choose from.
> One standard defines 1024 bytes as a kibibyte (the IEC one) and another
> as 1.024 kilobytes (the ATAPI one).

Yeah - don't I know it :)  That is indeed a problem.  But that
inconsistency seems to be on the decline in recent years.

> My only and overriding concern is that if a user buys something that
> says "80 GB" on the box, then Ubuntu says "80 GB" when asked about it.
> 
> Not "74 GiB", not "74 GB" and not "80 GiB".

But of course we have no way to control that, given the vagarities of
marketing departments, which as you point out are changing their minds
about hard disk marketing these days.

> > It is much more important that the ubuntu user not get confused about
> > internal inconsistencies, and e.g. misconfigure their backups or swap
> > space.
> > 
> > Users will encounter a discrepancy between a quoted size on a box vs a
> > number that shows up via ifconfig only once, but if we use "Giga"
> > inconsistently, they will have to deal with figuring out how to
> > correct for those internal inconsistencies every time they use their
> > system.
> > 
> I'm quite happy to agree on using Giga consistently to mean 1x10^9,
> however I was mindful of your comment that RAM manufacturers (and
> standards!) still build in powers of two.
> 
> I'm not sure how desirable or worrying it is for an Ubuntu machine to
> report 2.1GB of RAM when a user just bought 2GB, and it quite clearly
> said 2GB on the box.

I'm just saying it should be reported as 2 GiB, as the majority of
standards bodies suggest.  Reporting 2.1 GB is a bug.  Whether to wait
for upstream to fix the bug, or to fix it and carry a diff, will
depend on various other things.

> Though given RAM manufacturers now make disks (SSD), anyone know what
> they use? :p
> 
> Scott

Thanks, Scott!

Neal McBurnett                 http://mcburnett.org/neal/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20080924/9f07d5c8/attachment-0001.pgp