Далее речь только о видеокартах производителей, которые полностью поддерживаются свободными драйверами. В связи с тем, что выход новых линеек видеокарт стал ежегодным, а так же увеличился приток пользователей, использующих новейшее оборудование, крайне возросла востребованность свежайших версий драйверов с реализацией графических API (скопом входят в Mesa), а так же LLVM (для компиляции шейдерного кэша) и firmware-linux. Переход актуальных версий пакетов из Сизифа в платформу может занимать весьма длительное время, когда поддержка оборудования требуется здесь и сейчас. Причём работоспособность оборудования намного приоритетнее вероятных багов. К примеру, на момент написания этого отчёта в среде ALT Linux неработоспособны видеокарты серии RX 7000. Для того, чтобы добиться работоспособности, из Сизифа требуется вручную установить ядро 6.2, libdrm, LLVM 15 и firmware-linux. Со стороны пользователя, даже опытного, использование свежайших версий пакетов, связанных с видеокартами, задача нетривиальная. Если ядро можно просто взять из Сизифа, то скоп пакетов, относящихся к Mesa и т.д., потребует усилий для упрощения получения. Сильно упростить обновление пакетов позволяет autoports с задействованием apt pinning. На мой взгляд, оптимально ориентироваться на реализацию-наполнение Ubuntu-репозитория (PPA) от kisak: https://launchpad.net/~kisak/+archive/ubuntu/kisak-mesa В нём содержится исчерпывающий набор пакетов по графической подсистеме (libdrm, mesa и т.д.) свежайших релизных версий. Так же можно присовокупить пакет linux-firmware, который, к слову, задействуется CoreCtrl для поддержки детального управления параметрами видеокарты (предоставляется в соответствующем PPA, если продолжать тему организации в Ubuntu). Тем самым предлагаю реализовать автопорт всех (или почти) библиотек, что предоставляются в репозитории kisak. Для упрощения получения этих свежайших пакетов из autoports, по идее, будет оптимально предоставить мета-пакет с настроенным конфигурационным файлом apt pinning (/etc/apt/preferences.d/), в котором будут выставлены приоритеты только для пакетов графической подсистемы. Сразу стоит учесть, что для apt и Synaptic используются отдельные файлы preferences. Да, всегда подключенный репозиторий autoports может вызвать конфликт, если пользователь уже использует autoports для периодического обновления единичных пакетов, отключая и выключая его по необходимости, но это легко решается и это совсем ничтожная цена на фоне преимуществ: простейшее получение свежайших версий пакетов по графической подсистеме и поддержка новейших видеокарт (руками придётся поработать только для устаовки ядра). То есть пользователю потребуется установить один мета-пакет, который подтянет файл-конфигурацию с подключенным репозиторием и файл с настроенным pinning. Это будет особенно полезно для новичков и сбережения нервов сообщества (будет всё больше людей с новейшим оборудованием — всё больше вопрошающих, как им добиться работоспособности новейшей видеокарты).
Всё-таки отдельный подключаемый репозиторий на манер PPA со свежайшими версиями пакетов под платформу (без особого тестирования — достаточно успешной сборки) был бы оптимальным вариантом. В немалом числе случаев получение новейшего функционала важнее, чем вероятная нестабильность. Разумеется, необходимо предупредить пользователя, что использование пакетов из таких дополнительных репозиториев на свой страх и риск в виду (только) автоматического тестирования. Основным отличием таких репозиториев от карманов и autoports является узкая направленность. Тем самым в репозитории не один пакет, как в кармане, но и не всё подряд, как в autoports. Так же очень важным является удобство подключения-отключения. Подключение и отключение можно реализовать через Альтератор. Вероятно, через отдельный модуль, в котором бы предлагались те самые дополнительные репозитории. При отключении хорошо бы предлагать диалог, в котором можно выбрать автоматический откат (downgrade) на версию из платформы. Кроме очевидного набора пакетов, связанных с поддержкой видеокарт и самых свежих драйверов (OpenGL и Vulkan), к примеру, отдельно можно поставлять: ROCm (и аналог от Intel) и набор ПО "геймера" (corectrl, MangoHUD, goverlay, vkBasalt и подобные). Всё это, как правило, требуется свежайших версий и долгое тестирование с отбрасыванием версии при малейших регрессиях нередко приносит пользователю больше неудобств, чем пользы. В том же ROCm по сей день немало ошибок и затянутости ввода поддержки новых серий видеокарт (до полугода), а если ещё ждать тестирования со стороны команды ALT, которое, скажем прямо, весьма неторопливое для подобного типа пакетов и при этом будет зарубать версию за версией из-за найденных регрессий, то это приведёт к тому, что ROCm не получится использовать, можно сказать, вообще, а вместе с ним ещё массу программ, которые регулярно подтягивают функционал upstream и вскоре перестают работать на старых версиях ROCm. Подобное применимо и для новейших игр (в основном работающих через Proton-Wine), которые для работы требуют поддержки свежайших версий Vulkan. Подход с отдельными репозиториями со свежайшими наборами пакетов так же полезен для упрощения тестирования со стороны обычного пользователя, которому не придётся влезать в Сизиф или пытаться собирать самостоятельно.
Отличие вашего предложения от https://www.altlinux.org/Autoports в том, что вы говорите о системообразующих пакетах, которые требуют достаточно серьёзных изменений (взаимосвязанного обновления сотен пакетов), поскольку одно будет обязательно цепляться за другое. Хорошо, что есть аналогичные решения для Ubuntu. Но как можно заметить, это стороннее частное решение без участия Canonical. Поэтому интересно, какие усилия вы готовы прикладывать к этому решению? И какой смысл с этим заморачиваться, если можно просто перейти на Сизиф.
Перечисленные пакеты не требуют особых зависимостей, что демонстрирует их поставка через упомянутый PPA. Через PPA поставляется множество программ, причём даже такие сложные как qemu-kvm вместе со всей "типичной" обвязкой. Если такое возможно даже на Ubuntu, то в ALT, на мой взгляд, тем более не возникнет особых затруднений в связи с более гибким развитием стабильных выпусков. Более того, уже существующие "карманы" являются очень близким аналогом, что определённо упрощает реализацию. Мои усилия заключаются во внедрении дистрибутива в рабочие процессы по личной инициативе с целью минимизации зависимости от зарубежных решений, что способствует снижению бизнес-рисков и увеличению поддержки отечественных разработчиков. Остальное (с моей стороны) делается по мере возможностей, на энтузиазме и за свой счёт. Вся эта деятельность далека от профиля работы, если говорить прямо. Если делать ещё больше, то придётся стать сотрудником Базальт СПО. Использование Сизифа сопряжено со слишком высокими рисками потери работоспособности, что делает неприемлемым его использование в рабочих задачах. А перебор "удачных" срезов — это совсем не то, на что есть время в процессе выполнения задач организации, и такое решение будет приводить к необходимости формирования собственного отдела тестирования, что далеко не профиль для подавляющего числа организаций даже в нашей нише, не говоря о значительных издержках на содержание таковых специалистов. Разумеется, можно использовать Docker, но это в очередной раз подпадание под зависимость от третьих лиц вне РФ, а поддержка собственных образов требует инфраструктуры и специалистов. Исходя из описанного, аналог PPA-репозиториев со свежайшими версиями пакетов под конкретный набор задач является крайне необходимым. Этот механизм позволяет намного более гибко решать задачи бизнеса, а в ряде случаев вовсе получить саму возможность работать, следовательно, определяет выбор дистрибутива для оснащения организации. Так же изощрённым вариантом может быть набор Docker-образов (или иных контейнеров) на базе ALT и специализированный инструментарий, нацеленный на максимальное упрощение решения задач, которые закрывают PPA. В связи с ростом числа пользователей и от того всё более расширяющимся кругом решаемых с помощью ОС задач, подобные решения становятся экзистенциальной необходимостью. Со стороны ALT это будет сильным конкурентным преимуществом, углубляющим одно из ключевых его достоинств — самодостаточность (сам является платформой) и мощную инфраструктуру.
Ещё один вариант. Организовать упрощённое использования заданий по ряду пакетов. К примеру, через модуль Альтератора сделать автоматическое подключение свежайших заданий для конкретных пакетов (комплектов пакетов), выбранных пользователем. К примеру, галки для полного комплекта по wine, mesa, rocm, firmware-linux и т.п. По появлению нового задания отключать старое и подключать новое. Тем самым не придётся организовывать отдельные карманы и выделять дополнительные ресурсы на сопровождение
Created attachment 15154 [details] скрин inxi -G При запуске live дистрибутива alt k workstation p10 столкнулся с дикими тормозами. Проблема оказалась в том, что для рендеринга был выбран llvmpipe-драйвер. Попробовал alt k workstation p10.2. В этой ревизии, хоть драйвер выбирается такой же, производительность уже значительно лучше. На сколько я понимаю, проблема прежде всего возникает из-за того, что mesa линкуется с llvm 11, хотя для моей видеокатрты минимум нужен llvm 15. Из spec файла из mesa.src.rpm (http://ftp.altlinux.org/pub/distributions/ALTLinux/p10/branch/x86_64/SRPMS.classic/Mesa-23.1.8-alt2.src.rpm) я пришел к выводу, что сборка уже по идее должна идти с llvm 15, но почему-то по факту собранные библиотеки слинкованы с llvm 11. Стоит ли заводить отдельный баг на эту тему, или пусть живет в этой? P.S. моя видеокарта: radeon rx 7900 xtx
(Ответ для Vladimir Perepechin на комментарий #5) > Стоит ли заводить отдельный баг на эту тему, или пусть живет в этой? Конечно, стоит. Mesa не мой пакет, и я вряд ли именно за него возьмусь, а майнтайнер, ответственный за Mesa, этот баг не читает.
По поводу собственно бага - прошу прощения, год назад руки не доходили, уже даже успел забыть. Теперь появились новые ресурсы, сервис cronbuild переехал на новую более мощную ноду, так что буду думать и потихонечку разрабатывать поддержку. Есть надежда, что в 2024 желаемый сервис появится. Будет называться cronpockets? и будет обслуживать произвольное количество микро-addon репозиториев (pockets) по типу cronports, но с фиксированным списком пакетов.
(Ответ для viy на комментарий #7) > Есть надежда, что в 2024 желаемый сервис появится. > Будет называться cronpockets? cronbackports?
(Ответ для viy на комментарий #6) > (Ответ для Vladimir Perepechin на комментарий #5) > > Стоит ли заводить отдельный баг на эту тему, или пусть живет в этой? > > Конечно, стоит. Mesa не мой пакет, и я вряд ли именно за него возьмусь, а > майнтайнер, ответственный за Mesa, этот баг не читает. Конкретно этот отчёт о "теоретизировании", что есть потребность в ветке со свежайшими пакетами для поддержки новейшего графического оборудования именно для использования совместно со стабильной платформой (причём такое использование явно обозначать как "на свой страх и риск" для экономии на тестировании). Тем самым все прочие обсуждения тут лишние.
Спасибо. Завел баг https://bugzilla.altlinux.org/48698
