Kylin Desktop V11 изнутри: неизменяемая система, встроенные нейросети и обзор программ

Автоматизированное тестирование наших продуктов для Avalonia UI работает на виртуальных машинах с разными Linux: Ubuntu, Astra Linux, ALT, РЕД ОС. Мы планируем расширить этот набор. Изучили Kylin Desktop V11 (银河麒麟, «Галактический Цилинь») — основную ОС для госсектора Китая — и решили поделиться результатами. В этой ОС встречается несколько интересных вещей, о которых мы хотим рассказать сегодня. Корень системы неизменяемый и обновляется атомарно через ostree, apt работает в отдельном контейнере, у программ свой формат пакетов, а вместе с рабочим столом запускается сервер инференса NVIDIA Triton с двумя десятками нейросетей.

В статье мы расскажем, как устроена система, как она обновляется и как вернуть предыдущую версию, если обновление не удалось. Проверим встроенные нейросети в деле и пройдёмся по всем встроенным программам. Статья будет интересна разработчикам и администраторам Linux: всегда любопытно посмотреть, как всё устроено у соседей. Все выводы получены на живой системе, команды и их вывод приводим как есть.

Что за система

$ cat /etc/os-release
NAME="Kylin"
VERSION="银河麒麟桌面操作系统V11"
VERSION_US="Kylin Linux Desktop V11"
ID=kylin
VERSION_ID="v11"
KYLIN_RELEASE_ID="2603"
ID_LIKE=openKylin

$ uname -r
6.6.0-76-generic

Ветка V11 вышла в августе 2025 года на ядре 6.6. По заявлению Kylin, это первый коммерческий китайский дистрибутив на этой LTS-ветке ядра. Предок системы — openKylin, а не Ubuntu, как было у V10: в ID_LIKE стоит openKylin, пакеты имеют суффиксы вида -ok1k0.2. Окружение рабочего стола — UKUI 4.20 на Wayland с собственным композитором kylin-wlcom на основе wlroots. Композитор, в частности, умеет запрещать снимки экрана для отдельных окон или всего экрана.

Система собирается из одних исходников для x86_64, ARM64 и LoongArch64. Согласно документации, поддерживаются процессоры Phytium (D3000M, D3000, D2000, FT-2000/4), Loongson (3A6000, 3A5000), Hygon (C86-3G, C86-4G), Zhaoxin (KX-7000/6000/5000, KH-40000), Sunway SW-831, Kunpeng 920, а также Intel и AMD. Минимальные требования — 4 ГБ RAM, 128 ГБ диска и TPM 2.0, рекомендуемые — 8 ГБ RAM и SSD на 512 ГБ. Базовые компоненты: glibc 2.38, systemd 255, GRUB 2.12, Python 3.12, OpenJDK 17 и 21, GTK 3.24 и 4.14. Согласно документации, в ядро внесены собственные доработки. Активное приложение получает приоритет при распределении процессорного времени, а фоновые ограничиваются (задержка планирования снижена более чем на 90 %). Включён MPTCP (Multipath TCP): одно TCP-соединение может идти сразу по нескольким сетевым каналам, например по Wi-Fi и кабелю, поэтому пропускная способность растёт (до 8 раз), а соединение не рвётся, если один канал пропал. Доработан BFQ, планировщик дисковых операций: чтение и запись активного приложения обслуживаются в первую очередь, и крупные программы запускаются на 5 % быстрее. При нехватке памяти ядро завершает в первую очередь фоновые процессы и не трогает системные. Из новых механизмов планирования есть два. EEVDF — планировщик задач, который в ядре 6.6 заменил CFS: он не только делит процессорное время поровну, но и учитывает «крайний срок» каждой задачи, поэтому интерактивные программы реже ждут своей очереди. sched_ext позволяет загружать собственные алгоритмы планирования в виде eBPF-программ прямо на работающей системе, без пересборки ядра и перезагрузки. В основное ядро Linux он вошёл только в версии 6.12, в Kylin его перенесли в ветку 6.6. Отдельно заявлено, что в ядре выпуска закрыто 5163 CVE, из них 1308 с оценкой 7 и выше.

Первое отличие от обычного дистрибутива видно уже при установке. Полному варианту установки нужен диск от 100 ГБ. На 50 ГБ установщик отводит под корень 23 ГБ и падает с «No space left on device». После установки разметка такая:

NAME   FSTYPE LABEL
├─sda1 ext4   SYSBOOT   /boot
├─sda5 ext4   SYSROOT   /  (и всё, что ниже)
├─sda6 ext4   DATA      /data → bind-монтирования /home и /root
└─sda7 swap   SWAP

Домашние каталоги и /root вынесены на отдельный раздел DATA и подключаются bind-монтированием из /data. Это первая подсказка: система рассчитана на то, что корень можно целиком подменить, а пользовательские данные при этом сохранятся.

Неизменяемый корень: ostree

Начиная с выпуска 2603 системная часть Kylin V11 развёрнута через ostree, ту же технологию, что лежит в основе Fedora Silverblue и Endless OS.

$ sudo ostree admin status
* kylin 2205d98137c09e1d006147f850f3bce06fb25cf7650e73fa6dd1d0af66339e47.0
    Bootcsum: ab6d8ef570ed3afc7e397e0ead339dee23678bc110c1e9124b89c750c66d4cbd
    origin refspec: kylin:kylin/desktop/v11/2603/xc/general/all/release/amd64
  kylin c6914efa45786c8ff432b2a1a2c0933bbcdcb411d43bf03b65c83b3e5d4a2bc9.1 (rollback)
    Bootcsum: 233d332e8a78ae96784a48754d7fc7499a8495e4ae206adfaede579176d0f4fe
    origin refspec: kylin:kylin/desktop/v11/2603/xc/general/all/release/amd64
  kylin c6914efa45786c8ff432b2a1a2c0933bbcdcb411d43bf03b65c83b3e5d4a2bc9.0
    Bootcsum: 233d332e8a78ae96784a48754d7fc7499a8495e4ae206adfaede579176d0f4fe
    Pinned: yes
    origin refspec: kylin:kylin/desktop/v11/2603/xc/general/all/release/amd64

$ touch /usr/bin/hello
touch: cannot touch '/usr/bin/hello': Read-only file system

Команды выше выполнены в терминале графического сеанса, то есть на самом хосте. Почему по SSH картина другая, расскажем в разделе про KARE.

На диске три развёртывания:

• c6914e…0 — заводское, закреплённое (Pinned: yes), автоматическая очистка его не удалит;

• c6914e…1 — предыдущее, на него можно откатиться;

• 2205d9…0 — текущее. Его поставило обновление, которое сменило ядро с 6.6.0-63 на 6.6.0-76.

Имя ветки kylin/desktop/v11/2603/xc/general/all/release/amd64 само по себе интересно. Судя по всему, xc означает 信创 («инновационные ИТ», китайская программа импортозамещения), general — редакцию, all — набор пакетов. Репозиторий ostree лежит в /sysroot/ostree/repo, это режим bare объёмом 16 ГБ. Файлы развёртываний — жёсткие ссылки на объекты репозитория, поэтому три полные копии системы занимают место примерно одной.

Обновления система получает из репозитория ostree.kylinos.cn, его адрес задан в файле /etc/ostree/remotes.d/kylin.conf. В закрытом контуре достаточно развернуть собственное зеркало и указать его там. Для обычных программ у Kylin есть отдельное готовое решение, частный магазин программ (о нём ниже).

Загрузчик и откат на предыдущие версии

Каждое развёртывание получает свою запись в /boot/loader/entries, а GRUB строит из них меню:

title kylin v11 2603 release
version 3
options root=UUID=87d6… rw ostree=/ostree/boot.1/kylin/ab6d8e…/0
linux /ostree/kylin-ab6d8e…/vmlinuz-6.6.0-76-generic
initrd /ostree/kylin-ab6d8e…/initramfs-6.6.0-76-generic.img

Переключение на новую версию сводится к атомарной замене символьной ссылки boot.N. Состояния «обновилось наполовину» здесь не бывает: при сбое питания система загрузится либо в старое развёртывание, либо в новое. Чтобы откатиться, достаточно выбрать предыдущую запись в меню GRUB. Если нужно сделать предыдущее развёртывание основным, это делается штатной командой ostree (отдельной подкоманды rollback в ostree нет, в Kylin тоже):

sudo ostree admin set-default 1   # 1 — индекс развёртывания из ostree admin status
sudo reboot

В графическом интерфейсе всё это спрятано за привычным разделом «Обновление» в настройках, где номер сборки выглядит как KylinOS 2603 (83681.F260008):

Обновлениями можно управлять централизованно. Согласно документации, поддерживаются несколько зеркал с приоритетами, поэтапная раскатка на заданный процент машин, тихие и необязательные обновления по спискам серийных номеров из консоли администратора, ограничение скорости загрузки и защита от выключения машины во время обновления. Для ручной работы в образе есть полный набор man-страниц ostree-admin-*, а если повреждён сам загрузчик, есть утилита kylin-fix-boot-grub, которая восстанавливает GRUB из live-системы.

Надстройка Kylin: оверлеи и «режим обслуживания»

У чистого ostree /etc изменяемый, а /usr доступен только для чтения. Kylin идёт дальше и накрывает /etc, /usr и /var/lib собственными оверлеями. Схема описана в /sysroot/ostree/pkgs/system-ovl.conf:

[General]
Mode=normal
NextMode=normal
Deploy=2205d98137c09e1d006147f850f3bce06fb25cf7650e73fa6dd1d0af66339e47.0

[snapshot]
MaxCommitNumberInRepo=24

[watermark]
fontSize=20
fontColor=red
fontPos=BottomRight

[Overlay]
OverlayDir=/etc,/usr,/var/lib
PathPre=<stage>/sysroot/ostree/pkgs/ovl-<Deploy>

[usr-N]
LowerDir=<PathPre>/usr-ovl/usr-upper:<PathPre>/usr-ovl/usr-lower:<stage>/usr
UpperDir=
...
[usr-M]
LowerDir=<PathPre>/usr-ovl/usr-upper:<PathPre>/usr-ovl/usr-lower:<stage>/usr
UpperDir=<PathPre>/usr-ovl/usr-tmpupper
...

Секции -N описывают обычный режим (normal): у /usr нет upperdir, поэтому оверлей доступен только для чтения. Секции -M описывают режим обслуживания (maintain, 运维模式): появляется временный usr-tmpupper, и в систему можно вносить изменения. Режимами управляет демон ostree-maintain (D-Bus-имя com.kylin.MaintainMode). Внесённые изменения фиксируются как новые коммиты в локальном репозитории, их хранится до 24 (MaxCommitNumberInRepo). Секция [watermark] задаёт красный водяной знак в правом нижнем углу экрана, пока система находится в режиме обслуживания.

У каждого развёртывания свой каталог ovl-<hash> с etc-upper, usr-upper и var-upper. Поэтому при откате возвращаются и бинарники, и системные настройки той версии.

Итого, системная часть хоста собрана из таких слоёв, снизу вверх:

1. Репозиторий /sysroot/ostree/repo с объектами всех версий системы.

2. Развёртывания в /sysroot/ostree/deploy/kylin/deploy/: текущее, предыдущее для отката и заводское закреплённое. Их файлы — жёсткие ссылки на объекты репозитория.

3. Оверлеи pkgs/ovl-<развёртывание> поверх /etc, /usr и /var/lib. В обычном режиме /usr доступен только для чтения.

4. Вне развёртываний хранятся /var, общий для всех версий системы (кроме /var/lib, у которого свой оверлей в каждом развёртывании), и отдельный раздел DATA с /home и /root. В снимки они не входят, поэтому пользовательские данные и журналы переживают откат.

Поверх хоста работают контейнеры: KARE для deb-пакетов и Kaiming для приложений нового формата. О них ниже.

В документации Kylin такая архитектура называется «磐石» («скала», «твердыня»). Она состоит из трёх слоёв:

• неизменяемое ядро системы;

• слой обслуживания с изменениями, которые администратор вносит поверх ядра;

• слой приложений с двумя окружениями: KARE для старых deb-пакетов и Kaiming для программ в новом формате.

Как ставятся пользовательские пакеты, если ядро неизменно: контейнер KARE

Как же тогда работает sudo apt install? Подключимся к машине по SSH:

$ hostname
user-pc-kare

Хост называется user-pc, а SSH-сессия оказывается на user-pc-kare. Посмотрим на дерево процессов:

   1  systemd         /sbin/init splash
3102  kare            /usr/bin/python3 /usr/bin/kare run --run_direct openssh-server /usr/sbin/sshd -D
3166   \_ crun        /usr/bin/crun run --bundle /opt/kare-applications/shadow/merge -f /tmp/config….json
3169       \_ sshd    sshd: /usr/sbin/sshd -D [listener]

Сервер SSH запущен внутри OCI-контейнера (crun). Значит, и всё, что администратор делает по SSH, происходит в контейнере. Это KARE (Kylin Application Runtime Environment), слой совместимости, о котором в официальных материалах сказано только, что он «обеспечивает совместимость с V10».

Корень контейнера собран из оверлеев:

/usr  overlay  lowerdir=/usr:/opt/kare-applications/host/usr,
               upperdir=/opt/kare-applications/shadow/upper/usr, ...
/etc  overlay  lowerdir=/etc:/opt/kare-applications/host/etc,
               upperdir=/opt/kare-applications/shadow/upper/etc, ...
/     /dev/sda5[/var/opt/kare-applications/shadow/merge]

Нижний слой — неизменяемый /usr хоста, верхний — каталог shadow/upper. Всё, что ставит apt в этом окружении, оседает в shadow/upper и в ostree не попадает. Отсюда эффект, который мы наблюдали при подготовке образа: удаление встроенных пакетов не освобождает место на диске, а наоборот, занятое место растёт. После удаления WPS и ИИ-пакетов оно увеличилось с 35 219 до 35 266 МБ. Причина в том, что пакет из нижнего слоя удалить физически нельзя, его можно только скрыть служебным файлом-пометкой (whiteout) в верхнем слое, и эти пометки, как и обновлённая база dpkg, занимают дополнительное место.

Конфигурация контейнера /config.json — обычная OCI-спецификация:

"capabilities": ["CAP_CHOWN", "CAP_DAC_OVERRIDE", ..., "CAP_SYS_ADMIN",
                 "CAP_SYS_RAWIO", "CAP_NET_ADMIN", "CAP_SYS_MODULE", ...],
"uidMappings": [{ "containerID": 0, "hostID": 0, "size": 65536 }],
"namespaces": [{ "type": "mount" }, { "type": "uts" }]

Изолируются только пространства имён mount и uts. Сеть, PID и пользователи общие с хостом, привилегии администратора сохранены. Это сделано намеренно: KARE — слой совместимости, а не песочница. Старые deb-пакеты должны работать с устройствами, службами и процессами хоста так же, как в V10, просто их файлы ложатся в отдельный слой и не затрагивают неизменяемое ядро системы. Изоляцию приложений в V11 обеспечивает другой механизм, формат Kaiming.

systemctl внутри KARE

Внутри KARE /usr/bin/systemctl — символьная ссылка на Python-скрипт kare-systemctl.py. Запросы состояния (status, is-active, is-enabled, show, list-units и подобные) он передаёт настоящему systemctl. Остальные команды, например enable, disable, mask и restart, он не выполняет, а только дописывает в журнал /etc/kare/systemctl_commands.sh и возвращает код 0. Команды cat и list-timers в этот список не входят, поэтому тоже попадают в журнал. В нашем журнале нашлись команды скриптов настройки образа:

$ tail -5 /etc/kare/systemctl_commands.sh
/usr/bin/systemctl disable apt-daily.timer
/usr/bin/systemctl mask apt-daily.timer
/usr/bin/systemctl cat gdm3.service
/usr/bin/systemctl restart gdm3
/usr/bin/systemctl list-timers --all --no-pager

Логика понятна: deb-пакеты в постинсталл-скриптах часто вызывают systemctl enable, и в контейнере это не должно ломать установку. Но скрипты развёртывания, которые администратор запускает по SSH, тоже выполняются внутри KARE, и службы хоста они не меняют. Чтобы управлять службами хоста, команду нужно выполнять в пространствах имён mount и UTS процесса 1 (systemd):

sudo nsenter -t 1 -m -u systemctl mask apt-daily.timer

Или, как пришлось сделать нам для служб, на которые обёртка не реагирует, работать напрямую с символьными ссылками в /etc/systemd/system в тех же пространствах имён.

apt и dpkg тоже обёрнуты

/usr/bin/apt  -> apt_wrapper   (bash)
/usr/bin/dpkg -> dpkg_wrapper  (bash)

apt_wrapper разбирает аргументы и решает, кто будет обрабатывать операцию: родной apt.orig, kypackage_* или kare -P для пакетов из контейнеров. Удаление пакета, входящего в ostree-образ, в обычном режиме запрещено:

elif ! is_in_white_list ${package_name} && ! is_in_privilege_list \'${package_name}\' \
     && pkg_is_in_ostree ${package_name}; then
    printf "当前模式下,软件包 ${package_name} 不允许卸载\n"   # «в текущем режиме удалять пакет нельзя»

Ещё одна находка — способ, которым защищена конфигурация dpkg:

$ ls -la /etc/dpkg/dpkg.cfg.d/
crw-rw-rw- 1 root root 1, 3 ostree-guard

ostree-guard — это /dev/null, смонтированный bind-монтированием поверх файла конфигурации в режиме только для чтения. Это видно и по findmnt: udev[/null], ro. Простой способ защитить настройки dpkg от случайной перезаписи пакетами и скриптами.

Сам KARE

/usr/bin/kare — Python-утилита, которая умеет собирать окружения совместимости (-b ubuntu20.04 с сокращениями u16 … u24), ставить в них пакеты, искать файлы и запускать программы:

$ kare --help
  run                 使用KARE运行软件              (запустить программу в KARE)
  clear_base_apply    清除基础环境中的指定软件包     (удалить пакет из базового окружения)
  restore_apply       重置容器，恢复到下层状态 …    (сбросить контейнер к нижнему слою)
  try-install         仅测试安装的 deb 和环境 …     (пробная установка без установки)
  -b BUILD_RELEASE    构建兼容运行环境              (собрать окружение совместимости)

В системе два окружения: shadow (обновляемый слой над хостом) и v10sp1 (база Kylin V10 SP1 на 4,8 ГБ) для программ, собранных под прошлое поколение. Для v10sp1 при входе в сессию поднимается dbus-daemon-proxy --namespace v10sp1 и собственный polkit-агент, чтобы старые программы могли общаться с новым рабочим столом. В /etc/kare/extra-deb лежит список программ с особыми зависимостями. Например, для wemeet (Tencent Meeting) и zw3d2024 (китайская CAD-система) из архивов V10 подтягивается Mesa на LLVM 11.

Кроме KARE, в документации описаны ещё два окружения совместимости, которых нет в базовой установке: KMRE для Android-приложений (APK ставятся напрямую, без эмулятора) и KWRE для Windows-программ (заявлено более 50 адаптированных приложений). Оба ставятся из Магазина программ.

Третий формат пакетов: Kaiming

Если apt работает в контейнере, а система неизменяема, то прикладные программы поставляются отдельно, в формате Kaiming (开明, файлы .ok). Пакет состоит из трёх слоёв: базовый слой, рантайм и само приложение. Запускается всё через crun. Согласно документации, для переноса существующих программ есть инструмент конвертации deb-пакетов в формат Kaiming.

$ kaiming list
id                                    name                  version   size
top.openkylin.ukui                    ukui runtime          1.1.42    1.7 GB
top.openkylin.base                    openkylin base        1.1.13    3.1 GB
cn.kylin.kylin-aiassistant            kylin-aiassistant     3.0.67    203.3 MB
top.openkylin.qaxbrowser-safe-stable  qaxbrowser-safe-stable 1.0.46247 352.3 MB
top.openkylin.kylin-calculator        kylin-calculator      1.2.0.0   13.7 MB
top.openkylin.kylin-scanner           kylin-scanner         3.2.1     80.8 MB
...

Из kaiming list видно 17 пакетов: два базовых слоя и 15 приложений. Калькулятор, камера, музыка, видео, часы, погода, заметки, сканер, прожиг дисков и браузер поставляются уже не deb-пакетами. Ярлык в меню вызывает /var/opt/kaiming-tools/bin/kaiming. Это bash-обёртка, которая передаёт управление km-run (запуск) или km-cli (управление пакетами).

Метаданные приложения лежат в info.json, и там же описаны права приложения: доступ к файлам, сети, автозапуск и т. п.:

{
  "id": "cn.kylin.kylin-aiassistant",
  "base": "stable:top.openkylin.base/1.1.11/x86_64",
  "runtime": "stable:top.openkylin.ukui/1.1.40/x86_64",
  "annotations": {
    "kylin.gpu": true,
    "kylin.depend-apps": ["/usr/bin/ukui-control-center", "/usr/bin/pluma",
                          "/usr/bin/peony", "/usr/bin/ffmpeg"]
  },
  "permission": {
    "filesystem": { "filesystem-dirs": ["~"] },
    "net": { "network": true },
    "others": { "prevent-sleep": true, "system-power-policy": true },
    "processManager": { "autostart": true }
  }
}

Есть и команды для разработчика: kaiming build-init, build, build-finish, build-export, а также deltas для сборки инкрементальных пакетов. Отдельно поставляется copy-appimage-dependencies.sh, то есть путь «завернуть AppImage в .ok» предусмотрен.

Получается, что в одной системе живут три способа поставки ПО: ostree-образ, deb в контейнере KARE и пакеты Kaiming.

Встроенный ИИ: Triton, llama.cpp и облачные модели

Официально V11 позиционируется как «ОС для эпохи ИИ»: в анонсах упоминаются ИИ-подсистема, ИИ-ассистент и «гетерогенное планирование вычислений между CPU, GPU и NPU». Посмотрим, что за этим стоит.

Сервер инференса

Сразу после загрузки работает системная служба kytensor.service:

$ systemctl cat kytensor.service
Description=Kylin triton inference server
ExecStart=/bin/bash -c 'source /usr/share/kylin-ai-python-env/python-env/bin/activate && \
  /usr/bin/kytensor --model-repository=/usr/share/kylin-ai/model-repository \
                    --model-repository=/opt/appdata/kylin-ai/model-repository \
                    --model-control-mode=explicit'

Пакет kytensor-server версии 2.49 включает заголовки /usr/include/triton/core/tritonserver.h, tritonbackend.h и так далее. Это NVIDIA Triton Inference Server, переименованный в kytensor и запущенный на десктопе.

Режим explicit означает, что модели не загружаются при старте, их подгружают по запросу.

Один сервер, много форматов: бэкенды Triton

Здесь есть неочевидный момент. Сам Triton модели не исполняет. Это общий сервер: он принимает запросы по единому API (HTTP и gRPC), ставит их в очередь, собирает в батчи, загружает и выгружает модели. А вычисления передаёт подключаемым модулям — бэкендам. Каждый бэкенд умеет исполнять свой формат моделей, и Triton всё равно, что именно внутри.

В Kylin стандартных бэкендов три, они лежат в /opt/tritonserver/backends:

• onnxruntime — модели в формате ONNX. Это большинство моделей системы: распознавание речи, OCR, CLIP, эмбеддинги, вырезание фона;

• python — код на Python, который не является нейросетью, но нужен вокруг неё. Например, извлечение признаков из звука перед распознаванием речи (asr_feature-extractor_*);

• llamacpp — большие языковые модели в формате GGUF.

llama.cpp, конечно, умеет работать и сам по себе, через свой llama-server. Но в Kylin он подключён к Triton как бэкенд (libtriton_llamacpp.so). Поэтому языковая модель доступна через тот же API, что и все остальные, загружается и выгружается так же, и приложениям не нужно знать, что за ней стоит отдельный движок.

Кроме стандартных, для Kylin написали несколько собственных бэкендов. Они лежат прямо в каталогах моделей: ocr (libtriton_ocr.so) выполняет весь цикл распознавания текста, sam — сегментацию, tokenizer — разбиение текста на токены для моделей эмбеддингов, model_bank — выбор модели по умолчанию для каждой задачи. Тип бэкенда задаётся в config.pbtxt каждой модели одной строкой, например backend: "python" или platform: "onnxruntime_onnx".

Модели можно собирать в цепочки. Например, ensemble-asr_paraformer_nonstreaming описан как ансамбль: звук сначала идёт в извлечение признаков на Python, затем в кодировщик на ONNX, затем в декодер. Приложение отправляет один запрос с аудио и получает готовый текст, а промежуточные шаги на разных бэкендах выполняет Triton. Так же устроен OCR: бэкенд ocr получает картинку, сам вызывает модели поиска текста и распознавания и возвращает JSON с результатом.

Каждый формат имеет свою нишу:

• ONNX — общий формат обмена моделями. Модели, обученные в PyTorch или PaddlePaddle (как PP-OCR), экспортируются в ONNX и исполняются одинаково. Многие модели в Kylin при этом сжаты до 8-битных целых (QUInt8 в именах файлов), чтобы быстрее работать на CPU;

• GGUF и llama.cpp — стандарт для языковых моделей на пользовательских машинах. Там хорошо развито сжатие весов, а главное, у llama.cpp много аппаратных бэкендов: CPU с разными наборами инструкций, CUDA, HIP, SYCL и PONN для китайских ускорителей. Отдельный формат для LLM здесь проще, чем пытаться исполнять их через ONNX;

• Python — для подготовки и пост-обработки данных, где писать нейросеть не нужно, а библиотеки (kaldifeat, jieba) уже есть на Python.

Такая архитектура хорошо подходит для ОС, которая заявляет поддержку многих производителей ускорителей. Чтобы добавить новый формат модели или новое железо, достаточно добавить бэкенд, а приложения и API останутся прежними. У Triton есть готовые бэкенды и для других форматов (TensorRT, OpenVINO, PyTorch), в Kylin их сейчас нет, но подключаются они так же. Модели в систему тоже приходят обычными deb-пакетами: в каталоге каждой модели лежит model_description.yaml с именем пакета и описанием возможностей модели.

Каталог моделей оформлен по всем правилам Triton (config.pbtxt и версия 1/), а в некоторых конфигурациях сохранились копирайты NVIDIA из примеров:

$ ls /usr/share/kylin-ai/model-repository
asr_encoder_streaming          embd_cn-clip_512-uint8-image   ocr_ppocr-det     seg_sam-encoder
asr_decoder_streaming          embd_cn-clip_512-uint8-text    ocr_ppocr-rec     seg_sam-decoder
asr_fsmn-vad_streaming         embd_gte-base_uint8-text       matting_portrait  tts_melo
ensemble-asr_paraformer_*      punc_ct-transformer_*          matting_universal tokenizer_*

Всего 1,8 ГБ моделей и ещё 1,2 ГБ Python-окружения (kylin-ai-python-env: PyTorch 2.8 для CPU, kaldifeat, jieba, g2p_en, PyMuPDF, python-docx…). Конфигурации вполне настоящие, например ASR рассчитан на потоковый батчинг:

name: "asr_encoder_streaming"
backend: "onnxruntime"
max_batch_size: 128
sequence_batching { oldest { max_candidate_sequences: 1024
                             preferred_batch_size: [32, 64, 128] } }

Это настройки потокового батчинга: до 1024 одновременных последовательностей и батчи по 32–128 запросов. Заголовки этих файлов содержат копирайт NVIDIA 2021 года, то есть конфигурации основаны на примерах из экосистемы Triton.

Локальная LLM

Пакет kytensor-llm — это llama.cpp («Inference of Meta’s LLaMA model (and others) in pure C/C++») с полным набором бэкендов ggml:

libggml-cpu-{sse42,sandybridge,haswell,skylakex,icelake,alderlake,sapphirerapids}.so
libggml-cuda.so  libggml-hip.so  libggml-sycl.so  libggml-ponn.so  libllama.so

Кроме ожидаемых CUDA (NVIDIA), HIP (AMD) и SYCL (Intel) есть ggml-ponn, бэкенд из пакета gf-arise-llama-ponn. Судя по имени, он предназначен для китайских GPU серии Glenfly Arise. Это и есть то «гетерогенное планирование CPU/GPU/NPU» из пресс-релизов.

Какая именно модель ожидается, подсказывает каталог model_bank. В default_model.yaml указано llm: llm_Qwen-2.5-3b_1.0, а modeldevicebinding.json привязывает модели llm_* к NPU HOUMO.AI M50 и LQ50 (Houmo AI, китайский разработчик ускорителей). То есть штатный сценарий — Qwen 2.5 на 3B параметров на китайском NPU. В списке поддерживаемых ИИ-ускорителей в документации есть Glenfly, Houmo AI, Moore Threads, Ascend, Iluvatar, MetaX, Hygon, а также Intel, AMD и NVIDIA. Для ИИ-подсистемы рекомендуют держать свободными 6 ГБ на диске.

Ещё любопытнее зависимость kytensor-llm → tongyi-decrypt («通义大模型解密工具», «утилита расшифровки больших моделей Tongyi»). В пакете есть libtongyi_decrypt.so, libiot_sam.so и каталог /usr/share/tongyi_decrypt_sam/ с файлами .security/.dev_key и sst/*.itg. Получается, что локальные модели Qwen (Tongyi Qianwen от Alibaba) поставляются в зашифрованном виде и расшифровываются на устройстве. При этом в установленной системе нет ни одного файла .gguf: сама LLM в образ не входит, её докачивают отдельно.

Облачные движки

Без локальной модели ассистент работает через облако. В /usr/lib/x86_64-linux-gnu/kylin-ai/plugins/ai-engines/ лежат плагины, и строки в них сразу показывают, куда уходят запросы:

libfreetrial-engine-plugin.so  → https://aicloud.cloud.kylinos.cn
libdeepseek-engine-plugin.so   → https://api.deepseek.com/chat/completions
libqwen-engine-plugin.so       → https://dashscope.aliyuncs.com/compatible-mode/v1/chat/completions
libbaidu-engine-plugin.so      → https://aip.baidubce.com/…/wenxinworkshop/chat/completions_pro
                                 https://aip.baidubce.com/…/ernievilg/v1/txt2imgv2
                                 https://tsn.baidu.com/text2audio
libxunfei-engine-plugin.so     → https://spark-api.cn-huabei-1.xf-yun.com/…
libcustom-engine-plugin.so     → (адрес задаёт пользователь, OpenAI-совместимый API)

«Пробные» модели DeepSeek-R1, DeepSeek-V3 и Qwen-Plus оформлены как отдельные deb-пакеты, но внутри у каждого по одному JSON-файлу с описанием возможностей:

{
  "display_name": "深度求索（DeepSeek-R1-试用版）",
  "model_name": "deepseek-r1",
  "max_tokens": 64000,
  "supports_web_search": true,
  "supports_thinking": true,
  "supports_tool_choice": true
}

Эти модели работают через прокси самого Kylin (aicloud.cloud.kylinos.cn).

RAG и база знаний

Набор пользовательских служб (systemctl --user) превращает всё это в персональный RAG:

• kylin-ai-vector-engine — «Lightweight Vector Database Based on Milvus». Бинарник собран с OpenBLAS, TBB и gRPC, хранилище шифруется через SQLCipher, лимит 400 000 векторов;

• kylin-ai-knowledgebase-service и kylin-ai-document-qa-service — индексация документов и ответы по ним;

• kylin-ai-document-service — парсинг документов на Python;

• kyai-data-management-service — управление данными.

Системные промпты лежат открытым текстом в /usr/share/kylin-ai/kylin-ai-knowledgebase-service/prompts/. Основной требует отвечать строго по найденным фрагментам и ставить ссылки в формате <Source>X</Source>, а после каждого ответа самому оценивать, «можно ли на него опираться». Есть и отраслевые варианты промптов: field_government_enterprise_system, field_legal_system, field_medical_system, field_financial_system — сразу видно, на какого заказчика рассчитана система.

Наконец, пакет share-kytensor с пятью службами (agent, apiserver, scheduler, networking, occli) судя по названиям служб, реализует «совместное использование вычислительных мощностей» из анонса, когда машины в сети отдают друг другу инференс. По умолчанию все эти службы выключены.

Если собрать всё вместе, получится такая цепочка. Приложения (ИИ-ассистент, AI Memory Map, «Просмотр фото» с вырезанием фона) обращаются к ИИ через библиотеки SDK libkysdk-coreai и libkyai-assistant и через службы kylin-ai-runtime на D-Bus. Дальше запрос уходит либо к локальным моделям через сервер kytensor, либо к облачной модели через один из плагинов в kylin-ai/plugins/ai-engines. Что выбрать, локальную модель, облачную или собственный сервер, согласно документации, задаётся приоритетом в настройках ИИ-подсистемы.

Собственные модели есть и у WPS Office, он приносит их в формате TensorFlow Lite: text_detect.tflite, page_ocr_model.tflite, angledetectionmodel.tflite, quardscanner.tflite, pic_recommend_model.tflite. Получается, что в одной системе работают три ИИ-движка: ONNX Runtime и llama.cpp под управлением Triton и TFLite внутри WPS.

Проверяем нейросети в деле

Описание стека — это хорошо, но как всё это работает? Сервер kytensor слушает стандартный Triton API на 127.0.0.1:8000 (HTTP) и 127.0.0.1:8001 (gRPC), то есть доступен только локально. Для разработчиков это удобно: модели ОС можно вызывать из своих программ обычным клиентом Triton, не дожидаясь SDK:

$ curl -s localhost:8000/v2
{"name":"triton","version":"2.49.0","extensions":["classification","sequence","model_repository",...]}

Python-клиент tritonclient уже лежит в kylin-ai-python-env, только без HTTP-части (не хватает gevent), поэтому работаем через gRPC. Модели загружаются явно (model-control-mode=explicit):

import tritonclient.grpc as th
c = th.InferenceServerClient("127.0.0.1:8001")
c.load_model("ensemble-tts_melo")

Все замеры ниже сделаны на виртуальной машине с 4 vCPU и без GPU, то есть в худших для инференса условиях. Где это имело смысл, мы проверяли модели на китайском, английском и русском. Забегая вперёд: по-китайски почти всё работает отлично, на других языках — по-разному.

Синтез и распознавание речи

MeloTTS в варианте ZH_MIX_EN (китайский с вкраплениями английского, 44,1 кГц) синтезирует речь быстрее реального времени: RTF 0,26–0,35, то есть 5 секунд аудио за 1,5 секунды.

Пять китайских фраз мы прогнали через цепочку «TTS → ASR → пунктуация». Три вернулись практически дословно: длинная фраза с датой и временем (请在明天上午九点半之前提交二零二六年第三季度的财务报告。), прогноз погоды с числами и фраза о функциях ИИ-ассистента, в которой пропал только знак перечисления «、». В двух фразах ASR ошибся: «原子更新» (атомарное обновление) превратилось в «两次更新» (два обновления), а «V11» посреди китайской фразы — в mi@@ss一.

Paraformer распознаёт 5 секунд речи за 0,12–0,24 секунды. Модель пунктуации CT-Transformer расставляет запятые и точки за 2–4 мс и не ошиблась ни разу.

С другими языками картина иная. Мы подали на вход английскую и русскую речь из Windows SAPI (голоса Zira и Irina):

EN «Hello! This is a speech recognition test for the Kylin operating system.»
→ hel@@lothisisaspe@@e@@chre@@co@@g@@ni@@tiontestforthec@@y@@ando@@per@@atingsy@@ste@@m

RU «Привет! Это проверка распознавания речи в операционной системе Кайлин.»
→ pri@@v@@atethatpre@@vi@@ousc@@arswasneverne@@ar@@lytovi@@pe@@o@@tsonasy@@ste@@m@@ic@@a@@ali@@en

Английский узнаваем, но выдаётся сырыми BPE-токенами с маркерами @@, которые никто не склеил. Русский модель честно пытается записать латиницей как английский. Пунктуация на английском тоже показательна: hello，thisisatestofthekylinoperatingsystem。howareyou？. Знаки препинания стоят на месте, но китайские, а пробелы между словами пропали.

OCR

PP-OCR оформлен как собственный бэкенд Triton ocr, который сам вызывает модели ocr_ppocr-det и ocr_ppocr-rec. Важная деталь: если не загрузить их явно, бэкенд молча возвращает пустой список [] без ошибки. На вход подаётся массив H×W×3 в порядке BGR, на выходе JSON с полигонами, текстом и уверенностью. Скриншот всего экрана 1280×800 распознаётся за 0,5–0,6 секунды.

На китайском официальном документе (типичный сценарий для госсектора) результат идеален: все шесть строк, включая 〇 в дате и полноширинные скобки, распознаны с уверенностью 0,95–1,00. А вот поворот того же скана всего на 2° всё ломает:

Видна и причина. Бэкенд ocr в Kylin возвращает строго горизонтальные прямоугольники: у всех найденных строк на наклонном скане координаты углов попарно совпадают по осям. При наклоне в рамку попадает половина строки с куском соседней, и распознаватель уверенно, с оценкой 0,95+, выдаёт «平工织告《信自技术应用创新产品白求》时迪» вместо «关于印发《信息技术应用创新产品目录》的通知». Вывод практический: перед распознаванием сканов изображение стоит выравнивать.

Скриншоты интерфейса распознаются хорошо, в том числе смешанный китайско-английский текст в Магазине программ: «百度搭子（DuMate）是基于千帆大模型平», «国内首款支持国产操作系统和处理器的CAD设计软件» — с уверенностью 1,00.

С кириллицей всё предсказуемо. Словарь модели содержит 18 385 символов (китайские иероглифы, латиница, греческий), но русских букв в нём нет. Поэтому строку «Привет, Хабр! Проверка OCR» модель прочитала как ΠpnBeT, Xa6p! ΠpoBepka OCR: П стала греческой Π, «и» — латинской n, «б» — цифрой 6. Уверенность при этом 0,94.

Эмбеддинги: GTE и CN-CLIP

Мультиязычная модель GTE оказалась самой «интернациональной» в наборе. Матрица косинусной близости для вопросов на трёх языках:

Вопрос об обновлении ОС на китайском, английском и русском даёт близость 0,89–0,92, а с вопросом о погоде и рецептом борща — 0,35–0,46. Так что поиск по базе знаний (kylin-ai-knowledgebase-service) должен работать и с русскими документами, хотя сам ассистент рассчитан на китайский.

CLIP (Contrastive Language–Image Pre-training) — модель OpenAI, которая переводит и картинки, и текстовые описания в векторы одного пространства. Если картинка и подпись подходят друг другу, их векторы близки. CN-CLIP — версия этой модели от Alibaba, обученная на китайских парах «изображение — подпись», поэтому подписи для неё пишем по-китайски. В Kylin модель состоит из двух частей: кодировщик изображений embd_cn-clip_512-uint8-image и кодировщик текста ensemble-embd_cn-clip_512-uint8-text. На такой основе строится поиск картинок по текстовому описанию, например «найди фото с лошадью».

Мы проверили так называемую zero-shot классификацию: модель заранее ничему не учили на наших классах, а просто дали ей картинку и список подписей («лошадь», «подсолнух», «поверхность Марса», «скриншот» и т. д.), посчитали близость картинки к каждой подписи и выбрали самую близкую. Проценты — это близость, пересчитанная в вероятность по всем вариантам из списка. На обоях из /usr/share/backgrounds модель ответила уверенно и правильно, примерно за 0,1 с на изображение:

horse.jpg          → 一匹马 (лошадь)            94 %
sunflower.jpg      → 向日葵 (подсолнух)         99,8 %
mars.jpg           → 火星表面 (поверхность Марса) 100 %
island.jpg         → 海岛和大海 (остров и море)   99,8 %
shot-security.png  → 电脑屏幕截图 (скриншот)      100 %
hummingbird.jpg    → 一只蜂鸟 (колибри)          99,9 %

Последняя строка хорошо показывает ограничение такого подхода: модель выбирает только из предложенных вариантов. На обоях с именем hummingbird.jpg на самом деле зимородок. Пока этого варианта не было в списке, модель уверенно выбирала колибри, самую похожую из доступных подписей. Когда мы добавили метку «一只翠鸟» (зимородок), ответ разделился 54 / 46 в пользу колибри.

Вырезание фона

Модели matting используются в «Просмотре фото». matting_universal (вход 1024×1024) справилась с обеими фотографиями чисто, включая усы лошади и ветку под зимородком, но на CPU думает около 10 секунд на кадр. matting_portrait (512×512, обучена на людях) работает за 0,1–0,2 с, но на морде лошади объект частично «растворился»:

Сколько памяти нужно

Все модели, которые мы проверили выше (синтез и распознавание речи, пунктуация, OCR, эмбеддинги GTE и CN-CLIP, две модели вырезания фона), загруженные одновременно, заняли в памяти всего 4,7 ГБ (процесс kytensor). Это хороший результат: даже на машине с 8 ГБ памяти, как наша виртуальная машина, все они работали вместе с рабочим столом. Без загруженных моделей сервер занимает около 600 МБ. Режим model-control-mode=explicit подгружает модель, только когда она нужна какой-то функции, и выгружает через POST /v2/repository/models/<name>/unload, так что в обычной работе памяти уходит ещё меньше.

На чём написаны встроенные программы

Мы прошли по всем видимым ярлыкам в /usr/share/applications и в экспортах Kaiming и классифицировали исполняемые файлы по ldd и строкам в бинарниках. Скрипт простой: смотрим, с какими GUI-библиотеками связан ELF.

case "$(ldd "$bin")" in
  *libQt6Widgets*) tk=Qt6 ;;
  *libQt5Gui*)     tk=Qt5 ;;   # + отдельно libQt5Qml/Quick
  *libgtk-3*)      tk=GTK3 ;;
esac

Результат:

• Qt5 Widgets — основа всего фирменного: Центр безопасности, Магазин программ, Kylin OS Manager, резервное копирование (kybackup), системный монитор, скриншоты, журнал, менеджер биометрии, установщик пакетов;

• Qt5 + QML — файловый менеджер Peony, Настройки (ukui-control-center), поиск, просмотр фото, справка, а также ИИ-ассистент и AI Memory Map из пакетов Kaiming;

• GTK3 — наследие MATE: Pluma, MATE Terminal, Engrampa, а также FileZilla и GParted;

• Chromium — браузер Qi-An-Xin (奇安信可信浏览器), 352 МБ в формате Kaiming;

• Qt6 в поставке нет. Рабочий стол UKUI 4.20 и все фирменные программы собраны на Qt 5 (для разработчиков в SDK — Qt 5.15 и Qt Creator 6).

Обзор встроенных программ

Ниже кратко о каждой программе из меню. Описания составлены по запуску в системе и по встроенной справке: в Kylin есть приложение «Manual» (kylin-user-guide, 163 МБ) с отдельной статьёй на китайском и английском для каждой программы, а для части программ ещё и на тибетском.

Магазин, безопасность, обслуживание

Магазин программ (kylin-software-center). Через него ставятся нативные программы, Android-приложения (через окружение KMRE), Windows-программы (через KWRE) и драйверы. Есть разделы «AI Zone», «Efficient Office», «Industry-specific», вход через Kylin ID, проверка цифровой подписи пакетов и оценка качества адаптации. Для организаций без выхода в интернет есть частная версия магазина с веб-панелью администратора и собственным репозиторием.

Центр безопасности (ksc-defender) объединяет проверку безопасности, антивирус, защиту учётных записей (сложность пароля, блокировка после неудачных попыток, запрет удалённого входа root), межсетевой экран, исправление уязвимостей, приватность и «доверенное измерение» загрузки (TPM/TCM). В разделе «Инструменты» собраны контроль источника приложений, защита процессов от завершения, запрет выгрузки модулей ядра, защита файлов от изменения, контроль запуска программ, контроль внешних устройств и контроль сетевого доступа приложений. Антивирусный движок — Qi-An-Xin Endpoint Protection (пакет pksav 8.0.5).

Kylin OS Manager («麒麟管家») — оценка «здоровья системы», диагностика типовых проблем (сеть, приложения, оборудование), очистка мусора, менеджер устройств и набор утилит.

File Safe (box-manager, «文件保护箱») — защищённые каталоги-«сейфы» с изоляцией данных между пользователями на уровне ядра. Поддерживаются международные и китайские государственные криптоалгоритмы (国密) и аппаратное шифрование, схема «один сейф — один ключ, один документ — один ключ», ключи можно хранить в TPM. Сейфы автоматически блокируются при выходе из сеанса и блокировке экрана, а при удалении данные затираются. В нашей ВМ программа окна не открыла, описание дано по встроенной справке и документации.

Шифрование дисков (kylin-disk-encryption) — шифрование системного и несистемных разделов с сохранением данных. Разблокировка по паролю, TPM или TPM+PIN, сброс пароля по резервному ключу.

Отдельной строкой в состав входят модули DLP (kydlp-control): контроль копирования на USB-накопители, прожига дисков и печати, причём для печати предусмотрено распознавание текста отправляемых документов (kydlp-control-printer-ocr). Там же цифровые водяные знаки на экране (ukui-watermark) и запрет снимков экрана на уровне композитора.

Администрирование

• Kim-client (Kylin Identity Management) — ввод компьютера в домен: имя хоста и сервер на первом шаге, авторизация администратора на втором, есть «быстрый» и обычный режимы ввода. Службы kimdomain и kimcd держат связь с сервером, рядом стоят Kerberos и Samba. По всей видимости, это клиентская часть платформы централизованного управления «麒麟天御», которая, согласно документации, покрывает управление пользователями, устройствами, приложениями, политиками и аудитом.

• Резервное копирование (kybackup) — точки восстановления системы и данных, инкрементальные копии, восстановление с сохранением пользовательских данных, Ghost-образ и отдельный режим резервирования из меню GRUB. В V11 это дополняет механизм развёртываний ostree.

• Журнал (kylin-log-viewer) — единый просмотр журналов системы, загрузки, аутентификации, приложений, ядра, KySec, сбоев и аудита. Есть фильтры, поиск по подробностям, экспорт и настройка ротации, отдельно отслеживаются удалённые входы.

• Системный монитор — процессы, службы и диски, в V11 добавлена страница скоростей чтения и записи.

• Установщик пакетов (kylin-installer) — открывает deb по двойному щелчку и сам решает, ставить пакет в систему или в окружение совместимости KARE.

• Биометрия (biometric-manager) — регистрация отпечатков пальцев и других биометрических данных для входа, разблокировки и подтверждения прав. В списке драйверов есть устройства UPEK, AES4000, FDU2000. Согласно документации, поддерживаются лицо, отпечаток, рисунок вен, радужка и голос, а также вход по QR-коду WeChat и USB-ключу.

• Таймер выключения («Time Shutdown») — выключение по расписанию: однократно, по дням недели или ежедневно.

Рабочие программы

• Remmina — клиент удалённых рабочих столов (RDP, VNC, SSH). Согласно документации, в V11 и сам удалённый доступ к рабочему столу системы поддерживает протокол RDP, но это отдельный компонент, не Remmina.

• Принтер (kylin-printer) — установка USB- и сетевых принтеров, смена драйвера, пробная печать, уровень тонера, подключение принтеров с удалённого Samba-сервера. Согласно документации, в базе «десятки тысяч» моделей, драйвер подбирается и без интернета. В виртуальной машине окно отрисовывалось чёрным: это особенность виртуального видеоадаптера с полупрозрачными окнами, а не ОС.

• Запись экрана (kylin-screencap) — весь экран, область или окно, с микрофоном, выбором формата, качества и частоты кадров.

• Скриншоты (kylin-screenshot) — снимки с разметкой и горячими клавишами.

• Atril — просмотр PDF, DjVu, PostScript, XPS. Согласно документации, это штатный «просмотрщик документов».

• KolourPaint — простой графический редактор из KDE.

• Pluma, Engrampa, MATE Terminal, выбор цвета MATE — текстовый редактор, архиватор, терминал и пипетка/палитра из MATE.

• FileZilla, GParted — FTP/SFTP-клиент и редактор разделов.

• Sogou IME — основной китайский метод ввода (поверх fcitx5) с пиньинем, у-би и рукописным вводом. Его настройки вынесены отдельным ярлыком.

Приложения в формате Kaiming

Калькулятор (обычный и научный режимы), камера, музыкальный и видеоплеер, диктофон, часы с будильником, погода, заметки «Kylin Note» с быстрым вводом по горячей клавише, задачами и автоматическим недельным отчётом, прожиг дисков (данные, образы, копирование дисков), создание загрузочных флешек и «Messages» (kylin-ipmsg) — обмен сообщениями и файлами в локальной сети без сервера. Отдельно стоит AI Memory Map («记忆地图»): программа записывает действия пользователя и историю просмотра, после чего по ним можно искать по временной шкале и тексту, а также распознавать текст в выбранной области экрана. В нашей ВМ она не запустилась без ИИ-служб.

Сторонние программы в /opt/apps

• ExceedShare от CVTE (5.19) — беспроводная трансляция экрана на интерактивные панели, распространённые в китайских учреждениях и школах;

• драйвер ePass3000GM от Feitian — USB-ключи с китайской криптографией (SM2/SM3/SM4), используются для входа и электронной подписи;

• Qi-An-Xin Endpoint Protection — антивирусный движок Центра безопасности;

• Sogou IME — метод ввода, о нём выше.

Безопасность: KySec и KSAF

Последний слой — собственный модуль безопасности:

$ sudo getstatus
KySec status: enabled

exec control : warning
net control  : off
file protect : on
kmod protect : on
three admin  : off
process protect: on
device control: on
kid protect  : on
program blklist: on

$ cat /sys/kernel/security/lsm
lockdown,capability,kycp,ksaf,bpf

В ядре два собственных LSM, kycp и ksaf. Контроль запуска (exec control) основан на расширенных атрибутах: у каждого исполняемого файла в системе есть свои метки:

$ getfattr -d -m security /usr/bin/ls
security.exectl=0sCE+NaQAAAAAAAAAAAAAAAA==
security.ksaf=0s2QBYF2jkdxbZAFgXaOR3FgAAAAAAAAAABQAAAAQ=

В режиме warning неподписанный бинарник запускается, но пользователь получает предупреждение. В режиме normal запуск блокируется. Опция three admin включает разделение ролей между тремя администраторами (системный, безопасности и аудита), привычное по требованиям к защищённым ОС.

Документация описывает архитектуру подробнее. KSAF (Kylin Security Architecture Framework) — программируемый фреймворк из пяти уровней: исполнение, принятие решений, язык политик, определение и взаимодействие. Политики пишутся на собственном языке KSL (Kylin Security Language) с вставками на C и Python и подгружаются динамически. Фреймворк различает субъектов в контейнерах, песочницах и скриптах и разбирает поведение интерпретируемых скриптов прямо в ядре. Поверх него построен KYSEC 2.0. К этому добавляются доверенная загрузка с поэтапным измерением (TPM/TCM, Zhaoxin, Hygon, Phytium), двухфакторная аутентификация (пароль плюс OTP или USB-ключ) и заявленные сертификации по коммерческой криптографии (商密), классам защиты (等保) и отраслевым стандартам.

Выводы

По архитектуре Kylin V11 заметно отличается от привычных дистрибутивов. Неизменяемое ядро на ostree с атомарными обновлениями и откатом, два окружения приложений (KARE для совместимости, Kaiming для изоляции), программируемая модель безопасности KSAF, полноценный стек ИИ (Triton, llama.cpp, векторная БД, RAG). Всё это в системе, которую разворачивают в госучреждениях, вместе с инфраструктурой для них: доменом, частным магазином, управляемыми обновлениями, DLP.

Для администратора, пришедшего с Debian, главное отличие — несколько уровней системы. Привычные apt и systemctl работают в окружении совместимости, ядро системы меняется только через ostree и режим обслуживания. Нужно знать, в каком пространстве имён ты находишься, и всё становится логичным.

Образ, на котором проводился разбор: Kylin-Desktop-V11-2603-Release-Update1-20260818-X86_64, сборка 83681, ядро 6.6.0-76. Официальная документация, на которую мы ссылаемся (белая книга, примечания к выпуску, FAQ): страница V11 на kylinos.cn, портал разработчика. Другие источники: заметка об ostree в V11 2603 на SegmentFault, The Register о выходе KylinOS 11, CNR о выходе V11.