и если на каждое такое преобразование ругаться - будет много false positive.
Для C++ это гораздо более оправдано. Хочешь bool - пиши каст, хочешь идиоматичность - используй умные указатели или перегружай оператор каста.
Конечно же пример в статье с большой вероятностью указывает на ошибку (в частности потому, что можно вывести конкретное значение). Но при этом совершенно не важно, что было в значении, приведённом к bool - потому что программа обязана в дальнейшем вести себя так, как будто было присвоено значение true или false.
bool a = 4; // не делайте так!
int b = 4 + a; // b == 5
с другой стороны а как ещё-то?
int r = 4;
// какой-то путь, по которому r не меняется
bool cond1 = r; // так плохо
bool cond2(r); // а чем это лучше?
bool cond3 = bool(r); // много писать
bool cond4 = !!r; // лучше откомментить, если не везде
Дело не в том, могут они понять или нет — выучить таблицу приведений объектов в яваскрипте не труднее стиха «буря мглою небо кроет...».
Дело в том, что у любого действия должен быть наиболее ожидаемый результат. Для питона это особенно справедливо — у него нет «костылей» статической типизации, и a * b может внезапно оказаться скаляром, массивом или объектом.
Вообще перегрузка операторов должна производиться очень аккуратно, чтобы потом при чтении кода было очевидно, кто на ком стоял, и что в результате получается.
Мне кажется, именно такую физическую силу ясность чувства надо воспитывать в детях, а не «я чёт написал, оно чёт сделало — и ладно».
это примерно как ели (сущ.), ели (гл.) и ели (сокр. от метро Елизаровская)
gravy (сущ.) — подливка
gravy (прил.) — могильный, от grave
gravy (сокр.) — любое производное от grav_I_ty, но в англ. не любят когда слова на i заканчиваются, поэтому y
ПФ же очевидно развернули антикурительную пропаганду, потому что на момент wish you were here у них уже не было яркого психоделического движка в лице Барретта (собственно, которому этот альбом и посвящен).
По описанию похоже на битый стек.
Я бы посоветовал погонять с ASAN/MSAN/TSAN, а если только в gdb — то, возможно, record и обратное исполнение что-нибудь покажут. Ну или руками попытаться раскрутить стек, глядишь, что получится.
Привет от Оникс (но это не я) 8-)
Системд это хорошо, но ещё лучше указывать дистр где это всё работает. Например, в центосе 7 несколько устаревшая версия, и я не могу по человечески ограничить логгирование демона. 8-(
Окей. Попробуем начать с основ статистики.
Да и с подсчётом я облажался. N бит представляют 2^N различных блоков, и тогда 512 мб это 2^32 бит, и соответственно 2^(2^32) различных блоков, и на одно значение хеша приходится, как вы и сказали, 2^(2^32-160) различных блоков.
Но только вот какая штука:
Если нам дали значение хеша, и мы генерируем некий блок данных, то мы получим именно тот хеш, который нам дали с вероятностью 2^-160. Ок.
Но если значение хеша, которое нам дали, внезапно совпало с хешем блока, который мы вот только что сгенерили (т.е. наша вероятность коллизии 2^-160 уже сработала) — то вероятность того, что «на той стороне» посчитали хеш именно из этого блока — 2^-(2^32-160), если у нас нет каких-либо предположений о распределении данных «на той стороне».
Я вот понимаю криптографичность кеша как то, что а) нет перекоса в вероятности получить данный хеш (т.е. каждому хешу соответствует примерно одно и то же количество исходных текстов заданной длины), и б) малое изменение исходного текста сильно меняет хеш.
А про боязнь малых вероятностей — это не совсем так 8-)
Я не боюсь малой (1/2^256) вероятности получить хеш, который соответствует блоку из нулей. Я боюсь огромной (1-1/2^24) вероятности того, что блок из которого я получил «нулевой» хеш — на самом деле сильно от «нулевого блока» отличается. Особенно если у нас сильно меняется распределение вероятностей засчет некого изменения исходных данных («сжатие»).
PS. Я как-то в детстве читал что-то типа «занимательной математики». Там был рассказ про доцента и профессора, которые поспорили на велосипед, что за 10 минут в выходной день в маленьком городке мимо окна не пройдёт 100 человек. Доцент утверждал, что вероятность этого абсолютно, ничтожно мала — и тут мимо прошел отряд военных.
Может, кто знает, что это была за книга?
и всё же неспокойно.
sha1 это блок 160 бит, sha 256 — соответственно 256
для блока в 512 мб (2^32 бит) это означает, что каждому значению хеша (включая нулевой) соответствует, ни много ни мало, а примерно 2^24 возможных исходных блоков.
Конечно же, блоков с "ненулевым" хешем гораздо больше — их чуть меньше 2^32 8-)
Но если мы говорим про некий "запакованный" объект — то там степень разнообразия данных выше, и кмк коллизии с нулевым хешем гораздо более реальны.
Вот идея сливать сначала не весь такой объект, а только его часть — кмк может "прокатить": согласно условиям разработки хеша похожие блоки должны иметь существенно различный хеш.
А что с Рейзер4? Я думал, его по большей части забросили, и Шишкин сотоварищи его допатчивали по мере наличия (или отсутствия) времени к актуальным ядрам…
Если руками зачистить всё, что можно и нельзя, то минимальный CentOS можно ужать в ~150 Мб (но это, конечно, боль). Если до такого же уровня ужимать Альпайн, можно получить что-то типа ~40-50 Мб — что с одной стороны в 3 раза лучше, а с другой — стоят ли того всего-то 100 метров, при терабайтах СХД?
А ещё у Альпайна плохо описан процесс подключения внешних компонентов, и особенно — «third-party» модулей ядра. Надо будет как-нить в свободное время заняться…
С обновлением FlashPlayer'а BadRabbitовцы хорошо подгадали — недавний апдейт от Адоб сломал, например, флеш-компонент у vmware vcenter. Они, конечно, уже всё починили, но осадочек остался...
Единственная аксиома науки — что законы существуют и не меняются во времени. Если это неверно, то все науки бессмысленны.
всё остальное же — научные теории о том, какой вид имеют эти законы, и вот они не могут быть «неверны-неверны».
Например, 2 закон Ньютона не может не быть F=m*a. Потому что он в этой форме описывает множество феноменов, проверенных и перепроверенных тысячи раз в различных условиях.
Но на самом деле, если перейти к большим массам и ускорениям, окажется что он таки не прав, и нужны поправки Теории Относительности. Которые тоже проверены и перепроверены достаточно много.
И может быть, если мы ещё поднажмём, нам понадобится ещё какая-то коррекция.
Но вернувшись «на землю» мы обнаружим что Ньютоновская механика всё ещё очень хорошо описывает происходящее, а все поправки — и ТО, и наши гипотетические — малы настолько, что мы их не можем сдетектить с достаточной точностью.
О чём Этан и пишет — истинно научная теория не может измениться. она может быть только уточнена.
Ну, учитывая что гугль появился в 1998 году — табличка с надписью «сарказм» вполне себе прослеживается.
И кстати — vi (который предок vim) был сделан в 1976 году, так что ещё (наверное) есть люди, которые пользуются этим текстовым редактором в той или иной форме как минимум дольше, чем гуглём.
Ну и да, тот абзац именно про таких людей. 8-)
< del, предыдущий комментатор уже предложил scons >
Непрямое преобразование в bool идиоматично для C
и если на каждое такое преобразование ругаться - будет много false positive.
Для C++ это гораздо более оправдано. Хочешь bool - пиши каст, хочешь идиоматичность - используй умные указатели или перегружай оператор каста.
Конечно же пример в статье с большой вероятностью указывает на ошибку (в частности потому, что можно вывести конкретное значение). Но при этом совершенно не важно, что было в значении, приведённом к bool - потому что программа обязана в дальнейшем вести себя так, как будто было присвоено значение true или false.
с другой стороны а как ещё-то?
По стандарту С++ тип bool имеет константы true=1 и false=0.
см. https://en.cppreference.com/w/cpp/language/implicit_conversion#Integral_conversions
На этом основан метод приведения - !!x гарантировано или 0 или 1.
Дело не в том, могут они понять или нет — выучить таблицу приведений объектов в яваскрипте не труднее стиха «буря мглою небо кроет...».
Дело в том, что у любого действия должен быть наиболее ожидаемый результат. Для питона это особенно справедливо — у него нет «костылей» статической типизации, и a * b может внезапно оказаться скаляром, массивом или объектом.
Вообще перегрузка операторов должна производиться очень аккуратно, чтобы потом при чтении кода было очевидно, кто на ком стоял, и что в результате получается.
Мне кажется, именно такую
физическую силуясность чувства надо воспитывать в детях, а не «я чёт написал, оно чёт сделало — и ладно».gravy (сущ.) — подливка
gravy (прил.) — могильный, от grave
gravy (сокр.) — любое производное от grav_I_ty, но в англ. не любят когда слова на i заканчиваются, поэтому y
ПФ же очевидно развернули антикурительную пропаганду, потому что на момент wish you were here у них уже не было яркого психоделического движка в лице Барретта (собственно, которому этот альбом и посвящен).
с уважением, ваш КО.
Я бы посоветовал погонять с ASAN/MSAN/TSAN, а если только в gdb — то, возможно, record и обратное исполнение что-нибудь покажут. Ну или руками попытаться раскрутить стек, глядишь, что получится.
Системд это хорошо, но ещё лучше указывать дистр где это всё работает. Например, в центосе 7 несколько устаревшая версия, и я не могу по человечески ограничить логгирование демона. 8-(
Да и с подсчётом я облажался. N бит представляют 2^N различных блоков, и тогда 512 мб это 2^32 бит, и соответственно 2^(2^32) различных блоков, и на одно значение хеша приходится, как вы и сказали, 2^(2^32-160) различных блоков.
Но только вот какая штука:
Если нам дали значение хеша, и мы генерируем некий блок данных, то мы получим именно тот хеш, который нам дали с вероятностью 2^-160. Ок.
Но если значение хеша, которое нам дали, внезапно совпало с хешем блока, который мы вот только что сгенерили (т.е. наша вероятность коллизии 2^-160 уже сработала) — то вероятность того, что «на той стороне» посчитали хеш именно из этого блока — 2^-(2^32-160), если у нас нет каких-либо предположений о распределении данных «на той стороне».
Собственно, это должно быть свойством криптохеша — см. п.3 для свойств идеального криптохеша:
Ну и в рамках данного обсуждения мы «сгенерили» блок из всех нулей, что на вышеизложенные размышления влиять не должно.
Буду рад, если мне укажут на ошибку в моих предположениях.
Спасибо.
PS. И за Перельмана отдельное спасибо. 8-)
Я вот понимаю криптографичность кеша как то, что а) нет перекоса в вероятности получить данный хеш (т.е. каждому хешу соответствует примерно одно и то же количество исходных текстов заданной длины), и б) малое изменение исходного текста сильно меняет хеш.
А про боязнь малых вероятностей — это не совсем так 8-)
Я не боюсь малой (1/2^256) вероятности получить хеш, который соответствует блоку из нулей. Я боюсь огромной (1-1/2^24) вероятности того, что блок из которого я получил «нулевой» хеш — на самом деле сильно от «нулевого блока» отличается. Особенно если у нас сильно меняется распределение вероятностей засчет некого изменения исходных данных («сжатие»).
PS. Я как-то в детстве читал что-то типа «занимательной математики». Там был рассказ про доцента и профессора, которые поспорили на велосипед, что за 10 минут в выходной день в маленьком городке мимо окна не пройдёт 100 человек. Доцент утверждал, что вероятность этого абсолютно, ничтожно мала — и тут мимо прошел отряд военных.
Может, кто знает, что это была за книга?
и всё же неспокойно.
sha1 это блок 160 бит, sha 256 — соответственно 256
для блока в 512 мб (2^32 бит) это означает, что каждому значению хеша (включая нулевой) соответствует, ни много ни мало, а примерно 2^24 возможных исходных блоков.
Конечно же, блоков с "ненулевым" хешем гораздо больше — их чуть меньше 2^32 8-)
Но если мы говорим про некий "запакованный" объект — то там степень разнообразия данных выше, и кмк коллизии с нулевым хешем гораздо более реальны.
Вот идея сливать сначала не весь такой объект, а только его часть — кмк может "прокатить": согласно условиям разработки хеша похожие блоки должны иметь существенно различный хеш.
PS. респект за действующую модель.
А ещё у Альпайна плохо описан процесс подключения внешних компонентов, и особенно — «third-party» модулей ядра. Надо будет как-нить в свободное время заняться…
На б/м современной оси есть ещё fstrim искаропки
С обновлением FlashPlayer'а BadRabbitовцы хорошо подгадали — недавний апдейт от Адоб сломал, например, флеш-компонент у vmware vcenter. Они, конечно, уже всё починили, но осадочек остался...
всё остальное же — научные теории о том, какой вид имеют эти законы, и вот они не могут быть «неверны-неверны».
Например, 2 закон Ньютона не может не быть F=m*a. Потому что он в этой форме описывает множество феноменов, проверенных и перепроверенных тысячи раз в различных условиях.
Но на самом деле, если перейти к большим массам и ускорениям, окажется что он таки не прав, и нужны поправки Теории Относительности. Которые тоже проверены и перепроверены достаточно много.
И может быть, если мы ещё поднажмём, нам понадобится ещё какая-то коррекция.
Но вернувшись «на землю» мы обнаружим что Ньютоновская механика всё ещё очень хорошо описывает происходящее, а все поправки — и ТО, и наши гипотетические — малы настолько, что мы их не можем сдетектить с достаточной точностью.
О чём Этан и пишет — истинно научная теория не может измениться. она может быть только уточнена.
И кстати — vi (который предок vim) был сделан в 1976 году, так что ещё (наверное) есть люди, которые пользуются этим текстовым редактором в той или иной форме как минимум дольше, чем гуглём.
Ну и да, тот абзац именно про таких людей. 8-)