Содержание
Мир открытого софта непредсказуем, особенно если этот софт ещё и свободен (то есть является 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.