У них основной источник энтропии именно такие микросхемы, лампы были сделаны как источник хайпа и работали только как доп. источник энтропии.
Они не дураки, а гораздо умнее некоторых, тк именно они подняли этот хайп первыми (пофиг что снимать - ламп или рыб), не пытались использовать это в серьёзных целях и не изобретали велосипед, чтобы с высоко поднятой головой потом рассказывать какие "трудности" превозмогали.
Им нужен был инфоповод - они его создали, обыграли, наглядно показав, что заботятся о безопасных данных. Все.
P. S. в оригинальной статье есть прямо абзац, где рассказывается, что теоретически на такую генерацию злоумышленник теоретически может првлиять, но мол не бойтись - это всего лишь один из дополнительных источников энтропии.
Типичный Яндекс - все переусложнено, обязательно свой велосипед (а автоматических кормушек, уже отлаженных на thingiverse и им подобных очень много) и обязательно котики (роль которых здесь исполнили рыбки).
При этом микросхемы гсч QRNG / TRNG (оптический/электронный шум) полно на рынке и они именно для этого.
А можно странный вопрос от вообще не посвещенного? )
А поставить вдоль всего цеха шнэк или актуаторы (бульдозер наоброт - те борт, который умеет прижиматься к противоположному борту), чтобы корм подгребало - не дешевле и проще будет?
По МТС - "Запрет массовых автоматизированных вызовов" - это вообще о другом. Надо идти к ним в офис и писать заяву об отказе использования номера. Во всяком случае мне именно так сказали в их киоске.
Кто-нибудь делал такое? Может есть форма заявления или както онлайн можно это сделать?
А всего-то нужно было утвердить тело для GET ну и DELETE заодно, которое, внезапно, из RFC и не было никогда запрещено.
Ещё один пример, того, что люди, которые все это придумывают и сидят в различных коммитетах далеки как от программирования, так и от элементарного здравого смысла.
А потом нам с вами с этим мучиться.
P. S. очень смешно читать, что вот дескать POST меняет данные, а GET нет - это всего лишь соглашение, которое ещё и нарушается довольно часто в сложных проектах, а сделать можно как угодно.
А почему в stm32 вдруг стало нельзя по тактам программировать?
Если вы про HAL, то вроде никто не заставляет его использовать.
У меня есть проект на stm32 (не такой как в статье, но все же) в котором именно по тактам один кусок работает без каких-либо проблем, да, во внимание нужно больше принимать, так как проц куда навороченней, но это не проблема.
А что, ШИМа у него тоже нет? ))) Если есть - то это и есть DAC. А ШИМ можно еще и через DMA делать, а можно и вообще прерыванием и битбангом, если нет аппартаного.
Недоумеваю - я (и куча других людей) делали воспроизведление WAV ATTINY85, которая 8-битная с 16MHz, и да, она одновременно еще и успевала читать это с SD, а не просто играть, при этом вполне себе на 44kHz.
А тут 32-битный проц с частотой космолета - и для него использовали отдельную микруху....
Атмосфера реально классная, но игра размазана на огромное пространство плюс очень очень много механик.
Тот же Фаллаут в разы собранней, те плотность событий такая же, но территория меньше и гораздо плотнее, при этом механики куда более чёткие - так как их меньше и они гораздо понятней очерчены.
А почему не поставить дальномер под углом, чтобы луч проходил через точку около раковины и точку выше унитаза. расстояние меньше, чем без человека - кто-то есть. Да, ему все равно, если загородить это коробкой, например, но врядли кто-то так ведь делать будет?
Хуже $mol может быть только само-переведенный $mol)
Причём ещё и прогнанный через LLM, получивший за это кучу эмодзи и абсолютно бесполезный для читателя, ибо все это уже кучу раз опсосано со всех сторон.
Не выдержал Дмитрий, тоже ушёл в нейрослоп.
P. S. Надменный слог автора в купе с абсолютно надуманными примерами даже LLM не смогла погасить)
Под рефлектами я имел ввиду отражение кого-либо экземпляра класса (его данных) в/из БД.
Да, сейчас стало понятней, что имелось ввиду, благодарю. Т.е. получается этакий линтер по типам и самим параметрам + возможность отслеживать, не нраушится ли флоу вследствии изменений структуры БД? Вот это инетресно, да.
Вопрос немного из другого разреза разработки - а зачем вообще пытаться что-то рефлектить "из SQL", или "из языка"?
В чем проблема использовать БД как фронт использует бэк, делая запросы к хранимкам (если уж там есть сложная логика)? В таком случае при миграциях приложение вообще трогать не нужно будет, если старый вид данных, конечно, можно как-то получить. Достаточно изменить хранимку в БД - т.е. при bзменении БД вы остаетесь в парадигме лишь этой БД.
Что касается тестов - естественно, они внешние должны быть, тут ничего не сделать, но эндпоинты на хранимках избавляют от необходимости переделывать те тесты, которые уже были для них написаны, и нужно просто написать тесты только для нового или изменившегося функционала.
Вообще, использовать рефлекты при работы с БД - это очень заманчивая, но очень порочная практика, как и ORM, ИМХО. Это ускоряет старт, но жутко мешает потом в жизненном цикле. Обычные запросы и более понятны (не надо гадать, во что они там трансформируются промежуточным слоем) и легче могут быть оптимизированы или вообще заменены. Единственная проблема - смена БД. Но это крайне редкая проблема, можно сделать миграцию и ручками раз в 10 лет.
А кто будет усиленно следить за теми кто усиленно следит за теми кто следит за администраторами?! /s
У них основной источник энтропии именно такие микросхемы, лампы были сделаны как источник хайпа и работали только как доп. источник энтропии.
Они не дураки, а гораздо умнее некоторых, тк именно они подняли этот хайп первыми (пофиг что снимать - ламп или рыб), не пытались использовать это в серьёзных целях и не изобретали велосипед, чтобы с высоко поднятой головой потом рассказывать какие "трудности" превозмогали.
Им нужен был инфоповод - они его создали, обыграли, наглядно показав, что заботятся о безопасных данных. Все.
P. S. в оригинальной статье есть прямо абзац, где рассказывается, что теоретически на такую генерацию злоумышленник теоретически может првлиять, но мол не бойтись - это всего лишь один из дополнительных источников энтропии.
Ну в таком случае интересная и простая для понимания информация: "Вода мокрая!!!")))
Весь посыл статьи "Чтобы данные не утекали - разверните ИИ на своей инфраструктуре или локально".
Ну надо же, как неожиданно, свежо и радикально!
Сейчас виртуалки дешёвы - я все, чему не доверяю, запускаю в них.
Дел на 5 минут, виртуалок бесплатных - море, как минимум одна из них идёт в комплекте с виндой.
Очень полезная штука с помощью которой можно изолировать все, что только можно от хоста.
Возможно и автору стоит сделать стандартный образ в таком виде для распространения.
Типичный Яндекс - все переусложнено, обязательно свой велосипед (а автоматических кормушек, уже отлаженных на thingiverse и им подобных очень много) и обязательно котики (роль которых здесь исполнили рыбки).
При этом микросхемы гсч QRNG / TRNG (оптический/электронный шум) полно на рынке и они именно для этого.
А можно странный вопрос от вообще не посвещенного? )
А поставить вдоль всего цеха шнэк или актуаторы (бульдозер наоброт - те борт, который умеет прижиматься к противоположному борту), чтобы корм подгребало - не дешевле и проще будет?
По МТС - "Запрет массовых автоматизированных вызовов" - это вообще о другом. Надо идти к ним в офис и писать заяву об отказе использования номера. Во всяком случае мне именно так сказали в их киоске.
Кто-нибудь делал такое? Может есть форма заявления или както онлайн можно это сделать?
Очень наивно полагать, что с выходом нового метода, все кто его реализуют - сразу реализуют все правильно и по стандарту)))
А спустя год уже будет куча легаси, в котором все будет реализовано по новому и не менее криво.
Именно поэтому не надо плодить новые сущностии сверх необходимости, в надежде что "вот с ними то все сразу будет по другому"!
Если "придерживаться RFC", то что мешает реализовать и стандартизировать это для GET с телом?
Стандарт должен быть максимально логичным, лаконичным и удобным, а иначе котёл в аду будет разработчикам данного стандарта.
Здесь абсолютно бесполезный новый метод, суть которого отлично реализуема без его введения.
Стандарт всегда лучше хаоса, но не тогда, когда сам стандарт это хаос.
А всего-то нужно было утвердить тело для GET ну и DELETE заодно, которое, внезапно, из RFC и не было никогда запрещено.
Ещё один пример, того, что люди, которые все это придумывают и сидят в различных коммитетах далеки как от программирования, так и от элементарного здравого смысла.
А потом нам с вами с этим мучиться.
P. S. очень смешно читать, что вот дескать POST меняет данные, а GET нет - это всего лишь соглашение, которое ещё и нарушается довольно часто в сложных проектах, а сделать можно как угодно.
А почему в stm32 вдруг стало нельзя по тактам программировать?
Если вы про HAL, то вроде никто не заставляет его использовать.
У меня есть проект на stm32 (не такой как в статье, но все же) в котором именно по тактам один кусок работает без каких-либо проблем, да, во внимание нужно больше принимать, так как проц куда навороченней, но это не проблема.
Дак при такой системной частоте разве это не получится? 44kHz было лишь примером что может слабый проц.
А что, ШИМа у него тоже нет? ))) Если есть - то это и есть DAC. А ШИМ можно еще и через DMA делать, а можно и вообще прерыванием и битбангом, если нет аппартаного.
Недоумеваю - я (и куча других людей) делали воспроизведление WAV ATTINY85, которая 8-битная с 16MHz, и да, она одновременно еще и успевала читать это с SD, а не просто играть, при этом вполне себе на 44kHz.
А тут 32-битный проц с частотой космолета - и для него использовали отдельную микруху....
Не смог допройти, хотя брался несколько раз.
Атмосфера реально классная, но игра размазана на огромное пространство плюс очень очень много механик.
Тот же Фаллаут в разы собранней, те плотность событий такая же, но территория меньше и гораздо плотнее, при этом механики куда более чёткие - так как их меньше и они гораздо понятней очерчены.
А почему не поставить дальномер под углом, чтобы луч проходил через точку около раковины и точку выше унитаза. расстояние меньше, чем без человека - кто-то есть. Да, ему все равно, если загородить это коробкой, например, но врядли кто-то так ведь делать будет?
Хуже $mol может быть только само-переведенный $mol)
Причём ещё и прогнанный через LLM, получивший за это кучу эмодзи и абсолютно бесполезный для читателя, ибо все это уже кучу раз опсосано со всех сторон.
Не выдержал Дмитрий, тоже ушёл в нейрослоп.
P. S. Надменный слог автора в купе с абсолютно надуманными примерами даже LLM не смогла погасить)
Под рефлектами я имел ввиду отражение кого-либо экземпляра класса (его данных) в/из БД.
Да, сейчас стало понятней, что имелось ввиду, благодарю. Т.е. получается этакий линтер по типам и самим параметрам + возможность отслеживать, не нраушится ли флоу вследствии изменений структуры БД? Вот это инетресно, да.
Вопрос немного из другого разреза разработки - а зачем вообще пытаться что-то рефлектить "из SQL", или "из языка"?
В чем проблема использовать БД как фронт использует бэк, делая запросы к хранимкам (если уж там есть сложная логика)? В таком случае при миграциях приложение вообще трогать не нужно будет, если старый вид данных, конечно, можно как-то получить. Достаточно изменить хранимку в БД - т.е. при bзменении БД вы остаетесь в парадигме лишь этой БД.
Что касается тестов - естественно, они внешние должны быть, тут ничего не сделать, но эндпоинты на хранимках избавляют от необходимости переделывать те тесты, которые уже были для них написаны, и нужно просто написать тесты только для нового или изменившегося функционала.
Вообще, использовать рефлекты при работы с БД - это очень заманчивая, но очень порочная практика, как и ORM, ИМХО. Это ускоряет старт, но жутко мешает потом в жизненном цикле. Обычные запросы и более понятны (не надо гадать, во что они там трансформируются промежуточным слоем) и легче могут быть оптимизированы или вообще заменены. Единственная проблема - смена БД. Но это крайне редкая проблема, можно сделать миграцию и ручками раз в 10 лет.
Ну, либо я не понял сути вопроса.