NumPy сам понял, что умножить на указанное число нужно каждый элемент массива! Такая концепция называется транслированием, и она чрезвычайно удобна.
Не следует безоговорочно полагаться на автоматический перевод. Слово было переведено таким образом только из-за невосприимчивости автопереводчика к контексту. К сожалению, повальная безграмотность авторов курсов по вкатыванию (я не вас лично имею в виду, а указываю на общий тренд) приводит к загрязнению русского языка некорректной терминологией. С этим нужно бороться, и часть ответственности лежит на вас лично, поскольку вы на эту тему пишете.
Корректный термин здесь --- "укладывание" (см. "Python и анализ данных", перевод ДМК Пресс)
Пользуюсь REPL питона (ещё можно ptpython, он с подсветкой), брат жив, зависимость есть. На ведроиде Calculator++, как выше уже советовали, но пользуюсь редко.
Правильнее будет автоматически <...>, а не городить пользователю перепоны.
В мире и так уже полно сверх меры умных интерфейсов, создатели которых считают, что лучше пользователя знают, что пользователю нужно. В некоторых отраслях, несомненно, так и есть, но зачем каждый второй сайт и сервис в гулаг превращать? Почему погоня за улучшением UX должна оканчиваться удалением ценной функциональности? Почему в современном UX дизайне считается нормальным, когда сообщение об ошибке не содержит никакой информации о её причинах, делая её самостоятельную диагностику и устранение невозможной? Доколе...
Мы можем достаточно эффективно бороться с сайд ченнелом. В случае использования CPU — догружать ядра до 100%, увеличивая зашумленность канала передачи.
Не можем :3 У вас есть множество исполняемых процессов, каждому достаётся немного процессорного времени. Если вы добавляете в него процесс, оставшимся достанется немного меньше времени. Если убираете, то немного больше. Абсолютное значение времени не влияет на передачу (оно удаляется фильтром высоких частот), имеет значение лишь высокочастотная составляющая, которую вы подавить не сможете. Это всё равно что пытаться подавить ВЧ сигнал в проводе, добавив в него постоянный ток.
Основная проблема M1RACLES для меня в том, что этот канал сложно замониторить. И получается, что мы утечку данных не увидим )
Вы и утечку через модуляцию процессора не увидите, если не знаете кодирующей последовательности. Отличие M1RACLES только в его высокой эффективности в сравнении с побочными каналами.
В целом условия нормальные, есть пара вопросов 1 бит в минуту это конечно точно не успех, т.к. реальной угрозы не представляет.
O RLY? Хватит чтобы вытащить пароли и куки. Можно и это продемонстрировать.
Ну и дальше по ресурсам, если для достижения таких параметров нужно загрузить цпу на 100% или памяти сожрать десяток гигов, то ни о какой скрытности речи не идёт.
О скрытности речи в принципе не идёт. Атака по побочным каналам даже через описанный в статье регистр легко мониторится тривиальными инструментами. У меня плазма регулярно нагружает одно ядро на 100%; я не знаю, что она делает в это время, мне без разницы. Вариации потребления системных ресурсов сложными программами вопросы вызывают редко.
Ох, это был риторический вопрос, потому что принцип давно известен. Вот, например, критический обзор методов атак через кэш: https://arxiv.org/pdf/1606.01356.pdf. Но если вы настаиваете, то давайте сделаем, и напишем об этом статью на хабре с дисклеймером как в верхнем комментарии этой ветки.
какие параметры будем считать зачетными, минимальная скорость/вероятность передачи данных, максимальные ресурсы которые разрешенно использовать, какие условия испытаний/противодействия системы, сколько максимум усилий на реализацию?
Я предлагаю следующую постановку задачи: есть VM на VirtualBox; хост и гость — AMD64 машины, исполняющие современные дистрибутивы GNU/Linux без специальной преднастройки (скажем, Manjaro или что-либо Ubuntu-based в дефолтной конфигурации после установки). Хост исполняет VM и процесс-приёмник; гость, соответственно, исполняет наш процесс-передатчик. Задачу будем считать выполненной, если мы сумеем достичь скорости передачи не менее 1 бит в минуту при BER < 50% (думаю, добиться результата лучше усилий не составит, но это мы всегда успеем). Ограничения на усилия обусловлены нашей готовностью возиться с этим.
Если стартовые условия вас устраивают, я готов поделиться соображениями по практической стороне вопроса.
Тем не менее уязвимостью данная штука быть не перестает.
Согласно определению с Википедии, эта особенность не является уязвимостью, поскольку не предоставляет атакующему возможностей для реализации новых векторов атаки. Возможность скрытого обмена данными между процессами, исполняемыми на одной машине, будет существовать всегда, покуда есть разделяемые ресурсы. SergeyMax приводит выше совершенно корректный пример с загрузкой процессора или любого другого ресурса, подобающая модуляция которого позволит вам вытащить данные хоть из виртуальной машины. Хотите, сделаем PoC и раздуем из этого ещё одну бесполезную сенсацию?
Как подходить к разработке низкоуровневых приложений, не оставляя после себя тысячи строк непонятного и неподдерживаемого кода?
Рекомендуете ли вы глубже изучать паттерны архитектуры? Стремиться к «чистому коду»? Или же уйти на пару годиков в веб, поучиться у матерых сеньоров и вернуться с полученными знаниями во встройку?
Вы, главное, не переключайтесь, и до такого поста руки рано или поздно дойдут. А если серьёзно, выше уже совершенно корректно писали, что методы проектирования софта везде плюс-минус одни, эмбеды это или нет решающего значения не имеет, теория везде одна. Практику можно получить контрибьютингом в опенсорс, заодно получите и трезвую критику своих навыков, а может даже и ценный совет.
Ваш пример с UAVCAN, как и его документация, отлично вписываются в общую концепцию CAN-шины и схожих систем, где протоколл основывается на содержании сообщения (топика), и фреймворк издатель-подписчик показывает себя во всей красе. Однако та же архитектура вряд ли подойдет для систем наподобие LIN-шины, где сообщения напрямую содержат информацию о подписчике и элегантно оформить подписку на топик уже не получится.
Вообще UAVCAN работает поверх UDP тоже, например (через мультикаст группы). Это не только про CAN.
Одно другого не исключает. Заходите на стенд NXP какой-нибудь робототехнической выставки, они вам, наверное, с удовольствием расскажут про UAVCAN (за корректность не ручаюсь). Идею насчёт рекламы через Компэл всенепременно им подкину, нельзя без Компэл.
Берите любую ноду для v0, они аппаратно совместимы с v1. Ещё есть демоплаты для UAVCAN от NXP, но их пока нельзя купить за пределами США из-за экспортных ограничений, установленных администрацией Трампа.
Вы либо дилетант, либо космически толстый тролль. Как можно пытаться оценить сложность реализации системы, не зная о ней абсолютно ничего кроме того, что она как-то связана с векторным управлением?
Я смотрю на ваши комментарии в профиле и недоумеваю, вы с двача сюда пришли что ли? Здесь собираются более-менее адекватные люди в основном, обратите внимание.
Ну ладно тогда. Зачем писать грамотно? Мы же не на экзамене.
Не следует безоговорочно полагаться на автоматический перевод. Слово было переведено таким образом только из-за невосприимчивости автопереводчика к контексту. К сожалению, повальная безграмотность авторов курсов по вкатыванию (я не вас лично имею в виду, а указываю на общий тренд) приводит к загрязнению русского языка некорректной терминологией. С этим нужно бороться, и часть ответственности лежит на вас лично, поскольку вы на эту тему пишете.
Корректный термин здесь --- "укладывание" (см. "Python и анализ данных", перевод ДМК Пресс)
Ахаха гугл-транслейт пробивает новое дно. Всё ради контента
Где вложиться?
У вас очень противоречивый юзернейм.
Пользуюсь REPL питона (ещё можно ptpython, он с подсветкой), брат жив, зависимость есть. На ведроиде Calculator++, как выше уже советовали, но пользуюсь редко.
В мире и так уже полно сверх меры умных интерфейсов, создатели которых считают, что лучше пользователя знают, что пользователю нужно. В некоторых отраслях, несомненно, так и есть, но зачем каждый второй сайт и сервис в гулаг превращать? Почему погоня за улучшением UX должна оканчиваться удалением ценной функциональности? Почему в современном UX дизайне считается нормальным, когда сообщение об ошибке не содержит никакой информации о её причинах, делая её самостоятельную диагностику и устранение невозможной? Доколе...
Ого. Где почитать?
Мне обычно приходят на ум очереди на досмотр личных вещей в аэропортах.
Не можем :3 У вас есть множество исполняемых процессов, каждому достаётся немного процессорного времени. Если вы добавляете в него процесс, оставшимся достанется немного меньше времени. Если убираете, то немного больше. Абсолютное значение времени не влияет на передачу (оно удаляется фильтром высоких частот), имеет значение лишь высокочастотная составляющая, которую вы подавить не сможете. Это всё равно что пытаться подавить ВЧ сигнал в проводе, добавив в него постоянный ток.
Вы и утечку через модуляцию процессора не увидите, если не знаете кодирующей последовательности. Отличие M1RACLES только в его высокой эффективности в сравнении с побочными каналами.
Давайте продолжим здесь: https://habr.com/ru/post/560508/
O RLY? Хватит чтобы вытащить пароли и куки. Можно и это продемонстрировать.
О скрытности речи в принципе не идёт. Атака по побочным каналам даже через описанный в статье регистр легко мониторится тривиальными инструментами. У меня плазма регулярно нагружает одно ядро на 100%; я не знаю, что она делает в это время, мне без разницы. Вариации потребления системных ресурсов сложными программами вопросы вызывают редко.
Значит, процессы исполняются на разных машинах. В пределах одной машины у вас всегда есть процессор (или несколько), память, и т.п.
Ох, это был риторический вопрос, потому что принцип давно известен. Вот, например, критический обзор методов атак через кэш: https://arxiv.org/pdf/1606.01356.pdf. Но если вы настаиваете, то давайте сделаем, и напишем об этом статью на хабре с дисклеймером как в верхнем комментарии этой ветки.
Я предлагаю следующую постановку задачи: есть VM на VirtualBox; хост и гость — AMD64 машины, исполняющие современные дистрибутивы GNU/Linux без специальной преднастройки (скажем, Manjaro или что-либо Ubuntu-based в дефолтной конфигурации после установки). Хост исполняет VM и процесс-приёмник; гость, соответственно, исполняет наш процесс-передатчик. Задачу будем считать выполненной, если мы сумеем достичь скорости передачи не менее 1 бит в минуту при BER < 50% (думаю, добиться результата лучше усилий не составит, но это мы всегда успеем). Ограничения на усилия обусловлены нашей готовностью возиться с этим.
Если стартовые условия вас устраивают, я готов поделиться соображениями по практической стороне вопроса.
Согласно определению с Википедии, эта особенность не является уязвимостью, поскольку не предоставляет атакующему возможностей для реализации новых векторов атаки. Возможность скрытого обмена данными между процессами, исполняемыми на одной машине, будет существовать всегда, покуда есть разделяемые ресурсы. SergeyMax приводит выше совершенно корректный пример с загрузкой процессора или любого другого ресурса, подобающая модуляция которого позволит вам вытащить данные хоть из виртуальной машины. Хотите, сделаем PoC и раздуем из этого ещё одну бесполезную сенсацию?
Вы, главное, не переключайтесь, и до такого поста руки рано или поздно дойдут. А если серьёзно, выше уже совершенно корректно писали, что методы проектирования софта везде плюс-минус одни, эмбеды это или нет решающего значения не имеет, теория везде одна. Практику можно получить контрибьютингом в опенсорс, заодно получите и трезвую критику своих навыков, а может даже и ценный совет.
Вообще UAVCAN работает поверх UDP тоже, например (через мультикаст группы). Это не только про CAN.
Одно другого не исключает. Заходите на стенд NXP какой-нибудь робототехнической выставки, они вам, наверное, с удовольствием расскажут про UAVCAN (за корректность не ручаюсь). Идею насчёт рекламы через Компэл всенепременно им подкину, нельзя без Компэл.
Берите любую ноду для v0, они аппаратно совместимы с v1. Ещё есть демоплаты для UAVCAN от NXP, но их пока нельзя купить за пределами США из-за экспортных ограничений, установленных администрацией Трампа.
Вы либо дилетант, либо космически толстый тролль. Как можно пытаться оценить сложность реализации системы, не зная о ней абсолютно ничего кроме того, что она как-то связана с векторным управлением?
Я смотрю на ваши комментарии в профиле и недоумеваю, вы с двача сюда пришли что ли? Здесь собираются более-менее адекватные люди в основном, обратите внимание.