Ubuntu units policy

We finally have an units policy in Ubuntu. I started to work on this issue over a year ago. The first step was to talk to other people (Ubuntu developers and upstream), but the opinions diverged. Neither a consensus was found, nor any result came out of it (except heated discussions). Upstream was not willing to change anything. It was time to contact the Technical Board to get a decision for Ubuntu.

Now we have the policy and we can start filing bug reports and fixing them without discussions about the reasonability of the patches. Let’s get Ubuntu 10.04 (lucid) in shape!

21 thoughts on “Ubuntu units policy

  1. Thank you so much for working on this. This has been bothering the **** out of me, the way how we coders consistently get this wrong, pushing legacy conventions we ourselves are used to on the rest of the unsuspecting world.

    Will there be a LP tag or similar to track affected bugs ?

      • “units-policy” sounds fine, “consistent-units” would be another possibility. Does LP require to register the tags somewhere first ? I think it doesn’t.

    • pixelpapst,

      We (developers) have supposedly got this wrong for about 60 years now. Most people in industrialized countries that even know what a kB is know it is not based on base 10 measurements.

      However I do agree that putting them both (base 2 and base 10) in the application to appease the hard drive manufacturers is probably a good thing.

      Responding to the comment about the Intel SSD. It probably actually has a base 2 size of flash internally but that is hidden from the user as most SSD have a large chunk of internal reserved space and they only expose a portion of it. In this case 64GB (base 10).

      • And using MiB instead of MB but consistently throughout all applications would be very unlikely to upset anyone, even old developers stuck in their ways. The current mixture of base 2 and base 10 using the same prefixes is insanity.

      • The thing is, “Most people in industrialized countries that even know what a kB is” is not a good group to optimize for, because the majority of people (industrialized countried and world-wide) are just plainly confused about it as is.
        Seeing how long the “imperial units” are sticking around in the US, I have no illusions that the base-2 units will vanish overnight. But at least there’s a clear, non-ambiguous labelling now available (IEC), for people who do care to learn it.
        The policy gets it right: use base-10 except for RAM sizes (where it’s used so much we’ll take longer to phase it out). And for file sizes, if there happens to be a strong backlash against “show base-10” and “show both”, we can still create a GConf option later. Personally I think “show base 10, and in the file details screen show both” should be entirely verbose enough.

        @overbenny: do you have a pointer to the discussion with debian’s tech-ctte ? I wasn’t able to find it.

  2. Hard drives should default to base 10, but solid state drives like my Intel X-25M SSD should default to base 2.

    • No, the SSD should default to base 10, too. Intel uses 1 GB = 1,000,000,000 Byte for the X-25M SSDs (according to their datasheet). My SSD has a capacity of 64 GB (not 64 GiB).

      • Most SSDs use memory chips which are most likely base 2 sized, however there is often a huge amount of reserve space and using base 10 for SSDs allows them to have ~ 4.5GiB of that reserve space without consumers even realizing it. I have heard of drives having more than 16GB of reserve space, for example a 48GB drive that actually had 64GB of flash.

        64 GiB = 68719476736
        64 GB = 64000000000

  3. This is excellent news! Thanks for your help in getting it done.

    There will be some resistance at first, but they’ll see the light eventually.

    It’s important that everything be fixed as quickly as possible, though, or there will be more confusion as the sizes conflict from one app to the next. They already do conflict, of course, but if things are changing people will be more apt to notice. 😉

  4. Thanks for getting this done, and congratulations on getting it to be policy.

    The idea that humans must perpetually be inconvenienced with a weird system of units that’s contrary to what they’re used to in the rest of their life (and to the SI standards), just because of some historical mistakes involving abuse of terminology in the 1970s, was always absurd.

    [My further hope is that the ugliness of the kibi/mebi/gibi prefixes will convince people to abandon the unwieldy and inconvenient powers-of-1024 system altogether — who really liked seeing 4817233 bytes and being unable to figure out without a calculator how many megabytes it is? With the 1000000-byte definition it’s just 4.81 MB, but with the engineers’ definition it was 4.59 “MB”. But let’s see.]

    Is there something users or programmers not deeply involved with Ubuntu can do to help, e.g. by submitting patches for applications that are showing units incorrectly?

  5. Was this policy actually implemented in Ubuntu 10.10?

    I’m using version 10.10, installed with Wubi. As far as I can see, file sizes in the file manager are still given according to the non-SI conversion 1 MB = 1024 kB, 1 kB = 1024 B, …

    • Ubuntu contains code from many upstream projects (in this case GNOME is the key upstream project). Either we convince upstream (GNOME) to do the change or we carry patches. The former is preferred, but that’s not easy (no responses or bikeshed discussions).

Comments are closed.