Ubuntu Policy: prefixes for multiples of units

Neal McBurnett neal at bcn.boulder.co.us
Wed Sep 24 19:16:37 BST 2008

On Wed, Sep 24, 2008 at 06:26:12PM +0100, Scott James Remnant wrote:
> We've had an unofficial policy about this for a while now, but since we
> have the Ubuntu Policy manual
> <http://people.ubuntu.com/~cjwatson/ubuntu-policy/> I'd like to make
> this more official by including it there.

I've never heard of this sort of unofficial policy - where has it been

> First we should have the discussion.

Note the existing discussions: 

> When displaying large values of units such as bytes, it is common
> practice to round those units up to a larger multiple.
> While neither bytes nor bits are recognised by Le Système International
> d'Unités (SI), it has been standard industry practice to use their
> prefixes for multiples.  Ubuntu may use these prefixes.
> Thus we have the industry terms:
> 	kilobyte	kB		kilobit		kb
> 	megabyte	MB		megabit		Mb
> 	gigabyte	GB		gigabit		Gb
> 	terabyte	TB		terabit		Tb
> And so on into the future for peta(P), exa(E), zetta(Z) and yotta(Y).
> Despite being valid, the deca(da) and hecto(h) mutlipliers are largely
> unknown, so must not be used in Ubuntu.

These of course originated in true international standards - the SI or
International System of Units or Metric System, which are of course
used by industry also.


> 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.

> 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:


> 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.

> Until such time that a user would be able to walk into a store, and the
> majority of hardware that they might buy is labelled in IEC prefixes
> (500gibibyte hard-drive, etc.), Ubuntu must not use these prefixes.

How would we even research what is used on boxes for memory, hard
disks, modems etc?  And you propose that when that is true, we rip out
the patches where we differ from debian on this issue?  That is
backwards and will cause yet more headaches.

It is much more important that the ubuntu user not get confused about
internal inconsistencies, and e.g. misconfigure their backups or swap

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

> Since the standard prefixes used by the industry remain SI prefixes,
> Ubuntu must use these prefixes.

It makes much more sense for Ubuntu to promote the use of the binary
prefixes when that is what the software is in fact calculating.

> Despite common belief, in general the industry (largely thanks to its
> marketing department) has actually settled on factors of powers of ten
> for these prefixes.  (What was an 80GB drive may now be sold as an 85GB
> drive.)
> In particular, the following multiples must always use powers of ten as
> their factor:
>  * Disk and partition sizes, space used and remaining.
>  * File sizes.
>  * Bandwidth and transfer rates.
>  * Data transfer totals.
> Since RAM manufactures still quote sizes using powers of two as their
> factor, the following multiples must also match:
>  * Available, used and free RAM and swap.
>  * Sizes of software and files in memory.

RAM memory is of course always made in round binary multiples.  The
industry has been slow to adopt binary prefixes here, but even the
JEDEC notes that 'IEEE/ASTM SI 10-1997 states "This practice
frequently leads to confusion and is deprecated."'

> Where confusion could be caused, such as the swap partition, the most
> appropriate factor for the circumstance may be used, provided it is made
> clear what kind of unit is being entered.

A policy to promote inconsistency like this would be a huge step backwards.

Reporting quantities using different units, labelled the same, for
different media for for size vs bandwidth is terribly confusing and
broken, since it means normal arithmetic doesn't work.  This will get
worse over time as Moore's law widens the gap between decimal
multiples and binary multiples for systems of a given cost.

> For example, when creating a swap partition, we may ask the user for the
> size of the partition (power of ten) or the size of virtual swap memory
> (power of two).
> Scott
> -- 
> Scott James Remnant
> scott at canonical.com

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/cd8d1ea4/attachment.pgp 

More information about the ubuntu-devel mailing list