GeneralThis forum is for non-technical general discussion which can include both Linux and non-Linux topics. Have fun!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I know the how and why there is a difference between Metric file sizes and standard file sizes. I even understand the difference in the transfer file sizes. But really what the computer world needs is to adopt bits instead of bytes. this would save a lot of confusion.
A standard example of confusion is buying a hard drive. Say you buy a 60 gig hard drive. it is 60 million bytes. But in file size of the real world a mega byte is not 1000 bytes its 1024. and a gigabyte is 1024 megabytes. so in real world use the computer will tell you that you actually have a 54 gig Hard drive.
Another confusion is in transfers. So I am trying to transfer a file that is 200 megs. Now the files is truly 204,800 bytes. so the file is transferring 200 megs at 10 kB(ytes)ps.which is 80 kb(its)ps but the problem is when you hit 125 kBps it changes into mbps which is not as big of a number as mBps and even then would the transfer rate take in effect for 1024?
Now on my local computer transferring that file to a network file server. I get 4.7 MBps but is that metric 1000 bps or standard 1024 bps? I am thinking it means metric. Because the transfer of files is always takes longer than they should. If the file is 200 MB and the transfer is 4.7MBps then a file should transfer in 43 seconds. But its takes like 5 minutes.
So what I say is to change the whole system to at least metric bytes if not metric bits. It would take a while for everything to catch up on this idea. But really its just a system of measuring. Lets drop the occasional use of 1024 and just always program in 1000. This way we know absolutely how the transfers and file sizes will transfer.
Last edited by waterox; 02-27-2007 at 05:16 PM.
Reason: somehow I mis-spelled transfers in the title
I can understand you wanting to standardise it, but I don't see why you want to standardise a system based on powers of two to numbers that are powers of ten.
I can understand you wanting to standardise it, but I don't see why you want to standardise a system based on powers of two to numbers that are powers of ten.
Ok the powers of 2 is just mainly a doubleing up of the previous power. Eventually we get to 1024 which is called a kilobyte which technically represents 1000 bytes. But a byte in truth is the smallest usable number. So why do we STILL need to stick with the standard of 1024. 1024 was decided on to be the standard. After that they stuck with it. Why? Is there a good reason that the place marker. I mean a byte represent 256 the number of ascii characters you can make. right? 1024 is 4 units of 256. So does 4 bytes actually make up a bit of code above ascii? If so couldn't we make an abitrary name for that standard of measure.
This is what I am talking about. Its a standard of measure. But not all of them match and drives me crazy. Ok so we need 1024. So lets stop using bits. At ALL. Ok so in transferring in the old days. A modem passes modulation of sound and silence. The literal reference of a bit. So transfering started in the bits. When transfering from one drive to another its in bits. So this means that transfers are in bits until they reach a byte. But why go back to bits when you reach 1024 bits and call it mbps? 1.5mbps is not 1536 bytes PS its 187.5 kBps. because the measure is in this weird rounding down system that someone came up with. And everyone agrees on.
I am saying pick a standard then use metric numbers to measure all of those. In every situation. bit bytes or the new standard the 1024 bits = a barq. Yeah that sound good. This hard drive is 100 giga barqs which is 1.024,000 bits. My network transfers at 10 kBarq per second. That means my 200 mega barq file will transfer in so and so seconds..... it would be much easier. trust me.
I may be insane. But so was the first person who suggested planets go around the sun.
Well, the above convention allows for either to be used as appropriate.
So, when it's handy to be using the binary-based round numbers, we use those. When it's handy to use the denal-based ones, we use those. And, provided everyone sticks to that notation, we all know what each other's on about.
1024 was picked because it's the closest binary round number to 1000. 1024 is 2**10. 1000 is 10**3, which is why it's used as a round number in the denal system.
It's 2**3 + 2**5 + 2**6 + 2**7 + 2**8 + 2**9 in binary. That isn't a round number.
bits is usually used in transfering because not all systems have 8bit-bytes. Some have 7bit bytes, 2bit-bytes, and even 10bit-bytes. Depending on purpose. So bit's are used as a more convenient way of calculating speed of a transfer.
One thing is that after Ki, Gi have been introduced not everyone knows about them and some softwares treat K as Ki. And old software exist that this has not been changed in. Eventually it will all be changed.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.