Oops, discrepancy.  Where do I edit this thing?  ;)

The GNOME Documentation Style Guide already recommends using SI units for these
sorts of things:
http://developer.gnome.org/documents/style-guide/units-2.html

Terminology in the docs is supposed to carry through to the UI too, so anything
that isn't using the right units should have a bug filed against it.  I don't
think we need to duplicate this information in the HIG.

Hi Calum,

Unfortunately, the link provided makes no explicit mention of the binary
mebibyte versus SI megabyte issue.  In fact it just leaves it to the developer
to notice.  

Without any explicit mention of the issue, it is reasonable to assume it will be
ignored.  Mebibytes and Megabytes will continue to be used interchangebly
causing the confusion it has for years.....  "How come my new 200GB hard disk
shows up as 180GB !?!?!?!  etc.

I agree it could be more explicit, but it does say that SI units should be used,
and that it just wouldn't be practical to list them all.  It would be nice to
add megabytes and gigabytes to the list, but IMHO that's a bug against the GDSG
rather than the HIG.  Unfortunately I'm not sure it's maintained at the moment,
since Eugene and Pat stopped working on it :/

I'd still prefer not to work around this in the HIG, since we should minimise
the amount of duplication between the two guides.  But cc'ing Shaun McCance for
any input, and for any insight as to how GDSG issues should be resolved going
forward.

Side note: Calum, I think a lot of developers don't read the GDSG, because they
think it doesn't apply to them.  Maybe we should split the recommended
terminology into a seperate Recommended Terminology Guide, and reference it
prominently in both the HIG and the GDSG

So I'm a big fan of using SI units and ending this confusion.  I think we could
probably make more explicit mention of the SI/binary thing to ensure that people
understand that when we say SI, we mean SI.  All the same, there are probably
places where the binary units might be useful (disk partioning tools, other
sorts of low-level hardware mangling stuff).  We could possibly recommend
showing both units when the binary unit is really needed.  Something like "10 GB
(9.31 GiB)".  And then any application that does that should put an explanatory
blurb in its help file.

Dunno, just thinking out loud.

(In reply to comment #0)
> For example:
>   in SI units,      1,000,000,000 bytes equals a 'Gigabyte'
>   in binary units,  1,073,741,824 bytes equals a binary Gigabyte, or 'Gibibyte'

Well, there are actually three different prefix conventions, not two:

Microsoft: KB  = 1,024 bytes, MB  = 1,048,576 bytes
SI:        kB  = 1,000 bytes, MB  = 1,000,000 bytes
IEC:       KiB = 1,024 bytes, MiB = 1,048,576 bytes

(note the lowercase k)

SI and IEC are both standards, are compatible with each other, and are recommended in the Linux Programmer's Manual (man 7 units), while Microsoft's convention is unknown to the Average Joe, and inconsistent with the normal everyday use of SI prefixes that he's familiar with.

The current use of MS units in Nautilus causes a lot of grief when people see different numbers in different places, fear that Linux ate some of their new hard drive's space, try to fit "4.6 GB" (actually 4.9 GB) of data on a 4.7 GB DVD, etc.

> Personally, I would prefer recommending SI units as the default since they are
> the standard human-understandable units, rather than computer-oriented binary units.

The SI and IEC conventions can be used together without conflict.  You shouldn't just blindly say "we'll just use one everywhere!"  IEC units are more appropriate for things that are inherently multiples of powers of two:

* Memory sizes (always powers of 2 due to binary addressing)
* Partition sizes (multiples of a power of 2 sector size)
* "Size on disk" for files (always a multiple of sector size)

SI units should be (and usually are) used for everything else:

* Hard disk and other media sizes (determined by surface area and density)
* File sizes (completely arbitrary)
* File transfer rates (determined by hardware and network conditions)
* Hardware bit rates, bus speeds, clock speeds (arbitrary, usually multiple of 1,000 bit/s for convenience)
* ...

So if a file manager showed size on disk, for instance (Nautilus doesn't, which is fine with me), the Properties dialog for a 7,691 byte file would say something like:

Name:         file.txt
Size:         7.7 kB (7,691 bytes)
Size on disk: 8  KiB (8,192 bytes)

The file's size is arbitrary, and should be reported in normal decimal units that people are familiar with.  The size on disk is always exactly a multiple of 512, though, so would more appropriately be reported in exact binary units.

A hard drive that can hold 160,041,885,696 bytes would be reported as "160.0 GB".  How hard is that?  :)  In Windows, on the other hand, it would show up as "149 GB" in one place and "152,628 MB" in another.  What's the benefit to the user?  It's nonsensical and useless.

This convention is already followed by a lot of FOSS software, like apt, System Monitor, GParted, Pidgin, nautilus-cd-burner, kernel boot messages, etc.  I think it should be the Official Gnome Way, too.

Is there a function in the Gnome suite of developer toolkits that takes a number in bytes and returns a string containing either the SI or IEC value, according to user preferences?  Like, for example, the hypothetical calling of write_datasize(202349593) could either return "202.34 MB" or "192.97 MiB" depending on a gconf setting.

If not, would such a function be useful?  Or is it better in this case to keep it simple?

(In reply to comment #7)
> Is there a function in the Gnome suite of developer toolkits that takes a
> number in bytes and returns a string containing either the SI or IEC value,
> according to user preferences?

I only know of g_format_size_for_display(), which uses the non-standard convention exclusively (filed as Bug 301838).

It would probably be best if it could return either of the two standard values as you described, as it seems to be used for both memory and file sizes (has been used to replace both gimp_memsize_to_string and gnome_vfs_format_file_size_for_display).

Here's a thread where the returning of dual units was previously discussed, with most supporting it:

http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00237.html

They at least agreed to change "file_size" to "size", since it can be used for memory, file, or other sizes.

I like the idea of adding an argument for binary (Ki- = 1024), but making decimal (k- = 1000) the default, since the application of binary is rare (mostly just for memory).

*** Bug 580232 has been marked as a duplicate of this bug. ***

I'm really for the adoption of binary prefixes.

Being inconsistent and keeping users constantly confused is NOT a good policy!

Now i would like to summarize some of my points, that I mentioned in the Bug 580232, which is actually duplicate of this one:

The GNOME Human Interface Guidelines should include a direction about binary
prefixes.

The current situation is quite messy. MB meaning sometimes 1000^2 and sometimes
2^20 = 1024^2 is very much confusing.
We have to face it, MX doesn't mean 2^20 * X, but 1000^2 * X, and so on...
And file size on computers is measured by the units with base of 2, not 10, not
1000.
Implementing the IEC 60027-2 standard solves the problem. It introduces the Ki,
Mi and Gi (and so on...) prefixes, which unambiguously mean 2^10, 2^20, 2^30.
Eventually, GNOME users wont' be confused anymore thus improving their user
experience on the GNOME platform.

http://en.wikipedia.org/wiki/IEC_60027
http://en.wikipedia.org/wiki/Binary_prefix#IEC_standard_prefixes

Q: Even Microsoft uses the wrong K, M and G prefixes. Why should we be
different?
A: Saying, that others do it wrong too, is not an argument. And somebody has to
be the firts to do it.

Q: It has been messy and confusing right from the beginning and everybody is
used to it anyway, so keep it that way.
A: That is very shortsighted. And there are many people out there, who aren't
used to it and are very disappointed with it or confused.

Q: When the new KiB, MiB and GiB prefixes will be introduced, won't the regular
users be confused even more, or even scared and running away from their
computers?
A: Face it, regular user isn't much a accurate reader and ie MB and MiB is
visually very similar. So if the user doesn't know what's going on, he won't
even notice. And if you know, what are you looking for, than you will know
definitely that it's MiB = 1024^2 B = 2^20 B and NOT maybe something different.

Q: Regular users don't care. And I don't care. And anyway, I'm lazy to do
anything about it.
A: Well, you really don't have to. GNOME is a volunteer project. But I'm sure
that there are some guys, that will be willing to fix this, even for just
THANKS. ;)

I suggest, that the size of measurement with base of 2 takes place everywhere and thus the binary prefixes (KiB, MiB, GiB,...) are needed.

Measurement with the base of 1000 would take place only in some exceptions:

Like identifying mass storage devices, or harddiscs. Vendors are already naming and manufacturing it that way (250GB = 250 * 1000^3 B) and it gives nicer numbers because of that, so people can easier identify their USB stick ("16 GB USB mass storage"; but when it comes to capacity, or space left on that device it would be in GiB/MiB).

Or bandwidth, if 8 Mbps really means 8 * 1000^2 bits per second.

And maybe some others...


Any suggestions, or some reaction from guys responsible for the HIG?

thanks ;)

I don't think we really need to convince people of the benefits of following standards at this point.  Ubuntu Brainstorm users strongly support using standard measurements, and oppose the "K=1024" status quo, for instance:

http://brainstorm.ubuntu.com/idea/4114/
http://brainstorm.ubuntu.com/idea/18560/

It's more a matter of *which* standard units to use in which situations:

The binary convention exists because it simplifies calculations involving multiples of powers of two.  (16 + 16 = 32 with binary units, instead of 16 + 16 = 33 with decimal.)  So when measuring memory or other numbers that are always multiples of a power of two (which is rare), we should use the binary KiB = 1024-based units.

For any number that's not inherently a power of two, though, the binary convention makes calculations *more* complex.  So for media, disk drives, file sizes, bandwidth, and pretty much everything else, we should use the decimal kB = 1000-based units that users are already familiar with.

Since the value of K is ambiguous, I think we should avoid it wherever possible.  I suggest using "thousand bytes" or "binary kibibytes" anywhere that there's enough pixels to do so.  If the term "kibibyte" is too objectionable to people, it's worth considering Knuth's "large kilobyte" suggestion[1] instead.

If there is a need to discuss multiples of 1000x1024 bytes, this approach would let us call them "Microsoft megabytes", or something similar.

Argument 1: poor understanding in the lay community

Ordinary users only have a vague understanding of what a megabyte is.  For example, my father understands that it's more than a kilobyte and less than a gigabyte, but has no idea by how much.

Even if a user does know the values of (SI) megabytes, they're not used to manipulating those numbers.  When asked "how many 4MB songs can you fit on a 4GB iPod?", I would expect the average user to take a while (and perhaps need a pencil and paper).  On the other hand, I would expect "how many 4 million byte songs can you fit on a 4 billion byte iPod?" to produce a very rapid answer.

Argument 2: ambiguity in the computing community

As mentioned above, different values of K are appropriate in different contexts.  For example, memory will continue to be counted in KiB for the foreseeable future, and it's unlikely that POSIX will be updated for this stuff any time soon.  Using "thousand bytes" or "binary kilobytes" wherever possible minimises the possibility for confusion.

Argument 3: ambiguity of "billion" etc.

It was pointed out in ubuntu-devel-discuss that "billion" is also an ambiguous word[2].  However, that ambiguity is better-understood in the lay community, and is documented clearly enough to handle through localisations.  In the event that the meaning of "billion" varies within a single locale, "IEC gigabyte" can be used in that locale.

(This post is based largely on a discussion in the ubuntu-devel-discuss ML[3])

[1] http://www-cs-staff.stanford.edu/~knuth/news99.html (scroll to the bottom of the page)
[2] http://en.wikipedia.org/wiki/Long_and_short_scales
[3] https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2009-June/008336.html)

(In reply to comment #14)
> Since the value of K is ambiguous

Capital KB.  Lowercase kB is usually 1000.  Larger prefixes are usually decimal. TB is almost always decimal, for instance, since the only things made in that size are drives, which are measured in decimal.

> If the term "kibibyte" is too objectionable to
> people, it's worth considering Knuth's "large kilobyte" suggestion[1] instead.

He abbreviated it KKB, though, whereas most people follow the KiB convention.  "kibibyte" is an abbreviation of "kilobinary byte", which is probably less objectionable if you want to write it out.  (Though the only reason people don't complain about the sound of "gigga-bite" is because they're already used to it.)

> foreseeable future, and it's unlikely that POSIX will be updated for this stuff

Where is this defined in POSIX?

> It was pointed out in ubuntu-devel-discuss that "billion" is also an ambiguous
> word[2].

Yes.  That's a very strong reason to use unambiguous SI standard prefixes instead.  This is one of the reasons why SI exists.

now we also have to decide, whether to use KiB or kiB.
i would suggest KiB as it's so on wikipedia too.
http://en.wikipedia.org/wiki/Binary_prefix

(In reply to comment #15)
> Capital KB.  Lowercase kB is usually 1000.  Larger prefixes are usually
> decimal. TB is almost always decimal, for instance, since the only things made
> in that size are drives, which are measured in decimal.

Yes, you're right that "k" is a special case, and that authors usually use "T" and up in the SI sense today.

On the other hand, I'm not comfortable relying on that remaining unambiguous in the future.  I would never have believed 10 years ago that I'd get a computer with a gigabyte of main memory, and the next decade could be just as remarkable.

> He abbreviated it KKB, though, whereas most people follow the KiB convention. 
> "kibibyte" is an abbreviation of "kilobinary byte", which is probably less
> objectionable if you want to write it out.  (Though the only reason people
> don't complain about the sound of "gigga-bite" is because they're already used
> to it.)

I wasn't clear before - I'm not necessarily advocating "large kilobyte", just pointing out the option if people really object to kibibyte.  However, you make a good point that "large kilobyte" should be paired with "KKB" rather than "KiB".

> > foreseeable future, and it's unlikely that POSIX will be updated for this stuff
> 
> Where is this defined in POSIX?

I have to admit that I don't actually have a POSIX spec, but my understanding is that, for example, the '-k' option to 'du' is defined in POSIX to mean using 1024-byte blocks.  To match up with SI usage, this would have to be changed to 1000 (no doubt breaking many scripts), or deprecated in favour of '-K' or '--ki'.

> Yes.  That's a very strong reason to use unambiguous SI standard prefixes
> instead.  This is one of the reasons why SI exists.

If everyone agreed on a single meaning for the SI prefixes, I'd completely agree. But as I've said, the computing community has at least two and the lay community has less than one.  Therefore, it's better to explain what we mean by referring to the de facto standard with well-understood, well-enforced ambiguities that can be handled through locales.

i think, that the only way how to avoid unambiguity, is to use binary prefixes where possible (Ki-, Mi-,...). Because when one sees them, he can be sure, that we mean measuring of by the power of 2 (2^10, 2^20,...). and in special cases, we would use SI prefixes, ie storage devices, where it's common vendors' policy, and even then user can be sure, what we mean - measurement by power of 10 (8GB USB stick = 10^9 Bytes capacity) - because else we would use binary prefix - 7.45GiB USB stick (i hope that 8GB == 7.45...GiB)

I have created a wiki page concerned about this topic: http://live.gnome.org/BinaryPrefixes

please, feel free to edit this page and to add your ideas and comments.

(In reply to comment #17)
> On the other hand, I'm not comfortable relying on that remaining unambiguous in
> the future.  I would never have believed 10 years ago that I'd get a computer
> with a gigabyte of main memory, and the next decade could be just as
> remarkable.

It will remain unambiguous if we use it unambiguously, following the standards.

> I wasn't clear before - I'm not necessarily advocating "large kilobyte", just
> pointing out the option if people really object to kibibyte.

Right, I'm just pointing out the option of "kilobinary byte" from the IEC spec
as an alternative.

> but my understanding
> is that, for example, the '-k' option to 'du' is defined in POSIX to mean using
> 1024-byte blocks.  To match up with SI usage, this would have to be changed to
> 1000 (no doubt breaking many scripts), or deprecated in favour of '-K' or
> '--ki'.

I don't see any reason to change command line tools.  They already support --si
for SI measurements.  The fact that they measure in binary by default and
happen to assign this to the -k option (as opposed to -q or -3) is pretty
irrelevant.

This is about the Gnome desktop, anyway, not the GNU command line tools.  The
units used should be appropriate for end user purposes.

> If everyone agreed on a single meaning for the SI prefixes, I'd completely
> agree.

Everyone *has* agreed on a single meaning for the SI prefixes.

(In reply to comment #18)
> i think, that the only way how to avoid unambiguity, is to use binary prefixes
> where possible (Ki-, Mi-,...).

Why make things more difficult than they need to be?  Ki- is unnatural to
users, and should only be used in cases where it fits and makes calculations
simpler.  This is only the case when the quantity being measured always
naturally appears in multiples of 1024/512 bytes.  For anything else, it's
inappropriate and confusing.  It should definitely not be used for drive sizes
or file sizes.

> Why make things more difficult than they need to be?  Ki- is unnatural to
users, and should only be used in cases where it fits and makes calculations
simpler.  This is only the case when the quantity being measured always
naturally appears in multiples of 1024/512 bytes.  For anything else, it's
inappropriate and confusing.  It should definitely not be used for drive sizes
or file sizes.

it makes thing almost nothing more difficult. MB and MiB is visually VERY  similar, so regular users won't even notice, and educated ones will know definitely what you mean. and it's a widespread common to measure things by the power of 2 (= in KiB, MiB,...) almost everywhere, it's just wrongly named kB, MB. So what we should just do, is put the letter 'i' between 'M' and 'B' so that it is named in a right, unambiguous way.

it's simply so, that k = 10^3, M = 10^6, Ki = 2^10, Mi = 2^20. And changing the manner of measuring things suddenly from power of 2 to power of 10 doesn't seem to me as a right way.

btw take a look at the wiki.

(In reply to comment #21)
> it makes thing almost nothing more difficult. MB and MiB is visually VERY 
> similar, so regular users won't even notice,

It's not about visual similarity, it's about the units themselves.  This would make things inconsistent and confusing just for the sake of compatibility with the way *some* software historically does it.

Almost everything is traditionally measured in decimal.  The exceptions are memory (where binary makes more sense) and file sizes.  For file sizes, it does not make any sense to measure in binary.  This is just a historical aberration that we should abandon.  Files can be any arbitrary size, not multiples of 1024, so why show them as multiples of 1024?  You store files on a disk, which is always measured in decimal, so why show the files using a different convention?  This is why we get all these complaints like "Why can't I fit any more than 4.2 GB of data on my 4.7 GB DVD??"

The only reason the binary convention exists is to make calculations with multiples of 1024 simpler.  Instead of 16,384 byte (16 kB) + 16,384 byte (16 kB) = 32,768 byte (33 kB), you just have to add 16.0 KiB + 16.0 KiB = 32.0 KiB.  It makes these calculations simpler.

Files are not multiples of 1024, though.  If your files are 23,823 B and 85,295 B, converting them to a multiple of 1024 first is needlessly complex.  It should just be simple like 23.8 kB + 85.3 kB = 109.1 kB.

i completely agree with you that deprecating measuring everything (except memory) by the power of 2 and use the measuring by the power of 10 would  solve the problem. However:

1) it would need a lot of changes in the GNOME infrastructure. and what more, this is bug on GNOME HIG. Putting the letter 'i' into the unit name seems to me easier. And the result is the same - proper measuring/naming.

2) and except storage device naming and bandwidth (which is more profitable for vendors and ISPs) EVERYBODY in EVERYTHING uses measuring by the power of 2 (they just name the unit incorrectly) - filesize, space left on device and file transfer rate... and I don't see much benefit for GNOME to be one exception - for the user it would be more confusing than the letter 'i' in the unit name.

The situation is so, that things are measured in a power of 2 manner, however prefixes are wrongly used in a way, as if k were 1,024, M were 1,048,576 and so on, which is NOT. k = 1,000, M = 1,000,000...

So now we stand between two options:

A: keep the power of 2 measuring and adopt new unit names - IEC KiB, MiB,...
if GNOME would be compared to other platforms (KDE, Windows, MacOS X,...) the numbers would be the same, only unit names would be slightly different, that someone wouldn't even notice.

it's much easier to apply.

B: keep current unit names and adopt new way of measuring - by the power of 10. when compared to other platforms, the unit names would be identical, but numbers would be different.

this would be much more confusing for users and requires deeper changes in GNOME.


I think option A is much much better...

(In reply to comment #20)
> Everyone *has* agreed on a single meaning for the SI prefixes.

I think this is the crux of our disagreement.  Unfortunately it's a question of evidence, so I can only gesture in the direction of an argument.

Try asking non-technical friends how many megabytes there are in a gigabyte.  I've asked three people since I started posting in this thread, and none could even venture an answer.  That suggests to me there's no consensus in the lay community.

Also, have a look at bug #554172 in this bugzilla.  That documents several contradictory uses of prefixes currently in use.  That suggests to me there's no consensus in the computing community.



There's also another issue with transitioning directly to SI units: if application version N reports the size of a file as "1 GB", but version N+1 reports the size as "1.1 GB", then users will be confused and think it's a bug.  Some users will likely report bugs complaining about file corruption.

Users would have a chance of understaning if it went "1 GB" -> "1 GiB" -> "1.1 GB".  They would also have a chance if it went "1 GB" -> "1.1 billion bytes".

(In reply to comment #23)
> 2) and except storage device naming and bandwidth (which is more profitable for
> vendors and ISPs) EVERYBODY in EVERYTHING uses measuring by the power of 2

Really?  Why do you say that?  megabytes, megabits per second, megahertz, megapixels, megawatts, they all mean 1,000,000 with very few exceptions (namely, memory and file sizes in Windows).  For memory, we can use IEC units.  For file sizes, we can use decimal so it's consistent with everything else.

Most other things have always been decimal.  When you download a package with apt, it reports the size in decimal.  When you boot into Linux, it reports the size of your hard drive in decimal.  When you use networking tools, they report bandwidths in decimal.  Your processor speed is always measured in decimal.  When you partition your disk with fdisk, cfdisk, parted, etc. you are working in decimal.

(In reply to comment #24)
> I think this is the crux of our disagreement.  Unfortunately it's a question of
> evidence, so I can only gesture in the direction of an argument.

I'm just saying that these prefixes have only one real meaning.  That some software uses them incorrectly doesn't change the meaning of the prefixes.

> Try asking non-technical friends how many megabytes there are in a gigabyte. 

Try asking them how many grams there are in a kilogram, or meters in a kilometer, or pixels in a megapixel.  These prefixes have standard values that many users are already familiar with, especially in metric countries (anywhere other than the US).

> I've asked three people since I started posting in this thread, and none could
> even venture an answer.  That suggests to me there's no consensus in the lay
> community.

Then there is no merit to the argument that users will be any more confused by a change from the way things are.  :)  I also think this demonstrates the inherent difficulty of working with multiples of 1024 for arbitrary measurements, and the unwillingness of the user to learn it (since it doesn't serve any logical purpose anyway).

> There's also another issue with transitioning directly to SI units: if
> application version N reports the size of a file as "1 GB", but version N+1
> reports the size as "1.1 GB", then users will be confused and think it's a bug.

Sure, but they already do, because of the developers who insist on measuring things the wrong way, purely because it's what they're used to.  

But you're going to get complaints and bug reports no matter what you do.  If you report the disk in decimal and the files in binary, you'll get "Why can't I fit all these files on the disk??" complaints:

http://discussions.apple.com/thread.jspa?threadID=1541298
http://www.velocityreviews.com/forums/t269004-cant-fit-47gb-on-dvdr-using-oem-nero-6.html

If you report the disk in binary, you'll get "Why isn't my disk recognized correctly??" complaints:

http://forums.macrumors.com/showthread.php?t=219392
http://forums.cnet.com/5208-7588_102-0.html?threadID=123636

And if you report the files in decimal, things will be easier to calculate, but you'll get complaints from the people who think that binary is the One True Way to measure files, just because that's what MS-DOS did.  You can't win.  :)

I think there are two principles here we can all agree on:

1) Users should be able to do basic maths on any set of sizes
2) Users want to see the units in Linux that are displayed on the box/in Windows

In order for (1) to work, the following conditions need to be met:

a) Units must have a consistent meaning
b) Units must be well understood by users
c) If at all possible, the same unit should be used everywhere

In order for (2) to work, the following conditions need to be met:

a) Units should be used inconsistently
b) If units are used consistently, different units must be used in different places

Clearly, squaring this circle is no easy task :)

It seems like we basically know where users want specific unit measurements (disk sizes, memory).  So I suggest GNOME pick one standard unit and display legacy units where space allows.

So if we choose to measure things in multiples of 1,000, your memory might be shown as:

"537 MB (= 512 MiB)"

Or if we choose to measure things in multiples of 1,024, your disk might be shown as:

"512 GiB (= 550 GB)"

Or if we choose to measure things in millions and billions, they would be:

"537 million bytes (= 512 MiB)"
and
"550 billion bytes (= 550 GB)"

Where the legacy usage is the same as the official usage, no equivalent would be displayed.  So files would just be "XX MB", "YY MiB", or "ZZ million bytes".

By displaying legacy measures where necessary, we clue users in to what's going on.  Hopefully this will let them understand before they start badmouthing Linux on forums :)

Please, this is a bug report. It is not a debate forum. The bug report should be kept short, sticking to the facts and *specific*. Never reiterate what has already been said.

Much of the above discussion would have been much better suited on a forum or a mailing list, instead of ruining a bug report by making it almost impossible to follow.

Adding Bugzilla tip for comment 27 to make this explicit.

(In reply to comment #27)
> Much of the above discussion would have been much better suited on a forum or a
> mailing list, instead of ruining a bug report by making it almost impossible to
> follow.

What is there to follow other than the discussion?

This bug is about creating a standard for use of storage units in the HIG.  Seems like it would be legitimate to discuss it here, regardless of the way some people think bug report comments should be used.

People use bug comments for discussion.  Instead of trying to change human behavior over and over again in every bug report, try to change the bug reporting system to handle this human behavior better.

(In reply to comment #26)
> 2) Users want to see the units in Linux that are displayed on the box/in
> Windows

I don't want to. :)  Windows use of units makes no sense.

Don't ignore the Bugzilla Tip please, especially as it reflects GNOME developers and the maintainers of Bugzilla. It has and will lead to the disabling of accounts.

Could somebody suggest a specific forum or mailing list in which to discuss how to resolve this bug?  The results of that discussion can then be presented here.

Normally I would mark an newer bugs with fewer comments as a duplicate, but in this case the newer bug seems like a better place to start a conversation about fixing this.

*** This bug has been marked as a duplicate of bug 654996 ***