Ну вообще-то ФСБ явно запрещает публикацию информации о найденных и устранённых уязвимостях, и потому ни у одного сертифицрованного продукта вы никакой конкретной информации об этом не найдёте. Как и публичных баг-трекеров - за это просто заберут сертификаты. Более того, исходники ФСБ тоже запрещает публиковать, даже если авторы не против. И что только может пойти не так с подобной стратегией ? :))) Кроме того система построена так, что разработчикам дико невыгодного сообщать об уьязвимостях в сертифицированных продуктах. Местами даже просто невозможно. Кроче, это всё так и задумано и результаты получаются соотвествующие.
Пробоавл - блочит. Случайным образом. Сегодня блочит. Завтра - нет. Послезавтра снова блочит. Иногда блочит после 20 секунд. Иногда после пары минут. Иногда по трафику. Но блочит часто и уже больше года.
В общем я понял, что с этим алгоримом не так: Он имеет непредсказуемую сложность и непредсказуемый расход памяти. В худшем случае он вырождается в хранение полной копии всех данных с просмотром всех данных при каждом поиске. И ничего с этим поделать нельзя, так как трудно придумать данные, которые гарантируют размер скелета и сложность/скорость поиска. О чём автор честно предупредлил, но вот использовать такой алгоритм на практике не получится :) Кроме того алогоритм жёстко привязан к некоторой фиксированной длине блока данных, используемой при поиске копий/повторов. А если у нас такие данные, что мы прямо знаем оптимальный/допустимый размер блока и их структуру, то для них можно придумать более эффективный алгоритм поиска.
Кроме того в вашем алгоритме можно хранить не сами данные, а хэши подблоков, что круто ускоряет поиск, но при практически не влияет на точность. У вас там 16-байтные блоки, вроде, были? Ну вот и храните и испольуйте при поисике не сами блоки, а быстрые 4-байтные хэши этих блоков (например через сумму или исключающее-или произведний простого числа на значение байтов и индексов байтов в блоке) - на порядок быстрее будет при том же результате. Но поиск только блочный :)
Избыточная длина грузовика. Грузовики и так максимальной дпустимой длины обычно делают. А если беспилотные, где кабины нет, то выгоднее дополнительный груз тащить, а не обтекатель. И увеличение длины означает увеличение выноса заднего свеса (динамического габарита), что крайне неприятно и опасно.
Кроме того представьте b-tree в котором не одиночные элементы, а диапазоны хешей (в простейшем случае) - будет относительно быстро и относительно компактно (особено если не через указатели делать, а как линейную структуру). Или b-tree+bloom (в узлах дерева лежат битовые маски для дальнейшего сужения поиска). И ещё вопрос, что там быстрее получится. Хэши-то равномерно распределены и потому балансировка деревьев не нужна, что очень ускоряет процесс и упрощает алгоритмы. А ещё оно совершенно не зависит от длины входного блока данных. А в статье под фиксированный блок получается, либо скорость поиска падает. В статье алгоритм интересный, но совершенно точно не универсальный и очень неочевидно для чего именно он будет оптимальным.
Как раз данный алгорим очень быстро вымывает кэш (многократная обработка искомой строки + обращение к условно-большому скелету), а bloom обращается к памяти точечно и расходует одну троку кэша на одно обращение/поиск (ну и ещё один раз прочитать проверяемые данные для полученя хэша, но это в любом алгоритме неизбежно).
Сейчас ночь и это не точно, но во-первых, у вас какой-то очень простой bloom-фильтр. Можно же и по-сложнее. Можно не однобитный, а по сложной (и даже динамической) маске, например, биты ставить/проверять. Но идея интересная. Нужно только качественно подумать, какие у неё практические огрниченая по длинна словаря и блока поика. В том смысле, что на каких задачах это имеет смысл и какое получается быстродействие (манипуляции с со скелетом и данными вовсе не бесплатные же). Может оказаться, что bloom+b-tree и/или какие-то buckets окажется равен по быстродействию вашему алгоритму. В том смысле, что более медленный поиск "второго уровня" после ложно-положительного срабатывания bloom будет равен по быстродействию вашему чудо-алгоритму, что резко ограничивает рельные сценарии его применения. Кроме того у вас время поиска довольно быстро растёт и плохо предсказывается, а объём скелета и вовсе непредсказуем, в общем случае, а bloom он остаётся константой. Есть ощущение, что в какой-то момент (на каких-то задачах) ваш алгоритм начнёт проигрывать фильтру на основе деревьев.
Всё хуже. У грузовика аэродинамику определяет не перед, а зад. Зона разряжения сзади влияет на потребление топлива в разы больше, чем фома кабины. На реальных дорожных скоростях, конечно же. И проблема в том, что сзади-то ничего и не поделаешь. Кабина по-определению спереди должна быть, а у беспилотников всё в раму помещается. А надо бы сзади каплю приделать, но это будет безполезное значительное увеличение длины в угоду аэродинамике, а потому ой. Но вот цистерны такой формы делать - дорого, но с гарантирвоанной экономией 10..20% топлива... Может и окупится на больших объёмах.
Вполне пошло. И с коррозией решили, и с обрастанием илом и моллюсками. Но осталось две принцпиальные и нерешаемые проблемы: 1) при отказе обрудования его менять сказочно дорого. Настолько дорого, что дешевле вообще не менять несколько лет. В капсулах копится неиспользуемое обрудование, что тоже дорого.
1бе) ладно, если сервер навернулся, а если коммутатор? Ну, на первое время резерв есть, но дальнейшая работа получается без резерва. И на суше команда бежит и быстро меняет "по живому" без остановки серверов, а под водой и заменить сказочно дорого и долго и при замене нужно всю капсулу отключать на всё время ремонта. То есть нужно держать резерв по вычислительной мощности на время ремонта капсулы. Либо делать в разы больший резерв, чем на земле, что ещё больше задирает стоимость. По опыту эксплуатации оказалось, что дешевле ставить кратно-больший резерв, чем на суше, и молиться, что его хватит на срок службы капсулы. Но это ДОРОГО. Но всё равно дешевле, чем в капсулы лезть с ремонтом.
2) ничего не изменишь и не проагрейдишь. Как собрал, систему, так собрал. И даже каналы связи новые не проложишь. А в дата центрах, как выяснилось регулярно что-то меянют и перенастривают в сетевой архитектуре.
Короче издержки на устаревание и ремост сравнялись со стоимостью охлаждения на земле и потому идея потеряла практический смысл. Но на земле в любой момент, можно в значительной мере переделать архитектуру дата-центра, что очень хорошо с точки зрения безопасности инвестиций
Но далеко от потребителей и генерации, и слабая транспортная доступность. Допустим, что вы найдёте электростанцию (на которую нужно будет очень дорого и долго везти топливо), но в результате всё равно получите дата-центр с пингом 60..100 от европейской части и с узкими каналами связи (которые ОЧЕНЬ дорого строить). И все запчасти туда везти будет дорого и долго. И специалистов там днём с огнём не сыщешь - только большими деньгами на контракты заманивать.
Начнём с вопроса о том, много ли вы написали на том расте под контроллеры? Там местами больно, местами бессмысленно получается. Там сплошные C-heаders с макросами, творящими совершенно жуткие, с точки зрения раста, вещи. Там даже на C++ местами больно. Я очень сильно в эту сторону смотрю, но пока не смог найти ответа на вопрос "зачем?", так как на C++ можно сделать всё то же самое, просто не нужно стрелять себе в ноги. А по удобству современный C++ позволяет ровно то же ровно с той же степенью безопасности. Зато в случае необходимости погрузиться дебри bare metall на C++ это делается намного проще.
Не нравится C, пишитена C++. И будут все возможные плюшки, какие контрллер потянет. Раст на контроллерах будет в разы медленнее C++. Плюс там сплошные небезопасные указатели и проблемы с динамической памятью.
Просто это стоит миллионы баксов и раньше никто подобной благотворительностью не занимался. Это как тот баг в Линуксе, с котрого вся эта истерия началась. Тот самый, который мифическая (во всех смыслах) LLM "запросто" нашла за двое суток непрерывной многоагентской работы под контролем крутого специалиста. Сколько-сколько стоят двое суток непервной работы кучи агентов топовой LLM с двумя сутками крутого спеца? Там в описании процесса поиска проскализывало, что только расходы на LLM на поиск именного этой уязвимости вышли больше $20k (это за двое суток!!! Это сколько же там топовых агентов в парралель с максимальными контекстами крутилось?). Плюс ещё сколько-то отвалили специалисту за этот PR. И мы не знаем, сколько он там подходов/попыток делал.
Короче, если бы кто-то из китайцев выделил $100к на поиск багов в каком-то крупном OpenSource проекте и в довесок нанял бы крутого спеца на несколько суток, то они совершенно точно бы устроили ровно такой же PR на KiMi/DeepSeek/MinMax/GLM. Аналогично, что если бы кто-нибудь раньше дал Mozila безлимитный халявный доступ к LLM на несколько недель (на миллион баксов или около того) и впридачу одного-двух сильно материально-заинтересованных специалистов на это же время, то результат был бы плюс-минус такой же на любой современной LLM.
Просто антропики первыми догадались до такого PR-хода и сообразили выделить на это десяток миллионов долларов рекламного бюджета. Ну, как-бы, молодцы, конечно, но это чистый маркетинг и бабки. Я совершенно уверен, что если мне дадут доступ к современной LLM на $20к, то я тоже гарантированно критических дыр в ядре Линукса понахожу. Не за двое суток, конечно, это нужно прямо в теме быть, но за пару недель в рамках бюджета понахожу.
Ну вообще-то ФСБ явно запрещает публикацию информации о найденных и устранённых уязвимостях, и потому ни у одного сертифицрованного продукта вы никакой конкретной информации об этом не найдёте. Как и публичных баг-трекеров - за это просто заберут сертификаты.
Более того, исходники ФСБ тоже запрещает публиковать, даже если авторы не против.
И что только может пойти не так с подобной стратегией ? :)))
Кроме того система построена так, что разработчикам дико невыгодного сообщать об уьязвимостях в сертифицированных продуктах. Местами даже просто невозможно.
Кроче, это всё так и задумано и результаты получаются соотвествующие.
Ничего "подшаманить" нельзя.
Пробоавл - блочит. Случайным образом. Сегодня блочит. Завтра - нет. Послезавтра снова блочит. Иногда блочит после 20 секунд. Иногда после пары минут. Иногда по трафику. Но блочит часто и уже больше года.
Байкал? В России? Это который изначально лицензированный SPARC?
Серьёзно?
В общем я понял, что с этим алгоримом не так:
Он имеет непредсказуемую сложность и непредсказуемый расход памяти. В худшем случае он вырождается в хранение полной копии всех данных с просмотром всех данных при каждом поиске. И ничего с этим поделать нельзя, так как трудно придумать данные, которые гарантируют размер скелета и сложность/скорость поиска. О чём автор честно предупредлил, но вот использовать такой алгоритм на практике не получится :)
Кроме того алогоритм жёстко привязан к некоторой фиксированной длине блока данных, используемой при поиске копий/повторов.
А если у нас такие данные, что мы прямо знаем оптимальный/допустимый размер блока и их структуру, то для них можно придумать более эффективный алгоритм поиска.
Кроме того в вашем алгоритме можно хранить не сами данные, а хэши подблоков, что круто ускоряет поиск, но при практически не влияет на точность. У вас там 16-байтные блоки, вроде, были? Ну вот и храните и испольуйте при поисике не сами блоки, а быстрые 4-байтные хэши этих блоков (например через сумму или исключающее-или произведний простого числа на значение байтов и индексов байтов в блоке) - на порядок быстрее будет при том же результате. Но поиск только блочный :)
Избыточная длина грузовика. Грузовики и так максимальной дпустимой длины обычно делают. А если беспилотные, где кабины нет, то выгоднее дополнительный груз тащить, а не обтекатель.
И увеличение длины означает увеличение выноса заднего свеса (динамического габарита), что крайне неприятно и опасно.
Кроме того представьте b-tree в котором не одиночные элементы, а диапазоны хешей (в простейшем случае) - будет относительно быстро и относительно компактно (особено если не через указатели делать, а как линейную структуру). Или b-tree+bloom (в узлах дерева лежат битовые маски для дальнейшего сужения поиска). И ещё вопрос, что там быстрее получится. Хэши-то равномерно распределены и потому балансировка деревьев не нужна, что очень ускоряет процесс и упрощает алгоритмы. А ещё оно совершенно не зависит от длины входного блока данных. А в статье под фиксированный блок получается, либо скорость поиска падает.
В статье алгоритм интересный, но совершенно точно не универсальный и очень неочевидно для чего именно он будет оптимальным.
Как раз данный алгорим очень быстро вымывает кэш (многократная обработка искомой строки + обращение к условно-большому скелету), а bloom обращается к памяти точечно и расходует одну троку кэша на одно обращение/поиск (ну и ещё один раз прочитать проверяемые данные для полученя хэша, но это в любом алгоритме неизбежно).
Сейчас ночь и это не точно, но во-первых, у вас какой-то очень простой bloom-фильтр. Можно же и по-сложнее. Можно не однобитный, а по сложной (и даже динамической) маске, например, биты ставить/проверять.
Но идея интересная. Нужно только качественно подумать, какие у неё практические огрниченая по длинна словаря и блока поика. В том смысле, что на каких задачах это имеет смысл и какое получается быстродействие (манипуляции с со скелетом и данными вовсе не бесплатные же). Может оказаться, что bloom+b-tree и/или какие-то buckets окажется равен по быстродействию вашему алгоритму. В том смысле, что более медленный поиск "второго уровня" после ложно-положительного срабатывания bloom будет равен по быстродействию вашему чудо-алгоритму, что резко ограничивает рельные сценарии его применения. Кроме того у вас время поиска довольно быстро растёт и плохо предсказывается, а объём скелета и вовсе непредсказуем, в общем случае, а bloom он остаётся константой. Есть ощущение, что в какой-то момент (на каких-то задачах) ваш алгоритм начнёт проигрывать фильтру на основе деревьев.
Всё хуже. У грузовика аэродинамику определяет не перед, а зад. Зона разряжения сзади влияет на потребление топлива в разы больше, чем фома кабины. На реальных дорожных скоростях, конечно же.
И проблема в том, что сзади-то ничего и не поделаешь. Кабина по-определению спереди должна быть, а у беспилотников всё в раму помещается.
А надо бы сзади каплю приделать, но это будет безполезное значительное увеличение длины в угоду аэродинамике, а потому ой.
Но вот цистерны такой формы делать - дорого, но с гарантирвоанной экономией 10..20% топлива... Может и окупится на больших объёмах.
... но могут и не разрешить. Отличная новость.
Всё упирается в полную необслуживаемость и дороговизну. С активносьтю воды и более-менее разобрались.
Вполне пошло. И с коррозией решили, и с обрастанием илом и моллюсками.
Но осталось две принцпиальные и нерешаемые проблемы:
1) при отказе обрудования его менять сказочно дорого. Настолько дорого, что дешевле вообще не менять несколько лет. В капсулах копится неиспользуемое обрудование, что тоже дорого.
1бе) ладно, если сервер навернулся, а если коммутатор? Ну, на первое время резерв есть, но дальнейшая работа получается без резерва. И на суше команда бежит и быстро меняет "по живому" без остановки серверов, а под водой и заменить сказочно дорого и долго и при замене нужно всю капсулу отключать на всё время ремонта.
То есть нужно держать резерв по вычислительной мощности на время ремонта капсулы. Либо делать в разы больший резерв, чем на земле, что ещё больше задирает стоимость. По опыту эксплуатации оказалось, что дешевле ставить кратно-больший резерв, чем на суше, и молиться, что его хватит на срок службы капсулы. Но это ДОРОГО. Но всё равно дешевле, чем в капсулы лезть с ремонтом.
2) ничего не изменишь и не проагрейдишь. Как собрал, систему, так собрал. И даже каналы связи новые не проложишь. А в дата центрах, как выяснилось регулярно что-то меянют и перенастривают в сетевой архитектуре.
Короче издержки на устаревание и ремост сравнялись со стоимостью охлаждения на земле и потому идея потеряла практический смысл. Но на земле в любой момент, можно в значительной мере переделать архитектуру дата-центра, что очень хорошо с точки зрения безопасности инвестиций
Но далеко от потребителей и генерации, и слабая транспортная доступность.
Допустим, что вы найдёте электростанцию (на которую нужно будет очень дорого и долго везти топливо), но в результате всё равно получите дата-центр с пингом 60..100 от европейской части и с узкими каналами связи (которые ОЧЕНЬ дорого строить).
И все запчасти туда везти будет дорого и долго. И специалистов там днём с огнём не сыщешь - только большими деньгами на контракты заманивать.
Начнём с вопроса о том, много ли вы написали на том расте под контроллеры? Там местами больно, местами бессмысленно получается. Там сплошные C-heаders с макросами, творящими совершенно жуткие, с точки зрения раста, вещи. Там даже на C++ местами больно. Я очень сильно в эту сторону смотрю, но пока не смог найти ответа на вопрос "зачем?", так как на C++ можно сделать всё то же самое, просто не нужно стрелять себе в ноги. А по удобству современный C++ позволяет ровно то же ровно с той же степенью безопасности. Зато в случае необходимости погрузиться дебри bare metall на C++ это делается намного проще.
Не нравится C, пишитена C++. И будут все возможные плюшки, какие контрллер потянет. Раст на контроллерах будет в разы медленнее C++. Плюс там сплошные небезопасные указатели и проблемы с динамической памятью.
Речь про ЛЮБУЮ современную LLM :) Просто это всё чистая трата PR-бюджета и не более того.
Так народ платит за отсутствие антифрода и KYC. Вот что и почему народ за это платит, это уже другой впрос с очевидным ответом :)
Просто это стоит миллионы баксов и раньше никто подобной благотворительностью не занимался.
Это как тот баг в Линуксе, с котрого вся эта истерия началась. Тот самый, который мифическая (во всех смыслах) LLM "запросто" нашла за двое суток непрерывной многоагентской работы под контролем крутого специалиста.
Сколько-сколько стоят двое суток непервной работы кучи агентов топовой LLM с двумя сутками крутого спеца?
Там в описании процесса поиска проскализывало, что только расходы на LLM на поиск именного этой уязвимости вышли больше $20k (это за двое суток!!! Это сколько же там топовых агентов в парралель с максимальными контекстами крутилось?). Плюс ещё сколько-то отвалили специалисту за этот PR. И мы не знаем, сколько он там подходов/попыток делал.
Короче, если бы кто-то из китайцев выделил $100к на поиск багов в каком-то крупном OpenSource проекте и в довесок нанял бы крутого спеца на несколько суток, то они совершенно точно бы устроили ровно такой же PR на KiMi/DeepSeek/MinMax/GLM.
Аналогично, что если бы кто-нибудь раньше дал Mozila безлимитный халявный доступ к LLM на несколько недель (на миллион баксов или около того) и впридачу одного-двух сильно материально-заинтересованных специалистов на это же время, то результат был бы плюс-минус такой же на любой современной LLM.
Просто антропики первыми догадались до такого PR-хода и сообразили выделить на это десяток миллионов долларов рекламного бюджета.
Ну, как-бы, молодцы, конечно, но это чистый маркетинг и бабки.
Я совершенно уверен, что если мне дадут доступ к современной LLM на $20к, то я тоже гарантированно критических дыр в ядре Линукса понахожу. Не за двое суток, конечно, это нужно прямо в теме быть, но за пару недель в рамках бюджета понахожу.
Линкер, как правило, "выбрасывает" модулями, но при правильный настройках и lto он может выбрасывать по одной функции.