--===============1034650826==
Content-Type: multipart/signed;
  boundary="nextPart1783084.lmDak193xI";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1783084.lmDak193xI
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Thursday 09 July 2009 00:53:17 Josh Berry wrote:
> Nor does it mean what the IEEE, SI units, etc. define it to mean.  The
> IEEE is, in fact, pretty clear that "kilo" =3D 1,000, "mega" =3D
> 1,000,000, etc. now that the binary units have been standardized by
> the IEC.  (see: http://physics.nist.gov/cuu/Units/binary.html )

So now that the IEC has said so, Arora is leading me astray when it says a=
=20
file is 64.7 KB?  My flash cards aren't really 4GB?

You can thump the specs on the desk all you want but you can't just change =
the=20
definition of the units in this context without at least some more buy-in f=
rom=20
just KDE, a point you yourself have made in your response below when you=20
mention doing unprecedented things.

> Except it is NOT a new unit.  It is correcting a mistake that was made
> decades ago and propagated by lazy software developers.

"decades ago".  I mean, seriously, listen to that.  Right or wrong, the=20
definition of these units are backed up by *decades* of actual usage, so=20
you're going to have a very hard time convincing a lot of people that their=
=20
values magically changed once some IEC engineers signed a form to issue a n=
ew=20
standard.

And it's unfair to say "propagated by lazy software developers" because tha=
t's=20
what the unit was (at least for memory capacities).

> Unfortunately, the meaning of the *B units has become sufficiently
> diluted to the point where we now have two equally-passionate groups
> of people arguing over what they mean, and for all the messages that
> have flown back and forth, we are no closer to agreement.  If
> anything, the two sides have become entrenched and I don't see how
> further discussion will get us closer to an answer.
>
> Given the above, I've changed my mind -- I no longer think KDE should
> have any units other than the *iB units.  Those are the only units we
> seem to be able to agree on.  The meaning of the *B units has been
> sufficiently diluted to the point that NO MATTER what definition we
> pick, someone will likely misinterpret them.

Well there is apparently interest in having real decimal units.  My only re=
al=20
complaint is that it can't (yet) be the "kilobyte".

Go out and look on Google or Yahoo about kilobyte being 1024.  You'll find=
=20
pages telling you to impress your friends with the little-known fact that a=
=20
kilobyte is 1024 bytes, dozens of articles "explaining" kilobytes, megabyte=
s,=20
etc.  If anything, the unit has become more ubiquitous to mean 1024 in=20
computer applications over time, not less.

http://www.oftc.usyd.edu.au/edweb/networks/information/byte0.html
http://www.sharpened.net/helpcenter/answer.php?40
http://blogs.msdn.com/powershell/archive/2006/12/15/kb-1024-vs-1000.aspx
http://www.faqs.org/qa/qa-4830.html
http://answers.yahoo.com/question/index?qid=3D20080911025506AAa0gsF

> > How about we name it dkB (note the lowercase k), with equivalents all t=
he
> > way up (dMB, dGB, dTB, etc.)?  That way people who really do want to see
> > units in powers of 10 can, with no uncertainty as to what units they are
> > getting, and those of us who just want to go on with our lives can
> > continue to use KiB (or its misspelling KB).
>
> I think we already have too many units.  KDE really *would* be doing
> something unprecedented with this, as it really does break with what
> everyone else is doing (nevermind the standards).

> You objected before
> to confusing users with KB =3D 1000 -- I think this would be an even
> worse source of confusion.

You can't have it both ways.  It can't be OK to confuse users by changing K=
B=20
or forcing KiB and simultaneously not OK to confuse users by allowing a=20
explicitly base 10 kedibyte (I'm sure you'll notice I just made up that nam=
e=20
on the spot).  You will confuse thousands more users (backed up by decades =
of=20
experience using the units) by making KB base-10 than you will by showing n=
ew=20
units which the user has to manually select.  Even worse, the user would ha=
ve=20
to have manually selected the KB, and therefore been seeking it out in the=
=20
first place!  This user was probably expecting the KB he's used for decades=
=2E =20
Talk about confusing.

At the same time it's can't be OK for KDE to do something unprecedented wit=
h=20
units on the one hand (1000 byte KB) but not on the other hand (dkB).

> We need to disambiguate the existing units, not make up new ones.
> That's why "KiB" et al were created in the first place.

Well I'd argue that my proposal is exactly in line with existing practice. =
=20
Somehow computer users survived for decades with 1024-byte kilobytes before=
 it=20
became a major issue with mass storage manufacturers.  So we disambiguated =
by=20
making up new units.

But now we still have a disconnect over the old units, so I say we could=20
disambiguate the other way.  Perfect Solomon's logic, we have KiB and then =
we=20
have kdB.  Actually that could be confused easily with deci-, let's see=20
here... how about =E2=86=81 to mean explicitly decimal bytes?  (And from th=
ere, k=E2=86=81,=20
M=E2=86=81, G=E2=86=81, etc.)  (In case it doesn't show up, it's code point=
 U+2181, Roman=20
numeral five thousand, which looks to me vaguely like a D-within-a-D).

But less snarkily if you take one thing away from this email, let it be thi=
s:=20
Right now KB predominantly means, regardless of what IEC and SI may /want/,=
=20
1024 bytes.  It would not be good form for KDE to be the project to throw=20
grenades at their users (some of whom have used 1024 byte KBs for years if =
not=20
actually decades).  With the introduction and gradual uptake of -ibibytes t=
hen=20
perhaps it's something that can be rethought at the KDE 5 or 6 timeframe bu=
t=20
now is not the time to make the switch.

If enough users want the decimal units then there's no reason not to allow =
it,=20
but I don't want us to get caught showing KB meaning 1000 when the user thi=
nks=20
it means 1024 so it needs to be very clear.  After all, users have taken ha=
rd=20
disk manufacturers to court over just this very topic.

Regards,
 - Michael Pyne

--nextPart1783084.lmDak193xI
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iQIcBAABCAAGBQJKVYLUAAoJEAuvDJx7auny1U0P/2BBgIbKaqgPoC9Mph6LDhKc
2e3XMJ0GS/K4NTJlSa+v2ptSX3H4F0+JChWfvFHJdMiQzk2vYe0q7RH9H6adH50i
RnBFXvh7/GDxMZksqp83eJmVf8cOV/PpfJDrkLv+zxvrkd5lbrMJomZ8vOzPKISX
U4F/BBB4/gF1BTkdRHk1Uvs3LnmUhyNU52h7l9I0JVxXUZJt0yZYHS/HXipx0YFU
c9TT3gXggWYzyU/g8YS3XVAE1xnJOSrljL/XgQ9y1ks86z1SNq7Jncufz5x8aGeB
7yzUY+5qJzRwwFDek5WsBYBJrAgmxsMYeI+PjE9SDVifhaKxUhVlqAIHiDnQqPPO
Je/vjwNRUnEtAUtscsG+s2hdvN4dCJhsIjh2vZHxsmTbrpa37z8R+DkeWMFMgwI1
c2evGngGnxrxsiuzqW8awO6kQSwohp/EKQjZfW1WvvG1WYuHaUEy58PAddH8WzlR
xB2Wc6XyTRHKNKJ+8w8CCE0rQoe613nZka7y1WB0r7k59XruyigkSdATu5Zsmlzp
aiI0bfqIkDeQxRkfKxLmGywjPDuK6ay4YBbQjDSb/PG7SVoctUtqzlLWp+iodD+3
oCWhTDmVvL3R+ram6fHAqY2I7R/eBc0PK72kIyq5RyU2QJ30l7N4UszmYlcS5ZUs
Xt+rYiUCbERr137B9Ttw
=c4uv
-----END PGP SIGNATURE-----

--nextPart1783084.lmDak193xI--

--===============1034650826==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

--===============1034650826==--