Не совсем уверен, что генератор псевдослучайных чисел должен гарантировать одинаковые числа даже на одной платформе
Согласен, с вашим замечением, здесь я не совсем точно выразался. В качестве результата выступает не число с рандомайзера, а бинарь, который скомпилировался и будет работать прогнозируемо на любой платформе (проще говоря не падать из-за внутренних приколов ОС).
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, но что поделать...
Согласен, с вашим замечением, здесь я не совсем точно выразался. В качестве результата выступает не число с рандомайзера, а бинарь, который скомпилировался и будет работать прогнозируемо на любой платформе (проще говоря не падать из-за внутренних приколов ОС).
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, но что поделать...