Хотел нормальный fractional scaling, а собрал KDE 6.7 для РЕД ОС

Некоторое время назад я решил обновить KDE на своем ноутбуке.

Причина была довольно банальной. В ноутбуке установлен 14-дюймовый Full HD экран, для которого масштаб 100% слишком мелкий, а 200% — слишком крупный. В KDE Plasma 5 под X11 дробное масштабирование в целом работало, но хотелось нормально перейти на Wayland, где в старой версии KDE с fractional scaling всё было несколько менее радужно.

Кроме того, KDE 5.27, несмотря на LTS-статус и вполне приличную стабильность, к 2026 году уже начал ощущаться немного устаревшим. KDE 6 существует далеко не первый год, Wayland постепенно превратился из экспериментальной опции в основной сценарий работы, а я всё ещё сидел на Plasma 5.

На ноутбуке при этом была установлена РЕД ОС 8.

Самое очевидное решение проблемы — поставить Fedora, Альт Линукс или какой-нибудь другой более ориентированный на десктоп дистрибутив, где современный KDE уже есть в штатных репозиториях.

Но это было бы слишком просто.

Поэтому я решил собрать KDE 6 самостоятельно.

В результате небольшая задача «обновить графическую оболочку на ноутбуке» постепенно превратилась почти в 500 исходных пакетов, собственный RPM-репозиторий, несколько тестовых виртуальных машин, довольно много потраченных токенов LLM и некоторое понимание того, почему работа мейнтейнера Linux-дистрибутива сложнее, чем кажется со стороны.

Об этом процессе я и хочу рассказать.

Почему РЕД ОС?

Тут, пожалуй, стоит сразу сделать небольшую оговорку.

Я не работаю в РЕД Софт и никак не связан с компанией, поэтому всё написанное дальше — исключительно мой личный взгляд и опыт использования РЕД ОС. В целом я отношусь к дистрибутиву нейтрально: у него есть свои сильные стороны и особенности, а для меня он в первую очередь стал интересной площадкой для экспериментов.

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

РЕД ОС интересна мне по другим причинам.

Во-первых, мне вообще интересно экспериментировать с российскими Linux-дистрибутивами и смотреть, что у них находится внутри.

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

Можно было просто дождаться KDE 6 в официальных репозиториях. Но разработчики коммерческого дистрибутива в первую очередь решают задачи своих заказчиков, а свежесть рабочего стола случайного домашнего пользователя совершенно необязательно находится наверху списка их приоритетов. Поэтому ждать можно было достаточно долго.

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

Почему бы не попробовать?

Кроме практического результата у затеи было несколько побочных целей. Мне хотелось разобраться, как собирается большой набор взаимозависимых RPM-пакетов, как устроены репозитории, что происходит при обновлении одной большой версии графического окружения на другую и насколько современные LLM способны помочь человеку, который никогда профессионально не сопровождал Linux-дистрибутив.

Что именно будем собирать?

Первоначальный план был достаточно скромный: собрать KDE Frameworks 6 и Plasma 6.

Если получится — добавить сверху столько приложений из KDE Gear, сколько удастся без чрезмерного вмешательства в базовую систему.

При этом я сразу определил для себя важное ограничение: хотелось обновить именно KDE, а не постепенно превратить РЕД ОС 8 в Fedora.

Современное графическое окружение зависит от Qt, мультимедийного стека, системных библиотек, сервисов, Python-модулей и большого количества вспомогательных инструментов.

Самый простой способ получить свежий KDE на старой системе — начать обновлять вслед за ним всё подряд. Но тогда довольно быстро возникает вопрос: а что, собственно, осталось от исходного дистрибутива?

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

Пять дополнительных пакетов можно почти не заметить. Пятьдесят или сто — и получается уже маленький собственный дистрибутив.

А мои детские силы всё-таки не безграничны.

Поэтому одна из основных целей выглядела так:

получить максимально свежий KDE Plasma 6 на РЕД ОС 8, пересобрав минимально возможное количество системных пакетов.

Где возможно — использовать библиотеку из дистрибутива.

Если KDE требует более свежий API — попробовать backport или небольшой патч.

Если новая зависимость нужна только для второстепенной функции — подумать, нельзя ли эту функцию отключить.

И только если разумных вариантов не осталось — обновлять системный компонент.

Именно так из моей сборки, например, выпал DrKonqi. Ради средства отправки отчётов о падениях мне совершенно не хотелось тащить новый systemd и связанные с ним изменения.

DrKonqi — вещь полезная.

Но не настолько.

Вторая важная задача состояла в том, чтобы KDE можно было не только установить с нуля, но и обновить с существующей Plasma 5.27.

Как выяснилось позже, «KDE устанавливается с нуля» и «существующая KDE 5 нормально обновляется до KDE 6» — довольно разные задачи.

А сколько пакетов в KDE?

Когда говоришь «собрать KDE», это звучит примерно как «собрать программу из исходников».

Скачиваем исходники, запускаем что-нибудь вроде:

cmake
make
make install

и через некоторое время получаем KDE.

До начала проекта я представлял масштаб примерно так же.

На самом деле KDE — это не один проект. Есть Qt, KDE Frameworks, Plasma, KDE Gear и множество библиотек и вспомогательных компонентов, у каждого из которых свои зависимости и цикл сборки.

В RPM-дистрибутиве добавляется ещё один уровень.

Для сборки нужен SPEC-файл, где описаны исходники, BuildRequires, патчи, команды сборки и то, на какие бинарные пакеты должен разделиться результат.

Причём один исходный пакет вовсе не обязан соответствовать одному RPM.

К концу эксперимента мой репозиторий выглядел примерно так:

То есть «собрать KDE» в моём случае означало почти пять сотен исходных компонентов и около 1800 RPM-файлов.

Причём их ещё нужно собрать в правильном порядке.

Нельзя собрать компонент, пока отсутствуют его BuildRequires. А нужный BuildRequires сам может зависеть от третьего пакета. Есть циклы, опциональные зависимости и разные способы разбиения одного проекта на подпакеты.

В этот момент стало понятно две вещи.

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

Во-вторых, если я всё-таки когда-нибудь это закончу, возможно, готовая сборка будет интересна не только мне.

Fedora как донор SPEC-файлов

Писать пять сотен SPEC-файлов с нуля я, разумеется, не собирался.

Вопрос «какой дистрибутив взять за основу?» я, как и многие другие в процессе работы, задал ChatGPT.

Fedora выглядела логично: это RPM-дистрибутив со свежими KDE и Qt, а SPEC-файлы находятся в открытом доступе. Кроме того, Fedora обычно достаточно близка к upstream и уже содержит необходимые патчи и решения для сборки конкретных версий программ.

Аргументы показались здравыми, поэтому Fedora стала основным донором.

Подавляющее большинство SPEC-файлов в итоге — Fedora SPEC, адаптированные под РЕД ОС 8. Лишь для нескольких вспомогательных пакетов их пришлось писать практически с нуля.

При этом собственно KDE в большинстве случаев адаптировался не так уж тяжело.

Проблемы чаще начинались вокруг него.

Свежая Fedora может использовать библиотеку или инструмент сборки, которых в РЕД ОС 8 просто нет. Тогда приходится выбирать: обновить зависимость, научить пакет работать со старой версией или отказаться от необязательной функции.

Иногда достаточно патча. Иногда — выключенной опции CMake. Иногда проще жить без конкретной функции.

А иногда одна новая зависимость требует ещё три, и вот уже принцип «минимум изменений базовой системы» перестаёт быть эстетическим предпочтением.

А давайте просто отдадим всё Codex

К этому моменту у меня был набор SPEC-файлов, примерное понимание задачи и доступ к современным coding agents.

Возникла очевидная мысль:

Вот РЕД ОС 8, вот SPEC-файлы Fedora, вот список компонентов KDE. Собери всё это.

Первые результаты выглядели на удивление обнадёживающе.

Codex анализировал SPEC-файлы, находил зависимости, менял версии, добавлял патчи и постепенно двигал сборку вперёд.

Для человека, который раньше практически не занимался RPM packaging, это производит сильное впечатление. В какой-то момент начинает казаться, что теперь можно просто иногда проверять результат, а всё остальное компьютер сделает сам.

Как обычно, именно в этот момент начинаются проблемы.

Первые длительные автономные сборки я запускал на Sol — самой дорогой и сильной из доступных мне моделей. Логика была простой: задача сложная, значит надо взять максимально сильную модель и дать ей побольше самостоятельности.

Позже выяснилось, что обе части этого предположения были спорными.

Большая часть цикла выглядит так: запустить сборку, дождаться ошибки, посмотреть лог, поправить SPEC или патч, повторить.

Максимальные возможности модели нужны далеко не на каждом шаге.

На момент написания статьи порядок цен был таким:

Terra примерно в десять раз дороже Luna, а Sol — ещё примерно в два раза дороже Terra.

При сопоставимом количестве токенов одна итерация на Sol выходит примерно как 17–20 таких же итераций на Luna.

Разумеется, буквально считать «один Sol равен двадцати Luna» нельзя: сильная модель иногда решает задачу за один проход там, где дешёвой понадобится несколько.

Но порядок величин хорошо объясняет, почему гонять Sol на каждой упавшей сборке оказалось расточительно.

Потом у меня одновременно стали заканчиваться две вещи: токены и место на диске.

Часть работы пришлось восстанавливать.

Кроме того, длинные автономные сессии плохо контролируются. Агент может сделать двадцать правильных шагов, затем принять одно сомнительное решение и ещё какое-то время строить работу поверх него.

Поэтому постепенно я пришёл к противоположной схеме.

Основной моделью стала дешёвая Luna, которой я давал короткие задачи:

Вот пакет и лог сборки. Исправь ошибку.

Вот Fedora SPEC. Адаптируй его для РЕД ОС, не обновляя эту системную библиотеку.

Если Luna не справлялась — подключалась Terra.

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

В итоге LLM всё равно участвовала, наверное, процентов в 90 работы. Но вместо одной огромной задачи «собери мне KDE» получился поток коротких контролируемых итераций.

И это оказалось одновременно дешевле, предсказуемее и эффективнее.

От набора команд к сборочной системе

Даже если LLM отлично исправляет конкретный SPEC, кто-то всё равно должен помнить, что уже собрано и в каком порядке двигаться дальше.

У KDE не линейный список, а граф зависимостей.

Первый вариант графа тоже помог составить Codex, анализируя BuildRequires.

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

Но достаточно правильным, чтобы с него начать.

По мере работы находились скрытые зависимости, циклы и случаи, когда формально пакет уже можно собрать, но практически лучше сначала сделать что-нибудь ещё.

Параллельно появился отдельный скрипт сборки:

https://gitflic.ru/project/ebaranov/build-kde

Основой процесса стал mock.

Если сильно упрощать, mock создаёт чистое изолированное окружение, устанавливает туда BuildRequires пакета и выполняет сборку.

Для такой задачи это принципиально важно: пакет не должен собираться только потому, что на рабочей машине случайно установлена забытая зависимость.

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

Это уже больше походило на воспроизводимый процесс, чем на набор команд из истории shell.

Готовые RPM я отдельно подписываю GPG-ключом. Автоматизировать можно и это, но работу с приватным ключом мне комфортнее оставлять отдельным явно запускаемым шагом.

Добро пожаловать в dependency hell

Пока речь шла об отдельных пакетах, всё выглядело относительно просто.

Настоящее веселье начинается, когда их надо установить вместе.

Особенно поверх KDE 5.

В системе уже есть Plasma 5, KDE Frameworks 5, Qt, Python-модули и пакеты РЕД ОС, зависящие от частей старого стека.

А мы приходим с несколькими сотнями новых RPM и говорим dnf:

Сейчас мы всё аккуратно обновим.

dnf иногда предлагает довольно творческое понимание слова «аккуратно».

Новый пакет конфликтует со старым. Старый нужен третьему. Где-то поменялись Provides или Obsoletes, где-то Fedora и РЕД ОС по-разному разбили один проект на подпакеты.

Поэтому успешная сборка RPM ещё ничего не гарантирует.

Нужно отдельно посмотреть предварительный план транзакции.

На одном из этапов он выглядел так:

• Install: 443;

• Upgrade: 102;

• Remove: 11;

• Downgrade: 3.

Последнее особенно неприятно.

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

После разбора конфликтов KGlobalAccel, PyQt6 и нескольких других зависимостей финальный вариант выглядел уже так:

• Install: 443;

• Upgrade: 107;

• Remove: 9;

• Downgrade: 0.

Одним из показательных случаев стал KGlobalAccel.

В KDE 5 это не только библиотеки, но и отдельный сервис глобальных горячих клавиш. В Plasma 6 архитектура этой части изменилась, однако старые KF5-библиотеки всё ещё нужны некоторым KDE 5-приложениям.

Удалить старый пакет целиком оказалось плохой идеей.

Пришлось оставить совместимые библиотеки и убрать только конфликтующую часть.

Похожая история возникла с PyQt6 и связанными с ним sip и builder.

Именно здесь я начал лучше понимать одну неприятную особенность работы мейнтейнера:

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

Собралось. А обновляется?

Когда решатель зависимостей перестал предлагать очевидно разрушительные варианты, возникло желание считать задачу почти законченной.

Но оставалось тестирование.

Самый простой сценарий — чистая виртуальная машина с РЕД ОС.

Тут обнаружилась ещё одна небольшая особенность: в варианте Minimal Install устанавливается довольно много пакетов, которые я в минимальной системе увидеть не ожидал.

Для обычного пользователя это, возможно, неважно, но для тестового стенда лишние компоненты мешают понимать, какая зависимость действительно пришла из моего репозитория.

Поэтому появился небольшой скрипт очистки:

https://gitflic.ru/project/ebaranov/redos-minimal-cleanup

Но даже чистая VM ещё не означает чистый эксперимент.

Изначально я по привычке использовал VirtualBox. Для обычных тестов этого хватало, но с Wayland начались странности: сессия вела себя нестабильно, графические эффекты работали непредсказуемо, и было сложно понять, проблема в моей сборке KDE или виртуальном GPU.

На выяснение этого ушло заметно больше времени, чем хотелось бы.

В какой-то момент стало понятно, что VirtualBox добавляет слишком много неопределённости.

Тестовые машины я перенёс на virt-manager/KVM. После этого Wayland стал вести себя заметно предсказуемее.

Но даже идеально работающая чистая установка почти ничего не говорит о моей основной задаче.

Настоящим тестом был сценарий:

РЕД ОС 8 + KDE 5.27 → обновление → KDE 6.7.

На чистой системе старого пакета просто нет. При обновлении он может конфликтовать с новым.

При чистой установке создаётся свежая конфигурация. После миграции приложение получает настройки от предыдущей версии.

Поэтому пришлось поддерживать два сценария: чистую установку KDE 6 и миграцию с KDE 5.27.

Виртуальную машину для миграции удобнее было не чинить после каждого эксперимента, а откатывать к снапшоту и повторять обновление заново.

Получился своеобразный интеграционный тест длиной в несколько сотен пакетов.

Каждый баг становится тестом

Дальше проект развивался по знакомой схеме:

нашёл баг → исправил → проверил → через несколько дней чем-нибудь снова сломал.

После пары таких случаев становится понятно, зачем придумали регрессионное тестирование.

Проблема в том, что графическое окружение неудобно тестировать целиком автоматически.

Проверить установку пакета, запуск сервиса, наличие файлов или AppStream metadata сравнительно просто.

Но как автоматически проверить, что Alt+Tab показывает нормальный переключатель окон? Что Meta открывает меню? Что Spectacle действительно записывает видео? Что после подключения флешки появляется правильное уведомление?

В итоге часть проверок выполнялась автоматически, часть — руками на виртуальной машине, а некоторые имели смысл только на реальном ноутбуке.

Постепенно появился простой принцип:

Каждый найденный баг должен добавить хотя бы одну проверку в следующий прогон.

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

Виртуальная машина — это ещё не ноутбук

В какой-то момент виртуальные машины стали выглядеть достаточно убедительно: Plasma запускалась, Wayland работал, приложения устанавливались, миграция проходила.

Наступил момент, ради которого всё и затевалось.

Я сделал свежий backup и обновил настоящий ноутбук.

И окончательно понял, почему тестировать графическое окружение только в виртуалках несколько оптимистично.

На реальном железе появляется настоящий GPU, экран с дробным масштабированием, Wi-Fi, Bluetooth, suspend и приложения, которыми действительно пользуешься каждый день.

Главная цель проекта, к счастью, сработала.

Wayland на KDE 6.7 с масштабом 125% на моём 14-дюймовом Full HD экране работает заметно лучше старого варианта.

Именно ради этого всё и начиналось.

После миграции обнаружились некоторые мелкие проблемы — например, пришлось повторно ввести часть Wi-Fi-паролей, а экран блокировки иногда появлялся во время активной работы.

Ничего критического.

Но такие вещи хорошо напоминают, что десктоп проверяется не только командами.

Им ещё приходится пользоваться.

И тут РЕД Софт выпустил KDE 6

Есть ситуации, которые почти обязаны произойти, если проект длится достаточно долго.

Ты несколько недель собираешь сотни пакетов, чинишь зависимости, пишешь скрипты, гоняешь миграции, наконец устанавливаешь результат на настоящий ноутбук.

И примерно в этот момент РЕД Софт выпускает собственный KDE 6.

Первая реакция была примерно:

Ну замечательно.

Некоторое время я думал, что довольно успешно потратил несколько недель на работу, которую параллельно сделали люди, профессионально занимающиеся этим дистрибутивом.

Потом посмотрел внимательнее и немного успокоился: официальная сборка оказалась заметно старее моей.

Кроме того, к тому моменту готовый KDE был уже только частью результата.

Я успел гораздо глубже разобраться с RPM packaging, mock, dependency solver, воспроизводимыми сборками, тестированием миграций и поведением coding agents на большой долгоживущей задаче.

Ну и мой KDE всё-таки был свежее.

Так что можно было продолжать.

Раз уж собрал — сделаем репозиторий

Когда RPM стало несколько сотен, передавать их между машинами через что-нибудь вроде scp *.rpm перестало выглядеть разумно.

Так появился обычный RPM-репозиторий:

https://pkgrepo.ru/redos-kde67/

RPM подписаны GPG-ключом, repomd.xml тоже подписан, репозиторий отдаётся через nginx по HTTPS, исходные RPM доступны рядом с бинарными.

SPEC-файлы:

https://gitflic.ru/project/ebaranov/redos-kde67-specs

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

Система сборки:

https://gitflic.ru/project/ebaranov/build-kde

Для простого статического RPM-репозитория никакой особой тяжёлой инфраструктуры не понадобилось.

Иногда nginx, createrepo_c и немного shell — всё, что требуется.

Что в итоге получилось

На момент написания статьи основной стек выглядит так:

• Qt 6.10;

• KDE Frameworks 6.28;

• Plasma 6.7.4;

• KDE Gear 26.04.3.

Не всё из экосистемы KDE удалось или имело смысл собирать.

От некоторых компонентов я сознательно отказался, в отдельных программах отключил необязательные функции, если ради них требовалось слишком сильно менять базовую систему.

Но основная рабочая среда получилась.

Более того, я действительно использую её на ноутбуке каждый день.

При этом называть проект production ready я бы не стал.

Его состояние где-то между:

интересный эксперимент

и

этим уже вполне можно пользоваться дома.

Я проверял систему на своих виртуальных машинах и одном реальном ноутбуке.

Это несколько меньше, чем парк оборудования крупного Linux-вендора.

Где взять и как попробовать

Вся пользовательская документация, включая подключение репозитория и процедуру обновления:

https://pkgrepo.ru/redos-kde67/

Дублировать команды в статье я специально не буду: документация репозитория может обновляться, а старая инструкция в статье останется старой инструкцией.

Но перед экспериментом стоит помнить главное.

Это не официальный репозиторий РЕД Софт.

Его собирает случайный человек из интернета, который в свободное время решил проверить, получится ли перенести свежий KDE на РЕД ОС.

Я не являюсь профессиональным мейнтейнером РЕД ОС, не предоставляю техническую поддержку и не могу гарантировать, что очередное обновление не съест вашего хомяка.

На своём ноутбуке перед такими экспериментами я использую Btrfs snapshots и нормальные backup.

Очень рекомендую иметь аналогичный план возврата.

Можно ли теперь просто нажать кнопку и собрать всё заново?

Почти.

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

То есть процесс воспроизводим.

Но upstream меняется. Fedora меняет SPEC-файлы. Патчи перестают накладываться. Появляются новые зависимости.

Следующее большое обновление всё равно потребует работы.

Просто теперь это уже не экспедиция в неизвестность, а более-менее понятный процесс.

Поддерживать репозиторий дальше я планирую по мере сил и возможностей.

Что я понял про LLM

Без LLM я, скорее всего, вообще не стал бы начинать этот проект.

Не потому, что в RPM packaging невозможно разобраться по документации.

Разумеется, возможно.

Но цена входа для побочного домашнего проекта была бы слишком высокой.

LLM резко снижает стоимость каждого отдельного вопроса: можно показать ей ошибку компилятора, попросить объяснить макрос SPEC-файла, сравнить версии API или предложить минимальный патч.

Для человека, который уже умеет программировать и способен проверить ответ, это очень мощный инструмент обучения.

Но эксперимент показал и пределы такого подхода.

LLM хорошо решает локальные задачи.

Гораздо хуже — бесконечно долго тащит большой проект сама.

В начале мой подход выглядел примерно так:

Вот тебе компьютер. Собирай KDE.

К концу:

Вот конкретная проблема. Вот ограничения. Вот текущее состояние. Реши эту задачу и остановись.

Второй вариант оказался заметно эффективнее.

То же относится к моделям.

Для большинства задач мне хватало Luna.

Не получилось — Terra.

Sol оставался для действительно сложных случаев.

То есть:

Luna → Terra → Sol

а не:

Sol → Sol → Sol → закончились токены

Вторую схему мне тоже удалось проверить экспериментально.

Немного уважения к мейнтейнерам

До этого проекта работа мейнтейнера дистрибутива со стороны иногда выглядела примерно так:

Вышла новая версия программы. Почему они просто не обновят пакет?

Теперь я буду задавать этот вопрос осторожнее.

Собрать программу — часто самая простая часть.

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

А потом выходит следующая версия, и всё начинается снова.

В моём случае всегда можно было сказать:

Ну ладно, DrKonqi мне не настолько нужен.

У мейнтейнера коммерческого дистрибутива такой роскоши может не быть.

Есть пользователи, документация, SLA, сертификация, корпоративные заказчики и совсем другие требования к совместимости.

Поэтому сравнивать мой домашний репозиторий с официальным было бы странно.

У нас просто разные задачи.

Зато теперь я чуть лучше понимаю, почему фраза «ну обновите там KDE» не всегда вызывает у разработчиков дистрибутива такой же энтузиазм, как у пользователя.

Вместо заключения

Началось всё с того, что мне не нравилось дробное масштабирование на одном ноутбуке.

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

Но главный вывод для меня даже не про KDE.

Современные LLM очень сильно снижают порог входа в незнакомые технические области.

Они не делают человека мейнтейнером Linux-дистрибутива.

Я после этого проекта тоже им не стал.

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

При этом вайбкодинг довольно быстро упирается в предел.

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

Начать проект можно на чистом энтузиазме и промптах.

Заканчивать его почему-то всё равно приходится инженерными методами.

Ну и ещё один важный вывод.

Если вам кажется, что подобный домашний проект можно закончить завтра — скорее всего, вы правы.