Версии gcc/ядра/библиотек идут из SoC SDK, и вне зависимости от подхода надо будет их поддерживать в приложении.
У вендоров камер нет технической возможности нормализовать версии gcc/libc.
Скрипт для iptables, который закрывает все порты на вход и выход кроме двух, умещается в 10 строчках.
А софт вендора раз в 30 секунд будет их обратно открывать (да, это пример из реальной жизни) :)
Мы пробовали делать интеграцию на уровне API с несколькими вендорами — уходит очень много времени на отладку взаимодействия, и на тестирование результирующих прошивок. И более того, каждый апдейт со стороны — все старые проблемы вылезают обратно.
По опыту дешевле сделать поддержку в приложении работы напрямую с SoC. При наличии уже готового нашего видео-приложения и системы сборки — добавление поддержки нового SoC, быстрее чем тестирование/интеграция в прошивку вендора.
Захват и трансляция видеопотока это далеко не единственная функция прошивки. Софт отвечает за настройку параметров аудио/видео, за обратный канал аудио, за видео- и аудио- аналитики (детекторы событий — например движения и анормального звука), управление PTZ и т.д. и т.п. Кроме этого. нужно реализовать механизм обновления прошивок.
Подстраиваться под API каждого вендора камер (которых намного больше чем используемыз SoC) никаких ресурсов не хватит. И это не говоря о поддержке и выпуске обновлений.
А еще во многих случаях китайские прошивки содержат дыры/бэкдоры и много ненужного функционала который с одной стороны снижает информационную безопасность, а с другой стороны увеличивает требования к железу.
На мой вкус, когда регулярно нужно работать с проектами живущих в разных средах и разных ЯП — у vscode нет конкуренции.
Это у них получается за счет мощной системы плагинов и очень качественного терминала.
Бесспорно, под каждый ЯП есть более мощные и крутые частные решения типа qt crearor, inteliJ, и тд.
Но если нужно универсальное решение, то vs code — кажется пока лидер, как универсальный редактор кода, с кучей плагинов под нужные ЯП и окружения
Ох, простите, запутался в их схемах и связях…
но что это изменит? Ростех — продает, Роснано — учредитель. Увы, в данном случае для нас не изменится ничего (
Речь об обратном процессе — записи уроков через камеры. Не готов спорить о моральных аспектах видеонаблюдения, но когда доступ к "слежке" и более того, к подделке видеозаписей, получает не ограниченый круг лиц, это ни в какие ворота не лезет...
А вас не смущает, что эти господа получили под это субсидии от государства, а теперь врут заявляя что это Российская разработка.
Вот цитата из новости:
И кто им портит деловую репутацию, если они говорят заведомую неправду, непонятно на что потратив субсидии?
Мы сами не производим камеры, но закупаем камеры производства мировых лидеров, в том числе Hikvision и Dahua, по ценам как раз начинающихся от 1800 рублей за штуку....
Производителю "багрепорт" еще два года назад делали. Об этом написано в статье.
А в смысле при каждом обновлении менять разделы местами — да, так можно. Но в самой прошивке прийдется обрабатывать два разных режима. Чуть менее детерминированно получается. Ну и по размеру в этой схеме есть требование: kernel не должен быть больше app (у нас в общем требование такое же по большому счету)
Так флеш памяти не хватит постоянно держать два ядра.
А в момент записи ядра на флешку необходимо, что бы уже было записано второе, гарантированно не поврежденное ядро
Если речь идет об Android Wear, на котором обычно мало места, и используется squashfs — то сам по себе Wear достаточно нишевая история.
Если о телефонах и планшетах — то поиск по xda-developers говорит сам за себя — squashfs крайне редок на телефонах.
Стоит ли говорить о том, что удалять что-либо хотять именно отдельные, достаточно редкие, владельцы именно таких моделей?
С этим в корне не соглашусь. Предустановленные вендором мусорные приложения мешают даже если на флешке много места — хотя бы потому что засоряют список программ, могут в фоне жрать батарейку.
Более того, никто же не мешает:
а) не физически удалять приложения с диска, а только скрывать их из списка приложений и гарантированно деактивировать все их активности. На мой взгляд — такого решения было бы вполне достаточно, даже в случае RO system fs.
б) предустанавливать приложения от вендора на раздел data
Версии gcc/ядра/библиотек идут из SoC SDK, и вне зависимости от подхода надо будет их поддерживать в приложении.
У вендоров камер нет технической возможности нормализовать версии gcc/libc.
А софт вендора раз в 30 секунд будет их обратно открывать (да, это пример из реальной жизни) :)
Мы пробовали делать интеграцию на уровне API с несколькими вендорами — уходит очень много времени на отладку взаимодействия, и на тестирование результирующих прошивок. И более того, каждый апдейт со стороны — все старые проблемы вылезают обратно.
По опыту дешевле сделать поддержку в приложении работы напрямую с SoC. При наличии уже готового нашего видео-приложения и системы сборки — добавление поддержки нового SoC, быстрее чем тестирование/интеграция в прошивку вендора.
Захват и трансляция видеопотока это далеко не единственная функция прошивки. Софт отвечает за настройку параметров аудио/видео, за обратный канал аудио, за видео- и аудио- аналитики (детекторы событий — например движения и анормального звука), управление PTZ и т.д. и т.п. Кроме этого. нужно реализовать механизм обновления прошивок.
Подстраиваться под API каждого вендора камер (которых намного больше чем используемыз SoC) никаких ресурсов не хватит. И это не говоря о поддержке и выпуске обновлений.
А еще во многих случаях китайские прошивки содержат дыры/бэкдоры и много ненужного функционала который с одной стороны снижает информационную безопасность, а с другой стороны увеличивает требования к железу.
О мотивации было подробнее в предыдущей статье — https://habr.com/ru/post/415841/
Зависит от размера вендора. В среднем, как правило, на партиях от нескольких тысяч штук.
На мой вкус, когда регулярно нужно работать с проектами живущих в разных средах и разных ЯП — у vscode нет конкуренции.
Это у них получается за счет мощной системы плагинов и очень качественного терминала.
Бесспорно, под каждый ЯП есть более мощные и крутые частные решения типа qt crearor, inteliJ, и тд.
Но если нужно универсальное решение, то vs code — кажется пока лидер, как универсальный редактор кода, с кучей плагинов под нужные ЯП и окружения
Поправил, прошу рассмотреть повторно!
Ох, простите, запутался в их схемах и связях…
но что это изменит? Ростех — продает, Роснано — учредитель. Увы, в данном случае для нас не изменится ничего (
Насколько мне известно — Элвис и Элвис-Неотэк это разные компании. Какие у них отношения друг с другом — мне не известно.
Все написаное в статье относится исключительно к Элвис-Неотэк, и в их линейке VisorJet bullet & etc и близко нет никаких своих SoC...
Свою прошивку мы уже написали.
Но к таким методам дистрибуции все же не готовы :)
Речь об обратном процессе — записи уроков через камеры. Не готов спорить о моральных аспектах видеонаблюдения, но когда доступ к "слежке" и более того, к подделке видеозаписей, получает не ограниченый круг лиц, это ни в какие ворота не лезет...
В новости написано, что эти камеры будут использоваться в процессе дистанционного образования.
Не буду сильно вдаваться в конспирологические теории, но к примеру никто не мешает подменить видеопоток дырявой камеры с записью урока на что угодно.
Страшно представить, что можно наворотить, обладая такой возможностью...
Видеокомфорт давно уже трансформировался в другие сервисы, например, camera.rt.ru — туда же и перевели пользователей.
Бюджетных денег не пилим :)
А вас не смущает, что эти господа получили под это субсидии от государства, а теперь врут заявляя что это Российская разработка.
Вот цитата из новости:
И кто им портит деловую репутацию, если они говорят заведомую неправду, непонятно на что потратив субсидии?
Мы сами не производим камеры, но закупаем камеры производства мировых лидеров, в том числе Hikvision и Dahua, по ценам как раз начинающихся от 1800 рублей за штуку....
Производителю "багрепорт" еще два года назад делали. Об этом написано в статье.
А рандомные прокси и UA уже не помогают?
А зачем для маркета хромиум? Полгода назад он отлично утягивался без всяких ухищрений
А в смысле при каждом обновлении менять разделы местами — да, так можно. Но в самой прошивке прийдется обрабатывать два разных режима. Чуть менее детерминированно получается. Ну и по размеру в этой схеме есть требование: kernel не должен быть больше app (у нас в общем требование такое же по большому счету)
Так флеш памяти не хватит постоянно держать два ядра.
А в момент записи ядра на флешку необходимо, что бы уже было записано второе, гарантированно не поврежденное ядро
Привет,
Камеру видеокоморфт можно подключить к camera.rt.ru или lk.smarthome.rt.ru
Без них, как минимум, можно включить RTSP
ethernet PHY у нее нет.
Сервис обновления — сами делали. Не знаю готовых и подходящих решений. Обновления происходят в автоматическом режиме.
Если речь идет об Android Wear, на котором обычно мало места, и используется squashfs — то сам по себе Wear достаточно нишевая история.
Если о телефонах и планшетах — то поиск по xda-developers говорит сам за себя — squashfs крайне редок на телефонах.
С этим в корне не соглашусь. Предустановленные вендором мусорные приложения мешают даже если на флешке много места — хотя бы потому что засоряют список программ, могут в фоне жрать батарейку.
Более того, никто же не мешает:
а) не физически удалять приложения с диска, а только скрывать их из списка приложений и гарантированно деактивировать все их активности. На мой взгляд — такого решения было бы вполне достаточно, даже в случае RO system fs.
б) предустанавливать приложения от вендора на раздел data