Вышел free-classic-ng 0.0.2.

Можно указывать опции [-k|-m|-g|-t] для переключения между единицами.

Маловато опций, добавь все метрические префиксы от «кекто» до «кветта» :)

Рановато ещё. За 20 лет кол-во оперативки в моём системнике увеличилось всего в 128 раз. Такими темпами только через 40 лет до людей начнут доходить петабайты оперативки. Там и можно будет обновить скрипт.

62.7256851196289 GB

Это 64231.10156249999 MB

Это 65772647.99999999 kB

Это 67351191551.99999 B

Это 538809532415.99994 b (или как там биты обозначаются).

Отсюда вопрос: как назвать величину в 0.00006 бита?

Слишком длинное название и перл в зависимостях - не одобряю.

Отсюда вопрос: как назвать величину в 0.00006 бита?

60 микробит же.

только через 40 лет до людей начнут доходить петабайты оперативки

Но ведь уже сейчас, на предложения воспользоваться разными софтовыми улучшалками, типа zram, zswap, uksm и т.д. и т.п., звучат возгласы «просто добавь памяти», как будто у них там гуттаперчевые возможности железа под «петабайты оперативки». )

Здравствуйте, дорогие сторонники того, как free выводил кол-во используемой памяти до того, как в нём это поломали.

Хоть бы рассказал для тёмных, что там поломали.

на Perl 5

Фу! Не Паскаль.

Хоть бы рассказал для тёмных, что там поломали.

В другой теме рассказывал: Про изменение поведения free между procps 3 и procps 4 .

В двух словах:

Классическая арифметика free: used = total - free - cached - buffers.

Теперь free выводит другое ближе к total - free.

Ну а чего не libre-open-free-classic-ng-remaster?

Нет в тебе чувства прекрасного. Ну как может быть одновременно и classic и ng(next generation)? Ну и perl туда же. Нет бы python. А вообще classic версия должна быть на C, а ng на расте

Предлагаю переименовать в free-classic-ng-reborn-rs. Ну и переписать на русте.

Не всем нужен Perl, перепиши на awk

62.7256851196289

Прости, а откуда оно берёт лишние 0.6289 байт?

Рановато ещё. За 20 лет кол-во оперативки в моём системнике увеличилось всего в 128 раз.

Лох! В моём в 1024 (128m -> 128g).

...-game-of-the-year-edition

Погрешность вычислений при работе с числами с плавающей запятой же.

Оттуда же старый мем про

0.1 + 0.2 = 0.30000000000000004

Погрешность вычислений при работе с числами с плавающей запятой же.

Я в курсе. Вопрос в том, нахрена ты считаешь байты в IEEE754? Это ж эталонный говнобыдлокод просто!

Скрипт получает кол-во памяти из /proc/meminfo в килобайтах, а уже это кол-во пересчитывает в нужные юзеру величины (по дефолту - гигабайты) через деление.

а уже это кол-во пересчитывает в нужные юзеру величины (по дефолту - гигабайты) через деление.

Ага, и начинает брешить в процессе из-за ошибок округления. Как я уже писал, это просто эталонный говнобыдлокод. Не делай так, это плохо для кармы! Используй хотя бы целочисленное деление, а лучше fixed point числа.

целочисленное деление, а лучше fixed point числа

С точностью до байта даже ядро не скажет, поэтому погрешности меньше чем 1 никому тут не интересны.

С точностью до байта даже ядро не скажет

Как и с точностью до килобайта. Учёт памяти идёт по страницам.

поэтому погрешности меньше чем 1 никому тут не интересны.

Кто тебе сказал, что у тебя погрешность на уровне байтов, а не куда хуже? Ты проверял?

Но правда, хватит оправдывать свой говнобыдлокод. Просто сделай нормально.

Погрешность при делении float чисел есть, но она настолько незначительна, что все этим пользуются, и это нормально. Всё зависит от задачи. Утилитами типа free люди пользуются для оценки загруженности памяти. Эту оценку можно спокойно проводить и при такой погрешности.

saahriktu, ваши рассказы в разделе «Художественные произведения» на вашем сайте, это просто чума! Находка, надо же такое выдумывать!…

Согласен.

Один мужик шёл по одному городу. Кругом были дома, люди и машины. Дома из песка, а машины из прессованного
пепла. И они ездили по дорогам из стекла. Стёкла трескались, но их регулярно меняли. Потому, что стекло было
очень дешёвым. Из прессованного воздуха.
...

Погрешность при делении float чисел есть, но она настолько незначительна, что все этим пользуются, и это нормально.

Кто все? За счёт денег в IEEE754 бьют по щщам с ноги, например.

А тут не деньги, а RAM, причём не с точностью до байта, которой нет даже у ядра.

Вот взял и сделал версию с целочисленным делением. Теперь объясните мне: чем

Memory Total: 62 GB
Memory Used: 4 GB
Memory Free: 55 GB
Memory Cached: 3 GB
Memory Buffer: 0 GB

Memory Total: 62.7256851196289 GB
Memory Used: 3.40106964111328 GB
Memory Free: 55.8500022888184 GB
Memory Cached: 3.01894760131836 GB
Memory Buffer: 0.455665588378906 GB

На мой взгляд, второй вариант как раз таки точнее и больше подходит для оценки использования памяти.

Ты лучше расскажи, зачем тебе точность в 15 знаков после запятой

Мне не обязательно. Просто чем точнее - тем лучше. И я как раз спорю с человеком, который как раз это и утверждает. Просто у нас разные представления о точности отображения данных о памяти.

В его представлении точность гарантируют только целые числа. А я подхожу с точки зрения математики, т.е. чем больше цифр после запятой точнее - тем лучше.

Лучше в виде таблицы, например:

 085 $ free --mega
               total        used        free      shared  buff/cache   available
Mem:            8204        1230        5187         171        2272        6974
Swap:           4294           0        4294

 086 $ ./Desktop/free -m

Total   : 7824,016
Free    : 4197,98
Used    : 1414,46875
Cached  : 2013,406
Buffers : 198,1602
Units   : Mb

 087 $ ./Desktop/free -m | ft

  Total    Free    Used  Cached Buffers Units
  -----    ----    ----  ------ ------- -----
7824,02 4190,13 1416,24 2019,48  198,17 Mb

Ты лучше расскажи, зачем тебе точность в 15 знаков после запятой

Во-во, читать это жутко неудобно, двух знаков после запятой хватит всем! 😄

Просто чем точнее - тем лучше

Исходные данные уже неточные, в целых KB.

А я подхожу с точки зрения математики, т.е. чем больше цифр после запятой точнее - тем лучше.

Объясни мне с точки зрения математики, что такое 0.6289 байта и откуда они взялись, если ты делил количество килобайт (целое число) на степень двойки (тоже целое число).

А все вот эти знаки после запятой нужны?

Просто чем точнее - тем лучше.

В ядерной физике - да, там «десятые знаки» влияют на то, получит ли теория Нобелевку или пойдет в стол. Но нет смысла считать биты, когда ОЗУ измеряется в десятках… или даже тысячах гигабайт.

Объясни мне с точки зрения математики, что такое 0.6289 байта

Это погрешность вычислений. С точки зрения математики важнее другой вопрос: ряд правильных цифр после запятой увеличивает эту математическую точность, а их отбрасывание эту точность уменьшает.

Т.е. спор про 15-ю цифру после запятой относительно точности менее важен чем про ряд цифр после запятой до неё, который эту точность увеличивает.

ряд правильных цифр после запятой увеличивает эту математическую точность

Так а с чего ты взял, что у тебя эти цифры правильные? У тебя, судя по всему, ересь начинается уже с третьего-четвёртого знака.

Это погрешность вычислений. С точки зрения математики важнее другой вопрос: ряд правильных цифр после запятой увеличивает эту математическую точность, а их отбрасывание эту точность уменьшает.

Не путай «верные цифры» и «значащие цифры»: ошибки вычислений ©.

Сделай чтоб изначально размер был в байтах, а при использовании опции -h включались приставки.

Проверил по

Memory Total: 62.7256851196289 GB

Как минимум, 9 цифр после запятой тут нужны, иначе при срезании цифр и переводе в байты (и округлении до целых, разумеется) данные начинают расходиться с «free -b».

Исходные данные уже неточные, в целых KB.

Суть в том, что округление до целых резко увеличивает эту неточность. А float point арифметика хоть и увеличивает погрешность, но не так как при срезании цифр после запятой.

Это как если погрешность от float point арифметики размером с хомячка, а погрешность от целочисленной арифметики размером с Годзиллу.