"Честно говоря не понимаю эти постоянные кивания на военных, интернет и gps создавались для военных целей как это мешает их использовать в гражданской сфере?"
Абсолютно согласен с автором поста о бессмысленности и бесперспективности использования процессора Эльбрус для гражданской сферы. Подходы к построению систем для военных и граждан принципиально различаются. По факту у нас работает только два пути: изначально разработано для военной сферы, и только ими же и используется; разработано для гражданской сферы, с изменениями и дополнениями используется в военной сфере. Процессоры Intel установлены на множестве военной техники, телескоп Хаббл летает с процессором Intel Pentium 4 на борту. Это конечно же не те процессоры, которые установлены в миллионах домашних ПК, а доработанные с учетом надёжности и защиты для военной сферы. Аргументы про разработку Интернет и GPS не имеют никакого отношения к данной теме, по следующим причинам:
1) Это американская история успеха, и к российским реалиям она не имеет никакого отношения. Подобных примеров для СССР или РФ я не знаю, если Вы знаете, с удовольствием об этом услышу от Вас.
2) Интернет это не товар или даже не услуга, а проект и чертеж. Его никто не производит, его не нужно каким то образом поддерживать.
3) С GPS такая же история, это не товар, а услуга. В вашем смартфоне установлен совсем другой чип, и он принципиально отличается от чипов которые используют военные.
Вам в список можно было добавить разработку атомной бомбы, которая в последствие превратилась в мирный атом в виде атомных электростанций. Но в этом случае и в случае с Интернет и GPS, мы имеем дело с изобретениями от военных, которые легли в основу разработки гражданских систем. Примеров с использованием конечных устройств (разработанных изначально для военных), одновременно для военной и гражданской сферы попросту нет.
Так, где инструкция по созданию локального registry и его настройка? И еще один нескромный вопрос, а вы не рассматриваете вариант с увеличением время жизни сборочных машин?
Моя инструкция не отличается оригинальность, а является переводом статьи с блога docker.com с дополнениями в виде картинок. Запуск образа binfmt можно добавить в автозагрузку. У вас в качестве источника кэша используется - registry. В каком-то смысле для большинства случаев это не имеет смысл. Например, у меня Docker-образ который состоит из трех частей: ОС Alpine, слой с Runtime .NET, и слой с компилированной программой. При первой сборке, Alpine и Runtime загрузятся из реестра. При второй сборке, слой с Alpine и Runtime будет взят уже с локального кэша. Слой с компиляцией программы это постоянно изменяемый слой при каждой сборке. Таким образом, нет никакой необходимости в подобной опции для взятия кэша. Кэш имеет смысл применять при большой вариации запуска одного и того же приложения в различных окружениях. Но на практике это сложно представить, потому что многие компании сейчас пытаются реализовать микросервисную архитектуру и не превращать Docker-контейнер в многофункционального динозавра. Если идет речь про локальный репозиторий образов, то тогда следовало бы дополнить пост инструкцией как его создать. Но если у вас есть рабочий кейс, то тогда хотелось бы его увидеть.
Что-то как то много букв и слишком сложно. У вас по факту идет сборка не под процессор от Apple, а для архитектуры aarch64. Кэширование слоев в Buildx отрабатывает автоматически. На мой взгляд моя инструкция проще и короче. Вы еще не добавили в текст команду для очистки кэша, а то так место быстро закончится при постоянных сборках:
Весь вопрос в сопряжение самого устройства. Как вариант можно взять устройство Tuya или Sonoff, например это. Перепрошить его на ESPHome, и подвязать к Home Assistant.
NameSilo.com. Лишнее не спрашивает, скан паспорта и подтверждение с места работы как это требуют отечественные регистраторы не требуется. Ежегодно не требует подтверждение что ты не превратился в пингвина. Принимает все платежные системы включая Bitcoin. По скидке можно сразу купить на 10 лет. Все мои домены на нем, уже несколько лет. Говорят что еще средне абузоустойчивый, но проверять нет желания. ИМХО, западный регистратор - это отношения, отечественный регистратор - это сношение с тобой.
Готовые решения будут существенно дороже самосборных и обладать один/двумя недостатками. 1) привязка передачи данных к своим облачным сервисам, как это реализуют "умные" розетки, светильники и т.д. 2) свой аппаратно/программный центр сбора данных. ИМХО, самое простое и универсальное решение это взять связку:
18650 Lithium Battery Shield V8
ESP-WROOM-32
температурный датчик BMx
В ESP-WROOM-32 загрузить прошивку ESPHome. Настроить соединение по BLE - BLE Client Sensor. На одноплатный компьютер установить Home Assistant нативно или в варианте Docker контейнера. Для отображения панели управления на экране, запускать браузер как в примере.
А если браузер с web-интерфейсом или почтовый клиент запускать в песочнице и пользователю не работать с правами администратора? Мне так кажется, как специалисту по ИБ, этот ваш сотрудник работал в ОС с правами Администратора. Для корректности, уточните пожалуйста набор привилегий учетной записи этого сотрудника, включая набор привилегий для его любимого почтового клиента через который произошло заражение.
Для этого вообще существует отдельная специальность - промышленный дизайн. Понятно дело, датчик спрятанный в глубине корпуса будет показывать уже температуру внутри корпуса, а не в комнате. Так всегда, напечатать на 3D принтере не проблема, хоть завтра, но вот сделать правильный и красивый корпус, тут необходимо весьма подумать.
Мне следовало сначала написать обобщенный пост, а потом уже техническую реализацию разных модулей. Исправлюсь, напишу что имелось в виду и какова конечная цель. Цель не в создание метеостанции, а в создание демо-проекта проверки технологий, проведение испытаний технологий в малых системах. Если задавать технический заголовок, то он будет очень длинным. Потому что необходимо охватить: Docker, работу с устройством Linux framebuffer, брокер сообщений RabbitMQ и AvaloniaUI. А с Docker проблем нет, он просто работает, и про него нечего писать. Единственный момент, в контейнер передается напрямую устройства /dev/fbX и другие устройства GPIO. Может быть, на этом следовало бы заострить внимание. Потому что подобный подход решает многие проблемы с безопасностью, которые в Windows Embedded решаются еще теми петлями. На Linux все получается более лаконично и просто. Но сравнение с Windows Embedded это уже другая тема.
Можно запускать систему на eMMC. На Banana Pi M64 напаяно 8 Гб, вполне достаточно. eMMC не использовал по двум причинам: 1) лишний раз не тратить ресурсы микросхемы; 2) понизить технические характеристики для явного обнаружения узких мест. На некоторых платах, таких как Cubieboard и Cubietruck размещен разъем SATA. Cubietruck с SATA показывает прирост скорости произвольного доступа по сравнению с microSD на Banana Pi M64 до 50%. Но нужно учитывать, что на Cubietruck установлен достаточно старый SoC. С m.2 продается неплохая плата ROCK PI 4C с поддержкой NVME до 2 Тб.
Прошу меня извинить, если быканул. Как раз таки вы написали "Если вы планируете выпуск (допустим) миллиона устройств". Вы указали на конкретную разработку, но не суть важна. Просто есть компания Toradex и ее успешный бизнес. Я очень много взял материала с их сайта. В своих системах они успешно используют Docker. И тут в комментариях начинается, вопросы про стрельбу из пушки по воробьям. Ребята, нужно понимать что мир на МК не заканчивается. Это не разработка метеостанции, это проверка технологий для использования на подобных малых одноплатных компьютерах, в тех сферах где Arduino/STM32 не будет использоваться в качестве основной системы. Да признаю, это нужно было четко написать в самом начале. Материал по факту это наработка технологий и проверка рабочих гипотез, и все. Я просто видел много систем, где брали плату на STM32 и подключали к ноутбуку. Хотя на самом деле можно было прекрасно обойтись платой в стиле банана с подключенным монитором или LCD с емкостным экраном.
Ключевое слово "Если". Ни кто не планирует продавать метеостанцию на банане. И далее будет распознавание голоса и видео с с Home Assistant. В самом начале написано: "Пример метеостанции является демонстрацией встраиваемого решения работы с GPIO...". Это техническое демо, а не законченная система для продажи. И вывод прочитайте, все же: "Данная реализация проекта была проверкой работоспособности первоначальной идеи работы с GPIO из Docker-контейнеров и вывода полноценного UI на LCD ...". Блин, похоже никто не осилил статью, и до конца не смог дочитать.
"Честно говоря не понимаю эти постоянные кивания на военных, интернет и gps создавались для военных целей как это мешает их использовать в гражданской сфере?"
Абсолютно согласен с автором поста о бессмысленности и бесперспективности использования процессора Эльбрус для гражданской сферы. Подходы к построению систем для военных и граждан принципиально различаются. По факту у нас работает только два пути: изначально разработано для военной сферы, и только ими же и используется; разработано для гражданской сферы, с изменениями и дополнениями используется в военной сфере. Процессоры Intel установлены на множестве военной техники, телескоп Хаббл летает с процессором Intel Pentium 4 на борту. Это конечно же не те процессоры, которые установлены в миллионах домашних ПК, а доработанные с учетом надёжности и защиты для военной сферы. Аргументы про разработку Интернет и GPS не имеют никакого отношения к данной теме, по следующим причинам:
1) Это американская история успеха, и к российским реалиям она не имеет никакого отношения. Подобных примеров для СССР или РФ я не знаю, если Вы знаете, с удовольствием об этом услышу от Вас.
2) Интернет это не товар или даже не услуга, а проект и чертеж. Его никто не производит, его не нужно каким то образом поддерживать.
3) С GPS такая же история, это не товар, а услуга. В вашем смартфоне установлен совсем другой чип, и он принципиально отличается от чипов которые используют военные.
Вам в список можно было добавить разработку атомной бомбы, которая в последствие превратилась в мирный атом в виде атомных электростанций. Но в этом случае и в случае с Интернет и GPS, мы имеем дело с изобретениями от военных, которые легли в основу разработки гражданских систем. Примеров с использованием конечных устройств (разработанных изначально для военных), одновременно для военной и гражданской сферы попросту нет.
Это не интересно. Получается что твоя система будет зависеть от соседей, а это ненадежно. А воздух между прочем там другой, соседский).
Так, где инструкция по созданию локального registry и его настройка? И еще один нескромный вопрос, а вы не рассматриваете вариант с увеличением время жизни сборочных машин?
Моя инструкция не отличается оригинальность, а является переводом статьи с блога docker.com с дополнениями в виде картинок. Запуск образа binfmt можно добавить в автозагрузку. У вас в качестве источника кэша используется - registry. В каком-то смысле для большинства случаев это не имеет смысл. Например, у меня Docker-образ который состоит из трех частей: ОС Alpine, слой с Runtime .NET, и слой с компилированной программой. При первой сборке, Alpine и Runtime загрузятся из реестра. При второй сборке, слой с Alpine и Runtime будет взят уже с локального кэша. Слой с компиляцией программы это постоянно изменяемый слой при каждой сборке. Таким образом, нет никакой необходимости в подобной опции для взятия кэша. Кэш имеет смысл применять при большой вариации запуска одного и того же приложения в различных окружениях. Но на практике это сложно представить, потому что многие компании сейчас пытаются реализовать микросервисную архитектуру и не превращать Docker-контейнер в многофункционального динозавра. Если идет речь про локальный репозиторий образов, то тогда следовало бы дополнить пост инструкцией как его создать. Но если у вас есть рабочий кейс, то тогда хотелось бы его увидеть.
Что-то как то много букв и слишком сложно. У вас по факту идет сборка не под процессор от Apple, а для архитектуры aarch64. Кэширование слоев в Buildx отрабатывает автоматически. На мой взгляд моя инструкция проще и короче. Вы еще не добавили в текст команду для очистки кэша, а то так место быстро закончится при постоянных сборках:
Зачетный проект! Но это будет температура у соседей, а не у тебя.
Весь вопрос в сопряжение самого устройства. Как вариант можно взять устройство Tuya или Sonoff, например это. Перепрошить его на ESPHome, и подвязать к Home Assistant.
Как раз таки верно, давление — 0.01 hPa ( < 10 cm). Температура — 0.01° C. Влажность – 3%.
NameSilo.com. Лишнее не спрашивает, скан паспорта и подтверждение с места работы как это требуют отечественные регистраторы не требуется. Ежегодно не требует подтверждение что ты не превратился в пингвина. Принимает все платежные системы включая Bitcoin. По скидке можно сразу купить на 10 лет. Все мои домены на нем, уже несколько лет. Говорят что еще средне абузоустойчивый, но проверять нет желания. ИМХО, западный регистратор - это отношения, отечественный регистратор - это сношение с тобой.
Готовые решения будут существенно дороже самосборных и обладать один/двумя недостатками. 1) привязка передачи данных к своим облачным сервисам, как это реализуют "умные" розетки, светильники и т.д. 2) свой аппаратно/программный центр сбора данных. ИМХО, самое простое и универсальное решение это взять связку:
18650 Lithium Battery Shield V8
ESP-WROOM-32
температурный датчик BMx
В ESP-WROOM-32 загрузить прошивку ESPHome. Настроить соединение по BLE - BLE Client Sensor. На одноплатный компьютер установить Home Assistant нативно или в варианте Docker контейнера. Для отображения панели управления на экране, запускать браузер как в примере.
Потому что точность датчика позволяет. Сотые доли по ощущениям определить сложно, но изменение температуры с шагом в 0.3 градуса уже чувствуется.
А если браузер с web-интерфейсом или почтовый клиент запускать в песочнице и пользователю не работать с правами администратора? Мне так кажется, как специалисту по ИБ, этот ваш сотрудник работал в ОС с правами Администратора. Для корректности, уточните пожалуйста набор привилегий учетной записи этого сотрудника, включая набор привилегий для его любимого почтового клиента через который произошло заражение.
Для этого вообще существует отдельная специальность - промышленный дизайн. Понятно дело, датчик спрятанный в глубине корпуса будет показывать уже температуру внутри корпуса, а не в комнате. Так всегда, напечатать на 3D принтере не проблема, хоть завтра, но вот сделать правильный и красивый корпус, тут необходимо весьма подумать.
В моем случае нет js и html. Буду смотреть какие есть графические библиотеки для Uno Platform.
Мне следовало сначала написать обобщенный пост, а потом уже техническую реализацию разных модулей. Исправлюсь, напишу что имелось в виду и какова конечная цель. Цель не в создание метеостанции, а в создание демо-проекта проверки технологий, проведение испытаний технологий в малых системах. Если задавать технический заголовок, то он будет очень длинным. Потому что необходимо охватить: Docker, работу с устройством Linux framebuffer, брокер сообщений RabbitMQ и AvaloniaUI. А с Docker проблем нет, он просто работает, и про него нечего писать. Единственный момент, в контейнер передается напрямую устройства /dev/fbX и другие устройства GPIO. Может быть, на этом следовало бы заострить внимание. Потому что подобный подход решает многие проблемы с безопасностью, которые в Windows Embedded решаются еще теми петлями. На Linux все получается более лаконично и просто. Но сравнение с Windows Embedded это уже другая тема.
Прикольный интерфейс, круглый циферблат можно добавить как скин.
Зачем, если есть Armbian и он вполне устраивает?
Можно запускать систему на eMMC. На Banana Pi M64 напаяно 8 Гб, вполне достаточно. eMMC не использовал по двум причинам: 1) лишний раз не тратить ресурсы микросхемы; 2) понизить технические характеристики для явного обнаружения узких мест. На некоторых платах, таких как Cubieboard и Cubietruck размещен разъем SATA. Cubietruck с SATA показывает прирост скорости произвольного доступа по сравнению с microSD на Banana Pi M64 до 50%. Но нужно учитывать, что на Cubietruck установлен достаточно старый SoC. С m.2 продается неплохая плата ROCK PI 4C с поддержкой NVME до 2 Тб.
Прошу меня извинить, если быканул. Как раз таки вы написали "Если вы планируете выпуск (допустим) миллиона устройств". Вы указали на конкретную разработку, но не суть важна. Просто есть компания Toradex и ее успешный бизнес. Я очень много взял материала с их сайта. В своих системах они успешно используют Docker. И тут в комментариях начинается, вопросы про стрельбу из пушки по воробьям. Ребята, нужно понимать что мир на МК не заканчивается. Это не разработка метеостанции, это проверка технологий для использования на подобных малых одноплатных компьютерах, в тех сферах где Arduino/STM32 не будет использоваться в качестве основной системы. Да признаю, это нужно было четко написать в самом начале. Материал по факту это наработка технологий и проверка рабочих гипотез, и все. Я просто видел много систем, где брали плату на STM32 и подключали к ноутбуку. Хотя на самом деле можно было прекрасно обойтись платой в стиле банана с подключенным монитором или LCD с емкостным экраном.
Ключевое слово "Если". Ни кто не планирует продавать метеостанцию на банане. И далее будет распознавание голоса и видео с с Home Assistant. В самом начале написано: "Пример метеостанции является демонстрацией встраиваемого решения работы с GPIO...". Это техническое демо, а не законченная система для продажи. И вывод прочитайте, все же: "Данная реализация проекта была проверкой работоспособности первоначальной идеи работы с GPIO из Docker-контейнеров и вывода полноценного UI на LCD ...". Блин, похоже никто не осилил статью, и до конца не смог дочитать.