Почему-то я никогда не слышал ни об одной компании, которая блокировала у себя в сети доступ к AWS, чтобы сотрудники, не дай бог, случайно не подняли там business-critical сервис. Обычно можно просто объявить о необходимости использовать только единственное выбранное облако, а также осуществить туда переезд всех имеющихся сервисов. Проблема только в том, что никто этим заниматься не захочет, но проблемы планирования такие масштабных проектов давно известны, как и способы борьбы с ними.
Банит только если сессия одновременно используется с двух разных IP. При переключении IP меняется и со старого запросы естественным образом перестают ходить.
Нет, потому что двухфакторка обменивается на файл сесии, а вот его уже можно угнать.
Но у телеграма есть некоторая защита в том, что если одна сессия используется одновременно с двух разных ip, то телеграм её мгновенно банит и нужно будет проходить флоу авторизации по новой, а это уже будет очень заметно для пользователя. Поэтому украв сессию, нужно её сначала удалить с компьютера пользователя и тем самым разлогинить его оттуда =)
Единственный вариант защититься — при каждой попытке логина (даже своими руками) проверять список активных сессий в настройках приложения на наличие дублей и всякой подозрительной активности.
Ну там O(N) по операциям с памятью как ни крути и сверху либо O(1), либо O(N) по запросам к БД. Тут сразу ясно что лучше =)
Как-то в университете была лаба, где как раз сравнивались алгоритмы сортировки на предмет количества сравнений/свопов/памяти и приходили к интересным выводам (если надо посортить книги человеку руками, то внезапно каждый своп оказывается очень дорогим)
Замечу, что это будет работать только если бинарь компилировался с точностью той же версией rustc, которая используется при запуске.
У Rust так и нет никакого стабильного ABI, из-за чего нет никаких гарантий, что ваши бинари будут друг с другом совместимы, если компилировались по-разному.
А в чём проблема? Это вызывает какие-то проблемы при работе, что-то начинает работать хуже?
Если в ОС есть виртуальная память и качественно реализован механизм свопа, то какая разница сколько памяти потребляет приложение, если эта память повышает его отзывчивость?
Пока человек не пытается прокручивать галереи, всё у него будет хорошо и приятно — кеш куда-то на диск прозрачно выгружен. А если вдруг понадобилось галереи таки прокручивать, то снова всё будет хорошо и приятно — компактный кеш быстро загрузится с диска в память и не придётся переваривать большие оригиналы. Не вижу здесь сценария, где пользователь страдает и при этом можно его страдания облегчить через ограничение кеша.
Конечно хочется чтобы кеш не вытеснял память каких-то важных программ, чтобы потом уже их загружать не приходилось. Но, во-первых, у нас сейчас есть чертовски быстрые SSD и сжатие сверху — грубо кажется, что подгрузка займёт где-то столько же времени, сколько анимация переключения с Finder на что-то другое. А во-вторых, тут уж либо галереи смотреть, либо работать — если ограничить у кого-то одного память, то он нещадно начнёт лагать и ничего с этим не сделать.
Сильно зависит от компании и подходов. У меня, например, прямо сейчас премия напрямую зависит от того, сколько пользователей станут пользоваться моим кодом. И у меня довольно большая мотивация чуть подумать, провести 1.5 часа на встречах и отбросить какой-то узкоспециализированный функционал на время после выплаты премий, чтобы сейчас сэкономить себе пару дней его реализации и отполировать какие-то моменты.
У автора стоит задача нанять человека, который будет не тупо писать код. Он хочет человека, который будет держать в уме задачи бизнеса и разумно тратить своё время (и деньги работодателя).
Каждый impl в любом случае должен перечислить все дженерики и ограничения на них. Здесь нужны trait aliases, но они так и не стабилизированы.
Боль автора очень понимаю, особенно если вдруг показалось красивым запихать в поле структурки какой-нибудь associated type — тогда копипастить придётся совершенно безальтернативно.
Реализовывать общие для всех 80% потребностей не очень сложно. Но тогда каждому будет не хватать каких-то 20% фич и все ваши пользователи будут слегка страдать. А вот эти оставшиеся недостающие фичи для каждого человека будут достаточно уникальны.
Если фича нужна далеко не всем, то это никак не означает, что она не нужна. Лишь бы ресурсы были её реализовать и при этом гармонично совместить со всем остальным функционалом.
itertools работает с итераторами, у которых далеко не всегда есть произвольный доступ. Если вдруг у вас он есть, то лучше использовать его явно (ну или что-то кроме itertools)
Конкретно YubiKey всегда (в т.ч. после исчерпания всех попыток) можно сбросить в ноль и залить на него новый ключ. Но старый при этом умирает безвозвратно, в чём и идея. Платить не придётся =)
Но все таки в диаграмму и по c100k и по c1000k вывели записали какие-то данные.
Вариант с платформенными тредами как раз таки (ожидаемо) довольно быстро вылетел из соревнования и с большими числами запускался уже только Thread.startVirtualThread
На самом деле у вас не запустились таски одновременно
Они определённо не запустились in parallel — ни ядер, ни системных потоков никак не хватит. Но я уверен, что объекты тасок создавались и каждая concurrently ждала своего sleep(10) — ни одна таска не завершилась раньше десяти секунд. Кажется в этом же и суть бенчмарка — насоздавать (легковесных) тасок и посмотреть накладные расходы. А внутри них sleep чтобы весь миллион действительно висел в памяти в один момент времени.
Так что и не уверен, что какая-нибудь платфрома не забила и не оптимизировала
I/O-bound таске и не нужен отдельный поток для себя одной, а у нас здесь именно такие. При этом я плохо представляю как платформа может оптимизировать запуск миллиона тасок ждущих 10 секунд в что-то более оптимальное вроде «одна таска которая ждёт 10+ε секунд». У нас же есть сайд-эффект, что программа выполняется вполне конкретное время, его надо как-то сохранить.
Было бы интересно увидеть как изменятся графики
К сожалению, я не автор, а лишь простой мимокрокодил =)
В моём понимании, весь этот тест задумывался именно как анализ накладных расходов на запуск тасок внутри разных рантаймов, а не как эксперимент по запуску миллиона системных тредов из разных языков. И тогда он получается почти полностью осмысленный. Огорчает что правда почти никаких реальных ресурсов не создаётся и переключений между тасками нету, но может оно и к лучшему.
Без прогрева JVM
Сравнивается же память, а не время. Кажется, прогрев здесь не поможет, нет? Мне честно интересно, я с JVM почти не сталкиваюсь, на самом деле.
С++ нет в сравнении
А в нём есть какой-то достаточно меинстримный event loop? Всё-таки здесь по большей части сравниваются рантаймы, чем умение запустить миллион системных тредов из десяти разных языков. Опять не знаю ответа, на самом деле.
Автор не пользуется формулой расчета количества потоков
Если я всё правильно понимаю, то тут как раз таки блокирующий sleep и имеет смысл именно что запускать миллион тасок одновременно: на CPU нагрузки считай что нет. А вот память на обработку этих тасок действительно интересно поглядеть.
Отсутствует нивелирование тред пулом,
Большинство здесь приведённых рантаймов как раз таки раскидывают таски по тредам из своего пула. Не ручками же это реализовать, коли язык уже содержит довольно хорошую реализацию.
То есть цель всего этого — защитить лишь пароль пользователя, если вдруг где-то на сервере тот будет логироваться? Ну если сервис скомпрометирован, то данные на нем тоже и тогда пароль теряет смысл и защищать его уже как-то не очень нужно, ИМХО.
защита от MitM? Кажется, что эта схема не может быть лучше.
защита от слива базы? Эта схема позволяет имея только «серверные» данные узнать, является ли тот или иной пароль правильным. Ну а дальше делается обычный брутфорс, не вижу особенных преимуществ над обычными хорошо солеными хешами.
защита от недоверенного сервера? TLS гарантирует аутентичность, а дальше если хоть какие данные в нешифрованном виде вдруг бывают на недоверенном сервере, то можно их смело считать раскрытыми. Тут только всё шифрование на клиенте выполнять — но про это как раз в конце сказали.
Разве что здесь строго доказано, что брутфорс нельзя облегчить какой-нибудь уязвимостью в алгоритме хеширования. Но стоит ли оно того? Если вдруг злоумышленник получил доступ к базе с паролями, то имеет смысл считать, что все менее защищенные данные уже скомпрометированы. Тут остается только попытаться защитить сам пароль пользователя, но если он вдруг использует один на нескольких сервисах, то надёжность этого пароля определяется надёжностью самого уязвимого сервиса.
Предполагается, что где-то в вашей локальной сети будет машинка, которая обслуживает эту подсеть и выступает NAT из одного в другое. И она не должна быть доступна в большом интернете, ибо локальных сетей много.
Банально чтобы ходить в IPv4 вам понадобиться IPv4-адрес для этого, а их мало — пусть каждая локальная сеть решает эту проблему как-нибудь сама.
Почему-то я никогда не слышал ни об одной компании, которая блокировала у себя в сети доступ к AWS, чтобы сотрудники, не дай бог, случайно не подняли там business-critical сервис. Обычно можно просто объявить о необходимости использовать только единственное выбранное облако, а также осуществить туда переезд всех имеющихся сервисов. Проблема только в том, что никто этим заниматься не захочет, но проблемы планирования такие масштабных проектов давно известны, как и способы борьбы с ними.
Банит только если сессия одновременно используется с двух разных IP. При переключении IP меняется и со старого запросы естественным образом перестают ходить.
Нет, потому что двухфакторка обменивается на файл сесии, а вот его уже можно угнать.
Но у телеграма есть некоторая защита в том, что если одна сессия используется одновременно с двух разных ip, то телеграм её мгновенно банит и нужно будет проходить флоу авторизации по новой, а это уже будет очень заметно для пользователя. Поэтому украв сессию, нужно её сначала удалить с компьютера пользователя и тем самым разлогинить его оттуда =)
Единственный вариант защититься — при каждой попытке логина (даже своими руками) проверять список активных сессий в настройках приложения на наличие дублей и всякой подозрительной активности.
Ну там O(N) по операциям с памятью как ни крути и сверху либо O(1), либо O(N) по запросам к БД. Тут сразу ясно что лучше =)
Как-то в университете была лаба, где как раз сравнивались алгоритмы сортировки на предмет количества сравнений/свопов/памяти и приходили к интересным выводам (если надо посортить книги человеку руками, то внезапно каждый своп оказывается очень дорогим)
Пока ещё есть, но акцент на них со временем становится всё меньше и меньше, а релизы — приносят всё меньше больших изменений и более рутинны.
Если кому интересно, то я нагуглил числа теплоёмкости (при 25°С), вышло примерно одинаково:
Источник: https://www.batterydesign.net/thermal/
Для сравнения:
Стекло: 840J/kg
Вода обычная: 4100 J/kg.
(а при низкой температуре теплоёмкость скорее даже будет ещё меньше)
Замечу, что это будет работать только если бинарь компилировался с точностью той же версией rustc, которая используется при запуске.
У Rust так и нет никакого стабильного ABI, из-за чего нет никаких гарантий, что ваши бинари будут друг с другом совместимы, если компилировались по-разному.
С недавних пор появился https://ytsaurus.tech/ru =)
А в чём проблема? Это вызывает какие-то проблемы при работе, что-то начинает работать хуже?
Если в ОС есть виртуальная память и качественно реализован механизм свопа, то какая разница сколько памяти потребляет приложение, если эта память повышает его отзывчивость?
Пока человек не пытается прокручивать галереи, всё у него будет хорошо и приятно — кеш куда-то на диск прозрачно выгружен. А если вдруг понадобилось галереи таки прокручивать, то снова всё будет хорошо и приятно — компактный кеш быстро загрузится с диска в память и не придётся переваривать большие оригиналы. Не вижу здесь сценария, где пользователь страдает и при этом можно его страдания облегчить через ограничение кеша.
Конечно хочется чтобы кеш не вытеснял память каких-то важных программ, чтобы потом уже их загружать не приходилось. Но, во-первых, у нас сейчас есть чертовски быстрые SSD и сжатие сверху — грубо кажется, что подгрузка займёт где-то столько же времени, сколько анимация переключения с Finder на что-то другое. А во-вторых, тут уж либо галереи смотреть, либо работать — если ограничить у кого-то одного память, то он нещадно начнёт лагать и ничего с этим не сделать.
Сильно зависит от компании и подходов. У меня, например, прямо сейчас премия напрямую зависит от того, сколько пользователей станут пользоваться моим кодом. И у меня довольно большая мотивация чуть подумать, провести 1.5 часа на встречах и отбросить какой-то узкоспециализированный функционал на время после выплаты премий, чтобы сейчас сэкономить себе пару дней его реализации и отполировать какие-то моменты.
У автора стоит задача нанять человека, который будет не тупо писать код. Он хочет человека, который будет держать в уме задачи бизнеса и разумно тратить своё время (и деньги работодателя).
Каждый impl в любом случае должен перечислить все дженерики и ограничения на них. Здесь нужны trait aliases, но они так и не стабилизированы.
Боль автора очень понимаю, особенно если вдруг показалось красивым запихать в поле структурки какой-нибудь associated type — тогда копипастить придётся совершенно безальтернативно.
Реализовывать общие для всех 80% потребностей не очень сложно. Но тогда каждому будет не хватать каких-то 20% фич и все ваши пользователи будут слегка страдать. А вот эти оставшиеся недостающие фичи для каждого человека будут достаточно уникальны.
Если фича нужна далеко не всем, то это никак не означает, что она не нужна. Лишь бы ресурсы были её реализовать и при этом гармонично совместить со всем остальным функционалом.
А как же следующее?
sum(my_list[i] for i in range(10, 21))itertools работает с итераторами, у которых далеко не всегда есть произвольный доступ. Если вдруг у вас он есть, то лучше использовать его явно (ну или что-то кроме itertools)
Конкретно YubiKey всегда (в т.ч. после исчерпания всех попыток) можно сбросить в ноль и залить на него новый ключ. Но старый при этом умирает безвозвратно, в чём и идея. Платить не придётся =)
Если тапнуть по обрезанной ссылке, то она разворачивается
Hidden text
Вариант с платформенными тредами как раз таки (ожидаемо) довольно быстро вылетел из соревнования и с большими числами запускался уже только
Thread.startVirtualThreadОни определённо не запустились in parallel — ни ядер, ни системных потоков никак не хватит. Но я уверен, что объекты тасок создавались и каждая concurrently ждала своего sleep(10) — ни одна таска не завершилась раньше десяти секунд. Кажется в этом же и суть бенчмарка — насоздавать (легковесных) тасок и посмотреть накладные расходы. А внутри них sleep чтобы весь миллион действительно висел в памяти в один момент времени.
I/O-bound таске и не нужен отдельный поток для себя одной, а у нас здесь именно такие. При этом я плохо представляю как платформа может оптимизировать запуск миллиона тасок ждущих 10 секунд в что-то более оптимальное вроде «одна таска которая ждёт 10+ε секунд». У нас же есть сайд-эффект, что программа выполняется вполне конкретное время, его надо как-то сохранить.
К сожалению, я не автор, а лишь простой мимокрокодил =)
В моём понимании, весь этот тест задумывался именно как анализ накладных расходов на запуск тасок внутри разных рантаймов, а не как эксперимент по запуску миллиона системных тредов из разных языков. И тогда он получается почти полностью осмысленный. Огорчает что правда почти никаких реальных ресурсов не создаётся и переключений между тасками нету, но может оно и к лучшему.
Сравнивается же память, а не время. Кажется, прогрев здесь не поможет, нет? Мне честно интересно, я с JVM почти не сталкиваюсь, на самом деле.
А в нём есть какой-то достаточно меинстримный event loop? Всё-таки здесь по большей части сравниваются рантаймы, чем умение запустить миллион системных тредов из десяти разных языков. Опять не знаю ответа, на самом деле.
Если я всё правильно понимаю, то тут как раз таки блокирующий sleep и имеет смысл именно что запускать миллион тасок одновременно: на CPU нагрузки считай что нет. А вот память на обработку этих тасок действительно интересно поглядеть.
Большинство здесь приведённых рантаймов как раз таки раскидывают таски по тредам из своего пула. Не ручками же это реализовать, коли язык уже содержит довольно хорошую реализацию.
То есть цель всего этого — защитить лишь пароль пользователя, если вдруг где-то на сервере тот будет логироваться? Ну если сервис скомпрометирован, то данные на нем тоже и тогда пароль теряет смысл и защищать его уже как-то не очень нужно, ИМХО.
А в чём преимущество над стандартным TLS?
защита от MitM? Кажется, что эта схема не может быть лучше.
защита от слива базы? Эта схема позволяет имея только «серверные» данные узнать, является ли тот или иной пароль правильным. Ну а дальше делается обычный брутфорс, не вижу особенных преимуществ над обычными хорошо солеными хешами.
защита от недоверенного сервера? TLS гарантирует аутентичность, а дальше если хоть какие данные в нешифрованном виде вдруг бывают на недоверенном сервере, то можно их смело считать раскрытыми. Тут только всё шифрование на клиенте выполнять — но про это как раз в конце сказали.
Разве что здесь строго доказано, что брутфорс нельзя облегчить какой-нибудь уязвимостью в алгоритме хеширования. Но стоит ли оно того? Если вдруг злоумышленник получил доступ к базе с паролями, то имеет смысл считать, что все менее защищенные данные уже скомпрометированы. Тут остается только попытаться защитить сам пароль пользователя, но если он вдруг использует один на нескольких сервисах, то надёжность этого пароля определяется надёжностью самого уязвимого сервиса.
Предполагается, что где-то в вашей локальной сети будет машинка, которая обслуживает эту подсеть и выступает NAT из одного в другое. И она не должна быть доступна в большом интернете, ибо локальных сетей много.
Банально чтобы ходить в IPv4 вам понадобиться IPv4-адрес для этого, а их мало — пусть каждая локальная сеть решает эту проблему как-нибудь сама.