[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Using standardized SI prefixes



On Tue, 19 Jun 2007, Eduard Bloch wrote:
#include <hallo.h>
* 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	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

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



Reply to: