Re: Using standardized SI prefixes

[Hamish Moffatt]

On Thu, Jun 21, 2007 at 05:29:47PM -0400, Ivan Jager wrote:
> On Thu, 21 Jun 2007, Hamish Moffatt wrote:
> >On Wed, Jun 20, 2007 at 08:11:23PM -0400, Ivan Jager wrote:
> >You seem to claim that binary units (ie powers of 2) are natural
> >everywhere related to computers, but I disagree.
> 
> Not everywhere related to computers. Only when the unit is bytes.

Wow, what a concession!

> >It's natural for
> >memory and structures like it, but not for bitstream quantities like
> >network traffic.
> 
> Yes, for network traffic both are just as natural.

Except that our decimal prefixes (10^N) are part of our language and
therefore win by default.

> >Most NAND FLASH chips have 2062 byte
> >blocks, which even throws the memory device argument out the window.
> 
> I have no idea about this, but I would expect
> http://www.google.com/search?hl=en&q=2062+flash+nand&btnG=Search
> to have more results where the 2062 is a block size...

Sorry, I meant 2112.

> You forgot about ECC SDRAM which is 72 bits wide. So when you buy a 1GB 
> (72x128M)  DIMM, you're actually getting 1207959552 bytes of raw storage.

Actually the controllers don't memory-map the extra 8 bits per 64. The
existence of the extra bits is totally hidden between the RAM and the
controller.

For NAND flash however the whole 2112 byte blocks are memory mapped.
After every 2112 bytes there's a gap until the next 4K boundary.

> But even then, the powers of two are more natural than the powers of 10.

Yes for memory structures, I agree. You failed to address my point about
bitstream quantities like network traffic.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Russell Coker]

On Friday 22 June 2007 07:29, Ivan Jager <[EMAIL PROTECTED]> wrote:
> > CD-ROMs have 2304 byte raw sectors.
>
> 2048 + 256 for ECC, both of which are powers of two. Even if you use the
> 2304 raw bytes, that is a multiple of 2^8 bytes, and not even divisible by
> 10^1.

Powers of 2 are everywhere.  I have 8+2 toes, both of which are powers of two.  
How did humans even start counting in base 10 when it's obvious that there 
are 8+2 digits to count with (and that's both powers of 2).  :-#

-- 
[EMAIL PROTECTED]
http://etbe.coker.com.au/  My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Hamish Moffatt]

On Thu, Jun 21, 2007 at 09:32:09AM +0200, Adam Borowski wrote:
> On Thu, Jun 21, 2007 at 01:11:52PM +1000, Hamish Moffatt wrote:
> > I think Ben's point is that we don't know.
> > 
> > You seem to claim that binary units (ie powers of 2) are natural
> > everywhere related to computers, but I disagree. It's natural for
> > memory and structures like it, but not for bitstream quantities like
> > network traffic. 
> 
> But they don't use powers of 10 any more than they do powers of 10.  While
> bps speeds are an oft-quoted case that "always" use powers of 10, the
> connection I got here is guaranteed min=max 1Mbps which as far as I can
> measure it goes right at 1048576 bits per second, rain or sleet.
> And the ISP is one of the most despicable, cheating, greedy ones you can
> imagine -- for example our company pays for that 1Mbps more than in a
> civilised place you would pay for 100Mbps, so if they seen a place to
> overadvertise something, they would.
> 
> And as far as I know, usually 1Mbps stands for 1024x1000 bits where network
> speeds are concerned, to be wrong by both the correct and yours
> interpretation :p

The raw network transports (eg Ethernet and SONET) *are* quoted in powers
of 10, and they mean it. Gigabit ethernet is really a billion bits
(10^9) per second. OC-3 is really 155,520,000 bits per second.

Powers of 10 are perfectly natural in this case (imho). They are what we
humans are used to as the default. For computer memory structures where
an N bit address bus means you have 2^N bits of storage, powers of 2
make some sense, but not in the general case.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Ivan Jager]

On Thu, 21 Jun 2007, Hamish Moffatt wrote:


On Wed, Jun 20, 2007 at 08:11:23PM -0400, Ivan Jager wrote:

On Wed, 20 Jun 2007, Ben Finney wrote:

The problem is that *many* cases are incorrect; we can't say that
*all* of them are. That uncertainty is not amenable to a mindless text
substitution without judgement of each case. The solution can only be
for humans to find those cases where the units presented do not match
the quantities, and to file bugs against those packages asking for the
mistake to be corrected.


The other solution can be for humans to find those few (if any) packages
that say MB when they mean 1,000,000 and fix only those. Then we'd have a
consistent system conforming to the standards most CS people expect.

How many packages can you name that measure bytes in powers of 10? Are
there any? People tell me I am making an argument from ignorance, and that


I think Ben's point is that we don't know.

You seem to claim that binary units (ie powers of 2) are natural
everywhere related to computers, but I disagree.


Not everywhere related to computers. Only when the unit is bytes.


It's natural for
memory and structures like it, but not for bitstream quantities like
network traffic.


Yes, for network traffic both are just as natural.


Hard disks are different again; I don't know that there is any particular
reason for them to have 2^n byte sectors (and at the hardware level perhaps
they don't).


Page sizes are powers of two. Filesystem block sizes are multiples of the 
sector sizes, and it's very convenient when they can be aranged nicely in 
pages.



CD-ROMs have 2304 byte raw sectors.


2048 + 256 for ECC, both of which are powers of two. Even if you use the 
2304 raw bytes, that is a multiple of 2^8 bytes, and not even divisible by 
10^1.



Most NAND FLASH chips have 2062 byte
blocks, which even throws the memory device argument out the window.


I have no idea about this, but I would expect
http://www.google.com/search?hl=en&q=2062+flash+nand&btnG=Search
to have more results where the 2062 is a block size...

You forgot about ECC SDRAM which is 72 bits wide. So when you buy a 1GB 
(72x128M)  DIMM, you're actually getting 1207959552 bytes of raw storage.


But even then, the powers of two are more natural than the powers of 10.

Ivan


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RE: Using standardized SI prefixes

[General]

Dear Friends and colleagues,

I am a newbie on this list and Linux but an oldie when it comes to IT
industry. 

Can i highlight that the main attraction of ubuntu amongst all other Linux
derivates is its accessibility to end users. For this feature to continue to
flourish it is best if everything from the bottom up is standardise towards
the final goal of presenting it to the ordinary end user.

In today's world unfortunately presentation does matter a great deal more
than its worth, but that is the reality.


Kind Regards


Farjad
http://www.checknetworks.com


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Sam
Morris
Sent: Thursday, June 21, 2007 2:27 AM
To: [EMAIL PROTECTED]
Cc: debian-devel@lists.debian.org
Subject: Re: Using standardized SI prefixes

On Wed, 20 Jun 2007 20:11:23 -0400, Ivan Jager wrote:

> How many packages can you name that measure bytes in powers of 10? Are
> there any?

debian-installer does so (unless you are creating LVM Logical Volumes, in 
which case the units that you specify volume sizes in are base-2, but the 
units that volume sizes are displayed in remain baase-10)... :)

-- 
Sam Morris
http://robots.org.uk/

PGP key id 1024D/5EA01078
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078


-- 
Ubuntu-devel-discuss mailing list
[EMAIL PROTECTED]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Adam Borowski]

On Thu, Jun 21, 2007 at 01:11:52PM +1000, Hamish Moffatt wrote:
> I think Ben's point is that we don't know.
> 
> You seem to claim that binary units (ie powers of 2) are natural
> everywhere related to computers, but I disagree. It's natural for
> memory and structures like it, but not for bitstream quantities like
> network traffic. 

But they don't use powers of 10 any more than they do powers of 10.  While
bps speeds are an oft-quoted case that "always" use powers of 10, the
connection I got here is guaranteed min=max 1Mbps which as far as I can
measure it goes right at 1048576 bits per second, rain or sleet.
And the ISP is one of the most despicable, cheating, greedy ones you can
imagine -- for example our company pays for that 1Mbps more than in a
civilised place you would pay for 100Mbps, so if they seen a place to
overadvertise something, they would.

And as far as I know, usually 1Mbps stands for 1024x1000 bits where network
speeds are concerned, to be wrong by both the correct and yours
interpretation :p

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Hamish Moffatt]

On Wed, Jun 20, 2007 at 08:11:23PM -0400, Ivan Jager wrote:
> On Wed, 20 Jun 2007, Ben Finney wrote:
> >The problem is that *many* cases are incorrect; we can't say that
> >*all* of them are. That uncertainty is not amenable to a mindless text
> >substitution without judgement of each case. The solution can only be
> >for humans to find those cases where the units presented do not match
> >the quantities, and to file bugs against those packages asking for the
> >mistake to be corrected.
> 
> The other solution can be for humans to find those few (if any) packages 
> that say MB when they mean 1,000,000 and fix only those. Then we'd have a 
> consistent system conforming to the standards most CS people expect.
> 
> How many packages can you name that measure bytes in powers of 10? Are 
> there any? People tell me I am making an argument from ignorance, and that 

I think Ben's point is that we don't know.

You seem to claim that binary units (ie powers of 2) are natural
everywhere related to computers, but I disagree. It's natural for
memory and structures like it, but not for bitstream quantities like
network traffic. 

Hard disks are different again; I don't know that there is any particular 
reason for them to have 2^n byte sectors (and at the hardware level perhaps 
they don't).

CD-ROMs have 2304 byte raw sectors. Most NAND FLASH chips have 2062 byte
blocks, which even throws the memory device argument out the window.



Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Sam Morris]

On Wed, 20 Jun 2007 20:11:23 -0400, Ivan Jager wrote:

> How many packages can you name that measure bytes in powers of 10? Are
> there any?

debian-installer does so (unless you are creating LVM Logical Volumes, in 
which case the units that you specify volume sizes in are base-2, but the 
units that volume sizes are displayed in remain baase-10)... :)

-- 
Sam Morris
http://robots.org.uk/

PGP key id 1024D/5EA01078
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Ivan Jager]

On Wed, 20 Jun 2007, Ben Finney wrote:

Ivan Jager <[EMAIL PROTECTED]> writes:


Here's a shell for people who don't remember what the output of their
commands mean:

#!/bin/bash
while echo -n '$ '; read cmd line; do
man $cmd | cat;
eval $cmd "$line" | sed 's/KB/KiB/;s/MB/MiB/;s/GB/GiB/;s/TB/TiB/';
done


I'm choosing this to quote because it highlights the mistake being made.

The above assumes that this proposal is about *replacing*,
unilaterally, every instance of one text with another. This is
mistaken, because the proposal is about fixing *only* those cases
where the unit does not match the quantity. The programs which output
base-ten unit abbreviations correctly would be *broken* by the above
simple substitution.

The problem is that *many* cases are incorrect; we can't say that
*all* of them are. That uncertainty is not amenable to a mindless text
substitution without judgement of each case. The solution can only be
for humans to find those cases where the units presented do not match
the quantities, and to file bugs against those packages asking for the
mistake to be corrected.


The other solution can be for humans to find those few (if any) packages 
that say MB when they mean 1,000,000 and fix only those. Then we'd have a 
consistent system conforming to the standards most CS people expect.


How many packages can you name that measure bytes in powers of 10? Are 
there any? People tell me I am making an argument from ignorance, and that 
just because I don't know of any such packages doesn't mean they don't 
exist. Because of these packages that may or may not exist, they say we 
need to change all the other ones to avoid inconsistiencies with the 
packages we can't prove don't exist. Yey.


Well, anyways, I'm a lot less worried now that I realized that these 
bug reports get ignored and passed around for years.  At the rate things 
are going, Debian will probably be too newbie oriented for me well before 
you succeed at filling my output with "i"s. :P


Have fun,
Ivan


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Wesley J. Landaker]

On Wednesday 20 June 2007 08:28:33 Michelle Konzack wrote:
> I am sitting on my line but does this mean we sould use
>
>  2B
> k2B   => kilo Byte with power of 2
> M2B   => Mega Byte with power of 2
> G2B   => Giga Byte with power of 2
> T2B   => Tera Byte with power of 2

No, we should use kB = 1000 B and KiB = 1024 B, since that is what is 
actually standardized. k2B and friends were an example of how some people 
avoided misusing standard prefixes (i.e. not using kB for 1024), by making 
up non-standard ones that did made some sense. There have been lots of 
schemes like that over the years.

If it were k2B that were standardized instead of KiB, I'd be pushing to use 
that instead, but that's not the case. =)

-- 
Wesley J. Landaker <[EMAIL PROTECTED]> 
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2


signature.asc
Description: This is a digitally signed message part.

Re: Using standardized SI prefixes

[Eduard Bloch]

#include 
* Ivan Jager [Tue, Jun 19 2007, 06:39:24PM]:

> >>It's not that I can't *think* of any problems. It's that I, like several
> >>other people here, I don't *have* said problems with the programs I use,
> >>and I don't particularly care to have that "fixed". Just because you can't
> >>tell whether the output of ls -lh is using binary or decimal prefixes
> >>doesn't mean it's a problem for everyone else.
> >
> >So if you know that there are problems then there is no point in 
> >argumenting
> >against the people who want to have them solved.
> 
> Umm, again I fail to follow your logic. I want to have problems solved, so 
> why are you arguing with me? Your reasoning seems to imply you think there 
> are no problems in the world.

No, it doesn't imply that. And if you cannot follow, don't put words
into my mouth.

There are simple facts which are NOT mutual exclusive: "no problems",
"problems exist", "there are no problems for me". If you try to use the
last one to support the first and you don't see a problem there even now
then I doubt I can help you with understanding.

> You're going to have some trouble convincing me of that. :)

Me? No comment.

If I missed an irony tag somewhere then it is hidden really well.

Eduard.

-- 
Die einfachsten Menschen hör ich die feinsten Vermutungen äußern, wenn
der Schritt etc. eines Gesandten, Ministers politisch zu erklären ist.
-- Jean Paul


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Michelle Konzack]

Hi Wes,

I am sitting on my line but does this mean we sould use

 2B  
k2B   => kilo Byte with power of 2
M2B   => Mega Byte with power of 2
G2B   => Giga Byte with power of 2
T2B   => Tera Byte with power of 2

?

Thanks, Greetings and nice Day
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSN LinuxMichi
0033/6/6192519367100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature

Re: Using standardized SI prefixes

[Michelle Konzack]

Am 2007-06-15 17:36:33, schrieb Ivan Jager:
> On Fri, 15 Jun 2007, [EMAIL PROTECTED] wrote:
> >Yes. But you can't infer which one (1000 or 1024) MB mean. When you buy
> >a disk, what do the vendor says the capacity is? 80 GB. But your
> >software states it is no more than 75GB. What the fuck!? If GiB is
> >confusing to users, so is base 2. People use base 10 and k (kilo) means
> >1000, M (Mega) means 10^6, G (Giga) means 10^9, etc., because they are
> >used to base 10.
> 
> How about when you buy 80 GB of RAM, and your software says you have
> 88 GB?

You are fucked too, since your 486 does
only support 67108864 Byte of ram. -- Oops!

> How about using these prefixes to unambiguously refer to powers of 10? 
> kdkidi10^3
> Mdmeda10^6
> Gdgida10^9
> Tdteda10^12
> Pdpeda10^15
> Edexda10^18
> Zdzeda10^21
> Ydyoda10^24
> 
> Come on, you know you want a yodameter. :)

ROTFL!

Thanks, Greetings and nice Day
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSN LinuxMichi
0033/6/6192519367100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature

Re: Using standardized SI prefixes

[shirish]

On Tue, 19 Jun 2007, Eduard Bloch wrote:
> #include 
> * Ivan Jager [Tue, Jun 19 2007, 03:22:10AM]:
>



>>> Sure, but it makes it possible to make it _right_ in a good portion of
>>> situations. The people who really need binary units can make clear what
>>> they are doing there. Otherwise they would deliberately create
>>> confusion. You like to be among them? You like chaos and cheating?
>>
>> No, I like to avoid chaos and confusion. I do not currently have problems
>> telling the size of a file, and adding an extra column of "i"s to the
>> output of most programs isn't going to accomplish more than cause
>> confusion for me when I use a program that doesn't waste the extra space
>> to tell me, "Oh, by the way, I'm doing the sensical thing."
>
> Really? You need additional knowledge to interpret the program output
> and you call this less confusing? I doubt that.

Yes. I don't like computers that are designed for people who don't know
anything. I find such beasts confusing and obnoxious.


Resp. Sir,
It is precisely for people who don't know anything that comps. do sell,
components sell & you have cheap prices. Again who decides who knows
anything or nothing at all? I'm sure it'll be pretty thin list if we
go by that.
Also is there something in the debian manifesto which says that people
is only for people who do computer science only?




> But they ARE broken. Have been for years. If you make a simple analogy
> from that statement to other dings then you need to declare much more
> people as stupid Don Quixotes, like those who work on LFS (you know,
> 2GiB is ought to be enough for everyone), or on IPv6, or on Unicode,
> etc.etc.

I seem to be failing to folow your logic again... Anyways, you know we've
all switched to IPv6 already, right? We no longer need 6bone because all
our ISPs give us IPv6 addresss already. See http://www.6bone.net/ if you
don't believe me. Grr.


I don't know whether that last sentence was mentioned in seriousness
or in jest.
We in India, are on ipv4 still & the transition is going to take
another couple of years till one of the big ISP's does the change. I
know this for a fact as there were press releases made by BSNL (Indian
ISP)  to that effect.
http://en.wikipedia.org/wiki/List_of_countries_by_broadband_users

But does it mean that we are against IPv6, no all we all want is it
should be pretty easy so that ipv4 can work & its documented how it is
to be done. If similarly, there was an alternative solution for the
same in the KB/KiB thing it would make easier for me as a user to
decide.



 How about using these prefixes to unambiguously refer to powers of 10?
 kd kidi10^3
>>>
>>> Like in kidigram and medameter? What comes next, midroutopicans?
>>
>> Yes, my intention was to make a silly set of prefixes whose only purpose
>
> Doesn't look so for me. It looks more like a bad attempt to miscredit
> brave people.

Yes, all those brave people who risked their lives to, uhh, very bravely
do, uhh, something, umm, what people am I trying to miscredit? I think
maybe I need to figure this out before I can figure out what brave things
they were doing. Oh, or was I trying to miscredit all brave people?

I'm sorry, but I don't think I was trying to miscredit anyone. I simply
don't want people fixing a part of my system that works exactly how I want
it, just because it is confusing to non computer people.


There you go again, who are non-computer people. I would surely be
interested to known your definition of "non-computer people" & how
they should be discriminated against, atleast that is what appears to
me.


Ivan

Ivan Jager <[EMAIL PROTECTED]> writes:



--
 Shirish Agarwal
 This email is licensed under http://creativecommons.org/licenses/by-nc/3.0/

065C 6D79 A68C E7EA 52B3  8D70 950D 53FB 729A 8B17


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Enough already - Re: Using standardized SI prefixes

[Lars Wirzenius]

Little useful or helpful has been said in this thread for a while now.
Please don't continue the discussion, at least on debian-devel.

(Sorry to be so blunt.)

-- 
Rule #13 for successful communication: don't do Latin quotations


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Ben Finney]

Ivan Jager <[EMAIL PROTECTED]> writes:

> Here's a shell for people who don't remember what the output of their
> commands mean:
>
> #!/bin/bash
> while echo -n '$ '; read cmd line; do
> man $cmd | cat;
> eval $cmd "$line" | sed 's/KB/KiB/;s/MB/MiB/;s/GB/GiB/;s/TB/TiB/';
> done

I'm choosing this to quote because it highlights the mistake being made.

The above assumes that this proposal is about *replacing*,
unilaterally, every instance of one text with another. This is
mistaken, because the proposal is about fixing *only* those cases
where the unit does not match the quantity. The programs which output
base-ten unit abbreviations correctly would be *broken* by the above
simple substitution.

The problem is that *many* cases are incorrect; we can't say that
*all* of them are. That uncertainty is not amenable to a mindless text
substitution without judgement of each case. The solution can only be
for humans to find those cases where the units presented do not match
the quantities, and to file bugs against those packages asking for the
mistake to be corrected.

-- 
 \  "I like to fill my bathtub up with water, then turn the shower |
  `\on and pretend I'm in a submarine that's been hit."  -- Steven |
_o__)   Wright |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Ivan Jager]

On Tue, 19 Jun 2007, Eduard Bloch wrote:

#include 
* Ivan Jager [Tue, Jun 19 2007, 03:22:10AM]:


Should we also add filesystem overhead to all file sizes
just to avoid confusing newbies?


Second, "du" already does that. Go figure.


No, it doesn't. It rounds up to a multiple of the block size. That only


This rounding is still overhead, so don't say "it doesn't".


But it doesn't. du does not add filesystem overhead when displaying file 
sizes. It simply rounds up to the block size. The size it adds on is 
completely independent of the filesystem overhead.



accounts for a small fraction of the filesystem overheaad. (Perhaps this
will be more obvious if you write a multiple of your blocksize to a file.)


Oh, you cannot say that easily for everyone either. Just compare an FS
with big data files with /usr/share/doc contents.


Yes, what about it? Are you trying to make a point?


Sure, but it makes it possible to make it _right_ in a good portion of
situations. The people who really need binary units can make clear what
they are doing there. Otherwise they would deliberately create
confusion. You like to be among them? You like chaos and cheating?


No, I like to avoid chaos and confusion. I do not currently have problems
telling the size of a file, and adding an extra column of "i"s to the
output of most programs isn't going to accomplish more than cause
confusion for me when I use a program that doesn't waste the extra space
to tell me, "Oh, by the way, I'm doing the sensical thing."


Really? You need additional knowledge to interpret the program output
and you call this less confusing? I doubt that.


Yes. I don't like computers that are designed for people who don't know 
anything. I find such beasts confusing and obnoxious.


Here's a shell for people who don't remember what the output of their 
commands mean:


#!/bin/bash
while echo -n '$ '; read cmd line; do
man $cmd | cat;
eval $cmd "$line" | sed 's/KB/KiB/;s/MB/MiB/;s/GB/GiB/;s/TB/TiB/'; 
done


Tell me if that isn't obnoxious to use.


And you care about waste? You waste every 8 bit right now!


Yes, and if people were trying to force me to use UTF-16 so that we could 
use a different type of whitespace to separate words that what we use to 
separate sentences, I would also be objecting.



I can't say I adhere to, "Don't fix what isn't broken," but it does kind
of bug me when people are encouranging other people to encourage yet other
people to fix things that aren't broken.


But they ARE broken. Have been for years. If you make a simple analogy
from that statement to other dings then you need to declare much more
people as stupid Don Quixotes, like those who work on LFS (you know,
2GiB is ought to be enough for everyone), or on IPv6, or on Unicode,
etc.etc.


I seem to be failing to folow your logic again... Anyways, you know we've 
all switched to IPv6 already, right? We no longer need 6bone because all 
our ISPs give us IPv6 addresss already. See http://www.6bone.net/ if you 
don't believe me. Grr.



How about using these prefixes to unambiguously refer to powers of 10?
kd  kidi10^3


Like in kidigram and medameter? What comes next, midroutopicans?


Yes, my intention was to make a silly set of prefixes whose only purpose


Doesn't look so for me. It looks more like a bad attempt to miscredit
brave people.


Yes, all those brave people who risked their lives to, uhh, very bravely 
do, uhh, something, umm, what people am I trying to miscredit? I think 
maybe I need to figure this out before I can figure out what brave things 
they were doing. Oh, or was I trying to miscredit all brave people?


I'm sorry, but I don't think I was trying to miscredit anyone. I simply 
don't want people fixing a part of my system that works exactly how I want 
it, just because it is confusing to non computer people.


Ivan


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Ivan Jager]

On Wed, 20 Jun 2007, Eduard Bloch wrote:

#include 
* Ivan Jager [Tue, Jun 19 2007, 03:39:22PM]:

On Tue, 19 Jun 2007, Magnus Holmgren wrote:

Ivan Jager wrote:

They are not strictly better. Did you not read the part where I said I
didn't want an extra column of "i"s that serves no real purpose?


Don't you read the explanation where people say which purpose it does
serve? If you cannot distinguish between a perfect solution and a good
partial solution, then you are a real victim of the "not a perfect
solution" fallacy.


Uhh, I think you mixed something up in that last sentence. Anyways, just 
because it solves one problem for some people doesn't make it strictly 
better.



It's not that I can't *think* of any problems. It's that I, like several
other people here, I don't *have* said problems with the programs I use,
and I don't particularly care to have that "fixed". Just because you can't
tell whether the output of ls -lh is using binary or decimal prefixes
doesn't mean it's a problem for everyone else.


So if you know that there are problems then there is no point in argumenting
against the people who want to have them solved.


Umm, again I fail to follow your logic. I want to have problems solved, so 
why are you arguing with me? Your reasoning seems to imply you think there 
are no problems in the world. You're going to have some trouble convincing 
me of that. :)


Ivan


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Eduard Bloch]

#include 
* Ivan Jager [Tue, Jun 19 2007, 03:39:22PM]:
> On Tue, 19 Jun 2007, Magnus Holmgren wrote:
> >Ivan Jager wrote:

> >This sounds like another "not a perfect solution" fallacy. Accurately
> >presenting the full amount of disk space a file uses is an orthogonal
> >problem that having distinct prefixes can't be expected to solve. Having
> >distinct, unambiguous prefixes is still strictly better than having
> >ambiguous prefixes.
> 
> They are not strictly better. Did you not read the part where I said I 
> didn't want an extra column of "i"s that serves no real purpose?

Don't you read the explanation where people say which purpose it does
serve? If you cannot distinguish between a perfect solution and a good
partial solution, then you are a real victim of the "not a perfect
solution" fallacy.

> >What you personally have become accustomed to is irrelevant in the big
> >picture and in the long run. That you can't think of any problems
> >doesn't mean that no problems exist
> 
> It's not that I can't *think* of any problems. It's that I, like several 
> other people here, I don't *have* said problems with the programs I use, 
> and I don't particularly care to have that "fixed". Just because you can't 
> tell whether the output of ls -lh is using binary or decimal prefixes 
> doesn't mean it's a problem for everyone else.

So if you know that there are problems then there is no point in argumenting
against the people who want to have them solved.

Eduard.
-- 
Naja, Garbage Collector eben. Holt den Müll sogar vom Himmel.
   (Heise Trollforum über Java in der Flugzeugsteuerung)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Eduard Bloch]

#include 
* Ivan Jager [Tue, Jun 19 2007, 03:22:10AM]:

> >>Should we also add filesystem overhead to all file sizes
> >>just to avoid confusing newbies?
> >
> >Second, "du" already does that. Go figure.
> 
> No, it doesn't. It rounds up to a multiple of the block size. That only 

This rounding is still overhead, so don't say "it doesn't".

> accounts for a small fraction of the filesystem overheaad. (Perhaps this 
> will be more obvious if you write a multiple of your blocksize to a file.)

Oh, you cannot say that easily for everyone either. Just compare an FS
with big data files with /usr/share/doc contents.

> >Sure, but it makes it possible to make it _right_ in a good portion of
> >situations. The people who really need binary units can make clear what
> >they are doing there. Otherwise they would deliberately create
> >confusion. You like to be among them? You like chaos and cheating?
> 
> No, I like to avoid chaos and confusion. I do not currently have problems 
> telling the size of a file, and adding an extra column of "i"s to the 
> output of most programs isn't going to accomplish more than cause 
> confusion for me when I use a program that doesn't waste the extra space 
> to tell me, "Oh, by the way, I'm doing the sensical thing."

Really? You need additional knowledge to interpret the program output
and you call this less confusing? I doubt that.

And you care about waste? You waste every 8 bit right now!

> I can't say I adhere to, "Don't fix what isn't broken," but it does kind 
> of bug me when people are encouranging other people to encourage yet other 
> people to fix things that aren't broken.

But they ARE broken. Have been for years. If you make a simple analogy
from that statement to other dings then you need to declare much more
people as stupid Don Quixotes, like those who work on LFS (you know,
2GiB is ought to be enough for everyone), or on IPv6, or on Unicode,
etc.etc.

> >>How about using these prefixes to unambiguously refer to powers of 10?
> >>kd  kidi10^3
> >
> >Like in kidigram and medameter? What comes next, midroutopicans?
> 
> Yes, my intention was to make a silly set of prefixes whose only purpose 

Doesn't look so for me. It looks more like a bad attempt to miscredit
brave people.

Eduard.
-- 
Die Menschheit besteht aus einigen wenigen Vorläufern, sehr vielen
Mitläufern und einer unübersehbaren Zahl von Nachläufern.
-- Jean Cocteau


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Ivan Jager]

On Tue, 19 Jun 2007, Magnus Holmgren wrote:

Ivan Jager wrote:

On Sat, 16 Jun 2007, Eduard Bloch wrote:

#include 
* Ivan Jager [Fri, Jun 15 2007, 05:36:33PM]:

[...]
Should we also add filesystem overhead to all file sizes
just to avoid confusing newbies?


Second, "du" already does that. Go figure.


No, it doesn't. It rounds up to a multiple of the block size. That only
accounts for a small fraction of the filesystem overheaad. (Perhaps this
will be more obvious if you write a multiple of your blocksize to a file.)


This sounds like another "not a perfect solution" fallacy. Accurately
presenting the full amount of disk space a file uses is an orthogonal
problem that having distinct prefixes can't be expected to solve. Having
distinct, unambiguous prefixes is still strictly better than having
ambiguous prefixes.


They are not strictly better. Did you not read the part where I said I 
didn't want an extra column of "i"s that serves no real purpose?



What you personally have become accustomed to is irrelevant in the big
picture and in the long run. That you can't think of any problems
doesn't mean that no problems exist


It's not that I can't *think* of any problems. It's that I, like several 
other people here, I don't *have* said problems with the programs I use, 
and I don't particularly care to have that "fixed". Just because you can't 
tell whether the output of ls -lh is using binary or decimal prefixes 
doesn't mean it's a problem for everyone else.



(http://en.wikipedia.org/wiki/Argument_from_ignorance).


Actually, it is you who can't seem to think of any problems that would 
arise from changing almost everything. (or rather, you may be choosing to 
ignore said problems.)


In addition, you seem to be trying to move the burden of proof. Why do I 
need to prove that there isn't a problem? It is those who think it needs 
changing who should be proving there is a problem and that their proposed 
change actually fixes it without introducing new problems.



That you mistake an "SI" MB for a MiB, for example, is not an argument
against consistent prefix usage. The quicker everybody stops using power
of ten prefixes incorrectly, the quicker this transitional problem goes
away.


I don't mistake an SI MB for a MiB. Our disagreement is because I don't 
mistake a non-SI MB for an SI one, and, presumably, you do. This is why 
you see the ambiguity as a serious problem and I don't.


I am not against consistent prefix usage. On the contrary, I have pointed 
out that all the programs I use consistently use MB to mean 2^20 bytes, 
and that I would rather not have this consistency broken by ever having 
one say MB when it means 10^6 bytes.


Your argment is not in favor of consistency, but rather in favor of 
explicitly indicating consistency. I would find it much less obtrusive to 
simply drop a file in / explaining that we are consistent. (But I also 
think that is unnecesary.)


Trying to adhere to what the outside world does will not make Debian 
consistent, because the outside world is not consistent.


http://foldoc.org/?query=megabyte
http://www.m-w.com/dictionary/megabyte
http://dictionary.reference.com/browse/megabyte
http://dictionary.oed.com/cgi/entry/00304795

How about using these prefixes to unambiguously refer to powers of 
10? kd kidi 10^3


Like in kidigram and medameter? What comes next, midroutopicans?


Yes, my intention was to make a silly set of prefixes whose only purpose
was to look and sound silly while disambiguating from the commonly used
ones we all know and love.


An appeal to emotions, once again.


Maybe, but it doesn't change the fact that every argument you've made in 
favor of explicit binary prefixes applies equaly well to explicit decimal 
prefixes instead. It comes with the added benefit that we'd need to file 
a lot less bug reports.


I was actually kind of playing devil's advocate there, as I was arguing in 
favor of something I don't support. The part where the appeal to emotions 
comes in is that I don't expect you to support explicit decimal prefixes 
even though they are almost strictly better than what you do support.



Having
distinct, unambiguous prefixes is still strictly better than having
ambiguous prefixes.


So, that is saying it is strictly better to use the explicit binary *and* 
explicit decimal prefixes. My argument still holds that they are not 
strictly better because they do have the disadvantage of using an 
additional character.


Ivan


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Magnus Holmgren]

Ivan Jager wrote:
> On Sat, 16 Jun 2007, Eduard Bloch wrote:
>> #include 
>> * Ivan Jager [Fri, Jun 15 2007, 05:36:33PM]:
>>> [...]
>>> Should we also add filesystem overhead to all file sizes
>>> just to avoid confusing newbies?
>>
>> Second, "du" already does that. Go figure.
> 
> No, it doesn't. It rounds up to a multiple of the block size. That only
> accounts for a small fraction of the filesystem overheaad. (Perhaps this
> will be more obvious if you write a multiple of your blocksize to a file.)

This sounds like another "not a perfect solution" fallacy. Accurately
presenting the full amount of disk space a file uses is an orthogonal
problem that having distinct prefixes can't be expected to solve. Having
 distinct, unambiguous prefixes is still strictly better than having
ambiguous prefixes.

 I don't want to read some manual or source code just to know which base
 is used when I read or write 10G. When I write, how can I unambiguously
 tell the program that I mean 1000 or 1024? Only using G and Gi, this
 would be possible.
>>>
>>> It only solves half the problem. GB is still ambiguous even if GiB
>>> isn't.
>>
>> Sure, but it makes it possible to make it _right_ in a good portion of
>> situations. The people who really need binary units can make clear what
>> they are doing there. Otherwise they would deliberately create
>> confusion. You like to be among them? You like chaos and cheating?
> 
> No, I like to avoid chaos and confusion. I do not currently have
> problems telling the size of a file, and adding an extra column of "i"s
> to the output of most programs isn't going to accomplish more than cause
> confusion for me when I use a program that doesn't waste the extra space
> to tell me, "Oh, by the way, I'm doing the sensical thing."

What you personally have become accustomed to is irrelevant in the big
picture and in the long run. That you can't think of any problems
doesn't mean that no problems exist
(http://en.wikipedia.org/wiki/Argument_from_ignorance).

That you mistake an "SI" MB for a MiB, for example, is not an argument
against consistent prefix usage. The quicker everybody stops using power
of ten prefixes incorrectly, the quicker this transitional problem goes
away.

> I can't say I adhere to, "Don't fix what isn't broken," but it does kind
> of bug me when people are encouranging other people to encourage yet
> other people to fix things that aren't broken.

But things *are* broken.

>>> How about using these prefixes to unambiguously refer to powers of 10?
>>> kdkidi10^3
>>
>> Like in kidigram and medameter? What comes next, midroutopicans?
> 
> Yes, my intention was to make a silly set of prefixes whose only purpose
> was to look and sound silly while disambiguating from the commonly used
> ones we all know and love.

An appeal to emotions, once again.

-- 
Magnus Holmgren [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Magnus Holmgren]

Ivan Jager wrote:
> I think you missed the point. The only times it is not rounded is when
> the user is specifying a size. (And even then it is sometimes rounded.)

Rounding doesn't render distinguishing between GB and GiB useless,
except perhaps in the extreme case when you're *only* interested in the
order of magnitude.

>>> I thought this argument was mostly about measured sizes anyways,
>>> such as what you would get from ls -lh, df -h, du -h, or their GUI
>>> equivalents. These are all rounded.
>>
>> Any time the software says "GB" when the quantity was actually
>> calculated in 2^30, or says "GiB" when the quantity was actually
>> calculated in 10^9, the units are mismatched. Whether the quantity was
>> rounded is irrelevant to this fact.
> 
> It was relevant enough for Alex to say sizes aren't rounded... Yes,
> accuracy, precision, and ambiguity are all separate things. Rounding is
> not completely irrelevant though, since most of the time "1 GB" is
> correct, "1 GiB" is also correct.

Again, this is an extreme example. A more average case might be "3.2
GB", which is *not* a substitute for "3.2 GiB". Do you not agree that
rounding can be done to more than one significant digit?

-- 
Magnus Holmgren


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Ivan Jager]

On Sat, 16 Jun 2007, Eduard Bloch wrote:

#include 
* Ivan Jager [Fri, Jun 15 2007, 05:36:33PM]:


How about when you buy an 80 GB disk, and you know it's 80 * 10^9 bytes,
but your software says /home only has 79 GB and you know it means
79 * 10^9 bytes?


First, it would hardly say 79GB. Maybe 79.96GB which is much closer.


Huh, I guess I just have a bigger journal than you, more inodes per byte, 
and some backup superblocks. (I use the defaults.)



Should we also add filesystem overhead to all file sizes
just to avoid confusing newbies?


Second, "du" already does that. Go figure.


No, it doesn't. It rounds up to a multiple of the block size. That only 
accounts for a small fraction of the filesystem overheaad. (Perhaps this 
will be more obvious if you write a multiple of your blocksize to a file.)



I don't want to read some manual or source code just to know which base
is used when I read or write 10G. When I write, how can I unambiguously
tell the program that I mean 1000 or 1024? Only using G and Gi, this
would be possible.


It only solves half the problem. GB is still ambiguous even if GiB isn't.


Sure, but it makes it possible to make it _right_ in a good portion of
situations. The people who really need binary units can make clear what
they are doing there. Otherwise they would deliberately create
confusion. You like to be among them? You like chaos and cheating?


No, I like to avoid chaos and confusion. I do not currently have problems 
telling the size of a file, and adding an extra column of "i"s to the 
output of most programs isn't going to accomplish more than cause 
confusion for me when I use a program that doesn't waste the extra space 
to tell me, "Oh, by the way, I'm doing the sensical thing."


I can't say I adhere to, "Don't fix what isn't broken," but it does kind 
of bug me when people are encouranging other people to encourage yet other 
people to fix things that aren't broken.



How about using these prefixes to unambiguously refer to powers of 10?
kd  kidi10^3


Like in kidigram and medameter? What comes next, midroutopicans?


Yes, my intention was to make a silly set of prefixes whose only purpose 
was to look and sound silly while disambiguating from the commonly 
used ones we all know and love.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Ivan Jager]

On Fri, 15 Jun 2007, Ben Finney wrote:

Ivan Jager <[EMAIL PROTECTED]> writes:

On Thu, 14 Jun 2007, Ben Finney wrote:


[re added the relevant quote]

The difference being that digital specifications for things like
storage capacity and memory are not measured. They are calculated, and
in those contexts they *are* precise.



Since we *can* give a perfectly precise quantity of bytes and
other digital phenomena, and often do, this is even more reason to
use the precise meaning of the units for those quantities.


Ok, so this applies to dd and what else?


It applies to any software that refers to quantities that use these
units. Pick a unit for the quantity, base-10 or base-2, and use its
precise meaning and the precise term for it.


I think you missed the point. The only times it is not rounded is when the 
user is specifying a size. (And even then it is sometimes rounded.)



I thought this argument was mostly about measured sizes anyways,
such as what you would get from ls -lh, df -h, du -h, or their GUI
equivalents. These are all rounded.


Any time the software says "GB" when the quantity was actually
calculated in 2^30, or says "GiB" when the quantity was actually
calculated in 10^9, the units are mismatched. Whether the quantity was
rounded is irrelevant to this fact.


It was relevant enough for Alex to say sizes aren't rounded... 
Yes, accuracy, precision, and ambiguity are all separate things. Rounding 
is not completely irrelevant though, since most of the time "1 GB" is 
correct, "1 GiB" is also correct.


Ivan


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Ivan Jager]

On Sat, 16 Jun 2007, Wesley J. Landaker wrote:


On Saturday 16 June 2007 04:43:53 Josselin Mouette wrote:

Le vendredi 15 juin 2007 ?? 17:36 -0400, Ivan Jager a ??crit :

Yes. Any time the unit is bytes. There is even a standard for it.


I must have missed that one. Could you point us to this standard?


I too would love to see that standard.


Ok, so it appears to be deprecated, but it does exist.

October 30, 1986 ANSI/IEEE Std 1084-1986 IEEE Standard Glossary of 
Mathematics of Computing Terminology.


http://ieeexplore.ieee.org/iel1/2485/1030/00026589.pdf?isnumber=1030&prod=&arnumber=26589&arSt=&ared=&arAuthor=

"kilo (K). (1) A prefix indicating one thousand. (2) In statements 
involving size of computer storage, a prefix indicating 2^10, or 1024."


"mega (M). (1) A prefix indicating one million. (2) In statements 
involving size of computer storage, a prefix indicating 2^20, or 
1,048,576."


Apparently back then giga wasn't ever applied to computer storage. :)

Ivan

Re: Using standardized SI prefixes

[Ben Finney]

Bastian Venthur <[EMAIL PROTECTED]> writes:

> I suggest that we prepare a wikipage on wiki.debian.org with a
> friendly formulated bugreport template. After this template is
> mature enough, we can start writing wishlist bugreports on packages
> making wrong use SI prefixes (e.g. write KB but mean KiB) asking
> them to consider to switch to binary prefixes instead.

Done, http://wiki.debian.org/ConsistentUnitPrefixes>. Please
modify the bug report as needed; currently I think it may be a bit too
wordy, but lack the skill to pare it down without losing necessary
explanation or examples.

> We should not urge to use either binary prefixes or SI prefixes
> consistently in all packages! Instead we should urge to use the
> prefixes *correctly*. When 1k means 1000 Bytes, it is OK to use it
> -- when it means 1024 they, should make the switch to binary
> prefixes.

Agreed, this is the approach I've taken in the bug report.

-- 
 \ "I have had a perfectly wonderful evening, but this wasn't it." |
  `\   -- Groucho Marx |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Magnus Holmgren]

Phillip Susi wrote:
> Christof Krüger wrote:
>> Unfortunately, computer designers, technicians etc. are not living in an
>> isolated world (well.. maybe some of them).
>> No one wants to forbid the computer people to use base 2 numbers. They
>> are just asked to write KiB instead of KB if they mean base 2
>> quantities, because the rest of the world already uses kilo as 1000.
>> Changing the rest of the world makes no sense and having distinct names
>> for distinct thing does no harm.
> 
> Different disciplines often ascribe different meanings to the same
> words, so there is no reason why the prefix "Kilo" can not mean 1024 in
> the context of computer science, so please stop complaining about that.
>  You should just learn that in this context, that is what it means.
> Always has and always will.

*Different* disciplines, yes. Here the same words are used for two
meanings in the same discipline.

The SI units and prefixes aren't just words - they have each been
constructed and assigned specific meanings in a _universal_ context.
Your analogy with the mouse fails because "mouse" is a naturally
evolved, everyday word, which has *not* been universally defined (the
well-defined, scientific term would instead be lat. _Mus_ for the genus
or _Mus musculus_ for the species known as the common house mouse).

-- 
Magnus Holmgren
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Wesley J. Landaker]

On Saturday 16 June 2007 04:43:53 Josselin Mouette wrote:
> Le vendredi 15 juin 2007 à 17:36 -0400, Ivan Jager a écrit :
> > Yes. Any time the unit is bytes. There is even a standard for it.
>
> I must have missed that one. Could you point us to this standard?

I too would love to see that standard.

Well, there is IEEE 1541, and it does mention bits and bytes. But ... oh 
wait! It also says to use binary prefixes appropriately, and that SI 
prefixes *must not* be used to indicate binary multiples. 

Then there is IEC 60027-2 ... oh, yeah, binary multiples.

There are a few others, like ASTM SI-10. They all say the same thing. SI 
prefixes always have their normal, powers of 10, meaning.

All these standards are from almost 10 years ago.

Okay, let's look at a really *old* standard, ISO 31: ah, it ALSO says SI 
prefixes *always* mean powers of ten. If you want to do powers of two, you 
are supposed to use the prefix with a subscript 2. Note that this standard 
is being revised and combined with IEC 60027 to be ISO/IEC 8, and will 
then agree with the others cited above.

So basically, IEEE, IEC, ISO, ASTM, have all standardized things, the same 
way, that SI prefixes always have their SI meaning, even in the context of 
bits and bytes. This has actually been done, in practice, by 
standards-aware scientists and engineers for more than 15 years, who have 
used ad-hoc binary prefixes when necessary. Standardized binary prefixes 
only make things more clear and less ambiguous, and have now been around 
for almost 10 years.

-- 
Wesley J. Landaker <[EMAIL PROTECTED]> 
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2


signature.asc
Description: This is a digitally signed message part.

Re: Using standardized SI prefixes

[Josselin Mouette]

Le vendredi 15 juin 2007 à 17:36 -0400, Ivan Jager a écrit :
> Yes. Any time the unit is bytes. There is even a standard for it.

I must have missed that one. Could you point us to this standard?

> How about when you buy 80 GB of RAM, and your software says you have
> 88 GB?

How about buying 80 GiB of RAM and having software say you have 80 GiB?

> How about when you buy an 80 GB disk, and you know it's 80 * 10^9 bytes,
> but your software says /home only has 79 GB and you know it means
> 79 * 10^9 bytes? Should we also add filesystem overhead to all file sizes 
> just to avoid confusing newbies?

Filesystem overhead is not an inaccuracy. It is expected that you can
only create a 79 GiB filesystem on a 80 GiB disk. It is not expected
that a 80 GB disk is 88 GB.

> It only solves half the problem. GB is still ambiguous even if GiB isn't.

It is only ambiguous for approximative people. Furthermore, if the use
of GiB starts spreading, there will be no regression in the fact that GB
is ambiguous. However in the long term that ambiguity will disappear.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Using standardized SI prefixes

[Josselin Mouette]

Le vendredi 15 juin 2007 à 13:46 -0400, Phillip Susi a écrit :
> Different disciplines often ascribe different meanings to the same 
> words, so there is no reason why the prefix "Kilo" can not mean 1024 in 
> the context of computer science, so please stop complaining about that. 

You cannot always infer a unit from the context. Asking for inaccuracy
for such fallacious reasons sounds completely insane, from a scientific
PoV.

> You should just learn that in this context, that is what it means. 
> Always has and always will.

Sorry, it hasn't always been like this. And there is even less reason
for things to *remain* like this. The only reason that was invoked so
far is laziness.

> Because we needed a name, and Kilo is a good one to use.  There is no 
> rule that says you can't use the word for a different meaning in a 
> different context.

Do you need a rule not to do something stupid?

> And before computers were invented the word mouse always referred to a 
> small hairy rodent.  I don't see you complaining that it can also refer 
> to the computer pointing device on your desk.  When someone says they 
> caught a mouse or they clicked with their mouse, you can easily infer 
> which one they mean.

If you want comparisons, find suitable ones; you're talking about 1024
being close to 1000. Pi is close to 3, so we can say 3 instead of Pi as
well. When told the area of a circle is 3r², you'll be able to infer
that in this context, 3 means Pi.

> The context clearly indicates the meaning is 1024.  When referring to 
> bytes that context uses 1024.

Not always.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Using standardized SI prefixes

[Jean-Christophe Dubacq]

Phillip Susi a écrit :
> Christof Krüger wrote:
>> Unfortunately, computer designers, technicians etc. are not living in an
>> isolated world (well.. maybe some of them).
>> No one wants to forbid the computer people to use base 2 numbers. They
>> are just asked to write KiB instead of KB if they mean base 2
>> quantities, because the rest of the world already uses kilo as 1000.
>> Changing the rest of the world makes no sense and having distinct names
>> for distinct thing does no harm.
> 
> Different disciplines often ascribe different meanings to the same 
> words, so there is no reason why the prefix "Kilo" can not mean 1024 in 
> the context of computer science, so please stop complaining about that. 
>   You should just learn that in this context, that is what it means. 
> Always has and always will.
> 
>> Yup, I totally agree. But why do we call it "kilo" then, when we
>> actually mean 1024? Someone found it handy dozens of years ago and
> 
> Because we needed a name, and Kilo is a good one to use.  There is no 
> rule that says you can't use the word for a different meaning in a 
> different context.
> 
>> everybody has adapted it. So back then, someone was redefining your pi
>> to 3 because it was close enough and now we should leave it this way?
>> Remember that until computers have been invented (or binary logic), kilo
>> has always meant 1000.
> 
> And before computers were invented the word mouse always referred to a 
> small hairy rodent.  I don't see you complaining that it can also refer 
> to the computer pointing device on your desk.  When someone says they 
> caught a mouse or they clicked with their mouse, you can easily infer 
> which one they mean.
> 
>> However, I don't agree that this should hold true in computer science.
>> One possible meaning of KB is "1000 bytes". The other is "1024 bytes".
>> Now take the sentence: "Hello John. I've got a file here and want to
>> send it to you. It's 25KB large." Now please extract from the context
>> which meaning is significant here? The problem is that the both possible
>> meanings depict exactly the same: a quantity of bytes.
> 
> The context clearly indicates the meaning is 1024.  When referring to 
> bytes that context uses 1024.  Also capitalizing the K is another 
> indicator.  There is no ambiguity in that sentence to anyone familiar 
> with the computer science context.
It was already explained that even in computer science, kilo does not
always mean 1024. 56 kb/s is 56000 b/s, not 57344 b/s.

Anyway, I think the request initially was to indicate what kind of units
is in use, not to standardize on whether binary or decimal units should
be used. What has to be spotted is the places where formatting makes
inserting a i in the unit impossible. They should be very few, since
localization already pushes pieces of text around.

Then, somebody will stand and claim unification is required. But let's
deal with it later.

And anyway, we should not use byte anymore. Octet is less ambiguous !


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Ben Finney]

Ivan Jager <[EMAIL PROTECTED]> writes:

> BTW, I prefer SI units over imperial ones, but there are no SI units
> for information, so we're stuck using bits and bytes.

The issue isn't over the chosen unit. The issue is over the chosen
*abbreviations*. We use 'B' for byte, 'b' for bit; that's not at issue
in this thread.

> I also generaly prefer things to be unambiguous when there is no
> disadvantage, but, fortunately, that is not a problem for me in any
> of the programs I use.

This is the "I'm alright Jack" non-argument I already addressed in
this thread.

-- 
 \ "He who laughs last, thinks slowest."  -- Anonymous |
  `\   |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Eduard Bloch]

#include 
* Ivan Jager [Fri, Jun 15 2007, 05:36:33PM]:

> How about when you buy an 80 GB disk, and you know it's 80 * 10^9 bytes,
> but your software says /home only has 79 GB and you know it means
> 79 * 10^9 bytes?

First, it would hardly say 79GB. Maybe 79.96GB which is much closer.

> Should we also add filesystem overhead to all file sizes 
> just to avoid confusing newbies?

Second, "du" already does that. Go figure.

> >I don't want to read some manual or source code just to know which base
> >is used when I read or write 10G. When I write, how can I unambiguously
> >tell the program that I mean 1000 or 1024? Only using G and Gi, this
> >would be possible.
> 
> It only solves half the problem. GB is still ambiguous even if GiB isn't.

Sure, but it makes it possible to make it _right_ in a good portion of
situations. The people who really need binary units can make clear what
they are doing there. Otherwise they would deliberately create
confusion. You like to be among them? You like chaos and cheating?

> How about using these prefixes to unambiguously refer to powers of 10? 
> kdkidi10^3

Like in kidigram and medameter? What comes next, midroutopicans?

Eduard.
-- 
 jjFux: Ted hieß ja früher auch Walther
 winkiller: hm... es sind 8... die 7 kandidaten und NOTA
 Ist der jetzt eigentlich eine gespaltene Persönlichkeit, bei der aber
  beide Teile bekloppt sind?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Ivan Jager]

On Fri, 15 Jun 2007, [EMAIL PROTECTED] wrote:


On Fri, Jun 15, 2007 at 01:46:10PM -0400, Phillip Susi wrote:

Because we needed a name, and Kilo is a good one to use.  There is no
rule that says you can't use the word for a different meaning in a
different context.


Which context would this be? Computer Science? Computer Engineering?
Computer Networks? Storage Disks? Magnetic or Optical? File sizes?
Memory size? Cache size?


Yes. Any time the unit is bytes. There is even a standard for it.


I agree that in computer science, many (not
necessarily most of) times it would very bad sense to use a power of 10
instead of a power of 2. Like back when they used ten's complement.
However, this makes the point stronger, since 10 was a base used with
some digital computers.


It *was* used. Then people realized base 2 was a lot better for digital 
computers.


Some people living on this continent before us used to use base 20. So 
this makes the point stronger that if I want change for a $10, you should 
give me back four $5 bills. :)



And before computers were invented the word mouse always referred to a
small hairy rodent.  I don't see you complaining that it can also refer
to the computer pointing device on your desk.  When someone says they
caught a mouse or they clicked with their mouse, you can easily infer
which one they mean.


Yes. But you can't infer which one (1000 or 1024) MB mean. When you buy
a disk, what do the vendor says the capacity is? 80 GB. But your
software states it is no more than 75GB. What the fuck!? If GiB is
confusing to users, so is base 2. People use base 10 and k (kilo) means
1000, M (Mega) means 10^6, G (Giga) means 10^9, etc., because they are
used to base 10.


How about when you buy 80 GB of RAM, and your software says you have
88 GB?

How about when you buy an 80 GB disk, and you know it's 80 * 10^9 bytes,
but your software says /home only has 79 GB and you know it means
79 * 10^9 bytes? Should we also add filesystem overhead to all file sizes 
just to avoid confusing newbies?



I don't want to read some manual or source code just to know which base
is used when I read or write 10G. When I write, how can I unambiguously
tell the program that I mean 1000 or 1024? Only using G and Gi, this
would be possible.


It only solves half the problem. GB is still ambiguous even if GiB isn't.


How about using these prefixes to unambiguously refer to powers of 10? 
kd	kidi	10^3

Md  meda10^6
Gd  gida10^9
Td  teda10^12
Pd  peda10^15
Ed  exda10^18
Zd  zeda10^21
Yd  yoda10^24

Come on, you know you want a yodameter. :)

Ivan


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Criggie]

Joe Smith wrote:
> Also just rembering the exact conversion factors for
> Imperial units can be a problem especially with some of the more obscure
> units.

Nope - google knows everything!

http://www.google.com/search?hl=email&rls=email&q=100+m%2Fs+in+fathoms+per+fortnight

"2 parsecs in smoots" returns
2 Parsecs = 3.62637237 × 10^16 smoots

http://www.kottke.org/03/08/fun-with-the-google-calculator

If you lack net access at any given moment, then there's a *nix utility
named units, which is conveniently already packaged in debian.
http://packages.debian.org/stable/utils/units  Thanks to John Hasler for
that one.


-- 
Criggie

http://criggie.dyndns.org/




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[cascardo]

On Fri, Jun 15, 2007 at 01:46:10PM -0400, Phillip Susi wrote:
> Because we needed a name, and Kilo is a good one to use.  There is no
> rule that says you can't use the word for a different meaning in a
> different context.

Which context would this be? Computer Science? Computer Engineering?
Computer Networks? Storage Disks? Magnetic or Optical? File sizes?
Memory size? Cache size? I agree that in computer science, many (not
necessarily most of) times it would very bad sense to use a power of 10
instead of a power of 2. Like back when they used ten's complement.
However, this makes the point stronger, since 10 was a base used with
some digital computers.

> And before computers were invented the word mouse always referred to a
> small hairy rodent.  I don't see you complaining that it can also refer
> to the computer pointing device on your desk.  When someone says they
> caught a mouse or they clicked with their mouse, you can easily infer
> which one they mean.

Yes. But you can't infer which one (1000 or 1024) MB mean. When you buy
a disk, what do the vendor says the capacity is? 80 GB. But your
software states it is no more than 75GB. What the fuck!? If GiB is
confusing to users, so is base 2. People use base 10 and k (kilo) means
1000, M (Mega) means 10^6, G (Giga) means 10^9, etc., because they are
used to base 10.

I don't want to read some manual or source code just to know which base
is used when I read or write 10G. When I write, how can I unambiguously
tell the program that I mean 1000 or 1024? Only using G and Gi, this
would be possible.

> The context clearly indicates the meaning is 1024.  When referring to
> bytes that context uses 1024.  Also capitalizing the K is another
> indicator.  There is no ambiguity in that sentence to anyone familiar
> with the computer science context.

When you use K, this could be true. But remember not all users are
familiar with the computer science context. So, you type 600 and see
5.7MB. And users not familiar with the computer science context will
think: "What the ...?". So, if reading 5.7MiB will do them no favor,
that should read 6.0MB.

Regards,
Thadeu Cascardo.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Phillip Susi]

Christof Krüger wrote:

Unfortunately, computer designers, technicians etc. are not living in an
isolated world (well.. maybe some of them).
No one wants to forbid the computer people to use base 2 numbers. They
are just asked to write KiB instead of KB if they mean base 2
quantities, because the rest of the world already uses kilo as 1000.
Changing the rest of the world makes no sense and having distinct names
for distinct thing does no harm.


Different disciplines often ascribe different meanings to the same 
words, so there is no reason why the prefix "Kilo" can not mean 1024 in 
the context of computer science, so please stop complaining about that. 
 You should just learn that in this context, that is what it means. 
Always has and always will.



Yup, I totally agree. But why do we call it "kilo" then, when we
actually mean 1024? Someone found it handy dozens of years ago and


Because we needed a name, and Kilo is a good one to use.  There is no 
rule that says you can't use the word for a different meaning in a 
different context.



everybody has adapted it. So back then, someone was redefining your pi
to 3 because it was close enough and now we should leave it this way?
Remember that until computers have been invented (or binary logic), kilo
has always meant 1000.


And before computers were invented the word mouse always referred to a 
small hairy rodent.  I don't see you complaining that it can also refer 
to the computer pointing device on your desk.  When someone says they 
caught a mouse or they clicked with their mouse, you can easily infer 
which one they mean.



However, I don't agree that this should hold true in computer science.
One possible meaning of KB is "1000 bytes". The other is "1024 bytes".
Now take the sentence: "Hello John. I've got a file here and want to
send it to you. It's 25KB large." Now please extract from the context
which meaning is significant here? The problem is that the both possible
meanings depict exactly the same: a quantity of bytes.


The context clearly indicates the meaning is 1024.  When referring to 
bytes that context uses 1024.  Also capitalizing the K is another 
indicator.  There is no ambiguity in that sentence to anyone familiar 
with the computer science context.




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Ivan Jager]

On Fri, 15 Jun 2007, Ben Finney wrote:

David Verhasselt <[EMAIL PROTECTED]> writes:


Perhaps transforming it into a localization problem would do the
trick.  This way, users would be able to set their preference on
byte-count in the same place as their preference on currency,
decimal, and am/pm vs 24h. Applications could make use of the
localization settings to calculate the amount of bytes, which would
hopefully eventually centralize and generalize what counting-method
the user sees.


A GiB is the same in any locale, and has the same display -- "GiB" --
in any locale. Displaying it another way is misleading.


I like the way ls -lh prints it's output, thankyouverymuch. Adding an 
extra "iB" accomplishes nothing for me other than causing more filenames 
to wrap.


I'm not saying "GiB" is always bad, but just because some standards 
organization defined a prefix to mean something, doesn't mean the same 
prefix doesn't also have another meaning.


When you see GB, why do you insist that the G must have the SI meaning, 
when the B clearly doesn't? If I say 1 Ton, do you parse that as meaning

1 * 10^12 on's? :)


BTW, I prefer SI units over imperial ones, but there are no SI units for 
information, so we're stuck using bits and bytes. I also generaly prefer 
things to be unambiguous when there is no disadvantage, but, fortunately, 
that is not a problem for me in any of the programs I use. They all use 
the binary powers. If enough of them started using GiB, and even one of 
the programs I use regurarly switched to using decimal powers, I would 
suddenly become mistrustful of a lot of other programs, simply for not 
wasting an i.


Ivan


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Ben Finney]

Ben Finney <[EMAIL PROTECTED]> writes:

> A GiB is the same in any locale, and has the same display -- "GiB"
> -- in any locale. Displaying it another way is misleading.

I'm informed that this may not be the case. Consider the statement
modified to: "A GiB is the same in any locale, and displaying it as GB
is never correct no matter the locale".

-- 
 \   "A free society is one where it is safe to be unpopular."  -- |
  `\ Adlai Ewing Stevenson |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Alex Jones]

On Thu, 2007-06-14 at 20:15 +0200, David Verhasselt wrote:
> Yes, but the fact is that there are apparently a lot of different 
> opinions on what should be used. Therefore why not agree to disagree, 
> and let the user decide what they want to use. Make a centralized system 
> that converts an arbitrary byte-count to the user's preferred way of 
> viewing it. That's where I got the locale analogy from. I know, it's 
> probably overkill to create a whole new API for just this, but perhaps 
> there is an API where you could add a simple function that does this to. 
> Maybe in GTK?
> 
> Either way, a centralized system would help stop errorenous usage of 
> GiB, GB or Gb.

Don't we already do this for °C and °F?
-- 
Alex Jones
http://alex.weej.com/

Re: Using standardized SI prefixes

[David Verhasselt]

Ben Finney wrote:

David Verhasselt <[EMAIL PROTECTED]> writes:

  

Perhaps transforming it into a localization problem would do the
trick.  This way, users would be able to set their preference on
byte-count in the same place as their preference on currency,
decimal, and am/pm vs 24h. Applications could make use of the
localization settings to calculate the amount of bytes, which would
hopefully eventually centralize and generalize what counting-method
the user sees.



A GiB is the same in any locale, and has the same display -- "GiB" --
in any locale. Displaying it another way is misleading.

  
Yes, but the fact is that there are apparently a lot of different 
opinions on what should be used. Therefore why not agree to disagree, 
and let the user decide what they want to use. Make a centralized system 
that converts an arbitrary byte-count to the user's preferred way of 
viewing it. That's where I got the locale analogy from. I know, it's 
probably overkill to create a whole new API for just this, but perhaps 
there is an API where you could add a simple function that does this to. 
Maybe in GTK?


Either way, a centralized system would help stop errorenous usage of 
GiB, GB or Gb.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Ben Finney]

David Verhasselt <[EMAIL PROTECTED]> writes:

> Perhaps transforming it into a localization problem would do the
> trick.  This way, users would be able to set their preference on
> byte-count in the same place as their preference on currency,
> decimal, and am/pm vs 24h. Applications could make use of the
> localization settings to calculate the amount of bytes, which would
> hopefully eventually centralize and generalize what counting-method
> the user sees.

A GiB is the same in any locale, and has the same display -- "GiB" --
in any locale. Displaying it another way is misleading.

-- 
 \ "We demand rigidly defined areas of doubt and uncertainty!"  -- |
  `\ Vroomfondel, _The Hitch-Hiker's Guide To The Galaxy_, Douglas |
_o__)Adams |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Ben Finney]

Ivan Jager <[EMAIL PROTECTED]> writes:

> On Thu, 14 Jun 2007, Ben Finney wrote:
> > Since we *can* give a perfectly precise quantity of bytes and
> > other digital phenomena, and often do, this is even more reason to
> > use the precise meaning of the units for those quantities.
>
> Ok, so this applies to dd and what else?

It applies to any software that refers to quantities that use these
units. Pick a unit for the quantity, base-10 or base-2, and use its
precise meaning and the precise term for it.

> I thought this argument was mostly about measured sizes anyways,
> such as what you would get from ls -lh, df -h, du -h, or their GUI
> equivalents. These are all rounded.

Any time the software says "GB" when the quantity was actually
calculated in 2^30, or says "GiB" when the quantity was actually
calculated in 10^9, the units are mismatched. Whether the quantity was
rounded is irrelevant to this fact.

> While 10^9 <> 2**30, I find the later to be a much more useful
> number on a computer.

Nothing in this proposal speaks against using 2^30 bytes as a unit of
measure. The only thing wrong would be to refer to the unit as "GB",
because that isn't 2^30 bytes. The only unambiguous standard
abbreviation for that unit is "GiB".

-- 
 \ "Many are stubborn in pursuit of the path they have chosen, few |
  `\  in pursuit of the goal."  -- Friedrich Nietzsche |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Ivan Jager]

On Wed, 13 Jun 2007, Wesley J. Landaker wrote:


On Wednesday 13 June 2007 14:03:51 Lionel Elie Mamane wrote:

On Tue, Jun 12, 2007 at 05:33:12PM -0600, Wesley J. Landaker wrote:

Even in the US all legitimate science and engineering is done in SI
units.


Suurre... That's why in 1999 the NASA Mars orbiter didn't crash
because one (NASA) team worked in metric units and the other (private
contractor) in imperial units.


I am happy to very brutally assert that the team who didn't use SI was not
doing legitimate science or engineering. But whether it's from unskilled
employees or bad management, it's quite unfortunate. =(


Over here we have two sieres of intro physics courses. One is for science 
students, and the other is for engineers. Guess what the biggest 
difference is.


Yes, I know it's sad, but apparently engineers need to learn their physics 
in imperial units... :(


Ivan


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Ivan Jager]

On Thu, 14 Jun 2007, Ben Finney wrote:

Ivan Jager <[EMAIL PROTECTED]> writes:


On Wed, 13 Jun 2007, Alex Jones wrote:

1 TB is not rounded. It means precisely 1 × 10^12 bytes, no more
and no less. If they want to actually put 1.024 TB on the disk
then they can say 1 TB (approx.) like any other industry
(detergent, bacon, etc.).


1 TB has only one significant digit. It would be silly to think that
it was an exact measurement, at least in fields I am familiar
with. ;) No one I know would think 1km is as precisely measured as
1.0km.


The difference being that digital specifications for things like
storage capacity and memory are not measured. They are calculated, and
in those contexts they *are* precise.

Rounding can be done after the calculated number is obtained, but it's
not inherent in the process of obtaining the number the way that
measuring "1 km" or "1 tablespoon" is.

Since we *can* give a perfectly precise quantity of bytes and other
digital phenomena, and often do, this is even more reason to use the
precise meaning of the units for those quantities.


Ok, so this applies to dd and what else? I guess fdisk kind of counts, 
except even there, while being a specified size rather than measured, the 
size of the partition it creates is still rounded to a whole cylinder.
I'm having trouble thinking of anything where a n00b would be specifying 
sizes with prefixes and expecting it to be exactly a specific size down 
to the byte.



I thought this argument was mostly about measured sizes anyways, such as 
what you would get from ls -lh, df -h, du -h, or their GUI equivalents. 
These are all rounded. Do the GUI equivalents show full precision even 
with prefixes? That seems kind of pointless.


AFAIK we are using precise meanings of the prefixes. They are just 
ambiguous, since they have more than one precise meaning. On computers, 
when measuring units of bytes, I am confused any time someone isn't using 
the binary values. (Although I'm not so surprised when the numbers are 
coming from marketing people.) While 10^9 <> 2**30, I find the later to be 
a much more useful number on a computer.


A few more things I thought of where a user might need to specify a size:
xorg.conf VideoRAM option
mem argument on kernel commandline
mkfs
resize2fs
ping

All of these except for ping want the byte sizes to be divisible by some 
power of two. Because memory comes in powers of two, and disks come in 
multiples of 512 bytes, the powers of two tend to be a lot more useful 
than the powers of ten.


I might be too much of a systems person... Let me know if you can come up 
with examples where you would want to specify byte sizes in powers of 10 
rather than 2.


I am now somewhat tempted to do a small survey asking random people how 
much they think a megabyte is. :)


Ivan

Re: Using standardized SI prefixes

[David Verhasselt]

Perhaps transforming it into a localization problem would do the trick.
This way, users would be able to set their preference on byte-count in
the same place as their preference on currency, decimal, and am/pm vs
24h. Applications could make use of the localization settings to
calculate the amount of bytes, which would hopefully eventually
centralize and generalize what counting-method the user sees.

David Verhasselt


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[David Verhasselt]

Perhaps transforming it into a localization problem would do the trick. 
This way, users would be able to set their preference on byte-count in 
the same place as their preference on currency, decimal, and am/pm vs 
24h. Applications could make use of the localization settings to 
calculate the amount of bytes, which would hopefully eventually 
centralize and generalize what counting-method the user sees.


David Verhasselt


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Josselin Mouette]

Le jeudi 14 juin 2007 à 12:15 +0200, Gabor Gombas a écrit :
> On Wed, Jun 13, 2007 at 08:45:13PM +0200, Josselin Mouette wrote:
> 
> > The meaning of 1 TB is approximate only for approximate people. I'd
> > expect more rigor from people working in computer science (if we can
> > call it a science).
> 
> ... and since most Debian users are not computer scientists, Scott is
> right.
> 
> Yesterday my collegue asked me how much storage a server has that we
> bought from some project money, and he had to write a report. When I
> told him "931 MiB", he said "No, I want a number like 1T or 2T" (and he
> has an IT degree, although not CS in the strict sense). That's how
> people think, and if you do not acknowledge that, you're living outside
> of reality.

I don't know who told you he always needs precision, but it wasn't me.
http://lists.debian.org/debian-devel/2007/06/msg00589.html

(The answer to all of your nonsense is already in this post, no need to
repeat myself.)
-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: Using standardized SI prefixes

[Gabor Gombas]

On Wed, Jun 13, 2007 at 08:45:13PM +0200, Josselin Mouette wrote:

> The meaning of 1 TB is approximate only for approximate people. I'd
> expect more rigor from people working in computer science (if we can
> call it a science).

... and since most Debian users are not computer scientists, Scott is
right.

Yesterday my collegue asked me how much storage a server has that we
bought from some project money, and he had to write a report. When I
told him "931 MiB", he said "No, I want a number like 1T or 2T" (and he
has an IT degree, although not CS in the strict sense). That's how
people think, and if you do not acknowledge that, you're living outside
of reality.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Jean-Christophe Dubacq]

On Wed, Jun 13, 2007 at 07:41:27PM +0100, Adam D. Barratt wrote:
> On Wed, 2007-06-13 at 14:08 -0400, Felipe Sateler wrote:
> > Mike Hommey wrote:
> > 
> > > On Tue, Jun 12, 2007 at 09:25:13PM +, Evgeni Golov
> > > <[EMAIL PROTECTED]> wrote:
> > >> On Tue, 12 Jun 2007 15:42:08 -0300 Paulo Marcondes wrote:
> > >> 
> > >> > billion = 10^6 * 10^6 (IIRC, as used in Portugal - no jokes here!)
> > >> 
> > >> =10^12 :)
> > >> 
> > >> and Germany, France, former UdSSR, 
> > > 
> > > Anywhere where milliard is 10^9, basically...
> > 
> > Which includes England, according to Merriam-Webster [1]. 
> [...]
> > [1] http://www.m-w.com/mw/table/number.htm
> 
> The American usage has been becoming more common in England (and the
> rest of Britain :-) over the past few years, particularly in science and
> finance related usage.
> 
> I could be wrong, but I suspect most British people have never even
> heard of a milliard. It's usually referred to either as a billion or an
> "American billion".

http://en.wikipedia.org/wiki/Long_and_short_scales

It all depends on space and time.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Miles Bader]

Eduard Bloch <[EMAIL PROTECTED]> writes:
> What is not really understandable is why this stupid naming has been
> kept in Windows XP.

Because nobody actually cares except control-freak types, and they're
certainly not who windows is targetting!

-Miles

-- 
`To alcohol!  The cause of, and solution to,
 all of life's problems' --Homer J. Simpson


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[shirish]

Hi all,
   One of the ways to drive usage as somebody mentioned is to
drive upstream & that is a good way. Make sure most of free libraries
incorporate KiB [0] & the mathematical stuff needed (No computer
engineer here, just a user who cares)  so things turn out right while
making sure that the end-user utility GUI's [1]  do show them & as
well as update things on wikipedia to show the new reality [2] :)

[0] http://libburnia-project.org/changeset/877 as well as
http://libburnia-project.org/changeset/876

[1] http://dev.deluge-torrent.org/changeset/527

[2] http://en.wikipedia.org/wiki/Binary_prefix#Adoption

As more & more softwares start using the standards while in
development there would be no more need to try & advocate usage of Si
prefixes. We just need to add critical mass & that's it.
--
 Shirish Agarwal
 This email is licensed under http://creativecommons.org/licenses/by-nc/3.0/

065C 6D79 A68C E7EA 52B3  8D70 950D 53FB 729A 8B17


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Ben Finney]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Christof Krüger <[EMAIL PROTECTED]> writes:
>
> > I'd really like to hear some real arguments against SI prefixes,
> > besides being ugly or funny to pronounce or just because "it has
> > always been like that". Advantages of using SI prefixes has been
> > mentioned in this thread. Please tell me the disadvantages so
> > there can actually be a constructive discussion.
>
> Trying to change every piece of software in existence is a waste of
> time and energy for a problem that isn't that serious.

This proposal was never about "trying to change every piece of
software in existence". Just because perfection is unobtainable
doesn't stop us from working to improve the state of what we have.

> IMO, that's the *real* objection; most of the arguments are
> justifications for that position or are about things that we'd get
> over if this issue were addressed (like the silly words -- there are
> sillier words in English that just don't sound that way because
> we're used to them).

Agreed. Most of the arguments against this proposal to follow a useful
standard that improves clarity have been essentially "yuk" or "I'm
alright Jack".

Yes, the names sound silly. So does "byte", but we follow that
convention. A silly name is not an argument against following the
standard. The names are close enough to the wrongly-applied base-10
names that familiarity is fairly easily obtainable, while still being
different enough that they are distinct names.

Yes, most of us who frequently work with computers have become
accustomed to the ambiguity of these terms, in a field where precision
of terminology is highly valued. This is no reason not to work toward
fixing this for the majority of people who have yet to spend any
significant time exposed to these terms.

-- 
 \   "One of the most important things you learn from the internet |
  `\   is that there is no 'them' out there. It's just an awful lot of |
_o__) 'us'."  -- Douglas Adams |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Ben Finney]

Ivan Jager <[EMAIL PROTECTED]> writes:

> On Wed, 13 Jun 2007, Alex Jones wrote:
> > 1 TB is not rounded. It means precisely 1 × 10^12 bytes, no more
> > and no less. If they want to actually put 1.024 TB on the disk
> > then they can say 1 TB (approx.) like any other industry
> > (detergent, bacon, etc.).
>
> 1 TB has only one significant digit. It would be silly to think that
> it was an exact measurement, at least in fields I am familiar
> with. ;) No one I know would think 1km is as precisely measured as
> 1.0km.

The difference being that digital specifications for things like
storage capacity and memory are not measured. They are calculated, and
in those contexts they *are* precise.

Rounding can be done after the calculated number is obtained, but it's
not inherent in the process of obtaining the number the way that
measuring "1 km" or "1 tablespoon" is.

Since we *can* give a perfectly precise quantity of bytes and other
digital phenomena, and often do, this is even more reason to use the
precise meaning of the units for those quantities.

-- 
 \  "I moved into an all-electric house. I forgot and left the |
  `\   porch light on all day. When I got home the front door wouldn't |
_o__) open."  -- Steven Wright |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Wesley J. Landaker]

On Wednesday 13 June 2007 14:03:51 Lionel Elie Mamane wrote:
> On Tue, Jun 12, 2007 at 05:33:12PM -0600, Wesley J. Landaker wrote:
> > Even in the US all legitimate science and engineering is done in SI
> > units.
>
> Suurre... That's why in 1999 the NASA Mars orbiter didn't crash
> because one (NASA) team worked in metric units and the other (private
> contractor) in imperial units.

I am happy to very brutally assert that the team who didn't use SI was not 
doing legitimate science or engineering. But whether it's from unskilled 
employees or bad management, it's quite unfortunate. =(

-- 
Wesley J. Landaker <[EMAIL PROTECTED]> 
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2


signature.asc
Description: This is a digitally signed message part.

Re: Using standardized SI prefixes

[Ivan Jager]

On Wed, 13 Jun 2007, Alex Jones wrote:

On Wed, 2007-06-13 at 14:29 +0100, Scott James Remnant wrote:

Without the binary unit to consider, when we quote a drive as 1TB, we
know that it has *at least* 1,000,000,000,000 bytes available.
Depending on the drive, it may have anywhere between this and
1,099,511,627,776 bytes available.  It's actually more likely to have
something strange like 1,024,000,000,000 available.


10% error is no good for me. You can continue to play the "at least"
card, but what about when it's more important if it is "at most"
something? And seeing as this error only goes up exponentially, at which
prefix do you draw the line and say "no more"?

And no-one uses floppy disks any more. Let's just bury them all and
forget about them. :D


I see no problem with this "1TB" quote being approximate.  It's rounded
anyway.  If you really want to know how many bytes are available, you
can use this great unit called the "byte" which is accurate and not
subject to change[0].


1 TB is not rounded. It means precisely 1 × 10^12 bytes, no more and no
less. If they want to actually put 1.024 TB on the disk then they can
say 1 TB (approx.) like any other industry (detergent, bacon, etc.).


1 TB has only one significant digit. It would be silly to think that it 
was an exact measurement, at least in fields I am familiar with. ;) No one 
I know would think 1km is as precisely measured as 1.0km.


But, just because it is approximate, doesn't mean it isn't also 
ambigouous. :) 1 TB could mean between 5000 and 14999 
bytes, between 549755813888 and 1649267441663  bytes, or even 
between 5000 and 14999.99... bels. :)


So, if you want the exact number of bytes, don't round it off, and if you 
do round it off, don't be surprised if the rounding is ambiguous, because 
the units are not SI units, and the prefixes may or may not be. Just don't 
use prefixes when not rounding.


I wonder, do people feel as storngly about exactly how many tablespoons
1 TT is?

Ivan

Re: Using standardized SI prefixes

[Onno Benschop]

As I see it there are two ways of resolving the difference between KiB
and KB.

* Use Rosetta to update the text and fix the output so that it now
  reads KiB. This would be relatively simple to do, but not actually
  helpful longer term.
* Fix the source code that calculates KB by doing a bit shift[0] and
  instead dividing the number of bytes by a power of 10.



[0] I'm assuming that most applications will calculate how many
Kilobytes/Megabytes are used by dividing by a power of two.

-- 
Onno Benschop

Connected via Optus B3 at S31°54'06" - E115°50'39" (Yokine, WA)
--
()/)/)()..ASCII for Onno..
|>>?..EBCDIC for Onno..
--- -. -. ---   ..Morse for Onno..

Proudly supported by Skipper Trucks, Highway1, Concept AV, Sony Central, Dalcon
ITmaze   -   ABN: 56 178 057 063   -  ph: 04 1219    -   [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Josselin Mouette]

Le mercredi 13 juin 2007 à 15:19 +0200, Bjørn Ingmar Berg a écrit :
> When computers and humans interact (on a technical level)
> humans must adapt to the computer, because computers can not.

Anyone starting with such assumptions should never design any kind of
user interface.

> Dealing with chunks of data, addresses, registers, etc. has to be done
> in base 2.  Even if 1024 is "close enough" to 10^3 for a PHB or
> marketing humanoid, that will never make those two numbers equal.  And
> it must never be allowed to.  Computers, computer designers, computer
> technicians and most computer programmers will always deal with the
> _real_ base 2 numbers like 1024.

Which is why they need appropriate units.

> Another example.  Pi is an irrational number starting with 3.14
> Sure, it would be easier to "standardize" it to 3.00.  Done deal.  It
> would be easier to remember and more marketable.  It would also be
> totally useless AND completely wrong.  AFAIK some very dumb people
> actually managed to decree by law that pi was to equal 3.  They had to
> stop doing that.

This is exactly what you are trying to do: state that 1024 = 1000.

> A well-known and very common trait of language is that one given word
> can often have more than one specific meaning.  When this is the case
> you need a context to be sure.  This is considered normal, and never a
> real problem.  This should hold true regarding computers and counting
> as well.

Yeah, sure. This is why mathematicians always use 3 instead of Pi in
calculations. After all they are similar, and you can infer which one is
actually being used depending on the context.

> I am very convinced the correct solution is always to
> educate the public.  The world is not flat.  The earth is not the
> center of the universe.  Pi is not 3.  A kilobyte is not 1000; it is
> 1024 because that is the way computers work.

I am convinced the correct solution is to educate the group of blindfold
hackers who think 1024 = 1000. It is much easier than educating millions
of users.

Wake up, Neo. There is a world out there. And in this world, "kilo"
means 1000. One thousand. 10³.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Using standardized SI prefixes

[Lionel Elie Mamane]

On Tue, Jun 12, 2007 at 05:33:12PM -0600, Wesley J. Landaker wrote:

> Even in the US all legitimate science and engineering is done in SI
> units.

Suurre... That's why in 1999 the NASA Mars orbiter didn't crash
because one (NASA) team worked in metric units and the other (private
contractor) in imperial units.

-- 
Lionel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Christof Krüger]

On Wed, 2007-06-13 at 14:29 +0100, Scott James Remnant wrote:
> [...]
> And we still have many figures in both GB and GiB which are neither of
> the two!

okay ... reading on ...

> [...]
> I see no problem with this "1TB" quote being approximate.  It's
> rounded anyway.

So you don't care if it is approximate? Then you should care less if
it's even exact!

However, I find that tebibyte, gibibyte, mebibyte and kibibyte sound
quite familiar to their base-10 friends so that it should be no problem
even for a dumb user to understand its meaning if he already knew what a
gigabyte or megabyte is. This is especially the case with the short
notation (e.g. KiB vs. KB).

The more important case is when a user actually *cares* about the exact
number.
At the moment base 10 and base 2 numbers are often prefixed both with k
for kilo, M for mega etc. This means that there will be confusion if
something is labeled 100GB.
Now consider introducing SI prefixes.
There still will be confusion with "100GB", because apparently not
everyone likes SI prefixes and continues using the "old" prefixes with
base 2 numbers. However, when something is labeled "100GiB", there is no
confusion (remember that we are talking about a user that cares about
the exact number, the dumb user will guess that GiB must be something
similar to GB).
Okay, so we gained some confidence about what is meant. How can we get
rid of the rest of uncertainty? Answer: Use the SI prefixes
consistently! This will take a while of course, but eventually you can
only benefit.

Regards,
  Christof Krüger

Re: Using standardized SI prefixes

[Russ Allbery]

Christof Krüger <[EMAIL PROTECTED]> writes:

> I'd really like to hear some real arguments against SI prefixes, besides
> being ugly or funny to pronounce or just because "it has always been
> like that". Advantages of using SI prefixes has been mentioned in this
> thread. Please tell me the disadvantages so there can actually be a
> constructive discussion.

Trying to change every piece of software in existence is a waste of time
and energy for a problem that isn't that serious.

IMO, that's the *real* objection; most of the arguments are justifications
for that position or are about things that we'd get over if this issue
were addressed (like the silly words -- there are sillier words in English
that just don't sound that way because we're used to them).

-- 
Russ Allbery ([EMAIL PROTECTED])   

Re: Using standardized SI prefixes

[Josselin Mouette]

Le mercredi 13 juin 2007 à 15:06 +0100, Scott James Remnant a écrit :
> On Wed, 2007-06-13 at 15:01 +0100, Alex Jones wrote:
> 
> > 1 TB is not rounded. It means precisely 1 × 10^12 bytes, no more and no
> > less.
> > 
> No it doesn't.
> 
> The meaning of 1 TB depends on the context, and has always done so.

The meaning of 1 TB is approximate only for approximate people. I'd
expect more rigor from people working in computer science (if we can
call it a science).

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Using standardized SI prefixes

[Adam D. Barratt]

On Wed, 2007-06-13 at 14:08 -0400, Felipe Sateler wrote:
> Mike Hommey wrote:
> 
> > On Tue, Jun 12, 2007 at 09:25:13PM +, Evgeni Golov
> > <[EMAIL PROTECTED]> wrote:
> >> On Tue, 12 Jun 2007 15:42:08 -0300 Paulo Marcondes wrote:
> >> 
> >> > billion = 10^6 * 10^6 (IIRC, as used in Portugal - no jokes here!)
> >> 
> >> =10^12 :)
> >> 
> >> and Germany, France, former UdSSR, 
> > 
> > Anywhere where milliard is 10^9, basically...
> 
> Which includes England, according to Merriam-Webster [1]. 
[...]
> [1] http://www.m-w.com/mw/table/number.htm

The American usage has been becoming more common in England (and the
rest of Britain :-) over the past few years, particularly in science and
finance related usage.

I could be wrong, but I suspect most British people have never even
heard of a milliard. It's usually referred to either as a billion or an
"American billion".

Adam


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Christof Krüger]

> Let me start with a dumb example:
> For a child or uninterested commoner that flying critter is simply "a
> birdie".  For those in the know exactly the same entity is a "Falco
> peregrinus".
> Even if simply calling it "birdie" or perhaps "falcon" would be
> easier, more "user friendly" more "understandable for everyone" it
> simply would not be /correct/.
The word birdie is a generalization of quite every critter that can fly.
So it is correct, the critter "Falco peregrinus" is a birdie, too.
Calling this critter "falco peregrinus" is correct, too. The example
just doesn't apply here because KB is not a generalization of KiB and
vice versa.

> 
> Computers deal with numbers in base two.  Humans deal with numbers in
> base 10.  When computers and humans interact (on a technical level)
> humans must adapt to the computer, because computers can not.
> Dealing with chunks of data, addresses, registers, etc. has to be done
> in base 2.  Even if 1024 is "close enough" to 10^3 for a PHB or
> marketing humanoid, that will never make those two numbers equal.
Right, and this is the reason why having the same name for different
things is not good.

> And it must never be allowed to.  Computers, computer designers, computer
> technicians and most computer programmers will always deal with the
> _real_ base 2 numbers like 1024.
Unfortunately, computer designers, technicians etc. are not living in an
isolated world (well.. maybe some of them).
No one wants to forbid the computer people to use base 2 numbers. They
are just asked to write KiB instead of KB if they mean base 2
quantities, because the rest of the world already uses kilo as 1000.
Changing the rest of the world makes no sense and having distinct names
for distinct thing does no harm.


> Another example.  Pi is an irrational number starting with 3.14
> Sure, it would be easier to "standardize" it to 3.00.  Done deal.  It
> would be easier to remember and more marketable.  It would also be
> totally useless AND completely wrong.  AFAIK some very dumb people
> actually managed to decree by law that pi was to equal 3.  They had to
> stop doing that.
Well, another example that does not apply here. Nobody wants to change
something true to something wrong. The status quo is that KB can mean
either 1000 or 1024 bytes depending on the context (or shoe size of the
developer or whatever). So there is an ambiguity here. Introducing SI
prefixes would eliminate ambiguities if applied consistently. Pi is well
defined. There is no ambiguity.

> Computers
> have always, do, and will continue to deal with their numbers along
> the progression of 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, etc...
> So, when dealing with computers, must we.
Yup, I totally agree. But why do we call it "kilo" then, when we
actually mean 1024? Someone found it handy dozens of years ago and
everybody has adapted it. So back then, someone was redefining your pi
to 3 because it was close enough and now we should leave it this way?
Remember that until computers have been invented (or binary logic), kilo
has always meant 1000.

> A well-known and very common trait of language is that one given word
> can often have more than one specific meaning.  When this is the case
> you need a context to be sure.  This is considered normal, and never a
> real problem.  This should hold true regarding computers and counting
> as well.
This is called a homograph. An example taken from wikipedia:
shift n. (a change)
shift n. (a period at work)
I agree that in "normal life" you can guess the meaning from the context
because it has completely different meanings.
However, I don't agree that this should hold true in computer science.
One possible meaning of KB is "1000 bytes". The other is "1024 bytes".
Now take the sentence: "Hello John. I've got a file here and want to
send it to you. It's 25KB large." Now please extract from the context
which meaning is significant here? The problem is that the both possible
meanings depict exactly the same: a quantity of bytes.

> Finally a personal and subjective thought.  At times one has to chose
> whether to oversimplify facts and information to the point where
> "everyone" understands it, (If this happens they DO NOT understand it;
> they are given the illusion of understanding) or whether to educate
> the public.
I think that you base your argumentation on wrong assumptions. The
purpose of introducing SI prefixes is *not* to make the newbie's life
simpler, at least not as primary goal. Surely, there are situations
where it really doesn't matter (e.g. if you are interested in the order
of magnitude 10% error may be totally acceptable). However, SI prefixes
make life easier for technical stuff where it is important to be exact
without having to "guess" the context, ask every time or consider the
professional background of your communication partner.

Regards,
  Christof Krüger

Re: Using standardized SI prefixes

[Felipe Sateler]

Mike Hommey wrote:

> On Tue, Jun 12, 2007 at 09:25:13PM +, Evgeni Golov
> <[EMAIL PROTECTED]> wrote:
>> On Tue, 12 Jun 2007 15:42:08 -0300 Paulo Marcondes wrote:
>> 
>> > billion = 10^6 * 10^6 (IIRC, as used in Portugal - no jokes here!)
>> 
>> =10^12 :)
>> 
>> and Germany, France, former UdSSR, 
> 
> Anywhere where milliard is 10^9, basically...

Which includes England, according to Merriam-Webster [1]. The Spanish Royal
Academy also defines[2] it as 10^12, which would mean every Spanish
speaking country uses that definition too.

[1] http://www.m-w.com/mw/table/number.htm
[2] http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=bill%F3n
-- 

  Felipe Sateler


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Magnus Holmgren]

On Wednesday 13 June 2007 15:19, Bjørn Ingmar Berg wrote:
> Let me start with a dumb example:
(OK, dumb example duly deleted)

> Computers deal with numbers in base two.  Humans deal with numbers in
> base 10.  When computers and humans interact (on a technical level)
> humans must adapt to the computer, because computers can not.

I don't agree with that. Compilers generally understand numbers in base 10, 
for example. More about that later.

> Dealing with chunks of data, addresses, registers, etc. has to be done
> in base 2.  Even if 1024 is "close enough" to 10^3 for a PHB or
> marketing humanoid, that will never make those two numbers equal.  And
> it must never be allowed to.  Computers, computer designers, computer
> technicians and most computer programmers will always deal with the
> _real_ base 2 numbers like 1024.

So? This is why there needs to be a separate set of prefixes for powers of 2. 
As for that falcon, it's just another example of why there needs to be a 
well-defined vocabulary even if the common people don't care about the 
details.

> Another example.  Pi is an irrational number starting with 3.14
> Sure, it would be easier to "standardize" it to 3.00.  Done deal.  It
> would be easier to remember and more marketable.  It would also be
> totally useless AND completely wrong.  AFAIK some very dumb people
> actually managed to decree by law that pi was to equal 3.  They had to
> stop doing that.
>
> In the same was as with pi redefining or "standardizing" kilobytes and
> megabytes would be totally useless AND completely wrong.  Computers
> have always, do, and will continue to deal with their numbers along
> the progression of 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, etc...
> So, when dealing with computers, must we.

Again, computers are perfectly capable of presenting numbers in base ten or 
any other base, depending on what is most convenient. Otherwise we might have 
been forced to input numbers in binary and get answers like "Total distance: 
10011.1 km" back (with k meaning 2^10, of course). That SI prefixes have been 
used to express powers of two is more specifically an artifact of memory 
addressing. The sizes of memory banks are normally a power of two. In that 
case it's convenient to say that the memory capacity is 64 MiB when you mean 
that it's 67 108 864 byte. But for data on a wire, or even files on a disk, 
there isn't anything constraining sizes to a power of two (block sizes are a 
number of KiB, but you rarely need to think of that as a user).

> One does not redefine pi to a value of 3 because "that would make it
> more understandable for the commoner".  Mathematicians, architects
> (and basically everyone else) need it to stay ~3.1415926535 in the
> future.
> One does not redefine kilobyte to mean 1000 (base 10) because "that
> would make it more understandable for the commoner".  Real computer
> people need it to stay 1024 (base 10).

It's not about redefining "kilobyte to mean 1000", because, as has been 
pointed out repeatedly, a kilobyte is currently either 1000 byte or 1024 byte 
depending on context. There is no exact definition, just a rather vague 
convention. This is about once and for all ending that mess.

Your analogy with redefining pi as exactly 3 is way off, because pi is a 
natural constant and as such has been defined since the beginning of time. 
Redefining pi would be like trying to alter the shape of the universe or the 
laws of nature. Deciding that SI prefixes shall be SI prefixes even in 
computer context is not like trying to strip 24 bytes off every block of 
1024, or mandating that computers always have to use BCD internally.

> A well-known and very common trait of language is that one given word
> can often have more than one specific meaning.  When this is the case
> you need a context to be sure.  This is considered normal, and never a
> real problem.  This should hold true regarding computers and counting
> as well.

That doesn't make vagueness and ambiguity *desirable*. It is common to have a 
well-defined terminology wherever people need to communicate efficiently 
without misunderstandings. Two examples are the SI units and prefixes.

> Finally a personal and subjective thought.  At times one has to chose
> whether to oversimplify facts and information to the point where
> "everyone" understands it, (If this happens they DO NOT understand it;
> they are given the illusion of understanding) or whether to educate
> the public.  I am very convinced the correct solution is always to
> educate the public.

Good. Let's then teach the public that "borrowing" well-defined SI prefixes 
and giving them a different meaning in some situations was a bad idea, and 
that an adequate solution exists.

-- 
Magnus Holmgren[EMAIL PROTECTED]
   (No Cc of list mail needed, thanks)


pgp3oIOldbVpg.pgp
Description: PGP signature

Re: Using standardized SI prefixes

[Darren Salt]

I demand that Alex Jones may or may not have written...

> And no-one uses floppy disks any more. Let's just bury them all and forget
> about them. :D

I used one yesterday to do a BIOS upgrade. :-)

> 1 TB is not rounded. It means precisely 1 × 10^12 bytes, no more and no
> less.

It means 1024^4 bytes, no more and no less. :-þ

-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
|   http://www.youmustbejoking.demon.co.uk/progs.packages.html>

We'll get along fine as soon as you realise that I'm God!

Re: Using standardized SI prefixes

[shirish]

On Wed, 2007-06-13 at 12:51 +0200, Christof Krüger wrote:

> On Tue, 2007-06-12 at 15:52 +0100, Ian Jackson wrote:
> > shirish writes ("Using standardized SI prefixes"):
> > >   Please look at http://en.wikipedia.org/wiki/Binary_prefix .
> >
> > Urgh, these things are ugly and an abomination.  We should avoid them.
>
> I'd really like to hear some real arguments against SI prefixes, besides
> being ugly or funny to pronounce or just because "it has always been
> like that". Advantages of using SI prefixes has been mentioned in this
> thread. Please tell me the disadvantages so there can actually be a
> constructive discussion.
>
User Confusion.

Most users do not know what a "tebibyte" is, and they do not care.  They
know that "a terabyte" is "about a million million bytes", and that is
sufficient.

Since you're rounding anyway, the loss of accuracy between "about a
million million bytes" and "just over a million million bytes" is not
significant.  Certainly not at the expense at having to teach users
another new unit.

Hard drives are bought in gigabytes, memory is bought in gigabytes, etc.
Quoting the same figures with a different unit in the operating system
is pedantry for its own sake.

Users have already learnt that the term "gigabyte" is approximate.


Wrong most users think of "gigabyte" as absolute rather than
approximation. If that was not the case then
http://en.wikipedia.org/wiki/Binary_prefix#Legal_disputes wouldn't
have happened. Most of the users when they burn a CD/DVD use the
approximation "GB" to say a burn a movie DVD. Most of the DVD media is
marketted as 4.78 GB while its 4.38 "GiB" & hence when they download a
movie (legally downloaded or otherwise) or do mixed mode stuff. Also I
don't know many users who go down to byte-size level & see how much
space is remaining. I do get support calls over this quite a bit.
Thinking that users know its an approximate IMHO is an
oversimplification.


Introducing new units has only added confusion, rather than removed it.


The same could be said of relatively newer concepts like free
software, open source, copyright, creative licenses, .PNG, .SVG & all
the newer stuff that the web keeps pouring in. Micro formats anyone.
That doesn't mean we stop learning, it just means we adjust ourselves
to the new reality.


Before the new units, we all knew that 1GB was an approximate figure and
likely to be (for bytes) based on a power of 2.  Now we have figures
quoted in GB and GiB, some of which are power of 10, some of which are
power of 2.  Some figures quoted in GiB are wrong, and should be in GB;
likewise some in GB should be GiB.  And we still have many figures in
both GB and GiB which are neither of the two!

Renaming the 1.44MB floppy helps in neither case; it is neither 1.44MB
or 1.44MiB.  One could name it the 1.4MB or 1.47MiB floppy and confuse
everyone into thinking it's a different thing, of course.  Or maybe it
should be the 1,440KB floppy, or the 1,475KiB floppy?  Neither of these
help the situation.


 Right, although it doesn't completely solve the situation it does
take things to a nearer perfect answer. I do see that it would take
time for us to make that change but its a better change IMO.

> Without the binary unit to consider, when we quote a drive as 1TB, we

know that it has *at least* 1,000,000,000,000 bytes available.
Depending on the drive, it may have anywhere between this and
1,099,511,627,776 bytes available.  It's actually more likely to have
something strange like 1,024,000,000,000 available.

(And none of this takes into account partitioning and filesystem
overhead!)

I see no problem with this "1TB" quote being approximate.  It's rounded
anyway.  If you really want to know how many bytes are available, you
can use this great unit called the "byte" which is accurate and not
subject to change[0].


   Do you think most common users are ever going to go down to byte size
level to see if things fit or not. It would actually be a good test
for Novell . I believe they do  desktop tests for HIG & see how users
actually do stuff. Not techies but
day-to-day the Johns & Janes.

Scott

[0] Unless you're older than 25.
--
Scott James Remnant
Ubuntu Development Manager
[EMAIL PROTECTED]


Cheers

--
 Shirish Agarwal
 This email is licensed under http://creativecommons.org/licenses/by-nc/3.0/

065C 6D79 A68C E7EA 52B3  8D70 950D 53FB 729A 8B17

Re: Using standardized SI prefixes

[Magnus Holmgren]

On Wednesday 13 June 2007 15:29, Scott James Remnant wrote:
> On Wed, 2007-06-13 at 12:51 +0200, Christof Krüger wrote:
> > On Tue, 2007-06-12 at 15:52 +0100, Ian Jackson wrote:
> > [...] Please tell me the disadvantages so there can actually be a
> > constructive discussion.
>
> User Confusion.
>
> Most users do not know what a "tebibyte" is, and they do not care.  They
> know that "a terabyte" is "about a million million bytes", and that is
> sufficient.
>
> Since you're rounding anyway, the loss of accuracy between "about a
> million million bytes" and "just over a million million bytes" is not
> significant.  Certainly not at the expense at having to teach users
> another new unit.

This is a hurdle to adoption, a one time cost. It is not an argument against 
IEC prefixes per se. The long-term benefits outweigh the costs, IMO.

> Hard drives are bought in gigabytes, memory is bought in gigabytes, etc.
> Quoting the same figures with a different unit in the operating system
> is pedantry for its own sake.
>
> Users have already learnt that the term "gigabyte" is approximate.

No, it's not. It's ambiguous. A given number can be exact or approximate 
regardless of the unit. "1.0 GB" can mean either 1.0·10^9 byte or 1.0·2^30 
byte, but whether the real value is exactly one or the other or something 
near one or the  

> Introducing new units has only added confusion, rather than removed it.

New concepts can always cause initial confusion. Relearning is harder than 
learning something right from the beginning. The same argument has been used 
against metrication in the US. Again, it's a one-time cost.

> Before the new units, we all knew that 1GB was an approximate figure and
> likely to be (for bytes) based on a power of 2.  Now we have figures
> quoted in GB and GiB, some of which are power of 10, some of which are
> power of 2.  Some figures quoted in GiB are wrong, and should be in GB;
> likewise some in GB should be GiB.  And we still have many figures in
> both GB and GiB which are neither of the two!

You're talking a lot about approximation. If I understand you correctly, 
you're saying that any stated quantity of data must either be an exact 
number, e.g. 23 368 986 120 bytes, or an approximation with a single 
significant digit. That is *stupid*. You want to deny people the 
*possibility* of consistence, unambiguity and accuracy (without resorting to 
numbers on the form "3.1·10¹²"), just because you won't think that you'll 
need that possibility most of the time.

There *is* reason to state rounded numbers with two or three digits, in which 
case the difference between MB and MiB or GB and GiB definitely matters, and 
even with a single significant digit, 8 GiB (exactly) is 9 GB when rounded to 
the nearest whole number.

> Renaming the 1.44MB floppy helps in neither case; it is neither 1.44MB
> or 1.44MiB.  One could name it the 1.4MB or 1.47MiB floppy and confuse
> everyone into thinking it's a different thing, of course.  Or maybe it
> should be the 1,440KB floppy, or the 1,475KiB floppy?  Neither of these
> help the situation.

The 1 440 KiB floppy is dead. Let it rest in pieces. The fact that a marketing 
department screwed up long ago by thinking that 1 440 kB equals 1.44 MB, 
which it would have done, had that really *been* 1 440 kB and not 1 440 KiB, 
is not a case against IEC prefixes. On the contrary, it may well be a prime 
example of a confusion that wouldn't have happened if the IEC prefixes had 
been adopted by then.

-- 
Magnus Holmgren[EMAIL PROTECTED]
   (No Cc of list mail needed, thanks)


pgpQnKqXRd0XO.pgp
Description: PGP signature

Re: Using standardized SI prefixes

[Alex Jones]

On Wed, 2007-06-13 at 14:29 +0100, Scott James Remnant wrote:
> Without the binary unit to consider, when we quote a drive as 1TB, we
> know that it has *at least* 1,000,000,000,000 bytes available.
> Depending on the drive, it may have anywhere between this and
> 1,099,511,627,776 bytes available.  It's actually more likely to have
> something strange like 1,024,000,000,000 available.

10% error is no good for me. You can continue to play the "at least"
card, but what about when it's more important if it is "at most"
something? And seeing as this error only goes up exponentially, at which
prefix do you draw the line and say "no more"?

And no-one uses floppy disks any more. Let's just bury them all and
forget about them. :D

> I see no problem with this "1TB" quote being approximate.  It's rounded
> anyway.  If you really want to know how many bytes are available, you
> can use this great unit called the "byte" which is accurate and not
> subject to change[0].

1 TB is not rounded. It means precisely 1 × 10^12 bytes, no more and no
less. If they want to actually put 1.024 TB on the disk then they can
say 1 TB (approx.) like any other industry (detergent, bacon, etc.).
-- 
Alex Jones
http://alex.weej.com/

Re: Using standardized SI prefixes

[Alex Queiroz]

Hallo,

On 6/13/07, Scott James Remnant <[EMAIL PROTECTED]> wrote:


The meaning of 1 TB depends on the context, and has always done so.



Wrongly.

--
-alex
http://www.ventonegro.org/


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Scott James Remnant]

On Wed, 2007-06-13 at 15:01 +0100, Alex Jones wrote:

> 1 TB is not rounded. It means precisely 1 × 10^12 bytes, no more and no
> less.
> 
No it doesn't.

The meaning of 1 TB depends on the context, and has always done so.

Scott
-- 
Scott James Remnant
Ubuntu Development Manager
[EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part

Re: Using standardized SI prefixes

[Bjørn Ingmar Berg]

On 13/06/07, Christof Krüger <[EMAIL PROTECTED]> wrote:

I'd really like to hear some real arguments against SI prefixes, besides
being ugly or funny to pronounce or just because "it has always been
like that". Advantages of using SI prefixes has been mentioned in this
thread. Please tell me the disadvantages so there can actually be a
constructive discussion.


So far in this discussion i honestly thought that the arguments
against SI prefixes were too obvious to bother mentioning.

Let me start with a dumb example:
For a child or uninterested commoner that flying critter is simply "a
birdie".  For those in the know exactly the same entity is a "Falco
peregrinus".
Even if simply calling it "birdie" or perhaps "falcon" would be
easier, more "user friendly" more "understandable for everyone" it
simply would not be /correct/.
Therefore it must stay "Falco peregrinus" in all contexts where really
conveying information matters.

Computers deal with numbers in base two.  Humans deal with numbers in
base 10.  When computers and humans interact (on a technical level)
humans must adapt to the computer, because computers can not.
Dealing with chunks of data, addresses, registers, etc. has to be done
in base 2.  Even if 1024 is "close enough" to 10^3 for a PHB or
marketing humanoid, that will never make those two numbers equal.  And
it must never be allowed to.  Computers, computer designers, computer
technicians and most computer programmers will always deal with the
_real_ base 2 numbers like 1024.

Another example.  Pi is an irrational number starting with 3.14
Sure, it would be easier to "standardize" it to 3.00.  Done deal.  It
would be easier to remember and more marketable.  It would also be
totally useless AND completely wrong.  AFAIK some very dumb people
actually managed to decree by law that pi was to equal 3.  They had to
stop doing that.

In the same was as with pi redefining or "standardizing" kilobytes and
megabytes would be totally useless AND completely wrong.  Computers
have always, do, and will continue to deal with their numbers along
the progression of 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, etc...
So, when dealing with computers, must we.

One does not redefine "Falco peregrinus" to "birdie" because "that
would make it more understandable for the commoner".  Ornithologists
need it to stay "Falco peregrinus" in the future.
One does not redefine pi to a value of 3 because "that would make it
more understandable for the commoner".  Mathematicians, architects
(and basically everyone else) need it to stay ~3.1415926535 in the
future.
One does not redefine kilobyte to mean 1000 (base 10) because "that
would make it more understandable for the commoner".  Real computer
people need it to stay 1024 (base 10).

A well-known and very common trait of language is that one given word
can often have more than one specific meaning.  When this is the case
you need a context to be sure.  This is considered normal, and never a
real problem.  This should hold true regarding computers and counting
as well.

Finally a personal and subjective thought.  At times one has to chose
whether to oversimplify facts and information to the point where
"everyone" understands it, (If this happens they DO NOT understand it;
they are given the illusion of understanding) or whether to educate
the public.  I am very convinced the correct solution is always to
educate the public.  The world is not flat.  The earth is not the
center of the universe.  Pi is not 3.  A kilobyte is not 1000; it is
1024 because that is the way computers work.


Regards,
Bjørn Ingmar Berg

--

blog.bergcube.net/

Re: Using standardized SI prefixes

[Scott James Remnant]

On Wed, 2007-06-13 at 12:51 +0200, Christof Krüger wrote:

> On Tue, 2007-06-12 at 15:52 +0100, Ian Jackson wrote:
> > shirish writes ("Using standardized SI prefixes"):
> > >   Please look at http://en.wikipedia.org/wiki/Binary_prefix .
> > 
> > Urgh, these things are ugly and an abomination.  We should avoid them.
>  
> I'd really like to hear some real arguments against SI prefixes, besides
> being ugly or funny to pronounce or just because "it has always been
> like that". Advantages of using SI prefixes has been mentioned in this
> thread. Please tell me the disadvantages so there can actually be a
> constructive discussion.
> 
User Confusion.

Most users do not know what a "tebibyte" is, and they do not care.  They
know that "a terabyte" is "about a million million bytes", and that is
sufficient.

Since you're rounding anyway, the loss of accuracy between "about a
million million bytes" and "just over a million million bytes" is not
significant.  Certainly not at the expense at having to teach users
another new unit.

Hard drives are bought in gigabytes, memory is bought in gigabytes, etc.
Quoting the same figures with a different unit in the operating system
is pedantry for its own sake.

Users have already learnt that the term "gigabyte" is approximate.

Introducing new units has only added confusion, rather than removed it.

Before the new units, we all knew that 1GB was an approximate figure and
likely to be (for bytes) based on a power of 2.  Now we have figures
quoted in GB and GiB, some of which are power of 10, some of which are
power of 2.  Some figures quoted in GiB are wrong, and should be in GB;
likewise some in GB should be GiB.  And we still have many figures in
both GB and GiB which are neither of the two!

Renaming the 1.44MB floppy helps in neither case; it is neither 1.44MB
or 1.44MiB.  One could name it the 1.4MB or 1.47MiB floppy and confuse
everyone into thinking it's a different thing, of course.  Or maybe it
should be the 1,440KB floppy, or the 1,475KiB floppy?  Neither of these
help the situation.

Without the binary unit to consider, when we quote a drive as 1TB, we
know that it has *at least* 1,000,000,000,000 bytes available.
Depending on the drive, it may have anywhere between this and
1,099,511,627,776 bytes available.  It's actually more likely to have
something strange like 1,024,000,000,000 available.

(And none of this takes into account partitioning and filesystem
overhead!)

I see no problem with this "1TB" quote being approximate.  It's rounded
anyway.  If you really want to know how many bytes are available, you
can use this great unit called the "byte" which is accurate and not
subject to change[0].

Scott

[0] Unless you're older than 25.
-- 
Scott James Remnant
Ubuntu Development Manager
[EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part

Re: Using standardized SI prefixes

[Caeles]

One more opinion:

If you consider a number more relevant than its nearest power of 2,
then somebody else will consider every digit of that number relevant.
In that case, don't use rounding by SI/IEC prefixes at all.
For an example see Bug #420716.

The first number, where the difference between base 1024 and base
1000 results in a greater inaccuracy than rounding to the next power
of 2, is 2^150 vs 10^45. According to the cited wikipedia article,
SI and IEC prefixes roughly go only half as far. So the difference
between SI and IEC prefixes is immaterial.


Regards,

  Mark Weyer


P.S.: I am not subscribed to the list


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Christof Krüger]

On Tue, 2007-06-12 at 15:52 +0100, Ian Jackson wrote:
> shirish writes ("Using standardized SI prefixes"):
> >   Please look at http://en.wikipedia.org/wiki/Binary_prefix .
> 
> Urgh, these things are ugly and an abomination.  We should avoid them.
> 
> Ian.
> 

I'd really like to hear some real arguments against SI prefixes, besides
being ugly or funny to pronounce or just because "it has always been
like that". Advantages of using SI prefixes has been mentioned in this
thread. Please tell me the disadvantages so there can actually be a
constructive discussion.

Christof Krüger

Re: Using standardized SI prefixes

[Magnus Holmgren]

On Tuesday 12 June 2007 19:57, Joey Hess wrote:
> I had generally assumed that most programmers were reaonsable and used
> powers of 2, but this thread is certianly changing my mind about *that*.

It's not that unreasonable. Humans generally count in base 10 - computers 
count in base 2.

-- 
Magnus Holmgren[EMAIL PROTECTED]
   (No Cc of list mail needed, thanks)

  "Exim is better at being younger, whereas sendmail is better for 
   Scrabble (50 point bonus for clearing your rack)" -- Dave Evans


pgppaW9Zr6ibG.pgp
Description: PGP signature

Re: Using standardized SI prefixes

[Wesley J. Landaker]

On Monday 11 June 2007 22:57:00 John H. Robinson, IV wrote:
> It does solve a real problem. It solves an ambiguity. Does k mean 1000
> or 1024? Does M mean 100 or 1048576?
>
> Answer: k mean 1 000
> ki means 1 024
>   m means 1 000 000
>   mi means 1 048 576
>
> No more ambiguity.

Except, don't forget that prefixes are case-sensitive. "ki" and "mi" aren't 
correct binary prefixes, and "m" means milli.

Instead you want "k", "Ki", "M" and "Mi" above.

-- 
Wesley J. Landaker <[EMAIL PROTECTED]> 
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2


signature.asc
Description: This is a digitally signed message part.

Re: Using standardized SI prefixes

[Wesley J. Landaker]

On Tuesday 12 June 2007 01:48:27 Josselin Mouette wrote:
> > Why do you think that the marketing materials for most hard drives
> > include the note that 1 GB = 1 000 000 000 bytes?
>
> Maybe because they are sold in the US, one of the 3 countries where SI
> units are not standard?

Even in the US all legitimate science and engineering is done in SI units.

-- 
Wesley J. Landaker <[EMAIL PROTECTED]> 
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2


signature.asc
Description: This is a digitally signed message part.

Re: Using standardized SI prefixes

[Ben Finney]

Scott James Remnant <[EMAIL PROTECTED]> writes:

> On Tue, 2007-06-12 at 15:50 +0100, Alex Jones wrote:
>
> > On Tue, 2007-06-12 at 09:24 +0100, Scott James Remnant wrote:
> > Especially nowadays with terabyte disks coming out and hitting the
> > consumer market, there is *no place* for 10% of ambiguity.
> > 
> a) terabyte disks are often just that, 1x10^12 bytes.
>
> b) quoting the disk as 1TB guarantees that you have at least 1x10^12
>bytes available.

Exactly. So when software quotes a file size in terms of TB, when it
actually means TiB, the ambiguity is significant.

-- 
 \"There are only two ways to live your life. One is as though |
  `\  nothing is a miracle. The other is as if everything is."  -- |
_o__)  Albert Einstein |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Eduard Bloch]

#include 
* Roberto C. Sánchez [Tue, Jun 12 2007, 03:43:29AM]:

> Why do you think that the marketing materials for most hard drives
> include the note that 1 GB = 1 000 000 000 bytes?  If the SI prefixes
> only ever held their *precise* meanings, then such clarifications would
> not be necessary.

Because the Windows Explorer kept displaying sizes with GB suffix while
meaning 2^9 bytes. Which is understandable because they didn't have a
better term back 15 years ago.

What is not really understandable is why this stupid naming has been
kept in Windows XP.

Eduard.
-- 
Wissen ist Macht, wir wissen nix, macht nix.
-- Uralter Spruch


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Eduard Bloch]

#include 
* Bernhard R. Link [Tue, Jun 12 2007, 12:18:22AM]:

> > Excuse me? Pretty simple example: you have only 2.03 GB (real GB)
> > remaining free space (seen in some disk info tool) on your harddisk and
> > you are fetching a 2GB file (2 fake GB, 2GiB in fact). So what, it
> > breaks about 99% and displays some very unexpected message.
> 
> Isn't uncompressed size filesystem dependent? (At least the space the
> package will need when being installed will be).

I was talking about the application itself and not the package format.

But yes, in Debian packages it has "never" been absolutely accurate IIRC.
I imagine that it would be possible to find workaround by using some
some internal representation of the file types and numbers in the
package and a guessing algorithm for the used file space.

But what for? Packages can even create temporary stuff during
installation which you cannot predict well, or even persistent data
(index caches etc.). So this information in the packages is not more
than a coarse grained estimation of the required disk space.

Eduard.
-- 
 TV ist Zeitverschwendung
* micsch muss auch nochmal seine TV-Karte einbauen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Martijn van Oosterhout]

On 6/12/07, Lennart Sorensen <[EMAIL PROTECTED]> wrote:

On Tue, Jun 12, 2007 at 06:25:22PM +0200, Josselin Mouette wrote:
> Prefixes are case-sensitive. Kilo is "k". (This is also why there is
> much less ambiguity with K used for kibibytes.)

Hmm, I used to think both k and K were accepted for kilo, but I can't
find anything that says K is accepted for use as kilo.


All the symbols in SI units have to be distinct, as combined units are
units also. Consider:

kWh = kilo-watt-hour = 3.6 MJ
Nm = newton-metre

The capital K is used for kelvin. So Km = kelvin-metre, which I
suppose would be the unit to measure the total temperature over a
length (product of temperature and length).

Sure, most people can guess what you mean from the context but that
doesn't make it right...

Have a nice day,
--
Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Mike Hommey]

On Tue, Jun 12, 2007 at 09:25:13PM +, Evgeni Golov <[EMAIL PROTECTED]> 
wrote:
> On Tue, 12 Jun 2007 15:42:08 -0300 Paulo Marcondes wrote:
> 
> > billion = 10^6 * 10^6 (IIRC, as used in Portugal - no jokes here!)
> 
> =10^12 :)
> 
> and Germany, France, former UdSSR, 

Anywhere where milliard is 10^9, basically...

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Evgeni Golov]

On Tue, 12 Jun 2007 15:42:08 -0300 Paulo Marcondes wrote:

> billion = 10^6 * 10^6 (IIRC, as used in Portugal - no jokes here!)

=10^12 :)

and Germany, France, former UdSSR, 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Paulo Marcondes]

2007/6/12, Josselin Mouette <[EMAIL PROTECTED]>:


Sure, this is why googling for "for" returns 7 billion entries.


billion = 10^9 or
billion = 10^6 * 10^6 (IIRC, as used in Portugal - no jokes here!)

further argument to use powers, not words to define multiples.

P.S.: I googled 'for' ~7*10^9 results.
--
PMarc:
Debian, GIS, gpsd, OpenWRT user and wannabe-devel
Lives @ -22.915 -42.224


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Steve Langasek]

On Tue, Jun 12, 2007 at 05:19:45AM +, Andrew M.A. Cater wrote:
> On Mon, Jun 11, 2007 at 02:32:35PM -0700, Steve Langasek wrote:
> > On Mon, Jun 11, 2007 at 10:15:25PM +0200, Josselin Mouette wrote:
> > > Le lundi 11 juin 2007 à 15:25 -0400, Joey Hess a écrit :
> > > > > You seem to fancy the K-is-1024--k-is-1000 convention

> > > > No, I hate that convention. K and k should only ever refer to 1024.

> > > /me waits for the day measuring jugs are graduated in powers of two,
> > > just to please a group of hackers who don't like SI units.

> > Shall I bring you a half gallon of milk to Scotland, then?

> > "Pff, base 10, the metric system is so archaic"

> The US gallon being the Queen Anne period wine gallon or 0.83 
> gallons? I'll stick to Imperial thanks - four pints will be fine in 
> anywhere in Scotland/England/Ireland/Wales and I'll get slightly more :)

US gallon, of course; that way you get powers of two from the ounce on up.

8 gallons to the kiloounce; 32 gallons to the kilogill.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Joey Hess]

Josselin Mouette wrote:
> The question is not whether to use powers of 2 or 10 (different software
> use both), but rather to use the good prefixes depending on that
> choice. 

It sounds like you've surveyed a lot of software in Debian and found
some that uses 2 and some 10 for data storage measurement[1]. What's the
breakdown look like between the two? The only software I know of that
uses powers of 10 is partman (which I'm pretty sure d-i has a bug report
about somewhere). But I have not surveyed the other software, aside from
a few things like ls that I use day-to-day and know use powers of 2. I
had generally assumed that most programmers were reaonsable and used
powers of 2, but this thread is certianly changing my mind about *that*.

-- 
see shy jo

[1] Bandwidth measurement is, as noted in this thread, a general
absolute mess and PITA.


signature.asc
Description: Digital signature

Re: Using standardized SI prefixes

[Lennart Sorensen]

On Tue, Jun 12, 2007 at 06:25:22PM +0200, Josselin Mouette wrote:
> Prefixes are case-sensitive. Kilo is "k". (This is also why there is
> much less ambiguity with K used for kibibytes.)

Hmm, I used to think both k and K were accepted for kilo, but I can't
find anything that says K is accepted for use as kilo.

--
Len Sorensen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Josselin Mouette]

Le mardi 12 juin 2007 à 12:19 -0400, Lennart Sorensen a écrit :
> Nope.  kelvin is a unit, not a prefix.  K as a prefix means kilo, so KB
> is kilo bell.

Prefixes are case-sensitive. Kilo is "k". (This is also why there is
much less ambiguity with K used for kibibytes.)

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: Using standardized SI prefixes

[Lennart Sorensen]

On Tue, Jun 12, 2007 at 04:20:42AM +0100, Alex Jones wrote:
> Then why bastardise an SI prefix? This surely serves only to confuse
> people. Why don't we invent a new word? Should we call it the
> "thousandbyte"?

Because computer people have always bastardised everything.  Booting,
window, mouse, etc.

> It is simply a convenient accident that 2^10 ~= 10^3. As I'm sure you're
> well aware, this approximation starts to become way off as you approach
> tera-. In fact, that's about 10% error, which is simply unacceptable.
> It's time to move on and accept that the approximation fails with big
> numbers.
> 
> And I suppose you think that differences such as that between the
> American and the English ton are acceptable and desirable. Let it be
> known that I strongly disagree with you here. :)

The drive makers screwed up.  They are the ones that should be fixed.

--
Len Sorensen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Lennart Sorensen]

On Mon, Jun 11, 2007 at 05:49:18PM -0600, Wesley J. Landaker wrote:
> Well, in SI units, KB never means kilobyte, and is not ambiguous at all; 
> it's a kelvin??bel. 

Nope.  kelvin is a unit, not a prefix.  K as a prefix means kilo, so KB
is kilo bell.  You better have small values or you are dealing with
something very very loud.  So yes already trying to apply SI units to
bytes has gone all wrong and they shouldn't have even tried in the first
place.

--
Len Sorensen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Magnus Holmgren]

On Tuesday 12 June 2007 16:52, Ian Jackson wrote:
> shirish writes ("Using standardized SI prefixes"):
> >   Please look at http://en.wikipedia.org/wiki/Binary_prefix .
>
> Urgh, these things are ugly and an abomination.  We should avoid them.

Purely emotional arguments. I think it's to a big extent just a matter of 
getting used to them.

Do you have anything to add that hasn't already been said?

-- 
Magnus Holmgren[EMAIL PROTECTED]
   (No Cc of list mail needed, thanks)


pgpSvfcE221IF.pgp
Description: PGP signature

Re: Using standardized SI prefixes

[Scott James Remnant]

On Tue, 2007-06-12 at 16:50 +0100, (``-_-´´) -- Fernando wrote:

> Actually bandwidth is mesured in bits per second and no bytes per second
> 
> On 6/12/07, Scott James Remnant <[EMAIL PROTECTED]> wrote:
> >Bandwidth should be quoted in true SI units over a metric of time,
> >e.g. kilobytes-per-second  (e.g. the average UK DSL upload speed is
> >250kbps == 250,000bps)
> 
Right; I got the example correct but thinko'd the text.

Scott
-- 
Scott James Remnant
Ubuntu Development Manager
[EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part

Re: Using standardized SI prefixes

[(``-_-´´) -- Fernando]

Actually bandwidth is mesured in bits per second and no bytes per second

On 6/12/07, Scott James Remnant <[EMAIL PROTECTED]> wrote:

   Bandwidth should be quoted in true SI units over a metric of time,
   e.g. kilobytes-per-second  (e.g. the average UK DSL upload speed is
   250kbps == 250,000bps)

Scott

[0] try converting a continual 8 Megabits-per-second to Gibibytes for
the day 
[1] !!! the UK sucks
--
Scott James Remnant
Ubuntu Development Manager
[EMAIL PROTECTED]

--
Ubuntu-devel-discuss mailing list
[EMAIL PROTECTED]
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss






--
BUGabundo  :o)
(``-_-´´)
GPG key 1024D/00967685
Linux user #443786

http://BUGabundo.net
http://BrinKadeiraS.BUGabundo.net

http://host.BUGabundo.net  --  http://alojamento.BUGabundo.net

From 1€ / month


Crazy Domain Insane (200GB disk, 2TB bw, 6.00€ ($7.95)/month)

at http://www.dreamhost.com/r.cgi?249195/signup
50$ discount with promo code "BUG50" on all plans
Free lifetime domain with promo code "BUGDOMAIN"

Re: Using standardized SI prefixes

[Scott James Remnant]

On Tue, 2007-06-12 at 15:50 +0100, Alex Jones wrote:

> On Tue, 2007-06-12 at 09:24 +0100, Scott James Remnant wrote:
> > The difference is a sufficiently small percentage, that most users will
> > not care.
> 
> No, like I said in my earlier post, the error grows quickly. As 1.024^x,
> in fact.
> 
> x = 1 kibi vs. kilo   2.4%
> x = 2 mebi vs. mega   4.9%
> x = 3 gibi vs. giga   7.4%
> x = 4 tebi vs. tera   10%
> 
> Especially nowadays with terabyte disks coming out and hitting the
> consumer market, there is *no place* for 10% of ambiguity.
> 
a) terabyte disks are often just that, 1x10^12 bytes.

b) quoting the disk as 1TB guarantees that you have at least 1x10^12
   bytes available.

   Depending on the actual disk model, you may have 1x2^40 bytes, or
   1024x10^9 bytes, or 1024x2^30 bytes available - or in fact anything
   in between.

   Only by quoting 1TB are you not potentially violating a guarantee of
   available bytes.

   It is always better to underquote than overquote.

c) One of each "binary" unit, rounded with no decimal places, is
   identical to the equivalent SI unit.

   1YB = 1x10^241YiB = 2^80 =~(0 dec place) 1YB
   1ZB = 1x10^211ZiB = 2^70 =~(0 dec place) 1ZB
   1EB = 1x10^181EiB = 2^60 =~(0 dec place) 1EB
   1PB = 1x10^151PiB = 2^50 =~(0 dec place) 1PB
   1TB = 1x10^121TiB = 2^40 =~(0 dec place) 1TB
   1GB = 1x10^9 1GiB = 2^30 =~(0 dec place) 1GB
   1MB = 1x10^6 1MiB = 2^20 =~(0 dec place) 1MB
   1kB = 1x10^3 1KiB = 2^10 =~(0 dec place) 1kB

d) There are few places where binary units should be exposed to humans
   anyway. 

   Bandwidth should be quoted in true SI units over a metric of time,
   e.g. kilobytes-per-second  (e.g. the average UK DSL upload speed is
   250kbps == 250,000bps)

   Therefore Traffic should also be quoted in true SI units to make
   conversion between bandwidth and traffic easy[0]  (e.g. the web
   server shifted 86.4GB today =~ 86,400,000,000 bytes)

   Therefore File Sizes should also be quoted in true SI units, because
   they consist the majority of traffic; and to allow easy determining
   of the speed of upload (my 10GB file will take ~90 hours to upload on
   my DSL line[1])

   Therefore Disk Sizes should also be quoted in true SI units, because
   they are used to store files, and because the ATA standard says so (I
   can fit 10 10GB files on my 100GB disk).

   Memory usage should be quoted in true SI units, since executable
   programs are derived from files (this 10MB program binary will use
   10MB of RAM)

   Therefore Memory sizes should also be quoted in true SI units (I can
   fit 50 10MB programs, and 50 10MB files in my 1GB of RAM)


   The only real places I can see are where an implementation factor
   actually results in things using a true power of two, for example
   filesystem block sizes or disk sector sizes, etc.  And in these
   cases, the multiple of two only extends as high as the "block" or
   "sector" unit.

   A 1.5GB file will use 366,211 blocks of 4096 bytes.  Since you're
   referring to a technical implementation detail, which is only
   interesting in terms of accuracy, using phrases such as "kibiblocks"
   is ridiculous.

Scott

[0] try converting a continual 8 Megabits-per-second to Gibibytes for
the day 
[1] !!! the UK sucks
-- 
Scott James Remnant
Ubuntu Development Manager
[EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part

Re: Using standardized SI prefixes

[Ian Jackson]

shirish writes ("Using standardized SI prefixes"):
>   Please look at http://en.wikipedia.org/wiki/Binary_prefix .

Urgh, these things are ugly and an abomination.  We should avoid them.

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Alex Jones]

On Tue, 2007-06-12 at 09:24 +0100, Scott James Remnant wrote:
> The difference is a sufficiently small percentage, that most users will
> not care.

No, like I said in my earlier post, the error grows quickly. As 1.024^x,
in fact.

x = 1   kibi vs. kilo   2.4%
x = 2   mebi vs. mega   4.9%
x = 3   gibi vs. giga   7.4%
x = 4   tebi vs. tera   10%

Especially nowadays with terabyte disks coming out and hitting the
consumer market, there is *no place* for 10% of ambiguity. This was
precisely my point earlier. "Back in the day", nobody cared for 2.4%
error because all they ever measured anything in was kilo-somethings.
-- 
Alex Jones
http://alex.weej.com/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using standardized SI prefixes

[Martijn van Oosterhout]

On 6/12/07, Adam Borowski <[EMAIL PROTECTED]> wrote:

Except, I did not claim that one of the versions is superior.  What I stated 
was:
1. English is a language where the correct usage is what most people use,
2. "kilobyte" is preferred over "kibibyte" by a vast majority of those whose
   communicate using means accessible to Google search


I didn't want to get involved with this, but it's seems clear to me
that both KB and KiB would both be written out as "kilobyte" in most
cases because most of the time it simply doesn't matter.

It also seems clear to me that in cases where accuracy matters you
should use the prefix that applies. However, I don't think any of the
examples given it really matters, except possibly the DVD sizing, but
in that case you'd just drag it and see if it fits.

(Disclaimer: I'm from a metric country and bytes are really the only
thing where there is ambiguity as to what the 'k' means).

Have a nice day,
--
Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]