pfg21

отключать в биосе соответвующие носители или разъемы к которым они подключены

наверное там vi или vim - мощный cli текстовый редактор, но сложный в управлении аки станок с ЧПУ... :)
и да подсказокс клавишами у него на экране нет :)
посоветую поставить nano или mc (в комплекте будет mcedit) они более просты и наглядны в интерфейсе.

вариант2: изучить vi :)

спробовать rclone. он может множество облаков, в том числе и яндекс. опция монтирования через fuse имеется.
судя по описанию подключения использует отличный от webdav интерфейс.
однако яндекс не рад рклоуну

если тебе не нужна большая мощность на выходе, то лучше используй обычный выход ЦАП и аналоговый усилитель на 15 вольт.
какаянить стандартная микросхемка усилителя мощности звука вполне пару ампер на выходе даст.
плюс элементарная и понятная схема, отлично работает, настройки практически не требует. минус КПД и грется будет конечно. но зависит от потребления.

dc-dc это если тебе нужная большая мощность на выходе.
если схема стандартна, то в ООС просто добавить компаратор.
на плюсовой вход резистивный делитель от выхода чтобы преобразовывать 0-15 в рабочий диапазон ЦАП.
на минус выход ЦАП.
а выход компаратора подать вход ООС при превышении напряжения на выходе компаратор включится и остановит работу ШИМ.
изменения в блоке питания будут минимальны.

Чутка погуглил за тебя.
Во второй ссылке есть предложение по использованию службы юникс печати для винды и проброс порта.
https://anr-daemon.livejournal.com/10446.html
Попробуй сколхозить на подобии

Я б предложил маршрутизатор все таки использовать нативно, без контейнеров и прокладок.
А уже вторичные функции впихивать в контейнеры внутри опенврт.
https://openwrt.org/lxc_openwrt_host

Опенврт удобен тем что он минималистичен и имеет отличный веб-интерфейс

я так понимаю по наличию разъем под сенсор, предполгаю он слева надписи 25.5t. поищи описание движка.

погуглил за тебя :)
вот мануалка на похожий мотор где четко виден разъем и контакты внутре него
https://www.minicars.se/internt/artiklar/HW3040801...

вариант А: простой телефон или владелец - хомячок, носитель не зашифрован, есть только пин-код на вход.
то влезть можно, считав данные непосредственно с незашифрованной флеш-памяти.

вариант Б: телефон с защитой и владелец включил шифрацию носителя данных. ключ шифрации лежит внутри проца и недоступен.
то влезть, ясен пень, никак.

расчет шумоподавляющего дросселя ИБП
п.с.: учти что расчет идет по мощности или току потребления, а не по транзистору :)
или посмотреть готовые схемы фильтр питания ИБП опять же смотри на какие токи токи/мощности рассчитана схема.

если уже используешь rsync, то посоветую подняться чутка и выше и перейти на демона syncthing.
связь между клиентами качественно шифрована. никаких левых облаков и серверов - все данные только на своих компутерах. передача изменений в онлайн
есть возможность на некоторых клиентах хранить шифрованную копию раздачи без возможности доступа к файлам.
есть несколько вариантов по сохранению измененных файлов (простая корзина и сложнее)

ага, для автозапуска необходим вход пользователя.
используй вместо автозапуска службы виндоус, они конечно кривоваты для использования, но зато запускаются вне зависимости от пользователя.
крививоватость использования исправляю через Non-Sucking Service Manager есть еще какието поделки.
очередность можно сделать через зависимости, но виндовые зависмости сервисов не ковырял.

обязательно изучай линукс. в серверных делах без него никак.
со смартфона можно подключаться через кучу полноценных ssh-клиентов.
минус - смартфон не очень удобен для commad line. блютус клавиатура или планшет уже проще.
еще есть вариант прикрутить веб-интерфейсы, но тут готовых заготовок нет.

старые репы лежат здесь
https://old-releases.ubuntu.com/ubuntu/
подключи их и некрофиль дальше :)

все очень просто, покупаешь на каждый мобиль жпс-маяк
варианты вот здесь неплохо собраны
https://club.dns-shop.ru/blog/t-272-drugie-avtotov...
вариант2: сам костылишь систему

ТОЭ, часть первая, метод контурных токов. Изучать от корки до корки.
В нем описано как распределять контурные токи, а также правило что в одном контуре не должно быть "прописано" двух токов (не помню точные определения)

Опять же, даже теоретически, схема бессмысленна.
ибо два источника разного напряжения замкнутые меж собой создадут ток бесконечной мощности.
Ну и какой-то ток будет идти через сопротивление. Какой точно вычислить не возможно :)

из практичеких сображений нет :)
сложная операционная система с таксками и прочими крутыми штуками в элементарном алгоритме будет только мешать.
самое эффективное оформить всё через таймеры, а процессор усыпить. будить только управляющими входами для изменения параметров периодичности.

но если есть желание поковыряться с freertos - то может быть.

один из методов решения проблемы "стабильность против свежесть" ПО в продакшене.
к примеру тот же старикан дебиан "сильно тормозит" и от выпуска обновления исходников по до внедрения в стейбл-дистр есть куча этапов, где вылавливаются баги в том числе и на продакшене "хотящих новшеств".

а есть и более быстрые в плане новшеств дистры (не будем тыкать пальтцем:) ) которые предоставляют свежие, не полностью вычищенные исходники на продакшен пользователя - вот там аккурат и получают "траблшутинг на продакшене" для линухи.

п.с. в некоторых решениях, не требующих стабильности "траблшутинг на продакшене" становится очень выгоден и его используют.
ну к примеру в организации бесплатных впс, мелких сайтиков и прочей бесплатной дребедени. договором пользователю там ничего не гарантируется, даже если все накроется БП, он может лишь дождаться примитивного восстановления системы. а проверка серверного ПО идёт отлично и во множестве применений :)

это если буквально понимать "траблшутинг на проде в контексте линукс" :)

создать автозапускаемый+systemd.service
перезапуск в случае крушения и перенаправление логов прописать внутри сервиса.

не знаком с линейкой, но статей как запустить линйку через системд думаю хватает - читнуть их. там наверняка дополнительные тонкости описаны.

файл конфига изменен, но чтобы работающий в памяти sshd его перечитал необходимо ему намекнуть.
sudo systemctl reload ssh.service
потом глянуть статус
sudo systemctl status ssh.service
в нем должно быть.

фев 22 22:43:11 srv16 systemd[1]: Reloading OpenBSD Secure Shell server...
фев 22 22:43:11 srv16 systemd[1]: Reloaded OpenBSD Secure Shell server.
фев 22 22:43:11 srv16 sshd[462]: Server listening on 0.0.0.0 port 4453.
фев 22 22:43:11 srv16 sshd[462]: Server listening on :: port 4453.

чисто от себя: менять номер порта ssh для скрытия доступа бессмысленно. посоветую использовать хороший длинный ключ