{"action":"created","issue":{"url":"https://api.github.com/repos/hishamhm/htop/issues/201","labels_url":"https://api.github.com/repos/hishamhm/htop/issues/201/labels{/name}","comments_url":"https://api.github.com/repos/hishamhm/htop/issues/201/comments","events_url":"https://api.github.com/repos/hishamhm/htop/issues/201/events","html_url":"https://github.com/hishamhm/htop/issues/201","id":84237518,"number":201,"title":"MB, MiB and M; binary prefix standards and IEC 80000-13:2008 vs JEDEC 100B.01.","user":{"login":"EliteTK","id":4272014,"avatar_url":"https://avatars.githubusercontent.com/u/4272014?v=3","gravatar_id":"","url":"https://api.github.com/users/EliteTK","html_url":"https://github.com/EliteTK","followers_url":"https://api.github.com/users/EliteTK/followers","following_url":"https://api.github.com/users/EliteTK/following{/other_user}","gists_url":"https://api.github.com/users/EliteTK/gists{/gist_id}","starred_url":"https://api.github.com/users/EliteTK/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/EliteTK/subscriptions","organizations_url":"https://api.github.com/users/EliteTK/orgs","repos_url":"https://api.github.com/users/EliteTK/repos","events_url":"https://api.github.com/users/EliteTK/events{/privacy}","received_events_url":"https://api.github.com/users/EliteTK/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":5,"created_at":"2015-06-02T22:18:36Z","updated_at":"2015-06-08T22:01:31Z","closed_at":null,"body":"Ok, here goes.\r\n\r\nI would like to kindly ask if it would be possible to standardise the usage of binary prefixes for memory measurement in htop to use the IEC 80000-13:2008 standard and its accompanying set of binary prefixes.\r\n\r\nIt has always struck me as annoying that whenever I find software which attempts to measure memory, and I see the dreaded \"MB\" I am left wondering constantly whether the software really means MB in the SI prefix sense of a million bytes, or whether it means, in the far more colloquial sense 1024^2 bytes. This is especially annoying when no information is given about which logic the measurement follows, and no option is given to also display the value in plain bytes.\r\n\r\nThis is possibly why there are now two standards to try to settle this, IEC 80000-13:2008 which outlines the following prefixes:\r\n\r\n| Short | Prefix | Bytes |\r\n|----|----|----|\r\n| Ki | Kibi | 1024 |\r\n| Mi | Mebi | 1024^2 |\r\n| Gi | Gibi | 1024^3 |\r\n| Ti | Tibi | 1024^4 |\r\n| Pi | Pebi | 1024^5 |\r\n| Ei | Exbi | 1024^6 |\r\n| Zi | Zebi | 1024^7 |\r\n| Yi | Yobi | 1024^8 |\r\n\r\nAnd JEDEC 100B.01 introduced the following definitions:\r\n\r\n| Short | Prefix | Bytes |\r\n|----|----|----|\r\n| K | Kilo | 1024 |\r\n| M | Mega | 1024^2 |\r\n| G | Giga | 1024^3 |\r\n\r\nSomewhere along the line, the units: K, M and G also started to be used alone, without an accompanying B, I think I read somewhere once that these were standardised by GNU at some point, but I could not find any information now.\r\n\r\nIn any case, it appears that currently htop uses both the JEDEC standard, and in some cases the shorthand M to mean 1048576 Bytes.\r\n\r\nThere are reasons for why staying with the JEDEC standard might be helpful, this might be less confusing for people not familiar with the other standard, and it appears quite popular.\r\n\r\n\r\nHowever, I feel that there are great shortcomings of the JEDEC standard.\r\n\r\nFirstly, it is easily confused with SI prefixes which are a long standing standard for prefixing SI units, units which are commonly referred to as \"Metric.\" It seems strange that for some unknown reason, when we start talking about memory, we should suddenly switch to a completely different definition of a term. What if you want to actually say 1000 Bytes, you can no longer say kilo because someone may confuse it for 1024 bytes. (This can't be confused on paper since the metric prefix shorthand for kilo is k, where as the JEDEC shorthand is K but the point stands for both mega and giga.) Even NIST frowns upon the misuse of SI prefixes for anything but metric applications.\r\n\r\nSecondly, it has the shortcoming in that it only defines 3 multiples. In the modern day and age, we more and more often have to deal with amounts of data in multiples of 1 000 000 000 bytes. This might not be the case for computer memory yet (which is currently only relevant in htop) but maybe one day htop might expand to measuring disk space or we actually do start using multiples of 1 000 000 000 bytes of data and we will need the extra definitions.\r\n\r\nFinally, I feel that as htop is mainly centred around power users who spend a lot of time in a terminal, those users are already quite likely to be surrounded by applications which use Mega to mean 1 000 000 and Mebi to mean 1024². This is why I feel there is no serious reason to be different and I think it is time to switch to the IEC standard.\r\n\r\n\r\nIf however, switching over the few areas of code which do use MB to MiB is not feasible for whatever reason, it would at least be helpful to put a message, somewhere, informing any curious users about which exact standard the application follows, so that in the case that the user does need to know, they do not need to delve into source code to figure it out.\r\n\r\nEdit: Whoops, that was meant to be KB, MB and GB not K, M and G.\r\nEdit2: Wait, never mind, it was right in the first place."},"comment":{"url":"https://api.github.com/repos/hishamhm/htop/issues/comments/110154651","html_url":"https://github.com/hishamhm/htop/issues/201#issuecomment-110154651","issue_url":"https://api.github.com/repos/hishamhm/htop/issues/201","id":110154651,"user":{"login":"hishamhm","id":245621,"avatar_url":"https://avatars.githubusercontent.com/u/245621?v=3","gravatar_id":"","url":"https://api.github.com/users/hishamhm","html_url":"https://github.com/hishamhm","followers_url":"https://api.github.com/users/hishamhm/followers","following_url":"https://api.github.com/users/hishamhm/following{/other_user}","gists_url":"https://api.github.com/users/hishamhm/gists{/gist_id}","starred_url":"https://api.github.com/users/hishamhm/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/hishamhm/subscriptions","organizations_url":"https://api.github.com/users/hishamhm/orgs","repos_url":"https://api.github.com/users/hishamhm/repos","events_url":"https://api.github.com/users/hishamhm/events{/privacy}","received_events_url":"https://api.github.com/users/hishamhm/received_events","type":"User","site_admin":false},"created_at":"2015-06-08T22:01:31Z","updated_at":"2015-06-08T22:01:31Z","body":"> Sorry, but what consistency are you refering to?\r\n\r\nFirst, internal consistency, as the current UI currently uses \"M\" in some places and \"MB\" in others. Then, consistency with the other GNU userland tools, which use K, M and G based on powers of 2 (coreutils in particular).\r\n\r\nParaphrasing the original past, htop is indeed centred around users who spend a lot of time in a terminal, and those users are surrounded by applications which use M to mean 1024² (see standard commands `ls -h`, `du -h`, `free -h`...). This is one of the reasons why I feel there is no sufficient motivation to be different.\r\n\r\n> Okay, so assuming you go with M, which is SI prefix for 'mega'. I assume all memory measurement must be measured in 1000 and not 1024?\r\n\r\nNo, I will not change the meaning of \"100M\" displayed on the UI from one release to the next."}}