> какое отношение криптография имеет к хэш-таблицам?Никакого! Это прозрачный намек что к хеш-функции для хеш-таблицы в ФС требования не особо крyтые, а CRC32 "сам по себе" там не так уж плох. Если не заниматься всякой клиникой. Потому что если заниться, ушатать можно любую ФС.
> говорю: отсутствие элементарных базовых знаний. извини, я не верю, что у
> людей, не знающих таких простых вещей, все остальные знания «тип-топ».
Я уже наверное дюжину раз пытаюсь вытащить объяснение чем так уж сильно плох CRC32 как функция для хеш-таблиц, если забыть о всяких бзиканутых случаях с "хакерами и солонками". Не, я не буду спорить что есть и функции лучше, но имхо масштаб предъяв - преувеличен.
> нет, у них и в других областях наверняка пробел на пробеле. нафиг-нафиг.
Кэп, на этой планете накоплено намного больше знаний чем может уместиться в одну голову! Поэтому такая ситуация - совершенно обычное дело.
> видишь ли: человеку, хоть немного понимающему, просто не пришло бы в голову
> использовать crc32 как хэш-функцию.
Функция как функция. Не лучшая для хеш-таблиц, но и не хучшая. Зачем именно ее взяли - я не знаю. Но о например злонамеренном вызове коллизий в хеш-таблицах вообще задумались только недавно. По поводу чего появилось некоторое количество новых заслуживающих внимания функций, которые и быстрые и непредсказуемые. Но btrfs дизайнился заметно раньше чем они появились.
> см. выше: это индикатор того, что люди не имеют базовых знаний в
> «computer science».
ИМХО это преувеличение. Выбор оптимальностью не блещет, но не более того.
> у меня нет желания лично перечитывать весь их код, чтобы понять,
> в каких местах ещё они накосячили,
В любой достаточно большой программе есть энное количество багов. И crc32 в хеш-таблице - далеко не самое страшное что встречается в файловых системах. Вон например в ext4 не так давно был баг - если создать Очень Большой Файл, ФС может настать пиндец. Вот это я понимаю - баг! Которого бояться стоит. После таких багов понимаешь зачем апдейтить ядра.
> я лучше просто не буду пользоваться их гoвнoкодом.
Если уж такой зуд о качестве софта проснулся - я бы лучше думал как отделаться от TLS/SSL и соотв. либ. Куда актуальнее чем какой-то CRC32 в хеш-таблице. Который в целом работает и проблем от него не так уж и много.
> таких мегакосяков, как у бтр, я за авторами этих FS не припомню.
Ой, грабель хватает везде. XFS тер нулями файлы "для безопасности". Что, конечно, устраняло риски утечек данных, но сильно дестроило файлы в сомнительных случаях. Может хорошо для АНБ, но для обычного десктопа - хреново. А в EXT4 относительно недавно поймали крутой и реально страшный баг - см. выше. Практически все ФС можно положить по ресурсам до производительности "сильно ниже средней", так что опять же это не уникально для btrfs, это у всех так. Ну ок, на других манипуляциях. Если например миллион раз дописать файл - экстентной механике многих ФС становится душновато по метаданным, стираться такой файл будет добрых пять минут. А если таких файлов много - будешь полгода ждать расчистки ФС.
> уме назовёт её авторов адекватными.
Ну тогда я не понимаю с фига ли ты не считаешь софт который эту либу использует гoвнoкодом. Куда более существенный продолб, имхо.
> а не авторы OpenSSL. так тоже бывает.
Макака спросила ламеров. Ламеры сказали - "можно". Макака пошла и поменяла. ИМХО ламеры сами не знали к чему это приводит.
> без оснований.
Да хрен там, я читал их переписку. Авторы openssl судя по всему сами не понимали к чему ведет такое изменение но зачем-то сказали что так можно (с какими оговорками - второй вопрос). И для какой-такой отладки может поторебоваться изломать криптографию до уровня предсказуемых ключей? Разве что прогон тестовых векторов, но там этого не было. Так что булшит.
