Закладку можно спрятать много где. Даже в релейной защите. И вообще говоря, внешними тестами эту закладку не обнаружить. Для обнаружения закладки где-либо требуется как минимум реверс...
формирование ключей с приживлением квантовой физики.
Если речь о гсч, то это не прям сильно повышает степень защиты. Современные ксгспч генерируют достаточно стойкие ключи для большинства приложений.
Если речь о протоколах установления общего секрета, то они же все имеют очень сильные технические ограничения к каналам связи... Так-то понятное дело, что прокопать прямой провод до объекта всегда лучше, чем использовать общественные сети — но это редко целесообразно.
Это не совсем тот тезис, который я здесь говорю. Я лишь говорю о том, что аналогично тестам и симуляциям для физического оборудования, точно также можно делать тесты и фаззинг для тех же МЭ. Т.е. пример из Вашей статьи не совсем честный.
А вот качество что тех, что других тестов — это уже на совести и доверии к производителю...
P.S. хабр съел конец предыдущего комментария: "что именно подразумевается под ПАК ИБ на квантовых принципах? Речь о постквантовой криптографии, или о всяких bb84 и ко?"
Да, можно возразить: «Современные системы релейной защиты в энергетике — сплошные алгоритмы, но они же работают!» Работают, потому что их прогоняют на физических симуляторах с реальными токами и напряжениями. В ИБ алгоритмическую часть так не проверить. Никто не подаст на вход МЭ или VPN-шлюза все возможные пакеты аномалий. Это данность.
Автотесты и фаззинг вполне себе закрывает эту проблему. Другое дело, что обычно тяжело проверить покрытие и тщательность проверок — но аналогичная история с вышеупомянутыми релейными защитами: никто не знает насколько тщательное покрытие были в их тестах (и оно гарантированно не исчерпывающие...).
Поэтому этот тезис опять же выливается в доверие к людям.
С капчами, как и со всякими waf/antiddos сложность в том, что для них нужен масштаб применения. И у хабиа, кажется, недостаточный охват, чтобы реализовать вменяемую (поведеньческую) капчу.
Ну и имеет смысл определится сразу с ограничениями: какой объём данных Вы будете обрабатывать максимум (растить историю бесконечно смысла особого не имеет)
Векторные произведения концепт чисто геометрический, и вне собственно геометрических задач смысла особо не имеет. Поэтому, учитывая упор на анализ данных, как, было бы лучше вообще не рассказывать про векторное произведение. Пример крайне притянутым за уши выглядит...
Вместо этого лучше просто скорить совпадения. Например, если пользователь искал "motivating example", то есть большая разница между кейсами:
Нашли эти два слова подряд
Нашли эти два слова рядом (на расстоянии меньше D слов)
Нашли этидва слова в разных концах содержимого
Нашли одно слово в содержимом а другое в приложении
Поэтому Вам стоит просто ранжировать совпадения на основании того, а как близко находятся матчи. При этом я не уверен, что вариант 3 более релевантен чем вариант 4 в Вашем случае.
Плюс, обычно стоит давать разные приоритеты разным словам. Например, если у нас почти все элементы пришли из хрома, то поиск по запросу "хром" практически не должен учитывать заголовки. А вот в содержимом слово хром очень даже много значит. Это базово решается при помощи tf-idf (хотя и не совсем классическое применение).
Боюсь, это всё также довольно легко осваивается "вчерашними студентами" и вообще не является мерилом "сеньористости" (что бы это не значило).
Просто есть люди, которым заходит инженерия (всякие обходы деревьев или нюансы устройства индексов в бд), а есть кому заходит бизнес (как фичи деливерить и пофиг что здесь квадрат). Обычно нужны и те и другие — дальше вопрос только в балансе как в количестве, так и в соотношении качеств отдельных индивидов. И вот баланс уже зависит от компании и её потребностей.
то флаш кэша занимающий 5мс очевидно ничтожен по сравнению с запросами в интернет занимающими в десятки и сотни раз больше;
В этом случае у нас просто линейный Put. Амортизация тут неприменима. И тогда выигрыша от реализации 2.5 никакого нет.
Но в любом случае, O(n) кеш штука изначально довольно специфичная. Предлагать её без дополнительных вводных — странно.
кэш в процессорах ARM вообще на рандомную стратегию переделали ...
Ну так там же кеш по бакетам(в каждом бакете независимое вытеснение). И размер одного бакета 4-32, емнип. Это как раз ситуация довольно специфичная.
всё правильно, тут всё таки демонстрационная реализация :) к сожалению устройство и возможности мэпы конкретно в Go делают её особенно неудобной для любого "продвинутого" применения
Кажется было бы хорошо вставить по этому поводу комментарий — для неискушённых читателей. Впрочем, печально, что нет доступа к продвинутым юзкейсам (хотя в целом понятно почему).
При самописной реализации хештаблицы выигрыш от альтерантивных схем становится меньше. Можно же спокойно хранить ноды в стиле linked hashmap — и тогда выигрыш по памяти становится слабым (+заменить указатели на 32-битные индексы чтобы ещё ближе к другим вариантам стать).
Ну и как правило LRU не прям хорошо работает. Поэтому достаточно часто нужны гибридные стратегии — и там обычно тяжело отказаться от связных списков.
Здесь вместо внятно аргументации заголовка, просто самописная реализация хештаблицы. Это, как минимум, предаёт ожидания.
Дальше, позиция "поиск в хештаблице за O(1*)" более полезна, чем "поиск за O(n)". Вопрос только в том, в каком именно смысле там O(1) (этому можно придать строгую формулировку). В статье с таким заголовком я бы ожидал именно разбора различных формулировок и следствий из них.
Ну и в целом, хештаблицы — это инженерный трюк. А потому, разбирать абстрактную хештаблицу в вакууме смысла мало. Если уж и разбирать, то нужно брать конкретные реализации и особенности их работы.
Например, если взять хештаблицу в яве, то там не будет поиска O(n) даже в присутствии колизий (если ключи какие-нибудь строки, или числа — что почти всегда так). Просто потому, что бакеты там устроены как деревья, а не связанные списки.
Или, если взять хештаблицу в C#/Rust, то там другой подход. Там используется достаточно хорошая хешфункция, что спровоцировать колизии достаточно сложно даже в режиме "злоумышленика".
Кажется вариант 2 ввиду амортизации неприменим на практике. Обычно же этот lru требуется в онлайн задачах. Крайне редко он нужен в оффлайн алгоритмах.
Ну и использование итерации по мапе в качестве семплирования — не очень хорошо. Сразу по нескольким причинам. Никто же не обещает порядка итерации по мапе — это не то же самое, что и случайный порядок. Ну и в принципе, такая итерация использует внешнюю случайность — то есть она зависит от данных. Это плохо, так как данные могут быть скорелированны. Для робастности нужно использовать внутреннюю случайность.
Почему? В смысле, с ним не больше боли, чем в самом тс.
P.S. ну понятное дело, что в идеале any должен значить unknown, а реальный any должен называться untyped/typehole. Но это отдельный разговор, т.к. на уровне самого кодгена несложно заменить any на unknown.
Понятное дело, что динамика медленная. Но в качестве фоллбэка вполне себе норм. Потому что просто выкинуть существенно часть языка — решение такое себе.
Не очень понятно, а какую цель преследовали, зачем именно отказываться от v8? Может лучше было сделать фреймворк для биндингов, чтобы можно было легко вызывать ts код. В v8, емнип, довольно хорошо эта история должна быть проработана.
Ну и вопрос сравнений перфа, наверное, тоже не осветили. Хотя набор бенчиакров здесь сложновато найти, конечно.
Почему не смогли поддержать any? Его же можно в условный AnyJsValue транслировать и использовать динамические возможности... Смотрели в эту сторону?
Закладку можно спрятать много где. Даже в релейной защите. И вообще говоря, внешними тестами эту закладку не обнаружить. Для обнаружения закладки где-либо требуется как минимум реверс...
Если речь о гсч, то это не прям сильно повышает степень защиты. Современные ксгспч генерируют достаточно стойкие ключи для большинства приложений.
Если речь о протоколах установления общего секрета, то они же все имеют очень сильные технические ограничения к каналам связи... Так-то понятное дело, что прокопать прямой провод до объекта всегда лучше, чем использовать общественные сети — но это редко целесообразно.
Это не совсем тот тезис, который я здесь говорю. Я лишь говорю о том, что аналогично тестам и симуляциям для физического оборудования, точно также можно делать тесты и фаззинг для тех же МЭ. Т.е. пример из Вашей статьи не совсем честный.
А вот качество что тех, что других тестов — это уже на совести и доверии к производителю...
P.S. хабр съел конец предыдущего комментария: "что именно подразумевается под ПАК ИБ на квантовых принципах? Речь о постквантовой криптографии, или о всяких bb84 и ко?"
Автотесты и фаззинг вполне себе закрывает эту проблему. Другое дело, что обычно тяжело проверить покрытие и тщательность проверок — но аналогичная история с вышеупомянутыми релейными защитами: никто не знает насколько тщательное покрытие были в их тестах (и оно гарантированно не исчерпывающие...).
Поэтому этот тезис опять же выливается в доверие к людям.
С капчами, как и со всякими waf/antiddos сложность в том, что для них нужен масштаб применения. И у хабиа, кажется, недостаточный охват, чтобы реализовать вменяемую (поведеньческую) капчу.
Я не знаю откуда возник этот миф, как будто олимпиадники какие-то глупые люди и не умеет учитывать контекст. Я скорее наблюдаю картину наоборот...
Ну и имеет смысл определится сразу с ограничениями: какой объём данных Вы будете обрабатывать максимум (растить историю бесконечно смысла особого не имеет)
Векторные произведения концепт чисто геометрический, и вне собственно геометрических задач смысла особо не имеет. Поэтому, учитывая упор на анализ данных, как, было бы лучше вообще не рассказывать про векторное произведение. Пример крайне притянутым за уши выглядит...
Вместо этого лучше просто скорить совпадения. Например, если пользователь искал "motivating example", то есть большая разница между кейсами:
Нашли эти два слова подряд
Нашли эти два слова рядом (на расстоянии меньше D слов)
Нашли этидва слова в разных концах содержимого
Нашли одно слово в содержимом а другое в приложении
Поэтому Вам стоит просто ранжировать совпадения на основании того, а как близко находятся матчи. При этом я не уверен, что вариант 3 более релевантен чем вариант 4 в Вашем случае.
Плюс, обычно стоит давать разные приоритеты разным словам. Например, если у нас почти все элементы пришли из хрома, то поиск по запросу "хром" практически не должен учитывать заголовки. А вот в содержимом слово хром очень даже много значит. Это базово решается при помощи tf-idf (хотя и не совсем классическое применение).
Я видел использование обычного рандома в шифровальшике. При том дело было на шарпе — вроде там неплохо сделан доступ к криптостойкому ГСПЧ...
Боюсь, это всё также довольно легко осваивается "вчерашними студентами" и вообще не является мерилом "сеньористости" (что бы это не значило).
Просто есть люди, которым заходит инженерия (всякие обходы деревьев или нюансы устройства индексов в бд), а есть кому заходит бизнес (как фичи деливерить и пофиг что здесь квадрат). Обычно нужны и те и другие — дальше вопрос только в балансе как в количестве, так и в соотношении качеств отдельных индивидов. И вот баланс уже зависит от компании и её потребностей.
В этом случае у нас просто линейный Put. Амортизация тут неприменима. И тогда выигрыша от реализации 2.5 никакого нет.
Но в любом случае, O(n) кеш штука изначально довольно специфичная. Предлагать её без дополнительных вводных — странно.
Ну так там же кеш по бакетам(в каждом бакете независимое вытеснение). И размер одного бакета 4-32, емнип. Это как раз ситуация довольно специфичная.
Кажется было бы хорошо вставить по этому поводу комментарий — для неискушённых читателей. Впрочем, печально, что нет доступа к продвинутым юзкейсам (хотя в целом понятно почему).
При самописной реализации хештаблицы выигрыш от альтерантивных схем становится меньше. Можно же спокойно хранить ноды в стиле linked hashmap — и тогда выигрыш по памяти становится слабым (+заменить указатели на 32-битные индексы чтобы ещё ближе к другим вариантам стать).
Ну и как правило LRU не прям хорошо работает. Поэтому достаточно часто нужны гибридные стратегии — и там обычно тяжело отказаться от связных списков.
P.S. не поймите неправильно, статья интересная
Здесь вместо внятно аргументации заголовка, просто самописная реализация хештаблицы. Это, как минимум, предаёт ожидания.
Дальше, позиция "поиск в хештаблице за O(1*)" более полезна, чем "поиск за O(n)". Вопрос только в том, в каком именно смысле там O(1) (этому можно придать строгую формулировку). В статье с таким заголовком я бы ожидал именно разбора различных формулировок и следствий из них.
Ну и в целом, хештаблицы — это инженерный трюк. А потому, разбирать абстрактную хештаблицу в вакууме смысла мало. Если уж и разбирать, то нужно брать конкретные реализации и особенности их работы.
Например, если взять хештаблицу в яве, то там не будет поиска O(n) даже в присутствии колизий (если ключи какие-нибудь строки, или числа — что почти всегда так). Просто потому, что бакеты там устроены как деревья, а не связанные списки.
Или, если взять хештаблицу в C#/Rust, то там другой подход. Там используется достаточно хорошая хешфункция, что спровоцировать колизии достаточно сложно даже в режиме "злоумышленика".
Поэтому разбор странный.
Кажется вариант 2 ввиду амортизации неприменим на практике. Обычно же этот lru требуется в онлайн задачах. Крайне редко он нужен в оффлайн алгоритмах.
Ну и использование итерации по мапе в качестве семплирования — не очень хорошо. Сразу по нескольким причинам. Никто же не обещает порядка итерации по мапе — это не то же самое, что и случайный порядок. Ну и в принципе, такая итерация использует внешнюю случайность — то есть она зависит от данных. Это плохо, так как данные могут быть скорелированны. Для робастности нужно использовать внутреннюю случайность.
Понятно, что пробовали писать приложение на смеси c++ и TS. Вопрос в том, почему взялись за компиляцию, а не за интеграцию условного v8?
Ну, bun или v8 не так уж и важно. Это в любом случае меньше работы, чем написать комплиятор
Почему? В смысле, с ним не больше боли, чем в самом тс.
P.S. ну понятное дело, что в идеале any должен значить unknown, а реальный any должен называться untyped/typehole. Но это отдельный разговор, т.к. на уровне самого кодгена несложно заменить any на unknown.
Как раз наоборот. Динамика обычно требует pro, чтобы работать не прям совсем медленно.
Понятное дело, что динамика медленная. Но в качестве фоллбэка вполне себе норм. Потому что просто выкинуть существенно часть языка — решение такое себе.
Не очень понятно, а какую цель преследовали, зачем именно отказываться от v8? Может лучше было сделать фреймворк для биндингов, чтобы можно было легко вызывать ts код. В v8, емнип, довольно хорошо эта история должна быть проработана.
Ну и вопрос сравнений перфа, наверное, тоже не осветили. Хотя набор бенчиакров здесь сложновато найти, конечно.
Почему не смогли поддержать any? Его же можно в условный AnyJsValue транслировать и использовать динамические возможности... Смотрели в эту сторону?
Справедливости ради, подсчёт чисел Фибоначчи через цикл - это и есть тот самый другой алгоритм :)