Интегрированная рабочая среда, иначе называемая также рабочим окружением (Desktop Environment — DE), или по русски просто десктопом — это среда обитания применителя Linux’а, в которой протекает вся его жизнедеятельность.

О десктопах

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

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

О выборе

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

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

1. функциональность, то есть способность выполнить все задачи, которые встают перед применителем в его повседневной жизни;
2. комфортность — задачи эти должны быть выполнены простым и понятным способом;
3. эстетика — среда должна быть не только фунциональной и комфортной, но и выглядеть красиво.

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

Тем более что вариантов DE для опробования на самом деле не так много (в порядке появления на свет): Xfce (1996), KDE (14 октября 1996), GMOME (15 августа 1997), MATE (19 августа 2011), Cinnamon (2 августа 2012 года), Budgie (7 декабря 2013).

Кроме того, к интегрированным средам обычно относят LXDE (2006) и LXQt (2013), хотя, строго говоря, за отсутствием собственных сквозных средств конфигурирования они таковыми не являются. К ним примыкает и Lumina, которая начала было развиваться в правильном направлении (создания собственного оконного менеджера), но распространения (пока?) не получила.

Все перечисленные в прошлом абзаце десктопы делятся на два класса, в зависимости от набора библиотек, на которых они основаны. Таких наборов в принципе существует довольно много, однако в интегрированнх средах используется один из двух: Qt (KDE, LXQt и Lumina) и Gtk (все остальные десктопы).

В зависимости от базиса среды, обычно для нее подбираются и приложения с соответствующим основанием. Хотя в общем случае это не обязательно. Нам известен минимум один удачный пример органической интеграции Gtk-приложений в среду, основанную на Qt (это дистрибутив Maui, к сожалению, прекративший своё развитие). А интеграцией Qt/KDE приложений в Gtk-среду Cinnamon регулярно занимались мы с котом Мануалом (правда, в масштабах отдельно взятого персонального компьютера).

А вообще мы с Мануалом много лет работали в KDE. Начиная ещё с до-первой её версии, что была в Linux Mandrake, который даже не назвался тогда Russian Edition (RE) — и вплоть до конца жизненного цикла третьей ветки).

Затем, когда в ветке четвёртой KDE потеряла лицо (которое до того было человеческим, а стало… не будем говорить, какой частью человеческого тела), мы отправились на поиски подходящего для нас десктопа.

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

Не миновали мы и среду Unity (03 июня 2010 года): после сплошной обсценной лексики в её адрес на всех языках, которые мы никогда не знали, заценили мы с Мануалом оригинальность заложенных в неё идей. Правда, не могли не заметить, что реализованы эти идеи были… так себе обычно были реализованы. Возможно, мы были не одиноки в своём отношении, и именно поэтому среда Unity вскоре после 14 мая 2016 года (дата релиза последней версии) приказала долго жить.

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

Так продолжалось до тех пор, пока глаз наш не упал на Cinnamon — и аккурат в то время, когда эта среда, в версии 2.0, скинула с себя оковы старого «третьегномьего» мира. И тут мы с Мануалом поняли, что

Не нужны теперь другие бабы,
Душу всю корица нам сожгла.

И на других баб (то есть, пардон, сред) нам уже даже и смотреть не хотелось.

О Cinnamon

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

Шатания…

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

И даже среда Budgie, если удавалось не уронить её в первые минуты работы, внушала надежды на то, что её болезни роста будут со временем изжиты (впрочем, надежды эти она продолжает внушать и по сей день).

… и возвращение

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

В преддверии десятилетнего юбилея среды (02.01.2012) мы с Мануалом решили ознаменовать эту дату циклом материалов, рассказывающих о наших наблюдениях и впечатлениях, её касающихся. Правда, некогда, ещё до знакомства с Мануалом, я предпринимал такую попытку в онлайновой книге Linux Mint и его Cinnamon.

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

Мифы о Cinnamon

Хотя кое-что в окружаемом нас мире остаётся неизменным. В частности, сложившиеся на заре жизненного цикла нашего десктопа мифы о нём, поныне повторяемые регулярно с упорством, заслуживающим лучшего применения.

Миф первый: Cinnamon — оболочка для среды рабочего стола GNOME, являющаяся ответвлением от кодовой базы GNOME Shell.

Миф второй: предоставление пользователю среды Cinnamon более привычной, традиционной среды в стиле GNOME 2, удобной пользователям настольных ПК и ноутбуков.

Миф третий (противоречащий второму, хотя и передаваемый подчас совместно с ним): интерфейс среды Cinnamon максимально приближен к таковому Windows.

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

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

Пусть кто-нибудь попробует найти здесь хоть что-то общее с интерфейсом GNOME 2, за исключением факта наличия рабочего стола, главной управляющей панели и кнопок запуска приложений на ней. А в каком из десктопов нет этих элементов?

Тут же кроется опровержение и мифа третьего, о Windows-подобии интерфейса Cinnamon. Да, в последней есть и рабочий стол, и главная управляющая панель, и даже аналог пресловутой кнопки Пуск. Но смысл этих элементов интерфейса в Cinnamon, как будет показано со временем, совершенно иной.

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

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

Ранее было немного рассказано о рабочих средах вообще и о том, как мы с Мануалом из них всех выбрали именно Cinnamon. Что, собственно, и создало общий сюжет этих историй. А ответом на вопрос, почему мы это сделали, будут дальнейшие страницы её вводной части.

Модель разработки

Модель разработки среды Cinnamon сильно отличается от таковой прочих десктопов. Она оказывается противоположно направленной по сравнению с ними. Среды KDE, Xfce, GNOME, а позднее LXDE, LXQt и MATE, создавались командами разработчиков, более или менее независимыми от майнтайнеров отдельных дистрибутивов, и лишь потом начинали использоваться последними в своих сборках.

Среда Cinnamon с первых дней своего существования выглядела «привязанной» к прародительскому Mint’у. Почти так же, как это некогда имело место для Ubuntu и Unity — или, по крайней мере, как это воспринималось для последней пары так называемой общественностью.

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

Немного о дистрибутиве Mint

Дистрибутив Mint был создан в 2006 году Клементом Лефевром (Clement Lefebvre), который поставил своей целью создание идеального десктопа «для народа» — домашних пользователей и малого бизнеса. Он представлял собой дериват Ubuntu. То есть Mint в базовой своей части, вплоть до Xorg, был основан на пакетной базе Ubuntu, и все соответствующие пакеты брались из её репозиториев без всяких изменений. Однако изначально он имел и собственный репозиторий, содержащий дистрибутив-специфические компоненты.

Первоначально релизы дистрибутива Mint выходили довольно часто, но нерегулярно, с интервалом от полутора-двух до пяти-шести месяцев, с тенденцией к полугодовому циклу. Полугодовой релиз-цикл прочно устаканился, начиная с Linux Mint 13 Maya, как раз одновременно с включением в него среды Cinnamon.

В сентябре 2010 года было объявлено о выходе другого дистрибутива проекта Mint — Linux Mint Debian Edition (LMDE). Как можно догадаться по его имени, он был основан на пакетной базе не Ubuntu, а Debian. В качестве таковой выступала ветка testing последнего, и потому релиз-цикла у LMDE нет — его «плавающие» версии маркировались годом и месяцем. Впрочем, в наших историях речи о LMDE не будет. Так что вернёмся к Linux Mint.

Предыстория…

Предыстория наших историй уходит в глубокую древность до 2011 года, когда в качестве рабочего окружения в Mint использовался GNOME текущей версии — той же, что в базовой Ubuntu, в которой GNOME 2 тогда был в десктопом по умолчанию. Однако в Mint GNOME 2 был не единственным: почти со дня основания дистрибутива существовала и его KDE-редакция (апрель 2005 года), позднее к ней присоединились редакции с рабочими средами Xfce (июнь 2006 года) и LXDE (октябрь 2008 года). На протяжении 2008-2010 годов существовал даже вариант с оконным менеджером Fluxbox.

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

И иногда пропадали с горизонта вообще, как случилось с редакцией Fluxbox: она просуществовала в релизах helena, isadora, julia и katya, после чего исчезла без следа. Буквально — образов её сейчас нам не удалось найти ни на одном зеркале проекта Mint.

Надо сказать, что это оказалась не последняя, и уж точно не самая крупная потеря проекта Linux Mint. В декабре 2017 года было суждено выйти последней KDE-редакции этого дистрибутива, 18.3 Sylvia. Что Клем объяснял сложностью поддержки Qt based системы, идеологически сильно отличной от остальных редакций проекта, основанных на библиотеках Gtk.

Но в 2010–2012 года, с одной стороны, Ubuntu переходит на собственный десктоп Unity. С другой же — появляется релиз GNOME 3 с оболочкой GNOME Shell. Хотя GNOME 3 не стал тогда официальным десктопом Ubuntu — эта роль досталась собственной среде Unity, однако редакция Ubuntu GNOME заняла своё место в ряду перечисленных выше прямых клонов Ubuntu. А поддержка GNOME 2 разработчиками этого десктопа официально прекращается.

По ряду причин и сам Ubuntu GNOME, и GNOME Shell (не говоря уже об среде Unity) оказались для разработчиков Mint неприемлемыми. То есть они остались без собственного привычного десктопа, каковым до сих пор был GNOME 2. Поддержка которого в рамках проекта GNOME была прекращена. А ведь майнтайнеры Mint немало сил вложили в причёсывание GNOME 2, который стал похожим на нормальную среду в том числе и благодаря им.

Правда, летом 2011 года некто Perberos, пользователь Atchlinix’а, начал проект MATE, в котором продолжалось развитие идей традиционного рабочего стола «второгонома». И этот проект был поддержан представителями сообщества, которые не выражали восторга от новомодного «третьегнома».

В числе пользователей с образом мыслей, не восторженном в отношении GNOME 3, был и Клемент Лефевр со своими товарищами — создателями Linux Mint. И поэтому нет ничего странного, что в свой дистрибутив они включили среду MATE — одними из первых среди всех дистроителей: проект Ubuntu MATE был образован много позже.

А в промежутке времени между созданием Linux Mint MATE Edition и официальным клоном Ubuntu с десктопом MATE наша соотечественница Татьяна Иванова aka Vita замутила проект под именем Matuntu, на базе Ubuntu и десктопа MATE (июнь 2013 года). И с тех пор вот уже более восьми лет поддерживает его чуть ли не в одиночку. Разве что с помощью сочувствующих лиц. Среди которых надо назвать Игоря Мартынова aka ivm и Тенгиза Кучава aka Tengior (увы, 24 марта 2018 года его позвали верхние люди, но мы-то помним).

Повторяю, проект Matuntu начал реально развиваться тогда, когда об официальном Ubuntu MATE (вышедшем, согласно Distrowarch’у, 24 марта 2015 года) дело дальше разговоров ещё не двигалось.

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

Ну а в рамках проекта Linux Mint, кроме MATE Edition, происходила разработка новой оболочки для GNOME 3, которая в декабре 2011 года была анонсирована под именем Cinnamon. Как это было — описано в следующем разделе нашего Рассказа.

… и история

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

Далее развитие проекта происходило со страшной научно-фантастической силой: 23 января следующего года появляется релиз 1.3, в середине марта — 1.4, а затем, в сентябре — релиз 1.6. После чего устанавливается полугодовой релиз-цикл — релиз 1.8 выходит в свет 5 мая 2013 года, после серии релизов корректирующих. В октябре того же года появляется релиз 2.0, в апреле 2014 года — релиз 2.2.

Все релизы среды опережали версии Mint, для которых они предназначались, примерно на месяц-полтора. Эта фора отводилась для дополнительного тестирования среды силами энтузиастов и притирки её к целевому дистрибутиву. Что, как показала практика, давало весьма положительный результат. Так, версии Cinnamon 2.2 и 2.4 в релизы Mint 17 и 17.1, соответственно, были включены в существенно доработанном виде по сравнению с первоначально представленными сборками.

Смена версий Cinnamon отражает специфичность его судьбы. Что же происходило при этом? В предыдущем рассказе упоминалось, что история этого десктопа началась с появлением GNOME 3. Говорить о кипении страстей, связанных с этим событием, здесь не уместно. Достаточно сказать, что для многих применителей ряда дистрибутивов, включавших GNOME 2 в качестве штатного десктопа, его «осовремененная» версия, в частности, «очень прогрессивная» оболочка GNOME Shell» не вызывала ничего, кроме отвращения

Дистрибутив Mint с момента своего создания был связан с десктопом GNOME нерушимыми, казалось бы, узами. Но эта нерушимость касалась GNOME 2. А вот GNOME 3, особенно в своём первозданном виде, в концепцию развития дистрибутива не вписывался никаким боком. Попытки сохранить «второгном», но его основа, библиотеки Gtk 2, перестала поддерживаться разработчиками, и потому они успеха не имели. Ситуация требовала кардинального решения. И их нашлось целых два.

Первое решение носило косметический характер. Это был набор MGSE (Mint GNOME Shell Extensions), объединяющий дополнения к GNOME Shell, которые могли обеспечить не только традиционный интерфейс GNOME 2, но и восполнить недостающий функционал GNOME 3, а он поначалу был до крайности убог (впрочем, и сейчас выглядит не намного лучше). Обе задачи достигались за счёт внешних модулей, таких, как панель Bottompanel, система переключения между окнами Windowlist и меню приложений Menu. Результатом стал выход в ноябре 2011 года релиза Mint 12 Lisa, включавшего в качестве десктопа по умолчанию GNOME 3 с MGSE.

Однако, видимо, майнтайнерам Mint изначально было ясно, что MGSE — не более, чем паллиатив, и потому, с одной стороны, включили в свой дистрибутив альтернативный десктоп — MATE (первыми среди майнтайнеров распространённых дистрибутивов). А с другой стороны, можно догадаться, что где-то за кадром Клемент Лефевр (Clement Lefebvre), основатель и основной майнтайнер дистрибутива, вместе с соратниками уже ковал основу совершенно новой оболочки для GNOME 3. Которая стала доступной буквально через месяц после выхода Mint 12 Lisa и вместе с «третьегномовским базисом» получила имя среды Cinnamon.

Основную часть базиса среды Cinnamon составил оконный менеджер Muffin — форк штатного «управителя окон» Mutter из GNOME 3. Главное отличие новой оболочки от связки GNOME 3 и MGSE состояло в том, что функционал внешних расширений последнего был включён непосредственно в её состав. Это предоставило средства управления взаимодействием между дополнительными функциями и определения порядка их загрузки. В результате были реализованы добавление пиктограмм в область уведомлений, система уведомлений в стиле GNOME 2, возможность изменения позиции панели и её автоматического скрытия.

После серии основных и корректирующих релизов, стремительным домкратом следующих друг за другом, Cinnamon 1.4 UP1, появившийся 14 мая 2012 года, был включён в качестве штатного десктопа в Mint 13 Maya, анонсированный десять дней спустя. С тех пор выход его версий и стал привязан к релиз-циклу этого дистрибутива.

Всё это время Cinnamon представлял собой просто оболочку к GNOME 3, надстраивающую «форкнутый» менеджер окон и замещающую собой его штатный GNOME Shell. Он включал все базовые приложения GNOME 3 в неизменном виде, такие как терминал, файловый менеджер, текстовый редактор.

Однако во время подготовки релиза GNOME 3.6, в котором предполагалось существенное ограничение функционала и настраиваемости файлового менеджера Nautilus, разработчики Cinnamon начали работы над форком его версии 3.4, назвав её Nemo. Этот самый Nemo и попал в релиз Mint 14 Nadia, хотя сначала в качестве альтернативного. Но уже в версии Cinnamon 1.8.X он был интегрирован с рабочей средой. Кроме того, в этой версии отказались от Центра управления GNOME 3 ввиду его убожества. Он был заменён настроечным комплексом System Setting (по русски — Параметры системы), который позволял выполнить полное конфигурирование среды, не обращаясь к внешним полулевым (а то и откровенно левым) твикам.

Версии Cinnamon 1.8 суждено было стать последним «чистым» форком GNOME 3 — в это же время полным ходом шла подготовка релиза 2.0. Суть этой подготовки заключалась в полной замене базовых компонентов GNOME 3 собственными аналогами. То есть — в создании полностью обособленного окружения, не пересекающегося с GNOME 3 и не связанного с ним внешними зависимостями. В результате чего Cinnamon из оболочки для GNOME, вроде GNOME Shell и Unity, превращался в полноценное рабочее окружение. Итог этой деятельности был вынесен на суд общественности 10 октября 2013 года, в виде релиза 2.0.

Особенности современных версий

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

Первая — в Cinnamon гармонично сочетаются старые добрые элементы управления, такие, как главное меню в стиле кнопки Пуск (сами знаете откуда), и элементы модерна, столь привлекающие в Unity. Такие, как строка инкрементного поиска, подобная Dash — но без излишеств последнего, то есть без средств поиска в Интернете всякого рода «парнухи».

Вторая особенность — достигнутая в Cinnamon гармония между простотой конфигурирования и богатством его возможностей. Если настройки в KDE, при их изобилии, приобретают всё более необозримый вид, а в GNOME 3, напротив разубоживаются до полного неприличия, в нашем десктопе они почти столь же просты, как в Xfce, и почти столь же изобильны, как в KDE. И, в отличие от Unity, выполняются исключительно штатными средствами, а не бесчисленными сторонними твиками.

Третья особенность — аскетизм Cinnamon в отношении штатных приложений. В существующем виде к таковым можно отнести только файловый менеджер Nemo. Прочие приложения, обычно представленные в сборках Cinnamopn, такие, как терминал, текстовый редактор, программы для просмотра изображений и документов, а также аудио- и видеоприложения, не специфичны для этой среды и обычно заимствуются из проекта GNOME, хотя легко заменяемы. Например, компонентами кросс-десктопного набора X-Apps, также pазвиваемого в рамках проекта Mint

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

Четвёртая особенность среды Cinnamon — весь её традиционализм покоится на весьма современном базисе в виде библиотек Gtk 3, что должно обеспечить спокойное развитие этого десктопа в обозримом будущем. А после релиза в конце 2020 года GTK 4-й ветки начался постепенный, без всякого ажиотажа, переход компонентов среды на этот фреймворк.

При этом сохраняется и совместимость с приложениями не только на основе Gtk 3, но и Gtk 2, до сих пор широко распространёнными и не всегда имеющими адекватные аналоги.

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

Распространение и поддержка

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

Можно предполагать, что майнтайнеры большинства дистрибутивов отнеслись к Cinnamon настороженно — и пока не изменили своего отношения. В результате на сегоднящний день (05 декабря 2021) Cinnamon используется в 29 активно развиваемых дистрибутивах. Для сравнения: KDE используется в 82 дистрибутивах, GNOME — в 72, MATE — 53, Xfce — в 92. Хотя есть и десктопы, отстающие по использованию, например, Budgie (11 дистрибутивов), и братско-китайский Deepen (вообще 4 дистра).

Ну да ладно, майнтайнеры, игнорирующие Cinnamon — сами себе Злобные Буратины. Хуже то, что в дистрибутивах, вроде бы Cinnamon поддерживающих, поддержка эта не всегда на должной высоте. А под должной высотой поддержки этого десктопа (как, впрочем, и любого другого) следует понимать, во-первых установку его со специального инсталляционного носителя или возможность выбора нужного нам десктопа в процессе инсталляции, а не доустановку его из репозиториев после завершения оной. А во-вторых, версия этой среды должна соответствовать апстриму из репозитория проекта — для проекта Cinnamon таковой имеет место быть на GitHub’е.

По части поддержки среды Cinnamon первое место уверенно держит Linux Mint (вот неожиданно, верно?). При первичной инсталляции он может быть установлен со штатного ISO-носителя — образ так и называется: Linux Mint Cinnamon Edition (кроме него в рамках проекта доступны образы редакций с десктопами MATE и Xfce).

Эти образы по определению включают в себя последнюю версию среды Cinnamon, которая предназначена для очередного релиза Linux Mint CE, но становится доступной в репозитории примерно за месяц–два до его выхода. Так, в данный исторический момент версия Cinnamon 5.2 появилась в репозитории 18 ноября 2021, а релиз дистра грядущего 20.3 Una предполагался в начале декабря. А в реальности произошёл 7 января 2022 года.

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

А пока заметим, что в сборках среды Cinnamon почти всех прочих дистрибутивов обязательно чего-то не хватает. Перво-наперво, не хватает номеров версий. Если в Linux Mint CE мы тем или иным способом получаем 5.2 Una, то в таких записных rolling-системах, как Arch и его клоны (довольно многочисленные), нашего десктопа выше 5.0.7 мы до сих пор (14 января 2022) нигде не увидим. И даже в традиционнно самом «крутоскользящем» дистрибутиве — в Voidlinux’е, среда Cinnamon уже надолго было застыла на версии 4.8.6. Пока, наконец, рывком не поднялась до текущей 5.2.7.

В дистрибутивах, развивающихся по модели fixed release, ситуация с версиями Cinnamon ещё печальные. Так, в официальном репозитории Ubuntu версия среды — 4.8.6 в современных релизах, таких, как hirsute (21.04), impish (21.10) и в грядущем jammy, в прочих же ещё ниже.

Некогда многочисленные PPA-репозитории пакетов для среды Cinnamon, майентайнеры которых (le Bihan, embrosyn, gogo) шли в ногу с прогрессом, забросили это дело уже давно, на стадиях релизов Bionic, Disco и Focal, соответственно.

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

Зато такой установочный образ имеется для ремикса Ubuntu с именем Cinnamon в титулатуре (Ubuntu Cinnamon Remix — UCR). Развиваясь с 2019 года, первое время UCR оправдывал свой титул, справно включая последнюю версию среды в очередной релиз. По сети ходили слухи, что UCR станет официальным дериватом Ubuntu, подобно Ubuntu MATE и Ubuntu Budgie.

Однако официального статуса UCR так и не приобрёл, а сборки пакетов для среды Cinnamon (при-?)остановились на версии 4.8.6, уж не знаю, что тут было первично, а что вторично.

Как ни странно, довольно свежие версии нашего десктопа обнаруживаются в openSUSE, как Tumbleweed, так и Leap 15.3 — в обоих случаях это оказывается 5.0.5. Прочие же дистрибутивы, вроде как поддерживающие Cinnamon, с точки зрения качества этой поддержки восхищения не вызывают. А при взгляде на номера версий нашей среды в Debian’е просто прошибает скупая мужская слеза.

Лучом света в этом тёмном царстве выглядит Altlinux P10. Среди его стартовых наборов имеется и образ со средой Cinnamon, первый выпуск которого состоялся 12 сентября 2021 года. В нём, естественно, ни малейшей среды версии 5.2 не было. Однако StartedKit’ы Altlinux’а выходят ежеквартально. И по опыту прошлых лет можно ожидать, что в грядущем стартовом наборе будет уже актуальный Cinnamon, то есть 5.2.

Так что до недавнего времени гарантированно наслаждаться красотой актуальной версии среды Cinnamon можно было только в дистрибутиве Linux Mint, да и то, затратив для этого некоторые усилия. Однако ныне мы сможем выбирать между тремя дистрибутивами с полноценной поддержкой лучшего (по нашему с Мануалом мнению) десктопа всех времён и народов — Linux Mint, Altlinux P10 StartedKit, Voidlinux. Однако далее в этой части речь пойдёт только о первом варианте этого списка. К остальным двум мы надеемся вернуться со временем.

Linux Mint и Cinnamon

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

Способы Обретения

Как говорилось в прошлом рассказе, обзавестись системой с последней версией среды Cinnamon можно — и даже двумя способами. Первый способ в данный момент требует, чтобы система эта была Linux Mint версии 20.3 Una, которая только что вышла. И в любом случае он требует некоторого ожидания — очередная версия среды выходит минимум за месяц до следующего релиза дистрибутива; в случае с Cinnamon 5.2 и Mint 20.3 их разделили почти два месяца.

Однако долготерпение не входит в число многочисленных достоинств применителей Linux’а. И потому им остаётся второй способ. Как говорил наш начальник партии во времена моей беспокойной юности, чтобы сварить суп из курицы, надо иметь… нет, не курицу, а как минимум кошку.

Применительно к нашему случаю, можно сказать: чтобы установить Linux Mint с последней версией среды Cinnamon, надо как минимум иметь установочный образ Linux Mint CE предпоследнего релиза (или инсталляцию его на носителе целевой машины). Вполне возможно, что подойдёт и более старый релиз, но мы с Мануалом этого не пробовали, так как по возможности держим систему в актуальном состоянии.

Если машины с установленной Cinnamon-редакцией Mint’а не имеется, то её надо установить штатными средствами инсталлятора. Здесь уместно напомнить, что этот инсталлятор, один и тот же для всех дериватов Ubuntu, называется Ubiquity, он верой и правдой служит применителям дистрибутивов этого семейства, начиная Ubuntu 6.06 LTS Dapper, когда он был последним словом науки и техники. Хотя ныне он и выглядит уже несколько архаичным, однако каким будет установщик для релизов серии 22.04 — увидим, когда (и если) доживём

Процесс установки Mint’а описывался бессчётное количество раз, в том числе и автором этих строк. Так что не будем повторять написанное, например, здесь. А остановимся только на отдельных моментах процесса установки, которые некогда представлялись очень важными, но нынче уже таковыми не кажутся. В том числе и потому, что в современных машинах в качестве системного носителя чаще используется SSD, а не HDD.

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

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

1. Установку надо проводить в режиме UEFI, если это возможно. Читатель, знакомый с нашими предыдущими сочинениями, возможно, заметит здесь противоречие с прежними рекомендациями. На что мы, как истинные пофигисты, ответим, что противоречия эти нам пофигу. Тем более, что выбора нынче часто и нет: всё чаще встречаются ноутбуки, не позволяющие переключения UEFI в режим эмуляции старого BIOS’а (который часто называют BIOS Legacy).

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

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

И потому лучше заранее отвыкать от старого, доброго BIOS Legacy и понемногу привыкать к новому, пусть не очень доброму UEFI. Как известно, новое обычно является хорошо испорченным старым. Но чем чёрт не шутит: может, по мере привыкания «чистый» UEFI покажется не таким уж недобрым? А пока Legacy есть — от режима «чистого» UEFI, возможно, придётся отказаться ради совместимости с системой (системами?), уже ранее установленными на целевой машине в режиме BIOS Legacy.

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

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

В этом случае в режиме UEFI автоматически будет создан необходимый для его работы раздел с файловой системой FAT32 объёма заведомо более чем достаточного (около полугигабайта). После инсталляции он сам собой будет смонтирован в файловую иерархию как /boot/efi. А всё остальное дисковое пространство составит корневой раздел с файловой системой Ext4:

О дробном разбиении целевого носителя на разделы типа /home, /usr и тому подобных (чему мы с Мануалом раньше уделяли много внимания), нынче можно забыть. Да оно и не нужно: в эпоху SSD резоны, существовавшие во времена HDD, типа минимизации перемещения головок при считывания содержимого винчестера, силу потеряли. Покажите мне в современном SSD что-то, хоть отдалённо похожее на головки, сектора, группы цилиндров: всё это существует только в контроллерах твердотельных накопителей ради совместимости с дисковыми утилитами хотя и прошлого, но пока не заменёнными.

Также не имеет смысла возможность выбора файловой системы. Все ныне существующие их разновидности создавались во времена, когда о массовом использовании SSD не было и речи. А потому ни одна файловая система на эти накопители специально не рассчитана. Впрочем, то, на что было рассчитано большинство файловых систем, «родных» для Linux’а во время их создания, давно уже не актуально, и не только из=за повсеместного распространения SSD.

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

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

Файловая система ReiserFS имеет немало достоинств, в частности, эффективность работы с большим количеством маленьких файлов (в том числе и очень маленьких — таких, у которых все данные способны поместиться в область метаданных). Недостатки у неё тоже имеются, но о них просто смешно говорить на фоне недостатка главного: развитие этой ФС остановилось после ареста Ханса Рейзера в октябре 2006 года, и, скорее всего, не будет продолжено никогда. То же самое относится и к файловой системе Reiser4, которая даже не дожила до включения в ядро Linux’а.

Одно время на место Главной Linux’овой файловой системы активно прочили BTRFS, которая являет собой не только файловую систему, но и систем управления томами, то есть интегрированную систему размещения данных. Однако таковой она так и не стала. А после того, как BTRFS перешла в собственность Oracleн, а создатель (Крис Мейсон), на неё забил: впечатлений такое, что развитие BTRS если и не прекратилось, то сильно притормозилось.

К JFS для Linux’а, кажется, давно всерьёз никто не относится, хотя её версия для OS/2 некогда работала весьма справно. И для AIX, по слухам, тоже.

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

Останавливаться на достоинствах ZFS не буду — это было сделано ранее. И если лениво читать это многобуквие лениво — можете поверить нам с Мануалом на слово.

Недостаток же у ZFS только один, зато неисправимый: она никогда не станет полностью нативной файловой системой для Linux’а, так как её поддержка не может быть включена в ядро (в отличие от всех вышеупомянутых). И причины в том не технические, а сугубо бюрократические. Однако преодолеть их невозможно. А без этого применителя этой гремучей сцепки могут ожидать серьёзные сложности при обновления системы.

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

Все перечисленные выше файловые системы доступны на стадии инсталляции — достаточно на предыдущем скриншоте вместо автоматики выбрать пункт Другой вариант:

Если мы имеем дело с «чистым» (например, свежекупленным) диском, то увидим такую картину:

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

По умолчанию диск размечается в стиле msdos, то есть на нём можно создать до четырёх разделов (чего для нас более чем достаточно). Однако нынче при использовании UIFI-режима настоятельно рекомендуется также и схема разметки в GPT-стиле. Обрести её можно с помощью утилиты GParted. Только её следует запустить до начала инсталляции (из секции Administratios главного меню), выбрать в её меню пункт Device и затем — Create Partition Table:

В выпадающем меню появившейся панели заменить msdos на gpt:

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

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

Вне зависимости от стиля разметки диска, можно приступать к созданию разделов. И первым следует создать служебный раздельчик EFI. Отводимые для него в автоматическом режиме полгигабайта — явное излишество, которое можно безбоязненно урезать мегабайт до 100:

Реально сразу после установки на этом разделе будет занято меньше 6 МБ, так что можно рискнуть и отвести под него мегабайт 10–20 (меньше десяти по закону не положено, то есть современные дисковые утилиты, кажется, разделы меньше десяти мегабайт создавать не способны). Но лучше не рисковать, выжимая каждый байтик — чёрт его знает, как жизнь повернётся при частых обновлениях.

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

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

Теперь определяемся с файловыми системами для корневого и, возможно, «датского» разделов — для ЕFI-раздела нас, как при шести пиках, не спрашивают, а обязывают к FAT32. Для остальных же сначала резонно потребовать огласить весь список (то есть проглядеть его):

Если наши соображения о дисковой разметке
показались читателю убедительными, он с негодованием отметёт таких кандидатов на использование, как XFS, BTRFS и JFS, а Ext2 и Ext3 — просто как устарелые, употреблять которые нынче резонов нет. В результате у нас остаётся только Ext4, каковая исходно была и умолчальным выбором, и не только в этом дистрибутиве.

Ранее о её достоинствах и недостатках не было сказано ни слова. Но для корня файловой иерархии это оптимальный выбор по ряду причин.

Во-первых, Ext4 — это результат эволюционного развития Ext2 и Ext3. За время их жизни (как и её собственной), она устаканилась в своих особенностях, недостатки сами собой скончались естественным образом, как болезни роста, а достоинства окрепли и возмужали. В результате за Ext4 прочно (и обоснованно) закрепилась слава самой надёжной из Linux’овых файловых систем.

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

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

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

Наконец, в-пятых, будучи смортированной должным образом, без журналирования, Ext4 отобрала переходящий приз по быстродействию у своей предтечи, Ext2, который последняя удерживала почти четверть века. При этом не надо думать, что с отказом от журнала Ext4 просто превращается в Ext2: «родные» ограничения последней на размер файла, их количество etc. никуда не девались. Как и их практическое отсутствие для Ext4. Впрочем, быстродействие файловых операций — чуть ли не последняя вещь, на которую следует обращать внимание на SSD. Но какой же русский не любит быстрой езды?

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

Актуализация

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

Поэтому после завершения установки версии 20.2 перезагружаем машину и видим перед собой окно приветствия (так называемое Welcome). В современных версиях Mint (и, естественно, Cinnamon) это штука весьма полезная — она напоминает о настройках, которые необходимо сделать, и в каком именно порядке:

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

Нет, конечно, мы с Мануалом некоторые настройки всё-таки выполняем по разным причинам. Однако они настолько индивидуальны, что скажу о них как-нибудь отдельно, дабы не отвлекать читателя от первоочередной сейчас задачи Советской Власти — обретения актуальной версии среды Cinnamon. Для чего надо обратиться к репозиторию проекта. Впрочем, сделать это придётся только придётся только один раз — дабы убедиться, что все пакеты, относящиеся к среде Cinnamonн, имеют нужную нам версию (5.2.X):

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

Однако настоящие истории расчитаны в том числе и на применителей, желающих заодно ознакомиться с дистрибутив-специфическим инструментарием Mint’а, который обеспечивает системное единство этого дистрибутива. А одним из компонентов этого инструментария является phyton-сценарий по управлению пакетами, который сочинил Клемент Лефевр в 2008 году, тогда же назвав его apt‘ом. Имея на то полное право: обычного apt‘а тогда ещё и в проекте не было — его анонс представлен публике 1 апреля 2014 года.

Раз уж речь зашла о двух apt‘ах, есть простой способ различить утилиту apt от Mint-сценария apt: первый располагается в каталоге /usr/bin/, тогда как второй в /usr/local/bin/, о чём нам скажет команда which:

$ which apt
/usr/local/bin/apt

Утилита apt в Mint’е также имеется, как и во всех deb-based системах. И вывод команды which объясняет, почему никакой путаницы промеж двумя одноимёнными командами не происходит. Переменная $PATH определяется в файле /etc/environment так, что исполнение файлов из каталога /usr/local/bin/ имеет приоритет перед файлами из /usr/bin/:

PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin: ..."

Сценарий apt не имеет собственной man-страницы — команда

$ man apt

вызовет man-страницу для одноимённой утилиты. Может быть, поэтому многие пользователи Mint’а и не подозревают, с каким именно apt‘ом они имеют дело? Хотя между ними есть ещё одно явное различие: сценарий apt не нуждается в предварении командой sudo: запрос пароля для получения привилегий администратора будет сделан автоматически перед исполнением сценария, и только для тех случаев, когда они реально нужны.

Не смотря на отсутствие man-страницы, получение краткой справки по использованию сценария apt возможно, если дать его имя в командной строке в «голом» виде:

$ apt
apt
Usage: apt command [options]
       apt help command [options]

Commands:
  add-repository   - Add entries to apt sources.list
  autoclean        - Erase old downloaded archive files
  autopurge        - Remove packages with their configuration \ files and automatically remove all unused packages
...
  update           - Download lists of new/upgradable packages
  upgrade          - Perform a safe upgrade
  version          - Show the installed version of a package

И наконец, Обретение

Чего только ни придумают, чтобы в колхоз не ехать… Но теперь никаких подготовительных отговорок не осталось, так что приступаем к Обретению.

Первый шаг на этом пути — обновление, на всякий пожарный случай, установленной системы (то есть Linux Mint 20.2 Uma) до актуального состояния, хотя у нас оно актуально всегда — кот Мануал следит за этим строго. Итак, сначала обновление локального кеша пакетов:

$ apt update

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

$ apt upgrade

Шаг второй — в текстовом редакторе (например, в nano или Xed) от лица администратора открываем файл описания официального репозитория установленного у нас дистрибутива Uma:

$ sudo xed /etc/apt/sources.list.d/official-package-repositories.list

Шаг третий — находим в этом файле такую строку:

deb http://packages.linuxmint.com uma main upstream import backport

Причём далеко ходить не надо — она идёт там сразу после строки начального комментария:

# Do not edit this file manually, use Software Sources instead

Так что просто заменяем в ней кодовое имя обновляемого релиза (uma) на кодовое имя релиза-обновителя (una). Затем сохраняем файл и выходим из редактора.

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

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

$ apt update

А по завершении этого процесса для порядка даём команду

$ apt policy cinnamon

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

	Установлен: 5.0.7+uma
	Кандидат:   5.2.0+una

Остаётся последний шаг, пятый — тотальное обновление системы:

$ sudo apt dist-upgrade

В отличие от просто upgrade, субкоманда dist-upgrade не только обновляет все наличные пакеты, в таковом нуждающиеся, но также доустанавливает новые, появившиеся только в этой версии, и удаляет те, которые из неё исчезли. То есть она является аналогом субкоманды full-upgrade из обычного apt‘а.

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

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