Что происходит после подачи питания
Из каких ступеней состоит запуск станции?
Первому хабу нужен обслуживаемый системный образ. Разработка собственного ядра потребовала бы отдельного обоснования и вышла бы за задачу начальной операционной платформы.
Подача питания не означает немедленную готовность комнаты. Сначала запускается загрузчик, затем ядро Linux и драйверы, потом системные службы и Koobique. После этого ещё нужно восстановить сеть и сверить состояние устройств.
Мы будем различать эти ступени в журнале и интерфейсе. Тогда сообщение «станция запускается» можно заменить полезной причиной: накопитель доступен, локальный API работает, но один узел ещё не подтвердил состояние.
Koobique OS — продуктовая платформа поверх Linux. Linux управляет процессами, памятью, накопителями, радио и аудио. Rust-core интерпретирует физические данные и оркестрирует устройства. Такое разделение сохраняет контроль над системой, не требуя переписать USB, Wi-Fi и планировщик.
Системная основа#
Для первого x86-экземпляра предлагается стабильный Debian без графического рабочего стола и с фиксированным набором пакетов. Это облегчает диагностику, обновление драйверов и работу с инструментами. Для более управляемого образа позже сравниваются Buildroot и готовая A/B-инфраструктура. Малый размер образа полезен, но не должен стоить потери воспроизводимого восстановления. [37][90]
Необходимые службы: менеджер сети, SSH, синхронизация времени при наличии источника, журнал, Koobique-core, ограниченный привилегированный helper, аудиослужба и опциональные inference-workers. Нет обязательного Node.js, браузера, Kubernetes или Redis. Контейнеры могут использоваться для сборки и испытаний; их наличие на самой станции — отдельное решение.
Последовательность загрузки#
UEFI и загрузчик передают управление ядру. Драйверы поднимают накопитель и сеть. Системные службы запускают Core после доступности обязательных ресурсов. Core читает конфигурацию, отмечает восстановленные наблюдения как потенциально устаревшие, открывает API и ждёт свежего состояния узлов.
Готовность разбивается на уровни: процесс жив; конфигурация читается; локальный API доступен; сеть работает; конкретный узел синхронизирован. Один зелёный индикатор «всё хорошо» скрывает слишком много. Приложение должно объяснять, что именно ещё не готово.
Драйверы и идентификация оборудования#
Wi-Fi проверяется по PCI/USB ID и версии firmware. Аудио — по реально доступным каналам, частотам и поведению USB. Датчики CPU/платы — по драйверу hwmon и смыслу каждого показания. Например, k10temp документирует температурные каналы AMD; это не даёт права трактовать любое число hwmon как температуру воздуха. [38][39][40]
На ARM важны Device Tree и точная аппаратная ревизия. Неверное описание контакта или периферии может выглядеть как ошибка пользовательской программы. На типичной x86-платформе многие устройства описываются иначе; копировать инструкции настройки GPIO с Pi на Mini-ITX нельзя. [74]
Стабильные имена устройств формируются через udev по свойствам, а не по случайному /dev/ttyUSB0. Два подключённых ESP-модуля могут поменяться номерами после перезагрузки. Ошибка идентификации здесь опаснее отсутствия соединения: программа может отправить команду не тому исполнительному узлу.
Изоляция процессов#
Core работает без root. Доступ к USB, Bluetooth и аудио выдаётся конкретным сервисам. Привилегированный helper принимает узкий набор структурированных запросов: применить сетевой профиль, переключить образ, собрать диагностические сведения. Он не исполняет произвольную строку shell из приложения.
systemd/cgroup позволяют ограничить память, CPU и другие ресурсы служб. Speech-worker получает меньший приоритет доступности, чем управление. Но ограничения не должны быть настолько жёсткими, чтобы постоянно вызывать перезапуски и новую загрузку модели. Нужен запас и ограничение очереди запросов. [41]
Время, журнал и диск#
Относительные таймеры используют монотонные часы. Календарные расписания — часовую зону и явно обработанные скачки времени. После включения без интернета RTC помогает восстановить приблизительное время, но его точность проверяется. Истечение сертификатов не решается отключением всей проверки доверия.
Журнал имеет лимит объёма, ротацию и маскирование секретов. Пароль Wi-Fi, токен восстановления и аудиозапись не должны попадать в общий debug-log. При заполнении диска система сокращает диагностические данные раньше, чем теряет возможность сохранить критическую конфигурацию. Для этого требуется запас места и отдельные пороги.
Оптимизация без слепых отключений#
Сначала профилируется штатная система. Проверяются CPU governor, задержка пробуждения, нагрузка IRQ, запись диска и влияние аудио. Затем меняется один параметр и повторяется полный тест. Отключение защиты памяти, TLS-проверки или mitigations ради микросекунд не считается допустимой оптимизацией качества.
Системная приёмка#
После холодной загрузки проверить сеть, время, БД, USB-идентичности и локальный API. Остановить каждый необязательный worker и убедиться, что Core остаётся доступным. Проверить возвращение питания, свободное место, журнал причины сбоя и локальный SSH без внешнего сервиса.
Служба должна загрузиться даже без роутера#
Core стартует с локальным хранилищем и диагностикой без ожидания network-online.target. Появление адреса и смена сети обрабатываются как события. Для systemd выбираются Type=notify, WatchdogSec и ограниченные перезапуски; уведомление watchdog выдаётся только при продвижении критических задач. Слепой таймер, живущий отдельно от зависшего исполнителя, не подтверждает здоровье службы. [160][161]
В карте установки: Restore on AC Power Loss в UEFI/BIOS, политика сна H0, журнальные квоты, права на /data, nftables, SSH по ключам и отдельная сервисная учётная запись. Доступ к отладке не означает постоянную публикацию SSH на внешнем интерфейсе. Сначала проверяются локальный запуск и восстановление, затем удалённый путь.