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

Вводные соображения

Как говорилось в прошлом Рассказе, обзавестись системой с последней версией среды Cinnamon можно — и даже несколькими способами. Правда, в данный момент требуется, чтобы система эта была Linux Mint версии 20.3 Una, которая ещё не вышла. И потому остаётся два способа. Они описаны, исходя из реалий сегодняшнего момента (06.12.2021). Однако по прошлому опыту порядок действий был тот же самый. А зная верность разработчиков Mint’а традициям, можно ожидать, что и в обозримом будущем он существенно не изменится.

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

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

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

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

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

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

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

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

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

2. По возможности под новую инсталляцию следует отводить целый диск. Противопоказанием чему может быть только единственность целевого носителя (что бывает в ноутбуках) или его небольшой объём (что характерно для Stick’ов, включающих обычно eMMC объёмом 32, много 64 ГБ). Носитель для установки следует, разумеется, выбирать или чистый, или такой, содержимым которого можно безболезненно пожертвовать

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В домашнем же каталоге /home/username, который образуется автоматически при создании пользовательского аккаунта, следует держать только конфигурационные dot-файлы и, возможно, данные для сиюминутных проектов. Именно так уже очень давно поступаем мы с котом Мануалом. И потому со всей ответственностью можем повторить слова брата незабвенного Лёни Голубкова: «Так лучше, Лёня!»

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

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

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

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

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

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

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

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

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