Здесь собрано всё, что я успел написать про MX Linux, основанный на Debian 12, несущий KDE 5, без малейшего Wailand’а. Ввиду своей беспроблемности я присвоил ему звание одного из трёх Последних Linux’ов — он исполняет роль палочки-выручалочки, когда с двумя другими Последними Linux’ами обнаруживаются проблемы.

Выбор

Мир открытого софта непредсказуем, особенно если этот софт ещё и свободен (то есть является Free/libre and Open-source Software — далее FOSS). А потому в развитии его возможны самые неожиданные зигзаги.

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

Процесс выбора

Во одной из вводных историй про Cinnamon мы с котом Мануалом написали, что после выбора её в качестве ~~любимой жены~~ основной среды на другие десктопы нам и смотреть не хотелось. Но тут мы несколько лукавили. Потому что прекрасно понимали: объективная реальность, данная нам в ощущения разработчиков FOSS, может потребовать не просто смотреть на альтернативную среду, но даже работать в ней. И к этому надо быть готовым во избежание разброда и шатания, в которые автор этих строк впадал после обоих предыдущих «десктопных» зигзагов.

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

Зигзаги прогресса

Так уж исторически склалось, что системы с десктопом Cinnamon, которые мы с Мануалом использовали и используем, основываются преимущественно на пакетной базе Ubuntu. Это и

наша домашняя самоделка Cintu (прекратившая своё развитие), и
Ubuntu Cinnamon Remix (будущее которой остаётся туманным — первая и последняя тестовая сборка релиза 22.04 датируется прошлой осенью, и
Cinnamon-редакция дистрибутива Linux Mint, (пока?), подтверждающая славу одной из самых беспроблемных систем.

Вот как раз в базисной Ubuntu и угадываются некоторые изменения в 22.04 LTS — очередном «долгоиграющем» релизе. Сведения о них начали просачиваться в «прессу» ещё в октябре 2021-го, сразу после выхода предыдущего релиза (20.10 Impish). Они отслеживаются на форуме Matuntu и на сегодняшний день подытожены здесь: Ubuntu outlines plans for GNOME in 22.04 (.

Тон последнего сообщения достаточно сдержанный. Так, в нём предполагается, что

…Ubuntu 22.04 будет поставляться с GNOME 42, но с некоторыми консервативными решениями для приложений настольного компьютера. В отчёте о состоянии объясняется: «В настоящее время мы работаем над обновлением стека GNOME Shell до текущей стабильной версии 41, а затем начнём работать над его обновлением до версии 42, стремясь включить эту версию в LTS. В приложениях мы будем более консервативными, избегая решений на базе GTK4. По крайней мере, для софта, устанавливаемого по умолчанию…

Мы не считаем, что у нас было достаточно времени для тестирования новой версии GTK4, поскольку ранее на неё было портировано очень мало приложений (единственное в настоящее время в архиве Ubuntu — GNOME Chess).

В GNOME теперь только начинает портирование приложении на GTK4, которыеКак нуждаются в более длительном тестировании, чем обычные обновления. И потому это не те изменения, которое мы хотим включить непосредственно перед выходом релиза LTS… Портированные приложения сейчас… будут визуально несовместимы с другими нашими компонентами. Мы работаем над решением этой проблемы, но вряд ли это будет сделано в этом цикле разработки.

Ввиду важности цитата оказалась длинной. Однако слова её внушают оптимизм: сразу после релиза разработчики Ubuntu не будут вопить голосом Пьера Безухова после первой брачной ночи: «Должны же мы были здесь хоть что-нибудь сломать!»

Однако один кандидат на «поломание» обнаружился при знакомстве с новым инсталлятором из «полуночных» сборок будущего релиза Ubuntu. Это — настройки клавиатуры, точнее, полное их отсутствие. В частности, переключение с раскладки en на любую другую, например, на ru, возможно только по комбинации LWin+Spacebar, варианты русской раскладки нельзя выбрать ни на стадии инсталляции, ни позднее.

В 22.04 можно ожидать дальнейшего прогресса в деле snapy’нации «базиса»: всё большее пакетов будет распространяться только в формате snap, с одновременным «вымыванием» их из официального репозитория.

Далее, не смотря на обещание разработчиков не злоупотреблять портированием приложений на библиотеки Gtk 4, какую-то их часть эта судьба не минует. А ведь Gtk, то есть GIMP ToolKit, каким он был с рождения, постепенно всё более затачивается под среду GNOME и её приложения, постепенно превращаясь в GNOME ToolKit. Возникает вопрос, как в ходе такой эволюции поведут основанные на Gtk приложения, и особенно среды, базисом которых выступает тот же тулкит. То есть Xfce, MATE и более всего волнующая нас Cinnamon.

Наконец, замена Иксов на Wayland по умолчанию можно считать свершившимся фактом — правда, пока (?) только для среды GNOME, об остальных Gtk-средах пока вроде и разговоров не поднималось, не говоря уже о тестировании. Однако мы ведь знаем, что дурной пример заразителен…

Так что пока остаётся загадкой, как все эти зигзагчики могут сказаться на как на официальных клонах Ubuntu, и на всех трёх редакциях дистрибутива Linux Mint, из которых для нас с Мануалом важнейшей является Cinnamon Edition. Учитывая проверенный временем здоровый консерватизм последней, опасаться, что она в одночасье превратиться в нечто подобное материнской системе, пожалуй, не стоит. Но и совсем бесследно для среды Cinnamon и её базиса эти зигзагчики не пройдут. А потому сейчас самое время не спеша присматриваться к альтернативному десктопу. А, приняв решение касаемо десктопа, столь же неторопливо подбирать для него подходящий дистрибутив.

Выбор альтернативного десктопа

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

Как ни странно, в настоящий момент выбор этот оказывается очень прост, если следовать известной максиме Генри Форда (в которой неизвестно только одно — а говорил ли старина Генри что-то подобное):

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

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

Учитывая высказанные выше опасения за будущее Gtk, в нашем случае альтернативный десктоп может быть любым, при условии, что он основан не на Gtk-библиотеках. Что фактически сводится к среде KDE, основанной на библиотеке Qt и комплексе, ранее объединявшемся в kdelibs. Надеюсь, нас с Мануалом простят, но рассматривать как полноценные альтернативы недо-среды вроде LXQt или Lumena, реликт прежней эпохи TDE (развивающий линию KDE 3), не говоря уже об оконных менеджерах, мы не будем.

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

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

Первая особенность, казалось бы, однозначно положительная, имеет оборотную сторону: она чревата соблазном увлечься конфигурированием среды до такой степени, что, как в анекдоте «забыл, зачем». Что, в общем случае, можно обуздать только самодисциплиной (или пресыщением настроечной деятельностью, как это имеет место быть у нас с Мануалом).

Изобилие приложений обычно ставится в плюс среде (на то она и интегрированная). Однако приложения эти, во-первых, далеко не всегда нужны конкретному применителю, а во-вторых, времена, когда KDE-приложения были среди лучших в своём классе, остались в прошлом, в эпоху версий 3.X. Благо, они не обязательны к установке, а если уж установлены, то, благодаря модульности библиотек, ранее составлявших монстроидальную kdelibs, легко удаляются со всеми своими зависимостями. И могут заменяться чисто Qt-аналогами. И даже, при необходимости, аналогами на Gtk 2/3, которые хорошо интегрируются в KDE-окружение, о чём будет рассказано со временем.

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

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

Для KDE сеанс Wayland’а доступен, но не по умолчанию, как для GNOME, а только в качестве опции. И, по словам Джонатана Риддела (одного из основных разработчиков KDE и руководителя проекта KDE Neon), ситуация не изменится, пока в Wayland-сеансе не будет обеспечен полный функционал KDE в Xorg. И один из приоритетов здесь — управление устройствами ввода, в том числе и поддержка множественных раскладок клавиатур.

Приятно всю-таки видеть людей, которые не хотят дважды наступать на одни и те же грабли — первый раз разработчики KDE сделали это, позволив майнтайнерам ряда популярных дистрибутивов принять 4-ю ветку этой среды за полноценный релиз, хотя в момент выхода это была не более чем ранняя бета-версия. Каковой, кстати, она оставалась до конца своего жизненного цикла (то есть до выхода KDE 5).

Поскольку в Wayland’е, насколько можно судить по GNOME из Ubuntu, и просто с управлением раскладками дело обстоит так себе, а множественных раскладок не видно и на горизонте, у меня есть основание надеяться, что пары Иксов и KDE на мой век хватит, а потом меня эти вопросы волновать уже не будут. Так что можно спокойно заниматься подбором дистрибутива под среду KDE.

Подбор дистрибутива

А вот подбор дистрибутива оказался неожиданно посложнее. Напрашивающееся решение, KDE Neon, было забраковано сразу. Ибо, хотя в нём интегрированы самые последние версии среды KDE и её приложений (разработчики так и называют его — архивом пакетов KDE и Qt, а не дистрибутивом), базисом для них служит всё тот же последний LTS-релиз Ubuntu, очередная версия которого, 22.04, и представляется потенциальным источником будущих неприятностей. Обоснованно или нет — другой вопрос, на который пока нет ответа. Но, как известно, бережёного бог бережёт, а не бережёного — конвой стережёт. И потому в силу опять вступает аналогия максимы Генри Форда «от противного»:

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

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

не привязанные ни к какому постороннему базису дистры, такие, как Void Linux и Nutyx, развиваемые по модели чистого rolling’а и потому заведомо удовлетворяющие требованию «свежести» всего, чего возможно;
дистры, в качестве базиса имеющие Archlinux, сам по себе самый что ни на rolling, унаследованнный его потомками; примеры коих — Manjaro Linux, в данный момент весьма популярный в узких кругах, и EndeavourOS — наследник самоликвидировавшегося Antergos’а, (чем его майнтайнеры, совсем некстати, очень подкузьмили своим искренним приверженцам, среди которых были и мы с Мануалом);
дистры, в качестве базиса которых выступает Debian stable, актуализированнный с точки зрения ядра и KDE — Netrunner, Neptune; кроме того, есть ещё и siduction на Debian unstable.

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

Так что не буду тянуть Мануала за хвост, тем более, что интриги всё равно не получилось: имя выбранного нами дистрибутива красуется в заголовке этой страницы: MX Linux. Мы оживили его в памяти более чем через пять лет забвения, по причинам, о которых будет говориться позднее. И одновременно Татьяна Иванова aka Vita вспомнила про него на форуме Матунту.

Как тут не поверить в телепатию — подумали мы с Мануалом, и решили, что это судьба: MX Linux’у в его KDE-ипостаси быть нашим альтернативным дистрибутивом.

Результаты выбора

Казалось бы, MX Linux не удовлетворяет критериям, которые мы только что сами для себя сформулировали: и ядро в текущем релизе (MX-21 Wildflower) немного второй свежести (5.10.70 супротив актуального 5.16.2), и KDE не самое последнее (plasma-desktop 5.20.5, тогда как нынче на дворе мелькает 5.23.5). Однако это отставание от собственных рубежей может быть либо ликвидировано, либо признано (нами же) несущественным, как будет показано далее. Однако прежде посмотрим, откуда он такой взялся, этот ~~северный олень~~ MX Linux

MX Linux: вопросы истории

Дистрибутив MX Linux в своих истоках восходит к древним временам седых пирамид — к дистрибутиву, получившему название MEPIS (судя по пирамидам на его логотипе, от древнеегипетского города Мемфиса):

На фоне популярности дистров семейства Ubuntu как-то забылся тот факт, что она не была первой юзеролюбивой системой быстрого развёртывания (далее СБР), то есть не требовавшей долгого и нудного попакетного выбора (или, паче того, сборки из исходников). Нет, рубеж тысячелетий породил серию таких дистрибутивов. Первым из них был Storm Linux, за ним последовали Vector Linux, Handros (в девичестве Corel Linux) и Linspire (под девичьей фамилией «Lindows» приобретший скандальную известность). Все они основывались на Debian’е (за исключением Vector Linux — деривата Slackware) и в качестве десктопа использовали среду KDE — до выхода 2-й ветки GNOME был практически неработоспособен, и держался на голимом энтузиазме адептов свободы софта.

Все эти дистры во второй половине нулевых годов прекратили своё развитие, не оставив «потомства» в виде клонов и дериватов. И даже имена их помнят только такие старожилы, как автор этих строк. Да служба поиска Distrowatch’а способна извлечь их из небытия, если в поле Status выбрать Discontinued.

Однако в том же поколении СБР был и MEPIS, судьба которого оказалась более счастливой. Он возник вслед за упомянутыми выше дистрами, в 2003 году. И, подобно им, основывался на Debian’е, с KDE в качестве десктопа. Однако отличался некоторыми фронтирными для того времени функциями. Так, он был в числе первых дистров с LiveCD для установки и восстановления системы, возможностью автоматического конфигурирования «железа», изменения размера раздела NTFS, поддержкой шрифтов TrueType и многого другого, без чего современный Linux представить невозможно.

Кроме того, в рамках проекта развивались две линии систем — свободная и несколько коммерческих вариантов разного назначения. Впрочем, последние распространения не получили. И, видимо, поэтому (а также в связи с засильем Ubuntu) проект прекратил своё развитие. Пережив, тем не менее, всех своих собратьев и ровесников — последний релиз MEPIS’а датируются августом 2013 года.

Однако за десять лет существования вокруг MEPIS’а успело сложиться сообщество,развивающее два порождённых дистрибутива, благополучно здравствующих и по сей день. Сначала, ещё при жизни праотца, возник antiX (2010-04-12). Это система, рассчитанная на старые и маломощные машины, в качестве рабочего окружения в ней используются не интегрированные десктопы, а оконные менеджеры не из самых тяжёлых— Fluxbox, IceWM и JWM. Причём его Live-образ позволяет «на лету», прямо в «живой» сессии, выбрать любой из них, например, этот:

А затем наступил черёд и MX Linux’а. Сначала, в в марте 2014 года, он был выпущен как версия antiX’а, несколько «утяжелённая» рабочей средой Xfce, впрочем, в то время — самым лёгким из ~~железов~~ десктопов. Версия эта получила и собственное имя, подобно всамделишнему дистрибутиву. Как пишут его разработчики:

Название «MX» было выбрано так, чтобы объединить первую букву Mepis с последней буквой antiX, что символизирует их сотрудничество.

Одновременно с именем MX получил и номер версии — как ни странно, сразу 14-й: с одной стороны, потому, что выход его попал на «дыру» между версиями дистрибутива antiX — 13.2 (5 декабря 2013 года) и 15-й (30 июня 2015 года). А с другой стороны, выход этот случился действительно весной 2014 года. С тех пор для MX и пошла традиция: мажорный номер релиза давать по году его выпуска, а минорные номера — порядковые для следующих релизов того же года.

Однако официально днём рождения дистрибутива считается 2 ноября 2016 года — выход бета-версии MX-16 и примерно одновременное появление на Distrowatch’е его собственной страницы. С этого же времени ISO-образы установочных дисков становятся доступными на SourceForge.net — старые здесь, а актуальные — здесь. Получил MX и такой непременный аттрибут полноценного дистрибутива, как собственный репозиторий, о котором будет говориться позднее.

Долгое время MX был дистрибутивом одного десктопа: с официального образа можно было установить только рабочую среду Xfce. Однако по меньшей мере с релиза MX-15 существовал и образ с рабочей средой KDE, о чём я могу врать как очевидец . Правда, официального статуса они долго не имели, да и установка системы с них была не вполне тривиальной. Но со временем ситуёвина вокруг MX и KDE устаканилась: образ, включающий KDE, был приобщён к официозу начиная с релиза MX-19.3, а установка системы с него стала проходить так, как мы вправе ожидать от дистров такого типа (и класса). Но тут мы уже переходим от истории к современности.

А об истории осталось добавить буквально пару слов. Со дня своего возникновения MX поддерживал обе архитектуры PC — и 32-, и 64-битную. Причём сборки для i386 время от времени включали ядра как с PAE, так и без оной, что бывало актуально для неактуальных конфигураций.

Такое положение дел сохранялось и позднее — но только для редакции с флагманским десктопом, KDE-редакция распространяется только для архитектуры x64. Зато в релизе MX-21 к двум прежним рабочим средам добавилась редакция, содержащая оконный менеджер Fluxbox — и также для обеих архитектур.

Моя MX Story

Моя личная история с MX Linux, однако, началась до его официального дня рождения — в начале февраля 2016 года. И услышал от своего старого товарища по нескольким Linux-форумам, Валерия Моторина, широко известного в узких кругах как Zenwolf. У него удивительная способность откапывать малоизвестные или совсем новые дистрибутивы, часто не обычные, но всегда интересные. Так, некогда именно от Валения я узнал и о Zenwalk’е, и о Salix’е, которые применял потом достаточно долго (а о Salix’е даже написал электронную книгу).

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

Итак, установочный диск, он же Live CD, содержал текущий (тогда) релиз MX Linux 15, вышедший 24 декабря 2015 года, и среду Xfce версии 4.12. И после загрузки начались поразительные события. Во-первых, в Live-режиме систему можно было модифицировать произвольным образом. То есть в ней легко удалялись любые пакеты из штатного комплекта и столь же просто устанавливались любые пакеты, доступные в репозиториях. Рабочая среда Live-сессии конфигурировалась применителем в соответствие его вкусами и потребностями.

Но не это главное. А наследование системой, инсталлированной на целевой носитель (всё равно, виртуальные или реальный), всех модификаций Live-среды, выполненных перед запуском установщика. А с этой тотально кастомизированной системы можно было сделать снапшот в виде ISO-образа, пригодного для записи на «болванку» (тогда это было ещё актуально) или на флешку.

То есть, модифицировать систему в Live-сессии, можно было сделать с неё «живой» слепок, и даже обойтись без установки вообще, а сразу записать его на носитель, который будет служить установочным. Хотя работа в системе, установленной в виртуалке, облегчалась тем, что при этом не требовалось каких-то специальных действий по настройке взаимодействия гостевой и хост-машины — разделяемого каталога, общего буфера обмена и Drag&Drop. Ибо образ диска гостевых дополнений подключался автоматически при установке в виртуалку, и потом оставалось только включить соответствующие опции в настройках виртуальной машины (в пункте Устройства)

Всё вышеописанное привело меня тогда в восторг. Который продолжался около полутора месяцев. Но несколько омрачался только одним:я всегда любил среду Xfce за простоту её настройки и вполне достаточный функционал. Однако, после работы в среде Cinnamon она казалась мне бледненькой и скучноватой, а другого десктопа в MX тогда не было.

Так что я на некоторое (как мне тогда казалось) время отложил MX — недавнее появление его редакции с KDE внушало надежду, что и Cinnamon будет вскорости окучен этим дистром. А сам вернулся к Linux Mint CE, составления ради дополнений к недавно законченной онлайновой книжке про эту парочку. А потом меня, уже вместе с котом Мнуалом, затянуло в мутный омут самодельных систем из Ubuntu и среды Cinnamon — тем более что MX с этой средой появляться и не думал.

Так продолжалось до того момента, когда мы с Мануалом впервые задумались над средой и дистром, способными заменить Cinnamon и базис Ubuntu в случае каких-либо неприятностей. А об обстоятельствах, при которых мы поняли, что этими средой и дистром должны быть KDE и MX Linux (обстоятельствах почти мистических, заставляющих вспомнить о телепатии и тому подобной псевдоквазии), я уже рассказывал. К этому времени, 21 октября 2021 года, вышел в свет релиз MX-21 со средой plasma-desktop 5.20.5 в качестве одной из титульных. Вот о них и пойдёт речь в следующей истории.

MX Linux сегодня

В комментариях к одной из заметок старого ) цикла про MX Linux, некогда (март 2016 года размещавшегося на Блогосайте, был задан вопрос: «Чем этот дистрибутив отличается от обычного debian?» Дабы предвосхитить подобные вопросы впредь, по примеру Бернарда Шоу заранее отвечаю: читайте меня. А конкретно — именно данную историю, в которой говорится об особенностях современных релизов MX Linux.

Репозитории MX Linux

И первая особенность MX — устройство его репозиториев. Файл, в котором они традиционно описываются для дистров deb-based, /etc/apt/sources.list, в MX пуст:

$ less
#this file is empty by default.  Sources are under /etc/apt/souces.list.d

Поэтому смотрим содержимое предлагаемого в нём каталога:

$ cd /etc/apt/souces.list.d/
$ ls *
debian-stable-updates.list  mx.list

Как уже отмечалось, дистрибутив MX основан на пакетной базе Debian’а стабильной ветки. Ею в данный момент является Debian 11 bullseye, релиз которой состоялся 14 августа 2021. А её репозиторий описывается в файле debian.list:

$ less debian.list
# Debian Stable.
deb http://deb.debian.org/debian bullseye main contrib non-free
deb http://security.debian.org/debian-security bullseye-security main contrib non-free
...
debian.list (END)

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

Это официальный репозиторий материнской системы. Из него MX Linux заимствует свой базис — ядро, набор консольных утилит и Xorg, включая их обновления безопасности (файл debian-stable-updates.list). В принципе из него можно установить любые пакеты — а в официальных репозиториях Debian’а их не много, а очень много. Однако тогда и получится в итоге Debian, а не MX Linux. Тем более, что этого делать совсем не нужно. Ибо MX, как всякий уважающий себя дистрибутив, имеет собственный репозиторий, и даже два. А именно наличие репозитория отличает настоящий дистрибутив от поделок типа ремиксов и респинов.

Оба репозитория описываются в файле mx.list из указанного выше каталога, который выглядит следующим образом:

$ less 
# MX Community Main and Test Repos
deb http://mirror.truenetwork.ru/mxlinux/mx/repo/ bullseye main non-free
#deb http://mirror.truenetwork.ru/mxlinux/mx/testrepo/ bullseye test

#ahs hardware stack repo
deb http://mirror.truenetwork.ru/mxlinux/mx/repo/ bullseye ahs

Репозиторий mx содержит пакеты, определяющие специфику дистрибутива. Во-первых, это универсальный комплекс утилит для настройки всего и вся (от загрузчика до снапшота системы), объединяемых средством управления ими — MX-Tools Launcher. Именно им и определяется «лицо» нашего дистрибутива, которое применитель видит при запуске его с Live CD или сразу после установки:

А также может запустить в любой момент после установки:

Во-вторых, это дополнения и патчи к обоим его титульным десктопам — Xfce и KDE, которые в основе своей берутся из «материнского» репозитория; а вот столь же титульный оконный менеджер Fluxbox источником имеет mx-репозиторий.

В третьих, в mx-репозитории имеются ядра версий, более новых, чем в текущем Debian stable (в данный момент — по 5.13 включительно), а также ядра специального назначения — для 32-битных машин с поддержкой PAE или без оной, для облачных платформ, реального времени (опция PREEMPT_RT).

Всё перечисленное богачество содержится в разделе main репозитория mx. Рядом с ним располагается раздел non-free. Это не какой-то там варез: в терминологии Debian’а и его клонов так называют программы, имеющие хоть какие-то ограничения супротив правоверно-GPL’ных. Например, именно здесь можно найти проприетарные драйвера для видеокарт, которые распространяются без исходников.

Назначение раздела test понятно — как и то, что подключать его (то есть снимать символ комментария с соответствующей строки) не следует без чёткого понимания, зачем это делается. Как, впрочем, и проделывать ту же процедуру в файле debian.list для подключения разделов src и backports.

Второй репозиторий, ahs (Advanced Hardware Support), был создан в ноябре 2019 года с целью дать применителю возможность устанавливать такие вещи, как новые графический стек и прошивки, включая обновленные пакеты mesa, драйверы xorg и тому подобные пакеты, включая обновления пакетов тех приложений, которые могут их использовать. При этом в ahs будут попадать только пакеты, не конфликтующие с текущим основным ядром. Кроме того, в репозиторий ahs в режиме тестирования включаются ядра и пакеты драйверов dkms, более новые, чем в mx-репозитории (в данный момент — версий 5.14 и 5.15).

Репозиторий ahs предназначен для тех применителей, у которых есть самые новые чипы amdgpu или графические наборы Intel. А также те, кому требуются самые новые пакеты mesa. Со временем, по мере устаревания текущей базы Debian, пакеты из ahs будут переноситься в раздел main mx-репозитория.

Сразу после создания ahs-репозитория он имел статус экспериментального и требовал активизации вручную. Начиная с релиза MX-21, этот репозиторий подключён по умолчанию. Однако если применителя полностью устраивают стабильные mx-репозитории, причины использовать репозиторий ahs нет. По крайней мере, мы с Мануалом потребности в нём пока не ощутили, он подключён у нас как бы на всякий пожарный случай.

Установочные образы

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

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

Основное место хранения образов MX Linux — соответствующая страница официального сайта проекта, на которой, кроме ссылок для скачивания, имеются и описания всех доступных вариантов, причём на разных языках (перевод осуществляется в реальном времени), в том числе и на русском:

Сайт проекта MX Linux имеет многочисленные зеркала по всему миру. Правда, как видно из следующей картинки , на Руси таковых (пока?) не имеется:

Кроме того, образы MX имеются и на сервере SourceForge.net. Поскольку устройство всех серверов по определению идентично, на примере последнего его и рассмотрим. Можно видеть, что каталог файлов проекта, разделяется на несколько подкаталогов, содержимое которых интуитивно понятно:

Нас будет интересовать три из них — Final, Snapshots и Community_Respins. В первом содержатся официальные образы в том виде, в каком они вышли в свет в момент объявления 21-го релиза (конец октября 2021 года), хотя в данном случае образы с флагманским десктопом (то есть Xfce) были обновлены в конце ноября:

Образы с Xfce и Fluxbox имеют как 64-битные, так и 32-битные версии. Причём в подкаталоге Xfce имеется и образ с подключённым репозиторием ahs в 64-битном исполнении (MX-21_ahs_x64.iso).

В подкаталоге KDE лежит только один образ под архитектуру x64, собранный с поддержкой ahs (что в имени его не указано):

Каталог Snapshots, как следует из его названия, предназначен для снапшотов, то есть моментальных слепков, аккумулирующих, с некоторой периодичностью, изменения, произошедшие в пакетной её базе со времени выхода релиза. Ранее снапшоты появлялись нерегулярно. Но, начиная с релиза 21, похоже, они будут выходить в середине каждого месяца. Пока, во всяком случае, мы видели уже два снапшота, декабрьский и январский. Они собраны только с десктопами Xfce и KDE для архитектуры x64, и с поддержкой ahs. Последнее в именах образов не указано (MX-21_January_x64.iso и MX-21_January_KDE.iso, соответственно), но для KDE-редакции это точно так, а для Xfce предполагается по аналогии:

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

Наконец, в каталоге Community_Respins помещаются неофициальные сборки (то есть респины) от сообщества, коих там в настоящее время три. Правда, для нас с Мануалом некоторый интерес может представлять лишь одна — MX-Workbench:

Правда, это всего лишь очередная вариация на тему флагманского десктопа. А мы же с Мануалом остановились на MX-21 как надёжном базисе для KDE. И пусть версия последней несколько отстаёт от апстрима (plasma-desktop, версии 5.20.5 и 5.23.5), соответственно — не заметно, что из-за этого мы сильно потеряли в функционале или настраиваемости.

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

KDE: от истории к современности

История KDE до 4-й версии включительно достаточно подробно рассмотрена в книге Вопросы истории: UNIX, Linux, BSD и другие. Поэтому, дабы не повторяться, здесь этот период будет описан кратко. Версия же KDE 5.0 — это уже не столько история, столько современность, и ей будет посвящён заключительный раздел.

У истоков

Август 1995 года судьбоносным в истории графических сред стал в момент выхода Windows 95. Именно в ней впервые появляется центральный элемент большинства интерфейсов последующих лет – главная управляющая панель с сакраментальной кнопкой Start (она же Пуск), вызывающей каскадное меню приложений.

То есть Windows 95 создала тот архетип графического интерфейса, который быстро завоевал популярность среди широких народных масс. И с этим приходилось считаться разработчикам любых десктпопв. Не стал исключением и Маттиас Эттрих, когда сразу после этого события приступил к разработке KDE. Согласно легенде, он занялся этоим для того, чтобы его девушке было удобно работать в Linux’е.

Так что, создавая KDE, Эттрих включил в неё и управляющую панель в стиле Windows 95, и кнопку Start. Однако гораздо больше в интерфейсе среды было унаследовано от старых оконных менеджеров для Иксов. Например, система контекстных меню и множественные виртуальные рабочие столы.

Всё это имело место быть и в оконных менеджерах, часто воспроизводивших внешность Windows 95, таких, как FVWM95 и IceWM. Однако в KDE был ещё и набор штатных приложений — файловый менеджер Kfm, эмулятор терминала Konsole, текстовые редакторы KEdit и KWrite. Все они имели интерфейс в едином стиле и хорошо вписывались в среду. Самое же главное — в KDE впервые в истории графических сред Unix’а и Linux’а появилось единое средство конфигурирования, позволяющее настраивать параметры как самой среды, так и всех её приложений. Чего в оконных менеджерах тогда не было — как нет и сейчас.

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

Всё это было очень логично организовано в несколько «авторских» пакетов, таких, как kdelibs — библиотеки, дополняющие основную библиотеку Qt, kdebase — базовые приложения среды, kdenetworks — сетевые средства, kdemultimedia очевидного назначения, kdeartworks – набор украшательств, и так далее. А вскоре для KDE был создан и офисный пакет KOffice, в который поначалу входил растровый графический редактор Krita.

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

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

Однако вернёмся к материям более скучным, крючкотворным. Среда KDE основывалась на библиотеках Qt, не являвшей по в то время стопроцентно свободными. И потому была настороженно встречена ревнителями идеологической чистоты софта, такими, как разработчики Debian и Red Hat.

Однако среда KDE приобрела популярность среди людей весёлых, которым все эти идеологии были пох… фигу. И в июле 1998 года выходит первая версия первого по настоящему юзерофильного дистрибутива – Mandrake Linux. И в нём среда KDE была десктопом по умолчанию. А осенью того же года года среда KDE стала умолчальной в S.U.S.E.(кажется, тогда эта фирма писалась ещё так).

Затем, на рубеже тысячелетий, начался бум «Linux’ов с человеческим лицом», или, точнее, первых систем быстрого развёртывания (СБР). Почти во всех этих системах KDE в роли умолчального, а то и единственного десктопа использовалась среда KDE. Среди них был и MEPIS — далёкий предшественник MX Linux.

От «тройки» до «пятёрки»

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

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

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

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

Ибо с момента зарождения GNOME его интенсивно поддерживала самая мощная Linux-компания – Red Hat. А в 2003 году, после того, как фирма SUSE, выпускавшая одноимённый дистрибутив, была приобретена компанией Novell, за внедрение GNOME взялся игрок номер два: после расщепления этого дистрибутива на две ветки – коммерческую SLE (Suse Linux Enterprise) и развиваемую сообществом openSUSE, в первой как десктоп по умолчанию был принят GNOME.

Тем не менее, при несомненных успехах RHEL и SLE в корпоративном секторе, на пользовательских десктопах результаты их деятельности по продвижению GNOME были не очень заметны. А началом коренного перелома в этом продвижении стал конец 2004 года, когда в мировом масштабе развернулось распространение дистрибутива Ubuntu, в качестве рабочей среды по умолчанию использовавшей GNOME. Ибо в 2002 году, начиная проект, Марк Шаттлворт принял судьбоносное решение – использовать в новом дистрибутиве именно его. не KDE.

‬Шаттлворт объяснял свой выбор тем,‭ ‬что во времена, когда (в‭ ‬2002‭– ‬2003‭ ‬годах) он делался, GNOME был хорошим,‭ ‬а в KDE были одни‭ «‬рюшечки и менюшечки‭»‬.‭ ‬Однако,‭ свидетельствую как очевидец: ‬всё было с точностью до наоборот,‭ ‬и KDE далеко опережал Gnome по функциональности и‭ «‬юзабельности‭».‭ ‬Так что,‭ ‬на мой взгляд,‭ ‬Марк несколько лукавит.

Ибо на тот момент существовало несколько СБР, использовавших KDE как рабочую среду по умолчанию (и, замечу в скобках. в большинстве своём базирующихся, как и Ubuntu, на Debian’е) Например, неоднократно поминавшийся предшественник нашего MX,‭ дистрибутив MEPIS.

Так что использование GNOME для разработчиков Ubuntu (а Марк в то время лично участвовал в разработке) было единственныибутивм способом выделить свой дистр на фоне сородичей.‭ ‬И ‬последующий взлёт популярности GNOME был спровоцирован именно нарастающим распространением Ubuntu.

Так или иначе, но с выходом Ubuntu (и последовавшей массовой бесплатной рассылкой её дисков) — началось широкое распространение GNOME за счёт KDE. Однако на распределение пользователей по десктопам (или десктопов по пользователям?) в ещё большей степени повлияло другое роковое событие: выход 11 Июня 2008 года KDE 4.0.

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

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

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

Результат оказался более чем предсказуем. Поскольку было вполне очевидно, что дни 3-й ветки сочтены, начался массовый отток пользователей KDE на запасные аэродромы. Для кого им стал XFce, кто вернулся ко временам информационной юности – на менеджеры окон. Но немало бывших пользователей KDE попросило политического убежища в стане GNOME.

Сейчас, по прошествии многих лет, мы с Мануалом понимаем, что разработчики KDE почти всё сделали (почти) правильно. Допустив лишь одну маленькую тактическую ошибку: они обозвали релизом достаточно сырую тестовую версию. И никакие объяснения, что это не совсем таки настоящий релиз, не в силах были преодолеть магию Слова. Хотя, с другой стороны, не пойди KDE’шики на такой отчаянный шаг, разбудивший здоровую рабочую злость и применителей-прагматиков, и энтузиастов-тестировщиков, и сторонних разработчиков — кто знает, может быть, 4-я версия KDE отлаживалась бы и по сей день.

Хотя на самом деле почти так оно и произошло: большую часть своего жизненного цикла KDE 4.X (злые языки, вроде автора этих строк, утверждают, что весь) представляла собой грандиозный набор бета-версий перед перед выходом KDE 5.0, случившимся 15 июля 2014 года. Однако, как мы сейчас увидим, знакомство с «пятёркой» показало, что дело того стоило…

Хроника текущего момента

Как говорилось в первой из историй про историю KDE, ранее этот проект (K Desktop Environment в версиях 1–3) был монолитен, разделяясь на такие же монолитные пакеты, как kdelibs (набор основных библиотек), kdebase (набор штатных приложений), и так далее. В версии 4 проект стал именоваться KDE Software Compilation, и включал рабочик окружения, которые были ориентированы на разные платформы — обычные компьютеры, нетбуки м планшеты. Однако монстроидальные монолитные пакеты от этого никуда не девались.

А вот в версии 5 внутреннее устройство среды сильно изменилось. Во-первых, то, что раньше называлось KDE или (в версии 4) KDE SC, разделилось на три отдельные части (субпроекта), каждая из которых имеет собственный цикл выпуска и нумерацию версий:

KDE Plasma обеспечивает интерфейс платформы для различных рабочих областей;
KDE Frameworks — набор библиотек поддержки элементов интерфейса Plasma, надстраивающих Qt; они заменили единую библиотеку kdelibs;
KDE Applications — набор приложений и поддерживающих их библиотек, также базирующихся на Qt (ранее входивших в kdelibs).

Современная Plasma содержит такие рабочие окружения, ориентированные на различные платформы:

Plasma Desktop — на настольные компьютеры и ноутбуки;
Plasma Mobile — на смартфоны;
Plasma Minishell — на встроенные и сенсорные устройств;
Plasma Media Center — на «умные» телевизоры.

KDE Frameworks включает ныне более 70 основанных на Qt библиотек. Они являются основой для KDE Plasma и штатных приложений KDE, но могут входить в любой проект, например, во внешние KDE-приложения; именно благодаря модульной организации библиотек KDE ныне основанные на них приложения так легко интегрируются, например, в Gtk-среды.

KDE Applications — это комплект программного обеспечения, являющегося частью официального выпуска KDE Applications. В их число входят файловый менеджер Dolphin, эмулятор терминала Konsole, текстовый редактор Kate.

Кроме KDE Applications, есть и другие KDE-приложения, не входящие в штатный комплект для этой среды, но использующие не только библиотеки Qt, но и библиотеки из KDE Frameworks. Они развиваются в рамках самостоятельных проектов, имеют собственные релиз-циклы и нумерацию версий. Это растровый редактор Krita, офисный пакет Calligra Suite, файловый менеджер Krusader и некоторые другие.

Итоги

Первая часть историй про KDE и MX Linux подошла к концу. Итоги их можно подвести одной строкой:

Десктоп ясен, дистрибутив определён. За работу, товарищи!

Впрочем, перед этим необходимо установить определённый дистрибутив с прояснившимся десктопом, и выполнить в нём настройки, необходимые для комфортной работы. Истории, посвящённые этому, будут собраны во второй части нашего с Мануалом сочинения о KDE и MX Linux.

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

О создателях MX Linux тоже нашлось не очень много: проект этот начался с обсуждения будущих вариантов среди членов сообщества MEPIS в декабре 2013 года. Затем к ним присоединились разработчики из antiX, которые принесли с собой ряд утилит, ставших позднее составными частями набора MX Tools.

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

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

Эта картинка напоминает о двух истоках и двух составных частях проекта MX Linux — дистрибутивах MEPIS и antiX.

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

Первая часть Историй про KDE и MX Linux была посвящена вопросам выбора десктопа и дистрибутива, на котором он базируется. И выбор KDE в качестве рабочего окружения повлёк за собой привлечение в качестве базиса KDE-редакции диcтрибутива MX Linux. Зачем последовал призыв претворить этот выбор в реальность. Исполнение призыва и составит содержание второй части Истори про KDE и MX Linux.

Однако оказалось, что претворение выбора в реальность — многоэтапный процесс, включающий в себя: а) подготовку установочного носителя, б) подготовительные действия в Live-режиме, в) собственно установку системы-базиса вместе с рабочим окружением (в нашем случае дистрибутива MX Linux в его KDE-ипостаси), постинсталляционное конфигурирование и перекомплектацию пакетов (удаление лишних и доустановку необходимых). Во 2-й части наших Историй речь пойдёт обо всём, что предшествовало инсталляции. Её саму, как и пост-инсталляционные действия, мы с Мануалом решили отложить до части 3-й.

Подготовка установочного носителя

Как нетрудно догадаться, подготовка установочного носителя — первой на очереди, коль скоро мы предполагаем установку в реале. А для этого перво-наперво надо получить его образ (так называемый образ в стандарте ISO 9660, или просто iso-образ). В качестве установочного образа нашей будущей системы могут выступать либо релизный MX-21_KDE_x64.iso (2,6 ГБ), либо ежемесячный снапшот, в данный момент мартовский — MX-21_March_KDE.iso (2,5 ГБ). Как уже говорилось, KDE-ипостась MX Linux существует в сборке только для 64-битной архитектуры. Разумные люди, вроде меня, и тем более кот Мануал, знакомство с новым дистрибутивом начинают с установки его в виртуальной машине (в нашем случае это VirtualBox), для чего любого из указанных образов достаточно. Однако для нас с Мануалом MX не был совсем уж незнакомой системой, так что к виртуальной установке мы прибегли чисто для порядка (и для получения части иллюстраций к данной истории). Установка в реале требует, разумеется, чтобы установочный образ был воплощён на некоем установочном носителе, традиционно называемом Live OD («живой» оптический диск). Который в дальнейшем может пригодиться и для ремонтно-восстановительных работ. Хотя нынче необходимость в них возникает редко, но, как известно, неприятности, к которым ты готов, не происходят никогда. Происходят совсем другие неприятности. Не смотря на название, в настоящее время в качестве установочного носителя могут рассматриваться только USB-флешки; оптические носители практически вышли из употребления. Карты же SD или microSD, которые в принципе могут служить установочными носителями, менее универсальны: в настольных машинах соответствующий разъём редок, а ноутбки, в которых он есть всегда, почти никогда с него не могут загрузиться (требуется USB-переходник). Кроме того, подготовка установочной карты абсолютно такая же, как и флешки. Нынче существует множество хороших инструментов для записи iso-образов на флеш-накопители — информация о них регулярно появляется в соответствующем разделе форума Matuntu. Однако мы с Мануалом — ретрограды и консерваторы (очень уж консервы любим). И потому действуем по старинке, с помощью утилиты dd (в этом примере и следующих путь к файлу образа и имя файла целевого устройства следует заменить на свои реалии):

$ sudo dd if=~/Downloads/MX-21_March_KDE.iso of=/dev/sde

В качестве значения параметра of даётся имя файлв устройства, соответствующего USB-флешке целиком, а не какого-то её раздела, буде таковой имеется. И нужно помнить, что вся информация на такой флешке после записи образа исчезнет. Приведённую команду можно сопроводить такими обциями: bs=8M и status=progress. Обе они не обязательны. Но без первой (bs — размер единовременно записываемого блока, в примере — в мегабайтах) запись образа будет происходить умолчальными блоками 512 байт, что медленно и печально). А без второй опции не будет отображаться процесс копирования, Это вполне можно пережить, тем более что им создаётся лишнее мельтешение на экране. Второй способ копирования образа — самая обычная команда cp в современной её ипостаси, с именем файла образа в качестве источника и файла будущего установочного носителя в качестве цели:

$ sudo cp ~/Downloads/MX-21_March_KDE.iso /dev/sde

К целевому носителю команды cp относится всё, сказанное про таковой команды dd — это должно быть имя файла устройства целиком, и вся информация на нём после записи будет утрачена безвозвратно. Оба способа не зависят ни от дистрибутива, в котором происходит копирование, ни от копируемого образа, и дают неизменно превосходный результат. Однако на этот раз подготовка установочного носителя MX происходила в работающей системе Linux Mint Cinnamon Edition, версия 20.3 una. Там же история эта была описана (в редакторе KWrite) и проиллюстрирована в штатной программе GNOME Screenshot — самом неудобном инструменте этого назначения среди мной виденных. Для разнообразия мы с Мануалом решили воспользоваться входящей в комплект Mint’а любой редакции штатной графической утилитой записи образа на USB-накопитель (USB Image Writer), которая расположена в секции Стандартные главного меню. После её запуска при вставленной флешке возникнет такая панель: Для того, чтобы «процесс пошёл», достаточно нажать кнопку Записать — и процесс действительно пойдёт: До тех пор, пока поверх панели появится сообщение, что образ был записан — и при этом успешно: Записанный на флешку образ требует проверки: на указанном выше сайте Matuntu говорилось, что графические утилиты такого рода корректно срабатывают а) не все, б) не всегда и в) не со всеми образами. Так что результат записи требут проверки. Относительно совместимости (или несовместимости) USB Image Writer (пакет mintstick) с чем бы то ни было я в сети информации не нашёл. Так что оставался метод ползучего эмпиризма — загрузить машину со сделанной описанным образом флешки.

Дорога к «жизни»

История про загрузку MX в Live-режиме, как и предыдущая, про изготовление носителя, сочинялась в системе Linux Mint CE, и также иллюстрировалась средствами последней, в процессе установки MX в виртуальной машине. Хотя затем была выполнена реальная установка, которая и описывается с того момента, как это стало возможным. Для начала в подходящий порт нашего десктопа была воткнута флешка. В BIOS’е машины, в которой используется Legacy, обеспечивается единоразовый старт с флешки. После чего наблюдается достаточно стандартное, на первый взгляд, меню загрузчика Syslinux: В этом меню клавишей F2 можно сразу переключиться на русский язык. А также явным образом задать разрешение консоли — точнее, плотность символов, например, 800×600: На шрифте виртуальнх консолей системы после её установки это никак не отразится — но он будет впредь отображаться в меню её загручика, то есть GRUB’а. После этого этого остаётся только начать загрузку, нажав Enter на первом пункте. Однако особенность начального загрузчика MX в том, что в системе их два — и при запуске со сменного носителя Syslinux можно сменить на GRUB — тот, который раньше назывался GRUB 2 (и который станет загрузчиком установленной системы):: В режиме GRUB также можно выбрать русский язык — правда, для этого придётся пролистать длиннющий их список: Но зато одновременно будут установлены русская раскладка клавиатуры (в дополнение к американской английской) и часовой пояс Europe/Moscow — как будто на Руси других нету: Впрочем, русскую раскладку клавиатуры и часовой пояс можно будет, как мы увидим в дальнейшем, легко изменить в уже установленной системе, как в KDE (его средствами), так и в консоли (средствами дистрибутивов Deb based). Больше в загрузчике делать нечего. Поэтому возвращаемся в главное меню загрузчика (того или иного), следим за положением курсора на умолчальном (то есть первом) пункте и нажимаем Enter. Сначала мелькают строки загрузки ядра etc., затем появляется сплэш-картинка — это начинается загрузка графического режима: Финал загрузки — перед нами предстаёт рабочий стол KDE: Он выглядит так, как это было задумано разработчиками MX. И как будет выглядеть ваш рабочий стол после первого запуска. Но — но надеюсь, что только после первого: потому что разработчики MX предоставили заинтересованным лицам достаточно средств для индивидуализации системы. Разумеется, на базе KDE — эта среда, как никакая другая, к индивидуализации располагает. Впрочем, это будет темой совсем-совсем другой Истории.

Впервые в «жизни»

Первый случай потренироваться ~~на кошечках~~ в индивидуализации системы предоставляется уже в Live-режиме, Причём, как и на кошечках, — без всякого вреда и опасности для себя и системы. А, как будет показано в последней истории 2-ой части, возможно, что даже не без пользы.

Настройки в Live-режиме: зачем?

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

Экспресс-настройки: начали!

Итак, по умолчанию, сразу после запуска, на рабочем столе KDE вы, дорогие мои ~~болельщики~~ читатели, можете видеть главную управляющую панель вдоль нижнего края экрана, окно приветствия в его центре и три пиктограммы в левом верхнем углу, средняя из которых запускает установщик системы (как это показано на предыдущем скриншоте). Разумеется, первое побуждение каждого уважающего себя линуксоида — именно на этой пиктограмме и щёлкнуть. Или, на худой конец), на надписи Install MX Linux окна приветствия. Чтобы не откладывать дело установки в долгий ящик, а сразу к нему приступить. И, возможно, для большинства применителей MX первое побуждение было бы самым правильным. И им все истории, предшествующие собственно инсталляции, можно пропустить.

Однако есть и такие (а мы с котом Мануалом в их числе), кто согласен с товарищем Сааховым, что торопиться не надо: мы должны получить полноценную рабочую среду. А для этого потребуются некоторых действий по её предварительной настройке. Им и посвящены будут ближайшие Истории — сразу предупреждаю, что с сильным налётом субъективизма. Как это принято, у нас в Бразилии , подозреваю, у них тоже.

Про обои

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

Про шрифты

Вот и подошло время установок интерфейсных шрифтов, или хотя бы их кеглей: те, что прописаны по умолчанию, и я, и Мануал способны разглядеть, только уткнувшись носами в экран. Делается это, как и почти все настройки KDE, через центр управления системой, в локализованных версиях среды он обычно именуется Параметры системы. Пиктограмму её запуска майнтайнеры MX предусмотрительно поместили на управляющей панели крайней слева — даже мы с Мануалом находим её без труда: Кнопка эта вызывает окно параметров системы. В первой его секции, именуемой Внешний вид, находим пункт с ожидаемым названием Шрифты. Где имеется кнопка Изменить все шрифты, которая позволяет сделать это в один приём, С гарнитурами и шрифтоначертаниями мы пока заморачиваться не будем, ограничившись только изменением кегля: Лишь моноширинный шрифт, используемый в терминалах и текстовых редакторах, потребует индивидуальной настройки. Но и этим мы займёмся со временем, в более иной Истории, посвящённой настройкам KDE вообще.

Про клаву

Нет, это не про ту Клаву, с которой, согласно старому анекдоту, было хорошо. А про клавиатуру, её раскладки и их переключатели: без той клавы, если она настроена неправильно, реально плохо. А для профессиональных гиен… некогда пера, а ныне — клавиатуры (таким гиеном до недавнего времени был автор этих строк), так просто никак. У читателя может возникнуть вопрос: почему? И чем это мешает жить в Live-режиме, главная задача которого — обеспечить скорейшую установку системы? Мне лично это понадобилось для того, чтобы описывать процесс установки системы (в данном случае MX) параллельно с его выполнением. Для чего в Live-режиме имеются все предпосылки:

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

Стоит ли тратить на это время, если все настройки, сделанные в «живой» системе, в системе инсталлированной пропадут? Для меня опять же — стоит: сочинительская работа предвидится большая (в килобайтах). Работать я люблю в комфорте — для меня это в первую очередь привычные раскладка кириллицы и переключатели между ней и латиницей. А для тех, кто не собирается сочинять новеллы об установке системы, всё сказанное может не иметь значения. Разве что будет просто тренировкой работы в Live-режиме. Однако пора и по сути. Настройка клавиатуры запускается либо через ту же пиктограмму Параметры системы, что и настройка шрифтов, либо ПКМ на индикаторе раскладки в системной трее (по умолчанию подписан как US). Последнее проще: Сим вызывается окно модуля настройки клавиатуры, первая, вкладка которого, умочальная — Оборудование, нас сейчас не интересует (и, скорее всего, не заинтересует никогда). А нужна нам вторая вкладка, которая называется Раскладки. К ней и переходим: На беглый взгляд, тут по умолчанию указано всё, что нужно: и две раскладки (английская американская и русская), указанные в нужном порядке, и альтернативный переключатель между ними (Control+Alt+K), и индикатор текущей раскладки в системном трее (буковками US и RU). Однако и здесь что есть что делать.

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

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

В-третьих и главных, к русской раскладке можно (а по мне так нужно) добавить Вариант. Определение Русская подразумевает вариант winkeys, который принят сейчас в Иксах как уполчальный. И который совпадает с раскладкой ОС Windows, привычный большинству её пользователей — но самый неудобный из всех вариантов русской раскладки, когда-либо созданный прогрессивным человечеством.

Вообще-то вариантов у русской раскладки существует бесчисленное множество, но мой выбор — Русская пишущая машинка (устаревшая):

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

А мы успокоимся на основных настройках раскладок, которых у нас две — и, следовательно, они нуждаются в переключателе оных. Это можно сделать прямо здесь (детали, как и зачем, также будут в отдельной теме):

Но пока поступаем просто: переходим на вкладку Дополнительно, находим там пункт Переключение на другую раскладку, разворачиваем его и находим нужный нам способ переключения из числа так называемых немодальных, то есть нециклических. Для нас это: Левая Win на первую раскладку, Правая Win/Menu на раскладку последнюю. Здесь же отмечаем временный переключатель, действующий только пока нажат — им будет правый Control:

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

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

Инструменты документирования установки

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

Про инструменты вообще

Исходно материал был подготовлен, как следует из общего заголовка всех этих Историй, в KDE-редакции дистрибутива MX Linux. Однако почти всё из Истории про документирование применимо к любой Linux-системе, с маленькими поправками на особенности конкретного дистрибутива и его рабочего окружения. Поэтому первый из необходимых инструментов Live-документирования — не софтовый, а «железный». То есть внешний по отношению к «живой» системе носитель информации: иначе «всё, что заработано непосильным трудом» ©, будет безвозвратно потеряно при неизбежном рестарте по окончании инсталляции. У нас с Мануалом в любой из настольных машин уже много-много лет обязательно существует носитель (HDD или, нынче, SDD), на худой конец — раздел оного, предназначенный исключительно для хранения данных. Он является общим для всех установленных систем, где монтируется обычно в /home/data или в ~/data, и доступен из Live-среды любого дистрибутива по щелчку на его имени (label всегда тоже data) в файловом менеджере, иногда с вводом пароля администратора, а иногда и без. В общем случае в качестве такого внешнего носителя можно использовать обычную флешку (или SD-карточку) с файловой системой FAT32 или Ext 2/3/4, они также понимаются в Live-среде практически любого современного дистрибутива, обычно не требуя пароля (как это имеет место быть в MX Linux). Именно на такой независимый носитель записываются результаты документирования — по мере из создания или единовременно, после окончания процесса, копированием из «живой» файловой системы. В последнем случае, впрочем, нужно не забыть это сделать (я часто забывал, за что бывал укоряем котом Мануалом). Кстати сказать, на тот же внешний, по отношению к Live-системе, носитель можно скопировать и конфиги, изменённые в результате настройки среды KDE и её приложений. Правда, я обычно забывал это делать, или, как в данном случае просто поленился. Потому как система конфигов KDE достаточно запутанна, и мне казалось проще и быстрее выполнить заново те немногие настроечные действия, которые были описаны ранее (и те, что будут описаны вскорости). Однако при случае постараюсь это проверить. Результаты документирования представляют собой текст и иллюстрирующие его скриншоты. Или наоборот — скриншоты с сопровождающим их текстом. В любом случае в MX, как уже говорилось, есть прекрасные инструменты и для того, и для другого.

Про KWrite: тексты документации

Тексты следует создавать в текстовом редакторе. Про тех, что использует для этой цели текстовые процессоры, академик Крылов наверняка бы сказал, что они заслуживают четвертования на Дворцовой площади. Обоснование чему будет со временем дано в одной из Историй про работу с текстами. В большинство систем, использующих среду KDE (в том числе и в MX), штатно входит два текстовых редактора: KWrite, считающийся «простым», и «продвинутый» Kate. До недавнего времени я разделял эту точку зрения, являющуюся общепринятой. Не смотря на возражения Мануала, говорившего, что KWrite не так прост, как кажется.

Плотно столкнувшись с этим редактором, я присоединился к мнению Мануала: он более чем подходит для набора текстов в Live-режиме. И если в чём KWrite действительно прост — так это в настройке, что в данном случае является большим плюсом по сравнению с такими «продвинутыми» редакторами, как Kate, Geany и Komodo. Запускается KWrite из секции Служебные главного меню KDE. Настройки же его подробно описаны в Истории по данной выше ссылке. Поэтому здесь я остановлюсь на них лишь кратко. Настройки KWrite, как и всех KDE-приложений¸ вызываются через пункт Настройка его меню, далее обращаясь к подпункту Настроить редактор… И здесь нам толсто намекают, что первое, что надо сделать — это установить подходящий шрифт, потому что печатать вслепую ещё можно, а вот читать написанное — вряд ли. Первой же в списке стоит мифическая гарнитура Monospace: Мифична она тем, что представляет собой не имя реального шрифтового файла — файла с таким именем вы не найдёте в каталоге, где они содержатся (/usr/share/fonts). Нет, это так называемое «подстановочное» имя, и какой настоящей гарнитуре оно соответствует, определяется так:

$ fc-match mono

В MX, как и почти во всех современных дистрибутивах Linux, ответ на неё будет таков:

DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"

Что же, на стадии установки нас такая гарнитура вполне устраивает и в терминальных окнах, и в текстовых редакторах. До больших шрифтовых разборок, дело до которых дойдёт ещё не скоро. Забегая вперёд, отмечу, что и остальные «подстановочные» имена, которые при настройке KDE и приложений фигурируют в списке шрифтов на первых позициях (Sans Serif и Serif), определяются аналогично:

$ fc-match serif && fc-match sans 
DejaVuSerif.ttf: "DejaVu Serif" "Book"
DejaVuSans.ttf: "DejaVu Sans" "Book"

Однако в данный момент нас интересуют только шрифты рабочей области KWrite. Где, как и во всех текстовых редакторах (в отличие от «текстовых процессоров»), традиционно используется только семейство гарнитур Monospace. Если внимательно присмотреться к предыдущему скриншоту, можно даже увидеть боксик Показывать только моноширинные шрифты… Однако настоящие шрифтовые разборки у нас впереди, и будут в другом цикле Историй. Мы же вернёмся к Live-настройкам KWrite. После установки читабельного (для себя, любимого) шрифта их можно и закончить — всё остальное не обязательно. Хотя и создаёт дополнительный комфорт. А поскольку в голову пришла одна мысль, которой поделюсь в заключительной Истории 2-й части, то продолжу базар за настройки. На вкладке Шрифты больше делать нечего, переходим на вкладку Главное. А главным является — проследить, чтобы обязательно были включены опции Динамический перенос строк (иначе строки будут либо бесконечными, либо рваными) и Показать счётчик слов и символов — другого способа контролировать объём сочинённого в KWrite нет. Зато этот — очень удобный. Прочие опции этой вкладки применитель должен перепробовать сам, и решить, нужны ли они ему. Либо, не обращая на них внимания, оставить всё по умолчанию: И перейти на вкладку Границы. Где я слежу за отключением опций Предварительный просмотр текста в полосе прокрутки и Мини-карта я полосе прокрутки, за их полной (для меня, по крайней мере) бесполезности, ибо ничего предварительного я там не вижу. Лишними для моих, мирно-сочинительских целей, видятся и опции Полоса сворачивания блоков и Предварительный просмотр свёрнутого кода. Ибо не код я пишу, беллетристику сочиняю. Наконец, сортировка закладок по позиции (в тексте), ИМХО, гораздо полезней, чем по времени создания. Вкладку про цветовые схемы сейчас пропускаем, ибо отказываться от умолчальной (как на всех скришотах этой Истории), я причин не вижу. То, что вывороточная схема (черный фон, бэлый букв) полезней для глаз, чем обычная (свэтлый фон, чёрный букв), полагаю очередной легендой (не смотря на своё зрение). Да и Мануал, у которого, как у старого кота, зрение не лучше, со мной согласен. В секции Редактирование на первой же её закладке важно включить опцию Автоматически вставлять закрывающую скобку, её действие распространяется не только на обычные круглые скобки, но также на квадратные и фигурные: О прочих закладках этой секции сказать нечего. Как и о секции Открытие и сохранение — к ним обоим мы вернёмся уже при настройках инсталлированной системы. А пока, памятуя о ранее пришедшей мысли, завершим создание комфортной обстановки для редактирования настройкой панели инструментов. Доступ к настройкам панели получаем по ПКМ на ней же. И через это меню сначала устанавливаем положение текст, например, Только значки: Затем определяемся с размером пиктограмм — Очень большой будет самым подходящим для нас с Мануалом, двух полуслепых стариков: А поскольку высматривать эти самые пиктограммы им приходилось на свеобычном нынче «длинном» мониторе, то и ориентировка панели инструментом напрашивалась вертикальной: В результате всех описанных действий по настройке KWrite приобрёл следующий вид: Обращаю внимание, что вертикально ориентированная инструментальная панель пренепременнейше должна быть расположена вдоль левой стороны окна KWrite, Почему — страшная военная тайна. Но многотерпеливым моим читателям я её открою (по предъявлении справки о соответствующей форме допуска, разумеется). И случится это, когда Истории про редакторы дойдут до Kate. А пока у читателя вполне может возникнуть три вопроса: откуда берутся иконки на инструментальной панели, как среди них ориентироваться при отказе от подписей и почему они выглядят именно так, а не как по умолчанию. На последний вопрос ответить просто, хотя, возможно, ответ и покажется читателю уклончивым. Я не заскриншотил вид KWrite по умолчанию, но можете поверить мне на слово: это душераздирающее зрелище, от которого так хочется поскорее избавиться (что я и сделал, забыв про скриншот). Но выглядели они так потому, что это установлено было в настройках KDE по умолчанию. И там же меняются, о чем будут отдельные Истории. А чтобы ответить на первый вопрос, нужно вернуться к контекстному меню по ПКМ на инструментальной панели, и обратить внимание на пункт Панели инструментов, о котором раньше не не было речи. Кстати, точно такой же пункт того же содержания есть и в главном меню. В обоих случаях содержание его следующее: И достаточно убогое как в правой части, с текущими действиями, так и в левой, с действиями доступными. Однако надпись Основня панель инструментов, заставляет предполагать, что есть и ещё какой-то набор действий и соответствующих им пиктограмм. И она действительно появляется по щелчку где надо, имя ей — KatePartView (что такое KatePart — вкратце было сказано в первой части Историй про текстовые редакторы): И вот здесь в левой части окна, среди доступных действий, можно видеть полное раздолье для резвёжа: пиктограмм тут — таскай не хочу. Правда, сразу лучше этим не увлекаться: какие иконки реально должны быть всё время под рукой (то есть на глазах), определятся обычно только в ходе практической работы. А место не резиновое, даже на длинном экране и по горизонтали. Так что мы с Мануалом были поначалу очень скромны в отборе иконок, что можно видеть на последнем скриншоте. Без ответа остаётся пока второй вопрос: как ориентироваться среди иконок, лишённых подписей. Во-первых, по их виду. Так, иконки, основным элементом которых является направленная вниз стрелка, обычно связаны с записью редактируемого файла, отвечая действиям типа Сохранить и их разновидностям, вроде Сохранить как. Вот пример на нашей инструментальной панели: А разнонаправленные загогулины обычно соответствуют действиям Undo и Redo (верхняя и нижняя, соответственно): p2_030 Кстати, интуитивной понятностью привязанных действий (в том числе) и отличаются «хорошие» наборы пиктограмм от «плохих». А наборы пиктограмм из тем семейства Papirus, которые по возможности использованы в нашей системе MX, являются, по-моему, «хорошими». Во-вторых, пиктограммы сопровождаются всплывающими подсказками, содержащие которых идентично тем подписям к ним, которые мы не так давно отключили (и которые можно видеть на одном из предшествующих скриншотов). Они появляются только в момент наведения курсора на конкретную пиктограмму и, в отличие о подписей, не занимают места на экране. А в-третьих, на самом деле всё совсем не так, как в действительности. А гораздо проще: если действие пиктограмм не запомнилось сразу при настройке инструментальной панели, то оно отложится в памяти через несколько дней работы. Конечно, если пиктограмм на панели не слишком много. В связи с чем и сформулировался очередной афонаризм:

Не включай больше опций настройки, чем можешь запомнить.

Руководствуясь им (претендующим на звание Энного закона линуксоида). я закругляюсь с KWrite и перехожу к рассмотрению инструментов для создания иллюстраций процесса Live-документирования.

Про иллюстрации

Документирование процесса установки новой системы не сводится к его описанию — неотъемлемой его частью является создание иллюстраций. В качестве таковых выступают снимки экрана, именуемые в народе скриншотами. Это занятие требует соответствующего софта, то есть скриншоттеров. И их у нас есть — в штатный комплект KDE-приложений любого дистрибутива, использующего эту среду, в (почти) обязательном порядке входит скринщоттер под названием Spectacle. Он запускается из секции Служебные главного меню или просто по нажатию клавиши PrintScreen, что вызывает к жизни такое окно:

При настройках по умолчанию в момент запуска программы она делает скриншот текущего экрана целиком. Его можно скопировать в буфер обмена для последующей вставки (например, в сообщение социальной сети). А можно Сохранить — под жутким именем такого облика:Screenshot_20220402_020806.png (имя отражает дату и время съёмки. а суффикс — формат изображения) в каталог по умолчанию, каковым при первом запуске является ~/Picture. Или Сохранить как — под произвольно осмысленным именем в желательный каталог. Опция Сохранить как часто (в частности, в MX) включена по умолчанию. В этом случае изображение может быть записано и в более иных, нежели PNG, форматах: Где обращает на себя внимание, что в списке присутствует формат AVI. Да, дорогие товарищи ~~болельщики~~ читатели, Spectacle (почти) умеет делать не только скриншоты, но и скринкасты. Правда, не сам: а вызывая внешнюю программу-рекордер, которая должна быть установлена заранее. И которой в «живой» сессии MX нет, так что говорить о ней (пока?) не будем. А вообще Spectacle умеет очень много. Чтобы убедиться в этом, достаточно пощёлкать по кнопкам его окна — там всё интуитивно понятно, да к тому же ещё и описано (что немаловажно — по русски). Правда, есть и такие вещи, которые Spectacle в прямую не умеет. Так, у него нет штатной функции для съёмки всплывающих подсказок, выпадающих меню и прочих эфемерных элементова экранного изображения. Подоюной тому, что имеется у Shutter’а, о котором неоднократно рассказывалось.Правда, как можно видеть из иллюстраций к этой Истории, с помощью несложных ухищрений такие штуки обычно снять удаётся. Ещё на некоторых скриншотах можно видеть такие элементы, как текстовые пояснения и стрелки, указывающие на объекты, к которых они относятся. Средств для их создания в Spectacle также не увидеть. Для этого требуется привлечение специализированных программ, таких, как Flameshot или Ksnip. В Live-среде MX их нет, но доустановить их в инсталированную систему труда не составит. Однак в мои сегодняшние задачи не входит рассмотрение всех наличествующих или отсутствующих функций Spectacle, а также описание работы с этой программой. Наша задача сейчас гораздо скромнее — настройка её для целей экспресс-документирования процесса установки. Впрочем, таких необходимых настроек не много. В первой вкладке для разумеющих русскую грамоту всё понятно без комментариев:
Не намного больше интеллектуальных усилия нужно, чтобы вникнуть в смысл опций второй вкладки. Очевидно, что здесь определяется каталог, в который по умолчанию будут складироваться скриншоты (его целесообразно сделать тем же, куда сохраняются и тексты документирования) и маска их имени (совсем не обязательно предложенная — достаточно заголовка материала и счётчика картинок): Те, кому приходилось делать подряд многие десятки, а то и сотни скриншотов, знают, насколько это важно — легко сохранять их где надо и под каким надо именем. Так вот, в Spectacle это сделано хорошо: не нужно лазать в реестроподобный dconf-editor для смены учолчального каталога, после первой записи в отличное от него место оно запоминается (до следующей смены или до конца сеанса), а «счётчик кандров» работает на полном автомате. Наконец, третья, последняя, вкладка содержит список исходно предопределённых горячих клавиш для различных областей съёмки: p2_035 Здесь требуется маленький комментарий. Целесообразно определить хоткеи для съёмки текущего экрана — как видно из скриншота, по умолчанию таковых не имеется. Я чисто волюнтаристически назначил для этого Control+Shift+PrtScr. Что, в частности, позволяет сделать скриншот самого Spectacle: Таким образом у нас образовалось около 30 скриншотов, иллюстрирующим процесс… нет, пока ещё не установки, а настройки системы в Live-режиме. Их хотелось бы просмотреть и, при необходимости, немножко поправить. Для чего тоже есть вполне справный инструмент — вьювер изображений Gwenview, который имеет также некоторые функции редактирования. В него можно попасть непосредственно из Spectacle, нажав экранную кнопку Экспорт: p2_037 Можно вызвать Gwenview щелчком по имени подходящего файла в файловом менеджере. И, разумеется, через главное меню, из секции Графика. В любом случае окно вьювера будет выглядеть примерно так:

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

А собственно настройки программы через соответствующий пункт меню, Настройки —> Настроить Gwenview, настолько тривиальны, что об этом даже смешно говорить. Единственное, о чём тут стоит задуматься — Качество JPEG. По умолчанию оно установлено на 90%, и увеличивать его вроде некуда. А вот уменьшать, пр использовании этого формата (чего мы до сих пор не делали), возможно, иногда имеет смысл ради уменьшения размера файла: p2_040 На этом сердце с настройками всего, что может потребоваться впредь (до завершения «живого» сеанса), и успокоилось. Казалось бы, можно приступать к инсталляции, открыв установщик на первом рабочем столе, и к параллельному документированию процесса, запустив на втором рабочем столе KWrite, например. Ан нет. Ранее я обещал рассказать, как сохранить все описанные выше настройки KDE и приложений а инсталлированной системе.

Про сохранение Live-настроек

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

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

Как нам сообщало Окно приветствия, нашего Live-пользователя зовут demo. И, стало быть, домашний каталог его — /home/demo. Единственное, что надо озаботиться сохранением атрибутов файлов — для пользовательских конфигов это иногда может быть важно, а несомая на флешке отсталая FAT32 обычную файловую атрибутику Linux’а не поддерживает.

Выход простой — архивирование домашнего каталога гуртом — ведь кроме пользовательских конфигов (так называемых dot-файлов), там у нас ничего нет. Если, конечно, мы не скриншотили свои действия туда, куда Spestacle предлагал по умолчанию, то есть в /home/demo/Изображения.

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

Для этого:

переходим в домашний каталог нашего «живого» пользователя (напоминаю — в /home/demo/),

комбинацией Control+H включаем показ скрытых файлов (это те самые пользовательские конфиги, часть их которых была изменена нашими настройками),

комбинацией Control+A выделяем всё содержимое каталога,

из контекстного меню по ПКМ выделяем пункт Упаковать и

выбираем формат компрессированного архива TAR.GZ (как самый быстропакуемый и быстрораспаковываемый, хотя и не рекордсмен по компресии).

После чего в домашнем каталоге появляется файл компрессированного архива (в Linux’а архивация и компрессия — это разные вещи) с у молчальным именем demo.tar.gz.

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

Теперь открываем флешку в Dolphin’е (там появляются пункты Подключаемый устройства —> Сменный носитель) и копируем на неё архивный файл из /home/demo/. Ну а что с ним делать дальше — поговорим в части 3, после завершения инсталляции и перезагрузки машины.

Описанная процедура, как было сказано, предполагает, что на флешке имеет место быть файловая система FAT32. Если же она раньше была кем-то (интересно, кем?) переформатирована в какую-либо Linux’овую файловую систему, скорее всего, в Ext2 или в Ext4 (а у меня в хозяйстве таких флешек большинство, фабрично отформатированную флешку надо очень поискать в закромах Родины), то всё гораздо проще: можно обойтись без создания архива.

Вызываем эмулятор терминала (в KDE штатно — Konsole), в нём запускаем командой mc имеющийся в Live-среде MX файловый менеджер Midnight Commander (он очень похож на командира Norton’а, если кто о таком ещё помнит), в одной его панели выводим каталог /home/demo, а в другой содержимое воткнутой и поключённой в каталог /media/alv/932E-C2E6 флешки (последовательность цифири и букв — её идентификатор):

Теперь для копирования каталога /home/demo нажимаем клавишу F5. Идея этой истории, последней в части 2, пришла мне в голову во время доводки оной уже в установленной и работающей KDE-редакции MX. Поэтому на скриншотах фигурирует не каталог некоего demo, а домашний каталог меня, любимого.

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

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

Хотя времени на снимок будет с избытком — копирование неархивированного каталога займёт существенно больше времени, чем копирование сжатого архива. Почему — сейчас обсуждать не место и не время, но не из-за объёма: в моём случае архив занимал 1,6 ГБ, а каталог суммарно — 2,3 ГБ (я же говорил, что компрессор gzip, которым архив обрабатывался — не чемпион по степени сжатия файлов).

Так что возможно, что перед отправкой на исполнение надо было идти не к пункту Дальше, а к следующему — В фоне, и заниматься другими делами. Хотя это можно делать и без фонового копирования, ибо Linux — не Windows, и его многозадачность всамделишняя.

Я, например, сейчас сочиняю настоящий текст, и не испытываю никакого дискомфорта от того, что в соседнем окне происходит копирование:

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

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

Однако рано или поздно заканчивается всё. И не успел я дописать эту историю, как процесс пофайлового копирования закончился (время, как всегда, засечь забыл). И теперь мы на самом деле готовы к установке системы. Чем мы и займёмся в части 3. А пока

Привет, уркаганы, антракт!
©Владимир Турьянский

Продолжение — после Дня геолога. Ибо

В День геолога подарок
Сочинил я сам себе.
©почти Булат наш, Шалвовичstrong>

В виде второй части Истории про KDE и MX Linux…

Претворение в реальность

Подготовка установочного носителя

$ sudo dd if=~/Downloads/MX-21_March_KDE.iso of=/dev/sde

$ sudo cp ~/Downloads/MX-21_March_KDE.iso /dev/sde

Дорога к «жизни»

Впервые в «жизни»

Настройки в Live-режиме: зачем?

Экспресс-настройки: начали!

Про обои

Про шрифты

Про клаву

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

Инструменты документирования установки

Про инструменты вообще

Про KWrite: тексты документации

$ fc-match mono

В MX, как и почти во всех современных дистрибутивах Linux, ответ на неё будет таков:

DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"

$ fc-match serif && fc-match sans 
DejaVuSerif.ttf: "DejaVu Serif" "Book"
DejaVuSans.ttf: "DejaVu Sans" "Book"

Не включай больше опций настройки, чем можешь запомнить.

Про иллюстрации

При настройках по умолчанию в момент запуска программы она делает скриншот текущего экрана целиком. Его можно скопировать в буфер обмена для последующей вставки (например, в сообщение социальной сети). А можно Сохранить — под жутким именем такого облика:Screenshot_20220402_020806.png (имя отражает дату и время съёмки. а суффикс — формат изображения) в каталог по умолчанию, каковым при первом запуске является ~/Picture. Или Сохранить как — под произвольно осмысленным именем в желательный каталог. Опция Сохранить как часто (в частности, в MX) включена по умолчанию. В этом случае изображение может быть записано и в более иных, нежели PNG, форматах: Где обращает на себя внимание, что в списке присутствует формат AVI. Да, дорогие товарищи ~~болельщики~~ читатели, Spectacle (почти) умеет делать не только скриншоты, но и скринкасты. Правда, не сам: а вызывая внешнюю программу-рекордер, которая должна быть установлена заранее. И которой в «живой» сессии MX нет, так что говорить о ней (пока?) не будем. А вообще Spectacle умеет очень много. Чтобы убедиться в этом, достаточно пощёлкать по кнопкам его окна — там всё интуитивно понятно, да к тому же ещё и описано (что немаловажно — по русски). Правда, есть и такие вещи, которые Spectacle в прямую не умеет. Так, у него нет штатной функции для съёмки всплывающих подсказок, выпадающих меню и прочих эфемерных элементова экранного изображения. Подоюной тому, что имеется у Shutter’а, о котором неоднократно рассказывалось.Правда, как можно видеть из иллюстраций к этой Истории, с помощью несложных ухищрений такие штуки обычно снять удаётся. Ещё на некоторых скриншотах можно видеть такие элементы, как текстовые пояснения и стрелки, указывающие на объекты, к которых они относятся. Средств для их создания в Spectacle также не увидеть. Для этого требуется привлечение специализированных программ, таких, как Flameshot или Ksnip. В Live-среде MX их нет, но доустановить их в инсталированную систему труда не составит. Однак в мои сегодняшние задачи не входит рассмотрение всех начичествующих или отсутствующих функций Spectacle, а также описание работы с этой программой. Наша задача сейчас гораздо скромнее — настройка её для целей экспресс-документирования процесса установки. Впрочем, таких необходимых настроек не много. В первой вкладке для разумеющих русскую грамоту всё понятно без комментариев:
Не намного больше интеллектуальных усилия нужно, чтобы вникнуть в смысл опций второй вкладки. Очевидно, что здесь определяется каталог, в который по умолчанию будут складироваться скриншоты (его целесообразно сделать тем же, куда сохраняются и тексты документирования) и маска их имени (совсем не обязательно предложенная — достаточно заголовка материала и счётчика картинок): Те, кому приходилось делать подряд многие десятки, а то и сотни скриншотов, знают, насколько это важно — легко сохранять их где надо и под каким надо именем. Так вот, в Spectacle это сделано хорошо: не нужно лазать в реестроподобный dconf-editor для смены учолчального каталога, после первой записи в отличное от него место оно запоминается (до следующей смены или до конца сеанса), а «счётчик кандров» работает на полном автомате. Наконец, третья, последняя, вкладка содержит список исходно предопределённых горячих клавиш для различных областей съёмки: p2_035 Здесь требуется маленький комментарий. Целесообразно определить хоткеи для съёмки текущего экрана — как видно из скриншота, по умолчанию таковых не имеется. Я чисто волюнтаристически назначил для этого Control+Shift+PrtScr. Что, в частности, позволяет сделать скриншот самого Spectacle: Таким образом у нас образовалось около 30 скриншотов, иллюстрирующим процесс… нет, пока ещё не установки, а настройки системы в Live-режиме. Их хотелось бы просмотреть и, при необходимости, немножко поправить. Для чего тоже есть вполне справный инструмент — вьювер изображений Gwenview, который имеет также некоторые функции редактирования. В него можно попасть непосредственно из Spectacle, нажав экранную кнопку Экспорт: p2_037 Можно вызвать Gwenview щелчком по имени подходящего файла в файловом менеджере. И, разумеется, через главное меню, из секции Графика. В любом случае окно вьювера будет выглядеть примерно так:

Про сохранение Live-настроек

Для этого:

переходим в домашний каталог нашего «живого» пользователя (напоминаю — в /home/demo/),

комбинацией Control+A выделяем всё содержимое каталога,

из контекстного меню по ПКМ выделяем пункт Упаковать и

Привет, уркаганы, антракт!
©Владимир Турьянский

Продолжение — после Дня геолога. Ибо

В День геолога подарок
Сочинил я сам себе.
©почти Булат наш, Шалвовичstrong>

В виде второй части Истории про KDE и MX Linux…

MX, UEFI и ноутбук

Первая часть Историй про KDE и MX Linux была посвящена вопросам выбора десктопа и дистрибутива, на котором он базируется. И выбор KDE в качестве рабочего окружения повлёк за собой привлечение в качестве базиса KDE-редакции диcтрибутива MX Linux. Зачем последовал призыв претворить этот выбор в реальность. Исполнение призыва и составит содержание следующей части Истори про KDE и MX Linux.

Подготовка установочного носителя

$ sudo dd if=~/Downloads/MX-21_March_KDE.iso of=/dev/sde

$ sudo cp ~/Downloads/MX-21_March_KDE.iso /dev/sde

Дорога к «жизни»

Впервые в «жизни»

Настройки в Live-режиме: зачем?

Экспресс-настройки: начали!

Про обои

Про шрифты

Про клаву

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

Инструменты документирования установки

Про инструменты вообще

Про KWrite: тексты документации

$ fc-match mono

В MX, как и почти во всех современных дистрибутивах Linux, ответ на неё будет таков:

DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"

$ fc-match serif && fc-match sans 
DejaVuSerif.ttf: "DejaVu Serif" "Book"
DejaVuSans.ttf: "DejaVu Sans" "Book"

Не включай больше опций настройки, чем можешь запомнить.

Про иллюстрации

При настройках по умолчанию в момент запуска программы она делает скриншот текущего экрана целиком. Его можно скопировать в буфер обмена для последующей вставки (например, в сообщение социальной сети). А можно Сохранить — под жутким именем такого облика:Screenshot_20220402_020806.png (имя отражает дату и время съёмки. а суффикс — формат изображения) в каталог по умолчанию, каковым при первом запуске является ~/Picture. Или Сохранить как — под произвольно осмысленным именем в желательный каталог. Опция Сохранить как часто (в частности, в MX) включена по умолчанию. В этом случае изображение может быть записано и в более иных, нежели PNG, форматах: Где обращает на себя внимание, что в списке присутствует формат AVI. Да, дорогие товарищи ~~болельщики~~ читатели, Spectacle (почти) умеет делать не только скриншоты, но и скринкасты. Правда, не сам: а вызывая внешнюю программу-рекордер, которая должна быть установлена заранее. И которой в «живой» сессии MX нет, так что говорить о ней (пока?) не будем. А вообще Spectacle умеет очень много. Чтобы убедиться в этом, достаточно пощёлкать по кнопкам его окна — там всё интуитивно понятно, да к тому же ещё и описано (что немаловажно — по русски). Правда, есть и такие вещи, которые Spectacle в прямую не умеет. Так, у него нет штатной функции для съёмки всплывающих подсказок, выпадающих меню и прочих эфемерных элементова экранного изображения. Подоюной тому, что имеется у Shutter’а, о котором неоднократно рассказывалось.Правда, как можно видеть из иллюстраций к этой Истории, с помощью несложных ухищрений такие штуки обычно снять удаётся. Ещё на некоторых скриншотах можно видеть такие элементы, как текстовые пояснения и стрелки, указывающие на объекты, к которых они относятся. Средств для их создания в Spectacle также не увидеть. Для этого требуется привлечение специализированных программ, таких, как Flameshot или Ksnip. В Live-среде MX их нет, но доустановить их в инсталированную систему труда не составит. Однак в мои сегодняшние задачи не входит рассмотрение всех начичествующих или отсутствующих функций Spectacle, а также описание работы с этой программой. Наша задача сейчас гораздо скромнее — настройка её для целей экспресс-документирования процесса установки. Впрочем, таких необходимых настроек не много. В первой вкладке для разумеющих русскую грамоту всё понятно без комментариев:
Не намного больше интеллектуальных усилия нужно, чтобы вникнуть в смысл опций второй вкладки. Очевидно, что здесь определяется каталог, в который по умолчанию будут складироваться скриншоты (его целесообразно сделать тем же, куда сохраняются и тексты документирования) и маска их имени (совсем не обязательно предложенная — достаточно заголовка материала и счётчика картинок): Те, кому приходилось делать подряд многие десятки, а то и сотни скриншотов, знают, насколько это важно — легко сохранять их где надо и под каким надо именем. Так вот, в Spectacle это сделано хорошо: не нужно лазать в реестроподобный dconf-editor для смены учолчального каталога, после первой записи в отличное от него место оно запоминается (до следующей смены или до конца сеанса), а «счётчик кандров» работает на полном автомате. Наконец, третья, последняя, вкладка содержит список исходно предопределённых горячих клавиш для различных областей съёмки: p2_035 Здесь требуется маленький комментарий. Целесообразно определить хоткеи для съёмки текущего экрана — как видно из скриншота, по умолчанию таковых не имеется. Я чисто волюнтаристически назначил для этого Control+Shift+PrtScr. Что, в частности, позволяет сделать скриншот самого Spectacle: Таким образом у нас образовалось около 30 скриншотов, иллюстрирующим процесс… нет, пока ещё не установки, а настройки системы в Live-режиме. Их хотелось бы просмотреть и, при необходимости, немножко поправить. Для чего тоже есть вполне справный инструмент — вьювер изображений Gwenview, который имеет также некоторые функции редактирования. В него можно попасть непосредственно из Spectacle, нажав экранную кнопку Экспорт: p2_037 Можно вызвать Gwenview щелчком по имени подходящего файла в файловом менеджере. И, разумеется, через главное меню, из секции Графика. В любом случае окно вьювера будет выглядеть примерно так:

Про сохранение Live-настроек

Для этого:

переходим в домашний каталог нашего «живого» пользователя (напоминаю — в /home/demo/),

комбинацией Control+A выделяем всё содержимое каталога,

из контекстного меню по ПКМ выделяем пункт Упаковать и

Привет, уркаганы, антракт!
©Владимир Турьянский

Продолжение — после Дня геолога. Ибо

В День геолога подарок
Сочинил я сам себе.
©почти Булат наш, Шалвовичstrong>

В виде следующей части Истории про KDE и MX Linux…

Тенденции современного Linux’а

Можно догадываться, что конечным результатом тенденции, отмеченной во вступительной Истории, станет со временем полное отмирание режима Legacy BIOS — все, и потребители, и применители упадут в жаркие объятья «чистого» UEFI.

Тенденции…

Что струится в одном русле с явлениями последних 10–15 лет в «железе» и софте. Первая из этих тенденций — исключительно «железная», и прямого отношения к Linux’у не имеет, далеко выходя за его рамки. Это — почти полное вытеснение «квадратных» дисплеев «длинными».

Остальные же тенденции так или иначе связаны с Linux’ом:

замена GRUB Legacy на GRUB — что характерно, вначале они назывались GRUB и GRUB2, соответственно;
появление в утилитах дисковой разметки на позиции по умолчанию GPT-схемы вместо разметки в стиле MSDOS;
попытки продвижения файловой системы (с элементами управления логическими томами) BTRFS в качестве умолчальной при инсталляции некоторых дистрибутивов (например, openSUSE);
вялотекущее внедрение Wayland’а вместо X’ов;
тотальная systemd’изация дистрибутивов по принципу Василь Алибабаича: «все побежали — и я побежал».

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

Счастье для всех!.. Даром!.. Сколько угодно счастья!.. Хватит всем!.. Никто не уйдёт обиженный!..
© Братья-классики

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

…и их развитие

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

В отношении дисплеев маятник уже качнулся в обратную сторону — они становятся всё более «квадратными». В продаже опять появились стационарные мониторы 5:4, а в ноутбуках замечены даже и формата 3:2. С компьютерных экранов практически исчез некогда новомодный глянец — не иначе под влиянием лиц с не соколиным зрением. А как-то в сети мне попалось высказывание: по настоящему профессиональный монитор должен управляться нормальными кнопками, а не какими-то сенсорными тыкалками.

С GRUB’ами ситуация обратная: GRUB Legacy покинул сцену, и, видимо, безвозвратно. Хотя в дистре, наиболее приверженном традициям, в Slackware, до сих пор по умолчанию используется LILO…

Широкое распространение SSD в настольных персоналках и особенно в ноутбуках сделало бессмысленными дискуссии о преимуществах GPT-стиля разметки над разметкой в стиле MSDOS¸или наоборот. Потому что разделов, необходимых для размещения системы и данных, хватит при любом стиле.

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

Что же до файловых систем, которые должны размещаться на разделах SSD, то BTRFS, похоже. на роль универсального решения (пока?) подходит меньше всего. Почему — очень доходчиво объяснил Эдуард Шишкин в своём Втором интервью на Хабре . Надо заметить, что с ситуацией, похожей на описанную Эдуардом, мне столкнуться довелось. После чего я вычеркнул BTRFS из списков живущих (на моих машинах).

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

Что касается Wayland’а, надо отдать ему должное: он прогрессирует ползуче-поступательно. Следуя максиме: шаг вперёд — ни шагу назад. Став умолчальным графическим сервером в GNOME лет чуть не пять назад, Wayland с этой позиции не отступал. Не смотря на явную недоделанность этого решения. Правда, уж не знаю чего — Wayland’а или GNOME. Но в любом случае предполагалась дальнейшая экспансия Wayland’а.

В противоположность этому Джонатан Ридделл (разработчик KDE neon — не столько дистрибутива, сколько репозитория KDE-программ) пару-тройку лет назад сказал примерно так: Wayland будет стартовать в сеансе KDE только тогда, когда он полностью сравнится по функционалу с таковым в X-сеансе. Правда, по моим наблюдениям над дистрибутивом NuTyX, день этот недалёк.

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

Про systemd

Если деятельность «прогрессоров» в отношении Wayland’а продолжается полным ходом, и конца-краю ей пока не видно, то внедрение системы инициализации systemd можно считать в целом законченным. И, казалось бы, успех его неоспорим. Он выразился триумфальным шествием ~~советской власти~~ systemd’а по репозиториям дистрибутивов Linux’а. Когда в середине десятых годов буквально за считанные месяцы разработчики почти всех распространённых дистрибутивов, отрешившись от своих гибельных заблуждений, приобщились systemd’овой вере.

В числе systemd’изированных были такие дистры, как:

Fedora (2013-01-15 — что не удивительно, ведь systemd появился именно из этой касторовой шляпы с красноватым оттенком) и следующая за нею, как собачка, openSUSE (2013-03-13), служащие полигонами для промышленных RHEl и SLE, соответственно; что характерно, эти коммерческие сородичи перешли на systemd существенно позже, в конце десятых; причём SLE в данном случае полезла вперёд поперёк батьки-RHEl’а;
Arch и Debian, популярные среди участников сообществ OSS и FSS, также оказались в числе первых, их «воцерковление» относится примерно к 2015 году; правда, во втором случае этому предшествовала напряжённая борьба, закончившаяся тем, что наиболее консервативная часть Debian’истов создала собственный дистрибутив, Devuan, поначалу отличавшийся от прародителя только использованием SysV;
Ubuntu, разработчики которой на протяжении ряда лет развивали собственную систему инициализации, Upstart, оказалась в первом эшелоне прогресса, вместе со всеми многочисленными своими отпрысками, законными и незаконными, которые поголовно бросились за мамкой.

Я упомянул далеко не все systemd’изированные дистрибутивы, особенно клоны основных. Так что по победным реляциям systemd’изаторов во вроемя их триумфального шествия можно было подумать, что осталось всего два дистрибутива, не подверженных этой эпидемии: 1) Slackware убеждённого традионалиста Патрика Фолькердинга, сохранившего приверженность не только к загрузчику LILO, но и к системе SysV, и 2) CRUX Пера Лидена и его продолжателей, использующего реликтовую bsdinit. Однако в действительности всё оказалось не совсем так, как на самом деле хотелось бы systemd’изаторам.

В момент, когда сочиняются эти строки (31.05.2022, 15:22:27 MSK), на Distrowatch’е зарегистрирован 271 дистрибутив свободных UNIX-подобных систем в статусе Active. То есть практически все существующие и разрабатываемые, не приостановленные (Dormant) и не заброшенные (Discontinued).

Из них 240 позиций — это дистрибутивы Linux. Остальное — системы на основе BSD и Solаris (14 и 4, соответственно), а также загадочные другие (среди которых знаменитая своим долгостроем ReactOS). И на всём остальном systemd не работает (да и не должна, по замыслу Поттеринга). И потому в дальнейшем состязании они не участвуют: перед нами проходит поединок прогрессивной systemd и отсталой SysV среди дистрибутивов Linux’а.

А теперь присмотримся к участникам «поединкам» — и сразу станет видно, почему это слово кот Мануал настоял заключить в кавычки. На Distrowatch’е в резюме каждого дистрибутива Linux’а (как и всех более оных систем) есть строка Init Software, по значениям которой (в том числе и) можно сделать выборку на странице поиска:

Присмотримся к этим значениям — и будем несколько удивлены их количеством. Не считая таких «членов», как All, Not systemd и Other, их около десятка:

Так что наше состязание получается отнюдь не поединком, а скорее матчем: Сборная СССР (systemd) против Сборной мира (остальные init-системы). Или наоборот? Пока замнем этот вопрос. По началу будем считать их клубными командами: systemd против SysV. Первая на текущий момент выставляет 182 игрока, начиная с номера первого, MX Linux (1-е место в общем рейтинге)).

На это команда SysV отвечает слабым составом в 38 игроков. Где за номером 1-м идёт… кто бы вы думали? Правильно, MX Linux. Который, как мы только что видели, был первым номером и в команде systemd.

И тут вспоминаем, что в критический момент матча SysV была усилена игроками из дружественных клубов init-систем BSD-стиля: RC, OpenRC, runit — это те команды, про стиль игры которых я знаю точно. Хотя подозреваю, что к той же игровой школе примыкают и остальные клубы — Dinit, S6, Shepherd, Suite66. Таким образом клубная команда превратилась в сборную ~~людей и эльфов~~ Not systemd, игравшую против клуба ~~орков~~ systemd на своём поле. То есть на поле разнообразия, дающего свободу выбора.

И тогда силы сторон изменились: против клуба systemd в составе 185 игроков выступила уже сборная Not systemd вывела на поле 97 форвардов, хавбеков и беков. Численное преимущество всё равно остаётся за клубом, но менее чем двукратное. Чего явно недостаточно для утверждения о победе systemd’а в мировом масштабе.

Только не говорите мне, что суммарное число участников состязания не равно количеству состязующихся: это видно без KCalk, к которому рука невольно тянется для проверки такого чуда. Но вопросы — к Distrowatch’икам: им, видимо, удалось доказать, что от перестановки мест слагаемых сумма изменяется, и численность сборной не равна числу игроков, представляющих входящие в неё клубы. Так что ждём сообщения о присуждении ребятам Филдсовской или, на худой конец, Абелевской премии…

А пока лишь констатируем, что к числам, приводимым на Distrowatch’е, следует относиться с осторожностью. И предложим своё объяснение наблюдаемого феномена.

Для чего вспомним, в какой системе сочиняются эти строки. А ведь в этой системе (кто забыл — напоминаю: она называется MX Linux) init-схема может быть выбрана при загрузке системы как одна из двух (SysV или systemd) Advanced options в меню GRUB’а, причём умолчальной является именно загрузка SysV. Подчёркиваю: это одна и та же система, установленная с одного и того же образа, варианты её отличаются только init-схемами и последующим управлением системными сервисами.

Следствие показало, что поддержка в одном дистрибутиве и SysV, и systemd — достаточно распространённая ситуация. Правда, обычно, насколько я могу судить, для этого используются разные образы. И взаимоотношения между SysV и systemd могут быть разными: в одних дистрах, как в MX Linux’, первая используется как умолчание, вторая — как опция, в других системах — наоборот.

Далеко не всегда дело ограничивается двумя init-схемами: в качестве третьей могут выступать OpenRC или runit. Не является обязательной и поддержка systemd: в первом бунтаре против прогресса, Debuan’е, поддерживается три init-схемы — OpenRC, runit, SysV. А вот systemd среди них и не найти.

Однако рекордсменом по числу поддерживаемых init-систем следует считать дистрибутив Artix Linux. Он поддерживает пять систем инициализации: Dinit, OpenRC, runit, S6, Suite66. Характерно, что в этом ряду нет не только systemd (как в Debuan’е), но и SysV:

То есть разработчики Artix’а являются одновременно самыми бескомпромиссными борцам как с «прогрессом» в лице первой init-системы, так и с замшелым традиционализмом второй.

Нет в Artix’е и RC-схемы инициации (той, что обычно называется bsdinit). Вместо неё продвигаются её усовершенствованные потомки, вроде упомянутых выше OpenRC и runit. Которые, в отличие от systemd, не претендуют на «мировое господство» в мире свободного софта.

Характерно, что в Artix’е нет какой-либо умолчальной init-системы, по отношению к которой все остальные рассматривались бы как опциональные. Все они равноправны, и используются в соответствующих вариантах отдельных редакций дистрибутива, которые различаются рабочими средами — от LXDE и LXQt до Cinnamon и KDE:

На fig. 5 можно видеть, что имеется два исключения — Gtk- и Qt-сборки сообщества. Они которые имеют по одному варианту init-системы — с OpenRC.

Как уже говорилось, тотальное внедрение UEFI вместе с исчезновением режима BIOS Legacy, хотя и не вписывается в рамки только свободного софта. Однако повлияло на развитие дистрибутивов Linux. В первую очередь — их инсталляторов и утилит дисковой разметки. О чём и пойдёт речь в следующей Истории.

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

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

Длинные против квадратных

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

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

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

Хвала Ахурамазде, сейчас применители находятся именно в таком положении. Разработчики, занимающиеся рабочими средами, учли ошибки прошлого, когда не один год потребовался на то, чтобы придать пристойный вид их управляющим панелям при вертикальной ориентации. Ныне же, если вдруг из продажи в одночасье исчезнут все до одного «длинные» дисплеи — рыдать не придётся: интерфейс основных рабочих сред с вертикально-ориентированного на ориентированный горизонтально займёт считанные минуты. По крайней мере, за Cinnamon и KDE ручаюсь — плавали, знаем…

Против GRUB’а

Линию с обоими GRUB’ами можно было бы считать исчерпанной полной победой второго GRUB’а. Если бы не два обстоятельства. Первое — то, что в некоторых дистрибутивах (конкретно, в Slackware) в качестве загрузчика по умолчанию притулилось lilo. Имеется оно и в репозиториях ряда систем, от таких традиционных, как Debian (Buster и Sid), до вполне фронтирной Ubuntu и очень разнообразных вариантов Alt’а:

У «счастливых» обладателей материнок UEFI only выбор поуже https://pkgs.org/search/?q=elilo. Зато им доступно elilo из репозиториев полупромышленной openSUSE:

Так что у стойких нелюбителей второGRUB’а есть то, «чем могли бы ещё воевать». Но не это главное. Потому что существует и второе обстоятельство: появление UEFI BIOS сделало возможным загрузку ОСи без загрузчика. От слова «вообще». Задачу эту не назовёшь совсем уж тривиальной (особенно для того самого пенсионера, которому адресована большая часть моих Историй), но и совсем сверхъестественной она тоже не является, и в сети можно найти немало материалов на на эту тему.

Правда, мне не доводилось встречать реализацию «загрузки без загрузчика» в качестве штатной опции в каком-либо дистрибутиве. Почему — тайна сия велика есть. Ведь при всё большем распространении машин с UEFI без BIOS Legacy сам Ахурамазда велел: обеспечить их загрузку собственными средствами…

Схемы, разделы, файловые системы

Во многом аналогичный случай происходит сейчас с нашей коровой… то есть, пардон, со схемами разметки, разделами и файловыми системами. Машины с UEFI, особенно UEFI only изменили взгляд на специализированные загрузчики (неважно, GRUB ли это, GRUB Legacy, Lilo или что другое). Точнее, должны были бы изменить, чего в действительности пока не происходит.

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

Хотя, каюсь, не видал я APFS — файловой системы под macOS, специально ориентированной на твердотельные накопители. И даже не слышал о ней от людей, заслуживающих доверия. Так что, возможно, пока я тут пасквилянтствую, Apple уже лет пять как вовсю использует прогрессивную файловую систему для современных SSD. Хотя есть большое подозрения, что вся SSD-специфичность APFS — в её категорической несовместимости с HFS+…

Так или иначе, но вопрос о коррективах систем размещения наборов данных назрел. И GPT-разметка — вроде как первый шаг в этом направлении. Однако не успела она получить общее признание, как оказалось: заполнить 127 потенциально возможных GPT-разделов в условиях настольной персоналки (о серверах речи нет) просто нечем. А файловые системы pool’а ZFS или субтома BTRFS вовсе не обязаны находиться каждая на своём разделе в какой бы то ни было разметке.

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

О системах инициализации

Теперь, когда отгорели костры эмоций, вызванные «битвой столетия» — SysV vs systemd, можно констатировать: последняя одержала в этой битве победу. Но — не сокрушительную: сверхзадача, то есть унификация всего и вся в рамках systemd, не была достигнута. Правда. сокрушить Upstart удалось легко и быстро. Но возможно, что уже тогда для Марка Шаттлворта уже тогда

…первым пунктом было вопрос «ученье Африке»,
А потом уж про Ubuntu, в части «Разное»
© почти Галич

Но, не смотря на недавние победные реляции, осталось немало дистров, которые продолжают поддерживать SysV, и не только как опцию, но и как умолчание (примером чему — тот же MX). Да и число дистрибутивов Not systemd вроде меньше не стало, скорее, наоборот.

Более того, экспансия systemd послужила толчком для активизации разработки более иных init-систем. Например, BSD-стиля: ранее на слуху, кроме собственно bsdinit (иначе называемой RC), были только openRC и runit. Ныне в сети то и дело натыкаешься на S6, Suite66, Shepherd, Dinit. Возможно, что есть и такие init-системы, на которые мне наткнуться ещё не пришлось…

В общем, победа systemd оказалась Пирровой: никакой унификации init-систем не наступило — напротив, число схем инициализации увеличилось. И, соответственно, возросло количество дистрибутивов, поддерживающих несколько таких схем. А разработчики Archlinux’а, одного из пионеров systemd’изации (а ранее — одного из последних бастионов BSD-стиля) буквально на днях обмолвились об отказе от init-системы по умолчанию в принципе.

Опередивши батьку-Arch’а на пути в пекло, ту же политику проводят и разработчики Artixlinux’а, о котором я надеюсь подробно рассказать в ближайшей серии Историй.

О Wayland’е

С Wayland’ом проще всего — похоже, что эта единственная тенденция, которая может (почти) полностью реализоваться в обозримом будущем. Да, в GNOME она как бы реализована уже лет 5. Так что ждём только её проявления в KDE. Что проще всего отслеживать по дистрибутиву KDE Neon: как только в нём сессия Wayland (Plasma) появится по умолчанию — значит, Джонатан Ридделл признал её соответствующей по функционалу Иксовой сессии KDE.

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

Лично меня функционал Wayland (Plasma) с точки зрения того, что мне нужно (например, множественных раскладок клавиатуры) удовлетворяет уже в современном виде. То есть мы вот-вот получим полноценную систему KDE не в Иксовом профиле, а в Wayland’овом. Вопрос в другом — а получит ли применитель от нового графического сервера какой-нибудь профит по сравнению с тем, что он имел в Иксовом сеансе?

Вопрос, конечно, интересный… И однозначного ответа на него, как понимает читатель-применитель, нет и пока быть не может. До сих пор единственное, в чём заметно было «превосходство» Wayland’а над Иксами — это потребление памяти, в чём разница между графическим системами достигала иногда процентов 30-ти (сами догадываетесь в пользу кого).

Ныне эта разница существенно сгладилась. Утилита neofetch в момент старта графического режима для сеанса Иксов даёт значение 446 МБ:

В сеансе же Wayland (Plasma) в идентичных условиях той же самой виртуальной машины это значение составляет 491 МБ:

Учитывая, что Wayland ещё не достиг статуса «в законе», что бы не говорили GNOME’шники (и с чем KDE’шники, как мы видим на примере NEON’а, пока не согласны), разницу можно считать пренебрежимо малой.

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

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

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

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

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

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

Так, вывод о прогрессивности любых нововведений базируется на старой жизненной максиме: всё, что ни происходит — к лучшему. Хотя из истории мы знаем, что любое новшество имеет свою оборотную сторону. Примеры чего настолько массовы и очевидны, что об этом просто смешно говорить. Тем более, что это чётко сформулировал примерно полтора века назад великий русский поэт Толстой, aka Алексей Константинович:

Много разных бывает на свете чудес.
Я не знаю, что значит какой-то прогресс.
Но до здравого русского веча
Вам ещё, государи, далече.

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

Примером «нового» — скверно испорченного старого — является третьеGNOME с его GNOME Shell’ом. Если не при первом, то при втором взгляде на который невольно приходит на память TWM — если кто помнит, был такой оконный менеджер для оконной системы X (ныне известной под партийной кличкой Xorg), 1987 года издания. Однако тут мы переходим ко второму контр-выводу.

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

Апофигей представления разработчиков отражён в интервью с Кейтом Паккардом (одним из создателей Wayland’а), напечатанном как-то в Linuxformat’е. В нём Кейт сначала долго рассказывает, какое счастье настигнет пользователя по завершении разработки Wayland’а. А затем на прямой вопрос, какое графическое окружение использует сам, ответил: TWM.

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

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

Показательный пример тому — музыка (в широком смысле). Мало кто из нас не хотел бы «в свободный часок, на полчасика» прилечь позабавиться классикой. Но тех, кто профессионально занимается компьютерной аранжировкой (или как оно там именуется?) — существенно меньше.

Тем не менее, некомьютерных сфер приложения сил человеческих много больше, чем программерство и админство. И вникать в особенности всех применители-компьютерщики не могут. Да и не должны. Ведь, как говорил у Альфреда Бестера в «Феномене исчезновения» генерал Карментер:

Своё дело для каждого — и каждый для своего дела.

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

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

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

Другой пример полезности пива может дать распространение Wayland’а. Кто знает, может быть, когда ситуация с ним устаканится — и простые люди получат от него какой-то профит. Правда, скорее всего, это будет только в светлом будущем, в отдалённой перспективе…

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

UEFI и установка MX в KDE-редакции

Вот мы наконец и добрались до того, ради чего сочинялась эта История — до установки MX Linux на машину с UEFI BIOS, причём таким, который не способен переключаться в режим BIOS Legacy. Однако прежде необходимо сказать несколько слов про UEFI вообще.>

Немного про UEFI

Как было сказано в частях 2 и 3 нашей Истории (то есть здесь и здесь), машины с UEFI получили в наши дни повальное распространение. И всё бы было ничего, пока не стали появляться сначала ноуты, а затем и системные платы, которые невозможно переключить на режим эмуляции BIOS’а. Причём такого оборудования с каждым днём становится всё больше. И в скором времени можно ожидать, что старый добрый BIOS Legacy «вымрет весь, как лошади Пржевальского».

В отличие от явлений, описанных во второй https://www.alvstory.ru/istorii-pro-mx-uefi-i-noutbuk-chast-2-tendencii-sovremennogo-linux-a/ и третьей https://www.alvstory.ru/istorii-pro-mx-uefi-i-noutbuk-chast-3-protivostoyanie-tendenciyam/ частях нашей Истории, никакие программные ухищрения в борьбе с UEFI не помогут.

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

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

Подготовка источника установки: утилита MX Live USB Maker

Устанавливается MX на UEFI-машины точно с тех же образов, что и на машину С BIOS’ом. Поскольку в наших Историях речь идёт о дистрах со средой KDE, и дело происходило в мае 2022 года, в данном случае это был, для оправдания высокого звания дистра semi-rolling, свежий файл образа MX-21.1_May_KDE.iso, который скачивался отсюда.

Теперь этот образ следовало записать на флешку. Ранее я всегда пользовался для этой цели либо утилитой dd, либо банальной командой cp. Однако, когда во время своих «альтернативных исканий» мне потребовалась запись iso-образов на флешки почти в промышленных масштабах, я опробовал графическую утилиту USB Image Writer из штатного комплекта Linux Mint. Остался доволен результатами и потому решил сейчас повторить опыт.

В штатный комплект любого варианта MX Linux входит утилита графического режима, назначение которой очевидно из её названия — MX Live USB Maker. Она входит в состав инструментария MX и запускается из соответствующего пункта главного меню:

После чего в первую очередь требует авторизации:

А по вводе соответствующего пароля открывается вот такое окно:

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

Процесс этот может продолжаться 10–15 минут (в рассматриваемом случае, при объёме образа чуть меньше двух гигабайт, он занял 11 минут 14 секунд). И завершится сообщением об окончании этого безнадёжного предприятия:

После чего окно программы можно закрывать, а флешку вынимать и использовать по назначению. То есть любоваться MX Linux’ом «живьём» или устанавливать его на ПМЖ.

Всё сказанное выше относится к дистрибутивам проектов MX и Antix. Первых, как мы помним, в данный момент существует три официальных и несколько респинов от Сообщества, а из Antix’а, собственно и растут ноги всех MX-утилит. В число коих входит и MX Live USB Maker.

Для дистрибутивов MX и Antix утилита эта позволяет создавать так называемые «дозаписываемые флешки», о чём недвусмысленно свидетельствует пункт секции Mode, который так и называется — Full-featured mode — writable LiveUSB. Сама по себе штука эта очень полезная, но подробнее о ней я расскажу в другом месте.

Пока замечу только, что на такую флешку можно записать файлы, созданные в «живой» сессии (например, скриншоты процесса инсталляции), в каталог /MX-Live-usb/Live-usb-storage/demo/. И потом прочитать их на любой машине из каталога /media/$HOME/MX-Live-usb/Live-usb-storage/demo/.

Это не значит, что утилита наша не позволяет записать произвольный iso-образ какого-либо другого дистрибутива. Ещё как может — только о writable’ности придётся забыть, для чего переключить умолчальный «полнофишечный» режим на режим read-only LiveUSB.

В этом случае наша MX-утилита будет работать просто как графическая «морда» консольной утилиты dd. Что, впрочем, тоже полезно при массовой записи установочных флешек. Особенно если вспомнить длину командной строки dd, со всеми её обязательными и (очень) желательными опциями и аргументами.

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

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

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

Всё сказанное позволяет рекомендовать данную MX-утилиту для записи более-менее любых образов. При этом совсем не обязательно иметь MX Linux установленным на машине: запись прекрасно проходит и в Live-сессии. Для чего, правда, требуется не меньше двух свободных USB-разъёмов.

Загрузка с флешки

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

А также тем, что никакого выбора загрузчика оно не предлагает — GRUB в режиме UEFI only безальтернативен. Так что и заморачиваться на этот счёт применителю не приходится. Ему достаточно в пункте Language — Keyboard — Timezone выбрать язык: lang=ru_RU:Русский — Russian:

Раскладки клавиатуры при этом сами собой установятся как kbd=us,ru, а часовой пояс, столь же нечувствительно, определится как tz=Europe/Moscow. Часовой пояс, конечно, можно, скорректировать, но в пределах от Калининграда до Якутска, да и то с пропусками. А жителям Свердловска (ныне известного как Ёбург) придётся отыскивать свой город в Азии.

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

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

Запуск инсталлятора

Загрузка проходит без всяких неожиданностей и завершается появлением рабочего стола KDE вместе с окном приветствия, о котором сейчас говорить не будем, как и настройках «живьём». Потому что наша цель сейчас — поскорее начать установку и поглядет, чем установка на UEFI-машину отличается от установки на машину с BIOS Legacy.

Как мы помним, запустить инсталлятор можно либо щелчком на пиктограммке рабочего стола, либо нажатием кнопки Install MX Linux на панели приветствия:

Кстати говоря, на панели приветствия имеется очень ценная подсказка — логин и пароль пользователя (demo:demo) и администратора (root:root).

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

Тут начинается самый охмурёж — разметка диска. И это единственное, что отличает установку MX Linux (как, впрочем, и любого другого Linux’а) на UEFI-машину, от той же процедуры, выполняемой на машине с BIOS Legacy.

Рассуждения о дисковой разметке и дисковых разделах

Здесь надо твёрдо-натвердо затвердить две вещи. Первая — что для загрузки системы в режиме UEFI only, кроме раздела под корневую файловую систему, требуется ещё и своего рода загрузочный раздельчик (так называемый ESP — EFI System Partition) с файловой системой FAT32 (обязательно!), которая будет монтироваться в каталог /boot/efi.

И вторая вещь — не забыть этот раздельчик создать в процессе установки. Или заранее, с помощью утилит типа fdisk, cfdisk или Gparted, и определить его тип как EFI System. Впрочем, как мы скоро увидим, инсталлятор MX избавит нас от лишних хлопот, позаботившись об этом. А пока продолжим общие рассуждения.

В сети часто можно встретить мнение, что режим UEFI only требует обязательно разметки в GPT-стиле. По моим наблюдениям, никакой связи между UEFI-режимом и стилем разметки нет. UEFI-машина также благополучно грузится при разметке диска в стиле msdos. Важно только, чтобы на диске имелось два раздела, оба они были бы первичными и их типы были бы: EFI System на одном и Linux filesystem на другом.

Другое дело, что GPT-разметка сама по себе надёжней, и потому на новом (или приносимом в жертву со всем содержимым) HDD или SSD лучше создавать таблицу разделов GPT — в современных версиях утилит разметки это совсем не обременительно.

О размере EFI-раздела указания также противоречивы. Обычно советуют отводить под него сотни мегабайт, и даже не первые. В дистрибутивах, инсталляторы которых предусматривают автоматическое разбиение целевого носителя, под EFI-раздел отводится 300–500 МБ. Кажется, минимальное значение, которое мне встречалось, как раз в MX, составляет 250 МБ.

В то же время, если с помощью утилиты du, например, посмотреть реально занятое на таком разделе место, обнаруживается, что оно составляет 270–300 кило-(!)байт. И даже если предположить, что применитель будет держать по несколько дистрибутивов и в каждом активно экспериментировать с разными сборками ядра (что, между нами говоря, для применителей нашего профиля не характерно), то мегабайт 10–20 должно хватить.

Должен ли EFI-раздел быть первым (скажем, /dev/sda1)? Согласно всем известным мне сетевым данным, не обязательно. Да и при автоматической разметке он оказывается первым не всегда. Тем не менее, для себя я решил создавать его в первую очередь. Не из каких-то сакральных соображений — просто так меньше шансов забыть про него вообще.

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

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

Установка: размечаем диск

Ну, кажется, с общими рассуждениями покончено окончательно. Так что переходим к банальной рутине — то есть дисковой разметке, каковой инсталлятор MX предлагает заняться первым делом. И предлагает сделать это в одном из двух режимов: автоматическом, с использованием всего целевого носителя (и уничтожением его содержимого, буде таковое имелось), или ручном (Customize the disk layout):

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

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

Дальнейшие действия некоторое время происходят без нашего участия: сразу после их одобрямса начинается создание файловых систем на целевом носителе (в том числе и EFI-раздела, sda1, объёмом 256 МБ) и развёртывания на нём дистрибутива:

Процесс этот доходит до 94% и притормаживается:

Но, не дожидаясь «тормоза» (или сразу вслед за ним) можно задавать параметры сети (имя машины и домен)

и локализации — последние, при выборе перед загрузкой «в живую» русского языка (см. скриншот 8), скорее всего, уже установлены правильно:

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

При указании имени пользователя (оно же логин) и его пароля нужно только не забывать несколько простых правил: они должны включать только наичистейшу латиницу (первые 127 символов кодовой страницы) и не содержать проблев. На длину и вид пароля не накладывается никаких ограничений «снизу». То есть пароль типа 123 вполне допустим, инсталлятор не будет злобно ругаться ни на его краткость, ни на «простоту».

Ну а аккаунт root’а необходим только тем применителям, которые чувствуют себя ущемлёнными от невозможности авторизоваться в консоли root’ом и использовать su. Во всех других случаях он не только не нужен, но и вреден. Почему — говорил много раз, и здесь повторять неуместно.

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

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

В своё время, когда я впервые писал про MX Linux, именно наследование изменений, сделанных в Live-режиме, установленной системой восхитили меня больше всего. До того времени нечто подобное я встречал только в некоторых версиях Fedora и openSUSE, однако и там, и там эти фичи пропали без следа. Вот и я за шесть лет отрыва от MX Linux’а про них забыл…

Дальше всё просто и многократно описан: установка GRUB’а, завершение установки вообще, перезагрузка. И — проверка того, что нам наразбивал на SSD автомат:

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

Автор: alv

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

Выбор

Процесс выбора

Зигзаги прогресса

Выбор альтернативного десктопа

Подбор дистрибутива

Результаты выбора

MX Linux: вопросы истории

Моя MX Story

MX Linux сегодня

Репозитории MX Linux

Установочные образы

KDE: от истории к современности

У истоков

От «тройки» до «пятёрки»

Хроника текущего момента

Итоги

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

Подготовка установочного носителя

Дорога к «жизни»

Впервые в «жизни»

Настройки в Live-режиме: зачем?

Экспресс-настройки: начали!

Про обои

Про шрифты

Про клаву

Инструменты документирования установки

Про инструменты вообще

Про KWrite: тексты документации

Про иллюстрации

Про сохранение Live-настроек

Претворение в реальность

Подготовка установочного носителя

Дорога к «жизни»

Впервые в «жизни»

Настройки в Live-режиме: зачем?

Экспресс-настройки: начали!

Про обои

Про шрифты

Про клаву

Инструменты документирования установки

Про инструменты вообще

Про KWrite: тексты документации

Про иллюстрации

Про сохранение Live-настроек

MX, UEFI и ноутбук

Подготовка установочного носителя

Дорога к «жизни»

Впервые в «жизни»

Настройки в Live-режиме: зачем?

Экспресс-настройки: начали!

Экспресс-настройки: начали!

Про обои

Про шрифты

Про клаву

Инструменты документирования установки

Про инструменты вообще

Про KWrite: тексты документации

Про иллюстрации

Про сохранение Live-настроек

Тенденции современного Linux’а

Тенденции…

…и их развитие

Про systemd

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

Длинные против квадратных

Против GRUB’а

Схемы, разделы, файловые системы

О системах инициализации

О Wayland’е

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

UEFI и установка MX в KDE-редакции

Немного про UEFI

Подготовка источника установки: утилита MX Live USB Maker

Загрузка с флешки

Запуск инсталлятора

Рассуждения о дисковой разметке и дисковых разделах

Установка: размечаем диск

Автор: alv

Добавить комментарий Отменить ответ