Creo que la implementación se hace a toda prisa. Ver aquí:(usar la traducción de Google de Chrome)
https://www.linux.org.ru/forum/general/12078555
Entonces, hay lugares que solo leen .lst
ignorando base.xml
pero la información que contienen no es idéntica, y supongo que xml
es más completo, pero no estoy seguro.
Старые версии free
, такие как используемая в CentOS 6, отображают не более десяти цифр для каждого значения. В отображаемом «1641154969» отсутствует последняя цифра. Это было исправлено в версии 3.3.10 ; free
теперь отображает до одиннадцати цифр, что достаточно для одного эксбибайта памяти. (Я не проверял, но изменения в версии 3.3.0, если не раньше, могли решить и эту проблему.)
Несоответствие между 16 миллиардами байтов и отображаемым «15G» объясняется тем, что масштабирование здесь выполняется в степени двойки; 16411549690, разделенное на 1024×1024×1024, равно 15,284, что отображается как 15. Текущие версии free
добавляют i
к единице, чтобы было ясно, что они используют двоичные префиксы .
Этот вопрос объединяет два отдельных классабайтовых единиц , а именно десятичныеG гигабайты и двоичныеGi бибайты:
Prefixes for multiples of
bits (bit) or bytes (B)
Decimal Binary
Value SI Value IEC
1000 10^3 k kilo 1024 2^10 Ki kibi
1000^2 10^6 M mega 1024^2 2^20 Mi mebi
1000^3 10^9 G giga 1024^3 2^30 Gi gibi
Команда free -h
печатаетгибибайт, тогда как free -b
печатает байт . Выполняя математику, (сначала добавляйте суффикс 0
к количеству байтов, чтобы компенсировать ошибку free
, отмеченную в ответе Стивена Китта ):
echo $(( 16411549690 / (10**9) )) # gigabytes
echo $(( 16411549690 / (2**30) )) # gibibytes
Выходы:
16
15
Продавцы жестких дисков использовали эту распространенную путаницу, и один поставщик даже оказался в проигрыше в коллективном иске. См. Orin Safier против Western Digital Corporation , в котором недовольным покупателям в 2006 году было присуждено 30 долларов за программное обеспечение для резервного копирования, а не настоящие деньги, каждому за их проблемы.