Спасибо) Вторая уже на подходе, думаю завтра послезавтра опубликую, очень мотивируют такие вопросы)
Смотрите, есть сервисы и репозитории домена, которые напрямую работают с сущностями и объектами домена, а есть сервисы, репозитории уровня приложения (Application). Приведу примеры:
Сервис поиска объектов по картинке: получает данные из сущности VideoFrame (доменный объект) -> ищет объекты на картинке в своей реализации -> возвращает список распознанных объектов (тоже доменный уровень)
Сервис рисования рамок на картинках. Тут уже нет ответственности домена, сам сервис никак домен не меняет и он даже не нужен для его работы.
С последним согласен полностью, это впоследствии очень упрощает жизнь, но в таком случае необходимо определять Bounded Context, работать через аггрегаты и вводить событийную модель. Но это очень сложно пока в рамках данного гайда.
Видимо стоило добавить "без негатива". Странно, что так люди агрятся, хотя вполне у автора исходного комментария и моего ответа положительный контекст)
А ещё вопрос. что если нам понадобится получить все кадры с камер на втором этаже, к какому репозиторию будет относится метод получения таких данных?
Если мы говорим про Read запросы, то ни к какому. Лучше и правильней создавать отдельные Query обработчики (Application) для сложных запросов, которые на вход получают DTO, и на выход сразу отдают DTO. Репозиторий нужен для того, чтобы извлечь из хранилища целостную сущность, произвести над ней какие-то операции и сохранить.
В будущем я планирую использовать Yolo и еще одну простую нейронку для дообработки (как раз здесь и будет фабрика нужна для сборки объекта). Скорость обработки там примерно 400мкс на каждый кадр. Если мы будем собирать кадры в сущность при каждом HTTP GET запросе, то каждый такой запрос будет супер медленно обрабатываться, а все преимущества того же Timescale улетучатся. С другой стороны, процесс самой обработки видео уже будет более сложным и он будет охватывать изменение нескольких сущностей, где важно собрать целостный объект, но там уже будут более простые запросы к БД.
Вообще очень интересный вопрос, которым я тоже задавался, но почему-то его не осветил(( Притом вопрос "А на фига все это?" сразу же всплывает на каком-нибудь TODO или интернет-магазине, ведь там и предлагают чаще всего использовать для Read моделей репозитории. Жаль, что этот момент прошляпил... Сделаю работу над ошибками прям здесь или в следующей статье. Большое спасибо.
Почему используется старый вариант типизации с List, Optional, Dict и прочим, вместо list | dict
Так же не понятно зачем в возвращаемых типах указывать имя класса в кавычках
Тупая привычка со времен старых версий питона. Но, спасибо за замечания, внесу в ближайшее время корректировки.
Действительно ли в питоне нужны классы фабрики? Почему не обойтись функцией, если прям будет нужда.
Время жизни фабрики может быть больше самого Usecase на уровне Application, а также могут понадобится параметры, которые непосредственно не участвуют в создании сущности или которые меняют логику создания исходя из конфигурации приложения (например мы потом поймем, что необходимо будет перевести фабрику в абстрактный класс, а уже считывание конфигураций реализовать на уровне Infra).
Я с вами полностью согласен, можно обойтись функцией в 100% случаев, а если уж прям захочется расширить сценарий, то у нас на этот случай есть прекрасные декораторы. Но статья для новичков и я подумал, что возможно материал будет перегружен таким образом. В целом раз есть замечание и оно безусловно крутое, стоило бы раскрыть мысль более подробно или вообще опустить их написание, пока не придем к слою Application.
Не совсем уверен, что генератор псевдослучайных чисел должен гарантировать одинаковые числа даже на одной платформе
Согласен, с вашим замечением, здесь я не совсем точно выразался. В качестве результата выступает не число с рандомайзера, а бинарь, который скомпилировался и будет работать прогнозируемо на любой платформе (проще говоря не падать из-за внутренних приколов ОС).
Rust имеет намного меньше платформ в поддержке, чем free pascal,
Turbo Pascal / Delphi / Free Pascal (может в современных версиях не так, я за ним вообще не слежу) использует свою собственную функцию генерации seed от времени. Когда используется такой подход, то проблем с переносимостью нет. Rust - это позволить себе не может, так как он позиционирует себя этаким образцом безопасности, а такой подход может открыть массу уязвимостей, если дело касается чувствительных систем. В другой ветке я писал:
Я не оправдываю Rust, я с ним живу, до этого более 10 лет писал на плюсах, поэтому привык сам решать, что безопасно, а что нет. Но в тоже понимаю Rust Foundation, если они будут такое тащить в std, то рано или поздно вылезут имбецилы из другого лагеря, которые будут орать: а где ваша безопасность (я не только сейчас про криптостойкость алгоритмов, но и про безопасную работу с ОС), вот тут такие возможности натворить фигню. Если честно, меня это шликанье на безопасность вообще бесит, особенно со стороны комьюнити (кто проходил собесы на Rust, то поймет). Я выбирал Rust по другим причинам.
Я вам больше скажу, у него из коробки есть свой рандомайзер, ведь нужно же как-то делать hashmap, просто его API скрыто, чисто из-за принципов и политик Rust.
fpc их поддерживает до сих пор актуальными, хотя имеет на порядок больше целей для сборки
Да он вообще глыба, уверен, что если бы он вышел хотя бы в начале 10-х (когда начался тренд на типизацию динамических языков), то Rust бы никто не создавал. Язык опередивший свое время...
Где конкретно я сказал, что mt19937 использует /dev/random для реализации алгоритма? Я специально перепрочитал всю ветку, нигде такого не написано! Во втором шаге (предыдущий коммент) нет ни одной ссылки, на то что на вход алгоритма обязательно необходимо передавать имеено такой сид из /dev/random. Ни где не указано, что в mt19937 конкретно есть проблема с многопоточностью, я указывал только на проблемы с криптостойкостью, о чем свидетельствуют множество статей в области кибербеза.
И почему вы так прицепились к криптографии хотя рандом используется в миллионе других вещей, и активнее всего как мне кажется в графике (шумы)
Специально для вас цитирую себя:
Я сказал где-то, что так делать обязательно? Без проблем, считайте как хотите, rust - на уровне концепта, не даёт это сделать "из коробки", чтобы какой-нибудь программист не взял эту функцию из коробки в основу своего криптоалгоритма. Если он может так сделать, то rust потеряет свою главную фичу - безопасность. Когда программист использует сторонние либы для таких целей, то ответственность с языка снимается.
Нигде не написано, что это круто и всем нужно так делать.
Еще раз повторяю: есть проблема на ПЕРВОМ шаге (это цифра 1) алгоритма, а именно получение данных источника сида. Не буду повторятся, проблемы я уже описал выше (почитайте, пожалуйста и попробуйте это в голове сохранить).
Ко второму шагу у меня вопросов нет, я его лишь УПОМЯНУЛ в рамках вопроса о криптостойкости, отметив проблему (вполне нейтрально) плюсов в этом вопросе (в контексте обсуждаемого вопроса): "почему C++ смог, а rust нет".
А сейчас давайте вернемся к моим первоначальным тезисам: 1) в Rust главная фича - это безопасть. 2) в std должны попадать только те вещи, которые повторяемы на любой платформе. 3) C++ вешает ответственность на самого программиста, Rust - такое не позволяет. 4) я не даю нравственных оценок, хороши ли перечисленные политики или плохи. Более того я указываю на проблемы в этих политиках на примере ассинхронщины.
Теперь давайте рассуждать в рамках ЭТИХ тезисов, почему rand (де-факто стандарт генерации случайных чисел в Rust) не попал в std: 1) Есть платформозависимая часть, которая будет работать неопределенно в мультипотоке. Плюс могут быть проблемы с переносимостью и поддержкой на разных ОС (компилятор должен собрать из всех native компонентов рабочий код, за исключением платформ где явно не указана дирректива #[no_std]). 2) Можно ли реализовать в стандартной либе только алгоритмы, выкинув формирование сида. Да можно, но это может привести к неопределенному поведению, если программист все же решит юзать системные вызовы. 3) Нельзя допустить, чтобы какие-то не криптостойкие штуки попали в std, потому что может найтись уникум их использующий, там где нельзя (криптография). А как мы знаем, сегодня один ChaCha12 (используется в библиотеке rand) классный и хороший, а завтра опубликуют серию разгромных статей на этот счет. Плюс тот же mt19937 быстрее, насколько я знаю, поэтому для статистических расчетов предпочтительней использовать его, зачем ограничивать программиста только ChaCha12? Поэтому если программист хочет использовать конкретный алгоритм, то пусть юзает сторонние либы, разбирается в них, это уже проблемы не Rust, а пользователя.
Понимаете, когда я веду дисскуссию об определенных вещах, то стараюсь сохранить контекст, того что мне писали или я писал. Но когда приходится цитировать самого себя же - это несколько грубо по отношению ко мне. Также, хочу отметить, если вы хотите узнать мнение человека, то спросите, не надо додумывать за него, если все же хотите додумать, то вам к психологу.
В заключении отвечу на последний ваш тезис:
Очень странное оправдание для раста.
Я не оправдываю Rust, я с ним живу, до этого более 10 лет писал на плюсах, поэтому привык сам решать, что безопасно, а что нет. Но в тоже понимаю Rust Foundation, если они будут такое тащить в std, то рано или поздно вылезут имбецилы из другого лагеря, которые будут орать: а где ваша безопасность (я не только сейчас про криптостойкость алгоритмов, но и про безопасную работу с ОС), вот тут такие возможности натворить фигню. Если честно, меня это шликанье на безопасность вообще бесит, особенно со стороны комьюнити (кто проходил собесы на Rust, то поймет). Я выбирал Rust по другим причинам.
P.S. А ведь если уметь поддерживать беседу более, чем в одно сообщение, не вырывать из контекста, и не заниматься демагогией, то можно было бы упрекнуть меня за реальные и интересные противоречия: как тогда живет hashmap? Почему нельзя сделать публичным randomizer внутри std, который используется в коллекциях? работа с ФС и файлами реализована, а вот с этим нет, почему? Вот это действительно странно!
Я думал у меня получится в одном сообщении, активировать ваш механизм внимания и вы сможете хоть чуть чуть сохранить контекст. Но к сожалению, я был слишком наивен и лучшего мнения о собеседнике.
К сожалению, я не могу вместить ответ в одно предложение, чтобы вы не запутались. Поэтому предлагаю на этом остановится. Вы правы, а я не прав, как хотите, мне уже надоело.
если он у вас внезапно появился, то у вас проблема явно есть проблемы с хранение контекста. Ну да ладно, сделаем скидку и попробую еще раз объяснить в одном сообщении:
Алгоритм в c++/random и в rust/rand (не std)
1) в качестве источника энтропии платформозависимый источник (процессор - это не платформа, на будущее). В linux это /dev/random или getrandom(), windows - CryptGenRandom, wasm window.crypto.getRandomValues()
2) создаётся chacha12, в плюсах std::mt19937. Дальше генерация чисел.
Rust из коробки не готов брать на себя ответственность за поведение этих типов в мультипотоке. В плюсах это ответственность на программисте.
Буквально, мой тезис написанный ДВА раза: в rust другая идеология попадания в функций в стандартную библиотеку. Перед этим, объясняю почему rand не попал в стандартную либу. В первом комментарии еще подчёркиваю проблему этого подхода на примере ассинхронщины.
Вы:
не надо тащить раст мышление в плюсы.
Какой-то Милонов-style получается.
Не все алгоритмы должны быть какими-то там "криптостойкими" и мифически "безопасными".
Я сказал где-то, что так делать обязательно? Без проблем, считайте как хотите, rust - на уровне концепта, не даёт это сделать "из коробки", чтобы какой-нибудь программист не взял эту функцию из коробки в основу своего криптоалгоритма. Если он может так сделать, то rust потеряет свою главную фичу- безопасность. Когда программист использует сторонние либы для таких целей, то ответственность с языка снимается.
Какая разница как выбирается зерно для алгоритма?
Вы как представляете это: есть список алгоритмов, а ты дальше к ним пишешь свой источник энтропии? На хера эти функции тогда тащить в std, если можно вынести в отдельную либу? где ты все это получаешь СРАЗУ?
Как он может быть "некриптостойким" - понятия не имею
Если вы понятия не имеете, то может просто загуглите исследования по этому поводу, притом исходное название алгоритма у вас есть. Я лично не хочу заниматься просвящением и копированием ссылок на статьи по этой теме, потому что ощущение, что я "играю с голубем в шахматы"
Давно у нас понятие платформа стало эквивалентно процессору?
В плюсах <random> использует такой же алгоритм, берется источник энтропии, который дёргает системный вызов ОС. Если в ос не удалось его найти, то вызов по сути фиктивный, что влечёт проблемы с безопасностью. Вроде еще там только поддерживается не особо криптостойкий алгоритм prng, но не берусь утверждать точно, может можно другие юзать. Ещё в плюсах ты сам решаешь как бороться с неопределнным поведение в мультипотоке, когда дергаешь эти вызовы. Rust такое на уровне концепта запрещает.
В расте не было проблем это реализовать в стандартной либе, просто идеология там другая по включению в нее, вот и все.
Генерация случайных чисел - это платформозависимая история, std в rust должен гарантировать одинаковый результат выполнения операций на любой платформе. Плюс это будет проблемы с многопоточностью, у того же /dev/random случаются зависания при недостатке энтропии. Ну и последнее в 1987 году не так парились насчёт безопасности и криптостойкости, поэтому в тех же делфях был (вроде) рандом от времени, что потенциально несёт риски для всех криптографических алгоритмов.
Резюмируя, в std должно попадать все, что работает прогнозируемо на любой платформе, остальное - идите в библиотеки. Поэтому, в том числе, такой цирк творится в ассинхронщине
У вас аргументация строится на уровне: ну хватит хейтить, ну это же первые попытки, вон, смотрите, есть даже что-то прикольное.
Целевая аудитория наших дистров - это не айтишники сидящие в уютных опенспейсах и попивающие кофе на кокосовом молоке. А ребята, которым надо разработать (иногда на месте) и накатить кучу специализированного софта + плюс офисные пакеты, где-нибудь на Ямале, и единственный след интернета, что у тебя есть, это флешка с архивами, которые ты скачал, чиля в гостинице во время пересадки в Иркутске. В том числе из-за этой проблемы, госуха так тяжело переходит на наши дистры и любит майкрософт - скачал драйвер пак/кучу программ на жёсткий и спокойно ездишь везде. Попробуй ту же убунту накатить, поставить кучу софта без инета - охренеешь. Ещё не забываем, что существуют режимные объекты, где флешку трудно пронести, а ПО ставится чуть ли не на дискетах.
И вот здесь современные дистры в последние годы большие молодцы. Вот тебе локальная репа раскатанная хоть на болванках, вот тебе средства упаковки и т.д. многие хейтят онлайн поддержку, но чаще всего требуется поддержка именно по телефону, притом иногда приходится подниматся на какую-нибудь гору или высокое дерево, чтобы позвонить. Посмотрим как знатоки английского бы общались с тех поддержкой canonical в таких условиях... кстати, поддержкой там выступают специалисты, а не девочка зачитывающая стандартные скрипты, типа "пробовали перезагрузить?".
Ещё забыл упомянуть очень старое железо, много где ещё стоит windows 2000 и на этого динозавра надо что-то поставить.
Напоследок остановлюсь ещё на одном моменте, разработка для любой госухи, хоть зарубежной, хоть нашей - это огромная бюррократическая работа, написание тонны документации и получение кучи справок. Итог: пилят продукт два с половиной проггера, а сопровождают документально пару сотен человек. Да, обидно, что так, но в нашей стране ещё не так все плохо как в некоторых более развитых странах.
В таких условиях наши ребята молодцы, что смогли выпустить вполне себе крутые продукты и их умудряются сопровождать, добавлять поддержку наших процов и оборудования. Жаль конечно, что не взяли minix за основу с микроядром или не продолжают развивать react os, но что поделать...
Объективных причин нет. Стараюсь блокировать возможность наследования по личным предпочтениям. Rust головного мозга))))
Спасибо) Вторая уже на подходе, думаю завтра послезавтра опубликую, очень мотивируют такие вопросы)
Смотрите, есть сервисы и репозитории домена, которые напрямую работают с сущностями и объектами домена, а есть сервисы, репозитории уровня приложения (Application). Приведу примеры:
Сервис поиска объектов по картинке: получает данные из сущности VideoFrame (доменный объект) -> ищет объекты на картинке в своей реализации -> возвращает список распознанных объектов (тоже доменный уровень)
Сервис рисования рамок на картинках. Тут уже нет ответственности домена, сам сервис никак домен не меняет и он даже не нужен для его работы.
С последним согласен полностью, это впоследствии очень упрощает жизнь, но в таком случае необходимо определять Bounded Context, работать через аггрегаты и вводить событийную модель. Но это очень сложно пока в рамках данного гайда.
Видимо стоило добавить "без негатива". Странно, что так люди агрятся, хотя вполне у автора исходного комментария и моего ответа положительный контекст)
Если мы говорим про Read запросы, то ни к какому. Лучше и правильней создавать отдельные Query обработчики (Application) для сложных запросов, которые на вход получают DTO, и на выход сразу отдают DTO. Репозиторий нужен для того, чтобы извлечь из хранилища целостную сущность, произвести над ней какие-то операции и сохранить.
В будущем я планирую использовать Yolo и еще одну простую нейронку для дообработки (как раз здесь и будет фабрика нужна для сборки объекта). Скорость обработки там примерно 400мкс на каждый кадр. Если мы будем собирать кадры в сущность при каждом HTTP GET запросе, то каждый такой запрос будет супер медленно обрабатываться, а все преимущества того же Timescale улетучатся. С другой стороны, процесс самой обработки видео уже будет более сложным и он будет охватывать изменение нескольких сущностей, где важно собрать целостный объект, но там уже будут более простые запросы к БД.
Вообще очень интересный вопрос, которым я тоже задавался, но почему-то его не осветил(( Притом вопрос "А на фига все это?" сразу же всплывает на каком-нибудь TODO или интернет-магазине, ведь там и предлагают чаще всего использовать для Read моделей репозитории. Жаль, что этот момент прошляпил... Сделаю работу над ошибками прям здесь или в следующей статье. Большое спасибо.
Тупая привычка со времен старых версий питона. Но, спасибо за замечания, внесу в ближайшее время корректировки.
Время жизни фабрики может быть больше самого Usecase на уровне Application, а также могут понадобится параметры, которые непосредственно не участвуют в создании сущности или которые меняют логику создания исходя из конфигурации приложения (например мы потом поймем, что необходимо будет перевести фабрику в абстрактный класс, а уже считывание конфигураций реализовать на уровне Infra).
Я с вами полностью согласен, можно обойтись функцией в 100% случаев, а если уж прям захочется расширить сценарий, то у нас на этот случай есть прекрасные декораторы. Но статья для новичков и я подумал, что возможно материал будет перегружен таким образом. В целом раз есть замечание и оно безусловно крутое, стоило бы раскрыть мысль более подробно или вообще опустить их написание, пока не придем к слою Application.
Спасибо)
Вам спасибо, что дали вдохновения стартануть)
Читаешь заголовок и дисклеймер, превкушаешь: ddd, clear, onion с примерами на fastapi
По тексту: раздел bigger application из официальной документации + парочка приемов и объяснений из других разделов доки.
Для новичков лучше уж эти разделы доки на русский нормально перевести. Те же блоггеры на ютубе пусть и с примерами "todo" лучше данные темы освещают.
Согласен, с вашим замечением, здесь я не совсем точно выразался. В качестве результата выступает не число с рандомайзера, а бинарь, который скомпилировался и будет работать прогнозируемо на любой платформе (проще говоря не падать из-за внутренних приколов ОС).
Turbo Pascal / Delphi / Free Pascal (может в современных версиях не так, я за ним вообще не слежу) использует свою собственную функцию генерации seed от времени. Когда используется такой подход, то проблем с переносимостью нет. Rust - это позволить себе не может, так как он позиционирует себя этаким образцом безопасности, а такой подход может открыть массу уязвимостей, если дело касается чувствительных систем. В другой ветке я писал:
Я вам больше скажу, у него из коробки есть свой рандомайзер, ведь нужно же как-то делать hashmap, просто его API скрыто, чисто из-за принципов и политик Rust.
Да он вообще глыба, уверен, что если бы он вышел хотя бы в начале 10-х (когда начался тренд на типизацию динамических языков), то Rust бы никто не создавал. Язык опередивший свое время...
Где конкретно я сказал, что mt19937 использует /dev/random для реализации алгоритма? Я специально перепрочитал всю ветку, нигде такого не написано! Во втором шаге (предыдущий коммент) нет ни одной ссылки, на то что на вход алгоритма обязательно необходимо передавать имеено такой сид из /dev/random. Ни где не указано, что в mt19937 конкретно есть проблема с многопоточностью, я указывал только на проблемы с криптостойкостью, о чем свидетельствуют множество статей в области кибербеза.
Специально для вас цитирую себя:
Нигде не написано, что это круто и всем нужно так делать.
Еще раз повторяю: есть проблема на ПЕРВОМ шаге (это цифра 1) алгоритма, а именно получение данных источника сида. Не буду повторятся, проблемы я уже описал выше (почитайте, пожалуйста и попробуйте это в голове сохранить).
Ко второму шагу у меня вопросов нет, я его лишь УПОМЯНУЛ в рамках вопроса о криптостойкости, отметив проблему (вполне нейтрально) плюсов в этом вопросе (в контексте обсуждаемого вопроса): "почему C++ смог, а rust нет".
А сейчас давайте вернемся к моим первоначальным тезисам:
1) в Rust главная фича - это безопасть.
2) в std должны попадать только те вещи, которые повторяемы на любой платформе.
3) C++ вешает ответственность на самого программиста, Rust - такое не позволяет.
4) я не даю нравственных оценок, хороши ли перечисленные политики или плохи. Более того я указываю на проблемы в этих политиках на примере ассинхронщины.
Теперь давайте рассуждать в рамках ЭТИХ тезисов, почему rand (де-факто стандарт генерации случайных чисел в Rust) не попал в std:
1) Есть платформозависимая часть, которая будет работать неопределенно в мультипотоке. Плюс могут быть проблемы с переносимостью и поддержкой на разных ОС (компилятор должен собрать из всех native компонентов рабочий код, за исключением платформ где явно не указана дирректива #[no_std]).
2) Можно ли реализовать в стандартной либе только алгоритмы, выкинув формирование сида. Да можно, но это может привести к неопределенному поведению, если программист все же решит юзать системные вызовы.
3) Нельзя допустить, чтобы какие-то не криптостойкие штуки попали в std, потому что может найтись уникум их использующий, там где нельзя (криптография). А как мы знаем, сегодня один ChaCha12 (используется в библиотеке rand) классный и хороший, а завтра опубликуют серию разгромных статей на этот счет. Плюс тот же mt19937 быстрее, насколько я знаю, поэтому для статистических расчетов предпочтительней использовать его, зачем ограничивать программиста только ChaCha12? Поэтому если программист хочет использовать конкретный алгоритм, то пусть юзает сторонние либы, разбирается в них, это уже проблемы не Rust, а пользователя.
Понимаете, когда я веду дисскуссию об определенных вещах, то стараюсь сохранить контекст, того что мне писали или я писал. Но когда приходится цитировать самого себя же - это несколько грубо по отношению ко мне. Также, хочу отметить, если вы хотите узнать мнение человека, то спросите, не надо додумывать за него, если все же хотите додумать, то вам к психологу.
В заключении отвечу на последний ваш тезис:
Я не оправдываю Rust, я с ним живу, до этого более 10 лет писал на плюсах, поэтому привык сам решать, что безопасно, а что нет. Но в тоже понимаю Rust Foundation, если они будут такое тащить в std, то рано или поздно вылезут имбецилы из другого лагеря, которые будут орать: а где ваша безопасность (я не только сейчас про криптостойкость алгоритмов, но и про безопасную работу с ОС), вот тут такие возможности натворить фигню. Если честно, меня это шликанье на безопасность вообще бесит, особенно со стороны комьюнити (кто проходил собесы на Rust, то поймет). Я выбирал Rust по другим причинам.
P.S. А ведь если уметь поддерживать беседу более, чем в одно сообщение, не вырывать из контекста, и не заниматься демагогией, то можно было бы упрекнуть меня за реальные и интересные противоречия: как тогда живет hashmap? Почему нельзя сделать публичным randomizer внутри std, который используется в коллекциях? работа с ФС и файлами реализована, а вот с этим нет, почему? Вот это действительно странно!
Я думал у меня получится в одном сообщении, активировать ваш механизм внимания и вы сможете хоть чуть чуть сохранить контекст. Но к сожалению, я был слишком наивен и лучшего мнения о собеседнике.
К сожалению, я не могу вместить ответ в одно предложение, чтобы вы не запутались. Поэтому предлагаю на этом остановится. Вы правы, а я не прав, как хотите, мне уже надоело.
К чему вопрос? К криптостойкости?
Я конкретно говорю про mt19937, там еще дисклеймер в оригинале добавил.
Если про источник энтропии, то описал в ветке ниже, как это происходит.
P.s. мне уже лень цитировать самого себя.
если он у вас внезапно появился, то у вас проблема явно есть проблемы с хранение контекста. Ну да ладно, сделаем скидку и попробую еще раз объяснить в одном сообщении:
Алгоритм в c++/random и в rust/rand (не std)
1) в качестве источника энтропии платформозависимый источник (процессор - это не платформа, на будущее). В linux это /dev/random или getrandom(), windows - CryptGenRandom, wasm window.crypto.getRandomValues()
2) создаётся chacha12, в плюсах std::mt19937. Дальше генерация чисел.
Rust из коробки не готов брать на себя ответственность за поведение этих типов в мультипотоке. В плюсах это ответственность на программисте.
Вы контекст не храните, когда ведёте дискуссию, я буквально описал проблему.
Буквально, мой тезис написанный ДВА раза: в rust другая идеология попадания в функций в стандартную библиотеку. Перед этим, объясняю почему rand не попал в стандартную либу. В первом комментарии еще подчёркиваю проблему этого подхода на примере ассинхронщины.
Вы:
Какой-то Милонов-style получается.
Я сказал где-то, что так делать обязательно? Без проблем, считайте как хотите, rust - на уровне концепта, не даёт это сделать "из коробки", чтобы какой-нибудь программист не взял эту функцию из коробки в основу своего криптоалгоритма. Если он может так сделать, то rust потеряет свою главную фичу- безопасность. Когда программист использует сторонние либы для таких целей, то ответственность с языка снимается.
Вы как представляете это: есть список алгоритмов, а ты дальше к ним пишешь свой источник энтропии? На хера эти функции тогда тащить в std, если можно вынести в отдельную либу? где ты все это получаешь СРАЗУ?
Если вы понятия не имеете, то может просто загуглите исследования по этому поводу, притом исходное название алгоритма у вас есть. Я лично не хочу заниматься просвящением и копированием ссылок на статьи по этой теме, потому что ощущение, что я "играю с голубем в шахматы"
Исходный коммент про работу "из коробки" - значит средства языка + стандартная библиотека.
Первую часть вопроса не понял.
Давно у нас понятие платформа стало эквивалентно процессору?
В плюсах <random> использует такой же алгоритм, берется источник энтропии, который дёргает системный вызов ОС. Если в ос не удалось его найти, то вызов по сути фиктивный, что влечёт проблемы с безопасностью. Вроде еще там только поддерживается не особо криптостойкий алгоритм prng, но не берусь утверждать точно, может можно другие юзать. Ещё в плюсах ты сам решаешь как бороться с неопределнным поведение в мультипотоке, когда дергаешь эти вызовы. Rust такое на уровне концепта запрещает.
В расте не было проблем это реализовать в стандартной либе, просто идеология там другая по включению в нее, вот и все.
Генерация случайных чисел - это платформозависимая история, std в rust должен гарантировать одинаковый результат выполнения операций на любой платформе. Плюс это будет проблемы с многопоточностью, у того же /dev/random случаются зависания при недостатке энтропии. Ну и последнее в 1987 году не так парились насчёт безопасности и криптостойкости, поэтому в тех же делфях был (вроде) рандом от времени, что потенциально несёт риски для всех криптографических алгоритмов.
Резюмируя, в std должно попадать все, что работает прогнозируемо на любой платформе, остальное - идите в библиотеки. Поэтому, в том числе, такой цирк творится в ассинхронщине
У вас аргументация строится на уровне: ну хватит хейтить, ну это же первые попытки, вон, смотрите, есть даже что-то прикольное.
Целевая аудитория наших дистров - это не айтишники сидящие в уютных опенспейсах и попивающие кофе на кокосовом молоке. А ребята, которым надо разработать (иногда на месте) и накатить кучу специализированного софта + плюс офисные пакеты, где-нибудь на Ямале, и единственный след интернета, что у тебя есть, это флешка с архивами, которые ты скачал, чиля в гостинице во время пересадки в Иркутске. В том числе из-за этой проблемы, госуха так тяжело переходит на наши дистры и любит майкрософт - скачал драйвер пак/кучу программ на жёсткий и спокойно ездишь везде. Попробуй ту же убунту накатить, поставить кучу софта без инета - охренеешь. Ещё не забываем, что существуют режимные объекты, где флешку трудно пронести, а ПО ставится чуть ли не на дискетах.
И вот здесь современные дистры в последние годы большие молодцы. Вот тебе локальная репа раскатанная хоть на болванках, вот тебе средства упаковки и т.д. многие хейтят онлайн поддержку, но чаще всего требуется поддержка именно по телефону, притом иногда приходится подниматся на какую-нибудь гору или высокое дерево, чтобы позвонить. Посмотрим как знатоки английского бы общались с тех поддержкой canonical в таких условиях... кстати, поддержкой там выступают специалисты, а не девочка зачитывающая стандартные скрипты, типа "пробовали перезагрузить?".
Ещё забыл упомянуть очень старое железо, много где ещё стоит windows 2000 и на этого динозавра надо что-то поставить.
Напоследок остановлюсь ещё на одном моменте, разработка для любой госухи, хоть зарубежной, хоть нашей - это огромная бюррократическая работа, написание тонны документации и получение кучи справок. Итог: пилят продукт два с половиной проггера, а сопровождают документально пару сотен человек. Да, обидно, что так, но в нашей стране ещё не так все плохо как в некоторых более развитых странах.
В таких условиях наши ребята молодцы, что смогли выпустить вполне себе крутые продукты и их умудряются сопровождать, добавлять поддержку наших процов и оборудования. Жаль конечно, что не взяли minix за основу с микроядром или не продолжают развивать react os, но что поделать...