А почему в одном ЯП? Кто такое ограничения наложил?
Там квантор всеобщности, очевидно. Т.е. можно кидать в одном и ловить в другом, а можно наоборот, кидать во второй и ловить в первом (или вообще в третьем).
В целом, кроссязыковые исключения уже очень давно поддерживается много кем. Там есть разные виды синтаксиса, но в Ваших примерах та же проблема присутствует.
Другое дело, что моделей обработки ошибок есть много и разных. И они, к сожалению, не очень совместимы между собой. Например в тех же го, или расте в принципе не принято кидать исключения — и если бы кто-то захотел бы интегрировать их в AS/400, то Ваш ILE бы перестал быть таким красивым...
Вы кажется смешиваете фреймворк/платформу для разработки и серверные ОС. Понятное дело, что хорошая платформа для разработки должна поддерживать единую систему обработки ошибок (и не важно, десктоп/сервер/консоль). Но таковых очень много. Банально, Вы можете даже скрестить C++ и джаву без особой боли (если принять модель ошибок явы...).
Находясь в терминальной сессии можно программу запустить как в рамках этого же задания
А, ну тогда это скорее аналог cgroup или Job (в вин).
Если в той же винде я могу "занавесить" всю систему просто загнав программу в бесконечный цикл, то здесь так не выйдет. Можно "занавесить" задание, но такое задание всегда можно принудительно завершить командой endjob из любого другого задания. Т.е. все, что происходит в задании, происходит только в этом задании и никак не влияет на остальные.
Ну, это скорее особенность винды, т.к. она пытается притворился, что программы умирают кооперативно. В том же линуксе спокойно можно убить любой процесс не дожидаясь ничего. Но различия этих подходов никак не связаны с десктопной vs серверной ОС — это просто разные дизайн решения, с разными трейдоффами на тему cancelation (каноничная проблема: если задание отправило сетевой пакет на перегрузку реактора, то крайне не хочется убивать это задание, пока оно не отправит пакет на отмену...).
Аналогично про временные ресурсы: в любой адекватной ОС хочется иметь механизмы аллокации временных ресурсов(файлов и прочего), которые ОС сама подчистит после завершения процесса/задачи. Поэтому опять же не про серверную ОС.
На самом деле может. С использованием одноуровневой модели памяти накладные расходы на переключение контекста заданий стремятся к нулю.
Ну так это решение на уровне железа! Можно пойти дальше и взять тот же cheri и там тоже всё будет быстро :)
В общем и в целом, пока что все софтовые различия, которые Вы описываете имеют вполне себе неплохие аналоги в тех же Win/Lin.
То есть я пока не вижу какого-то функционала, которого нет в условном Win именно по причине, что это "десктопная ОС". И чтобы при этом, данный функционал сделал десктопный опыт хуже.
Я понимаю, что AS/400 сделана достаточно интересно и в ней есть много интересных/хороших решений. Но пока что я не вижу чем эти решения "принципиально серверные".
так, чтобы даже самая кривая программа в одном задании не могла оказать влияние на все остальные
В общем случае, не очень понятно, что это значит. Я так понимаю, что "задача" примерно соответствует "потоку" (или же процессу)? Любому потоку отдаётся ограниченный таймслайс и занести в лаги он может исключительно при большом количестве потоков — но это уже административная проблема. Ну и если действивтельно появляется такое требование, то есть всякие ulimit/cgroups/job/etc — чтобы ограничить потребление ресурсов группы процессов.
Второй момент - время переключения контекста заданий. В винде/линуксе это достаточно большие накладные расходы.
Так эти накладные расходы вызваны наличием виртуальной памяти — то есть вышеупомянутой изоляции. Что здесь серверная ОС может сделать по-другому?
Третий момент - системное логирование, журналирование изменения объектов. На серверной ОС всем этим должна заниматься система (системные журналы, логи заданий...).
Вроде с этим все успешно справляются на уровне дистрибутивов. Тот же journald довольно неплохо реализует агрегацию логов.
Четвертый момент - поддержка исключений на уровне системы, а не ЯП. Т.е. вы не должны ориентироваться на языковые исключения, а иметь в доступе простой механизм использования системных с возможностью проброса их на любой уровень стека вызовов по необходимости.
Что здесь имеется ввиду и зачем это нужно? Ну, вот в той же вроде есть SEH — можно кидать исключения в одном ЯП а ловить в другом. Но не очень понятно, что это принципиально меняет (в любом случае стараются держать каждый процесс на одном ЯП)...
Закладку можно спрятать много где. Даже в релейной защите. И вообще говоря, внешними тестами эту закладку не обнаружить. Для обнаружения закладки где-либо требуется как минимум реверс...
формирование ключей с приживлением квантовой физики.
Если речь о гсч, то это не прям сильно повышает степень защиты. Современные ксгспч генерируют достаточно стойкие ключи для большинства приложений.
Если речь о протоколах установления общего секрета, то они же все имеют очень сильные технические ограничения к каналам связи... Так-то понятное дело, что прокопать прямой провод до объекта всегда лучше, чем использовать общественные сети — но это редко целесообразно.
Это не совсем тот тезис, который я здесь говорю. Я лишь говорю о том, что аналогично тестам и симуляциям для физического оборудования, точно также можно делать тесты и фаззинг для тех же МЭ. Т.е. пример из Вашей статьи не совсем честный.
А вот качество что тех, что других тестов — это уже на совести и доверии к производителю...
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.
Там квантор всеобщности, очевидно. Т.е. можно кидать в одном и ловить в другом, а можно наоборот, кидать во второй и ловить в первом (или вообще в третьем).
В целом, кроссязыковые исключения уже очень давно поддерживается много кем. Там есть разные виды синтаксиса, но в Ваших примерах та же проблема присутствует.
Другое дело, что моделей обработки ошибок есть много и разных. И они, к сожалению, не очень совместимы между собой. Например в тех же го, или расте в принципе не принято кидать исключения — и если бы кто-то захотел бы интегрировать их в AS/400, то Ваш ILE бы перестал быть таким красивым...
Вы кажется смешиваете фреймворк/платформу для разработки и серверные ОС. Понятное дело, что хорошая платформа для разработки должна поддерживать единую систему обработки ошибок (и не важно, десктоп/сервер/консоль). Но таковых очень много. Банально, Вы можете даже скрестить C++ и джаву без особой боли (если принять модель ошибок явы...).
Комментарий большой, поэтому отвечу по частям.
А, ну тогда это скорее аналог cgroup или Job (в вин).
Ну, это скорее особенность винды, т.к. она пытается притворился, что программы умирают кооперативно. В том же линуксе спокойно можно убить любой процесс не дожидаясь ничего. Но различия этих подходов никак не связаны с десктопной vs серверной ОС — это просто разные дизайн решения, с разными трейдоффами на тему cancelation (каноничная проблема: если задание отправило сетевой пакет на перегрузку реактора, то крайне не хочется убивать это задание, пока оно не отправит пакет на отмену...).
Аналогично про временные ресурсы: в любой адекватной ОС хочется иметь механизмы аллокации временных ресурсов(файлов и прочего), которые ОС сама подчистит после завершения процесса/задачи. Поэтому опять же не про серверную ОС.
Ну так это решение на уровне железа! Можно пойти дальше и взять тот же cheri и там тоже всё будет быстро :)
В общем и в целом, пока что все софтовые различия, которые Вы описываете имеют вполне себе неплохие аналоги в тех же Win/Lin.
То есть я пока не вижу какого-то функционала, которого нет в условном Win именно по причине, что это "десктопная ОС". И чтобы при этом, данный функционал сделал десктопный опыт хуже.
Я понимаю, что AS/400 сделана достаточно интересно и в ней есть много интересных/хороших решений. Но пока что я не вижу чем эти решения "принципиально серверные".
В общем случае, не очень понятно, что это значит. Я так понимаю, что "задача" примерно соответствует "потоку" (или же процессу)? Любому потоку отдаётся ограниченный таймслайс и занести в лаги он может исключительно при большом количестве потоков — но это уже административная проблема. Ну и если действивтельно появляется такое требование, то есть всякие ulimit/cgroups/job/etc — чтобы ограничить потребление ресурсов группы процессов.
Так эти накладные расходы вызваны наличием виртуальной памяти — то есть вышеупомянутой изоляции. Что здесь серверная ОС может сделать по-другому?
Вроде с этим все успешно справляются на уровне дистрибутивов. Тот же journald довольно неплохо реализует агрегацию логов.
Что здесь имеется ввиду и зачем это нужно? Ну, вот в той же вроде есть SEH — можно кидать исключения в одном ЯП а ловить в другом. Но не очень понятно, что это принципиально меняет (в любом случае стараются держать каждый процесс на одном ЯП)...
Закладку можно спрятать много где. Даже в релейной защите. И вообще говоря, внешними тестами эту закладку не обнаружить. Для обнаружения закладки где-либо требуется как минимум реверс...
Если речь о гсч, то это не прям сильно повышает степень защиты. Современные ксгспч генерируют достаточно стойкие ключи для большинства приложений.
Если речь о протоколах установления общего секрета, то они же все имеют очень сильные технические ограничения к каналам связи... Так-то понятное дело, что прокопать прямой провод до объекта всегда лучше, чем использовать общественные сети — но это редко целесообразно.
Это не совсем тот тезис, который я здесь говорю. Я лишь говорю о том, что аналогично тестам и симуляциям для физического оборудования, точно также можно делать тесты и фаззинг для тех же МЭ. Т.е. пример из Вашей статьи не совсем честный.
А вот качество что тех, что других тестов — это уже на совести и доверии к производителю...
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, чтобы работать не прям совсем медленно.