Опубликовано: 15.10.2026 | Источник: OpenNET

ALT Mobile 11.0 в дипломе: от Phosh-оболочки до защищаемой ВКР по embedded Linux

Поддомен: Cloud/DevOps (встраиваемые Linux-платформы, сборка и сопровождение образов). Роль эксперта: DevOps/SRE-инженер.

Введение

30 марта 2026 года «Базальт СПО» представила ALT Mobile 11.0 — мобильную платформу на пакетной базе репозитория Сизиф (p11), укомплектованную оболочкой Phosh поверх композитного сервера Phoc и технологий GNOME. Целевое железо — не только смартфоны и планшеты, но и встраиваемые устройства с сенсорным экраном: считыватели штрихкодов, контрольно-кассовые аппараты, терминалы сбора данных.

Почему это важно выпускнику ИТ-специальности? Потому что здесь сходятся сразу четыре защищаемых пласта: архитектура мобильной ОС, сборка образов под конкретное железо, юзабилити сенсорного интерфейса и эксплуатация парка устройств. Такой кейс даёт измеримые метрики (время загрузки, потребление, размер образа), а значит — сильную главу «Эффективность» вместо пересказа документации. Ниже — как превратить новость в структуру ВКР, какие артефакты приложить и что считать.

Частые вопросы студентов по теме

Мне дадут исходники ALT Mobile для экспериментов?

Да, платформа собирается из открытых репозиториев ALT: пакетная база p11 («Сизиф»), сборочные профили и инструменты. Для ВКР достаточно воспроизвести сборку в виртуальной машине и на одной целевой плате — это уже полноценный практический результат.

Хватит ли одной платы, если в лаборатории нет терминала сбора данных?

Хватит. Возьмите любой SBC с сенсорным экраном или QEMU с пробросом тач-панели. В главе 3 честно опишите ограничения стенда — это нормальная инженерная практика, а не слабость работы.

Как оформить схемы сборки, чтобы их принял нормоконтроль?

Компонентную схему — по C4 (уровни Context и Container), развёртывание — UML Deployment Diagram, стадии сборки — BPMN или activity-диаграмму. ГОСТ 34.601-90 задаёт стадии создания системы, ГОСТ 19.201-78 — структуру ТЗ, если работа оформляется как программная документация. Не смешивайте нотации в одной схеме.

Какие метрики реально посчитать за семестр?

Время холодной загрузки, потребление ОЗУ в простое, размер образа, время установки OTA-обновления, число дефектов на релиз, MTBF на стенде. Этого достаточно для главы об эффективности по ISO/IEC 25010.

Темы ВКР, которые вырастают из этого кейса

• Тема 1. Воспроизводимая сборка образа ALT Mobile 11.0 для терминала сбора данных.
  Актуальность: в статье прямо указаны встраиваемые устройства как целевой класс — значит, нужен воспроизводимый профиль сборки, а не «ручная настройка на коленке».
  Цель: получить повторяемый образ под конкретную плату с фиксированными метриками.
  Задачи: анализ p11 и сборочных профилей; проектирование профиля; сборка и верификация; замер времени загрузки и размера образа.
  Структура: Гл. 1 — анализ платформы и инструментов сборки; Гл. 2 — проектирование профиля и скриптов; Гл. 3 — стенд, замеры, сравнение с базовым образом.

• Тема 2. Адаптация Phosh/Phoc под считыватель штрихкодов: юзабилити и энергоэффективность.
  Актуальность: GNOME-оболочка проектировалась под смартфон, а не под «одно окно приложения и сканер».
  Цель: снизить энергопотребление в простое без потери отзывчивости.
  Задачи: обзор Phosh/Phoc; профилирование; настройка композитора и политик питания; A/B-замеры.
  Структура: Гл. 1 — Wayland-стек и GNOME-технологии; Гл. 2 — конфигурация оболочки; Гл. 3 — метрики и выводы.

• Тема 3. Сравнительная оценка мобильных Linux-платформ по ISO/IEC 25010.
  Актуальность: ALT Mobile 11.0 конкурирует с postmarketOS, Aurora OS и Android-решениями — нужна объективная методика выбора.
  Цель: построить модель оценки и ранжировать платформы.
  Задачи: выбор характеристик стандарта; веса критериев; экспертный опрос или замеры; ранжирование.
  Структура: Гл. 1 — теория и стандарт; Гл. 2 — методика и матрица; Гл. 3 — расчёты и проверка чувствительности.

• Тема 4. CI/CD-конвейер сборки и OTA-обновления парка терминалов.
  Актуальность: парк устройств на сенсорных экранах требует управляемых обновлений и откатов.
  Цель: сократить время доставки исправления до устройства.
  Задачи: проектирование пайплайна; атомарные обновления; стратегия отката; метрики DORA.
  Структура: Гл. 1 — обзор подходов к OTA; Гл. 2 — реализация конвейера; Гл. 3 — нагрузочные и отказные сценарии.

Основная часть: как встроить кейс в главы работы

1. Карта соответствия «материал статьи → глава ВКР»

2. Архитектурный разрез: что показать в главе 2

Опишите стек послойно: ядро и драйверы → Wayland → Phoc как композитор → Phosh как оболочка → прикладное киоск-приложение. Ключевая мысль для защиты: Phosh — это не «GNOME, урезанный напильником», а отдельная оболочка, использующая библиотеки GNOME и протокол Wayland. Такая формулировка сразу показывает понимание предмета.

Отдельно проговорите ограничения: единая кодовая база на смартфоны и ТСД означает компромиссы по энергопотреблению и политике окон. Это отличный повод для раздела «Анализ компромиссов» — комиссия такие места любит.

3. Практика сборки: пример профиля и автозапуска

Для главы 2 полезно привести фрагмент сборочного профиля — он демонстрирует, что вы работали с инструментами, а не пересказывали релиз-ноут.

# targets/tsd-rk3566.mk — профиль терминала сбора данных
DISTRO_TYPE       = mobile
KERNEL_PACKAGE    = kernel-image-un-def
@$(call add,THE_PACKAGES,phosh phoc squeekboard)
@$(call add,THE_PACKAGES,alt-mobile-branding-release)
@$(call add,THE_PACKAGES,terminal-collector)
@$(call set,IMAGE_TYPE,hybrid)
@$(call set,ROOTFS_SIZE,2048M)

А вот systemd-юнит, который превращает устройство в рабочее место оператора — его удобно показать как листинг приложения А.

[Unit]
Description=Kiosk frontend for barcode terminal
After=graphical.target
[Service]
User=operator
Environment=WAYLAND_DISPLAY=wayland-0
Environment=MOZ_ENABLE_WAYLAND=1
ExecStart=/usr/bin/terminal-collector --fullscreen --api https://erp.local/api
Restart=on-failure
RestartSec=5
[Install]
WantedBy=graphical.target

Для темы 4 добавьте стадии конвейера: сборка → smoke-тест в QEMU → подпись образа → доставка на стенд → откат при провале health-check. Здесь же уместно упомянуть наблюдаемость: метрики и трассировку удобно снимать через OpenTelemetry, а не изобретать свой формат логов.

4. Эффективность: какие метрики считать

Сравнивайте не «до/после» в вакууме, а с базовой конфигурацией или альтернативной платформой. Разница в 15–20% уже защищаема, если методика воспроизводима и указано число прогонов.

Чему вы научитесь

• Проектировать воспроизводимые сборочные профили для встраиваемого Linux и оформлять их как приложение к ВКР.
• Строить конвейер CI/CD с этапами верификации образа, подписи и откатом.
• Инструментировать устройство и снимать метрики по OpenTelemetry вместо ручных замеров «на глаз».
• Оценивать платформу по ISO/IEC 25010, а не по субъективному «нравится/не нравится».
• Оформлять ТЗ и стадии разработки по ГОСТ 34.601-90 и ГОСТ 19.201-78 без переделок у нормоконтроля.

Источник: Мобильная платформа ALT Mobile 11.0, построенная на технологиях GNOME (опубликовано 2026-03-30)