EndeavourOS, или, для краткости, EOS, — второй из трёх моих последних Linux’ов, хотя по справедливости должен называться первым: на протяжении более чем двух лет именно в нём осуществлялась вся практическая работа.

Вводная История про EndeavourOS. Что нужно знать про эту дистру

Официальный сайт проекта EndeavourOS содержит достаточно сведений, чтобы составить представление об этой дистре, которая известна также под именем ΕOS. Эта аббревиатура используется (в том числе и) её майнтайнерами и (полуофициально) является официальной. Она и будет использоваться в этой книге ввиду «малабукаффья» (и здоровой лени).

ΕOS является одним из дериватов Arch’а, разрабатываясь, как и первопредок, по модели «скользящих релизов» (rolling release). От него же он унаследовал приверженность архитектуре x86_64, хотя ветви для aarch64 также уделяется внимание (но об в моих Историях не будет говориться от слова «вообще»).

От прародителя EOS унаследовал систему управления пакетами , дающую прямой доступ ко всем официвльным репозориям Arch’а. Присоединив к ним собственный небольшой репозиторий endeavouros — без всякой дискриминации по части доступа со стороны одноимённой команды pacman.

В собственном репозитории содержатся, по-первых, дистро-специфические пакеты, во-вторых, модифицированные пакеты из Arch’вых «реп» и из AUR (пользовательского дитстрибутива Arch’а).

AUR для pacman‘а напрямую недоступен, тому служат специальные оболочки (так называеые wrapper’ры и helper’ы). Их много, и все они лежат в AUR’е же. Однако многие Arch-клонеры модифицированно виде в свои репозитории, и EOS — не исклювение: в нём по умолчанию имеется yay, который может служить средством управления пакетами из всех репозиториев (включая официальные).

Главное отличие EOS’а от первопредка — в инсталляторе. В Arch’е он сначала работал в текстовом режиме, потом около 10 лет его не было вообще, с начала 20-х есть как опция Archinstall, опять же текстовый. EOS же с самого рождения обзавёлся штатным инсталлятором, работающим в графическом режиме и основанным на модном нынче фреймворке Calamares, подобно многим сородичам по клану.

Официально проект ΕOS в настоящее время поддерживает несколько рабочих сред: на базе Qt — KDE Plasma и LXQt, на базе Gtk — GNOME, Cinnamon, Budgie, MATE и Xfce, а также «внеклассовый ~~огнедышащий дракон~~» оконный менеджер i3. «Спиcочные» DE (и примкнувший к ним WM) выбираются при инсталляции выбором нужного пункта:

Илл. I-001. Выбор рабочего окружения из установочного списка

Прочие DE и WM’ы, не попавшие в «установочный спиcок», могут быть установлены использоваться в этой дистре, если они имеются в репозитории extra Arch’а, или в AUR’е. Разумеется, для установки любых DE и WM, как «списочных», так и произвольных, необходимо подключение к сети.

Лишь один DE может быть установлен автономно — тот, который: во-первых, используется как рабочая среда в live-режиме для демонстрации несравненных достоинств ΕOS заинтересовавшымся лицам (например, молоденьким девушкам и их неизменно юным бабушкам), и, во-вторых, служит «пускачём для инсталлятора», превращающего вышеозначенных лиц из заинтересовавшихся в заинтересованных. Таковой ныне, с ноября 23-го года, является KDE, сменившая в этой роли среду Xfce).

Очевидно, что в каждый момент времени актуален только один установочный (он же «живой») образ дистры EOS, однозначно идентифицируемый датой его выхода в свет с точностью до месяца, по которой ему и присваивается имя iso-файлу. И под этим же именем, с уточняющим эпитетом названия дистра, он становится известен как очередной релиз EOS’а.

Каждому здравомыслящему человеку (а я себя позиционирую именно так) ясно, что термин релиз для rolling-дистра — от Глюкавого. И потому я предпочитаю периодические снапшоты любых rolling-дистров называть квази-релизами. Для EOS такие «вроде как релизы» с некоторых пор стали дополнительно получать почётные почётные титулы. Так, последний имеет полное имя Endeavouros-Galileo-11-2023.iso. Что, вместе с «Периколой» Оффенбаха разбудило мой напрочь отсуствующий поэточеский талант:

Галилео Галилей,
По стакану нам налей
И нам дистру сынсталей!

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

Во-первых, пролистав страницу почти до конца, я дошел до раздела Download mirror list:

Из этого списка нужно выбрать подходящее. Для меня, как ни странно, по опыту с более иными дистрами, самым подходящим зеркалом оказывается обычно оказывается какое-нибудь из шведских, а Швеция, как известно, находится в Европе:

И в списке европейских зеркал есть Швеция, а в ней — город Уму с университетом. Он большой, Википедия пишет, что самый больной на севере Швеции. Глядя на здание, в это можно поверить:

Почему бы в таком здании не стоять серверу, а на нём — не лежать зеркалу проекта EOS? Вот и эмблемка у универа подходящая:

Второй способ — скачать через Torrent

Илл. I-006. Кнопки скачивания через Torrent

Есть и другие способы, например, скачать через торрет-архив Distrowatch’а, но я решил, что пока и двух много. Тем более, что всё написанное — это вообще всё, что следует знать для первого знакомства с дистром. Мне, по крайней мере, этого хватило, когда я впервые пришёл на сайт проекта EOS, что называется, «с серьёзными намереними».

Но раз речь зашла о Distrowatch’е, добавлю: на текущий момент (последние три месяца) EndeavourOS находится на третьем месте в рейтинте нашего дистр-учётчика, а за последние 3 года не выходил из «тройки призёров»:

Илл. I-007. EOS в рейтинге Distrowatch’а. 2022 года

Цену рейтингу Distrowatch’а все разумные люди знают, если задавать ему неправильные вопросы. Хотя, если спрашивать его правильно — ответы могли бы дать материал для докторской диссертации по массовой психологии (или психологии масс?)

Но не рейтинги вызвали мой интерес к данному дистрибутиву, а совсем другие причины. Какае? Об этом — в следующих Историях.

История про KDE и EndeavourOS. Установка системы

Не смотря на несомненные достоинства MX-KDE, мы с котом Мануалом продолжали свои искания альтернативы Mint’у с его Cinnamon как основый для «пенсионерского» Linux’а. И они, через пелену воспоминаний, привели нас к EndeavourOS, о котором и будет говориться в этих Историях.

Предыстория

Последние несколько месяцев мы с Мануалом немало времени убили на выбор альтернативного варианта «Linux’а для пенсионеров» — о причинах, почему это неожиданно приобрело актуальность, достаточно подробно сказано в первой части Историй про KDE и MX. Помимо дистрибутива, фигурирующего в названии, мы достаточно внимательно поглядели, то есть с установкой не только в виртуалке, но и на реальном «железе», несколько вариантов.

Во-первых, Netrunner Core — систему, как и MX, на базе Debian Stable, представляющую собой минималистическую сборку «головного» дистрибутива, который называется Netrunner просто. Он был всем хорош, в том числе и минимализмаом — размер iso-образа текущей версии 1,3 ГБ. И это — при KDE в качестве десктопа…

В-вторых, мы примерились к двум rpm based дистривутивам, использующим в качестве менеджера пакетов apt-rpm — Altlinux и PCLinuxOS. В отличие от монодесктопного Netrunner Core, оба они поддерживают несколько рабочих сред (первый — так вообще чуть ли не все существующие), и имеют минимальные сборки с KDE. В Altlinux таковая входит в состав так называемых стартовых наборов (StartedKits, текущая сборка с KDE — 1,6 ГБ), в PCLinuxOS представлен сборкой pclinuxos64-kde-darkstar (1,8 ГБ).

Не прошли мы мимо и классического дистрибутива с KDE в качестве умолчального десктопа — Slackware, благо аккурат в эти дни вышел очередной, 15-й, его релиз, как в официальном исполнении, так и в сборке Alien Bob’а (в миру Эрик Хамелирс).

Ни про одну из рассмотренных систем у нас не найдётся ни единого худого слова. Однако каждая имела особенности, которые не были недостатками сами по себе, но оказывались таковыми в рамках поставленной задачи — поиске дистрибутива, подходящего для пенсионера. Для которого критичен фактор времени.

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

Так что мы с Мануалом продолжали свои искания. Что заставило вспомнить о некогда любимом дистрибутиве под названием Antergos, о котором в своё время немало было написано и на Блогосайте, и на Цинии https://www.cinia.ru/tag/antergos/.

Правда, сам Antergos прекратил своё развитие в апреле 2019 года, потому как его майнтайнеры сочли свою миссию выполненной и занялись другими делами. Однако надо отдать им должное — инфраструктура проекта (сервера, репозитории etc.) поддерживалась ещё несколько месяцев. Для тех, кто, возможно, возжелает развивать проект дальше.

И желающие нашлись — сформировалась команда волонтёров, которая продолжила работу над дистрибутивом. Теперь уже, правда, под другим именем — EndeavourOS. И первые образы нового дистрибутива появились уже в августе 2019 года. А декабрём того же года датируется датируется то, что можно считать уже «релизом в законе», зарегистрированным на Distrowatch’е. Предыстория EndeavourOS закончилась, началась нормальная цивилизованная жизнь.

Про EndeavourOS вообще

Как и Antergos, EndeavourOS (далее, для простоты, EOS) основан на дистрибутиве Archlinux. И если первый можно было назвать «Arch’ем с инсталлятором», то к EOS такое определение подходит гораздо в большей степени: его отличия от материнской системы настолько минимальны, что практически не видны невооружённым глазом.

Разумеется, превращение Antergos’а в EOS не обошлось без потерь. Так. последний утратил графические средства управления пакетами, унифицированные для доступа как к официальному репозиторию Arch’а, так и к неофициальному AUR’у (Arch Users Repository). Не стало в нём и поддержки ZFS «из коробки», на стадии инсталляции.

Кстати, Antergos был первым и долгое время единственным (что бы ни говорили по этому поводу апологеты Ubuntu) дистрибутивом, реально таковую обеспечивающим. В EOS же фактически поддерживается только две файловые системы — Ext4 и BTRFS.

Когда я увидел один из первых, ещё до-релизных, выпусков EOS, отсутствие указанных функций несколько разочаровало. И всё ждал, когда же их портируют из Antergos’а. Так и не дождался…

Но зато за время ожидания понял, что EOS — это не Antergos, и что в отсутствии графической «морды» для пакетного менеджмента или поддержки ZFS есть великая сермяжная правда, бо ни та, ни другая фича на данном этапе социалистического строительства народу нужны не больше, чем плезиозавры. Тем более что у EOS’а есть другие полезные особенности — о них я скажу, когда дело дойдёт до установки и начальной настройки дистрибутива.

Как и его предшественники, папаша Arch и дядька Antergos, EOS разрабатывается по rolling-модели. Так что его релизы, как и у всех «скользких» дистрибутивов, в сущности представляют собой периодически составляемые выборочные снапшоты официального репозитория Arch’а, снабженные инсталлятором на базе Calamares’а.

В данном случае основная задача инсталлятора — не столько развёртывание на целевом носителе системы с носителя установочного, сколько извлечение из сетевого репозитория (конкретно — официального репозитория Arch’а) предопределённых наборов пакетов, выбираемых пользователем. Хотя, конечно, пакеты выбранного списочного состава должны быть не только получены, но и подвергнуты обычным при инсталляции чего бы то ни было издевательствам. То есть — распакованы и включены в файловую иерархию целевого накопителя.

Из модели разработки EOS’а следует схема его распространения, унаследованная от Antergos’а. Дистрибутив в момент релиза доступен в виде единственного образа объёмом под 2 ГБ. В данный момент это EndeavourOS_Atlantis-21_4), скачать можно с одного из зеркал (список приведён в конце этой страницы). Например, вот с этого.

Распространяемый образ — самый обычный LiveOD с рабочим окружением Xfce, некоторым минимальным набором софта и инсталлятором. В то же время любознательный читатель, который не поленится заглянуть на официальный сайт проекта (или хотя бы на посвящённую ему страничку DistroWatch.а), может увидеть, что в EOS поддерживаются, кроме Xfce, такие рабочие окружения, как Budgie, Cinnamon, GNOME, i3, KDE Plasma, LXQt, MATE. Как это происходит, мы увидим в Истории про установку EOS.

Подготовка к установке EndeavourOS

Прежде чем начать установку любого дистрибутива (в том числе и EOS), необходимо изготовить установочный носитель — ныне в качестве такового ныне имеет смысл рассматривать только USB-флешки. Ибо оптические носители для этих целей практически вышли из употребления, подготовка установочной SD-карты ничем не отличается от флешки, а внешние HDD или SDD — тема специальная, частично рассмотренная здесь.

Разумные существа, вроде меня и тем более кота Мануала, знакомство с новым дистрибутивом начинают с установки его в виртуальной машине (в нашем случае это VirtualBox), для чего любого из указанных образов достаточно. Однако для нас с Мануалом ни один из перечисленных во вступительной Предыстории не был совсем уж незнакомым. Так что к виртуальной установке мы в наших исканиях прибегали чисто для порядка (и, иногда, для получения дополнительных иллюстраций к данной Истории).

Установка в реале требует, разумеется, изготовления установочного носителя. Он же в Live-режиме может пригодиться для ремонтно-восстановительных работ. Делается такой носитель либо прямыми командами, либо одной из специальных утилит графического режима. Их существует множество, чему посвящён, например, соответствующий раздел форума Matuntu. Однако мы с Мануалом — обскуранты и консерваторы (да к тому же ещё и лентяи). И потому действуем по старинке, с помощью утилиты dd (в этом и следующих примерах путь к файлу образа и имя файла целевого устройства следует заменить на свои реалии):

$ sudo dd if=~/Downloads/EndeavourOS_Atlantis_neo-21_5
of=/dev/sde bs=8M status=progress

Опции bs (размер единовременно записываемого блока в мегабайтах, цифра 8 чисто условна и вызвана многолетней привычкой) и status не обязательны. Но без первой запись образа будет происходить умолчальными блоками 512 байт. Это очень медленно и печально. Без второй опции не будет отображаться процесс копирования. Так что она не обязательна тем более. Ещё и потому, что создаёт лишнее мельтешение на экране.

Второй из прямых способов копирования образа — самая обычная команда cp в современной её ипостаси, с именем файла образа в качестве источника и файла будущего установочного носителя в качестве цели:

$ sudo cp ~/Downloads/EndeavourOS_Atlantis_neo-21_5 /dev/sde

По сравнению с dd второй способ проще — буковок набирать меньше, и меньше вероятность перепутать местами источник и цкл (то есть if и of, соответственно). Правда, размер блока при команде cp невозможно задать явно, и как он вычисляется, одному Ахурамазде ведомо. Тем не менее, оба прямых способа представляются мне равноценными: они не зависят ни от дистрибутива, в котором происходит копирование, ни от копируемого образа, и дают неизменно превосходный результат.

Однако при переборе альтернативных вариантов подготовка к установке их происходила в системе Linux Mint Cinnamon Edition. И мы с Мануалом решили для разнообразия воспользоваться входящей в его комплект штатной графической утилитой записи образа на USB-накопитель (USB Image Writer), которая расположена в секции Стандартные главного меню. После её запуска при вставленной флешке возникнет такая панель:

Нетрудно догадаться, что в левом поле стоит имя файла образа, в правом — «имя» флешки и, в скобках, имя файла соответствующего ей устройства. Если, конечно, таковое вставлено — если нет, правое поле будет пустым. Пока флешка не очутится там, где ей следует быть, то есть в USB-порту. Тогда её имя появится в правом поле. Но перед этим потребуется ввод пароля администратора (в данном случае — пользователя, который может получить административные привилегии):

И тогда для того, чтобы «процесс пошёл», достаточно нажать кнопку Записать — и процесс действительно пойдёт:

После его окончания поверх окна программы появится панель с сообщением, что образ был успешкно записан:

Что, впрочем, в общем случае не гарантирует, что флешка будет успешно работать как загрузочная. На упмянутом выше форуме Matuntu говорится, что графические утилиты такого рода корректно срабатывают а) не все, б) не всегда и в) не со всеми образами. А, например, разработчики Altlinux’а до недавнего времени вообще не советовали записывать их образы чем бы то ни было, кроме команды dd. Хотя нынче они признают годными такие графические утилиты, как ALT Media Writer, SUSE Studio Imagewriter и ROSA Image Write.

Относительно совместимости (или несовместимости) USB Image Writer (пакет mintstick) с чем бы то ни было я в сети информации не нашёл. Так что оставался метод ползучего эмпиризма — загрузить машину со сделанной описанным образом флешки. Мы с Мануалом производили такую проверку в среде Cinnamon дистрибутива Linux Nint для всех упомянутых в Предыстории образов — и каждый раз успешно. То есть по крайней мере в родном окружении утилита проверку на вшивость прошла.

Установка EndeavourOS

Проверка свежеизготовленной флешки с EOS плавно переходит в запуск этого дистрибутива в Live-режиме. То есть сначала появляется меню загрузчика установочного носителя, которое на машине, работающей в режиме BIOS Legacy (а именно в этом режиме настроен наш десктоп) выглядит так:

То же самое меню в режиме UEFI можно было подсмотреть только в виргуалке:

В обоих случаях нужно нажать Enter на первом пункте меню. Впрочем, пункт этот умолчальный, и можно не делать ничего — загрузка начнётся автоматически. И закончится появлением рабочего стола Xfce. Причём на реальной (моей) машине на его фоне появится панелька с предложением выбрать драйвер сетевой карты:

На выбор их предлагается два: а) 8169 по умолчанию, и б) 8168 при наличии пробоем с первым. Я сделал умолчальный выбор (никаких проблем потом не обнаружилось), после чего появляется окно Welcome, то есть приветствия:

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

Забегая вперёд, надо отметить, что Welcome — одно из тех самых замечательных дистроспецифических изобретений EOS, о которых я упоминал ранее. Потому что это не просто экран при приветствия типа «Здрасте, я ваша тётя», а средство доступа к различным постинсталляционным настройкам. Почему подробно о них будет говориться в следующей истории.

Пока же панель приветствия послужит нам для запуска инсталлятра. Для этого нажимаем на ней кнопку с надписью Start the installer:

мы видим очередную панель выбора — на этот раз метода установки, Online или Offline. Как следует из названий, при оффлайновом методе можно обойтись без подключения к сети. Однако при этом на целевом носителе будет развёрнут образ носителя установочного, со средой Xfce. Нам же от EOS требовался дкесктоп KDE, а с интернетом было всё нормально, так что выбор онлайнового режима был однозначен:

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

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

Как обычно в инсталляторах Calamares based, следующим шагом будет определение клавиатуры. До сих пор все отпрыски кальмара, которые я видел (а я видел их очень немало), не знали о том, что в нём может быть более одной раскладки. И потому при выборе русского языка настаивали, что и раскладка при этом обязательно должна быть русской, без малейшей альтернативы на основе латиницы.

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

А теперь, маэстро, урежте марш! при принятии автоматически предлагаемой раскладки, то есть русской, английская (американскоя) сохраняется, причём первой. Это даёт возможность уже на стадии инсталляции определить и вариант раскладки вместо умолчального winkeys — общепринятого среди пользователей Windows, но самого неудобного из всех придуманных русскоязычным человечеством:

Так, я приобщился к клавиатурному труду на пишущих машинках, и отдаю предпочтение варианту Russian (typewriter, legasy). О преимуществах её перед любыми другими было написано немало, так что здесь распространяться не эту тему не буду

Возможность точной настройки клавиатуры — это вторая фирменная «фишка» EOS.

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

Впрочем, тут ничего особенно делать не пришлось: для всякого рода дистрибутивных исканий у нас был раздел 120 ГБ на перовом, полутерабайтном, SDD (то есть уствойство с именем /dev/sda1), и его оставалось просто уничтожить:

А затем — создать заново, разместив там файловую систему Ext4:

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

После окончаниb разборки с разделами наступает самый волнующий момент — выбор десктопа и кое-какого дополнительного софта, для чего выводится такая панель:

Здесь по умолчанию для установки отмечены первые две позиции списка — базовая система, в которой рекомендуется ничего не убирать, и Firefox со средствами его интернационализации.

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

Не лишним выглядит и Firefox; поддержка языка в нём устанавливается в соответствие с ранее определённой локалью (то есть русской). Ну а то, что KDE должен быть отмечен для установки, очевидно — ведь ради него вся эта катавасия и затевалась. Кажется, что пакетов в KDE, подборке довольно много, но это действительно только кажется: после внимательного изучения их списка мне удалось вычеркнуть только print-manager. Да и то только потому, что принтера у меня нет физически.

В итоге список софта, отобранного для установки, выглядит так (включая некие «доступные инструменты», отмеченные чисто на всякий пожарный случай):

Покончив с выбором софта, переходим к созданию пользовательского аккаунта. И тут нам наконец предоставляется возможность проверки — правильно ли мы настроили алавиатуру. Оказалось — правильно: все данные аккаунта, в отличие от прочих инсталляторов на базе Calamares’а вводятся нормальной латиницей:

За одно это разработчикам EOS можно простить отказ от наработок проекта Antares. Тем более что практика показала — без них вполне можно обойтись без всякого ущерба для функциональности.

Теперь — завершающий штрих: вывод резюме всех ранее выполненных действий, от определния локали и настроек клавиатуры до схемы дисковой разметки и места для установки загрузчика. Последний, кстати, в многодисковых конфигурациях всегда устанавливается по умолчанию в MBR того носителя, на который инсталлируется EOS — в нашем случае устройства /dev/sda:

Важно, что сейчас мы имеем последнюю возможность вернуться (с помощью кнопки Назад) и поправить то, что не понравилось. О чём нас и предупреждает панель, появляющаяся после нажатия на кнопку Установить:

Поскольку мы полагаем, что всё было сделано правильно, смело жмём на кнопку Приступить к установке. И видим, что «процесс пошёл»:

Установка EOS происходит быстро. Она сводится к скачиванию определённого ранее набора пакетов по сети (из официального репозитория Arch’а), распаковке оных (простых tar-архивов, компрессированных утилитойzstd) и размещению в дереве файловой иерархии.

А потому время инсталляции EOS лимитируется скоростью соединения с интернетом, мощностью машины и быстродействием целевого носителя. Со всеми тремя параметрами у нас с Мануалом на дестктопе всё в порядке:

интернет 100 Мбит/сек;
процессор Intel 4790K, 4 Ггц, 4 ядра, 8 потоков;
целевой носитель Crucial_CT512MX100SSD1 512 КБ).

Так что сообщение о завершении установки появляется очень быстро — к сожалению, я, как (почти) всегда забыл засечь время. Могу только сказать, что покурить я успел, а вот принять стопарика, буде появилось бы такое желание, пожалуй, не получилось бы…

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

При установке в реале при этом можно ничего не делать, а просто наблюдать процесс перезагрузки — на него, как и на текущую воду и горящий костёр, можно смотреть беспрерывно. Установочную флешку можно вытащить из машины. А можно и не вытаскивать — она ничему не помешает.

Другое дело — при установке в виртуалке. В EOS автоматического размонтирования и извлечения установочного носителя не происходит — этим надо озаботиться самому. Иначе перезагрузка наша опять окажется в Live-режиме. И невнимательный пользователь рискует провести в нём все отпущенные ему судьбой годы.

Разумеется, среди нас, товарищи, таких нет. Ведь такие товарищи — нам, товарищи, совсем не товарищи. Так что в любом случае, реальном или виртуальном, после мельтешения цифр, появления и исчезновения меню GRUB’а на фоне рабочего стола KDE выплывает панель приветствия Welcome. И настало время рассмотреть её подробнее.

А в завершение этой Истории остаётся добавить только, что Мухтар действительно постарался — «фишку» с раскладками клавиатуры мы уже видели. Казалось бы, дело не хитрое — а насколько упрощает жизнь применителя. Окончательно же в старании Мухтара мы убедимся, ознакомившись с программой Welcome и некоторыми другими постинсталляционными настройками. Но уже — в следующей Истории.

История про KDE и EndeavourOS. Приглашение в систему, или Welcome

Как бы ни был близок выбранные дистрибутив и десктоп к идеалу, после сразу после установки оба они установки для комфортной работы нуждаются в некоторой доводке, поскольку идеал у каждого свой. А rolling-системы (и даже системы semi-rolling) нуждаются в немедленном обновлении. Впрочем, выбравшие EOS не обязаны после первого рестарта системы хвататься, засучив рукава, за пакетный менеджер и текстовый редактор: у них перед глазами Окно приветствия, которое возьмёт на себя часть задач по первичной настройке среды обитания.

Настройки в окне Welcome

Всё когда-нибудь бывает в первый раз, причём иногда не единожды. И, как говорилось в первой части Историй про EOS, Окно приветствия на фоне рабочего стола KDE — это первое, что видит применитель после первой перезагрузки машины:

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

Обновление зеркал

И действительно, кнопки на этой вкладке вызывают первоочередные действия, и именно в порядке их расположения. Так, первая кнопка, Обновить зеркала, синхронизирует описание репозиториев на локальной машине с теми или иными зеркалами официальных репозиториев проекта Archlinux и нашего дистрибутива, Endeavouros:

Зеркала выбираются автоматически, похоже, что по формальному признаку — локали, определённой при инсталляции. Во всяком случае, все репозитории находятся не территории России:

Результаты тестирования репозиториев можно (точнее, нужно) записать в файл
/etc/pacman.d/mirrorlist, для чего на последней панели предназначена одноимённая кнопка. Кроме того, в каталоге /etc/pacman.d/ содержаться ещё три файла. Два из них, mirrorlist.bak и mirrorlist.pacnew — результаты исходной и последней проверки зеркал официального репозитория Archlinux’а, соответственно. Файл же endeavouros-mirrorlist — список зеркал собственного репозитория EOS. Их немного (да и сам-то репозиторий небольшой). Однако наличие этого репозитория говорит о том, что EOS — действительно «дистрибутив в законе», а не какой-нибудь там клон или респин.

Интересно, что среди зеркал EOS, наряду с такими цивилизованными странами, как Германия, Канада, Франция и Швеция, а также Поднебесная, фигурируют известные своими Linux’овыми достижениями Сингапур и Южная Корея. А вот России-то и нет. Почему? Мордой EOS не вышел? Или Яшка-лейтенант ушами прохлопал? Впрочем, зеркал репозитория EOS нет и на двух других серверах с зеркалами репов официального Arch’а — ни на Truenetwork.ru, ни на mirror.surf. Видимо, и они продолжают… зубОм щёлкать?

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

Обновление пакетов

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

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

Запускается полное обновление системы...
разрешение зависимостей...
проверка конфликтов...

Затем выводится список пакетов, подлежащих обновленияю (в момент сочинения этих строк — общим числом 47), приводится объём их загрузки и распаковки, изменение размера занятого пространства (примерно 346, 1049 и 4,6 МБ, соответственно) и предложение продолжать процедуру:

Нажав Enter, соглашаемся с этим предложением. Дальнейшие события отображаются на экране, а по завершении их опять предлагается нажать Enter для закрытия терминального окна — оно свою задачу выполнило. Поскольку обновление включило в себя и обновление ядра, Уведомления из трея выдаёт рекомендацию перезагрузить систему:

Так и делаем. Убеждаемся, что перезагрузка проходит нормально, после неё ядро обновилось с версии 15.15.8 до 5.16.16, а приложения, по крайней мере те, что были запущены перед рестартом, работают нормально. С единственной шерооватостью — клавиатурные переключатели с латиницы на кириллицу (у меня они настроены как нециклические, о чём будет сказано в одной из следующих Историй) отказываются переключать и туда, и сюда. Хотя переключение по ЛКМ на индикаторе раскладки в системном трее работает как обычно.

Побороть это оказалось просто. Достаточно было зайти в настройки виджета Раскладка клавиатуры, убедиться, что все мои раскладки, их переключители и прочие параметры сохранились в неприкосновенности, и нажать кнопку Применить. После чего заработали и основные нециклические переключатели (LWin — латиница, Menu или RWin — кириллица), и временный переключатель (RControl, пока нажат), и клавиша Compose (RAlt), и ввод всегда цифири с NumPad’а a la Mac.

Ещё одно изменение, неожиданное, но не плохое и не хорошее: фон главной управляющей панели «порозовел», тогда как исходно был очень светло-серым. Однако сейчас я этим заморачиваться не стал, а продолжил знакомство с окном Welcome.

Очистка от продуктов жизнедеятельности

При общем обновлении системы, описанной в предыдущей Истории, как и просто при установке отдельных пакетов они сначала скачиваются и помещаются в каталог /var/cache/pacman/pkg/где и хранятся, даже когда в них минует надобность. Так, из 29-го скриншота следует, что апгрейд, проводившейся для создания иллюстраций к Истории про обновление системы, обошёлся в 346 МБ расхода дискового пространства:

Всего же за неполную неделю после установки EOS отходов жизнедеятельности накопилось 1,3 ГБ

du /var/cache/pacman/pkg/
1,3G    /var/cache/pacman/pkg/

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

Так что очистка системы от продуктов жизнедеятельности применителя — задача актуальная вообще, а в rolling-системах — особенно. Этой цели служит третья кнопка рассматриваемой вкладки — Настройка очистки консоли. Выглядит она так:

На этой вкладке выводится информация месте, занимаемом кэшированными пакетами, и о пространстве носителя с EOS, остающемся свободным. А сама настройка очистки сводится к установке её периодичности и числа сохраняемых версий пакетов. На следующем скриншоте показаны параметры:

Недельная периодичность на первый взгляд кажется нормальной, числа сохраняющихся версий деисталлированных пакетов не то что трёх, и двух-то много. И имеет смысл поставить «птицу» напротив опции удаления пакетов деинсталлированных, но ещё сохраняемых в кэше. После чего ввести по запросу административный пароль. После этого параметры очистки кэша пакетов можно было бы считать установленными — однако при следующем запуске данного модуля сохраняется только периодичность проверки, число версий и удаление из кэша деинсталлированных пакетов остаётся умолчальным.

Другие «послеустановки»

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

На очереди настройка вывода Уведомлений об апдейте EOS, что делается прямым редактированием соответствующего конрфига в терминальном окне, вызываемом кнопкой «втрого уровня», которая зовётся Edit config:

Умолчальный вид Уведомлений мы видели в конце Истории про обновление системы, и оно вполне достаточно. Так что не будем заниматься этими мелочами — по крайней мере сейчас.

Менеджер дисплеев отвечает за авторизацию в системе, предлагая ввод (или выбор) логина пользователя и ввод его пароля. В KDE-редакции EOS по умолчанию используется SDDM. Этот DM специально разрабатывался для среды KDE и в замене не нуждается, хотя ему и имеются альтернативы:

Из них прменителям более иных сред (м даже оконных менеджеров) стоит обратить внимание на lightdm. Он имеет уникальную фишку — гостевой вход в систему. Сейчас не место и не время подробно рассказывать о последнем (тем более что я о нём писал. Но прошу поверить на слово — это штука очень полезная. И мы с Мануалом часто жалеем, что её нет в SDDM.

Как было сказано в Истории про установку EOS из первой части текущих историй, при создании пользовательского аккаунта можно заказать автоматический (то есть беспарольный) вход в систему, и тогда видеть окна входа вообще не придётся. Чем мы с Мануалом почти всегда и пользуемся.

О группе кнопок, связанных с обоями EOS достаточно сказать, что в этом дистрибутиве существует единственная тема, и по умолчанию в ней одна обоина — endeavouros-wallpaper. Та самая, которая присутствует в качестве фона на всех предыдущих скриншотах:

При запросе Скачать больше обоев EndeavourOS можно найти довольно много фоновых картинок. Но все они будут вариациями на тему умолчальной или вот такой:

Различаются они лишь цветовой гаммой, и потому не вдохновляют. Однако страдающие дурной болезнью укоащательства (я её переболел, а Мануал не подвержен) могут быбрать любые подходящие картинки или их коллекции из файлового древа.

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

Что мы сейчас и сделаем.

Другие вкладки

Страница за номером 1 содержит общую информайию о дистрибутиве EOS, такую, как ссылки на сайт проекта, его Wiki, новости, форум и инструкцию по принесению пожертвований разработчикам:

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

Все ссылки открываются в браузере по умолчанию — в свежеустановленном EOS (а также ранее, в Live-режиме) эту роль исполняет Firefox. В том числе и последняя ссылка 1-й вкладки, О Welcome. Вместо обычных для такого пункта сведений, таких, как номер версии и дата выпуска, копирайты etc., она ведёт на web-страничку с обзором возможностей программы и содержания остальных вкладок. Полезно и интересно. Но читать это нужно было до установки системы (то есть в Live-режиме), а не после неё. Так что в качестве стартовой вкладки в уже инсталлированной системе 1-я страница Welcome не очень на месте.

Вкладка Ассистент кое в чём повторяет 2-ю вкладку: первые две её кнопки позволяют обновить зеркала и систему. К обновлению же имеет отношение и третья кнопка — Pacdiff & Meld: через неё определяется, как поступать с конфигами обновляемых пакетов — сохранять старые версии или перезаписывать их:

Кнопки Приложения по категориям и KDE: информация — это просто ссылки на соответствующие страницы англоязычной Wiki проекта Archlinux. Кнопки же Просмотр всех Arch пакетов и Просмотр всех AUR пакетов — ссылки на страницы поиска пакетов в официальном репозитории дистрибутива и в репозитории AUR. Они оказываются востребованными в установленной системе, когда (и если) возникает необходимость в её перекомплектации. Так что и 3-я вкладка не самая подходящая для стартовой.

Вкладка Советы содержит набор кнопок —, ссылок на оригинальные материалы проекта EOS — текстовые и визуальные (графика и видео) по управлению пакетами, включая пакеты из AUR, по настройке оборудования, советы, как помещать на форуме системную информацию, справочник по пользовательским командам:

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

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

Установка программ

И наконец, последняя вкладка — Установка программ. Её рассмотрение, ввиду важности, выделим в отдельное производство. Тем более что это единственный оставшийся кандидат на высокое звание стартовой вкладки Welcome.

Редакция EOS с рабочей средой KDE не претендует на компактность, хотя и особо раздутой её не назовёшь — в свежеустановленном виде она занимает примерно 5,5 ГБ. При этом обращает внимание отсутствие некоторых пакетов, обычных во всех дистрибутивах, таких, как LibreOffice (кроме уж сосем минималистичных систем). Да и Chromium всё чаще заменяет, а то и вытесняет традиционный Firefox.

Конечно, и LibreOffice, и Chromium, и даже удостоенный той же чести Firewall не составит труда установить обычным способом, из репозитория. Причём LibreOffice — в одном из двух вариантов, на выбор: libreoffice-still (то есть «ещё прежний». текущая версия 7.2.6-1), или libreoffice-fresh («совсем свежий», нынче 7.3.1-1). Однако данная вкладка и предназначена для установки некоторых особо избранных программ:

Например, установим версию libreoffice-fresh — этот пакет нам реально нужен, а версию только такую и можно с этой вкладки установить. Так что нажимаем соответствующую кнопку и видим терминальное окно совершенно другого облика, чем ранее, с очень маленькими буквами, поменять которые не получается. Масштабированию что комбинацией Control++/-, что прокруткой мышиного колеса буковки тоже не подвержены.

Одновременно в отдельном окошке (с нормальными буквами, зависящими от настроек среды) запрашивается административный пароль. После введения которого процесс установки пошёл, отображаясь в том самом терминальном окне. Но недолго — установка заканчивается очень быстро:

Убедиться в успехе этого предприятия очень легко, запустив его через пункт, скажем, LibreOffice Writer главного меню. Одновременно не обнаружив ни намёка на русский язык в интерфейсе; то есть установка локально-зависимого пакета libreoffice-fresh-ru, с точки зрения разработчиков Welcome — излишняя роскошь.

Что же, сказали мы с котом Мануалом, без сопливых обойдёмся. И установили пакет русификации обычным образом:

$ sudo pacman -Su libreoffice-fresh-ru

После чего все компоненты libreoffice запускались с интерфейсом на чистейшем русском языке.

Ни Chromium, ни Firewall нам не требовались. Зато было интересно поглядеть на Выбор ядра Linux. Тем более что всплывающая подсказка над этой кнопкой обещала, что это — Установка простого менеджера ядер Linux.

Перед этим я успел перезапустить Welcome — и увидеть, что кнопка про установку libreoffice с последней закладки исчезла: видимо, программа позволяет устанавливать «особо избранные» пакеты только один раз:

Дивиться этому обстоятельству мы не стали, а смело нажали кнопку с надписью Выбор ядра Linux.

Результат был где-то ожидаемый: открылось терминальное окно, точно такое же, как при установке LibreOffice, и в нём замелькали строки сообщений о ходе установки пакета akm. Последним их этих сообщений было слово Финиш:

Кстати, akm — это не аббревиатура автомата Калашникова, а программа, именуемая A Kernel Manager (и о которой я раньше не слышал). Однако она, как оказалось, широко известна в узких кругах применителей EOS, о которой написано, например, здесь. Пакет akm входит в состав фирменного инструментария этого дистрибутива, насчитывающего, кроме него, ещё немало пакетов.

Вообще-то, ознакомиться с eos-инструментарием (и другими дистро-специфическими компонентами) можно на любом зеркале репозиториев EOS. Например, на этом. Не потому, что он лучше других — просто стоит первым в списке зеркал файла /etc/pacman.d/endeavouros-mirrorlist…

В официальном репозитории Archlinux’а и даже в AUR’е большинства этих пакетов нет (пакет akm, отсутствует и там, и там). Хотя они используются, как говорят, в некоторых более иных, нежели EOS, дериватах Arch’а.

Пока я бегло знакомился с материалами по akm и eos-инструментарию, ранее мне неизвестными, установка пакета (давно) завершилась. После перезапуска Welxome кнопка Выбор ядра Linux исчезла со вкладки Установка программ (как перед этим случилось с кнопкой для установки libre
office). Зато программа akv возглавила секцию Система главного главного меню KDE:

Впрочем, программу эту можно запустить из командной строки терминального окна Konsole одноимённой командой:

Или, наконец, из строки минитерминала, вызываемого комбинацией клавиш Alt+F2

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

Легко догадаться, что пакеты, боксики которых отмечены (собственно ядро и его заголовочные файлы) установлены в системе. Прочие же доступны из официального репозитория. В данный момент установлено одно ядро (версии 5.16.16-arch1-1). Оно находится в разделе core и является загружаемым по умолчанию.

Ядро linux-lts (версия 5.15.31), также находящееся в разделе core, относится к так называемым «долгоигрющим»; оно имеет, как считается, повышенную устойчивость и увеличенный срок поддержки.

Два других доступных ядра относятся к категории кастомизированнх и располагаются в разделе extra.

Ядро linux-hardened (версия 5.15.31) основано на linux-lts с тем же номером, и собрано в расчёте на максимальную безопасность.

Ядро linux-zen (версии 5.16.16.zen1-1) оптимизировано для использования на настольных машинах и ноутбуках (но не на серверах), отличается, как говорят, повышенной скоростью загрузки и визуальным быстродействием (так называемой «отзывчивостью»).

Ни долгосрочная поддержка, ни повышенная безопасность меня не интересовали. Но про linux-zen я читал немало материалов, и он показался мне интересным. Так что, не смотря на ворчание Мануала (мол, глупостями ты, парень, занимаешься), я решил совместить приятное с полезным (и на akm посмотреть, и linux-zen заполучить). И потому в окне, приведённом на предыдущем скриншоте, отметил «зелёными птицами» две последние страницы списка и нажал кнопку Execute.

Сначала от меня в терминальном окне (то есть в Konsole) потребовали ~~удостоверить свою личность~~ ввести административный пароль:

После того, как я ~~предъявил справку, что не верблюд~~ это сделал, мне сообщили имена устанавливаемых пакетов, размеры их загрузки и распаковки, суммарные значения того и другого, сопроводив это вопросом — а приступать ли к установке:

А как же! — ответил я. И понеслась душа по кочкам… пока ядро и заголовочные файлы не установилися, и GRUB не перенастроился, и не последовало обычное в таких случаях предложение нажать Enter для закрытия терминального окна:

Теперь следовало перезагрузиться — чисто для порядку, чтобы убедиться, что с ядром linux-zen всё нормально. Я на короткое время отвлёкся от Welcome и отправил машину на рестарт.

Чуть задержался за разглядыванием меню GRUB’а: пункт с linux-zen к нему добавился, причём первым, по умолчанию. Дальше всё протекало плавно, без сообщений об ошибках. И всё вроде работало… за исключением сети, она не была видна от слова вообще.

Без сети работать нынче, разумеется, невозможно. Но я отложил этот вопрос до лучших времён. Ведь что хотел получить от akm — было получен: свою работоспособность он показал, а опции сборки ядра и поддержка им «железа» — не его вахта…

Так что я перезагрузился обратно, с исходным, то есть «ванильным», ядром, и пошёл окучивать две последние кнопки на последней вкладке. Напомню, они называются Просмотр всех Arch пакетов и Просмотр всех AUR пакетов. Это просто ссылки, которые ведут на официальный сайт проекта. Первая — на страницу поиска пакетов в официальном репозитории Arch’а:

Вторая кнопка вызывает страницу со списком пакетов репозитория AUR и средствами поиска среди них:

Надо подчеркнуть, что обе кнопки ничего, кроме вызова указанных страниц, не делают. А с найденными на них страницами следует поступать обычным образом, то есть устанавливать обычным образом, из командной строки, с помощью утилит pacman или yay.

Впрочем, управление пакетами в EOS — это совсем другая история. А в истории этой пора подводить итоги.

Предварительные итоги

Некоторое время назад я предположил, что в Welcome вкладка Установка программ — это единственная возможная альтернатива умолчальной вкладке Действия после установки в качестве стартовой. Тогда это действительно было чистым предположением. Но с тех пор я в своём мнении укрепился.

Более того, думается, что стартовая вкладка Welcome может быть разной на разных этапах приобщения к EOS. В свежеустановленной системе для первичных настроек послеустановочная страница будет задействована почти постоянно.

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

Главный же итог первых двух частей про EOS таков: Мухтар постарался. И его старание выразилось как в инсталляторе 1-й части, так и в Окне приветствия описанном в части 2.

История про KDE и EndeavourOS. Обновление системы, или UpdateInTerminal

В прошлой Истории говорилось о фирменной утилите QuickStart Installer, которая позволяет легко и просто устанавливать пакеты. Правда, больше ничего не позволяет. Да и пакеты способны установить не все, которые доступны в репозиториях, а только из ограниченного (хотя и довольно обширного) списка.

То есть перед нами не пакетный менеджер, пусть и не очень функциональный (вроде описанного ранее MX Packageinstaller), а просто установщик пакетов «на скорую руку», рассчитанный «на самых маленьких» (или, напротив, «на самых стареньких»).

Напротив, UpdateInTerminal, о котором пойдёт речь в этой Истории, — вполне полноценный инструмент для обновления системы. Он запускается, во-первых, из секции Система главного меню KDE:

После этого открывается терминальное окно, в котором сначала происходит синхронизация репозиториев с локальной базой пакетов, затем проверка обновлений оных, разрешение зависимостей, проверка конфликтов, и, после запроса на продолжение и положительного на него ответа, — собственно, обновление системы:

Во-вторых, как говорилось во 2-й части Историй про EOS, та же самая утилита UpdateInTerminal вызывается из окна Приветствия EOS:

Далее — всё, как сказано в предыдущем абзаце.

В-третьих, утилиту UpdateInTerminal можно запустить из командной строки терминала одноимённой командой. Смысл — в этом случае можно воспользоваться её опциями. Последних немного, но они есть:

	~/ UpdateInTerminal --help
	Usage: UpdateInTerminal [options]
	Options:
	    --noup     Don't check Arch & EndeavourOS updates.
	    --noaur    Don't check AUR updates.
	    --nt       Check updates in a new terminal window.
	    --sync     Run program 'sync' afterwards if updates were detected.
	    --keyring  Update keyring packages first. This may help on some PGP signature issues.

Из меню утилита запускается с опцией --nt, и это, товарищи, правильно. Среди прочих опций заслуживает внимания --noaur — обновление программ, установленных из AUR, не всегда желательно. Для чего могут быть нужны остальные опции (и нужны ли вообще) — пока не придумал.

Но в целом результат работы UpdateInTerminal идентичен обновлению системы штатными средствами пакетного менеджмента. И потому её можно считать не вредной (а иногда и полезной.

История про KDE и EndeavourOS. Установщик программ, или QuickStart Installer

Во второй части Историй про EOS говорилось про фирменное Приглашение этого дистра. Которое, помимо всего прочего, включает и вкладку Установка программ, с помощью которой можно установить несколько пакетов (вроде Libreoffice), которые майнтайнеры сочли этого достойными.

За три месяца, прошедшие со времени сочинения второй части про EOS соответствующий модуль Приглашения претерпел, однако, заметные изменения. Вкладка Установка программ, разумеется, никуда не делась, но нынче приобрела такой вид:

Назначение кнопок Просмотр всех… пакетов очевидно. А вот кнопка Выбор популярных программ вызывает утилиту QuickStart Installer, представляющую собой очень простой установщик пакетов:

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

Использование установщика — проще некуда: нужные секции списка разворачиваются, и желаемые пакеты отмечаются «птицами»:

После этого остаётся только нажать кнопку Install Now, ввести пароль для обретения прав администратора и наблюдать процесс установки:

Запускать утилиту QuickStart Installer не обязательно через Приглашение — это можно сделать и из главноего меню:

На этом функционал утилиты QuickStart Installer исчерпан: в ней нет ни поиска пакетов, ни средств получения информации об оных, нет и возможности их удаления.

То есть утилита эта ни в коем случае не является менеджером пакетов: она предназначена только для быстрой установки ограниченного круга программ. Если потребности применителя выходят за этот круг — ему придётся обратится к штатным средствам пакетного менеджмента дистрибутивов семейства Archlinux, о которых будет рассказано в одной из ближайших Историй.

KDE и EndeavourOS. Три Истории про управление пакетами: pacman и yay

В последних Историях мы рассмотрели два «фирменных» инструмента дистрибутива EOS для работы с пакетами — простой установщик пакетов QuickStart Installer и «обновитель системы» UpdateInTerminal. И убедились, что их функционала недостаточно для полноценного управления пакетами. Поэтому и сочинились три следующие Истории.

История 1. Менеджер пакетов pacman

Штатный менеджер пакетов для всех систем, основанных на Arch, носит имя pacman. Он был разработан Джаддом Винетом (Judd Vinet), создателем дистрибутива Archlinux, двадцать лет назад (первая версия — 2002 год), и с тех пор существует почти в неизменном виде.

Про пакеты Arch’а

Прежде чем говорить об управлении пакетами, необходимо сказать пару слов о пакетах вообще, в Arch baser системах в частности и в дистрибутиве EOS в особенности.

Коротко говоря, пакеты вообще — это формы распространения программ, каковых существует две основных: пакеты исходных текстов, и пакеты бинарников, то есть откомпилированных исходников.

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

Пакеты для дистрибутива Arch и его производных — файлы примерно такого вида:

yay-11.2.0-1-x86_64.pkg.tar.zst

Где yay — имя пакета (для примера), 11.2.0-1 — авторский номер версии и майтайнерский номер сборки, x86_64 — целевая архитектура сборки, то есть для машин с 64-битным x86 Intel-совместимым процессором. Возможное значение последнего параметра — any, то есть для любой архитектуры, можно видеть в пакетах словарей для проерки орфографии (но не самих утилит спеллинга), тем, иконок, бэкграундов и тому подобной косметики. Некоторые клоны Arch’а (и EOS в их числе) поддерживают сборки под ARM-процессоры, но о них мы говорить не будем.

Первый суффикс в имени пакета, pkg, показывает, что перед нами именно бинарный пакет, а не, скажем, архив исходников. Второй (tar) и третий (zstd) суффиксы указывают на то, что это tar-архив, скомпрессированный утилитой сжатия.

В качестве утилиты сжатия в настоящее время выступает zstd — эталонная реализация алгоритма Zstandard, Как ныне считается, алгоритм этот обеспечивает оптимальное соотношение между степенью сжатия и скоростью компрессии и декомпрессии. До недавнего времени оптимальной в этом отношении полагали утилиту xz (алгоритм LZMA), а ещё раньше вполне хватало gzip-сжатия (алгоритм Deflate).

Если посмотреть содержимое файлов пакетов (например, с помощью архиватора Arc, вызываемого из Dolphin’а), то в любом из них обнаружатся скрытые файлы (так называемые dot-файлы, поскольку их «скрытость» обозначается точкой в начала имени). Их всего три штуки (.BUILDINF, .MTREE, .PKGINFO), и содержат они метаинформацию. Прочие файлы пакета — собственно откомпилированные его бинарные компоненты:

Скриншот 1, декомпрессированный пакет yay

Из dot-файлов наиболее интересен для применителя .PKGINFO. Он содежит такие сведения о пакете, как его имя, номер версии, краткое описание etc., включая информацию о зависимостях:

Бинарные компоненты различаются в зависимости от характера пакета. Чобы убедиться в этом, достаточно сравнить между собой скриншоты 3, 4 и 5:

Скриншот 5. Структура пакета paper-icon-theme

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

Репозитории

В EOS поддерживается два репозитория. Первый — официальный, общий для всего Arch-семейства дистрибутивов (для России, например, такое зеркало). Из него берутся базовые пакеты (раздел core) и пакеты дополнительные (разделы extra), а также раздел multilib для пакетов поддержки 32-битных приложений в 64-битной системе. Все эти разделы поддерживаются участниками проекта.

Есть также раздел community, который поддерживается сообществом дистрибутива. Точнее, особо доверенным его участникам. Почему в целом весь репозиторий имеет статус официального для дистрибутива Arch. Он является основным и для всех систем, на Arch’е основанных.

Второй репозиторий — хотя и небольшой, но собственный репозиторий EOS (список зеркал — в файле /etc/pacman.d/endeavouros-mirrorlist). Он играет роль официального для этого дистрибутива, включая дистроспецифичные утилиты разного, преимущественно системного, назначения:

Большинство этих утилит имеет префикс eos в имени пакета. Несколько забегая вперёд, это можно определить такой командой:

~/ pacman -Ss '^eos-*'

Вывод её заодно покажет, какие из этих утилит установлены:

endeavouros/eos-apps-info 1.2.5-3 [установлен]
    Documentation about apps in the EndeavourOS repository.
endeavouros/eos-bash-shared 1.25-1 [установлен]
    Bash code shared by certain EndeavourOS apps.
endeavouros/eos-downgrade 0.3-1
    Downwgrade EndeavourOS packages (currently alpha quality).
endeavouros/eos-hooks 1.6-1 [установлен]
    EndeavourOS pacman hooks
endeavouros/eos-lightdm-gtk-theme 2.2-1
    EndeavourOS theme for lightdm-gtk-greeter
endeavouros/eos-lightdm-slick-theme 2.0-4
    EndeavourOS theme for lightdm-slick-greeter
endeavouros/eos-log-tool 1.4.15-1 [установлен]
    Gathers selected system logs and sends them to the internet.
endeavouros/eos-lxdm-gtk3 0.5.3-4
    Lightweight X11 Display Manager for EndeavourOS
endeavouros/eos-packagelist 2.0-1 [установлен]
    An application to gather and optionally install package lists from the EndeavourOS installer
endeavouros/eos-plasma-sddm-config 22.03.1.2-1 [установлен]
    EndeavourOS Theme for SDDM for Plasma
endeavouros/eos-qogir-icons 4-2 [установлен]
    A colorful design icon theme for linux desktops
endeavouros/eos-quickstart 1.3-2 [установлен]
    An application for getting a quick start with installing packages
endeavouros/eos-rankmirrors 2.3-1 [установлен]
    EndeavourOS mirror ranking tool
endeavouros/eos-sddm-theme 2.0-2
    EndeavourOS Theme for SDDM
endeavouros/eos-skel-ce-awesome 1.0-8
    pre user creation skel setup for Awesome EOS-CE
endeavouros/eos-skel-ce-bspwm 1.0-18
    Pre user creation skel setup for Bspwm EOS-CE
endeavouros/eos-skel-ce-openbox 1.0-14
    Pre user creation skel setup for Openbox EOS-CE
endeavouros/eos-skel-ce-qtile 1.0-9
    Pre user creation skel setup for Qtile EOS-CE
endeavouros/eos-skel-ce-sway 1.0-8
    pre user creation skel setup for SWAY EOS-CE
endeavouros/eos-skel-ce-worm 1.0-11
    pre user creation skel setup for worm EOS-CE
endeavouros/eos-translations 1.9-1 [установлен]
    EndeavourOS translation support
endeavouros/eos-update-notifier 1.17-1 [установлен]
    Software update notifier and 'news for you' for EndeavourOS users.

Правда, как показывают примеры таких EOS-утилит, как QuickStart Installer и UpdateInTerminal, префикс этот не обязателен.

Тем более, что в репозитории EOS имеются собственные сборки пакетов, прямого отношения к проекту не имеющие. Исходники их размещаются на Github’е, на сайтах разработчиков, и так далее.

Среди них — такие пакеты, как akm (управление ядрами Linux), инсталлятор Calamares, wrapper yay, о котором будет рассказано далее в третьей Истории, и некоторые другие.

Кроме официальных репозиториев, обще-Arch’евского и «фирменного» EOS’сового, существует ещё неофициальный Arch User Reposirory (AUR), также поддерживаемый применителями дистрибутивов этого семейства. Но не обязательно особо доверенными, а, что называется, «с улицы». На AUR действие pacman‘а не распространяется. И потому речь о нём также пойдёт позднее, во второй Истории.

Операторы, опции и аргументы

Как было сказано ранее, pacman существует уже 20 лет в почти неизменном виде. А вид этот таков. Любое действие в pacman выполняется с помощью конструкции, включающей, кроме одноимённой команды, операторы, его опции и аргументы. Оператор определяет одно из базовых действий в отношении пакета (пакетов), и он в единственном экземпляре является обязательным элементом конструкции.

Список поддерживаемых операторов (в русскоязычных материалах называемых также действиями или операциями) можно определить таким образом:

	~/ pacman -h
	использование:  pacman <действие> [...]
	действия:
	    pacman {-h --help}
	    pacman {-V --version}
	    pacman {-D --database} <параметры> <пакет(ы)>
	    pacman {-F --files}    [параметры] [файл(ы)]
	    pacman {-Q --query}    [параметры] [пакет(ы)]
	    pacman {-R --remove}   [параметры] <пакет(ы)>
	    pacman {-S --sync}     [параметры] [пакет(ы)]
	    pacman {-T --deptest}  [параметры] [пакет(ы)]
	    pacman {-U --upgrade}  [параметры] <файл(ы)>

	используйте 'pacman { -h --help}' вместе с другими операциями для просмотра параметров

Опции уточняют действие операторов — скоро мы это увидим на примере оператора -S, Как можно догадаться из вывода предыдущей команды, список опций, имеющих силу для того или иного оператора (а одна та же опция может сопровождать разные операторы), можно получить с помощью оператора -h в сочетании с любым другим оператором. Например, конструкция

~/ pacman -hT

даст такой вывод:

	использование:  pacman {-T --deptest} [параметры] [пакет(ы)]
	параметры:
	-b, --dbpath <путь> указать альтернативное расположение базы данных
	-r, --root <путь> указать альтернативный корневой каталог
	-v, --verbose выводить больше информации
	--arch  установить альтернативную архитектуру
	--cachedir <каталог> указать альтернативное расположение кэша
	--color <когда> раскрашивать вывод
	--config <путь> использовать альтернативный конфигурационный файл
	--confirm всегда спрашивать подтверждения
	--debug показывать отладочные сообщения
	      --disable-download-timeout
	                       use relaxed timeouts for download
	--gpgdir <путь> установить альтернативный домашний каталог для GnuPG
	      --hookdir

установить альтернативное расположение hook —logfile <путь> использовать альтернативный файл журнала —noconfirm не спрашивать подтверждения —sysroot работать с подключенной гостевой системой (только root)Исключение — оператор -V, который не предполагает ни опций, ни аргументов. А просто выводит сведения о текущей версии pacman‘а, авторских правах на него и лицензии, под которой он распространяется:

Отступление. На этом и последующих скриншотах вид пригашения командной строки может показаться необычным. Это связано с тем, что я вот уже 20 лет в качестве пользовательского shell’а по умолчанию всегда и везде использую zsh, причём настроенный в соответствие с Воззрениями покойного кота Мануала. В обсуждение причин вдаваться не буду — они веские и многочисленные. Замечу только, что с точки зрения настройки и последующей интерактивной работы традиционный Bash супротив него — всё равно что плотник супротив столяра…

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

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

~/ pacman -Ss '^eos-*'

Сочетание оператора и опции в командной будет объяснено уже в следующем разделе — забегая вперёд скажу только, что оно предписывает поиск пакетов в удалённом репозитории. А вот смысл маски аргументов расшифрую сейчас.

Маска эта указывает, что искомые имена пакетов должны содержать символы eos в начальной позиции (спецсимвол ^), а после дефиса включать произвольную последовательность символов (спецсимвол *). Одинарные (так называемые строгие) кавычки же экранируют спецсимволы. То есть заставляют считать ^ и * именно «символами специального назначения», а не просто элементами текста.

Оператор синхронизации -S

Дистрибутив EOS, как и все системы на базе Arch’а (по крайней мере, все, мне известные), разрабатывается по модели «скользящих» обновлений (rolling release). То есть изменения разной степени значимости вносятся в него постоянно, не следуя каким-либо релиз-циклам. В связи с этим важнейшим операторов pacman‘а оказывается -S, выполняющий синхронизацию локальной базы данных установленных пакетов с удалёнными репозиториями. Из чего следует, что любые действия с пакетами должны начинаться с такой синхронизации. Это делается командой:

eos# pacman -Syu

Отступление: обращаю внимание на приглашение командной строки. Во всех приведённых ранее примерах оно имело вид ~/. Он символизирует, что для выполнения последующей команды достаточно прав обычного пользователя. Форма же eos# подсказывает, что выполнение команды из последнего примера требует прав администратора. Права эти могут быть получены или разово, посредством sudo pacman, или на неопределённый срок, с помощью sudo -s (завершение действия административных полномочий — командой exit). Здесь и далее это — чистая условность, дабы не оговаривать каждый раз права на выполнение той или иной команды.

Возвращаемся, однако, к синхронизации. Непосредственно за неё, как уже было сказано, отвечает оператор -S. А далее вступают в силу опции данного оператора: -y обеспечивает пересчитывание уже синхронизированной базы, а опция -u обновляет те пакеты, которые в таком обновлении нуждаются.

В результате происходит полное обновление системы, которое во второй Истории мы выполнили с помощью соответствующего модуля Приветствия. Который, в свою очередь, вызывает EOS-утилиту обновления системы UpdateInTerminal.

Ознакомиться со всеми опциями оператора -S можно с помощью оператора вызова помощи:

~/ pacman -hS

Есть случай, когда оператор -S обходится без опций, но зато требует аргументов. Это — установка отдельных пакетов, имена которых в качестве таковых и выступают:

eos# pacman -S aisleriot akm

Как видно из примера, аргументов у данной команды может быть больше одного (в общем случае — сколько угодно, в разумных пределах, разумеется), а её исполнение требует прав администратора.

Однако у оператора -S есть опции, при которых она обходится правами обычного пользователя. Так, прежде чем устанавливать пакет, его не худо бы найти и убедиться, что это именно тот пакет, который нужен.

Поиск пакета, как уже говорилось, выполняется такой командой:

~/ pacman -Ss aisleriot
extra/aisleriot 3.22.23-2
    A collection of patience games written in guile scheme

А для получения сведений о пакете служит опция -i:

~/ pacman -Si aisleriot
Репозиторий          : extra
Название             : aisleriot
Версия               : 3.22.23-2
Описание             : A collection of patience games written in guile scheme
Архитектура          : x86_64
URL                  : https://wiki.gnome.org/Apps/Aisleriot
Лицензии             : GPL
Группы               : Нет
Предоставляет        : Нет
Зависит от           : guile  gtk3  librsvg  libcanberra  dconf
Доп. зависимости     : pysolfc: PySol card sets
                       pysolfc-cardsets: PySol card sets
Конфликтует с        : Нет
Заменяет             : Нет
Размер загрузки      : 11,96 MiB
Установленный размер : 26,88 MiB
Сборщик              : Jan Alexander Steffens (heftig) <heftig@archlinux.org>
Дата сборки          : Пт 17 июн 2022 11:04:25
Проверен             : MD5  SHA-256  Подпись

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

Ко всем остальным операторам pacman‘а приходится обращаться реже, чем к оператору синхронизации. Однако от этого они не становятся менее важными.

Оператор запроса -Q

Оператор -Q сходен по действию с оператором синхронизации, однако он обращается не к удалённым репозиториям, а к базе пакетов, установленных в системе. Так, команда

~/ pacman -Qs akm

отыщет соответствующий пакет, если он установлен:

local/akm 2.11-1
    Arch kernel manager.

Если пакет, указанный в качестве аргумента, не установлен, то молча, без всякого сообщения, вернётся пустое приглашение командной строки:

Скриншот 8. Если пакет в системе не установлен

Для установленного же пакета можно получить и более подробную информацию:

~/ pacman -Qi akm
Название             : akm
Версия               : 2.11-1
Описание             : Arch kernel manager.
...
Причина установки    : Явно установлен
Установочный скрипт  : No
Проверен             : Подпись

Команда

~/ pacman -Qe

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

accountsservice 22.08.8-2
adobe-source-han-sans-cn-fonts 2.004-1
adobe-source-han-sans-jp-fonts 2.004-1
adobe-source-han-sans-kr-fonts 2.004-1
akm 2.11-1
...
xterm 372-2
yad-eos 12.0-1.3
yakuake 22.04.3-1
yay 11.2.0-1
zsh 5.9-1

А команда

~/ pacman -Qd

выведет список пакетов, установленных в качестве зависимостей:

a52dec 0.7.4-11
accounts-qml-module 0.7-4
acl 2.3.1-2
adobe-source-code-pro-fonts 2.038ro+1.058it+1.018var-1
...
zimg 3.0.4-1
zlib 1:1.2.12-2
zstd 1.5.2-7
zvbi 0.2.35-4
zxing-cpp 1.4.0-1

Статус пакета, «явный» или «автоматический», присваивается при его установке — прямой ли командой pacman -S pkgname или как зависимость иного устанавливаемого пакета, соответственно. Однако статус этот можно поменять и вручную. Команда

eos# pacman -S --asdeps pkgname

отметит пакет-аргумент как автоматически установленный, а команда

eos# pacman -D --asexplicit pkgname

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

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

Действительно, смена статуса пакетов требуется не часто. Но когда требуется — то требуется без дураков. Потому что пакеты, установленные в как зависимости других пакетов, вместе с «материнским» пакетом и удаляются, что не всегда желательно. И в этом случае может быть целесообразно автоматический статус пакета на «ручной». С необходимостью обратной процедуры я не сталкивался, но теоретически могу представить, что и она может быть нужна.

А вот что видится необходимым — это возможность фиксации версий отдельных пакетов, то есть запрета их автоматического обновления по команде тотального апдейта системы pacman -Syu. Особенно важно это для программ из AUR’а. Во-первых, обновление больших и сложных пакетов связано с пересборкой не только их самих, но их зависимостей, что требует времени (иногда не значительного, а очень значительного). Во-вторых, иногда после этого программы, которые раньше успешно собирались, устанавливались и справно функционировали, после обновления теряли работоспособность полностью.

К сожаления, оператор -Q в pacman‘е не имеет опций, аналогичных команде apt-marc hold из пакетного менеджера apt в deb based системах. Для фиксации версий пакетов требуется прямое редактирование файла /etc/pacman.conf, Для чего его следует открыть от лица администратора в любимом редакторе, например так:

eos# nano /etc/pacman.conf

В нём отыскивается строка

#IgnorePkg   =

С неё снимается символ комментария

#, а в качестве значения этого параметра вписывается имя пакета, который хотелось бы защитить от обновлений, например:

IgnorePkg   =  COLMAP

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

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

~/ pacman -Ql eos-bash-shared
eos-bash-shared /etc/
eos-bash-shared /etc/eos-script-lib-yad.conf
eos-bash-shared /etc/eos-sendlog.conf
eos-bash-shared /usr/
eos-bash-shared /usr/bin/
eos-bash-shared /usr/bin/ChangeDisplayResolution
...
eos-bash-shared /usr/share/endeavouros/scripts/
eos-bash-shared /usr/share/endeavouros/scripts/eos-script-lib-yad
eos-bash-shared /usr/share/endeavouros/scripts/ksetwallpaper.py

А команда

~/ pacman -Qo UpdateInTerminal

решает обратную задачу, позволяя определить, к какому пакету принадлежит данный файл:

/usr/bin/UpdateInTerminal принадлежит eos-bash-shared 1.25-1

Наконец, команда

~/ pacman -Qdt

выводит список «осиротелых» пакетов. То есть зависимостей удалённых пакетов, более никакими другими пакетами не используемых:

cereal 1.3.2-1
cmake 3.23.2-2
coin-or-lemon 1.3.1-3
flann 1.9.1-7
glfw-x11 3.3.8-1
graphviz 5.0.0-1
ninja 1.11.0-1
opencv 4.6.0-3
proj 9.0.1-1
python-sphinx 5.1.1-1

Пакеты-«сироты» обычно имеет смысл удалять, дабы не захламлять систему. Хотя часто требуется удалить пакеты вне зависимости от их статуса. Чем мы сейчас и займёмся.

Оператор удаления -R

Как известно, пакеты не только устанавливают, но иногда и удаляют. Так, автор этих строк обычно начинает работу в любом дистрибутиве с удаления пакетов, которые он полагает лишними — не из экономии места на диске, а чтобы глаза не мозолили. Правда, EOS с точки зрения комплектации достаточно аскетичен, и излишеств в нём не много. Разве что аудио-, видео- и вообще медиаплейеры, которые я в любой системе истребляю безжалостно, заменяя их скромным, но универсальным mpv.

За удаление пакетов отвечает оператор -R. Просто удаление единичного пакета выполняется так:

eos# pacman -R aisleriot

Общесистемные конфиги пакета (они, как правило, располагаются в каталоге /etc) при этом сохраняются. Для того, чтобы удалить и их, требуется указать опцию -n:

eos# pacman -Rn akm

В результате из каталога /etc/ пропадёт конфиг «ядерного» менеджера akm.conf.

Опция -s при удалении пакета вызывает заодно и удаление тех его зависимостей (depends</code), которые в результате этого «осиротеют». Действие этой опции рекурсивно, то есть распространяется на зависимости «сирот первого уровня», если те также пополняют «сиротское семейство». И при массовом удалении пакетов тут возможны накладки, почему использование опции -s требует осторожности и аккуратности. То есть, как минимум, внимательного чтения списка удаляемых пакетов

Как подсказывает солдатская смекалка, удалять можно только установленные пакеты, в первую очередь неиспользуемые. Поэтому оператор -R логично применять вслед за оператором -Q. Так, с помощью последнего можно выявить все неиспользуемые пакеты:

~/ pacman -Qdtq go

А затем удалить свои находки:

eos# pacman -Rsn go
[sudo] пароль для alv:
проверка зависимостей...

Пакет (1)  Старая версия  Изменение размера

go         2:1.18.4-1           -409,20 MiB

Будет освобождено:  409,20 MiB

:: Удалить эти пакеты? [Y/n]

В данном примере неиспользуемый пакет нашёлся только один — язык программирования Go требовался только при установке утилиты yay, и более ни за чем не нужен (так называемая makedepends, см. Историю третью).

Однако при активном использовании AUR’а таких отходов жизнедеятельности, требовавшихся только при сборке его пакетов, может накопиться много. И есть смысл объединить две команды pacman в конвейерную конструкцию:

~/ pacman -Qdt | sudo pacman -Rsn -

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

Локальная установка

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

Аргументом при этом должно быть имя файла пакета, причём полное, а не так называемое basename. Необходимо также указание пути, даже если файл пакета находится в текущем каталоге. Например:

eos# pacman -U ./zfs-dkms-2.1.5-1-any.pkg.tar.zst

Теперь после нажатия на Enter последует такой вывод:

	загрузка пакетов...
	разрешение зависимостей...
	проверка конфликтов...

	Пакет (2)              Новая версия  Изменение размера  Размер загрузки

	endeavouros/zfs-utils  2.1.5-1                8,88 MiB         2,37 MiB
	zfs-dkms               2.1.5-1               17,11 MiB

	Будет загружено:     2,37 MiB
	Будет установлено:  25,99 MiB

	:: Приступить к установке? [Y/n]

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

Но в общем случае установка столь же быстра, как и при использовании оператора -S. Что особенно хорошо видно, если вместо пути к файлу пакета использовать полный URL последнего — а оператор -U позволяет и такую форму аргумента:

eos# pacman -U https://mirror.alpix.eu/endeavouros/repo/endeavouros/x86_64/zfs-utils-2.1.5-1-x86_64.pkg.tar.zst

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

~/ pacman -Ss '^zfs-*'

в таком вот виде:

С последующей установкой найденного:

eos# pacman -S zfs-dkms zfs-utils

В таком виде:

Скриншот 10. Установка пакетов поддержки zfs

То есть в EOS оператор -U оказывается невостребованным, по крайней мере, для меня: все нужные мне пакеты имеются либо в официальном репозитории Arch’а, либо в «фирменном» репозитории EOS, либо, на худой конец, в AUR’е.

Однако оказалось, что есть немало сторонних, то есть и близко неофициальных, репозиторев Arch’а, список которых приведён на странице с очевидным названием Unofficial user repositories. Скачанные с них пакеты формата *.pkg.tar.zst и следует устанавливать с помощью команды pacman -U path2/pkgname.

Правда, при беглом просмотре указанной страницы (а до просмотра не беглого у меня руки пока не дошли) для себя я там нашёл только один ресурс: Arch GeoTux, да и тот последний раз обновлялся на рубеже 19-го и 20-го годов. Однако в нём обнаружилось два полезных для меня бинарных пакета — COLMAP и Mic-Mac, которые имеются ещё только в AUR’а — но там их установка сопряжена со значительными трудностями.

Есть и ещё одна точка приложения оператора -U, узкая, но часто необходимая — получение доступа к AUR’у, о котором пойдёт речь в следующей Истории. Дело в том, что соответствующих утилит нет в официальном репозитории Arch’а от слова вообще. Нет их обычно и в собственных репозиториях дериватов Arch’а (исключения, кроме EOS — Manjaro и, возможно, ещё какие-то дистры, с которыми я не сталкивался).

И тут возникает задача, подобная той, что решал барон Мюнхгаузен, вытаскивая самого себя из болота за волосы: получить доступ к AUR’у с помощью средств, только в AUR’е и имеющихся. Задача эта, в отличие от задачи враля-барона, решаема, и со временем, в третьей Истории, будет рассказано, как.

Ресурсы про Arch и его pacman

Историю же про pacman следует завершить, хотя я рассказал не о всех возможностях этого пакетного менеджера. И тому было две причины. Первая — за 20 лет его существования о нём накопилось много информации, которую легко найти в сети. А о второй причине догадаются те читатели, которые осилят третью из нынешних Историй.

Итак, информация о pacman‘е богата и разнообразна. Во-первых, это встроенная система помощи, вызываемая командой с оператором помощи и одним из «заглавных» операторов. То есть операторов, передаваемых прописными буквами. Кроме буквы -V: в этом случае будет просто повторён вывод pacman -h.

Во-вторых, всегда следует помнить тётю Маню и верить тёте Мане — она знает всё ~~за облаву~~ за команду pacman:

~/ man pacman

Кстати, при чтении тексты встроенной помощи и соответствующих разделов man-страницы выглядят идентичными. Что это: man-страница создавалась из фрагментов встроенной помощи, или в последней выводятся подходящие вырезки из man-страницы — тайна сия велика есть.

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

В частности, это касается и самого интересного в контексте данной Истории — страницы про pacman, про Tips and tricks к нему, про Meta package and package group, про System maintenance.

Очень интересна страница pacman/Rosetta. Правда. она существует в английском оригинале и переводах на четыре европейских (немецкий, испанский, финский и португальский) и три азиатских (арабский и два каких-то CJK) языка. Русского перевода нет, но он и не нужен.

Так как статья вполне доступна даже тем, кто, подобно автору этих строк, не силён во вражьей мове: для её понимания достаточно как-то разбирать латиницу и знать названия пакетов. Ибо посвящена она сравнению pacman‘а с системами пакетного менеджмента таких дистров, как Red Hat/Fedora (dnf), Debian/Ubuntu (apt), SLES/openSUSE (zipper) и Gentoo (emerge). И предназначена в первую очередь для тех, кто запанибрата с одной из них.

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

Конечно, статья эта даёт некоторый материал и для сравнения возможностей фигурирующих в ней систем управления пакетами. Но я этим заниматься не буду. Потому что подошло время для нашей второй Истории — про репозиторий AUR и средства для работы с ним.

История 2. AUR и его wrapper’ы

В официальном репозитории Arch’а, по данным раздела Packages сайта проекта, более тринадцати тысяч пакетов; точнее, на данный момент (3 августа 2022 года) — 13191. Чего, казалось бы, должно хватить на все случаи жизни. Ан нет, часто бывает так, что каких-то позарез нужных пакетов в основном репозитории нет из-за специфических вкусов или задач применителя. И тогда настаёт время вспомнить про AUR.

AUR: введение

Так, до недавнего времени я целиком вписывался в основной репозиторий — за двумя мелкими, но необходимыми исключениями. Во-первых, мне для проверки орфографии позарез нужен русский словарь с обязательной буквой Ё (то есть когда еще вместо ещё считается ошибкой). А во-вторых, для иллюстрирования своих некомпьютерных сочинений («Историй про историю» и «Историй про геологию») мне необходима программа Google Earth Pro.

Ни того, ни другого в основном репозитории Arch’а нет. Как нет и фотограмметрических программ, необходимость в которых появилась у меня в последние месяцы. Причём последних нет и в репозиториях Debian’а (за буквально единичным исключением в виде COLMAP), и даже в Alt’овском Sisyphus’е (про остальные дистрибутивы и говорить не приходится). Так что последняя надежда оставалась на AUR.

И в своих надеждах я не обманулся. Поскольку AUR включает в себя (на то же 3 августа) 84308 наименований пакетов, было бы странно не удовлетворить через него любые потребности.

AUR vs более иные

Для сравнения: в нынешнем MX Linux 21.1, основанном на Debian stable и имеющем доступ ко всем пакетам его репозиториям (плюс не очень большое количество пакетов из репозитория собственного), на тот же день имеется 60822 пакета. Число определяется по выводу команды

~/ apt-cache search ^

в дистрибутиве MX Linu, основанном на Debiab stable, о котором немало говорится на этих страницах

Отступление. Интересно было бы сравнить эти числа с количеством пакетов в Ubuntu, включая PPA-репозитории, с таковым openSUSE вместе с его репозиториями semi-official и «домашними»: в обоих этих дистрах дополнительные, помимо официальных, репозитории представляют собой нечто вроде аналогов AUR’а. Однако число пакетов в обоих случаях учёту не поддаётся — по крайней мере, мне простого способа такого учёта не придумалось.

Также любопытно было бы посчитать число пакетов в бессчётных неофициальных репозиториях Slackware, но это вообще, похоже, задача не решаемая.

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

AUR: поиск нужных пакетов

Репозиторий AUR (что означает, пардон за тавтологию, — Arch Usr Reposirory) имеет удобное средство онлайового поиска пакетов по ключевым словам в имени и описании, только в имени, по имени майнтайнера, etc.

Скриншот 11. AUR: критерии поиска пакетов

С помощью этого инструмента мгновенно нашлись все фотограмметрические пакеты, описанные Владимиром Родионовым в соответствующей статье. Из которых практический интерес для меня представляли COLMAP:

и примкнувший к нему ~~Шепилов~~ OpenMVS:

А также самодостаточный пакет MicMac:

О том, что «ёжкин словарь» для проверки русской орфографии (пакет hunspell-ru-aot) и Google’вская Земля (пакет google-earth-pro) в AUR’е имеются, я помнил по тем временам, когда был активным применителем Antergos’а — косвенного предка EndeavourOS.

Кстати, в те времена в AUR’е находился и ещё один из необходимых мне пакетов — браузер Vivaldi. Но с тех пор он успел перекочевать секцию community официального репозитория. Где его легко найти с помощью уже тамошней службы поиска:

Так что Vivaldi — один из примеров того, как секция community официального репозитория Arch’а пополняется за счёт AUR’а, этим самым community и развиваемого.

Устройство AUR’а

По своему устройству AUR очень отличается от официального репозитория Arch’а и сделанного по его образу и подобию «фирменного» репозитория EOS, который также можно считать официальным для этого дистрибутива.

Официальные репозитории Arch’а и его дериватов (таких, как EOS и Manjaro) — это действительно хранилища (варианты перевода слова Reposirory, согласно Переводчику Google — также вместилище, склад и даже склеп), физически содержащие откомпилированные, архивированные и компрессированные файлы пакетов. Их «пакетная сущность» подчёркивается, как уже говорилось, обязательным суффиксом pkg в именах файлов.

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

Он содержит компрессированные архивы вида pkgname.tar.gz. Их главным, а часто и единственным компонентом является файл PKGBUILD — именно в нём с исчерпывающей полнотой описывается вся информация, необходимая для получения исходников пакета pkgname (с сайта разработчиков или ныне чаще с Githab’а), компиляции их и инкорпорации в файловую систему.

В этом же файле указываются зависимости собираемого пакета — необходимые для его работы (depends) или только для сборки (makedepends), опциональные, добавляющие функциональности (optdepends).

Кроме PKGBUILD, в архиве исходников могут оказаться и другие файлы, например, какие-либо patch’и, если они необходимы, или .SRCINFO, содержащие дополнительную информацию об «авторских» исходниках.

Посредством скачивания исходников, их компиляции и последующей интеграции компонентов в файловое древо (то есть директив файла PKGBUILD) устанавливается, наверное, более чем 99,9% пакетов, окученных в AUR’е.

Нештатная установка из AUR’а

Однако некоторые программы в нём скачиваются в бинарной форме. Это не значит, что они лежат в AUR’е физически. Как правило, это программы, на распространение которых их разработчиками накладываются те или иные ограничения. Например, они доступны только в бинарном виде.

Типичным примером такой «полусвободной» программы является Google Планета Земля (в девичестве Google Earth Pro). Она распространяется свободно (подобно бесплатному пиву, а не свободному слову), но только как бинарный пакет в deb- и rpm-форматах. И при этом разработчики хотят от пользователя знакомства с Политикой конфиденциальности:

Скриншот 16. Google Earth Pro. Лицензионное соглашение

Впрочем, не проявляя в этом настойчивости. Если, не читая указанного документа (а он достаточно длинный, весьма скучный и, подобно всем аналогичным, в меру брехливый), нажать кнопку Принять и скачать, предложение выполнить вторую часть намеченной программы последует незамедлительно:

Скриншот 17. Google Earth Pro. Панель загрузки

После этого в каталоге, определённом как место скачивания, появляется файл google-earth-pro-stable_current_amd64.deb. С которым можно расправиться и вручную — подобно тому, как я когда-то делал для установки пакетов в дистрибутивы, к тому вовсе не предназначенные.

Однако нахождение пакета google-earth-pro в AUR’е избавляет нас от этой докуки. И единственное, что нам требуется — программа доступа к этому «репозиторию». Программ таких много (то есть больше двух), именуются они wrapper‘ами и helper‘ами, и о них надо сказать несколько слов.

Программы wrapper’ы для AUR’а

Если мне удалось достаточно внятно рассказать, что происходит при установке пакета из AUR’а, то внимательному читателю (а других читателей, надеюсь, у меня нет) не составит труда догадаться, что pacman тут оказывается (почти) не при делах.

Точнее, он вступает в дело, когда пакет исходников найден, скачан, откомпилен и в виде бинарника валяется где-то на задворках мрачного системного кеша (в ~/.cache/yay/). Со временем мы увидим, что задача барона Мюнхгаузена таки решается. Но пока будем исходить из того, что она уже решена. А как она может быть решена — будет рассказываться в Истории 3.

Ну так вот, решение задачи доступа к AUR’у обеспечивают программы, называемые helper’ами. Некоторые из них выполняют только поиск и скачивание, другие — ещё и сборку.

Наконец, третьи способны установить собранный пакет — за ними закрепилось название wrapper’ов (на рiдной мове — обёрток) для pacman‘а. Как нетрудно догадаться из их названия, они обеспечивают именно то, на что pacman не способен. Из них до недавнего времени наиболее распространённым был yaourt — по крайней мере, он попадался мне чаще всего.

Кроме того, wrapper’ы, выполняющие полный комплекс работ по доступу к AUR’у, имеют графические «морды». Примерами их является Octopi на базе Qt, использовавшийся по умолчанию в Manjaro, и Pamac, бывший главным инструментом для управления пакетами в Antergos’е до его безвременной кончины.

Похоже, что wrapper’ы с графическим интерфейсом теряют свою популярность, поскольку, как считается, их использование может привести к поломке системы, в частности из-за неуправляемых частичных обновлений. Что же касается CLI-обёрток, то вроде наиболее популярной среди них ныне является yay, которая и будет предметом рассмотрения в Истории 3.

История 3. Обёртка Yay

Название обёртки yay расшифровывается как Yet another yogurt. Видимо, намекая на то, что именно этот йогурт наиболее полезен для здоровья (системы). Впрочем, если это название воспринимать не как аббревиатуру, то его можно перевести как «Ура». Что достаточно точно отражает эмоции при знакомстве с её возможностями.

Обёртка yay устанавливается в EOS по умолчанию при стандартной инсталляции этого дистрибутива в любой его комплектации. И, разумеется, соответствующий пакет в бинарном виде находится в (почти) официальном «фирменном» репозитории этого дистрибутива — endeavouros (например, здесь https://mirror.alpix.eu/endeavouros/repo/endeavouros/x86_64/).

Немного из прошлого

Обёртка yay была разработана осенью 2016 года. По крайней мере, в AUR’е она появилась 5 октября 2016 года благодаря парижанину, известному под ником Jguer, который с тех пор неизменно сопровождает пакет на Github’е. Можно предполагать, что он же является одним из его авторов. Сообщество должно знать своих героев — так что вот он:

В EOS пакет этот появился, начиная с первых, ещё до-релизных, версий дистрибутива. В качестве «сборщика» там указывается Antergos Build Server, и датировалась первая сборка, которую мне довелось видеть (в версии 9.0.2-1), 7 апреля 2019 года. В самом Antergos’е, когда я был активным его применителем (то есть практически до конца его существования), в качестве CLI-обёртки pacman‘а использовался yaourt. Так что, видимо, внедрение yay было одним из первых шагов по превращению Antergos’а в EOS.

В настоящее время пакет yay из репозитория EOS имеет версию 11.2.0-1, датируемую 17 июня 2022 года, URL исходников остаётся неизменным. И в качестве майнтайнера бинарного пакета выступает команда разработчиков EndeavourOS.

Кроме EOS, yay, насколько я знаю из сетевых источников, активно используется в Manjaro. Хотя, когда поглядывал на этот дистрибутив, будучи ещё применителем Antergos’а, никаким yay в нём и не пахло. Да и нынче на сайте Manjaro для установки главной героини нашей Истории официально рекомендуют использовать Pamac.

Обретение yay. Простой способ

Бинарный пакет yay практически не имеет зависимостей, необходимых для работы (кроме таких, как git и pacman, без которых жизнь в любой Arch based системе невозможна или очень затруднительна). Так что можно предполагать, что, будучи скачанным из указанного репозитория, он без проблем должен установиться с помощью команды

eos# pacman -U path2/yay

Однако, если это по каким-то причинам не произойдёт, или просто хочется сделать «всё по науке», то можно избрать другой способ, который ранее был назван способом Мюнхгаузена. Далее это было проделано с одним из клонов Arch’а, недавно возникшим дистрибутивом AaricKDE, установленным в виртуалке. Где и выяснилось, что он напрочь лишён собственных инструментов для работы с AUR.

Обретение yay. Способ «по науке»

Во-первых, надо позаботиться о том, чтобы были установлены пакет git и группа пакетов base-devel:

~/ sudo pacman -S --needed git base-devel

Оба они имеются в официальном репозитории Arch’а и по крайней мере второй, «групповой», пакет наверняка частично установлен; потому для «пущего наукообразия» для pacman‘а указывается опция --needed, препятствующая переустановке пакетов, в системе уже имеющихся.

После этого клонируем архив исходников искомого пакета в какое-нибудь подходящее место — у меня для этого заблаговременно создан каталог clones в моём домашнем каталоге:

~/ mkdir clones

в который и следует перейти:

~/ cd clones

Собственно команда клонирования выглядит так:

~/ git clone https://aur.archlinux.org/yay.git

Восле её выполнения в каталоге clones появляется субкаталог yay, в который мы и переходим:

~/ cd yay

Теперь остаётся только собрать пакет:

~/ makepkg -s

Здесь опция -s предписывается собирать недостающие зависимости из официального репозитория Arch’а, если они имеются — а в данном случае такая необходимая для сборки yay зависимость, как язык программирования go, имеется.

Сборка даже такого несложного и небольшого пакета, как yay, займёт некоторое время. А после её окончания в текущем каталоге обнаружится файл вида yay-*.pkg.tar.zst — это и есть собранный пакет. Остаётся последний штрих — установить его; напоминаю, что в качестве аргумента необходимо указать полное имя файла пакета и путь к нему, в данном случае это текущий каталог:

~/ sudo pacman -U ./yay-11.2.0-1-x86_64.pkg.tar.zst

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

~/ makepkg -si

Каковая в примере была дана исключительно в педагогических целях. Для проверки правильности выполненных действий в виртуальном AaricKDE с помощью свежесобранного yay были установлены пакеты hunspell-ru-aot и google-earth-pro — оба без всяких проблем.

Подготовка к использованию yay в более иных дистрибутивах

Однако, если мы имеем дело не с EOS (где yay устанавливается по умолчанию при стандартной инсталляции), то перед установкой каких-либо пакетов из AUR’а требуется ещё одно подготовительное действие — генерация базы данных разрабатывемых пакетов. Это делается так, причём один-единственный раз:

~/ yay -Y --gendb

Согласно сетевым источникам, эта команда используется при переходе на yay с какой-либо другой «обёртки». На счёт того, нужна ли она при установке, скажем, на чистый Arch (где никаких обёрток нет и не было), а пакеты из AUR’а устанавливались методом «грубой силы» (он же — метод Мюнхгаузена), указаний в источниках я не нашёл. Сам не не был ни в той, ни в другой ситуации.

Исходя из общих соображений, полагаю, что в случае «чистого Arch’а» приведённая команда не нужна. Впрочем, остаток своих дней я не собираюсь провести в сравнительном изучении особенностей различных клонов Arch’а, и потому вопрос этот меня не очень волнует. Ибо в EOS с его «искоробочным» он просто yay не имеет смысла.

Особенности wrapper’а yay

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

Правда, ответ на вопрос «что делать?» очевиден. Как говорил Шарль де Голль, «если вино налито — оно должно быть выпито, а если пакет установлен — он должен быть применён». И разумеется — по прямому назначению. Остаётся только определить, какое назначение yay — прямое.

Особенность первая: универсальность

Собственно, и тут вроде всё ясно: прямое назначение yay — работа с AUR’ом. Однако неожиданно (для меня) оказалось, что наша обёртка-героиня справляется с установкой бинарных пакетов из официального репозитория Arch’а и «фирменного» репозитория EOS не менее успешно, чем со сборкой исходников, окученных в AUR’е. Причём делает это не сложнее, чем специально предназначенный для того pacman. А подчас, как мы скоро увидим, и гораздо проще.

Видимо, разработчиками yay так и задумывалось: сделать из этой «обёртки дешёвой» универсальное средство для работы с любыми пакетами, предназначенными для дистрибутивов семейства Arch based, как бинарными, так и «исходниковыми». Причём средство, более простое в использовании, чем pacman с его helper’ами и более иным wrapper’ам. Этим и обусловлены многие особенности yay.

Так, в yay имеют место быть абсолютно все операторы и их опции, поддерживаемые pacman‘ом. И оказывают они точно такое же действие. Это — вторая причина, почему в первой Истории мне лень было подробно расписывать операторы и опции pacman‘а, ограничившись самым необходимым минимумом.

Тем более, что в pacman‘е можно найти не все операторы и опции, поддерживаемые в yay — последний обнаруживает некоторые уникальные свойства. В частности, он в некоторых случаях может выполнять свои задачи не только без опций (такое и с pacman‘ом бывает), но даже и без операторов.

В частности, это касается одной из самых часто используемых командных конструкций, вызывающей тотальную синхронизацию локальной базы данных с удалёнными репозиториями, которые могли претерпеть обновление со временем (и наверняка его претерпели — не зря же все клоны Arch’а развиваются по «скользящей» модели), локальное считывание обновлённой базы пакетов и (почти наверняка) обновление тех установленных в системе пакетов, которые в этом нуждаются.

То есть выполняется то, что при использовании pacman’а выражается командной конструкцией

~/ sudo pacman -Syu

Здесь, во-первых, вопреки собственным условностям я указал, что команда эта требует прав администратора, получаемых командой sudo. Во-вторых, напомню, что команда pacman выполняет синхронизацию и обновление только для пакетов, установленных из официального репозитория Arch’а (в случае EOS — также и для пакетов из его фирменного репозитория). Пакеты, собранные из AUR’а, ею не затрагиваются.

Чтобы синхронизировать и обновить все пакеты, в том числе и из AUR’а, потребуется аналог этой команды, использующий нашу «обёртку-героиню»:

~/ yay -Syu
[sudo] пароль для alv:

Более того, на самом деле и оператор синхронизации, и его опции не обязательны. Если ограничиться «голой» командой, результат будет тот же самый:

Должен обратить внимание, что обе формы команды синхронизации через yay не требуют явного предварения командой sudo, Или любого иного способа обретения привилегий администратора.

Ибо обёртка наша не только героична, но и весьма интеллектуальна. И сама в состоянии определить, когда административные привилегии на самом деле необходимы — например, при обновлении системы, установке и удалении пакетов, etc. И тогда она вправе спросить — «юзверь ты дрожащая, или право root’а имеешь?» И потребовать подтверждения в виде пароля той юзвери, которая действительно потенциально имеет это право.

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

Особенность вторая: минимизация ввода

Сказанное позволяет сформулировать ещё две особенности обёртки yay. Первая — минимизация ввода с клавиатуры: мало того, что команда обёртки вдвое короче команды pacman, так она ещё иногда позволяет обходиться не только без опций, но и без оператора. Пустячок, а приятно…

Минимизации ввода служит и автодополнение аргументов обёртки yay по нажатию клавиши Tab. Правда, не для всех оболочек. Но, как известно, большинство целевой аудитории ~~пьют одеколон «Свежесть»~~ используют bash, те, которые с претензиями (вроде автора этих строк) — ~~коньяк в международном аэропорту «Шереметьево»~~ применяют zsh, ну а любители ~~доигрывать вчерашнюю сику~~ пооригинальничать — упражняются с fish‘ем. И все эти три шелла в yay автодополнениями окучены.

Особенность третья: «интеллектуальность»

Следующая особенность нашей обёртки (суммарно, если начинать отсчёт от универсальности, уже третья) — встроенное напоминание о том, в каких случаях для выполнения её директив необходимы права администратора, а когда можно обойтись правами обычного пользователя.

Так, pacman при пропуске команды sudo в случаях её необходимости просто откажется от выполнения директивы (хотя о требовании прав root’а и сообщит). После чего директиву эту приходится повторять уже с предварением sudo. Что, разумеется, не смертельно, учитывая имеющиеся в любом шелле возможности повтора предыдущей команды или её части, таких, как sudo!! и Esc+.. Однако я о таких вещах постоянно забываю.

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

Вообще-то об особенностях yay можно говорить очень долго — я вкратце остановился только на тех, которые представляются важными. Не вообще, а лично для меня — внимание кого-то иного, вероятно, привлекут особенности совсем другие. Например, обращение yay с зависимостями (а обёртка наша позволяет ликвидировать в системе все makedepends любого пакета после его сборки).

Была у меня и мысль проделать ту работу, от которой я отказался в разговоре про pacman — дать полное описание операторов и опций yay, в том числе и уникальных. Но это показалось мне скучным — проще было бы перевести официальную документацию к обёртке-героине. Но я, завершая раздел об её особенностях, просто скажу пару слов об этой самой документации. Ведь это — тоже одна из особенностей yay.

Источники информации о yay

Если о pacman‘е в сети можно найти немало сведений, в том числе и на русском языке, то yay пока (?) таким вниманием не избалован. И основных источников информации об этой обёртке всего два: встроенная помощь, вызываемая командой

~/ yay -h

и, разумеется, безотказная тётя Маня:

~/ man yay

Правда, при ближайшем рассмотрении оказывается, что оба текста совпадают почти построчно. Охватывая, как честно предупреждает тётя Маня (а мы, товарищи, знаем, что она честна, даже если чего-то недоговаривает)

…только параметры, уникальные для Yay. Все прочие предлагается смотреть в man pacman.

Впрочем, кое-какие русскоязычные материалы по yay в сети найти можно. В частности, заслуживает внимания статья Что такое Yay. Особенности. Использование, автор которой представлен как некий пользователь сайта. Есть и немного переводных материалов, однако они несут столь отчётливые следы Транслита Гоши, что вызывают желание обратиться к оригиналу в виде указанной только что документации. Именно ею я и пользовался, составляя нижеследующий пример.

Продолжение Истории 3. Пример практического использования Yay

Как было сказано ранее, сочинять подробное руководство по yay мне было лениво. И, вместо этого, я предлагаю решение средствами этой героической обёртки конкретной задачи, которая встаёт передо мной при каждой установке системы «с нуля». Задача эта — перекомплектация системы, то есть удаление пакетов, которые майнтайнеры посчитали необходимыми, и доустановка тех, которые считаю необходимыми я.

Предварительные замечания

В данном примере объектом перекомплектации выступил дистрибутив EOS в KDE-редакции, необходимые действия основывались на многократно описанных ранее «Воззрениях» кота Мануала на Блогосайте и Цинии. Данное описание предназначено, во-первых, для демонстрации особенностей yay. А во-вторых, оно призвано служить шпаргалкой для меня, любимого — вдруг придётся переустанавливать систему себе или устанавливать ещё кому-то.

Для решения данной задачи была создана виртуальная машина с обычными параметрами (RAM 4 ГБ, целевой носитель 128 ГБ, 2 виртуальных «процессора», поддержка UEFI). Установка проводилась в автоматическом режиме, с автоматической же разметкой диска:

Скриншот 20. Параметры виртуальной машины

Первая синхронизация

Поскольку EOS развивается по модели «скользящих» обновлений, первое действие наше — синхронизация локальной машины с удалёнными источниками пакетов, перечитывание обновлённой базы данный и обновлением установленных пакетов, что делается так:

[alv@eos-kde ~]$ yay
[sudo] пароль для alv:

После ввода пароля на доступ к правам администратора и согласия со всеми предложениям процедура обновления совершается:

Будет загружено:     570,33 MiB
Будет установлено:  1655,69 MiB
Изменение размера:    -8,18 MiB

:: Приступить к установке? [Y/n]

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

[alv@eos-kde ~]$ yay -Ps

Обращая внимание на оператор -P — в pacman’е такого нет. Впрочем, поскольку никаких действий с пакетами мы пока не производили, ничего интересного там не видим — она нужна просто как точка отсчёта:

Первые установки: оболочка zsh и выпадающий терминал Yakuake

Теперь наступает время установки первого пакета. Практически по всех дистрибутивах Linux в качестве регистрационной пользовательской командной оболочки по умолчанию (так называемый login shell) используется bash. Что я полагаю позорным и преступным, ибо zsh, который я назначил себе на эту роль лет двадцать назад, подходит для неё гораздо лучше.

Отступление. Кстати, я в своём мнении был не одинок. Был некогда дистрибутив под названием Apricity, в котором тоже пользовательским шеллом выступал zsh. Однако он, едва возникнув, лет пять назад скончался в страшных судорогах, подобно турецкоподданному папе Остапа Бендера. Та же участь постигла и нашу Cintu, в которой zsh был login shell’ом со дня её возникновения .

Однако, чтобы обрести zsh в EOS, нужно сначала установить соответствующий пакет:

	[alv@eos-kde ~]$ yay -S zsh
	[sudo] пароль для alv:
	разрешение зависимостей...
	проверка конфликтов...

	Пакет (1)  Новая версия  Изменение размера  Размер загрузки

	extra/zsh  5.9-1                  6,60 MiB         2,22 MiB

	Будет загружено:    2,22 MiB
	Будет установлено:  6,60 MiB

	:: Приступить к установке? [Y/n]

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

[alv@eos-kde ~]$ chsh -s /bin/zsh

А также обзавестись его конфигом ~/.zshrc), соответствующим Воззрениям кота Мануала, и тем или иным образом перезапустить пользовательский сеанс. Впрочем, к обёртке yay, о которой нынче идёт разговор, это отношения уже не имеет.

Так что возвращаемся к управлению пакетам. На очереди к установке программа, без которой я всегда чувствую себя как без рук — выпадающий терминал (Drap-Down). На эту роль в любой системе с десктопом KDE есть единственный достойный (и достаточный) кандидат — yakuake:

█▓▒░alv@eos-kde░▒▓██▓▒░ Пт авг 12 05:04:58
~/ yay -S yakuake
[sudo] пароль для alv:

Теперь Yakuake, который всегда под рукой и вызывается по умолчанию клавишей F12, будет нашим главным плацдармом для работы yay. Обращаю внимание, что вид приглашения командной строки изменился — это следствие смены не терминальной программы. а регистрационного шелла:

Скриншот 22. Выпадающий терминал Yakuake

В штатном предустановленном терминале KDE, Konsole, оно будет таким же, как и в виртуальной (так называемой «текстовой») консоли, до настройки которой у нас дело дойдет со временем.

Удаление «излишеств»

А пока предстоит дело, которому я в любой системе предаюсь «отдельно, с большим наслажденьем» — истребление пакетов, полагаемых мною лишними. Правда, в EOS с его аскетической комплектацией по умолчанию фронт работы ограничен — в стандартной установке этого дистра даже офисного пакета нет, ни LibreOffice, ни, на худой конец, OpenOffice:

Отвести душу можно в секции Мультимедиа, где имеется аж три аудио- и видеоплейера — Dragon Player, Elisa и Медиаплейер VLC:

Скриншот 24. Нужно ли нам три мелиаплейера?

А, как говорил наш дорогой и незабвенный Леонид Ильич Брежнев, нам и два-то генеральных секретаря ни к чему. А про три медиаплейера и говорить нечего. Поэтому, чтобы никому из них обидно не было, истребляем их все:

~/ yay -Rns dragon elisa

Заодно вместе с их конфигами (опция -n) и зависимостями (опция -s). Причём в данной директиве достаточно двух аргументов — пакет VLC будет удалён как зависимость аудиоплейера Elisa:

Чтобы не остаться совсем без музыки и кинов, вместо из всех устанавливаем консольный медиапдейер mpv — по моим потребностям его более чем достаточно, и в обращении он (для меня) очень удобен:

~/ yay -S mpv

И зависимостей он за собой тянет по божески:

Скриншот 26. … а вот эта — нет

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

Установка необходимого

Установить же по первости осталось немного. Например, полюбившийся мне в последние месяцы тестовый редактор Kwrite — как оказалось, будучи настроенным должным образом, он пригоден не только для мелкой правки конфигов, но и для всамделишней сочинительской работы:

~/ yay -S kwrite

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

~/ yay -S vivaldi
разрешение зависимостей...
проверка конфликтов...

Пакет (1)          Новая версия   Изменение размера  Размер загрузки

community/vivaldi  5.4.2753.28-1         333,93 MiB        99,19 MiB

Будет загружено:     99,19 MiB
Будет установлено:  333,93 MiB

Среди дополнительных (optdepends) зависимостей Vivaldi числится пакет vivaldi-ffmpeg-codecs для воспроизводства каких-то проприетарных аудио и видео. Я c таковыми за последние годы не сталкивался ни в одной из своих систем, так что спокойно обхожусь без него. Но зарубку в памяти сделал: чем чёрт не шутит — а вдруг понадобится?

Кстати, теперь у нас в системе стало два браузера: Vivaldi добавился к наличествовавшему после стандартной инсталляции EOS Firefox’у. Последний мне нынче кажется грубым и неуклюжим. Да я и забыл, когда запускал его последний раз ради него самого — кроме как в deb- и rpm-системах для захода на официальный сайт проекта Vivaldi и скачивания оттуда свежей версии последнего.

В Arch based системах такой необходимости нет — Vivaldi имеется в общем для них всех официальном репозитории. И, вспомнив слова Л.И.Брежнева о нужности нам двух генеральных секретарей, подумал: а не пора ли отрешиться от старого мира, когда подчас требовалось не меньше двух браузеров на разных движках? И не снести ли Firefox к матери некоего Кузьмы?

Пацан подумал — пацан сделал:

~/ yay -Rns firefox firefox-i18n-ru

Больше никакого удаления пакетов у нас не предвидится. Так что самое время для страховки дать команду освобождения от «сиротских» зависимостей

~/ yay -Yc

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

~/ yay -Qdt

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

Обращение к AUR’у

Интересно, что за всё время сочинения этого примера я ни разу не обратился к yay ради того, для чего он был придуман: к установке пакетов из AUR’а. А ведь кое-какие из этих пакетов мне нужны гораздо больше, чем плезиозавры народу.

Среди таких пакетов — hunspell-ru-out, словарь для проверки орфографии русских текстов с обязательной буквой Ё (то есть в котором еще вместо ещё отмечается как ошибка). Ну что поделать, с юных лет не могу забыть, что великий русский шахматист, четвёртый чемпион мира, на просьбы позвать к телефону Алёхина имел обыкновение отвечать:

— Такого здесь нет, есть Алехин.

А в комментарии к одной из статей на эту тему мне напомнили, что превращение русского дворянина князя Лёвина в старого еврея Левина — тоже дело рук советских редакторов и экранизаторов графа нашего, пахаря.

Так что заберём у великого шахматиста незаконную Ё, и вернём её герою великого писателя. Для чего всего-то и нужно:

~/ yay -S hunspell-ru-out

Кстати, AUR — чуть не единственное хранилище пакетов от слова вообще, где hunspell-ru-out уцелел и продолжает обновляться до актуальных версий (на данный момент — 0.4.5). Вторым таким хранилищем до недавнего времени был Alt’овский Sisyphus. Но там развитие пакета прекратилось на версии, если эклер не подводит, 0.4.2. Да и установить этот пакет вне дистрибутивов семейства Alt несколько проблематично.

Второй жизненно важный для меня пакет из AUR’а — google-earth-pro, но о его установке достаточно подробно говорилось ранее.

Наконец, чуть выше несколько погорячился, говоря о ненужности второго браузера. Конечно, плагин к Vivaldi для доступа к сайтам типа Флибусты обычно работает безотказно. Но иногда сбоит. И что делать, если сбой пришёлся на момент, когда срочно потребовалась точная цитата из, скажем, «Повести о Ходже Насреддине»? Раньше я всегда в таких случаях полагался на свою память, но в последнее время обнаружил, что она иногда тоже даёт сбои. И понимаешь, что на всякий случай надо держать под рукой что-то типа Tor Broser, каковой и устанавливается из AUR’а:

~/ yay -S tor-browser

Причём в версии, соответствующей локали установленной системы, в моём случае — русской. Правда, пока я занимался установкой Tor Browser’а и, главное, подключался к сети Tor, нормальная работа плагина «Обход блокировок Рунета» восстановилась — сбои его редко продолжаются дольше нескольких минут. Ну ничего,
Tor Browser — штука такая, что её стоит держать на всякий пожарный случай.

Заключительные замечания

Ну а я, наконец, приближаюсь к концу Истории про yay и вообще всех Историй про управление пакетами. Ибо осталось упомянуть только, что в последние месяцы мне потребовались фотограммерические программы, о которых не так давно писал мой старый друг Владимир Родионов. И которые именно в AUR’е и представлены полнее всего.

Однако оказалось, что тема эта

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

что должна быть выделена в отдельное производство (тут-то мне и потребовалась цитата их бессмертной «Повести» Леонида Соловьёва). Что, надеюсь, произойдет в ближайшее время. А пока — нечто вроде маленького заключения по Историям о пакетах.

И просто заключение. Pacman или Yay?

В заключении осталось ответить на вопрос: удалось ли разработчикам yay создать универсальный инструмент доступа к программам для любых Arch based систем в любых их хранилищах, как к репозиториям бинарников, так и подюоркам сценариев установки из исходников PKGBUILD’ам. Не знаю, ставили ли они перед собой такую задачу. Но если и нет — значит, она решилась сама собой. Так что подведём краткий итог.

В пользу yay говорит:

в первую очередь однотипность действий в отношении пакетов из официальных репозиториев и AUR;
«маловукффие» как самой программы, так и её оперfторов и опций (вплоть до полгого иногда отсутствия оных;
«напоминалка» о вводе команды sudo, когда это действительно необходимо.

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

KDE и EndeavourOS. Yay: краткая шпаргалка по операторам и опциям

Обёртка yay, принятая в EndeavourOS (далее EOS) по умолчанию, «из коробки», обеспечивает доступ к официальным репозиториям Arch, к AUR Arch User Repository и к собственному репозиторию EOS. Как было сказано в Историях про управление пакетами в EOS, yay поддерживает все операторы и опции, что и pacman (плюс некоторые дополнительные), и не требует явного использования команды sudo — пароль администратора при необходимости (например, при установке или удалении пакетов) запрашивается автоматически. Кроме того, в некоторых случаях yay обходится без операторов и опций, обязательных для pacman‘а.

Всё это делает yay универсальным средством работы с любыми пакетами для систем на базе Arch’а, простота синтаксиса способствует его изучению, а лаконичность оного упрощает применение этой обёртки. Поэтому в настоящей шпаргалке собраны все необходимые и (почти все) практически достаточные команды yay.

Как известно, работа с пакетами любого rolling-дистрибутива начинается с синхронизации локальной базы данных пакетов с удалёнными репозиториями и тотального обновления системы. В yay из EOS для всех репозиториев это делается одной командой:

~/ yay -Syu
[sudo] пароль для alv:

Поддерживается и более простая её форма:

~/ yay
[sudo] пароль для alv:

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

После обновления системы чего смотрим её статистику, что делается так:

~/ yay -Ps

что, понятно, не требует административного пароля. И даёт такой вывод:

==> Yay версии v12.0.4
===========================================
==> Всего установлено пакетов: 966
==> Установлено сторонних пакетов: 3
==> Пакеты, установленные по запросу пользователя: 199
==> Суммарный размер, занятый пакетами: 5.6 GiB
==> Размер кэша "pacman"%!(EXTRA string=/var/cache/pacman/pkg/, string=1.6 GiB)
==> Размер кэша "yay"%!(EXTRA string=/home/alv/.cache/yay, string=192.0 MiB)
===========================================
==> 10 самых объёмных пакетов:
libreoffice-still: 416.9 MiB
vivaldi: 328.1 MiB
google-earth-pro: 244.1 MiB
firefox: 242.7 MiB
linux: 174.4 MiB
gcc: 171.3 MiB
linux-firmware: 158.4 MiB
linux-headers: 158.3 MiB
qt5-webengine: 151.5 MiB
gcc-libs: 137.8 MiB
===========================================
:: Выполнение запроса в AUR...

Из которого что-то может быть полезным, что-то — не очень. Хотя вывод этот может пригодиться как точка отсчёта.

Кстати, оператора -P в pacman‘е нет — он отвечает за вывод на экран неких результатов. Уникальна для yay и опции -s в таком контексте здесь она вызывает вывод статистики.

В контексте оператора синхронизации -S смысл опции -s, и означает поиск пакета. Например, так находим командную оболочку Zsh:

~/ yay -Ss zsh
...
extra/zsh-doc 5.9-3 (2.6 MiB 6.3 MiB)
    Info, HTML and PDF format of the ZSH documentation
extra/zsh 5.9-3 (2.2 MiB 6.6 MiB)
    A very advanced and programmable command interpreter (shell) for UNIX

А нашедши — устанавливаем её на замену скучному Bash’у. И в этом случае обходимся без опций, одним оператором синхронизации:

~/ yay -S zsh
Sync Explicit (1): zsh-doc-5.9-3
[sudo] пароль для alv:

Заодно устанавливаем и документацию к Zsh’у форматах Info, HTML и PDF:

~/ yay -S zsh-doc
Sync Explicit (1): zsh-doc-5.9-3
[sudo] пароль для alv:
...
(1/2) Arming ConditionNeedsUpdate...
(2/2) Updating the info directory file...

Без неё разобраться с этой оболочкой было бы не просто.

Пакеты подчас приходится удалять, например, осточертевшие пасьянсы:

~/ yay -R aisleriot
[sudo] пароль для alv:

Это — простое удаление, с сохранением общесистемных но не пользовательских конфигов и осиротелых зависимостей. От тех и других можно избавиться, добавив к оператору удаления -R опции n и s, соответственно. И аргументов у команды удаления может быть сколько угодно (в разумных пределах):

~/ yay -R libreoffice-still libreoffice-still-ru
[sudo] пароль для alv:

Таковы операторы и опции команды yay, самые нужные любому применителю в повседневной работе. Их хорошо бы заучить лучше, чем Моральный кодекс строителя коммунизма — здорово упрощает жизнь. В более специальных случаях следует бращаться к тёте Мане:

~/ man yay

Я, однако, оставляю это удовольствие ну очень заинтересованным читателям…

История про EndeavourOS и аппетиты его десктопов.

~/ yay -Syu
[sudo] пароль для alv:

Поддерживается и более простая её форма:

~/ yay
[sudo] пароль для alv:

После обновления системы чего смотрим её статистику, что делается так:

~/ yay -Ps

что, понятно, не требует административного пароля. И даёт такой вывод:

==> Yay версии v12.0.4
===========================================
==> Всего установлено пакетов: 966
==> Установлено сторонних пакетов: 3
==> Пакеты, установленные по запросу пользователя: 199
==> Суммарный размер, занятый пакетами: 5.6 GiB
==> Размер кэша "pacman"%!(EXTRA string=/var/cache/pacman/pkg/, string=1.6 GiB)
==> Размер кэша "yay"%!(EXTRA string=/home/alv/.cache/yay, string=192.0 MiB)
===========================================
==> 10 самых объёмных пакетов:
libreoffice-still: 416.9 MiB
vivaldi: 328.1 MiB
google-earth-pro: 244.1 MiB
firefox: 242.7 MiB
linux: 174.4 MiB
gcc: 171.3 MiB
linux-firmware: 158.4 MiB
linux-headers: 158.3 MiB
qt5-webengine: 151.5 MiB
gcc-libs: 137.8 MiB
===========================================
:: Выполнение запроса в AUR...

~/ yay -Ss zsh
...
extra/zsh-doc 5.9-3 (2.6 MiB 6.3 MiB)
    Info, HTML and PDF format of the ZSH documentation
extra/zsh 5.9-3 (2.2 MiB 6.6 MiB)
    A very advanced and programmable command interpreter (shell) for UNIX

~/ yay -S zsh
Sync Explicit (1): zsh-doc-5.9-3
[sudo] пароль для alv:

Заодно устанавливаем и документацию к Zsh’у форматах Info, HTML и PDF:

~/ yay -S zsh-doc
Sync Explicit (1): zsh-doc-5.9-3
[sudo] пароль для alv:
...
(1/2) Arming ConditionNeedsUpdate...
(2/2) Updating the info directory file...

Без неё разобраться с этой оболочкой было бы не просто.

Пакеты подчас приходится удалять, например, осточертевшие пасьянсы:

~/ yay -R aisleriot
[sudo] пароль для alv:

~/ yay -R libreoffice-still libreoffice-still-ru
[sudo] пароль для alv:

~/ man yay

Я, однако, оставляю это удовольствие ну очень заинтересованным читателям…

История про EndeavourOS и LXQt. Введение

История про EndeavourOS и LXQt. Установка

История про EndeavourOS и виртуальные консоли

Дистрибутив EOS, как и почти все современые дистры общего назначения, кроме узкоспециальных, по умолчанию грузится в графическом режиме с выбранным при инсталляции рабочим столом (в нашем случае KDE). Но, разумеется, никуда не девались и виртуальные консоли, обычно называемые текстовыми. Что не совсем верно, но для определённости будем использовать это название.

Вступление: кому лень — можно и не читать

Переключиться в консольный режим можно по комбинации клавиш Atl+Control+F2…F6, по Atl+F1 — возврат в графический режим умолчального десктопа. То есть доступно пять виртуальных консолей. Хотя поначалу радости от них мало: во-первых, буковки там маленькие и некрасивые, во-вторых, при русской локали ru_RU.UTF-8 вместо символов кириллицы, имеющихся, например, в приглашении командной строки, будут видны светлые квадратики:

Если же на экран файл с большим количеством русскоязычных вкраплений (например, мой конфиг оболочки ~/.zshrc), зрелище будет вообще душераздирающим:

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

Если читатель подумает, что это безобразие — уникальная особенность EOS, то он сильно ошибётся: вот уже многие годы майнтайнеры всех дистрибутивов, которые мне довелось видеть, не утруждают себя настройкой консоли вообще, и кириллической консоли в частности. Даже наш Atl не будет исключением. А ведь он издревле (заслуженно) гордился образцовой русификацией всего и вся, с конца прошлого тысячелетия, когда звался ещё Mandrake Linux Russian Edition, и выпускался IPLabs Linux Team.

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

Некоторые резоны в этом есть, хотя в принципе это не верно. Однако спорить по этому поводу я не буду, так как в опровержение в скажу точно в развитие известного высказывания АнтонПалыча Чехова:

У человека всё должно быть прекрасно: и операционка, и её дистр, и рабочая среда. И даже консоль.
© Моё

А, надеюсь, никому не придёт в голову называть прекрасными серые квадратики вместо русских букв. Разве что записному русофилу, полагающему прекрасным всё русское. Или, напротив, отъявленному русофобу, считающему: чем всё русское хуже — тем лучше. Ведь противоположности сходятся, не так ли?

Но мы-то, товарищи, знаем, что

…нет ничего слюнявее и плюгавее
Русского безбожия и православия.
©

Потому как

…если они не сходятся в теории вероятности,
То сходятся в неопрятности.
©

А вот побороть неопрятность в консоли — это вполне в наших силах.

Конечно, применителям deb based систем здесь совсем просто: у них есть утилита dpkg-reconfigure, способная решить проблему в «два притопа, три прихлопа», о чём здесь и далее некогда рассказывал кот Мануал.

Для более иных систем такого универсального решения нет — широкое внедрение systemd и спровоцированное им развитие иных стилей инициализации (таких, как openRC, runit, Dinit, S6, Suite66, Shepherd) существенно осложнили ситуацию. Возвращая нас на 20 лет назад и заставляя читать соответствующую документацию (что, скажу вам по секрету, надоело хуже… любой редьки, редиски и прочих овощей; не говоря уж о том, о чём подумали все испорченные мальчики).

Так что и я не претендую на универсальность решения, предлагаемого для EOS. Однако кажется, что может работать в ряде Arch based систем, к коим эта дистра принадлежит. Хотя разработчики «головного» Arch’а вроде бы отказались от использования каких-либо схем инициализации по умолчанию.

Два притопа, три прихлопа: экранный вывод и клавиатурный ввод

Этот раздел описывает кириллизацию консоли в EOS. Поэтому страдающим от болезни печени и избытка грамотности можно начинать чтение прямо с него.

Так вот, в нашем случае два притопа, то есть обеспечение экранного вывода кириллицы и её же ввода с клавиатуры достигаются редактированием (от имени администратора) одного и того же файла, например, так:

~/ sudo nano /etc/vconsole.conf

По умолчанию в моём случае он содержит единственную строку типа

KEYMAP=ru

которая ничему не соответствует и ничего не даёт. Её можно смело удалить (или, скажем, политкорректней, закомментировать). И вместо неё прописать две строки:

с описанием пути к имени шрифтового файла вывода (разумеется, и самого файла тоже), и
с тем же самым для файла раскладки клавиатуры.

Разумеется, и шрифт, и раскладка должны быть в кодировке UTF-8 и поддерживать символы кириллицы. Так что начнём со шрифта, дабы избавиться от вида самой большой неопрятности кириллической консоли — квадратиков вместо русских букв.

Таких шрифтов у нас есть в каталоге /usr/share/kbd/consolefonts/, например, LatArCyrHeb, LatGrkCyr, LatKaCyrHeb и тому подобные. Однако вопрос кириллических шрифтов в консоли — не тот, где может быть два мнения, моё и неправильное, идо неправильное мнение тут просто не имеет права на существование. Поэтому — веселее, моряк, веселее, моряк, делай так:

~/ yay -S terminus-font

и вот так (в том самом /etc/vconsole.conf):

FONT=ter-u32b

Изменения вступают в силу сразу после сохранения — бывшие квадратики волшебным образом преобразуются в символы кириллицы:

Скриншот 3. Кириллица вместо квадратиков

Второй притоп: клавиатурный ввод

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

~/ ls /usr/share/kbd/keymaps/i386/qwerty/ru*UTF-8*
/usr/share/kbd/keymaps/i386/qwerty/ruwin_alt_sh-UTF-8.map.gz
/usr/share/kbd/keymaps/i386/qwerty/ruwin_alt-UTF-8.map.gz
/usr/share/kbd/keymaps/i386/qwerty/ruwin_cplk-UTF-8.map.gz
/usr/share/kbd/keymaps/i386/qwerty/ruwin_ctrl-UTF-8.map.gz
/usr/share/kbd/keymaps/i386/qwerty/ruwin_ct_sh-UTF-8.map.gz

Они различаются только переключателем с латиницы на кириллицу (в консольных раскладках, в отличие от иксовых, он встроен в файл). Выбирается подходящий (например, Alt+Shift) и вписывается в поле KEYMAP.

В отличие от шрифтов, изменение консольной раскладки требует перезагруки системы (или её реинициализации иным образом). А файл /etc/vconsole.conf приобретает такой вид:

#KEYMAP=ru
KEYMAP=ruwin_alt_sh-UTF-8
FONT=ter-u32b
#FONT=latarcyrheb-sun32
#FONT=LatGrkCyr-12x22
#FONT=solar24x32

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

Третий прихлоп: служба консольной мыши

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

~/ yay -S gpm

И, переключившись в консоль, получаем право root’а и активируем его:

~/ sudo -s
eos# systemctl start gpm.service

После этого на чёрном фоне чёрной-чёрной консоли появляется маленький светлый прямоугольник, реагирующий на движения мыши. Это и есть её курсор в консольном воплощении/ С его помощью можно, зажав левую кнопку мыши, выделять фрагменты экрана (но не текста! — текст, продолжающийся за пределы экрана, выделен не будет) для автоматического помещения в экранный буфер. И в дальнейшем его (то есть буфера) содержимое можно вставить в любое место текущей виртуальной консоли щелчком средней кнопки (каковой у нынешних грызунов обычно является колёсико). Или любой из остальных четырёх, активных в данное время.

Приложение. EndeavourOS и LXQt

Занимаясь подбором систем, пригодных в качестве «Linux’а для пенсионеров», я немало времени и внимания уделил системам для настольных машин, в том числе и достаточно мощных. Но очень мало коснулся систем, подходящих для ноутбуков и особенно «левых» устройств типа телевизионных stick’ов. Хотя первые давно уже популярней десктопов, а вторые популярность постепенно набирают. Причём среди нашей ЦА распространение и тех, и других больше, чем «в мировом масштабе».

Постановка задачи

Специфика ноутов и stick’ов — в аппаратных ограничения. Так, ноуты, находящиеся в руках наших пращуров, по своим ТТХ, как правило, далеки от чудес лаптопной мысли, о которых можно прочитать сейчас в обзорах на Хоботе и 3ДэНьюсе. По которые можно сказать словами Ульянова в скобках Ленина, что

страшно далеки они от народа.

Что же касается stick’ов — то они более чем заслуживают звания даже не недо-book’ов и недо-top’ов, не недо-компов вообще.

В результате я (точнее, мы ещё с Мануалом) занялся подбором систем для машин такого рода. В качестве подопытных кроликов выступали:

мой ноутбук, важные в рамках сюжета характеристики его приведены здесь;
теле-stick INTEL Stick STK1A32SC, описанный здесь;
несколько виртуальных машин, сделанных в Virtualbox’е версии 6.1.36-1 с идентичными параметрами: CPU с двумя потоками, RAM 4 ГБ, диск 128 ГБ, включён режим EFI.

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

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

Следствие показало, что для всех трёх «конфигураций» такие среды, как Cinnamon и KDE показались слишком тяжёлыми в обоих опробованных дистрибутивах — EndeavourOS и MX Linux. Даже Xfce в последнем, не смотря на первоначальные восторги (а эта среда для MX является, по выражению майнтайнеров, флагманской, и редакция этого дистра производит впечатление «вылизанности»), при постоянной практической работе не потрясала своим быстродействием.

К тому же Xfce основан на библиотеках Gtk. И, хотя следов тлетворного влияния 4-й их версии в этом десктопе пока не заметно, она не отвечает условиям, сформулированным в одной из первых Историй про «пенсионерский» Linux. И как на ней скажется грядущий (и неизбежный, как распад мировой социалистической системы) «прогресс» Gtk-строения — можно только догадываться.

И тут я вспомнил о среде LXQt, на которую некогда поглядывал. Некогда огульно, вместе с LXDE, я относил её к недо-средам, хотя при ближайшем знакомстве понял, что был совсем не прав. Сделав зарубку на память — при случае покопаться с LXQt как следует.

Случай этот наступил сейчас, при подборе среды, хорошо работающей при не очень могучих ресурсах машины. И впечатления стали ещё более положительными. Конечно, по изощрённости настроек LXQt очень уступает Cinnamon, не говоря уже о KDE. Однако возможности конфигурирования её сравнимы с таковыми Xfce, а вот по простоте настройки она вревосходит всех своих собратьев. И быстродействие системы на отновительно сладых машинах, как реальной (ноутбук), так и виртуальной, оказалось на уровне.

Штатных приложений в LXQt немного — но это я считаю плюсом: ничто не мешает подбирать свои любимые приложения вместо навязанного набора, с которым не всегда знаешь, что делать. Например, в KDE после более чем двадцати лет применения назначение немалого числа его штатных приложений остаются для меня загадкой (шёпотом и в сторону: из чего я делаю вывод, чо приложения эти мне не нужны).

В общем, уже при предварительном огляде LXQt (в live-режиме дистров на базе всё того же Artix’а — последний за прошедшее время шибко усовершенствовался) я пришёл к выводу, что оба они — вещи стоящие. Но для себя избрал сладrую парочку, имена которой вынесены в заглавие этой истории: EOS и LXQt.

Почему EOS?

Тому было две причины. Первая — Artix, как я уже говорил, за минувшие пять лет весьма развился, но не совсем в том направлении, какое требовалось для нашей задачи: он стал коллекцией редакций, поддерживающих, кроме почти всех десктопов, также (почти) все существующие схемы инициализации, о чём я уже как-то упоминал.

Что порождает бессчётное количество образов установочных носителей, каждый из которых нуждался в скачивании и ознакомлении. А средих полудюжины поддерживаемых init-схем отсутствовали две самые распространённые и самые документированный — systemd и SysV. Прочие же init-схемы требовали изучения по крайней мере в той степени, чтобы сделать между ними осознанный выбор. А на это у меня как раз и нет времени.

И мне показалось антигуманным подвергать такому издевательству нашего потенциального применителя — пенсионера. И потому обещанного ранее продолжения Историй про Artix и всякоразные схемы инициализации не будет. По крайней мере, в этой жизни.

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

Что же до systemd’а, умолчального в EOS, то лично у меня с ним сложилось почти по поговорке: «не слюбилось, но стерпелось». Тем более что обычные пользовательские задачи (а их не так много) можно решать и там — с некоторым геморроем, конечно, но это — неизбежное следствие «прогресса».

Так что переходим к «во-вторых»: управление пакетами в EOS меня просто покорило. Как говорилось в одной из предыдущих Историй, обёртка Yay придаёт штатному pacman‘у универсализм при непревзойдённой лаконичности синтаксиса, способствующей простоте освоения и эффективности применения.

Покрутив некоторое время EOS с LXQt в виртуальной машине, я пришёл к выводу, что это и есть то, что надо по условиям задачи. И водрузил эту систему на свой многострадальный ноут.

Установка и особенности

В настоящее время в дистрибутиве EOS поддерживается десять редакций, из которых восемь с десктопами (практически всеми ныне развиваемыми, кроме не так давно реанимированного CDE), одна с оконным менеджером i3-wm и одна без графического рабочего окружения (No Desktop).

Вступление

Как говорилось в самой первой Истории про EOS, установка всех редакций EOS осуществляется с одного и того же образа.

Для этого на старте выбирается режим Online (требующий, естественно, подключения к сети), после чего с загрузочного носителя запускается (не считая Live-окружения) только инсталлятор (на базе Calamares’а), в котором выполняются все подготовительные действия, от локализации до выбора рабочего окружения.

После этого пакеты базовой системы, выбранного десктопа с его штатными приложениями и, возможно, кое-каким дополнительным софтом (список в некоторых пределах корректируем) скачиваются с одного из зеркал официального Arch’евского и «фирменного» EOS’овского репозиториев и разворачиваются в созданной файловой системе.

Таким образом достигается три цели:

кроме того, что установочный образ (ежемесячный снапшот) остаётся одним и тем же для всех редакций дистрибутива, он может быть любого возраста, по крайней мере, в пределах текущего и предшествующего «брендов» (таковыми нынче являются Artemis и Apollo, соответственно, глубже я не залазил);
версии всех установленных пакетов всегда будут актуальны и соответствовать таковым в репозиториях;
установка происходит одинаково для снапшота любого возраста и при выборе любого десктопа.

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

Подготовительные действия

Самое главное в этом разделе — то, что всё, сказанное далее, применимо к любой редакции EOS. Специфика редакции LXQt начинается только с подраздела Выбор десктопа.

Запуск инсталлятора, сеть, метод установки

Сразу после старта машины с Live-носителя EOS и загрузки его десктопа (а им является Xfce) на экране появляется окно Приветствия (Welcome). В нём две вкладки и в той, что откртыа, первой кнопкой идёт Start the Installer, то есть запуск инсталлятора системы, которую и надлежит нажать:

Первым же вопросом будет, как уже говорилось, выбор метода установки — Online или Offline. Второй метод не требует подключения сети, но результатом его будет установка копии загруженной Live-системы с дестопом Xfce и версиями пакетов, идентичными таковым на время создания снапшота. Ни то, ни другое нас не устраивает (особенно десктоп), поэтому жмём первую кнопку:

Скриншот 2. Выбор метода установки и проверка сети

При выборе метода Online подключение к сети, как легко догадаться, необходимо. Если соединении кабельное — в нынешних условиях соединение (почти) наверняка установится автоматически (как на скриншоте 2). Но машины, для которых выбирается дистр с десктопом LXQt (не очень мощные ноуты и теле-stick’и), скорее всего, подключаются к сети по WiFi’ю, что потребует некоторой настройки. Каковая, впрочем, скорее всего, сведётся к опознанию среди доступных соединений (а их в многоквартирном доме нынче может быть весьма немало) своего и вводу своего пароля для доступа к нему:

И то, и другое с большой долей вероятности нашим пенсионером благополучно забыто (или записано неизвестно где). Однако опознать своё соединение обычно довольно просто: представители Интернет-провайдера, осуществляющего подключение, не очень утруждают фантазию, и в качестве имени подключения используют аббревиатуру своей фирмы плюс номер квартиры, а в качестве пароля — номер телефона, с которого поступил заказ.

Разумеется, всё это — временное решение (а вы что подумали?). И пользователь в любой момент может легко поменять и то, и другое. Однако мы-то с вами знаем, что нет ничего более постоянного, чем временное решение. И обычно оно таковым и оказывается. Что в данном случае пойдёт нам на пользу…

Локаль и клавиатура

Разобравшись с сетью, кнопку Online можно нажимать безбоязненно. Она вызывает окно приветствия инсталлятора, которое сопровождается определением языка — в моём случае он каждый раз оказывается русским (без всякого моего в этом участия). Русскими будут и остальные локально-зависимые параметры. А время будет, как ни странно, московским:

Скриншот 4. Локально-зависимые параметры

Раскладка клавиатуры — тоже некоторым образом локально-зависимый параметр. И тут надо напомнить, что инсталлятор EOS — первый из виденных мной таковых на базе Calamares’а, который понимает, что раскладок может быть больше одной, и случайно одна из них может оказаться русской, каковую он и предлагает по умолчанию. Не забывая, что при установке нужна как раз английская.

И здесь можно спокойно останавливаться на родной кириллице, и даже указать её вариант. По умолчанию это — Default, что нынче соответствует winkeys, но можно выбрать и любой другой из обширного списка:

Скриншот 5. Выбор раскладки и её варианта

Например, я с давних пор предпочитаю вариант typewriter (legacy) — это стандарт для советских пишущих машинок (а в пост-советское время пишущих машинок у нас, кажется и не делали).

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

Разметка диска и выбор ФС

При разметке диска своего ноута я целиком положился на автоматику — это гарантия того, что не будет забыто про EFI-раздел достаточного (я бы сказал, очень более, чем достаточного) объёма. Кроме того, нынче я вовсю использую «спящий» режим, без раздела подкачки невозможный. А раздел этот также создаётся автоматически:

Скриншот 6. Автоматическая разметка диска для использования «спящего» режима

Правда, раздел подкачки требуется не простой, а очень большой: вдвое больше объёма оперативной памяти. Забегая вперёд, скажу, что у меня при 4 ГБ RAM swapr-раздел был на автомате создан более чем в 8 ГБ:

Скриншот 7. Утилита cfdisk: итоги автоматической разметки

Я не призываю следовать моему примеру: автоматическая разметка приемлема только в том случае, если система устанавливается на «чистый» носитель. Или — на носитель, всем содержимым которого можно пожертвовать. В противном случае придётся прибегнуть к ручной разметке. Я о ней говорить не хочу, но в сети можно найти много материалов на эту тему, рассмотрение коих оставляется заинтересованным лицам.

При создании файловых систем на создаваемых разделах я положился на умолчания инсталлятора. Собственно, для EFI-раздела никакого выбора и не предлагается: он обязан нести файловую систему FAT32, иначе машина просто не загрузится. А для раздела, которому после установки суждено будет стать корнем файловой иерархии, кроме умолчальной ext4, можно определить btrfs или xfs.

Скриншот 8. ФС для корня: варианты выбора

Я последние годы придерживаюсь умолчания установщика, и вам того же желаю. Ибо xfs создавалась очень давно и совсем для других целей. А btrfs, напротив, возникла относительно недавно, и (пока?) не может считаться… выражаясь политкорректно, окончательно отлаженной.

Выбор десктопа и пакетов

Здесь уже начинается специфика редакции LXQt, отличающая её от всех остальных разновидностей дистрибутива EOS

Раздел вместе с несомой им файловой системой создаётся для размещения на нём системы просто. Вот тут и наступает психологический момент для выбора рабочего окружения, которое лицо системы и определяет. Впрочем, в данном случае выбора нет по условиям задачи — таким окружением должно стать LXQt:

Здесь при выборе любого десктопа на предыдущей стадии предлагается установить базовые и разделяемые (common) пакеты, включая Иксы, а также Firefox с пакетом локализации:

Скриншот 10. Список устанавливаемых пакетов

Оба списка редактируемы, хотя для базовой части это не рекомендуется. Да и просмотр списка её пакетов показывает, что удалять здесь (даже при моей страсти истреблять всё для меня лишнее) особенно нечего. Разве что можно проредить список шрифтов за счёт noto-fonts и семейства adobe-sans:

Я делаю это не из жадности и экономии. Но и тот, и дркгой пакеты включают в себя
огромное количество шрифтов с поддержкой языков Южной и Юго-Восточной Азии, очень востребованных в наших Среднерусских палестинах. Вывод их списка занимает три четверти всего списка шрифтов (если не больше). И, когда много экспериментируешь со шрифтами, пролистывание его раздражает до чрезвычайности.

Впрочем, и удалить эти шрифты получается, если повезёт. Например, в KDE-редакции шрифты семейства Noto интегрированы с этим десктопом, и удаление их из списка удаляемых пакетов к ожидаемому результату не приводит.

А вот в редакции LXQt, как показали результаты описываемой установки, отмеченные на исключение из списка устанавливаемых шрифты Noto после установки системы не обнаруживаются в ней от слова вообще. Правда, шрифты семейства adobe-sans, которые я пытался подвергнуть той же участи, в итоговую инсталляцию всё же просочились — возможно, как единственные моноширинный в наборе LXQt. Но зато потом и удалялись он без труда.

В принципе, для меня было бы безболезненным удаление Firefox’а с его локалями. Потому как последние годы в любых системах я запускаю этот браузер один раз и с единственной целью: зайти на официальный сайт проекта Vivaldi и установить оттуда этот лучший интернет-инструмент всех времён и народов из deb- или rpm-пакета.

В EOS (и сородичах) такой необходимости нет: Vivaldi нынче имеется в официальном репозитории Arch’а, и может быть установлен оттуда в любой момент штаными средствами дистрибутивов этого семейства. Однако привычка держать минимум два браузера, и на разных движках, стала второй натурой с допенсионных времён…

Выбор LXQt в качестве десктопа на предыдущей стадии автоматически приводит в включение в кандидаты на установку соответствующих пакетов. Развёрнутый их список можно видеть на следующем скриншоте:

Список довольно короткий, но не из жадности или лени майнтайнеров, а потому что в LXQt вообще мало штатных приложений. И, насколько я понимаю, в этот список они включены чуть ли не все. Так что вычёркивать из него что-либо просто грешно. Тем более, что кое-какие из них явно заслуживают внимания. Например, текстовый редактор FeatherPad, чуть ли не единственный в многочисленном семействе *Pad’, поддерживающий мультидокументный интерфейс (MDI, то есть по простому вкладки).

Проверка на вшивость: создание аккаунта

Определившись с пакетами, переходим к следующему номеру нашей программы — созданию первого пользовательского аккаунта. Дело ответственное вдвойне. Во-первых, проверка на вшивость настроек раскладки клавиатуры. Напомню, что во всех инсталляторах на базе Calamares’а, с которыми я раньше сталкивался, именно здесь и была засада. Если ранее была выбрана русская раскладка клавиатуры, то как раз здесь обнаруживалось, что и поля учётной записи пользователя заполняются кириллицей (без малейшей возможности переключиться на латиницу).

Чего категорически нельзя — логин, пароль и имя хоста должны включать только первые 127 символов кодовой таблицы. И это известно каждому младенцу линуксоиду не хуже, чем рецепт очистки политуры, Так что приходилось возвращаться к настройкам клавиатуры (благо кнопка Назад ещё работала), и менять раскладку на американскую английскую, каковая в установленной системе и оказывалась единственной — кириллизацию следовало выполнять уже средствами выбранного десктопа.

Так вот, в инсталляторе EOS это безобразие изжито, и учётные данные вводятся как надо, латиницей:

Скриншот 13. Создание пользовательского аккаунта

Которую при желании можно сменить на кириллицу по Alt+Shift — только зачем нужна кириллица при установке системы? Другое дело, что те же раскладки и их варианты, а также переключатель оных, сохраняться и в установленной системе.

Второе, чем определяется важность создаваемого при инсталляции пользовательского аккаунта — его несколько привилегированное положение. Оно возникает, если стоит галочка Использовать тот же пароль для аккаунта администратора. Это не значит, что администратор получает какой-то другой пароль — пароля у него как раз нет (хотя аккаунт root’а есть). Просто пользователь причисляется к ~~лику святых~~ группе wheel. И членство в этой группе даёт ему право получать привилегии root’а командой sudo после ввода своего собственного, пользовательского, а не административного пароля.

Как я уже говорил, аккаунт root’а пароля по умолчанию не имеет. Но его можно задать, если снять галочку с указанного бокса. И тогда для доступа к административным правам можно будет использовать команду su. Вот только я лично избегаю это делать — раньше получение прав администратора обеими командами, su и sudo, вызывало путаницу (в обсуждение причён чего здесь вдаваться не буду). Сейчас вроде таких проблем уже нет, но sudo всё равно гибче в настройках и использовании, а также удобней в обращении.

И, наконец, опция Автоматический вход в систему по умолчанию выключена. Включать ли её — дело личной параидальности или, напротив, отсутствия оной. Я почти всегда включаю. За исключением первой установки какой-либо системы, дабы поглядеть на дисплейный менеджер. А так — SDDM’ов я не видел, что ли?

Завершающие штрихи

Здесь опять не будет ничего специфического для редакции LXQt — штрихи, завершающие установку, одинако для всех вариантов дистрибутива EOS.

Резюме

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

установку локально-зависимых параметров;
настройку клавиатуры;
создание на целевом носителе новой таблицы разделов в GPT-стиле;
разбиение целевого носителя на определённые ранее разделы, создание на них файловых систем и раздела подкачки;
настройку загрузочного раздела, который будет смонтирован в /boot/efi;
собственно установку EOS.

Всё это достаточно подробно описано словами (правда, английскими) и сопровождается картинкой, отражающей новое разбиение целевого носителя:

Скриншот 14. Резюме предварительного этапа

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

Собственно установка

Если если все необходимые коррективы в параметры предыдущих стадий сделаны, или в них просто нет необходимости — нажимается кнопка Установить, и, после предупреждения о необратимости дальнейших действий, установка начинается:

Теперь возврат к прошлому невозможен — процесс можно только прервать нажатием кнопки Отмена. Установка много времени не занимает, хотя я так ни разу и не удосужился его засечь.

Перезагрузка

В сообщении об окончании установки предлагается либо перезагрузить машину, либо вернуться в Live-окружение. Выбираем первый вариант (правда, отметить «птицей» боксик Перезагрузить необходимо: самому):

На этом вахта инсталлятора EOS заканчивается — после перезагрузки перед нами готовая рабочая система.

После установки

После перезагрузки появляется либо окно авторизации дисплейного менеджера с предложением ввести пароль (если автоматический вход при установке не был включён):

Либо, в обратном случае, как я обычно делаю, сразу рабочий стол LXQt с окном приветствия EOS, то есть

Welcome. Но это уже другое Welcome, одна из задач которой — сразу выполнить первоочередные действия в свежеустановленной системе. Именно на них мы и остановимся, так как целиком Приветствие было описано во второй Истории про EOS.

Итак, перед нами следующая панель:

Скриншот 18. Welcome, Действия после установки

Не забываем, что перед нами дистрибутив, развиваемый по модели «скользящих» обновлений, то есть такой, в котором почти каждый день что-нибудь да меняется — и это следует понимать не фигурально, а почти буквально. То есть любые действия в нём должны начинаться с синхронизации локально установленных пакетов с зеркалами удалённых репозиториев.

Настройка зеркал, обновлений и очистки кеша

И начать надо с обновления списков самих зеркал. И именно это действие вызывается одноимённой кнопкой, стоящей во главе первоочередных задач применителя любой rolling-системы, в том числе и EOS. Нажатие на эту кнопку вызывает полный список зеркал по странам, по умолчанию подключены только российские https-зеркала:

Тот же самый список можно получить в любой момент времени без всякого Welcome, а из секции Система главного меню любого десктопа, поддерживаемого EOS, ибо кнопка из Приветствия просто вызывает утилиту Reflector Simple.

Проверка https-зеркал России ранжирует их по быстродействию следующим образом:

Скриншот 20. Обновление зеркал from Russian

Добавление к списку https-зеркал также Швеции увеличило общее их число до девяти, причём шведские зеркала по быстродействию превзошли все российские, кроме одного:

Я выбрал зеркала шведского происхождения, памятуя старые времена пятнадцати- и двадцатилетней давности, когда я работал во FreeBSD и Source Based дистрибутивах Linux, и меня вопрос быстродействия зеркал волновал, и весьма сильно: российские серверы тогда работали… так себе, а самыми быстрыми показывали себя скандинавские и голландские, и первенство среди них было за шведскими. Что ж, относительная картина сохранилась и сейчас, хотя российские зеркала стали гораздо быстрее… Так что я сохранил их в mirror-листе (то есть в файле /etc/pacman.d/mirrorlist).

И теперь пришло время воспользоваться новым mirror-листом, нажав следующую кнопку — Обновить систему. Она вызывает фирменную EOS-утилиту UpdateInTerminal, о которой не так давно говорилось в соответствующей Истории:

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

В сущности, UpdateInTerminal дублирует функции команды yay -Syu, распространяясь как на официальный репозиторий Arch’а и «фирменный» репозиторий EOS, так и на AUR (каковую в форме yay и проще исползовать в дальнейшем). Её преимущество — с её помощью легко выполнить тотальную синхронизацию и обновление системы при первом запуске дистра ещё до того, как применитель успел ознакомиться со средствами его пакетного менеджмента.

Специфика rolling-модели развития дистрибутивов семейства Arch такова, что в локальном кэше /var/cache/pacman/pkg накапливается немало отходов жизнедеятельности, так как по умолчанию там хранится три предыдущие версии обновляемых пакетов. В результате команда du показывает, что объём указанного каталога может достигать пяти-шести гигабайт. Сократить масштабы бедствия можно с помощью кнопки Настройка очистки пакетов. В вызываемом ею окне я урезал число предыдущих версий обновляемых пакетов до 1, и всегда отмечаю опцию Remove uninstalled but still cached packages now:

Скриншот 23. Настройка очистки кэша пакетов

Свой ноут я после установки EOS в LXQt-редакции практически ещё почти не использовал. Но на активно пользуемом десктопе это сократило объём системного кеша почти на треть — от более чем 5 до 3,5 ГБ.

Установка программ

В Историях про EOS, pacman и yay говорилось об управлении пакетами вообще и их установке в частности. Однако кое-какие пакеты можно установить из Welcome сразу же после первого запуска. Для чего следует перейти на вкладку Установка программ и нажать на ней кнопку Выбор популярных программ для установки:

Скриншот 24. Установка некоторых программ

Нажатие на эту кнопку вызывает не что иное, как фирменную утилиту EOS под названием QuickStart Installer, которая представляет собой простой установщик программ, который был описан ранее.

После запуска любым образом, из Welcome ли, или из главного меню, открывается такое окно:

Скриншот 25. Список пакетов, сгруппированных по назначению

И тут следует понимать, что QuickStart Installer — это никакой не менеджер пакетов типа Synaptic’а в deb based системах или даже не Packageinstaller из MX Linux, а именно и только средство для быстрой установки пакетов. Причём не всех доступных в репозиториях, а только сподобившихся такой чести.

У QuickStart Installer‘а нет даже функции поиска пакетов. То есть надо разворачивать нужные группы из списка и отмечать в них «птицами» пакеты, которые требуется установить. Уже установленные, например, при первичной инсталляции, пакеты будут даны полужирным шрифтоначертанием.

Возникает вопрос — а за каким зелёным такой Installer нужен? Я ИМХую так, что исключительно для быстрой установки сразу после первого запуска системы — тех, которые позарез необходимы сразу и навсегда. Например, браузера Vivaldi: тот, кто поработал с ним достаточно долго, без него чувствует себя как без глаз (поскольку на другие браузеры и смотреть не может) и без рук (а о практическом их применении и говорить нечего).

Так что разворачиваем секцию Browsers, что идёт второй на предыдущем скриншоте и помечаем его «птицей»:

Хорошо бы заодно и удалить выделенный полужирным Firefox (если ранее мы не отказались от его установки). Но увы — функция удаления пакетов в QuickStart Installer‘е также отсутствует. Так что остаётся только нажать кнопку Ibstall Now в нижней части окна, ввести свой пользовательский пароль для доступа к правам администратора:

Согласиться, что пакеты, перечисленные в терминальном окне, будут установлены:

Скриншот 28. Для согласия достаточно нажать **Enter**

И некоторое время наблюдать в том же терминале этот волнительный процесс. А по завершении его снова нажать Enter для закрытия терминального окна:

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

…жизнь таких сама научит строго.
Тут я согласен…

Но пока этого не произошло, почему бы не пойти навстречу своему капризу? Для чего разворачивается секция Office (в свежеустановленной EOS любой редакции пустая) и в ней находится офисный набор libreoffice, который там един в двух лицах, still (якобы стабильный) и fresh (наисвежайший). И для установки помечается тот, на который глаз упадёт. Предположим, что это будет libreoffice-fresh:

Скриншот 30. Установка одного из LibreOffice

Далее всё происходит, как в предыдущем примере — ввод пароля, согласие с установкой пакетов и закрытие терминала после её окончания. И тут наивную молодёжь пенсионного возраста постигнет некоторое разочарование: установленный таким образом libreoffice-fresh (как, впрочем, и libreoffice-still) окажется голо-оригинальным пакетом с англоязычным интерфейсом и без малейших средств поддержки русского языка, в частности, без словаря для проверки русской орфографии. Для обеспечения и того, и другого придётся поставить соответствующий локально-зависимый пакет. Но уже обычными средствами пакетного менеджмента типа pacman‘а или yay — QuickStart Installer таковой не поддерживает.

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

В штатном комплекте LXQt-редакции дистрибутива EOS текстовый редактор имеется, и весьма неплохой — FeatherPad. Однако для всамделишней сочинительской работы он не всегда достаточен. Так что вместо офисного пакета установим мы пару самых продвинутых текстовых редакторов, какие мне известны.

Во-первых, это Kate, который находится в той же секции Text Editor, что и FeatherPad. Где и помечается для установки. А во-вторых — Geany, располагающийся в секции Development Tools, напротив него также ставим «птицу»:

Оба редактора примерно эквивалентны по своему функционалу, хотя и по разному. Сила Kate — собственно в сочинительстве, то есть в наборе текста «из головы» и его первичном редактировании. Geany же незаменим, когда несколько отдельных текстовых фрагментов надо свести воедино, чтобы они представляли нечто вроде книги. И, таким образом, редакторы эти не только не мешают, но и взаимно дополняют друг друга.

Автор: alv

Про себя напишу потом Посмотреть все записи автора alv