Версии gcc/ядра/библиотек идут из SoC SDK, и вне зависимости от подхода надо будет их поддерживать в приложении.
У вендоров камер нет технической возможности нормализовать версии gcc/libc.

Скрипт для iptables, который закрывает все порты на вход и выход кроме двух, умещается в 10 строчках.

А софт вендора раз в 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