(Pardon the joke, but while the "m" obviously means "M" from context, I really wish people -- especially computer engineers -- wouldn't say bits when they mean something eight times as large.)
I think you have a good point. The whole reason for standards (like SI units) is so that people don't need to guess or interpret. I don't get why this was downvoted.
A bit isn't a divisible unit, so nobody is going to be confused as to whether "mb" stands for "millibits". As for the capitalization of "b", if we're going to be pedantic then we should say "Mo" for "megaoctets", since "byte" is, as far as IEEE standards are concerned, of ambiguous length. But I think we can trust people enough to not spend too long puzzling over whether "mb" means megabytes or megabits, just as we can trust them to assume that byte implies eight bits in this context.
What ? Sure it is. When you measure the information content (or, the entropy) of a message, you very frequently get non-integer numbers of bits per (character/unit/message/whatever).
Written english, for instance, has 1.46 bits of information per character.
> But I think we can trust people enough to not spend too long puzzling over whether "mb" means megabytes or megabits
Please don't assume this. I have the great pleasure working with network Engineers, who have apparently globally decided that bits are a perfectly reasonable measurement of throughput and react very differently to speed in Mb/s and MB/s. I'm not trying to be pedantic or say that this is how it should be, I'm just saying that people really do use both units and it is horribly confusing and anything you can do to not be ambiguous is appreciated.
Well, no. If we're going to be pedantic, we should say MiB (mebibytes), because file sizes on disk are expressed in multiples of powers of 2, but the SI prefixes are multiples of 10.
So a 1 megabyte file (as reported by the file system) is actually 1048576 bytes, which technically - sorry, I mean pedantically - speaking, is 1 mebibyte.
To make matters worse, disk manufacturers use the decimal prefixes, so our nice 1 terabyte drive is 931 mebibytes, but is reported by the file system as 931 megabytes (not MiB).
Finally, memory manufacturers use the binary prefix, so 1 megabyte of RAM is actually 1 mebibyte (1048576 bytes).
A bit of a mess, no?
All the above is, IMHO, a consequence of imprecision. If we get used to being loose with our terminology, we risk carrying that attitude over into our work product, with sometimes regrettable results.
So I'll continue to strive to be pedantic (translation: precise).
I didn't know OS/X used the decimal prefixes, but that just means it's less true, not untrue. There are still many more systems out there that use the binary prefix. I imagine most *nix, and not sure about Windows. And RAM is still power of 2.
I don't think it's terribly user hostile to express sizes as powers of two when you work with these kinds of numbers for a living, especially when it's near the bare metal (Erlang binary data type FTW!)
But I do think it's user hostile to have two different units depending on what you're looking at. If it were all decimal or all binary, it would be much easier.
Agreed. Fun fact: Wolfram alpha understands Mebibytes, which is useful if you want to quickly convert between networking specs (say megabits) and "real" computer units.
Then again, maybe doing more simple math by actually using one's brain wouldn't hurt either. :)
Edit: And yes, I'm aware that you'll never get the converted speed of what is written on the network device's box. But sometimes it's nice to have an upper limit you can compare to at least.
Many, many wire protocols use 5 bits of bandwidth to send 4 bits of information, for various reasons. So dividing by 10 gives you a better estimate.
Of course when gigabit became a thing, your practical throughput was more like 75 MBps for a very long time, and being off by 25% in capacity planning is a pretty big error (one I've seen numerous engineers make, and a few make both, which means you're off by 40%)
After using many Unix tools that have this convention, I'm ok with 10 M referring to 1010241024 bytes (10 MiB), contrasted with 10 MB meaning 10,000,000 bytes.
This is gatekeeping, since the message is coded to be obvious to those "in the know" (of course mb means mebibyte!) but is a barrier to those who are trying to learn more (mb probably means megabits per second? it's a unit for measuring download speed? why is the 's' left off?)
This is putting the burden of collaboration in the wrong place: it shouldn't be a question of, can we expect a reasonable engineer in the industry to understand this unambiguously (with some deductions); but rather, can I hold down the shift key when typing the abbreviation for megabytes.
Obviously this depend on the actual audience, don't bother following this in team chat where speed is more important than clarity.
Because we solve practical problems, and do not nit pick of what is technically correct. We are not drones and easily understand that in this context it's megabytes.
Just look at all that "technically it's mebibytes bla bla bla" in replies. No one cares. Write some code. Or better - go outside.
space launches have crashed because of confusion over standard units.
in that case it was confusion between metric and certain fantasy engineering units, but an error of 1000/1024 will cause troubles just as badly.
so with that attitude maybe don't write that code, and better stay inside or a rocket might fall on your head.
but for serious, that correction probably has taught more than 10 people the difference between uppercase B = bytes, lowercase b = bits, uppercase M = mega = 1 000 000, lowercase m = milli, MiB = mebibyte = 1024 x 1024 bytes = 1 048 576 bytes, or at least made them aware of the important fact there is a difference. while your pedantry about nitpicking has taught nobody anything except to always be alert cause there's people like you that like to offload mental ballast and use wrong units because they insist their errors can be inferred and corrected from context... which is an important lesson also, but as a warning, not to defend the behaviour.
You should have included the whole window in the screenshot to prevent confusion: http://imgur.com/a/e2wb3
Specifically to those who don't use iTunes Connect, this page is titled "Estimated App Store file sizes for Build", and the (?) callout says "This is the amount of disk space the app will take up on the customer's device."
Then that's pretty confusing when the (?) button next to Install Size says "This is the amount of disk space the app will take up on the customer's device."
I'm not sure the same can be assumed for Apple based on several things such as internal secrecy, differing organisational hierarchies, their willingness to focus on things that aren't tangible metrics like end user file download size.
Between the org and culture differences I'm just not so sure Apple can be safely assumed as similar as you expect.
None of the things you mention change the fact that if you increase the IOS system image size by 3x, it will likely no longer fit in the default firmware partition :)
(Pardon the joke, but while the "m" obviously means "M" from context, I really wish people -- especially computer engineers -- wouldn't say bits when they mean something eight times as large.)