«Погружение в Salix»

Погружение в Salix (fb2) - Погружение в Salix 19962K скачать: (fb2) - (epub) - (mobi) - Алексей Викторович Федорчук (alv)

Погружение в Salix

Быстрое вхождение

Алексей Федорчук aka Alv

Эта электронная книжка, aka e-book, посвящена дистрибутиву Salix – одному из «клонов» Slackware. Он интересен и сам по себе. Но также и тем, что среди всех потомков старейшего из выживших дистрибутивов он в наибольшей степени наследует особенности родительской системы. И потому знакомство с ним может рассматриваться (в том числе и) как самый быстрый и простой метод вхождения в мир Slackware. Ибо фраза «Если ты знаешь Slackware – ты знаешь Linux» до сих пор не потеряла своей актуальности.

Настоящая книжка не является руководством по Salix, Slackware или, тем более, по Linux'у вообще. Нет, это описание дистрибутив-специфических особенностей Salix'а – тех, которые показались мне интересными, и которые я задействовал в своей практической работе.

Основу книжки составили заметки о Salix на Блогосайте и цикл статей, размещённых на IBM developerWorks (содержание его здесь). Ныне они исправлены, дополнены и причёсаны, так что полного совпадения с материалами, ранее размещёнными на указанных ресурсах, нет.

Непосредственным стимулом к оформлению всех изложенных материалов послужило желание моего сына Виктора погрузиться в Salix самому и приобщить к нему сестру Ольгу. Так что им эта e-book'а и посвящается.

Глава 1. Общая характеристика, назначение, история

В первой главе даётся общий обзор дистрибутива Salix и его история, а также содержится краткое терминологическое введение. Кроме того, авто попытается объяснить, объяснение того, почему в первой фразе аннотации применительно к Salix'у нему применены кавычки.

Введение

Salix, первоначально носивший имя Salix OS (официальный сайт проекта) представляет собой один из дистрибутивов Linux, основанных на Slackware, старейшей из ныне живущих Linux-систем. От прародительницы он унаследовал простоту устройства и здоровый консерватизм, привнеся, однако, некоторые черты, свойственные так называемым «дружелюбным» (user friendly) дистрибутивам. Впрочем, как читатель увидит в дальнейшем, его «дружелюбие» никогда не становится навязчивым.

Salix относительно молод – первый его релиз, за номером 13.0, был представлен в сентябре 2009 года. И не сказать, что с тех пор он ослеплял фейерверком версий и обновлений: за четыре с половиной года он сменил лишь пять «мажорных» релизов, из которых текущим на момент сочинения этих строк является 14.1. Однако они отражают, во-первых, все важные изменения в родительской Slackware, от которой наследуют нумерацию версий. А во-вторых и главных – в них воплощаются все значимые события, происходящие в мире Linux, такие, как появление принципиально новых функций в ядре системы, существенные изменения используемых рабочих сред, выход обновления основных приложений.

Целью разработчиков Salix было создание компактного, лёгкого, но полнофункционального дистрибутива, полностью совместимого со Slackware. При этом они основывались на собственной интерпретации знаменитого принципа KISS, расшифровывая эту аббревиатуру как Keep It Super Simple, то есть Сделать проще некуда. Чего и достигли путём реализации трёх требований:

   1. простота разработки достигалась происхождением Salix от самого прозрачно устроенного из существующих дистрибутивов Linux, то есть Slackware, которая может быть индивидуализирована в очень широких пределах;

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

   3. простота использования Salix относительна: Slackware предоставляет пользователю полный контроль над системой, ничего не делая за него, но требуя понимания сути действий; для желающих иметь систему, которая «просто работает» Salix выступает как связующее звено, предоставляя полностью локализованные системные инструменты, управление зависимостями пакетов и их репозиторий; в то же время цели сделать полностью упрощённый и автоматизированный дистрибутив по примеру Ubuntu не ставилась.

Упрощению использования Salix служит в первую очередь его система инсталляции. Каждый, кто имел дело с установкой Slackware, знает, что, хотя сам по себе инсталлятор её предельно прост в употреблении, он предусматривает только два его варианта:

   1. устанавливать «гуртом» предопределённые наборы пакетов (так называемые sets или series) – но в этом случае в системе оказывается много лишнего;

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

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

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

Разумеется, не обошлось здесь и без того, чтобы «поступиться принципами»: в штатном комплекте Salix имелись OpenOffice.org и Firefox, функциональных аналогов которым среди «лёгких» приложений просто нет. Кстати, браузер – единственная программа, представленная в штатной установке «в двух лицах», вторым из которых выступает «лёгкий» Midori. Однако для всех, связанных с Интернет-технологиями (а кто нынче с ними не связан?) наличие в системе более чем одного браузера – не роскошь, а необходимость. Так что это «отступление от канона» можно не засчитывать.

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

Из сказанного выше становится ясно, что разработчики Salix ориентировали свой дистрибутив на совершенно определённую группу пользователей – с одной стороны достаточно подготовленных и опытных, способных решать возникающие задачи, с другой же – не отягощённых свободным временем, чтобы заниматься этим постоянно. Разумеется, они не оставили за бортом и пользователей начинающих – но только тех из них, кто всё-таки готов был разбираться в том, как работает их система.

Цели и задачи, которые ставили перед собой создатели Salix, они изложили в интервью, состоявшемся 2 октября 1999 года (доступно и в русском переводе. И за прошедшие годы ни разу не отклонились от «генеральной линии».

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

Вопросы терминологии

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

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

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

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

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

По первому критерию всё изобилие существующих дистрибутивов можно разделить на две группы:

   1. дистрибутивы «для всех», предназначенные (обоснованно или нет – другой вопрос) для массового использования в более или менее неизменном виде;

   2. дистрибутивы «для себя», ориентированные на построение индивидуализированных систем.

К первой группе относится большинство активно развиваемых в настоящее время «больших» дистрибутивов – Fedora, openSUSE, Mandriva и, в крайнем её выражении – Ubuntu. Вторая представлена Slackware, Gentoo, Archlinux, CRUX. Место в её рядах находится и для нашего героя — Salix.

Своей целевой аудитории дистрибутивы достигают посредством инсталляции. И по методам последней также можно выделить две группы:

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

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

Представителями первой группы являются Fedora, openSUSE, Slackware и многие другие. Во вторую группу входят все варианты Ubuntu, Zenwalk и ещё несколько менее известных клонов Debian и Slackware. К ней же, с некоторыми оговорками, примыкает и Salix.

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

Для групп, выделенных по второму критерию, ситуация ещё менее чёткая. Ряд систем пакетного выбора (Fedora, openSUSE и некоторые другие), следуя примеру Ubuntu, обзавелись образами LiveCD/DVD, которые суть ни что иное, как их варианты для их быстрого безальтернативного развёртывания. Хотя основным методом их установки по прежнему считается отбор пакетов и их наборов с полных установочных носителей.

А вот собственно системы быстрого развёртывания практически все не могут быть установлены иначе, нежели безальтернативно для данного установочного носителя: выбор вариантов установки здесь осуществляется на стадии выбора последнего. Хотя выше я упомянул, что Salix здесь – некоторое исключение: с одного и того же установочного носителя для него существует три варианта установки. Впрочем, возможности выбора пакетов нет ни в одном из них.

И последний терминологический вопрос, имеющий отношение к Salix – об именовании дистрибутивов, производных от той или иной материнской системы. Их обычно называют:

   • клонами, которые стремятся максимально точно воспроизвести функционал исходной системы и сохранить совместимость с ней (например, CentOS и Scientific Linux – клоны RHEL);

   • форками – «отщеплениями от генеральной линии» родительского дистрибутива, обычно достаточно быстро теряющими совместимость с последним; «Тому в истории мы тьму примеров сыщем», а в недавнем прошлом один из них – ответвление Mageia от Mandriva;

   • дериватами – их создатели, приняв за основу тот или иной дистрибутив, изначально ставят своей целью изменение его ориентации и, соответственно, функциональности; исторически первым дериватом, безусловно, была Suse, разработчики которой, взяв в качестве базовой системы конструктор Slackware, приспособили его для корпоративного использования;

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

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

Предыстория

Как уже было сказано, дистрибутив Salix относительно молод, но корни его уходят в глубокую древность зари дистростроения. Ибо он происходит от Slackware – старейшего дистрибутива из тех, что дожили до наших дней: первая её версия была обнародована создателем, Патриком Фолькердингом (Patrick J. Volkerding), 17 июля 1993 года, положив Linux-дистрибуции в том виде, в каком мы её знаем сейчас.

Особенностями дисрибутива Slackware были:

   • собственная меню-ориентированная программа инсталляции псевдографического режима;

   • выделение категорий пакетов — базовой системы (A), консольных приложений (AP), средств разработки (D), оконной системы X и ее приложений (X и XAP, соответственно), и так далее;

   • набор утилит для манипуляции пакетами (pkgtools), не предусматривающего, однако, никакого контроля зависимостей.

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

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

Рисунок 1-1. Патрик Фолькердинг, создатель Slackware

Впрочем, история зарождения Linux-дистрибуции подробно описана в электронной книге Вопросы истории: UNIX, Linux, BSD и другие, и пересказывать её я не буду. Остановлюсь только на отдельных её моментах, сыгравших свою роль в судьбе нашего героя. А именно – на появлении клонов Slackware. Ибо особенности этого дистрибутива таковы, что он может выступать не только как законченная система, но и как каркас для создания систем индивидуализированных.

Возможностями Slackware как «конструктора» начали активно пользоваться чуть ли не с момента её зарождения. И первым результатом этого стал дистрибутив S.u.S.E.; впрочем, глядя на его сегодняшних потомков (SLE и openSUSE), догадаться об этом нелегко. Однако Slackware дала и немало (более шестидесяти) ответвлений, следующих заветам Патрика; правда, на сегодняшний день из них активно развивается не более дюжины. И причина не в том, что сама Slackware стала менее «продуктивна». Нет, резко сократилось число применителей, которые нуждаются в её «конструкторских» возможностях. А амбиции по созданию собственного дистрибутива «с перламутровыми пуговицами» удовлетворяются обычно на базе Ubuntu.

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

Одним из первых опытов в этом направлении стал Vector Linux, разработанный на базе Slackware Робертом Ланге (Robert S. Lange) и Даррелом Ставемом (Darrell Stavem) на самом рубеже тысячелетий. Уже в первой версии этого дистрибутива, вышедшей в июне 2000 года, была реализована концепция безальтернативной установки интегрированной рабочей среды (в данном случае KDE) с фиксированным набором пользовательских приложений, необходимых и, более или менее, достаточных для решения стандартных задач офисного или домашнего десктопа.

Дистрибутив Vector Linux дожил до наших дней, хотя не пользуется широкой известностью – думаю, что одной из причин тому была его эклектичность. Больше удачи выпало на долю другого представителя систем быстрого развёртывания, основанных на Slackware – дистрибутиву Zenwalk. Поскольку он имеет прямое отношение к нашей теме, остановимся на его истории чуть подробнее.

Дистрибутив Zenwalk возник в середине 2004 года под именем Minislack, а свое нынешнее имя он получил в начале второго года жизни – в августе 2005-го. Его разработчик, француз Жан-Филипп Гийомен (Jean-Philippe Guillemin), – ставил своей целью создание на базе Slackware компактной системы, предназначенной для «себя, любимого». Свои побуждения он описывает во Вступлении к Руководству пользователя Zenwalk (русский перевод).

Рисунок 1-2. Жан-Филипп Гийомен, создатель Zenwalk

Именно в дистрибутиве Zenwalk впервые последовательно был проведён в жизнь принцип «одна задача – одно приложение». Кроме того, в нём декларировалась полная совместимость с материнской Slackware. Однако её исконный инструментарий был дополнен собственной системой управления пакетами netpkg (в том числе и с графическим интерфейсом) и графическими средствами настройки системы.

Жан-Филипп оказался не одинок в своих представлениях об идеальном дистрибутиве Linux. И потому со временем вокруг проекта выросло не очень большое, но активное сообщество разработчиков. В результате дистрибутив развивался очень активно: новые версии его выходили с интервалами от месяца до полугода, и не в соответствие с каким-либо графиком релизом, а при обновлении ядра, рабочей среды (в качестве которой выступала Xfce) и других важных компонентов. Появлялись и различные варианты сборок дистрибутива – с рабочими средами GNOME и KDE, серверная, LiveCD, предназначенная для образовательных целей.

И всё было очень хорошо, но к 2009 году среди основных разработчиков Zenwalk наметились разногласия относительно его дальнейшей судьбы. Потому что, во-первых, этот дистрибутив всё больше отдалялся от первозданной Slackware, полагаясь на собственные средства конфигурирования и пакетного менеджмента, а во-вторых, снизил темп развития. Последнее выразилось в том числе и в том, что в наступившую эпоху доминирования 64-разрядных процессоров Zenwalk по прежнему существовал только в сборке под 32-битную архитектуру. Результатом этих разногласий стало появление дистрибутива Salix.

Появление Salix

Одним из тех, кого не устраивало направление развития проекта Zenwalk, был Георгий Влахавас (George Vlahavas, Греция), один из самых активных его участников. И когда разногласия с Жан-Филиппом перешли в антагонистические противоречия, он основал новый проект и собрал вокруг него группу единомышленников, в прошлом также входивших в число основных разработчиков Zenwalk.

Рисунок 1-3. Георгий Влахавас, создатель Salix

Впрочем, была и другая причина «откола» группы разработчиков от проекта Zenwalk. Один из сооснователей нового проекта, Пьерик Ле Брён (Pierrick Le Brun, Франция): в упомянутом выше интервью, объясняет её так:

Хотя мы очень уважаем Жан-Филиппа Гийомена как кодировщика, творческого и артистического человека, у нас были некоторые возражения против его автократической и иногда беспорядочной манеры управления проектом. Достаточно сказать, что через некоторое время он просто убил веселье (killed the fun). А ведь не нужно забывать, что для разработчиков-любителей веселье – это действительно одна из важных мотиваций их деятельности.

Рисунок 1-4. Пьерик Ле Брён, сооснователь Salix

Название нового дистрибутива долго обсуждалось его первыми разработчиками, и в конце концов ему было присвоено имя Salix OS, в котором первая часть – латинское название ивы. Ещё один из сооснователей его, Торстен Мюльфельдер (Thorsten Mühlfelder, Германия), говорит, что, среди прочих соображений, на выбор имени повлияло наличие интересных художественных работ, использующих идею дерева. Начиная с версии 14.1, вторая часть имени дистрибутива отпала, и теперь он называется просто Salix.

Рисунок 1-5. Торстен Мюльфельдер, сооснователь Salix

В результате 16 сентября 2009 года вышла в свет первая версия Salix, включившая в себя рабочую сред Xfce, ограниченный набор «лёгких» приложений, собранных всё по тому же принципу «одна задача – одно приложение», OpenOffice.org (тогда ещё не разделившийся на две ветки) и Firefox. В отличие от Zenwalk, Salix изначально собирался под две архитектуры – x86 и x86_64, благо незадолго перед тем, в августе 2008 года, вышла и первая 64-битная версия Slackware.

Рисунок 1-6. Ива – талисман дистрибутива Salix

Комплектация Salix была очень сходной с таковой Zenwalk, однако он не являлся ни клоном, ни форком последнего, представляя скорее «возвращение к истокам». Его разработчики отказались от использования дистрибутив-специфичных компонентов Zenwalk, включив зато средства конфигурирования и управления пакетами, существующими для дистрибутива Slackware, но не входящими в её умолчальную комплектацию.

Однако Salix нельзя назвать и прямым клоном или, тем более, форком Slackware: её пакеты были тщательно отобраны и часто пересобраны, составив собственный репозиторий дистрибутива. Кроме того, в Salix вошли и оригинальные составляющие, разработанные Георгием Влахавосом – графическая надстройка над средствами управления пакетами и инструменты для конфигурирования системы. Тем не менее, Salix действительно сохранил (и сохраняет до сих пор) полную совместимость со Slackware, и её пакеты почти всегда могут использоваться в нём безболезненно (и без всяких модификаций). В ознаменование этого первый релиз Salix получил номер 13.0, соответствующий номеру той версии Slackware, на которой он основывался. И эта традиция сохраняется по сей день.

Рисунок 1-7. Salix – первая версия

Таким образом, Salix не укладывался в рамки традиционной номенклатуры дистрибутивов с её клонами, форками и прочими ремиксами. Мой старый товарищ Валерий Моторин aka zenwolf (один из первых его применителей в России) предложил для него термин бакфут (от BAcK to FUTure), как мне кажется, удачный. Ибо, в связи с тенденциями современного дистростроения, мы увидим ещё не одно такое «Возвращение в будущее».

Salix: что было дальше

До конца 2009 года вышло два корректирующих релиза Salix – 13.0.1 и 13.0.2. Затем в июне 2010 года появляется релиз 13.1, основанный на Slackeware соответствующего номера версии, также сопровождавшийся парой корректирующих релизов. И если первая версия дистрибутива существовала в единственном варианте – с рабочей средой Xfce, то для следующей нашлись энтузиасты, начавшие собирать его с другими десктопами и оконными менеджерами – KDE, LXDE, Fluxbox.

Эта тенденция получила некоторое развитие и в дальнейшем. Так, 12 мая 2011 года, через месяц после выхода материнской Slackware 13.37, увидел свет и соответствующий релиз Salix, который сопровождался «дочерними» сборками, в которых к ранее существовавшим присоединились варианты с десктопом MATE и оконным менеждером Ratpoison.

В обоих случаях сборки с графическими окружениями, отличными от Xfce, появлялись с запозданием относительно «головной» версии, иногда значительным. А иногда – и не появлялись вовсе. Вслед за релизом 14.0, вышедшим 21 ноября 2012 года, последовали только варианты дистрибутива с KDE и Ratpoison. А текущий релиз Salix, 14.1 (дата выхода – 4 марта 2014 года) существует сейчас в трёх редакциях – с десктопами Xfce и MATE, а также с оконным менеджером Openbox. В различных пре-релизных стадиях доступны также сборки с Fluxbox'ом и KDE.

Однако для любителей KDE более интересным может показаться другой дистрибутив – Slackel. Это – дериват Salix'а, созданный и поддерживаемый Дмитрисом Дземосом (Dimitris Tzemos), который выступает и основным майнтайнером KDE-линии «головного» Salix'а.

Тем не менее, сборку Salix с рабочей средой Xfce следует считать основной для этого дистрибутива. И далее в этой книжке речь пойдёт преимущественно о ней – и о вариантах её установки, которые будут предметом следующей главы. Хотя пройти мимо остальных редакций Salix'а я также не мог – да и сын его, Slackel, заслуживает нескольких слов, которые будут сказаны в главе 11.

Глава 2. Стандартная установка

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

Системные требования

С точки зрения оборудования, Salix никаких особых претензий не предъявляет. Официально рекомендуемая разработчиками конфигурация целевой машины такова: Intel Pentium III/1 ГГц (или эквивалентный от другого производителя), 512 МБ оперативной памяти и 8 ГБ свободного дискового пространства. Весьма скромно, причём добавляется, что Salix обычно работает без проблем и на более слабых конфигурациях.

К сожалению (или, скорее, к счастью), у меня нет машины с такими характеристиками, чтобы проверить слова разработчиков. Но по собственному опыту могу утверждать, что на любых более или менее современных машинах Salix не просто быстро работает – он работает очень быстро.

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

Кроме сказанного, необходимо иметь возможность загрузки с внешнего носителя – в век отмирания оптических приводов требование не столь очевидное. В качестве внешнего носителя могут выступать USB-флешки, SD-карты (через внешний или встроенный кард-ридер), внутренние «сидюки» или внешние OD-приводы с USB-интерфейсом. Важно только, чтобы BIOS материнской платы позволял сделать одно из этих устройств загрузочным. С чем, впрочем, нынче проблем нет. Скажем, если не удаётся загрузка с SD-карты через встроенный кард-ридер (а это типичная картина для некоторых серий ноутбуков), система прекрасно загрузится с то же карточки, вставленной в кард-ридер внешний, подсоединяемый к USB-разъёму.

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

Далее, необходимо иметь сам установочный носитель. Для текущего релиза (14.1) сборки его iso-образов с рабочим столом Xfce существуют для архитектур x86 и x86_64, объёмом 697 и 713 мегабайт, соответственно. И на соответствующей странице сайта проекта сказано, как их можно получить – по прямым ссылкам на сервер SourceForge.net или через торренты.

В любом случае, после получения требуемого образа, его нужно перенести на носитель. Позволю себе не останавливаться на вопросе, как они записываются на CD или DVD (образ Salix64 Xfce 14.1 впервые за всю историю этого дистрибутива хоть чуть-чуть, но в стандартный 80-минутный компакт не вписывается). А вот о переносе на твердотельные носители типа USB-флешек или SD-карточек (в данном случае между ними разницы нет) пару слов сказать стоит.

Проще всего перенос iso-образа выполняется с помощью прямой команды dd, данной примерно в таком виде:

# dd if=path2/salix-*iso of=/dev/sd?

Где значение if – имя файла образа (с указанием пути к нему), а значение of – имя файла целевого устройства (например, в моём случае – /dev/sdf). Важно, что в качестве имени выходного файла должно фигурировать устройство в целом (raw-устройство), а не какой-либо его раздел. Можно задать и ещё некоторые опции, например, размер блока или их число, но они не являются обязательными; подробности – в man (1) dd.

Носитель, на который выполняется перенос командой dd, не нуждается ни в какой предварительной подготовке: он может быть размечен произвольным образом или не содержать таблицы разделов вообще, отформатирован в любой файловой системе – или не нести никакой, содержать данные или быть чистыми. Единственно, он не должен быть смонтирован в файловую систему. И ещё следует помнить, что имеющиеся на целевом носители данные в процессе переноса на него образа будут утрачены безвозвратно.

Кроме команды dd, существует немало утилит графического режима, предназначенных для переноса iso-образов на твердотельные носители. Многие из них специфичны для того или иного дистрибутива. Но утилиту Unetbootin можно найти практически в любом из них – по крайней мере, из числа распространённых.

В отличие от dd, Unetbootin требует предварительной подготовки целевого носителя: он должен быть размечен как один раздел (например, /dev/sdf1), отформатированный в файловой системе FAT32, подсоединён к машине и смонтирован в файловую систему. После этого, запустив программу (потребуется ввод пароля для получения прав администратора), выбрать образ диска, подлежащий записи. Выбор целевого устройства и раздела на нём происходит автоматически – и обычно правильно, хотя внимание к этой детали не помешает:

Рисунок 2-1. Перенос iso-образа Salix на твердотельный носитель утилитой Unetbootin

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

Личная самоподготовка

Из ближайших разделов этой главы будет видно, что установка Salix'а вовсе не страшна. Однако она требует некоторого объёма предварительных знаний. Как и требования к аппаратуре, он не очень велик. В «кандидатский минимум» будущего применителя этого дистрибутива входят достаточно общие представления о принципах дисковой разметки, знание факта существования нативных файловых систем Linux и понятие о том, что такое загрузка системы и системные загрузчики.

Я на этих вопросах останавливаться не буду – они освещены в многочисленных «толстых» книгах про Linux и разнообразных сетевых материалах. А скажу пару слов по поводу того, а что же это такое – процесс инсталляции? Как ни странно, на эту тему не очень много говорят и пишут, что создаёт вокруг него ореол таинственности. Который усугубляется ещё и современными инсталляторами многих дистрибутивов – красивыми и простыми в обращении, но скрывающими от будущего применителя внутреннюю сущность происходящих действий.

На самом деле ничего таинственного в процессе инсталляции нет. Как бы он ни выглядел внешне, но внутренне он сводится к двум моментам. Первый – инсталлятор представляет собой самую обычную программу, работающую под управлением той системы, которую он призван инсталлировать (бывают исключения, но к нашему случаю они не относятся). Следовательно, первый этап большого инсталляционного пути – это загрузка системы (в данной ситуации – ядра Linux) с какого-либо внешнего носителя (или по сети, например, по технологии PXE).

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

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

   • подготовка целевого носителя, то есть разметка его, создание и монтирование файловых систем;

   • выбор компонентов устанавливаемой системы и их перенос на целевой носитель;

   • обеспечение загрузки с него свежеустановленной системы.

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

Обычно в обязанности инсталлятора включается и всякого рода постинсталляционное конфигурирование, но это уже – опции, существенно зависящие от специфики дистрибутива.

Стандартная установка

Цели ясны, задачи определены – помещаем установочный носитель куда следует, и за инсталляцию, товарищи! Которая начинается с предложения загрузить ядро системы, при необходимости введя его параметры (обычно такой необходимости не возникает):

Рисунок 2-2. Инсталляция начинается с предложения загрузить ядро системы

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

Рисунок 2-3. Выбор раскладки клавиатуры

Здесь не надо поддаваться иллюзиям и пытаться выбрать русскую раскладку – кроме осложнений, это не даст ничего. Ибо эта опция предназначена не для русскоязычных, а для европейских применителей: многие из них используют национальные раскладки типа германо-скандинавской qwertz или французской azerty, отличающихся от стандартной qwerty мелкими, но существенными деталями в расположении специальных символов.

Следующий пункт установочной программы – выбор между режимами INSTALL и AUTOINSTALL. Второй применим только в случае установки на «чистый» диск (или диск, содержимым которого можно пожертвовать, поэтому я скажу о нём позднее. Так что в большинстве случаев следует выбирать режим INSTALL, как более гибкий и универсальный:

Рисунок 2-4. Выбор режима установки

Далее я исхожу из предположения, что в целевой машине имеется один накопитель – традиционный винчестер или SSD. Варианты установки в многодисковых конфигурациях будут рассмотрены отдельно. Так что на следующей стадии, выбора диска, выбирать особо не из чего – достаточно отметить единственное предложение нажатием клавиши Spacebar:

Рисунок 2-5. Выбор диска для установки

А вот после этого возможны варианты. Если целевой диск содержит раздел, который может стать целевым для установки Salix (то есть – пустой или такой, содержимого которого не жалко), можно через пункт Exit сразу перейти к следующей её стадии. Если же нет (или разделы диска требуют изменения) – следует нажать экранную кнопку Go для запуска программы дисковой разметки, роль которой исполняет стандартная утилита cfdisk.

На деталях разметки диска я останавливаться не буду – этот вопрос многократно рассмотрен в сетевых и печатных материалах. Замечу только, что в случае простой однодисковой конфигурации обычно достаточно создать три раздела – под будущий корень файловой иерархии (здесь впору вспомнить о тех самых 8 ГБ из минимальных требований, но при современных объёмах накопителей на нём лучше не экономить), под каталог /home для пользовательских данных (тут работает один из трёх принципов: «сколько нужно», «сколько можно» или «сколько не жалко») и раздел подкачки. Без последнего при объёме оперативной памяти от 4 ГБ и более вполне можно обойтись – правда, при этом последует соответствующее предупреждение, но оно спокойно игнорируется.

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

Хорошей идеей для SSD-носителей является также использование интегрированных систем размещения данных, вроде ZFS или btrfs, с их «резиновыми» файловыми «как бы системами», data sets в первом случае и subvolumes – во втором. Однако первая не поддерживается на стадии установки (хотя в дальнейшем её нетрудно подключить – этим мы займёмся в соотвествующей главе), а вторая ещё не дошла до нужной кондиции.

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

Рисунок 2-6. Выбор корневого раздела

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

Рисунок 2-7. Выбор режима форматирования

Далее предстоит весьма ответственный шаг – выбор для корневого раздела файловой системы: инсталлятор Salix поддерживает практически все, которые являются нативными для Linux. В частности, это один из немногих дистрибутивов, который до сих пор поддерживает reiserfs на стадии установки. Однако по умолчанию Salix для корневого раздела предлагает XFS :

Рисунок 2-8. Выбор файловой системы для корневого раздела

Выбор файловой системы я здесь обсуждать не буду – это вопрос в значительной степени религиозный, и определяется личными предпочтениями и предыдущим опытом. Но если таковых не имеется – то вполне резонно принять выбор разработчиков дистрибутива. Тем более, что XFS в современном её виде действительно обладает замечательным быстродействием – за исключением некоторых ситуаций, типа удаления многих мелких файлов, на чём она просто вязнет. А в случае сомнений беспроигрышный вариант – ext4. Она лишена ярких достоинств, но не имеет и существенных недостатков.

Вне зависимости от выбора, после форматирования корневого раздела, следует проделать эту же процедуру и с разделом под будущий домашний каталог, для которого также по умолчанию предлагается XFS. А потом указать для него точку монтирования явным образом – /home.

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

Рисунок 2-9 Итог разметки диска и форматирования

Разумеется, этот список будет включать все действительно созданные разделы. И именно он будет зафиксирован в файле /etc/fstab установленной системы.

Следующий шаг – выбор источника установки: CD/DVD или USB-носитель. Предлагается также установка с дискового раздела или ранее смонтированного каталога, но я эти случаи не рассматривал. А затем, после определения установочного носителя, наступает момент выбора варианта установки, коих предлагается три – полный (FULL), базовый (BASIC) и минимальный (CORE):

Рисунок 2-10. Выбор варианта установки

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

Не смотря на различие результата, процесс установки во всех трёх вариантах протекает почти одинаково, так что ниже речь пойдёт о установке полной. Об отличиях вариантов BASIC и CORE я скажу в главе третьей.

После выбора варианта и нажатия на кнопку OK начинается попакетное развёртывание системы, ход которого при желании можно наблюдать воочию. Хотя и не очень долго: поскольку формат пакетов Salix очень прост — это обычные для Slackware txz (то есть tar-архивы, сжатые утилитой xz), установка происходит весьма быстро (при инсталляции с USB-носителя – примерно за 3 минуты).

И теперь наступает время установки загрузчика – Salix по сию пору сохраняет верность традиционному LILO, и на на стадии инсталляции иные загрузчики недоступны. Хотя в дальнейшем никто не может запретить установку GRUB2 из штатного репозитория.

Вариантов установки LILO – два, «простой» (simple) и «экспертный» (expert). Можно также отказаться от установки загрузчика вообще (skip) – на случай, если на машине уже установлена какая-либо другая ОС со своим загрузчиком, менять который не целесообразно:

Рисунок 2-11. Установка загрузчика LILO

Различие же между «простым» и «экспертным» вариантом – следующее. В первом конфигурационный файл LILO /etc/lilo.conf автоматически настраивается для загрузки только устанавливаемой системы (то есть Salix) с некоторыми опциями по умолчанию. Единственный уточняющий вопрос – о месте размещения самого загрузчика, в MBR целевого диска, в PBR корневого раздела, или, как атавизм, на загрузочную дискету:

Рисунок 2-12. Выбор места размещения загрузчика

К «простому» варианту имеет смысл прибегнуть, если в машине имеется единственный накопитель и нет других установленных систем. В противном случае лучше обратиться к варианту «экспертному»: он позволяет более гибко настроить параметры загрузки устанавливаемой системы, а также добавить в меню загрузчика пункты для других ОС – не только дистрибутивов Linux, но даже и Windows.

Про Windows ничего сказать не могу. А вот добавление в меню LILO загрузки какого-либо иного дистрибутива Linux для корректного его запуска, возможно, потребует ручной правки /etc/lilo.conf или обращения к специальной утилите LiloSetup (о которой буде говориться в главе#).

В обоих вариантах настройки LILO доступна возможность выбора видеорежима его запуска – стандартного текстового (с плотностью знаков 80x25) или одного из использующих кадровый буфер (frame buffer):

Рисунок 2-13. Выбор видеорежима для запуска загрузчика

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

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

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

Первое из таких действий – указание настройки системных часов, по местному времени или по UTC, с последующим выбором часового пояса, например, Europe/Moscow. После чего определяется системная локаль. Из «русскоязычных» локалей на стадии установки доступны только «юникодовские» ru_RU.utf8 и ru_UA.utf8. Впрочем, приверженцы «допотопной» DOS, «бомжовской» KOI-8 или «классово чуждой» cp1251 обычно сами знают, как установить свою любимую локаль.

Следующий шаг – создание пользовательского аккаунта. Начиная с текущего релиза, в Salix', согласно установленной Ubuntu моде, аккаунт администратора по умолчанию заблокирован – попросту говоря, при инсталляции пароль для доступа к нему не задаётся. А административные привилегии обычный пользователь получает через команду sudo и ввод своего пароля. Так что в Salix, в отличие от Slackware, пользовательский аккаунт обязателен. И создаётся очень просто – указанием логина и, с повторением, пароля, все остальные поля учётной записи будут заполнены по умолчанию:

Рисунок 2-14. Создание пользовательского аккаунта

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

Остаётся нанести последний штрих – выбрать сервер с зеркалом репозитория Salix. По умолчанию инсталлятор предлагает репозиторий на сервере компании HostingXtreme – одного из спонсоров проекта. Если же он в наших широтах покажет себя не очень быстрым, список зеркал можно получить с этой страницы и заблаговременно проверить на скорость, например, утилитой ping.

Рисунок 2-15. Выбор сервера с зеркалом репозитория Salix

На этом процесс инсталляции и начального конфигурирования заканчивается – следует предложение, от которого невозможно отказаться – перезагрузить машину.

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

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

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

А, конечно, Ubuntu некогда установила эталон простоты инсталляции «в пять кликов». При установке Salix'а их (точнее, нажатий на стрелки управления курсором и клавишу Enter) придётся сделать несколько больше. Но разгрызи меня гром, как говорил бригадир Жерар, если это хоть сколько-нибудь сложнее «пяти зулусских кликов». А от двух моментов при установке, которые требуют некоторых знаний и иногда даже размышлений, то есть разметки диска и определения места для установки загрузчика, не в силах избавить ассегаи всех полков Чаки.

Глава 3. Варианты установки

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

Введение

Из второй главы настоящей книжки было видно, что в процессе установки дистрибутива Salix есть две «точки ветвления» его основной линии. Первая – это выбор между режимами INSTALL и AUTOUNSTALL, вторая – выбор между вариантами установки FULL, BASIC и CORE. Но на самом деле есть ещё и «нулевая точка» – выход из программы инсталляции на втором её шаге. Но о нём я скажу в самом конце, потому что рассматривать боковые ответвления (то есть те, которые не отмечены по умолчанию) целесообразно в обратном порядке. В том числе и потому, что все они, в конце концов, вливаются в основную линию процесса установки.

Особенности установки BASIC и CORE

Установка вариантов BASIC и CORE протекает точно так же, как и FULL, включая конфигурирование загрузчика – вплоть до настроек времени, связанных с часовыми поясами. В этот момент требуется единственное за всю инсталляцию обращение к сети для синхронизации локальных часов с мировым временем. А для управления сетью в Salix по умолчанию применяется программа Wicd, которая устанавливается только в полном варианте. Поэтому в вариантах BASIC и CORE после настройки LILO следует предложение настроить сеть.

Рисунок 3-1. Приглашение к настройке сети

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

   • проводное соединение с использованием сервера DHCP;

   • проводное соединение со статической IP-адресацией;

   • «петлевое» (loopback) соединение внутри локальной машины;

   • автоматическое конфигурирование с иcпользованием NetworkManager.

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

А вот для настройки сети с подключением по WiFi, через VPN или при DSL-подключении теоретически следовало бы использовать NetworkManager. Почему «теоретически» – скоро станет ясно.

Так что для начала я рассмотрю самый простой и случай – проводное подключение с использованием DHCP-сервера. Первым шагом в этом направлении будет указание имени целевой машины. В большинстве случаев оно задаётся произвольно, но задаётся обязательно, иначе программа инсталляции не позволит перейти к следующим шагам.

Рисунок 3-2. Определение имени машины

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

Рисунок 3-3. Определение имени домена

Если данная комбинация не проходит – следует обратиться к провайдеру за соответствующими сведениями. Хотя выяснится это только после установки.

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

Рисунок 3-4. Выбор настройки с сервером DHCP

Далее предлагается задать имя сервера DHCP. В большинстве случаев используется автоматическое его определение, так что это поле нужно оставить пустым. Если это не так – следует обратиться к провайдеру.

Рисунок 3-5. Имя сервера DHCP (опционально)

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

Рисунок 3-6. Конфигурация сети

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

Рисунок 3-7. Сконфигурирована ли сеть с помощью NetworkManager?

Однако радоваться рано. После завершения установки системы и перезагрузки машины обнаружится, что никакого сетевого соединения нет и в помине. Что не удивительно, потому что в ходе инсталляции не был установлен не только апплет для управления сетью, но и сам NetworkManager. Программы Wicd, разумеется, нет тоже. Так что можно либо заниматься ручной настройкой сети, либо установить один из менеджеров соединений с локальной машины, скачав заблаговременно нужные пакеты. Но проще всего – во всех сомнительных случаях выбирать вариант полной установки.

В противоположность «нетрадиционным» способам подключения к сети, настройка «петлевого» соединения происходит очень просто. На первых шагах в качестве имени хоста и домена целесообразно указать localhost и local.domain, соответственно. После чего будут автоматически установлены IP и маска подсети, зарезервированные для «локального» использования.

Рисунок 3-8. Настройка «петлевого» соединения

Рассмотрение настройки сети со статической адресацией оставляю заинтересованным лицам.

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

Особенности режима AUTOINSTALL

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

Рисунок 3-9. Выбор диска для автоматической инсталляции

А вслед за тем – предупреждение, что все данные на диске будут уничтожены. Если на это согласиться – целевой носитель будет размечен и отформатирован так, как показано на рисунке 3-10.

Рисунок 3-10. Результат автоматической разметки диска

При этом под корневой раздел будет отведено примерно 10 ГБ, под раздел подкачки – половина объёма оперативной памяти, а всё остальное отдаётся под каталог /home.

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

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

На стадии выбора режима инсталляции будущему применителю предоставляется ещё один вариант выбора – пункт Exit Installation с выходом из программы установки в командную оболочку. Командой

root@salix64:/#echo $SHELL

она определяется как /bin/sh, то есть POSIX Shell, однако на самом деле представляет собой оболочку Альмквиста (ash) из набора Busybox. Она предоставляет такие возможности для комфортной интерактивной работы, как автодополнение команд и путей, историю команд, контроль заданий. В сборку Busybox включено более 500 утилит командной строки, преимущественно административного назначения. А из вида приглашения командной строки можно заключить, что запущена оболочка с правами суперпользователя.

Таким образом, в руках будущего применителя Salix фактически оказывается весьма полная консольная система. Зачем она ему может понадобиться? Ответить нетрудно: хотя инсталлятор этого дистрибутива и позволяет использовать более одного целевого диска, например, подмонтировав второй в качестве /home, но по-настоящему мультидисковых конфигураций не поддерживает. То есть на стадии установки штатно нельзя задействовать ни программный RAID, ни менеджер томов LVM. Так что если в таковых есть потребность – их надо настроить до запуска инсталлятора, вручную.

Конечно, подготовить диски для softRAID или LVM можно с помощью специализированных LiveCD, вроде Image Magic, причём сделать это в «культурной» обстановке графического режима, с помощью наглядной графической утилиты GParted. Однако это было бы умножением сущностей – установочный носитель Salix позволяет проделать всю ту же работу и, на мой взгляд, гораздо проще. Всё необходимое для этого – поддержку в ядре мультидисковых устройств и набор утилит из пакетов mdadm и lvm2 (для работы с программным RAID и LVM, соответственно) командная среда дистрибутива Salix предоставляет.

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

   • при наличии в машине двух и более дисков программный RAID в ряде случаев оказывается целесообразным;

   • на типичном применительском десктопа имеет смысл использовать softRAID Level 0;

   • размещаться на нём должна ветка /home файлового древа.

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

   1. fdisk или cfdisk при использовании таблицы разделов MBR;

   2. gdisk или cgdisk – при разметке в стиле GPT.

Кроме того, в командной среде Salix доступна и универсальная утилита parted, позволяющая оперировать обоими стилями разметки, а также создавать файловые системы. Но, на мой взгляд, она неоправданно усложнена. Чего совершенно нет у утилиты GNOME Disks (о которой написано здесь).

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

Так или иначе, на одном из дисков требуется создать раздел под будущий корень файловой иерархии (размером около 10 ГБ или немного больше), а затем на обоих – по разделу примерно одинакового объёма, которые будут объединяться в RAID. Я в случае двухдисковых конфигураций создаю обычно два обычных раздела – на один устанавливается система для практической работы, на другой – для экспериментов, раздел же под /home на RAID Level 0 для них оказывается общим.

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

Вне зависимости от используемых для разметки инструментов, важный момент – правильное определение идентификаторов типа файловой системы создаваемых разделов. Если для разделов под корень (или под /boot) его следует сохранить присвоенный по умолчанию тип 83 (Linux native), то для разделов под RAID он должен быть изменён на fd (Linux raid autodetected).

Закончив с разметкой диска, приступаем к созданию программного RAID'а. Это делается с помощью утилиты mdadm, которая в рассматриваемом случае запускается в такой форме:

# mdadm --create /dev/md0 --auto=yes --level=0 --raid-devices=2 /dev/sd[a,b]2

Здесь --create (или -C) – субкоманда создания массива, в качестве аргумента которой указывается имя его файла устройства, --level – определение его уровня, --raid-devices – число входящих в массив устройств с указанием их имён (/dev/sda2 и /dev/sdb2). Опция же --auto=yes предписывает создать устройство именно с указанным в примере именем. Иначе после перезагрузки оно может оказаться чем-нибудь вроде /dev/md127, что потребует дополнительных действий по редактированию /etc/fstab. И, разумеется, имена файлов устройств должны быть указаны в соответствие с реалиями целевой машины.

После создания RAID'а результат выполненных действий может быть проверен такой командой:

# mdadm --detail /dev/md0

Если всё было сделано правильно, вывод её должен выглядеть примерно так:

1 8 18 1 active sync /dev/sdb2

Вместо субкоманды --detail можно использовать её сокращённую форму -D. А подробную справку по субкомандам mdadm и её опциям можно получить с помощью общей директивы:

$ mdadm --help

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

$ mdadm --create --help

Из вывода последней можно узнать о таких дополнительных параметрах, как указание размера блока «распараллеливания» (Chunk Size), который теоретически должен влиять на быстродействие (чем больше, тем лучше), Однако сведений, насколько это чувствительно в десктопной обстановке, я не нашёл, и потому проще положиться на умолчание mdadm; как можно видеть из вывода субкоманды -D, оно составляет 512 Кбайт.

Завершив создание RAID, на нём (и на обычных разделах) можно создать и файловые системы одной из команд семейства mkfs (mkfs.ext4, mkfs.xfs и так далее – в зависимости от того, какие из них предполагается использовать). Но это вполне возможно выполнить и из инсталлятора, который запускается командой setup. Единственный момент, требующий внимания – после определения корневого раздела (например, /dev/sda1) и его форматирования не забыть выбрать для форматирования и монтирования устройство программного RAID (в примере – /dev/md0).

Есть ли особенности при установке на SSD?

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

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

За последние годы через мои руки прошло немало твердотельных накопителей разных производителей, моделей и даже интерфейсов (от SATA II до PCI-E). Некоторые из них использовались в обстановке, для десктопа близкой к экстремальной. И потому могу заявить со всей ответственностью: ныне применитель может не ломать себе голову над спецификой SSD, а устанавливать на них систему (и в дальнейшем работать с ней), как на любой традиционный винчестер.

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

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

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

Дать какой-либо рецепт в этом случае невозможно – проблема определяется не спецификой дистрибутива (инсталлятор Salix никаких проприетарных драйверов для чипов Nvidia или AMD не устанавливает), а типом дискретного видео. Так что единственное, что может быть некоторой страховкой от неудачи первого запуска – отключение, если возможно, последнего в BIOS, с последующим разбирательством в спокойной обстановке.

Второй момент связан с подключением сети. Очевидно, что ныне в ноутбуках для этого почти всегда используется WiFi. Который, как было сказано выше, при вариантах установки BASIC и CORE просто не настраивается. Так что для ноутбука целесообразно выбирать полную установку. А с учётом того, что диск в нём обычно один, и, как правило, не требует изощрённой разметки, то и выбор режима AUTOINSTALL тут напрашивается.

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

Заключение

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

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

   • машина с единственным «чистым» или «очищаемым» накопителем, и при отсутствии претензий к разметке, располагает к рехиму AUTOINSTALL;

   • при желании нарастить систему собственноручно интерес представляет вариант CORE;

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

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

Глава 4. Итоги установки

Четвёртая глава посвящена сравнению результатов инсталляции Salix в вариантах FULL, BASIC и CORE с точки зрения набора пользовательских приложений и занимаемого дискового пространства. В заключение приведено сравнение объёмов инсталляции вариантов Salix и примерных аналогов в других дистрибутивах. А также предполагается, какова сфера применения каждого из вариантов. Но сначала – несколько слов о загрузке Salix, так как её процесс почти не зависит от варианта установки.

Начальная загрузка

После завершения установки и перезагрузки машины перед нами предстаёт сначала загрузочное менюLILO – оно будет неизменным после инсталляции по любому варианту.

Рисунок 4-1. Загрузчик LILO

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

Загрузка системы распадается на две стадии – собственно загрузку ядра Linux и инициализацию системных служб. Поскольку в Salix ход этого процесса не прячется за «красивыми» сплэш-картинками или просто чёрным экраном, как это обычно бывает в более «дружелюбных» дистрибутивах, а документируется выводом на экран, смену стадий можно обычно уловить визуально. Сообщения о загрузке ядра выводятся в том режиме, который был установлен при инсталляции для LILO: если выбор был сделан в пользу стандартного, то это будет текстовый режим со шрифтами плотностью знаков 80x25. При переходе к стадии инициализации видеорежим сменится на графический, через frame buffer. Завершается инициализация приглашением к авторизации: после варианта CORE последует текстовое предложение ввести логин и затем пароль, после установки в вариантах FULL и BASIC для этого выводится графическое окно дисплейного менеджера GDM.

Рисунок 4-2. Приглашение к авторизации в графическом режиме

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

Вариант FULL

Как уже неоднократно говорилось в предыдущих статьях цикла, основной рабочей средой дистрибутива Salix является Xfce. И именно она загружается после авторизации в окне GDM. В Salix представлена Xfce последней стабильной версии – 4.10: его разработчики не пошли по пути включения в свой дистрибутив пред-релизных сборок версии 4.12, как это сделано в соплеменном Zenwalk 7.4 и, например, в Xubuntu 14.04. Написано же об Xfce версии 4.10 немало, в том числе и автором этих строк. Что избавляет меня от необходимости повторять общеизвестные (для заинтересованных лиц, разумеется) вещи. Подчеркну только, что в Salix среда Xfce представлена в виде, очень близком к тому, что предлагается по умолчанию в настройках её разработчиков. Впрочем, этот подход (по возможности наиболее полное сохранение особенностей «авторских» пакетов) вообще характерен для героя нашего повествования.

Рисунок 4-3. Среда Xfce в дистрибутиве Salix: вид по умолчанию

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

Рисунок 4-4. Главное меню Xfce

В пункте Графика можно видеть Atril (программу просмотра файлов в формате PDF, DjVu и так далее), GIMP, программы сканирования и просмотра изображений.

Рисунок 4-5. Графические приложения

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

Рисунок 4-6. Основной пользовательский инструментарий

В группу Интернет объединены почтовый клиент, клиент мгновенных сообщений, браузер Midori, менеджер соединений Wicd и так далее. Обращаю внимание на отсутствие «тяжёлых» браузеров и модного NetworkManager.

Рисунок 4-7. Программы для работы в Интернете

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

Рисунок 4- 8. Мультимедийные программы

В пункте Офис можно видеть полный иконостас офисного пакета LibreOffice – перечислять его компоненты не буду.

Рисунок 4-9. LibreOffice во всей красе

Наконец, пункт Разработка радует видом программы Geany, часто относимой к классу «легких» интегрированных сред разработки, иначе IDE (Integrated Development Environment). Но которая, кроме того, представляет собой один из лучших текстовых редакторов, пригодных для сочинения не только исходных текстов программ, но и текстов нарративного характера.

Рисунок 4-10. Средства разработки

Таким образом, можно видеть, что слова разработчиков Salix о тщательном отборе самых лёгких и хорошо вписывающихся в среду Xfce приложений, каждое из которых предназначено для выполнения какой-либо одной задачи, не разошлись с делами. Спорным может представляться только отказ от какого-либо «тяжёлого» браузера в пользу «лёгкого» Midori («легкость» его очень условна, а функциональность – ограничена) и выбор мультимедийных приложений – но это вопрос вкуса.

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

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

Рисунок 4-11. Пользовательские настройки

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

Рисунок 4-12. Общесистемные настройки

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

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

Поэтому очень интересен вопрос, какова же цена этой самодостаточности с точки зрения расхода дискового пространства. Она оказывается не очень высокой – всего в свежеустановленной по полному варианту системе оказывается около 760 пакетов (как определить их число – будет рассказано в следующей статье цикла). Согласно команде df -h, они занимают 3,1 ГБ – что записанные в системных требованиях 8 ГБ свободного дискового пространства (см. главу вторую) определены с хорошим запасом даже для полной установки.

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

Вариант BASIC

При установке Salix в варианте BASIC устанавливается точно та же самая оконная система X (то есть Xorg) и рабочая среда Xfce, которая выглядит точно так же, как и в варианте FULL (см. рисунок 4-3). Комплектацию её приложениями проще всего рассмотреть «от противного» – чего в ней нет по сравнению с полным вариантом инсталляции.

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

Рисунок 4-13. Установка BASIC: главное меню и инструментарий

Разумеется, выполнять практическую работу в такой системе невозможно. Но зато применитель имеет полную свободу в подборе приложений по своему вкусу и привычкам. Например, ему вольно вместо LibreOffice установить пакет Apache OpenOffice, или вообще ограничиться текстовым процессором AbiWord и электронной таблицей Gnumeric. И, разумеется, он может заниматься настройкой системы в полное своё удовольствие – практически все необходимые для этого средства в базовом варианте сохранились в неприкосновенности.

Разумеется, сильно поубавилось и число пакетов – их всего без немногого 600. Да и места на диске они занимают скромные 1,9 ГБ. Напоминаю, что в это число входит Xorg и среда Xfce в необходимой для их полноценного функционирования комплектации.

Вариант CORE

Комплектацию варианта CORE тем же методом «от противного» можно описать буквально в двух словах: в ней нет рабочей среды Xfce и Xorg. Это чисто консольная система. Но зато на его примере можно видеть, что в этом плане Salix снабжён весьма богатым набором утилит и приложений текстового режима. Здесь есть средства для работы со всеми поддерживаемыми Linux файловыми системами и мультидисковыми устройствами (RAID и LVM), инструментарий для локального администрирования и работы с сетью, полный набор средств разработки и сборки программ. Из чисто пользовательских приложений можно отметить текстовые редакторы Vim и nano, консольные аудиоплейеры mpg321 и moc, а также Midnight Commander.

Принцип одного приложения для каждой задачи работает и в подборе консольных программ. Здесь опять не увидеть дублирующих друг друга, например, ftp-клиентов или почтовых программ. А дублирование текстовых редакторов или аудиоплейеров – кажущееся. Так, Vim и nano на самом деле предназначены для решения разных задач работы с текстами, а mpg321 и moc – для разных ситуаций и даже настроения: ведь смысл прослушивания музыки – получение эмоций, ему соответствующих.

Всё это консольное богатство укладывается в чуть больше чем полтысячи пакетов. И занимает на диске 1,1 ГБ.

На мой взгляд, в «стержневой» системе два упущения. Первое – косметическое: по умолчанию не активизирована служба консольной мыши. Хотя пакет gpm присутствует, и это исправляется очень легко.

Второе упущение более существенное: полное отсутствие консольных браузеров. В Salix нет ни links, ни elinks, ни даже канонического lynx. Так что фактически применитель базового варианта этого дистрибутива остаётся без возможности обратиться к сетевым источникам информации. Это упущение должно быть исправлено возможно быстрее, о чём пойдёт речь в главе 5. Но сначала –

Краткий итог

Как итог всего сказанного в этой части цикла я приведу сравнение различных вариантов установки Salix с дистрибутивами сходной комплектации, точнее, также с вариантами их установки, с точки зрения занимаемого дискового пространства. В качестве объектов сравнения дистрибутивы, близкие по времени релиза, с которыми я имел дело в последнее время. Это:

   • Xubuntu (14.04 Trusty Tahr) как аналог полной установки Salix, поскольку она использует ту же рабочую среду Xfce и сходный набор пользовательских приложений;

   • openSUSE 13.1, устанавливаемая с полного DVD (или NET-образа) в варианте Минимальное X Window – он наиболее близок (хотя и не идентичен) базовому варианту Salix;

   • Sabayon Spin Base 14.01, более или менее соответствующий «стержневой» инсталляции нашего героя.

Результаты сравнения приведены в таблице.

Таблица 4-1. Сравнение занимаемого дискового пространства разных вариантов Salix и их примерных аналогов

Дистрибутив Объём установки, ГБ Salix FULL 3,1 Xubuntu 3,2 Salix BASIC 1,9 openSUSE, минимальное X Window 2,0 Salix CORE 1,1 Sabayon SpinBase 2,0

Казалось бы, объём дискового пространства при установках Salix в вариантах FULL и BASIC примерно равен таковому его ближайших аналогов, не так ли? Так, да не совсем. При сравнении полной установки Salix и Xubuntu нужно учитывать, что последняя не включает в себя LibreOffice – роль офисного пакета в ней играет сцепка AbiWord и Gnumeric, существенно меньшая по «весу». В openSUSE же с «голой» X Window нет никакой интегрированной рабочей среды – только лёгкий оконный менеджер IceWM. Так что Salix в обоих случаях представляется более компактным. Для консольных же инсталляций Salix и Sabayon эта разница почти двухкратна – и не в пользу последнего.

Три варианта установки Salix предполагают разные модели применения этого дистрибутива. Для варианта FULL это немедленная практическая работа – после, возможно, небольшой косметической доводки. Вариант же BASIC может применяться двояко: как основа для построения системы с собственным рабочим окружением, отличным от Xfce «головного» проекта, или as is – как специализированная рабочая станция, например, для разработки программ.

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

Глава 5. Управление пакетами: slapt-get

В пятой главе сначала дан краткий обзор средства работы с пакетами, применяемыми в дистрибутивах семейства Slackware. Далее описывается утилита slapt-get – основной инструмент для работы с пакетами и репозиториями в дистрибутиве Salix: приведена общая её характеристика, специфические черты и примеры практического применения.

Введение

В Salix предусмотрено несколько средств для работы с пакетами,. С одной стороны, в нём имеются базовые утилиты, входящие в пакет pkgtools, унаследованный от Slackware. С другой – в нём могут быть установлены любые средства управления пакетами, когда-либо разрабатывавшиеся для родительского дистрибутива.

Но есть и третья сторона медали – принятые по умолчанию две пары инструментов управления пакетами и их репозиториями:

   1. консольная утилита slapt-get и её графическая надстройка Gslapt, предназначенные для работы бинарными пакетами и их репозиториями; дополнительным средством к этой паре выступает служба slapt-update-service, отслеживающая изменения в репозиториях и запускающая по требованию программу Gslapt для обновления установленных пакетов;

   2. также консольная программа slapt-src с графической оболочкой Sourcery – та и другая обеспечивают автоматизацию сборки пакетов из их исходных текстов с помощью специальных сценариев, так называемых слакбилдов (slackbuilds).

Три из этих четырёх инструментов, slapt-get, Gslapt и slapt-src не уникальны для Salix'а. Они были разработаны Язоном Вудвардом (Jason Woodward) для первозданной Slackware ещё в 2003-2005 годах, и с тех пор время от времени использовались как в ней самой, так и в ряде происходящих от неё дистрибутивов (например, в Vector Linux). Однако в состав официального дистрибутива она не была включена. Авторство же Sourcery принадлежит Жоржу Влахавасу — инициатору проекта Salix. И именно в этом дистрибутиве они были объединены «в одной коробке» и возведены в ранг основного инструментария для управления пакетами. Чем во многом и определилась специфика Salix.

Управление пакетами: обзор

Впервой главе говорилось о сохранении совместимости Salix с оригинальной Slackware. Это касается и средств управления пакетами. Поэтому свой рассказ я начну с их обзора в прародительском дистрибутиве.

Сначала – несколько слов о формате пакетов. В Slackware и всех её клонах он предельно прост, представляя собой скомпилированные бинарные файлы «авторского» пакета (то есть созданного его разработчиком), собранные в архив утилитой tar, сжатый компрессором xz (современный суффикс файлов пакетов – txz). К этому добавляется описание пакета и, обычно, пред- и постинсталляционные сценарии. Однако никакой информации о зависимостях пакета в нём самом не содержится.

Базовые средства Slackware для работы с пакетами собраны в пакете (смайлики по вкусу) pkgtools. Он предназначен для работы с единичными пакетами или их сериями и объединяет следующие утилиты:

   • installpkg – установка пакета;

   • upgradepkg – обновление пакета;

   • removepkg – удаление пакета;

   • explodepkg – развёртывание пакета как архива;

   • makepkg – создание пакета.

Все они требуют указания аргумента в виде имени пакета (или группы пакетов, а первые три – ещё и прав администратора для своего выполнения.

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

$ sudo pkgtool

В аргументах эта команда не нуждается, так как предполагает работу в интерактивном режиме.

Рисунок 5-1. Интерфейс утилиты pkgtool

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

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

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

Отсутствие контроля зависимостей и средств работы с репозиториями – именно особенности инструментов pkgtools, а не их недостатки, потому что в ряде случаев могут оказаться и достоинствами. Впрочем, описание тех и других в мою задачу не входит. Важно, что утилиты pkgtools – это базовые средства для работы с пакетами в Slackware, и все остальные инструменты, о которых я скажу чуть позже, основываются на них. Поэтому они в обязательном порядке имеются во всех клона прародительской системы, в том числе и в Salix.

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

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

Отсутствие в пакетах Slackware описания зависимостей отнюдь не мешает их контролю – напротив, облегчает его какими-либо внешними средствами – собственными, разработанными для этого дистрибутива (например, swaret) или заимствованными других систем пакетного менеджмента (ports, pkgsrc, packman и так далее). Большинство этих разработок не получили широкого распространения, некоторые вообще заброшены. Однако на долю одной из них выпал настоящий успех. Это – утилита slapt-get и её графический интерфейс Gslapt. Именно они по умолчанию применяются в Salix для управления пакетами.

Утилита slapt-get: обзор

Утилита slapt-get, предназначенная в Salix для манипуляции пакетами и их репозиториями, создавалась во многом «по мотивами» семейства утилит APT из дистрибутива Debian. Однако это не адаптация последних для пакетов иного формата, подобно apt-rpm. Скорее, она объединяет большую часть функциональности утилит apt-get и apt-cache своими собственными средствами.

В отличие от базовых средств pkgtools, утилита slapt-get работает не с отдельными пакетами, а с их репозиториями, сетевыми или локальным. Одно из зеркал официального репозитория проекта Salix мы выбирали на стадии инсталляции системы (см. главу вторую). При этом slapt-get, подобно утилитам семейства APT, не просто устанавливает пакеты и регистрирует их в базе данных, но и контролирует зависимости (с некоторыми оговорками, о которых я скажу позднее). Однако делается это иначе, чем в apt-get.

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

Формат пакетов Slackware, как уже говорилось, не предусматривает информации о зависимостях: эта функция, если она поддерживается, возлагается внешние их описания. Например, в официальном репозитории Salix зависимости пакета фиксируются в одноимённом ему файле с суффиксом dep. Это – простой текстовый файл, в котором перечислены пакеты, от которых зависит данный. При этом никаких градаций зависимостей по их «важности», как в deb-формате, нет: все они обязательны к разрешению. Однако пакеты Salix, как и Slackware, традиционно собираются по возможности с включением только обязательных (так называемых «жёстких») зависимостей. За счёт чего, кстати, и достигается компактность инсталляции этого дистрибутива, о которой шла речь в главе четвёртой.

Впрочем, бывают и исключения. Например, консольные программы типа Midnight Commander или links собираются в Salix'е с поддержкой gpm – это необязательная («мягкая») зависимость, позволяющая использовать в них мышь как указательно-позиционирующее устройство.

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

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

$ slapt-get [options] target [arguments]

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

Некоторые опции и цели, кроме полной, многосимвольной, формы, имеют и форму краткую, односимвольную. В этом случае перед ними идёт одиночный дефис: так, цель -i является эквивалентом для --install.

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

Цели и опции в выводе -h сопровождаются описаниями – краткими, но кристально ясными, в локализованной системе во многих случаях (в частности, в нашем) – на родном языке применителя (то есть русском). Поэтому описывать их подробно я не буду. А остановлюсь на практическом применении утилиты slapt-get.

Утилита slapt-get: применение

Если в свежеустановленной системе Salix попытаться установить какой-либо пакет с помощью slapt-get, ответом будет такое сообщение:

$ sudo slapt-get --install zshЧтение списка пакетов...Не удалось открыть package_data package_data: Нет такого файла или каталога Возможно, вам нужна опция --update?

Это естественно: утилита slapt-get ничего не знает о содержимом репозитория, с которым она призвана работать. Чтобы она могла устанавливать из него пакеты и обновлять систему, она должна прочитать их список – файл PACKAGES.TXT, представляющий собой нечто вроде оглавления. Делается это командой

$ sudo slapt-get --update

И при первом запуске занимает некоторое время, зависящее от скорости соединения с сервером. И тут надо дать несколько пояснений. Во-первых, цель --update имеет и односимвольную форму -u.

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

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

После формирования локального списка пакетов репозитория утилита slapt-get становится пригодной к установке или удалению программ, а также всех других действий, которые потребуются впредь. И первое из таких действий – это знакомство со списком пакетов, установленных в ходе первичной инсталляции системы. Делается это такой командой:

$ slapt-get --installed

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

Просмотр списка пакетов показывает, что некоторые из них – явно лишние (хотя, если честно, то это проще увидеть через главное меню Xfce). В частности, я первым делом удаляю браузер Midori, ибо назвать его вполне работоспособным в настоящее время трудно. Это требует определения точного имени соответствующего пакета:

$ slapt-get --search midori

Здесь аргумент уже требуется – это ключевое слово, котороеslapt-get будет искать в именах пакетов и их описаниях. И в результате выведет следующее:

midori-0.5.7-x86_64-1gv [inst=да]: midori (a lightweight web browser)

Можно видеть, что slapt-get, кроме имён пакета, полного и базового, а также его краткой характеристики, выводит и его статус (inst=[да/нет]): чтобы этому научиться, утилитам семейства APT, в лице только что появившегося apt, потребовалось 16 лет.

В полном имени пакет следует обратить внимание на символы после указания архитектуры – в данном случае 1gv: число указывает на номер его сборки, а литеры – сокращение от имени или ника майнтайнера. В примере они говорят, что таковым для Midori является Георгий Влахавас, и пакет этот собран специально для дистрибутива Salix, а не заимствован, скажем, из репозитория Slackware. Все расшифровки таких сокращений в обязательном порядке указаны для каждого участника проекта Salix. И скоро станет ясно, почему это имеет значение. А пока выполним собственно удаление пакета:

$ sudo slapt-get --remove midori

Если при установке пакетов slapt-get, с одной важной оговоркой, автоматически разрешает его зависимости, то при удалении попытки удалить их не делается, даже если они более никаким пакетом не используются. Так что единственный способ избавиться от таких «осиротелых» зависимостей – удалить их точно так же, как и сам пакет. А просмотреть список зависимостей можно такой командой:

$ apt-get --show midori

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

В результате удаления Midori наша инсталляция Salix остаётся без браузера вообще, в чём легко убедиться такой командой:

$ apt-get --search browser | grep inst=да

Передача по конвейеру результатов вывода «информационных» целей slapt-get очень полезна при отборе необходимых пакетов. Особенно эффективно этот механизм работает в командной оболочке zsh, в которой для командных конструкций конвейеризации предусмотрены так называемые глобальные псевдонимы. В частности в конфигурационном файле ~/.zshrc можно задать строку вида

alias -g G='|grep'

и после этого использовать для фильтрации пакетов директиву вида

$ apt-get --search browser G inst=да

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

Так что надо срочно устанавливать ему замену – например, Firefox; не потому, что он лучше всех – но для некоторых моих задач альтернативы не имеется. Как и раньше, определяем точное имя пакета – и сталкиваемся с неожиданностью – в выводе команды

$ slapt-get --search firefox

обнаруживается два подходящих пакета:

mozilla-firefox-24.1.0esr-x86_64-1 [inst=нет]: mozilla-firefox(Mozilla Firefox Web browser) mozilla-firefox-24.5.0esr-x86_64-1gv [inst=нет]: mozilla-firefox (safe and easy web browser from Mozilla)

Тут-то и впору вспомнить о суффиксах после номера сборки пакета: одна сборка принадлежит проекту Salix, вторая – взята из репозитория Slackware. Правда, в данном случае ломать голову особенно не приходится: команда

$ sudo slapt-get --install mozilla-firefox

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

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

$ slapt-get --filelist mozilla-firefox

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

/usr/ /usr/bin/ /usr/doc/ /usr/doc/mozilla-firefox-24.5.0esr/ /usr/lib64/ /usr/lib64/firefox-24esr/

Цель --filelist доступна только для инсталлированных пакетов.

Отдельной цели для обновления единичного пакета до его более свежей версии в slapt-get не предусмотрено. Это достигается с помощью всё той же цели --install имя_пакета: если новая версия доступна в репозитории, то она будет установлена взамен старой, если нет – последует сообщение, что пакет имярек в обновлении не нуждается.

Ранее я упоминал опцию --reinstall, которая вместе с целью -i заменяет, при необходимости, установленный пакет другим его экземпляром той же версии:

$ sudo slapt-get --install --reinstall joe

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

$ sudo slapt-get --upgrade

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

Наконец, при выходе новой версии дистрибутива вовсе не обязательно заниматься переустановкой её «с нуля» – достаточно выполнить команду

$ sudo slapt-get --dist-upgrade

которая проделает эту работу автоматически.

Важно, что при установке пакета подтверждение на выполнение действий по умолчанию не запрашивается, а при удалении (и при тотальном апгрейде), напротив, требуется. Это положение можно изменить, указав в первом случае опцию --prompt (она же -p), во втором --no-prompt (или -y).

И ещё одна важная опция для применителя, впервые сталкивающегося с утилитой slapt-get: -s, или --simulate. Как явствует из её имени, она имитирует выполнение установки, удаления или обновления пакетов, выводя сообщение об их результате, но не выполняет никаких действий. Так что в сомнительных случаях можно обратиться к ней.

Пара слов в заключение

Утилита slapt-get предусматривает ещё несколько целей (таких, как --clean – очистка локального кеша пакетов, или --autoclean – удаление пакетов устаревших). Есть в ней и ещё немного сопровождающих опций (например, --download-only – скачивание пакетов без их установки, что может быть полезным при переносе на машину, не имеющую подключения к Интернету). Однако я и не ставил своей целью написать полное руководство по slapt-get, тем более что таковое, в виде одноимённой man-страницы, давно написано. Тем не менее, сказанного, думаю, достаточно, чтобы сделать два вывода.

Вывод первый: не смотря на свою простоту и внешнюю непритязательность, утилита slapt-get справляется с задачами управления пакетами ничуть не хуже, чем утилиты семейства APT, косвенно послужившие её прообразом.

Вывод второй: своему успешному применению утилита slapt-get обязана не только своим достоинствам, но и репозиториям, специально подготовленным для работы с ней. Устройство репозиториев – очередная специфическая особенность дистрибутива Salix, которая будет рассмотрена в следующей главе.

Глава 6. Управление пакетами: репозитории

В шестой главе рассказывается о сериях пакетов Slackware и их назначении, об устройстве репозиториев Salix и их отличиях от репозиториев прародительской системы, в частности – о способах, обеспечивающих в них контроль зависимостей. После этого рассматривается настройка утилиты slapt-get, и дан обзор зеркал репозиториев Salix, а также неофициальных репозиториев Slackware, которые также могут быть использованы в этом дистрибутиве.

Серии пакетов Slackware: вместо введения

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

Во всех развитых системах пакетного менеджмента существует понятие так называемых метапакетов (metapackages), хотя они носят разные имена, Во FreeBSD, из которой и пошло это понятие, они называются метапакетами и метапортами, в дистрибутивах, использующих формат пакетов deb – задачами (tasks), в openSUSE – шаблонами (patterns), в Fedora – группами (groups). Однако суть остаётся одна и та же. Метапакет – это список тем или иным образом связанных пакетов, которые могут быть установлены, обновлены и, в некоторых случаях, удалены одной командой.

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

   • a – минимальный набор пакетов для функционирования системы в консольном режиме;

   • ap – консольные приложения и утилиты, выходящие за пределы необходимого минимума;

   • d – инструментарий для разработки и сборки программ;

   • e – GNU Emacs и всё, что имеет к нему отношение;

   • f – различная общесистемная документация, включая FAQ и HOWTO;

   • k – исходные тексты ядра Linux;

   • kde – пакеты, в сумме образующие одноименную интегрированную среду и необходимые для её работы библиотеки;

   • kdei – пакеты интернационализации для среды KDE и её приложений;

   • l — библиотеки общего назначения, от общесистемной glibc до Qt и Gtk;

   • n – программы для работы с сетью;

   • t – TeX и всё, что с ним связано;

   • tcl – интерпретатор языка TCL и связанный с ним инструментарий;

   • x — оконная система X, то есть Xorg, включая X-сервер, драйверы устройств ввода-вывода и видеоподсистемы и так далее;

   • xap – приложения графического режима, не входящие в базовую систему Xorg, включая оконные менеджеры;

   • xfce – одноимённый интегрированный десктоп и его штатные приложения;

   • y – древние консольные игры, идущие ещё из BSD-систем.

В Salix'е действенны все наборы материнской системы, однако есть и некоторые собственные:

   • games – игры, заменяющие доисторический набор f (которого здесь нет);

   • gnome – приложения для одноимённой среды, несколько лет назад исключённой из официального репозитория самой Slackware;

   • locale – пакеты локализации для LibreOffice, Firefox и Thunderbird;

   • lxde – рабочая среда LXDE и её штатные приложения;

   • mate – современный клон GNOME 2.

Любая из серий пакетов может быть установлена одной командой – для этого в slapt-get предусмотрена специальная цель:

$ sudo slapt-get --install-set [имя серии]

Принцип комплектования серий пакетов в Slackware несколько иной, нежели, скажем, задач в Ubuntu: подобно шаблонам в openSUSE, это скорее тематические группы, нежели целевые наборы типа ubuntu-desktop. И, помимо «канонических» серий Slackware, таких, как a, ap и так далее, собственные наборы пакетов могут создаваться достаточно произвольно: для этого достаточно поместить соответствующие пакеты в один каталог, который дополняется так называемым файлом тегов (tagfile), содержащим их перечень. Однако slapt-get оперирует не сериями пакетов, а их репозиториями, к рассмотрению которых мы наконец и переходим.

Репозитории Salix

Применение к репозиториям Salix множественного числа несколько условно. В сущности, здесь мы имеем дело с единым хранилищем пакетов (и его официальными зеркалами), а не такими сложно структурированными конструкциями, как официальные и полуофициальные (semi-official) репозитории openSUSE или репозитории main, universe, restricted и multiverse в Ubuntu, не говоря уже о её бесчисленных PPA-репозиториях. Впрочем, нечто вроде аналога последних (или «домашних» репозиториев openSUSE) в Slackware и в Salix тоже имеется, но об этом речь пойдёт главе 8.

А пока рассмотреть устройство репозитория Salix проще всего на конкретном примере – например, мастер-сервера проекта. Здесь можно видеть сборки пакетов для каждой из поддерживаемых архитектур – x86 (именуемой i486) иx 86_64. Есть ещё и сборка для процессоров ARM, но это вещь специфическая, и я о ней говорить не буду. Далее речь пойдёт о линии x86_64, как более актуальной.

Внутри каждой «архитектурной линии» обособляются две ветви – репозитории собственно Salix и репозитории Slackware, каждая с разделением на версии (от первой, 13.0 до текущей, 14.1 – впредь будет подразумеваться последняя).

Рисунок 6-1. Корневой каталог репозитория для 64-разрядной архитектуры

Поскольку разработчики Salix, как они сами подчеркивают в упоминавшемся в первой главе интервью, развитие базовой системы передоверили «головной организации», основная часть пакетов дистрибутива хранится в каталоге /salix/x86_64/slackware-14.1/ – его одноимённом подкаталоге slackware64 и extra. Он же представляет собой почти точное зеркало соответствующих ветвей официального сервера родительского дистрибутива – за двумя важными исключениями.

Первое – «сдублированы» не все пакеты Slackware, а только те, которые задействуются в дистрибутиве Salix. О втором же исключении я скажу чуть позже.

В основной части «головной» ветки репозитория, то есть в каталоге /x86_64/slackware-14.1/slackware64, можно видеть те самые серии пакетов, о которых говорилось в предыдущем разделе, а также несколько служебных файлов:

CHECKSUMS.md5 CHECKSUMS.md5.asc FILE_LIST MANIFEST.bz2 PACKAGES.TXT

Рисунок 6-2. Ветка репозитория Salix, заимствованная из прародительского дистрибутива

Важнейшим из них является файл PACKAGES.TXT, содержащий перечень всех пакетов с характеристикой каждого – той самой, которое выводит команда slapt-get при указании цели show и имени пакета. Например, для пакета zsh она выглядит так:

PACKAGE NAME: zsh-5.0.2-x86_64-1.txz PACKAGE LOCATION: ./slackware64/ap PACKAGE SIZE (compressed): 2428 K PACKAGE SIZE (uncompressed): 9340 K PACKAGE REQUIRED: gdbm,ncurses PACKAGE CONFLICTS: PACKAGE SUGGESTS: PACKAGE DESCRIPTION: zsh: zsh (the Z shell) zsh: zsh: Zsh is a UNIX command interpreter (shell) which of the standard shells zsh: most resembles the Korn shell (ksh), although it is not completely zsh: compatible. It includes enhancements of many types, notably in the zsh: command-line editor, options for customizing its behavior, filename zsh: globbing, features to make C-shell (csh) users feel more at home and zsh: extra features drawn from tcsh (another 'custom' shell). Zsh waszsh: written by Paul Falstad. zsh:

Остальные файлы каталога, а их может быть больше, чем приведено на скришноте, также важны. Так, файл, CHECKSUMS.md5 содержит контрольные суммы файлов, подтверждающие их «неизменность», файл GPG-KEY, расположенный в родительском каталоге, включает ключи, удостоверяющие их «подлинность», и так далее. Однако именно наличие файла PACKAGES.TXT волшебным образом превращает обычный каталог с файлами пакетов на локальном диске или удалённом сервере в их репозиторий.

Переходим глубже, в подкаталог одной из серий – и там видим уже собственно файлы пакетов и по два файла со служебной информацией. Например, для того же пакета zsh (в серии ap) они таковы:

   • zsh-5.0.2-x86_64-1.txz – архив с бинарным исполняемым файлов, документацией и прочими компонентами пакета;

   • zsh-5.0.2-x86_64-1.txt – краткое описание пакета;

   • zsh-5.0.2-x86_64-1.txz.asc – контрольная сумма для проверки целостности архива.

Всё – больше никакой информации в репозитории Slackware вроде бы не содержится. В том числе – и никакой информации о зависимостях пакетов.

Теперь обратимся к дистрибутив-специфичной ветке репозитория Salix, то есть к каталогу /x86_64/14.1. Он содержит пакеты, либо отсутствующие в официальном репозитории Slackware (например, slapt-get, описанный в пятой части цикла, его графическую оболочкуGslapt, о которой речь пойдёт в части седьмой, и некоторые другие), либо пакеты, которые разработчики дистрибутива по тем или иным причинам сочли необходимым собрать по своему (например, mozille-firefox). Здесь мы видим те же служебные файлы PACKAGES.TXT с «аннотированным» списком пакетов, GPG-KEY с колючами, ChangeLog.txt с описанием обновлений репозитория, и другие.

Рисунок 6-3. Дистрибутив-специфическая ветка репозитория Salix

Отправившись «глубже», в подкаталог salix, можно обнаружить серии пакетов, в том числе и специфические для дистрибутива, например, серию mate, а в ней – отдельные пакеты. Но здесь на каждый индивидуальный пакет приходится уже пять файлов. Например, для пакета caja (файловый менеджер – форк Nautilus из GNOME2) это будут:

caja-extensions-1.8.0-x86_64-1gv.dep caja-extensions-1.8.0-x86_64-1gv.md5 caja-extensions-1.8.0-x86_64-1gv.meta caja-extensions-1.8.0-x86_64-1gv.txt caja-extensions-1.8.0-x86_64-1gv.tx

Содержимое трёх из них (*.txz, *.txt и *.md5) мы уже знаем, а что же такое файлы *.dep и *.meta? Узнать это легко, если их просмотреть. Первый – это описание тех самых пресловутых зависимостей для пакета:

atk,bzip2,cairo,cxxlibs|gcc-g++,dconf...

А файл *.meta – результирующая метаинформация:

PACKAGE NAME: caja-extensions-1.8.0-x86_64-1gv.txzPACKAGE LOCATION: ./salix/mate PACKAGE SIZE (compressed): 78 K PACKAGE SIZE (uncompressed): 312 K PACKAGE REQUIRED: atk,bzip2,cairo,cxxlibs|gcc-g++,dconf,expat,fontconfig,freetype,gcc,gdk-pixbuf2,glib2,gtk+2,harfbuzz,icu4c,libX11,libXau,libXcomposite,

libXcursor,libXdamage,libXdmcp,libXext,libXfixes,libXi,libXinerama,libXrandr,libXrender,libXxf86vm,libdrm,libffi,libpng,libxcb,mate-desktop,mate-file-manager,mesa,pango,pixman,startup-notification,udev,xcb-util,zlib PACKAGE CONFLICTS: PACKAGE SUGGESTS: ...

Можно видеть, что она включает в себя не только «жёсткие» зависимости (PACKAGE REQUIRED), но может описывать и зависимости опциональные («мягкие» – PACKAGE SUGGESTS), а также конфликтующие пакеты, если те и другие имеются (в примере их нет). Именно благодаря этой метаинформации slapt-get может не только отслеживать зависимости пакетов при их установке, но и разрешать их автоматически.

И тут читатель вправе задать вопрос: если «специфическая» часть репозитория охватывает меньшинство пакетов Salix, а большинство их берётся с зеркала репозитория Slackware, то как зависимости контролируются для них? Ведь там в сериях пакетов мы не видели и намёка на описания зависимостей.

Для ответа на этот вопрос достаточно обратиться к каталогу /x86_64/slackware-14.1, родительскому по отношению к тому, что был приведён на рис. 2. И там обратить внимание на подкаталог dep.

Рисунок 6-4. Основные каталоги ветки Slackware

Зайдя в него, можно обнаружить множество файлов с маской *.dep – по суммарному количеству пакетов в ветке Slackware. В них-то и описаны зависимости для пакетов, заимствованных из прародительского репозитория, ни о каких зависимостях и не подозревающего. Например, в файле zsh.dep можно увидеть следующее:

gdbm,ncurses

Наличие подкаталога с файлами зависимостей – второе (наряду с составом пакетов) отличие ветки Slackware в репозитории Salix отличие последнего от официального репозитория «головного» дистрибутива.

Ну а вынесены эти файлы в отдельный подкаталог из соображений, можно сказать, этических: дабы сохранить структуру ветки, заимствованной из Slackware, в неприкосновенности. То есть подкаталог /x86_64/slackware-14.1/deps – своего рода мега-патч для репозитория, обеспечивающий контроль зависимостей в хранилище пакетов, изначально на это не рассчитанном.

Заодно можно ответить и на другой вопрос: почему slapt-get не получил широкого распространения в самой Slackware и, за некоторыми исключениями, в её клонах? Первая часть ответа очевидна: в официальном репозитории исходного дистрибутива никаких описаний зависимостей не содержится. И в этом случае slapt-get теряет большинство своих преимуществ – более эффективной системой управления пакетами оказывается slackpkg. Для разработчиков же любых клонов Slackware включить slapt-get в штатный комплект своего дистрибутива недостаточно: надо также создать репозиторий с поддержкой зависимостей, а главное – поддерживать его в актуальном состоянии. Что, понятно, является нелёгкой и не очень увлекательной работой, к которой мало кто из энтузиастов оказался готов. Насколько я знаю, единственный, кроме Salix, дистрибутив, где такая работа ведётся – это Vector Linux. Но он и создавался изначально как система, предназначенная, в том числе, и для коммерческого распространения.

Настройка slapt-get

Теперь, зная, как устроены репозитории Salix, можно вернуться к утилите slapt-get – точнее, к её настройке. Потому что большая часть последней – как раз и есть обеспечение доступа к репозиториям.

Все настройки slapt-get хранятся в файле /etc/slapt-get/slapt-getrc. Это простой текстовый файл, который можно условно разделить на три неравные секции.

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

WORKINGDIR=/var/slapt-get

И менять её без веских оснований не следует (я таких оснований не вижу). А вот посмотреть на её содержимое не вредно:

$ ls /var/slapt-getpackage_data patches/ salix/ slackware64/

Самое главное здесь – файл package_data: это «интегрированная» локальная копия файлов PACKAGES.TXT всех подключённых репозиториев, создаваемая командой

$ sudo slapt-get —update

Тот самый файл, без которой slapt-get отказывается выполнять какие-либо иные действия.

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

Вторая секция также содержит единственную строку, хотя и несколько более длинную:

^rootuser-settings,^zzz-settings.*,-i?86-

Это – те самые исключения, то есть маски имён пакетов, не затрагиваемых обновлениями по команде

$ sudo slapt-get --upgrade

А также – автоматическими обновлениями, о которых будет говориться в части седьмой. Удалять из этой строки ничего не следует. При необходимости обновить, например, ядро системы это можно сделать, явным образом добавив опцию --ignore-excludes к команде установки пакета, например:

$ sudo slapt-get --install --ignore-excludes kernel-huge

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

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

# The Slackware repositories, including dependency informationSOURCE=-14.1/:OFFICIAL SOURCE=-14.1/extra/:OFFICIAL # The Salix repository SOURCE=/:PREFERRED # Local repositories # SOURCE=file:///var/www/packages/:CUSTOM

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

На странице Repository mirrors сайта проекта приведён список всех зеркал мастер-репозитория Salix. Для тех, что доступны по протоколу HTTP, я с помощью утилиты ping проверил время отклика – результаты сведены в таблице.

Таблица 6-1. Время отклика зеркал официального репозитория Salix

Зеркало Страна Время, мсек ftp.nluug.nl/os/Linux/distr/salix Нидерланды 60 ftp.belnet.be/salixos.org Бельгия 66 salix.enialis.net Франция 70 mirror.inode.at/data/salix Австрия 71 slackware.org.uk/salix Англия 77 ftp.heanet.ie/pub/salix Ирландия 84 mirrorservice.org/sites/download.salixos.org Англия 85 salix.mirror.garr.it/mirrors/salix Италия 85 mirrors.nix.org.ua/linux/salixos Украина 94 ftp.nux.ipb.pt/dists/salix Португалия 110 ftp.cc.uoc.gr/mirrors/linux/salix Греция 115 salix.hostingxtreme.com США, Огайо 161 mirror.its.dal.ca/salix Канада 167 mirrors.xmission.com/salix США, Юта 198 mirror.bjtu.edu.cn/salix Китай н./с. США, Джорджия н./с. download.salixos.org Франция н./с.

Примечание: сервера в таблице приведены в порядке возрастания времени отклика; н./с. – нет соединения.

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

Дополнительные репозитории

Количество пакетов в репозитории Salix по определению ограниченно – разработчики этого дистрибутива принципиально не стремились объять необъятный мир свободного программного обеспечения. Поэтому вполне реальна ситуация, когда применитель не обнаружит жизненно важного или любимого пакета. И тут восполнить «недостачу» можно двумя способами.

Один из них – сборка недостающих пакетов из исходных текстов. Разумеется, не в «лобовом» варианте, с помощью трёх волшебных заклинаний./configure, make, make install: этот путь очень быстро приведёт к захламлению системы, и прибегать к нему следует в самом крайнем случае. Да в нём нет и необходимости: от Slackware дистрибутив Salix унаследовал механизм работы с так называемыми слакбилдами (Slackbuilds) – сценариями автоматизированной сборки пакетов. И, более того, укрепил и расширил их, в том числе с помощью графической оболочки к консольным средствам. Но этот путь будет рассмотрен в одной из ближайших частей.

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

Неофициальные репозитории Slackware – это своего рода налоги PPA-репозиториев Ubuntu или «домашних» репозиториев openSUSE. Они не столь многочисленны, как последние (и, тем более, первые). Но имеют место быть, причём некоторые из них развиваются уже многие годы, возникнув задолго до создания PPA и OBS. Среди них можно видеть

   • репозитории «братских» дистрибутивов, подобно Salix, сохраняющих полную совместимость со Slackware (например, репозиторий дистрибутива Slackel;

   • репозитории для сборки специализированнх систем – примером может послужить Microlinux Enterprise Desktop (или просто MLED);

   • хранилища пакетов для отдельных интегрированных сред (например, Ktown, содержащий сборки версий KDE, более новых, чем включены в релиз) или оконных менеджеров (таких, как репозиторий пакетов для Enlightenment DR17 – Slack64e14;

   • наконец, личные репозитории энтузиастов – самым известными являются хранилища пакетов, собранных Эриком Хамелирсом (Eric Hameleers, также известный как Alien Bob и Alien Pastures) для применителей из США и иных стран.

Более подробно о неофициальных репозиториях Slackware можно прочитать Приложении.

Разумеется, все найденные репозитории Slackware не следует сразу же вписывать в /etc/slapt-get/slapt-getrc и немедленно выполнять тотальное обновление кеша, а затем и пакетов. Как раз наоборот, делать этого не следует: неофициальные репозитории развиваются сами по себе, часто содержат разные версии одного и того же пакета, да ещё и их зависимости могут быть несколько разными. Так что при таком огульном подключении вполне вероятны конфликты.

Так что лучше вписать неофициальные репозитории с необходимыми пакетами в альтернативный конфигурационный файл (например, /etc/slapt-get/slapt-get-ktownrc для использования новых версий KDE), и для обращения к его содержимому использовать slapt-get с опцией --config [имя файла].

Впрочем, slapt-get в консольном исполнении не предполагает автоматического, независимого от действий применителя (как это обычно происходит в Ubuntu), обновления пакетов. Эта функция возлагается на соответствующую службу, использующую графическую оболочку Gslapt, которая будет предметом рассмотрения в седьмой главе.

Глава 7. Управление пакетами: Gslapt

В седьмой главе описывается Gslapt – графическая надстройка над утилитой slapt-get, рассказывается о её практическом применении и настройке. А также даётся общее заключение о целесообразности их параллельного применения, как взаимодополняющих инструментов для работы с пакетами.

Обзор

Если утилиту slapt-get в какой то мере можно считать созданной по мотивам утилит семейства APT, то её графическая оболочка Gslapt – оригинальная разработка, созданная специально для Slackware. Однако как неотъемлемая часть системы она присутствует только в Salix (и Vector Linux).

В дистрибутиве Salix Gslapt устанавливается по умолчанию в обоих вариантах с графической средой. Он запускается из раздела Система главного меню через одноимённый пункт, предварительно запрашивая пароль пользователя. Что осуществляется через утилиту gksu – графическую надстройку над командами su и sudo (в данном случае, по понятным причинам, используется вторая).

Рисунок 7-1. Запрос пароля пользователя перед запуском Gslapt

Первое действие, требуемое после запускаGslapt – запрос на получение списка пакетов для подключённых репозиториев. Причём это необходимо в любом случае – даже если этот список уже был получен ранее консольной утилитой slapt-get (почему – будет сказано в разделе о настройке Gslapt).

После этого Gslapt выглядит примерно таким образом:

Рисунок 7-2. Gslapt: первый запуск

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

   • общие сведения о пакете – краткая характеристика, статус и приоритет. версия, репозиторий и так далее;

   • описание пакета;

   • зависимости, если они были определены майнтайнером;

   • список изменений, если имеются;

   • список файлов пакета и путей к ним, доступный, если пакет установлен.

Через кнопки инструментальной панели доступны три действия:

обновление списка пакетов, которое желательно проводить при каждом запуске Gslapt;

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

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

Гораздо более богатые возможности представляет меню Gslapt. Через пункт Файл можно обновить локальный кеш пакетов, отметить пакеты с доступными обновлениями и устаревшие пакеты, а также выполнить все «заказанные» операции. Второй и третий подпункты требуют внимания, о чём я подробнее скажу в следующем разделе.

В пункте Правка имеются подпункты Снять все отметки (в некоторых случаях очень востребованная опция) и Настройки, о которых пойдёт речь позднее.

Через пункт Просмотр, как легко догадаться, можно изменить режим вывода списка пакетов, что можно сделать и горячими клавишами: F2 выведет список пакетов, доступных для установки,F3 – пакетов установленных, F4 – отмеченных для выполнения какого-либо действия, F5 – пакетов, для которых в данный момент имеются обновления; нажатие F1 вернёт вывод всех пакетов.

В пункте Пакет собраны действия, доступные в Gslapt – то есть цели (target) в терминах slapt-get (см. главу пятую) - в зависимости от статуса пакета, зафиксированного в данный момент курсором. Например, для неустановленного пакета активизировано единственное действие – Установить (точнее, пока только отметить для установки):

Рисунок 7-3. Gslapt: первый запуск

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

Рисунок 7-4. Gslapt: отметка пакета для переустановки или удаления

В соответствующих случаях установленный пакет можно обновить или, напротив, «откатить» до предыдущей версии.

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

Наконец, в пункте Помощь, во-первых, всегда можно освежить в памяти условные обозначения, применяемые в Gslapt для обозначения статуса пакетов:

Рисунок 7-5. Gslapt: легенда для обозначения статуса пакетов

Во-вторых, можно просмотреть списки изменений во всех подключённых репозиториях:

Рисунок 7-6. Gslapt: списки изменения в репозиториях

Ну и, как всегда, из подпункта О программе можно уточнить номер версии Gslapt и вспомнить о его авторе:

Рисунок 7-7. Gslapt: о программе

Ознакомившись в общем с возможностями программы, рассмотрим приёмы её практического применения.

Действия с отдельными пакетами

Начнём со случая действий над единичными пакетами. Каковые обычно начинаются с их поиска. Отыскать нужный пакет проще всего с помощью строки Search, где вводится символьная последовательность, совпадения с которой будут искаться в именах пакетов, их резюме и описаниях. То есть она не обязана быть именем файла или его частью (хотя знание точного имени существенно упрощает дело), однако может содержать маски типа* или?.

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

Рисунок 7-8. Поиск пакетов

Для каждого из найденных пакетов можно просмотреть его общие свойства и описание:

Рисунок 7-9. Описание найденного пакета

Если пакет установлен, для него доступен список содержащихся в нём файлов, с указанием их положения в файловой иерархии:

Рисунок 7-10. Список файлов найденного пакета

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

В строке поиска можно указать и пакеты, установленные с помощью pkgtools (см. главу пятую, а также собранные из слакбилдов, о которых пойдёт речь в следующей части. Однако для них во вкладке общих свойств не будет указан источник, тогда как для пакетов, установленных с помощью slapt-get или Gslapt в качестве такового указывается один из штатных репозиториев дистрибутива.

Далее, как уже говорилось в предыдущем разделе, к найденному пакету могут быть применены предусмотренные программой Gslapt действия: Установить (Control+I), Переустановить (Control+E), Обновить (Control+U), Установить старое (то есть предыдущую версию, Control+D) и Удалить (Control+R). Комбинация клавиш Control+N снимает с пакета сделанную отметку. Выполнение действий над отмеченными файлами происходит только после нажатия кнопки Выполнить, через пункт меню Файл -> Выполнить или комбинацией клавиш Control+Enter.

Некоторые пакеты, вне зависимости от их статуса, например, различные варианты сборки ядра, отмечены соответствующим значком (расшифровку его смысла см. на рис. 5). И для них не активизирован ни один пункт контекстного меню (или меню Пакет). Это так называемые исключения (EXCLUDE), о которых говорилось в главе шестой (и к которым мы ещё вернёмся в заключительном разделе):

Рисунок 7-11. Пакеты-исключения

Пакеты, входящие в список исключений, средствами Gslapt нельзя ни удалить, ни обновить, ни переустановить без некоторых дополнительных действий. Или это можно сделать из командной строки утилитой slapt-get с указанием опции --ignore-excludes.

Групповые действия с пакетами

Как помнится по главе пятой, утилита slapt-get может не только устанавливать, обновлять и удалять отдельные пакеты, но и обновлять систему в целом. Разумеется, на это способен и Gslapt: достаточно любым способом (горячими клавишами Control+A, через главное или контекстное меню) отметить все пакеты, для которых доступны обновления, после чего нажать Control+Enter или экранную кнопку Выполнить.

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

Рисунок 7-12. Список пакетов, предназначенных к обновлению

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

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

В Salix имеется и возможность автоматического отслеживания обновлений – она носит название Slapt-update-service, устанавливается и активизируется по умолчанию при первичной инсталляции системы. После чего представляет собой пиктограмму в системном лотке управляющей панели Xfce. О наличии обновлений сообщает всплывающая подсказка при наведении на неё курсора мыши. После чего щелчок мышью вызывает панель с предложением эти обновления выполнить:

Рисунок 7-13. Предложение автоматического обновления

Если согласиться с этим предложением – последует запрос пароля пользователя (см. рис. 7-1), после чего будет запущен Gslapt, который выведет список обновляемых пакетов, точно такой же, как на рис. 7-12. И к которому применимо всё, что было сказано относительно обновления непосредственно из Gslapt.

От автоматического отслеживания обновлений можно отказаться вообще: для этого достаточно исключить Slapt-update-service из списка системных служб. Как – будет рассказано в главе 10.

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

Настройка Gslapt

Я уже упоминал, что в Gslapt интегрирована настройка всей этой системы управления пакетами – та самая, которая в предыдущей главе выполнялась в «ручном режиме». Для чего в пункте Правка главного меню предусмотрен одноимённый подпункт, вызываемый также клавишной комбинацией Control+P.

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

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

Рисунок 7-14. Определение рабочего каталога Gslapt

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

Вкладка Исключения содержит список этих самых EXCLUDE, который по умолчанию выглядит так:

Рисунок 7-15. Список исключений

Ну а как с этим списком целесообразно обращаться – было сказано в главе шестой.

Вкладка Репозитории в наглядном виде воспроизводит соедержание третьей секции файла /etc/slapt-get/slapt-getrc:

Рисунок 7-16. Репозитории

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

Рисунок 7-17. Добавление репозитория

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

Наконец, последняя вкладка панели настроек – проверка GPG-ключей:

Рисунок 7-18. Проверка GPG-ключей

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

Краткий итог

Можно видеть, что Gslapt по своему функционалу, как и следовало ожидать, полностью повторяет консольную утилиту slapt-get (ибо является надстройкой над ней). И при этом включает в себя функции настройки, которая иначе реализуется прямым редактированием конфигурационных файлов, и проверки обновлений, которая в slapt-get не предусмотрена. Кроме того, все возможности по работе с пакетами в Gslapt предстают в очень наглядной форме.

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

Так что краткий итог моего затянувшегося обзора таков: slapt-get и Gslapt целесообразно применять параллельно, по ситуации. Нужно только помнить о взаимовлиянии их настроек и всегда начинать работу с ними с обновления локального кеша.

Глава 8. Управление пакетами: сборка из исходных текстов

В восьмой главе рассказывается о сборке пакетов из исходных текстов и о специально предназначенном для этого механизме Slackbuilds, о репозиториях слакбилдов вообще и официальных репозиториях слакбилдов для Salix в частности, а также об утилите slapt-src, служащей для работы со слакбилдами.

Что такое slackbuilds

В самом общем виде слакбилд – это просто сценарий автоматической сборки любого бинарного пакета из его исходных текстов, обеспечивающий выполнение (почти) всех стадий этого процесса – получение «авторского» архива, его развёртывание в дерево исходников, их конфигурирование и собственно компиляцию, завершающуюся созданием бинарного пакета в формате Slackware. В идее слакбилдов легко увидеть черты сходства с портами FreeBSD, портежами Gentoo и особенно с Arch Building System дистрибутива Archlinux. Однако есть и несколько важных различий со всеми перечисленными системами пакетного менеджмента. О некоторых я скажу чуть позже.

Именно из слакбилдов собираются пакеты Slackware и всех её клонов, в том числе и Salix – те самые, которые лежат в соответствующих официальных репозиториях. Однако существует и огромное число пакетов, по тем или иным причинам не попавшим в состав «бинарного официоза» ни одного из дистрибутивов. Вот среди них и следует искать наши «недостачи».

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

Рисунок 8-1. Структура репозитория SlackBuilds.org

Обращение с найденным слакбилдом в общем случае примерно таково (хотя детали могут меняться). Вначале он (то есть файл вида *.SlackBuild и несколько файлов с метаинформацией, в том числе файлом README) скачивается в подходящий каталог, затем ему присваивается аттрибут исполнения:

$ chmod a+x *.SlackBuild

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

$ ./*.SlackBuild

Для обеих процедур, как можно видеть, достаточно прав обычного пользователя. В результате второй в текущем каталоге появляется скачанный из сети архив исходных текстов, файл проверки контрольной суммы, а в каталоге /tmp – готовый бинарный пакет, то есть файл вида *.txz. Который остаётся только установить обычным образом, например, описанным в главе пятой, разумеется, уже с правами администратора:

$ sudo installpkg *.txz

В самих по себе слакбилдах штатно не предусмотрено никакого механизма контроля зависимостей – кроме, разумеется, вывода сообщений в случае их нарушения. Централизованно не предлагает такого механизма и сам репозиторий SlackBuilds.org. В этом первое важное отличие слакбилдов от систем типа портов или портежей.

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

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

Однако Salix предоставляет некоторую возможность контроля зависимостей при сборке произвольных слакбилдов – собственный официальный их репозиторий.

Слакбилбы и Salix

В официальном репозитории Salix можно увидеть целых два хранилища слакбилдов --sbo и slkbuild.

Рисунок 8-2. Корень официального репозитория Salix

Чтобы больше не возвращаться к этому вопросу – для начала скажу пару слов о ветке slkbuild. Не смотря на кажущееся изобилие разделов, повторяющих структуру SlackBuilds.org, на момент сочинения этих строк она включает в себя всего два пакета весьма специфического назначения, в чём легко убедиться, просмотрев, например, /slkbuild/14.1/SLACKBUILDS.TXT:

SLACKBUILD NAME: pastebinitSLACKBUILD LOCATION: ./misc/pastebinit SLACKBUILD FILES: SLKBUILD slack-desc pastebinit-1.3.1.tar.gz SLACKBUILD VERSION: 1.3.1 SLACKBUILD REQUIRES: python,configobj SLACKBUILD SHORT DESCRIPTION: pastebinit (pastebin from the command line) SLACKBUILD NAME: solaar SLACKBUILD LOCATION: ./system/solaar SLACKBUILD FILES: SLKBUILD slack-desc 0.9.2.tar.gz SLACKBUILD VERSION: 0.9.2 SLACKBUILD REQUIRES: dbus-python,pygobject3,python,pyudev SLACKBUILD SHORT DESCRIPTION: solaar (Device manager for Logitech's Unifying receiver peripherals)

А знакомство с файлом /slkbuild/14.1/ChangeLog.txt не показывает следов активного обновления:

Sun Dec 01 2013system/solaar-0.9.2: Added. +-------------------------+ Wed Nov 27 2013 misc/pastebinit-1.3.1: Added.

Так что больше я к нему возвращаться не буду. Пока прошу только обратить внимание на строку SLACKBUILD REQUIRES: в описании слакбилдов для обоих пакетов.

А вот репозиторий sbo – это, как можно догадаться по названию, нечто вроде «филиала» SlackBuilds.org, не только повторяющего его структуру, но и во многом соответствующего ему по содержанию (с некоторыми купюрами).

Рисунок 8-3. Структура sbo-репозитория Salix

В чём же, кроме этих купюр, отличие? Дьявол, как известно, таится в мелочах. И в данном случае эта мелочь — файл SLACKBUILDS.TXT, представляющий собой описание репозитория. Точнее, даже одна строка в описании каждого слакбилда репозитория. И строка эта –

SLACKBUILD REQUIRES:

в которой перечисляются зависимости пакета, собираемого данным слакбилдом (если они у него есть, разумеется). Например, в файле salix.hostingxtreme.com/sbo/14.1/SLACKBUILDS.TXT последние строки описания слакбилда для пакета EMBOSS выглядят так:

SLACKBUILD MD5SUM: cc3fca80cb0618deb10fa0d29fe90e4bSLACKBUILD MD5SUM_x86_64: SLACKBUILD REQUIRES: jdk SLACKBUILD SHORT DESCRIPTION: EMBOSS (European Molecular Biology Open Software Suite)

Тогда как в файле slackbuilds.org/14.1/SLACKBUILDS.TXT аналогичные строки имеют вид:

SLACKBUILD MD5SUM: cc3fca80cb0618deb10fa0d29fe90e4bSLACKBUILD MD5SUM_x86_64: SLACKBUILD SHORT DESCRIPTION: EMBOSS (European Molecular Biology Open Software Suite)

Именно различие в одну строку и позволяет учитывать зависимости при использовании слакбилдов из официального репозитория Salix в отличие от репозитория SlackBuilds.org. Хотя сами по себе слакбилды в них ничем между собой не различаются – более того, это просто одни и те же слакбилды.

А теперь давайте посмотрим, как это выглядит на практике. Для чего рассмотрим утилиту slapt-src, специально предназначенную для работы со слакбилдами.

Утилита slapt-src

Как уже говорилось, утилита slapt-src – не специфичный для Salix инструмент. Однако именно в этом дистрибутиве она заиграла всеми своими красками – в первую очередь благодаря описанным в предыдущем разделе его официальным репозиториям.

Утилита slapt-src написана тем же автором – Язоном Вудвардом, что и slapt-get, и работает в том же стиле.

Конструкция её команды требует указания действия (action — аналог target в slapt-get), в большинстве случаев – аргумента, то есть имени slackbuild'а, и, возможно, опций. Полный список действий и опций можно получить командой

$ slapt-src --help

или просто запустив slapt-src в «голом» виде. В отличие от slapt-get, в этой утилите какждое действие и каждая опция имеют как полную, так и краткую форму – так, вместо --help можно ввести -h. Действия и опции сопровождаются кристально ясными описаниями (в том числе и на русском), так что я остановлюсь .

Порядок действий при использовании slapt-src – точно тот же, что и при работе с slapt-get. Первое действие – запуск команды

$ sudo slapt-src -u

которая скачает данные о слакбилдах из подключённых репозиториев. А затем – с помощью

$ slapt-src -l

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

$ slapt-src -s slackbuildname

отыскивается нужный. При необходимости командой

$ slapt-src -w [или --show] pkgname

просматривается его описание. После чего можно приступать к сборке:

$ slapt-src -i slackbuildname

Имя слакбилда всегда совпадает с именем пакета, который собирается с его помощью.

Как обычно, всё сказанное проще проиллюстрировать на примере, что я сейчас и проделаю. В конце прошлого раздела было приведено описание слакбилда для пакета EMBOSS – вот он примером и послужит. Во-первых, в силу своей компактности. А во-вторых – как иллюстрация того, для каких пакетов в принципе можно обнаружить слакбилды. Что косвенно указывает, на кого, в том числе, ориентирован дистрибутив Salix (как, впрочем, и материнская Slackware).

Начинаем, разумеется, с поиска:

$ slapt-src -s EMBOSSEMBASSY:6.6.0 - EMBASSY (EMBOSS associated software) EMBOSS:6.6.0 - EMBOSS (European Molecular Biology Open Software Suite)

Теперь можно просмотреть информацию о пакете:

$ slapt-src -w EMBOSSИмя слакбилда: EMBOSS Версия слакбилда: 6.6.0 Категория слакбилда: academic/EMBOSS/ Описание слакбилда: EMBOSS (European Molecular Biology Open Software Suite) Файлы слакбилда:

EMBOSS.SlackBuild EMBOSS.desktop EMBOSS.info EMBOSS.png README References doinst.sh slack-desc Требования слакбилда: jdk

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

$ sudo slapt-src -i EMBOSS

то нам о них тут же после ввода пароля напомнят – и не просто напомнят, а предложат установить:

Следующие пакеты будут установлены: EMBOSS Следующие зависимые слакбилды будут собраны и установлены: jdk Продолжить? [y/N]

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

Простота использования slapt-src усугубляется элементарностью его настройки: все его конфигурируемые параметры лежат в файле /etc/slapt-get/slapt-srcrc и сводятся к указанию каталога для сборки пакетов, их «выходному» формату и перечислению подключённых репозиториев. Однако к вопросу настройки я ещё вернусь в следующей части цикла, которая будет посвящена Sourcery – графической настройке над slapt-src.

Глава 9. Управление пакетами: оболочка Sourcery

Предмет девятой части цикла – Sourcery, графическая оболочка для slapt-src. Она позволяет выполнять действия со слакбилдами если не проще, то, безусловно, наглядней. Если утилита slapt-src – средство, общее для всех дистрибутивов семейства Slackware, то её графическая оболочка Sourcery – это фирменный инструмент дистрибутива Salix, разработанный и поддерживаемый его создателем и одним из основных майнтайнеров – Геогием Влахавасом. Что, разумеется, не значит, будто её нельзя использовать и в составе родительской системы. Однако Salix – единственный дистрибутив, в котором Sourcery установлен по умолчанию.

Вступление

Sourcery запускается из одноимённого пункта раздела Система главного меню Xfce, для начала требуя, как и Gslapt, ввода пользовательского пароля:

Рисунок 9-1. Запрос пароля

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

Рисунок 9-2. Первый запуск

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

Рисунок 9-3. Вид по умолчанию

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

Пример применения

Порядок работы с Sourcery очевиден. Сначала в списке слакбилдов (или, что гораздо проще, через строку поиска) отыскивается требуемый пакет. Предположим, это будет TauDEM – пакет для работы с картографическими данными в DEM-формате (я продолжаю намекать, кому может быть полезен дистрибутив Salix). Затем на него (через главное или контекстное меню) ставится отметка Установить:

Рисунок 9-4. Выбор пакета для установки

И, в принципе, можно нажимать кнопку исполнения. Однако перед этим очень невредно обратиться к пункту контекстного меню Получить информацию, который выведет такую панель – здесь следует обратить внимание на строку Зависимости, содержащей в данном случае единственный пакет openmpi:

Рисунок 9-5. Информационная панель: общие сведения о пакете

Содержание следующей вкладки, Описание, понятно без комментариев:

Рисунок 9-6. Информационная панель: описание пакета

Обычно внимательного ознакомления требует вкладка Файл README – здесь могут содержаться сведения об опциях сборки пакета. Если таковые обнаружатся – их надо задать через пункт меню Установка опций вот таким образом:

Рисунок 9-7. Установка опций компиляции

Однако в нашем примере их нет. Вместо этого мы видим не менее полезную информацию – описание функционала пакета, краткое, но достаточное:

Рисунок 9-8. Информационная панель: файл README

После этого кнопкой выполнения, через меню Файл -> Выполнить или комбинацией клавиш Control+Enter вызывается панель подтверждения серьёзности намерений:

Рисунок 9-9. Подтверждение установки

При этом сообщается, что будет установлен не только «заказанный» пакет, то и его зависимости – тот самый пакет openmpi, который был указан в общих сведениях о пакете (см. рис. 9-5).

После этого слакбилды в порядке, требуемом для удовлетворения зависимостей, отправляются на выполнение – то есть в нашем примере сначала openmpi, а затем уже TauDEM. Ход выполнения заданий отображается в соответствующем окне, как в обычном терминале при сборке через slapt-src:

Рисунок 9-10. Выполнение заданий

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

Рисунок 9-11. Успешное завершение работы

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

Рисунок 9-12. Сообщение об ошибке выполнения слакбилда

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

Рисунок 9-13. Отчёт о выполнении слакбилда

В данном случае для сборки пакета TauDEM потребовалась утилита cmake – и действительно, в базовой установке Salix её нет, что автору слакбилда не пришло в голову. Однако она имеется в стандартном репозитории и легко может быть установлена из бинарного пакета, например, с помощью slapt-get. После чего процедуру сборки слакбилда придётся повторить (с тем исключением, что зависимость пакета TauDEM, пакет openmpi, уже собрана и установлена). Наградой за что будет вожделенное сообщение об успехе (см. рис. 9-11).

Сразу замечу, что список отчётов обо всех выполненных через Sourcery действиях сохраняется в соответствующих лог-файлах, список которых можно вызвать через меню Просмотр -> Отчёты или горячими клавишами Control+L:

Рисунок 9-14. Список отчётов о выполнении слакбилдов

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

Немного о настройке

Вот и всё, что нужно для успешного применения Sourcery. Осталось сказать несколько слов о его настройках. Поскольку это – оболочка для slapt-src, то главные из них концентрируются в том же файле /etc/slapt-get/slapt-srcrc, и могут быть изменены его прямым редактированием.

Однако имеется и визуальное средство для конфигурирования, предоставляющее некоторые дополнительные возможности. Это — панель Настройка, вызываемая через меню Правка -> Параметры (или через комбинацию Control+P). Здесь, во-первых, можно пополнить список источников слакбилдов и их приоритет (он задаётся порядком в списке, изменяемым простым перетаскиванием):

Рисунок 9-15. Панель настроек: источники скриптов

Впрочем, на мой взгляд, пополнять список репозиториев большого смысла не имеет, ибо, например, главный источник слакбилдов для всех времён и народов – SlackBuilds.org не содержит информации о зависимостях. А без неё Sourcery теряет всё свою прелесть.

Далее, можно изменить каталог для хранения слакбилдов и всего, что с ними связано: скачанных архивов исходных текстов, результатов их распаковки, собранных бинарных пакетов, входящих в их состав файлов, предназначенных уже для прямого включения в файловую иерархию. По умолчанию это /usr/src/slapt-src:

Рисунок 9-16. Панель настроек: рабочий каталог

Поскольку в этом каталоге содержится абсолютно всё, что может потребоваться применителю при желании модифицировать не только слакбилд, но и исходные тексты пакета, возможно, у него появится и желание поместить всё это хозяйство в какое-либо иное место. Однако более востребованная функция здесь – скорее очистка каталога от всех этих «продуктов жизнедеятельности» Sourcery (точнее, slapt-src).

Наконец, можно попросить Sourcery разрешать зависимости – именно попросить, потому что, как уже неоднократно подчёркивалось, он это сделает только в том случае, если информация о зависимостях данного слакбилда имеется в содержащем его репозитории:

Рисунок 9-17. Панель настроек: разрешение зависимостей

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

Глава 10. «Фирменные» утилиты

В десятой главе я хотел бы сказать о ещё одном дистрибутив-специфическом его компоненте – собственных утилитах конфигурирования. Они были разработаны Георгием Влахавосом не для замены традиционных средств настройки (среди которых испокон веков главным является текстовый редактор), а для их дополнения. Большая их часть собрана в два пакета --salixtools и salixtools-gtk. Как нетрудно догадаться, в первый в входят средства консольные, во второй – имеющие графический интерфейс. По своему функционалу они, по большей части, пересекаются. Более того, утилиты второго пакета – это, в основном, графические оболочки для команд пакета первого.

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

Итак, пакет salixtools. В его составе:

   • clocksetup – инструмент настройки даты и времени;

   • keyboardsetup – инструмент для настройки раскладок клавиатуры;

   • localesetup – средство установки системной локали;

   • reposetup – утилита для выбора зеркала репозиториев;

   • service – команда запуска, останова и перезапуска системных служб;

   • servicesetup – утилита для настройки служб, запускаемых при старте системы;

   • update-all – команда для обновления репозиториев;

   • usersetup – утилита для управления пользовательскими аккаунтами.

Легко видеть, что все действия, достигаемые перечисленными средствами (кстати, все они требуют прав администратора, то есть должны предваряться командой sudo), были выполнены в ходе постинсталляционной настройки системы. И если последняя была проделана аккуратно – возвращаться к ним не придётся практически никогда. Если же такая необходимость всё-таки возникнет – возможно, более удобными окажутся альтернативы, работающие в графическом режиме. Они, как уже говорилось, собраны в пакете salixtools-gtk, а вызываются из соответствующих пунктов раздела Система главного меню Xfce. Среди них:

   • Имя компьютера в сети (gtkhostsetup) – назначение полностью соответствует названию пункта меню;

   • Звуковая карта (gtkalsasetup) – настройка ALSA для звуковой карты; в скобках замечу, что столь «любимый» многими pulseaudio в Salix по умолчанию не используется и в официальных репозиториях отсутствует, хотя и может быть установлен из слакбилдов;

   • Дата и время (gtkclocksetup) – графический интерфейс для clocksetup, и служит той же цели;

   • Обновление значков (gtkiconrefresh) – средство обновления общесистемных пиктограмм;

   • Клавиатура (gtkkeyboardsetup) – графический интерфейс для keyboardsetup, то есть средство для настройки клавиатурных раскладок;

   • Язык системы (gtklocalesetup) – графический интерфейс для localesetup, то есть средство для установки системной локали;

   • Системные сервисы (gtkservicesetup) – графический интерфейс для servicesetup, позволяющий легко управлять загрузкой системных сервисов;

   • Пользователи и группы (gtkusersetup) – графический интерфейс для usersetup, инструмент управления пользовательскими аккаунтами.

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

К этой же группе примыкает утилита LiloSetup, представляющая собой отдельный одноимённый пакет и вызываемая из меню Система через пункт Программа установки LILO. Она позволяет настраивать загрузку системы в относительно комфортной обстановке графического режима. И о ней стоит сказать подробнее.

Вопреки своему названию, LiloSetup не обязательно устанавливает одноимённый загрузчик (хотя может сделать и это, например, при запуске с Live-носителя), а в основном позволяет отредактировать его конфигурационный файл, после чего выполняет обновление записи в MBR. Само по себе LILO было установлено в ходе инсталляции системы (см. главу вторую). И при первом запуске, после авторизации, LiloSetup выводит окно его настроек в том виде, в каком они были сделаны при установке:

Рисунок 10-1. Первый запуск LiloSetup

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

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

Рисунок 10-2. Выбор имени загружаемой системы

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

Рисунок 10-3. Меню LILO с отредактированными именами

Правда, зачем это делать – я так и не понял, потому что эти новые имена нигде не фиксируются – в частности, они пропадают и при следующем запуске утилиты, даже в том же сеансе. Но только после изменения хотя бы одного имени активизируется кнопка Править файл настроек. Ею в системном текстовом редакторе (в Salix'е таковым по умолчанию выступает Leafpad) открывается прототип нового конфигурационного файла – /tmp/lilosetup:

Рисунок 10-4. Редактирование /etc/lilosetup в Leafpad'е

Как можно видеть по его родительскому каталогу, файл этот генерируется автоматически, однако его можно редактировать. Правда, он содержит только секцию общих настроек LILO – секции, соответствующие остальным имеющимся на машине системам, придётся вписывать вручную. Так, для Salix'а её можно просто скопировать из файла /etc/lilo.conf, вписав после

# Конец секции общих настроек LILO

такие строки:

# Linux bootable partition config begins image = /boot/vmlinuz root = /dev/sda1 label = Salix read-only # Linux bootable partition config ends

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

Рисунок 10-5. Подтверждение намерений

И в случая согласия через мгновение появится сообщение об успехе выполнения процедуры:

Рисунок 10-6. Сообщение об успехе

Успех знаменуется появление в каталоге /etc/ нового конфигурационного файла – lilosetup.conf, который был сгененрирован из отредактированного прототипа – /tmp/lilosetup. Теперь остаётся только обеспечить запуск Lilo с параметрами нового конфига. Это делается такой командой:

$ sudo lilo -C /etc/lilosetup.conf

После этого можно перезагрузить систему, дабы убедиться в том, что всё работает нормально. И приступить к составлению секций для загрузки других систем, имеющихся на данной машине. В качестве образца заполнения секций можно брать шаблоны из файла /etc/lilo.conf_example или обратиться к бесчисленным сетевым материалам (имеющимся, в том числе и на Блогосайте, применительно к соплеменному Zenwalk'у).

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

Предвижу возражение: того же самого эффекта можно добиться и в оригинальной Slackware. Можно. Но – затратив на это время и усилия. То есть, в сущности, повторить работу, которую уже проделали Георгий Влахавос и его соратники. Так зачем же изобретать велосипед вместо того, чтобы с благодарностью не воспользоваться результатами их труда?

Глава 11. Редакции и сородичи

Как было сказано в главе первой, в дистрибутиве Salix, кроме основной редакции с десктопом Xfce, имеется ещё несколько вариантов с разными рабочими окружениями: MATE, KDE, Openbox, Fluxbox. В принципе можно установить в Salix'е и Cinnamon, хотя и версии – 2.0, то есть не последней.

Кроме того, существует Slackel, занимающий положение на грани между дериватом Salix'а и его редакцией. Хотя и сам имеет три редакции – с KDE и оконными менеджерами Fluxbox и Openbox. Причём каждая из них имеет два варианта образов – чисто установочный и Live-OD, также с возможностью установки.

Я знакомился MATE- и KDE-редакциями «головного» дистрибутива, с обоими вариантами KDE-редакции Slackel'а. О них и пойдёт речь в главе одинадцатой. Начну с MATE-редакции Salix'а, как наиболее близкой идеологически к «командорскому» варианту.

Salix: MATE-редакция

Редакция Salix'а с MATE – самая молодая из всех. Но начну я, по озвученной выше причине, именно с неё. Сначала, в марте текущего года, пакеты этого десктопа появились в составе одноименной серии в официальном репозитории. Затем было несколько пре-релизных образов – с одним из них я знакомился. И наконец в мае вышел первый релиз – образы salix-mate-14.1.iso и salix64-mate-14.1.iso (для 32- и 64-разрядных машин, соответственно.

Про MATE в сети можно было найти немало положительных отзывов. В частности, Сергей Голубев полагает, что

...десктопа лучше старого доброго GNOME 2 пока не придумано.

А MATE является его современным (и развивающимся) воплощением. И, следовательно, заслуживает, как минимум, знакомства. Тем более, что для этого не обязательно скачивать образ и переустанавливать систему – достаточно одной команды:

$ sudo slapt-get --install-set mate

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

И так все ясно.

Среда MATE – предельно точное воспроизведение интерфейса и функционала GNOME 2. Настолько точное, что отличия можно увидеть в только в деталях умолчальной темы оформления и в более иных названиях штатных приложений (Gaja вместо Nautilus'а, Pluma вместо Gedit'а, и так далее). Что не может не радовать – звучные квази-испанские имена пакетов MATE на слух куда приятней, чем почти неименное G, обычно присутствующее в названиях приложений GNOME (и старого, и нового).

Я неоднократно писал, что никакой особой симпатии к GNOME-раз и к GNOME-два не испытывал никогда (а про GNOME-три и говорить не хочется). Хотя допиленность последних версий «второгнома» и их интегрированность с дистрибутивом Fedora версий с 11 по 14 включительно и убедили меня, что в подземельях Мории жить тоже можно. Однако, глядя на MATE, ни малейшей ностальгии не испытывал.

Тем не менее, сам факт существования этого десктопа расцениваю как явление положительное, ибо увеличивает разнообразие мира. А портирование MATE в Salix – так ещё и практически полезно. Ведь с тех пор, как Патрик отказался поддерживать GNOME в рамках генеральной линии партии (ох как я его понимаю), в Slackware и её клонах время от времени возникают проблемы с Gtk-пакетами (читай – приложениями не из KDE), поскольку они иногда почему-то оказывались связанными зависимостями с GNOME и его быблиотекми. Теперь такие пакеты можно смело брать из набора MATE. Так, именно оттуда я вытащил для Xfce-редакции Salix'а и менеджер архивов для Thunar'а, и универсальный вьювер PDF/Djvu/всякоразных форматов.

Однако начну по порядку. Установка MATE-редакции, как и следовало ожидать, ничем не отличалась от таковой обычного Salix'а с Xfce, и точно так же подразумевает три варианта: CORE, BASIC и FULL. А по завершении её, перезагрузки и авторизации через GDM, даёт такой вот результат:

Рисунок 11-1. Рабочий стол MATE после первой загрузки

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

Рисунок 11-2. Центр управления MATE

Здесь меня интересовал пункт Клавиатура – в виденном мной пре-релизе невозможно было установить никакую раскладку клавиатуры, кроме имеющейся по умолчанию американской английской

Рисунок 11-3. Настройка клавиатуры

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

Рисунок 11-4. Добавление кириллической раскладки и её варианта

Как и установка переключателя раскладок – любого из их традиционного набора:

Рисунок 11-5. Определение переключателя раскладок

Одновременно с этим появился и индикатор текущей раскладки в виде флажка на панели управления.

Убедившись, что система пригодна к практическому использованию в наших языковых краях, я бегло просмотрел набор предустановленных приложений – при инсталляции я выбрал «полный» вариант установки. Говорить о них словами было бы скучно, поэтому просто проиллюстрирую соответствующие пункты меню Приложения скриншотами. Первая секция, Аудио и Видео, показала наличие следующих программ:

Рисунок 11-6. Приложения: секция Аудио и Видео

В пункте Графика обнаружилось следующее:

Рисунок 11-7. Приложения: секция Графика

В секции Интернет обнаружилось наличие Firefox'а, отсутствие всякого Network Manager'а (вместо него для настройки сети имеется Wicd) и какого-либо «родного» браузера для GNOME. Последние на моей памяти менялись так часто, что я и забыл, который из них сейчас считается самым прогрессивным, а запускать его мне было лениво:

Рисунок 11-8. Приложения: секция Интернет

В «образовательный» пункт почему-то попал редактор формул из LibreOffice, остальные же его компоненты обнаружились где и положено, в пункте Офис:

Рисунок 11-9. Приложения секция Офис

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

Рисунок 11-10. Приложения: секция Программирование

А в «стандартном» пункте, как обычно, собралась всякая всячина, от Galculator'а до скриншоттера. Среди неё оказался и текстовый редактор Leafpad, а вот штатного редактора Pluma как раз не обнаружилось:

Рисунок 11-11. Приложения: секция Стандартные

С меню Система также всё понятно без комментариев. Пункты секции Параметры соответствуют пиктограммам Центра управления, и выглядит следующим образом:

Рисунок 11-12. Система: секция Параметры

А в пункте Администрирование собраны общесистемные настройки:

Рисунок 11-13. Система: секция Администрирование

Здесь надо отдельно сказать о звуке. Как и в Salix'е с Xfce, управление им осуществляется через ALSA, ни малейшего Pulseaudio тут нет, на радость ненавистникам последнего.

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

Оставалось убедиться, что всё это – не глюк виртуальной реальности, и установить систему на всамделишнее «железо». Для чего iso-образ был записан на флешку с помощью утилиты Unetbootin, что не составило ни малейшей проблемы. Как, впрочем, и для варианта с Xfce. Более того, замечу к слову, что и для родительской Slackware времена, когда образы её установочных дисков можно было переписать на твердотельные носители, только прибегнув к некотором ухищрениям, остались в прошлом. Ныне эта процедура выполняется через Unetbootin безболезненно. Подозреваю, что это можно сказать и про остальные утилиты аналогичного назначения, да и про прямую команду dd тоже, хотя на практике попробовать последний вариант я так и не удосужился.

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

Slackel, сын Salix'а: вступление

Один из показателей успеха дистрибутива – число порождённых им клонов, дериватов, ремиксов и прочих потомков. Разумеется, в этом отношении трудно угнаться за Ubuntu, от которой, кроме законных детей типа Kubuntu, Xubuntu etc., происходит бессчётное число потомков не вполне законных, но признанных (таких, как Mint), отпрысков «в законе» местного масштаба (вроде многочисленных клонов с региональной спецификой, например, андалузской), и даже откровенных ублюдков (которых поминать не будем, ибо нет в том чести).

Однако и Slackware в своё время немало отличилась по этой части: лет пять назад, выбрав в поиске Distrowatch'а Based on Slackware, можно было получить список примерно из полусотни имён. Правда, иных уж нет, а те далече: в настоящий момент из этого активно развивается едва дюжина дистрибутивов. И причина не в том, что сама Slackware стала хуже. Просто резко сократилось число тех применителей, которые нуждались в её возможностях конструктора. А амбиции по созданию собственного дистрибутива с розовыми обоями и перламутровыми кнопками можно легко и просто удовлетворить, взяв за основу Ubuntu.

Тем не менее, новые клоны Slackware, и клоны удачные, возникают постоянно, примером чему – Zenwalk и Salix.

Как мы знаем из истории, описанной в главе первой, Salix являет собой дистрибутив, производный от Slackware. А Salix, к тому же ещё в очень юном, менее чем трёхлетнем, возрасте успел породить и собственного отпрыска – дистрибутив Slakel.

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

Разработчик Slakel'а – Дмитрис Дземос (Dimitris Tzemos), он же по совместительству выступает основным майнтайнером KDE-редакции «головного» Salix'а, о которой пойдёт речь в следующем разделе. Текущая версия Slakel'а распространяется в трёх редакция, различающихся рабочими окружениями. Ими являются, с одной стороны, «лёгкие» оконные менеджеры Openbox и Fluxbox, с другой – KDE, самый «тяжёлый» из дектопов. Каждая редакция имеет свою нумерацию релизов: для Openbox-редакции текущие номера 6.X.Y, для Fluxbox-редакции – 1.0. Редакция же с KDE нумеруется в соответствие с номером версии десктопа-эпонима – от первой, kde-4.6.4, до актуальной в момент сочинения этих строк kde-4.10.5. Кроме этого, в каждой редакции имеется по два образа – установочный и «живой», но тоже с возможностью установки. Они именуются как slackel* и slackellive*, соответственно, с добавлением разрядности для 64-битной сборки, имени WM/DE и собственного номера релиза. Причём последние различаются для установочных и Live-образов в «третьем знаке».

Исторически первая редакция Slackel'а, вышедшая в июне 2011 года и соответствовавшая Slackware и Salix 13.37, использовала KDE в качестве десктопа. Редакция с Openbox'ом присоединилась к ней в январе 2013 года. И с этого момента этот дистрибутив основывается на ветке Current родительской системы. А Fluxbox-редакция впервые появилась в августе текущего года, пока только в виде Live-образа.

Slackel, сын Salix'а: *box'овые редакции

Однако рассмотрение Slackel'а я начну с *box'совых редакций, причём с установочных, потому что Live-образы – это отдельная песня, которая будет спета под занавес, после рассказа о KDE-редакциях Slackel'а и Salix'а – они настолько похожи, что их имеет смысл описывать совместно.

Но сначала – несколько слов об инсталляции с установочных образов. Она одинакова для всех редакций и один в один воспроизводит инсталлятор Salix'а, включая три варианта: всё те же CORE, BASIC и FULL. В процессе установки обнаруживается лишь одно отступление от «генеральной линии»: в качестве начального загрузчика в Slackel'е, кроме LILO, предлагается также GRUB 2:

Рисунок 11-14. Выбор начального загрузчика

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

Рисунок 11-15. Здесь можно задать параметры ядра

До недавнего времени в установщике Slackel'а была курьёзная особенность: сначала он предлагал задать пароль root'а, а затем, как и в текущей версии Salix'а, радостно сообщал, что аккаунт администратора не активирован, и предлагал создать простой пользовательский, из которого доступ а административным привилегиям будет осуществляться через sudo. Однако в последней версии Slackel'а это безобразие ликвидировано: аккаунт администратора доступен. Хотя для авторизации при запуске всех общесистемных утилит gksu запускается в режиме sudo (то есть с запросом пользовательского пароля).

После установки и перезагрузки мы видим меню GRUB'а, в котором почему-то фигурирует номер версии Slackware, хотя, как было сказано ранее, современные редакции Slackel'а базируются на ветке Current:

Рисунок 11-16. Меню загрузчика GRUB2

А затем – такое приглашение к авторизации:

Рисунок 11-17. Приглашение к авторизации GDM

Меню загрузчика одинаково для всех редакций, дисплейный менеджер – GDM для обеих *box'осовых редакций. А дальше начинаются разночтения, в зависимости от используемого WM/DE. Для Openbox-редакции, с которой я начну дальнейший рассказ, загруженный рабочий стол выглядит так:

Рисунок 11-18. Openbox-редакция: рабочий стол

Я, конечно, понимаю, что выжженной солнцем и вытоптанной козами Греции к зелёной траве относятся очень трепетно. Но прочитать на её фоне белые буковки, думаю, мало кому удастся. Поэтому я сразу обратился к настройкам Openbox'а, дабы поменять фоновый рисунок. И был несколько ошарашен.

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

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

Ну так вот, настройщики Openbox'а (а их там два) совмещают в себе запутанность и уже полное отсутствие логики (сравнимые только с настройками Unity, да и то только при участии всех её многочисленных твикеров) с бедностью их возможностей, не уступающей GNOME-трёшным (без твикеров).

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

А в остальном, если отрешиться от внешней оболочки, Slackel – тот же Salix в своей консольной части, и почти он же – по набору приложений графического режима. С поправкой на штатные приложения среды, разумеется. Так, в качестве терминала в нём используется Sakura (вполне приятный терминал, не хуже других, хотя и не лучше), файловым менеджером выступает поминаемый ранее SpaceFM, из редакторов присутствуют Leafpad и Geany, из офисных пакетов – AbiWord и Gnumeric.

В общем, отцовские заветы типа «одна задача – одно приложение», и по возможности «лёгкое», Slackel выполняет неукоснительно. Но, как я уже сказал, оконный менеджер Openbox в нынешнем его виде меня ни разу не вдохновил. А Fluxbox я некогда активно применял и даже любил. Так что при первой возможности ознакомился и с этой редакцией.

Как я уже сказал, она пока существует только в виде Liv-образа, об инсталяторе которого речь пойдёт позднее. А в установленном виде она выглядит, как и все прочие редакции Slackel'а от Дмитриса Дзевоса (Dimitris Tzemos), с поправкой на панели и менюшки рабочего стола:

Рисунок 11-19. Fluxbox-редакция: рабочий стол с окном терминала

С первого взгляда даже трудно поверить, что перед нами потомок легендарного Blackbox'а, издревле прославленного своей элегантностью. – настолько он похож на Openbox и порождённую им среду LXDE. Особенно возмутила меня кнопка главного меню на управляющей панели, что является позорным и преступным отступлением от *box'овых традиций.

Да и базовые приложения в основном заимствованы из LXDE. Так, терминальное окно на предыдущем скриншоте – это действительно LXDE Terminal. И в данной сборке у него действительно нет ни строки заголовка, ни элементов управления окном. Масштабированию оно не поддаётся, и переместить его никуда нельзя, можно только закрыть.

Зато настройки рабочего стола, на первый взгляд, сделаны в стиле *box'ов – из контекстного меню по правому клику, в виде смены стилей Fluxbox'а:

Рисунок 11-20. Fluxbox-редакция: смена стиля рабочего стола

Через то же самое меню, казалось бы, можно изменить фон рабочего стола:

Рисунок 11-21. Fluxbox-редакция: изменить фон? А вот фигушки!

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

Рисунок 11-22. Fluxbox-редакция: Параметры рабочего стола в главном меню

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

Рисунок 11-23. Fluxbox-редакция: внешний вид рабочего стола

Находятся эти файлы в каталоге /usr/share/wallpapers. Правда, «находятся» – это сказано громко: никакой альтернативы «греческому полю» не предлагается, и отключить вывод обоев нельзя – можно только удалить соответствующий файл:

$ sudo rm /usr/share/wallpapers/slackel.png

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

Рисунок 11-24. Fluxbox-редакция: Значки рабочего стола

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

Рисунок 11-25. Fluxbox-редакция: рабочий стол как домашний каталог

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

$ LANG=C xdg-user-dirs-update --force

Внимание – опция принудительного переименования каталогов здесь обязательна. После чего следует удалить прежние каталоги с кириллическими именами – и рабочий стол Fluxbox'а будет выглядеть в соответствие с выбранным цветом фона (см. рис. 11-23):

Рисунок 11-26. Fluxbox-редакция: рабочий стол после настроек

Это удобно, особенно если велеть файловому менеджеру (в этом амплуа здесь выступает PCManFM) открывать каталоги одним кликом:

Рисунок 11-27. Fluxbox-редакция: настройка файлового менеджера

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

Больше никаких особых настроек среды через графические «морды» не обнаруживается. Это не значит, что их нет: Fluxbox можно очень тонко настроить прямым редактированием конфигурационных файлов. И вообще, в целом Fluxbox мне понравился больше своего Open-собрата – не смотря на крамольную кнопку главного меню.

Slackel и Salix: KDE-редакции

Если MATE-редакция Salix'а – самая молодая в этом дистрибутиве, то его ипостась с KDE, напротив, принадлежит к числу старейших: как было сказано в главе первой, она появилась уже во втором релизе – том, что имел номер 13.1 и появился на свет в октябре 2010 года. Что же до Slackel'а, то его первая KDE-редакция (она же – первая версия этого дистрибутива вообще) появилась в июне года 2011, и развивалась явно под влиянием Salix'а. Хотя ныне скорее имеет место обратная картина. Так, KDE-редакция релиза текущего, 14.1, с апреля месяца пребывает в статусе 1-й беты. Аналогичная же версия Salix'а, slackel-kde-4.10.5, то она датируется аж мартом нынешнего года. Основной майнтайнер KDE-редакций в обоих дистрибутивах один и тот же – Дмитрис Дзевос, и, видимо, он больше внимания уделяет собственному дистрибутиву, а «общему делу» достаётся по остаточному принципу.

Как уже сказано, установка всех редакций обоих дистрибутивов протекает совершенно одинаково, с той лишь разницей, что в Slackel'е запрашивается пароль root'а и предлагается выбор загрузчика – LILO или GRUB. В установленном по варианту FULL виде различий между KDE-редакциями тоже не много. В дистрибутив-специфических аспектах и Salix, и Slackel с KDE отлича.тся от Salix'а с Xfce не больше, чем самурай с тати отличается от самурая с катаной. В обоих случаях присутствует комплекс специфичных для Salix системных утилит, объединённых в пакеты salixtools и salixtools-gtk, с текстовым и графическим интерфейсами, соответственно. Разумеется, и в той, и в другой системе не обошлось без сладкой парочки консольных утилит slapt-get и slapt-src, дополняемых не менее сладкими Gslapt и Sourcery с интерфейсом графическим. И хотя и та, и другая из графических «мордочек» основана на библиотеках Gtk, но в KDE-среду вписываются без внутреннего отторжения.

Более того, обе KDE-редакции не слишком отличаются и от самурая без меча... то есть, пардон, от Salix в инсталляции CORE. За исключением того, что в последней меча, то есть десктопа, нет вообще. Но самурайский-то дух от наличия меча. не зависит. По крайней мере, говорят, что так обстоит дело у настоящих самураев. А в настоящих дистрибутивах он не зависит от наличия десктопа...

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

Так, из пакета kde-baseapps-lite, что в собственном репозитории Slackel'а (а именно этот пакет определяет своеобразие KDE-редакции дистрибутива) выпилен даже традиционный Konqueror в обеих своих ипостасях (и файлового менеджера, и браузера). В роли файлового менеджера остался один Dolphin, а браузером работает... нет, даже не rekonq, а обычный FireFox. Кроме того, из пользовательских приложений имеются только Konsole и KWrite с Kate:

Рисунок 11-28. KDE-редакция Slackel'а: меню после установки BASIC

Рисунок 11-29. KDE-редакция Slackel'а: базовые приложениями

В KDE-редакции Salix'а тоже не найти ни малейших следов Konqueror'а. Здесь мы видим те же самые Konsole, Dolphin и Kate:

Рисунок 11-30. KDE-редакция Salix'а: Konsole

Рисунок 11-31. KDE-редакция Salix'а: Dolphin

Рисунок 11-32. KDE-редакция Salix'а: Kate

Неожиданным оказался выбор браузера. В Salix с KDE эта ниша оказалась занята не Firefox'ом, ни даже Rekonq'ом, а некоей Qupzilla, которой я раньше не то что не видел, но о которой даже и не слышал. Кстати, браузер этот (основанный на Qt, без использования библиотек KDE) был вполне приятен видом:

Рисунок 11-33. KDE-редакция Salix'а: браузер Qupzilla

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

Как в Salix'е, так и в Slackel'е KDE-редакции содержат набор инструментария для разработки Qt-приложений, это их родовая черта:

Рисунок 11-34. KDE-редакция Salix'а: набор Qt-инструментария

Рисунок 11-35. Он же в KDE-редакции Salix'а

Думаю, излишне упоминать, что в обоих случаях и Nepomuk ещё никуда не делся, и искоренить его не получится – для этого нужно ждать версии 4.13 (или выше), которой для этих дистрибутивов нет (и, похоже, не предвидится). В результате, не смотря на почти полное отсутствие пользовательских приложений (а кроме перечисленных, их действительно нет), KDE-редакции и Salix'а, и Slackel'а после установки по варианту BASIC заняли одни и те же 3,3 ГБ.

Salix и Slackel: установка с LiveCD, или проще некуда

Вот уже десять лет минуло с той поры, как по миру Open Source начали ходят жизнеутверждающие сказания о фантастически простой установке Ubuntu – в пять мышиных кликов. И около двадцати лет шёпотом и в темноте пересказывают очень страшные истории о том, как сложно устанавливать Slackware. Как и все мифы и легенды, опровергнуть их очень трудно. Но я всё же попытаюсь – на примере установки дистрибутивов Salix и Slackel с Live-носителей – причём любых их редакций, таковые имеющих. А имеют их все их редакции, кроме «командорской», с Xfce, и идеологически ближайшей к ней редакции MATE.

Если мы загрузим Salix или Slackel с любого из Live-носителей, то после старта «живой» системы на рабочем столе и в главном меню обнаружится пиктограмма, предназначенная, как следует из подписи к ней, для запуска инсталлятора. Например, в KDE-редакции slackellive это выглядит так:

Рисунок 11-36. Пиктограмма для запуска инсталлятора

После щелчка на ней будет запрошен пароль – в случае Salix'а пользовательский (one), в случае Slackel'а – root'овый (live). И после его ввода в обоих случаях откроется очень похожее окно инсталлятора:

Рисунок 11-37. Live-инсталлятор Salix'а

Рисунок 11-38. Live-инсталлятор Slackel'а

Окно инсталлятора невидимой вертикальной линией поделено на две части. Левая предназначена для копирования live-системы на USB-носитель (или SD-карту, не имеет значения). О ней мы говорить не будем – то же самый результат быстрей и проще достигается прямой записью образа с помощью команды dd, и имеет смысл только в том случае, если в качестве загрузочного носителя использовался DVD-диск.

А вот правая часть – наш случай. Здесь можно видеть имя целевого носителя (в обоих примерах – /dev/sda1) и боксик, отмеченный по умолчанию (что предписывает установку LILO в его MBR). Если на диске в машине имеется более одного раздела, целевое устройство можно поменять – нужно только помнить, что его содержимое будет уничтожено. Если диск не размечен (или нуждается в переразметке) – следует нажать кнопку Partitions, которая вызовет самый обычный GParted. И с помощью последнего создать раздел нужного размера (скажем, гигабайт 10-15) – он будет корнем файловой иерархии.

Ломать голову над файловой системой для корня не нужно – всё равно раздел будет переформатирован в ext4. Как не нужно думать о разделах под какие-либо ещё ветви файлового древа, вроде /home – они при установке будут проигнорированы. Но если они нужны – ими вполне можно будет заняться и потом, после инсталляции системы. Сейчас достаточно факта наличия раздела под корень – причем любого, в стиле MBR или GPT, первичного или логического.

Теперь следует заполнить обязательные поля в нижней части окна. Для Salix'а это имя пользователя и его пароль (root'а, как мы помним, в этом дистрибутиве нет). А в Slackel'е, как мы помним по предыдущим разделам этой главы, он есть. И потому для него пароль также нужно задать. Во всех случаях пароль, для контроля правильности ввода, можно сделать видимым – если, конечно, за спиной не стоит классовый враг с его звериным оскалом.

После этого смотрим на нижнюю строку с радиокнопками, соответствующими вариантам установки – core, basic и full. И хладнокровно её игнорируем: вне зависимости от выбора, установка пройдёт в режиме full. То есть содержимое live-системы будет просто перенесено на целевой раздел винчестера (или SSD). Поэтому нажимаем длинную кнопку с надписью Install live system – и идём курить или, скажем, заваривать чай: ни на что большее времени не хватит. Потому что по возвращении пред нами предстанет такая картина:

Рисунок 11-39. Завершение Live-инсталляции Salix'а

Рисунок 11-40. Завершение Live-инсталляции Slackel'а

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

Ну как, очень сложно? Хотелось бы ещё проще? А не получится – проще просто некуда. Это вам не пять марковских кликов – это фактически установка в один мышиный писк. После которой на выходе получается полноценная рабочая среда – KDE, Openbox или Fluxbox с набором приложений, как я уже сказал, соответствующим варианту FULL. Разумеется, этот способ установки подходит далеко не для всех случаев жизни. Но есть и немало ситуаций, когда он близок к оптимуму.

Глава 12. Разные мелкие полезности

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

Искоренение кириллицы из домашнего каталога

В случае выбора русской локализации Salix'а и Slackel'а в домашнем каталоге пользователя, в соответствие со стандартом freedesktop.org, самопроизвольно возникают подкаталоги с кириллическими именами – Загрузки, Документы, Видео, и так далее. Тем, кто активно пользуется CLI для всякого рода файловых операций и тому подобных действий, это доставляет немало неудобств, заставляя в иксовых эмуляторах треминала постоянно переключать раскладку клавиатуры. А в «голой» консоли есть риск поначалу вообще увидеть квадратики вместо русских букв.

Так что искоренение каталогов с русскими именами – не проявление русофобии, а для многих – практическая необходимость. Благо делается это очень просто – одной командой:

$ LANG=C xdg-user-dirs-update --force

Вместо LANG=C можно указать LANG=POSIX или LANG=en_US, это одно и то же. Причём желательно дать эту команду сразу после инсталляции системы, пока в кириллические каталоги не попали какие-либо файлы, например, скачанные из сети материалы (в браузерах по умолчанию обычно установлено сохранение загрузок в каталоге ~/Загрузки) или скриншоты (экранные снимки, сделанные нажатием клавиши PrintScreen, без дополнительных настроек попадают в каталог ~/Изображения). Потому что приведённая команда не переименовывает каталоги, а создаёт параллельно кириллическим их аналоги латиницей – ~/Desktop, ~/Documents, ~/Images, и так далее. Так что русскоязычные каталоги проще удалить пустыми, нежели думать о копировании их содержимого.

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

Доводка консольного режима: включение мыши в консоли

В Salix'е по умолчанию не включена служба консольной мыши – gpm, хотя сам по себе одноимённый пакет присутствует во всех вариантах установки всех редакций Salix'а. А поскольку без мыши в консоли жить очень скучно, службу эту нужно активизировать. Для чего получаем перманентные права root'а – они будут нужны всё время:

$ sudo -i

Переходим в каталог /etc/rc.d/ (не обязательно, но потом потребует меньше телодвижений), создаём в нём файл

# touch rc.gpm

и делаем его исполняемым:

# chmod a+x rc.gpm

А затем в любимом текстовом редакторе (например, в nano) вписываем в него такие строки:

#!/bin/sh # Start/stop/restart the GPM mouse server: export TEXTDOMAIN=slackware . gettext.sh

if [ «$1» = «stop» ]; then gettext «Stopping gpm..." echo /usr/sbin/gpm -k elif [ «$1» = «restart» ]; then gettext «Restarting gpm..." echo /usr/sbin/gpm -k sleep 1 /usr/sbin/gpm -m /dev/mouse -t imps2 else # assume $1 = start: gettext «Starting gpm:" echo «/usr/sbin/gpm -m /dev/mouse -t imps2" /usr/sbin/gpm -m /dev/mouse -t imps2 fi

Строки эти были нагло потибрены из соответствующего файла оригинальной Slackware – там, если соглашаться с умолчаниями инсталлятора, служба gpm включается автоматически. И тут впору пожалеть, что в Salix'е она ещё не работает – иначе эти строки были бы просто выбелены мышью и вставлены в текст щелчком средней кнопки.

Опция -t описывает протокол работы мыши – и, насколько я знаю, подходит для всех ныне существующих устройств этого класса, кроме, возможно, каких-то трекболов и трекпойнтов. Теперь после рестарта машины курсор мыши в виде прямоугольника появится во всех виртуальных консолях (а в Salix'е их всего три). Однако можно не дожидаться перезагрузки, а запустить службу gpm немедленно, командой

# /etc/rc.d/rc.gpm

После этого можно начать доведение до ума консольного режима, имея в руках такое мощное оружие, как мышиный copy and paste.

Доводка консольного режима: русификация вывода

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

$ localeLANG=ru_RU.utf8 LC_CTYPE="ru_RU.utf8"LC_NUMERIC="ru_RU.utf8" LC_TIME="ru_RU.utf8" LC_COLLATE=C LC_MONETARY="ru_RU.utf8" LC_MESSAGES="ru_RU.utf8" LC_PAPER="ru_RU.utf8" LC_NAME="ru_RU.utf8" LC_ADDRESS="ru_RU.utf8" LC_TELEPHONE="ru_RU.utf8" LC_MEASUREMENT="ru_RU.utf8" LC_IDENTIFICATION="ru_RU.utf8" LC_ALL=

И, следовательно, вывод команд, где это возможно, должен выводиться по русски. Например, на команду

$ date

Должно последовать такое:

Cp мaй 7 17:01:36 MSK 2014

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

За загрузку консольных шрифтов отвечает файл rc.font из того же каталога /etc/rc.d. Сразу после установки она содержит единственную строку:

unicode_start ter-v16n

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

setfont -v ter-v22b

где -v – опция, обеспечивающая вывод сообщения о загрузке шрифта, а ter-v22b – имя шрифтового файла. Все файлы шрифтов содержатся в каталоге /usr/share/kbd/consolefonts, но не все имеющиеся там шрифты содержат символы кириллицы. Шрифты семейства Terminus – содержат, и к тому же имеются всех мыслимых размеров (от 8x12 до 12x32, так что каждый может подобрать размер по глазам), двух шрифтоначертаний (для LCD-мониторов рекомендуется полужирное – отсюда литера b в имени файла), да ещё и включают таблицу перекодировки внутреннего 16-битного представления во внешнее 8-битное.

Сделанного достаточно, в чём легко убедиться, запустив rc.font на исполнение, которое, благодаря опции -v, выведет на экран такое сообщение:

3aгpyжaeтcя 512-cимвoл шpифтa 11x22 из фaйлa /usr/share/kbd/consolefonts/ter-v22b.psf.gz3aгpyжaeтcя юниĸoднaя тaблицa oтoбpaжeния...

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

Ещё раз повторяю: никаких дополнительных телодвижений, которые можно встретить в сетевых описаниях, типа старта/стопа режима unicode, загрузки карты соответствия и вывода на все консоли так называемой «магической последовательности», ныне не нужно. Разве что что при использовании старых шрифтов, без собственной карты – но нынче в них нет ни малейшей необходимости: шрифты семейства Terminus покрывают почти все потребности применителей. Ну а тем, которые с претензиями, остаются ещё и шрифты типа LatArCyrHeb, LatGrkCyr и LatKaCyrHeb (между нами говоря, вполне уродливые, но зато содержащие символы не только латиницы и кириллицы, но и некоторых более иных алфавитов).

Теперь для полноты счастья остаётся только обеспечивать и ввод символов кириллицы – например, чтобы комментировать свои конфиги и скрипты на языке родных осин. Этим делом ведает файл /etc/rc.d/rc.keymap, который по умолчанию выглядит так:

#!/bin/sh# Load the keyboard map. More maps are in /usr/share/kbd/keymaps. if [ -x /usr/bin/loadkeys ]; then /usr/bin/loadkeys -u us fi

Здесь достаточно заменить английско-американскую раскладку us на любую подходящую кириллическую, список которых можно просмотреть так:

$ ls ls /usr/share/kbd/keymaps/i386/qwerty/ru*

Например, на такую:

if [ -x /usr/bin/loadkeys ]; then /usr/bin/loadkeys -u ruwin_cplk-UTF-8

Это русская раскладка для кодировки UTF-8, соответствующая варианту winkeys из Иксов, с переключением латиница/кириллица клавишей CapsLock. Тем же, кто когда-то учился печатать на пишущей машинке, и так и не смог привыкнуть к маразму под названием «вариант winkeys», могу предложить мою раскладку, соответствующую иксовому варианту Typewrite Legacy – ru-type-legacy_cplk-UTF-8. Соответственно, вторая строка в rc.keymap приобретут такой вид:

/usr/bin/loadkeys -u ru-type-legacy_cplk-UTF-8

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

Thunar и архивы

Описанная ниже проблемка возникает, вероятно, только при базовой установке Salix'а – в установке FULL всё необходимое имеется по умолчанию.

Чтобы просматривать, распаковывать и создавать архивы через файловый менеджер Thunat требуется, во-первых, плагин к нему – thunar-archive-plugin. По умолчанию он не устанавливается, так что:

$ sudo slapt-get -i thunar-media-tags-plugin

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

Просмотр каталога /usr/libexec/thunar-archive-plugin показал, что подходящим менеджером архивов может быть Ark, Engrampa или File-roller. Последнего в репозитории не обнаружилось, Ark – менеджер архивов для KDE и здесь явно не к месту, так что оставался один вариант – Engrampa, менеджер архивов для MATE. Каковой я и установил:

$ sudo slapt-get -i engrampa

После чего содержимое архивов через Thunar стало просматриваться, а указанные выше пункты контекстного меню заработали. Разумеется, для тех типов архивов, для которых установлены утилиты управления. Правда, по умолчанию имеются почти все необходимые – tar, xz (это формат сжатия пакетов Slackware), gzip, bzip2, cpio, zip, unrar и ещё какие-то. На всякий пожарный я доустановил только p7zip. Пакета для создания rar-архивов не обнаружилось, но при необходимости его можно создать из slackbuilds – slapt-src показывает его наличие. У меня, впрочем, такой необходимости пока не возникло ни разу (за последние десять или пятнадцать лет).

Thunar и права root’а

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

Благо, сделать это в Thunar'е не просто, а очень просто, без установки каких-либо дополнительных плагинов – достаточно обратиться к пункту его главного меню Правка -> Особые действия, отвечающему за дополнительные пункты меню контекстного, вызываемого щелчком правой кнопки мыши. По умолчанию в этом меню всего один дополнительный пункт – Открыть терминал:

Рисунок 12-1. Thunar: особые действия

И одну запись можно видеть в панели настройки особых действий:

Рисунок 12-2. Пример особого действия: открыть терминал

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

Рисунок 12-3. Создание нового действия

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

Рисунок 12-4. Условия особого действия

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

Рисунок 12-5. Пример особого действия: редактирование файла от root'а

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

Рисунок 12-6. Выбор пиктограммы для нового действия

Во второй же вкладке сохраняем шаблон и отметку на текстовых файлах, как оно было по умолчанию.

Далее создаём пункт открытия каталога в Thunar'е от лица суперпользователя. Здесь всё столь же очевидно:

Рисунок 12-7. Редактирование действия: название, описание, команда

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

Рисунок 12-8. Редактирование действия: в контекстном меню для каталогов

И последнее – это открытие root'ового терминала:

Рисунок 12-9. Терминал с правами root'а

Здесь условием появления также будет каталог.

После этого контекстное меню при фиксации на имени файла приобретёт такой вид:

Рисунок 12-10. Контекстное меню для файла

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

Рисунок 12-11. Контекстное меню для каталога

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

Рисунок 12-12. Панель авторизации gksu

После чего соответствующая программа (Thunar, текстовый редактор или терминал) будут открыты с правами администратора.

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

И по секрету добавлю, что того же результата можно добиться прямым редактированием файла ~/.config/Thunar/uca.xml, во-первых. А во-вторых, список особых действий не сводится к перечисленным, а ограничен только потребностями и фантазией применителя.

Thunar и поиск файлов

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

Первое из таких средств – утилита Catfish, которая обнаруживается в системе после полной инсталляции Salix'а. А при выборе базовой установки её легко добавить посредством

$ sudo slapt-get -i catfish

Утилита Catfish – нечто вроде интегратора таких команд, как find (задействована по умолчанию), locate, slocate и любых других «искателей». Как её можно прикрутить к Thunar'у? С помощью всё того же волшебного пункта Правка -> Особые действия, добавив её вызов в контекстное меню. Для чего заполняется такая форма:

Рисунок 12-13. Редактированиедействия: Поиск

В качестве условия появления отмечается боксик Каталоги.

Утилита Catfish – средство достаточно гибкое и мощное, но несколько громоздкое для поиска «на скорую руку», когда необходимость отыскать некий файл неожиданно возникает при просмотре файловой иерархии. Кроме того, в ней не предусмотрено поиска по содержимому файлов. Поэтому в ряде случаев удобнее воспользоваться утилитой mate-search-tool из пакета mate-utils. Правда, он потянет за собой ряд компонентов декстопа MATE (включая даже mate-desktop). Но от фанатичного пуризма мы ведь давно избавились, не так ли? Если избавились – устанавливаем именованный пакет:

$ sudo slapt-get -i mate-utils

А затем встраиваем mate-search-tool в контекстное меню Thunar'а:

Рисунок 12-14. MATE Search меню Thunar'а

После чего отыскиваем в текущем каталоге нужный файл по его имени или маске:

Рисунок 12-15. MATE Search: поиск по маске имени

А дополнительно – и по входящему в него фрагменту текста:

Рисунок 12-16. MATE Search: поиск по тексту

Хотя, если честно, мне обычно в большинстве случаев проще воспользоваться пунктов Открыть терминал из контекстного меню, а далее – утилита find в руки. Или, при необходимости, grep – особенно в сочетании со встроенными средствами поиска оболочки zsh и её глобальными псевдонимами, Но это – совсем другая история, в которой Thunar'а можно совсем не давать...

Thunar и Яндекс.Диск

Клиент Яндекс.Диска для Linux существует, насколько я знаю, только в rpm- и deb-виде, то есть в формат Salix'а не вписывается. Конечно, есть подозрение, что с помощью утилиты rpm2tgz первый можно привести к виду, пригодному для установки в Slackware и её дериватах, и что, будучи установленным, он ещё и заработает. Однако подозрение не есть уверенность, да и не стоит этот клиент возни, ибо показался мне неудобным. Так что проще получить доступ к Яндекс.Диску через стандартный WebDAV, благо такая возможность имеется.

Делается это действительно просто: запускается Thunar, через закладку боковой панели открывается Обзор сети и в адресной строке вместо нечленораздельного network:/// вписывается вот это:

davs://username@webdav.yandex.ru/

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

Шпаргалки по установке пакетов: gThumb

В Salix'в качестве штатного вьювера графических файлов применяется Viewnior (а не Risretto, как я почему-то думал раньше), которую можно обнаружить в пункте Графика главного меню Xfce после полной инсталляции. Это замечательно простая и быстрая программа, имеющая даже некоторые функции редактирования – в частности, кадрирования изображений. Кроме того, она позволяет подключать и внешний графический редактор для более тяжёлых работ (по умолчанию – GIMP). Однако у неё нет таких важных для любого линуксописателя функций, как коррекция яркости/контрастности, а главное – масштабирования изображений. Согласитесь, что применять для этих целей GIMP несколько неоправданно.

Я с давних пор привык использовать во всех Gtk-системах программу gThumb. Она тоже в первую очередь предназначена для просмотра изображений, однако наделена теми самыми функциями, которых не хватает Viewnior'у. И потому сразу после первой установки Salix'а занялся её поисками. В репозитории бинарников gThumb не обнаружился, зато легко нашёлся в списке штатных слакбилдов:

$ slapt-src --search gthumb gthumb:3.2.4 - gThumb ( An image viewer )

Однако собрать этот пакет сразу командой slapt-src не получится – она пожалуется на отсутствие пакета itstool, каковой, напротив имеет своим местопребыванием репозиторий бинарников:

$ slapt-get --search itstool itstool-1.2.0-x86_64-1 [inst=нет]: itstool (Translate XML documents with PO files) itstool-2.0.2-noarch-1gv [inst=нет]: itstool (Translate XML documents with PO files)

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

$ sudo slapt-get -i itstool

После которой управитель пакетов разберётся сам (по секрету скажу, что он установит itstool-2.0.2-noarch-1gv). И теперь команда

$ sudo slapt-src --search gthumb

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

Шпаргалки по установке пакетов: GPRename

В жизни каждого линуксописателя наступает момент, когда он сталкивается с необходимостью переименования большого количества файлов по какой-то определённой модели. Особенно актуально это при массовом изготовлении скриншотов для иллюстрирования очередной статьи. Ибо традиционные скриншоттеры часто дают своим файлам имена вроде Снимок экрана - 25.04.2014 - 15:39:52.png. Которые хорошо бы превратить в что-то типа [название статьи]-[номер рисунка].png.

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

Одна из таких утилит, thunar-bulk-rename, представляет собой дополнение к одноимённому файловому менеджеру (в «головном» Salix'е оно установлено по умолчанию). Она проста в использовании и для указанных задач вполне эффективна. Однако в других редакциях дистрибутива её нет – и там целесообразно использовать утилиту GPRename: она не привязана к среде Xfce, да и возможностей к неё несколько больше, хотя применение – несколько сложнее.

В штатном репозитории Salix'а пакета с таким именем нет. Зато он обнаруживается среди его слакбилдов:

$=> slapt-src --search gprename gprename:5 - GPRename (A GTK2 batch renamer for files and directories)

Так что дело за малым – собрать его:

$=> sudo slapt-src -i gprename Следующие пакеты будут установлены: gprename Следующие зависимые слакбилды будут собраны и установлены: perl-libintl Продолжить? [y/N]

Приятно, что в данном случае зависимости пакета не приходится выискивать – они предлагаются к установке автоматом. И с этим предложением нужно просто согласиться. После чего программу можно вызвать из главного меню: Инструменты -> GPRename.

Шпаргалки по установке пакетов: Chromium

Единственным штатным браузером, устанавливаемых в ходе развёртывания системы, в Salix'е является Midori, медленный, мало функциональный и работающий часто, мягко говоря, не без нареканий. Правда, пользоваться им никто не неволит – в репозитории дистрибутива имеется FireFox, который без проблем устанавливается стандартным образом.

А вот Chromium'а нет ни в официальном репозитории бинарников, ни в списке штатных слакбилдов. Однако из этой ситуации есть два выхода: сложный и простой. Первый – зайти на величайший в мире слакбилдник SlackBuilds.org, где он легко находится поиском, а затем:

      • скачать архив слакбилда chromium.tar.gz в подходящий каталог, типа /tmp или куда-нибудь в свой домашний;

      • распаковать архив – после этого там образуется подкаталог path2/chromium;

      • скачать в этот подкаталог архив исходников – в данном случае chromium-31.0.1650.57.tar.xz;

      • присвоить файлу path2/chromium/chromium.SlackBuild бит исполнения:

$ sudo chmod a+x chromium.SlackBuild

      • проверить, установлен ли пакет yasm и если нет (а по умолчанию его нет) – установить из репозитория:

$ sudo slapt-get -i yasm

      • запустить слакбилд на исполнение:

$ sudo ./chromium.SlackBuild

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

Завершится сборка сообщением, что

Slackware package /tmp/chromium-31.0.1650.57-x86_64-1_SBo.tgz created.

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

$ sudo installpkg chromium-31.0.1650.57-x86_64-1_SBo.tgz

А затем новый браузер можно запустить из главного меню Xfce через Интернет -> Chromium.

Однако если избытка времени или терпения ждать нет, можно прибегнуть к простому способу: зайти на блог Эрика Хамелирса (Eric Hameleers), не менее известного как AlienBOB, или открыть его репозиторий. Где имеются регулярно обновляемые бинарнки Chromium'а, а также ещё много чего полезного, в частности, сборки LibreOffice и собственные разработки автора.

Шпаргалки по установке пакетов: Мультимедиа

Рецепт этой шпаргалки потребуется при установке Salix'а в варианте BASIC – в варианте FULL необходимости в большинстве описанных ниже действий не возникнет.

Для начала надо заметить, что ни малейшего Pulseaudio в Salix'е нет – управление звуком осуществляется через Alsa, и все необходимые для того пакеты в базовой установке присутствуют по умолчанию, остаётся только установить микшер:

$ sudo slapt-get -i xfce4-mixer

После этого я установил mplayer2, поскольку он, по сравнению со своим предком, просто mplayer'ом, развивается более активно:

$ sudo slapt-get -i mplayer2

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

$ mplayer parh2/filename

или даже

$ mplayer parh2/*.mp3|*.flac

При желании к нему можно подобрать в официальном репозитории графический фронт-энд – gnome-mplayer или smplayer. Первый показался мне более уместным в Gtk-системе, нежели второй, основанный на Qt. А с точки зрения функционала, при моих скоромных потребностях в этом плане, разница между ними не заметна.

Шпаргалки по установке пакетов: выпадающий терминал Tilda

Некогда, с подачи Сергея Голубева, проникся я идеей выпадающих (drop-down) терминалов – тогда в виде Yakuake, ибо работал преимущественно в среде KDE. Проникся настолько, что почти перестал применять обычный эмулятор терминала: практически во всех случаях удобней оказывалось прибегнуть либо к терминальному окну, встроенному в файловый менеджер или текстовый редактор, либо вызвать терминал выпадающий.

Переключившись на рабочие среды, основанные на Gtk (Xfce, Unity, Cinnamon), я начал подыскивать аналогичные средства эмуляции терминального режима. Увы, с терминалами, встроенными в файловые менеджеры, оказалось плохо: плагины для Nautilus'а и Nemo или не работали, или выглядели отвратительно, а для Thunar'а таковых не имелось вообще. Зато с выпадающими терминалами выбор имелся – я опробовал Terra и Guake, в конце концов остановившись на последнем.

Начиная «погружение в Salix» с его средой Xfce по умолчанию, я был уверен, что в шесть секунд найду какой-нибудь «выпадающий» аналог. Не тут-то было: в репозиториях бинарных пакетов не обнаружилось ни одного знакомого имени, а среди слакбилдов имелись Yakuake (который, принадлежа среде KDE, совсем не гармонировал с «головной редакцией» дистрибутива) и YeahConsole, который сам по себе не столько терминал, сколько оболочка для таких программ, как XTerm, rxvt и так далее.

И тогда я вспомнил, что в одном из обсуждений темы выпадающих терминалов на Джуйке упоминался drop-down терминал Tilda, до которого у меня тогда руки так и не дошли. Наудачу набрав его имя в команде

$ slapt-src -s tilda

я с радостью обнаружил наличие его слакбидла:

tilda:0.9.6 - tilda (an FPS-style terminal)

Каковой и был немедленно установлен:

$ sudo slapt-src -i tilda

При первом запуске из главного меню Xfce (он попал в раздел Инструменты) появилась панель его конфигурирования:

Рисунок 12-17. Tilda: основные нсатройки

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

Во вкладке Внешний вид можно не только задать размеры терминального окна, но и его центирирование – не только по горизонтали, но и по вертикали. Если при этом ещё и включить анимацию, выпадающий терминал превращается в терминал «всплавающий» посреди экрана:

Рисунок 12-18. Tilda: настройка внешности

А во вкладке Сочетание клавиш устанавливается способ вызова терминала – по умолчанию почему-то это клавиша F1. Что я немедленно заменил на стандартную для программ такого рода клавишу F12:

Рисунок 12-19. Настройка вызова

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

Рисунок 12-20. Tilda: вид после запуска

Теперь остаётся только обеспечить её автозапуск, например, через главное меню: Настройки -> Сеансы и запуск -> Автозапуск приложений:

Рисунок 12-21. Tilda: внесение в автозапуск

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

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

   • Shift+Control+T – создание новой вкладки;

   • Shift+Control+W – закрытие текущей вкладки;

   • Control+PageUp – переход на предыдущую вкладку;

   • Control+PageDown – переход на следующую вкладку;

   • Shift+Control+C – копирование выеделнного фрагмента в буфер;

   • Shift+Control+V – вставка содержимого буфера позицию курсора;

   • Shift+Control+Q – выход из Tilda.

На этом функционал программы исчерпывается. Нельзя ни перемещать вкладки, ни давать им произвольные имена (например, нумеровать), нет возможности расщепления терминального окна. Однако свои основные функции – представить интерфейс командной строки в нужном месте и в нужное время, Tilda выполняет исправно и к тому же быстро.

Шпаргалки по установке пакетов: VirtualBox

Виртуальная машина входит для меня в категорию «необходимого и достаточного». С давних пор я привык использовать в этом качестве VirtualBox. Однако в официальном репозитории Salix'а его не обнаружилось, а версия из его же слакбилдов рассчитана только на 32-битные системы. Так что остаётся официальный сайт проекта, где и версия его обычно более новая. Правда, среди Linux-хостов среди представленных дистрибутивов пакета именно для Slackware не оказалось. Тем не менее, я решил, что в этом качестве должен сгодиться All distributions, версию которого для 64-битной архитектуры и скачал.

Дальше – всё как всегда, и как всегда очень просто. Сначала скачанному файлу надо придать бит исполняемости:

$ chmod a+x VirtualBox-4.3.10-93012-Linux_amd64.run

А затем эту исполняемость претворить в действительность:

$ sudo ./VirtualBox-4.3.10-93012-Linux_amd64.run

Обращая внимание на форму аргумента – в Salix'е по традиции текущий каталог не числится в умолчаниях значений переменной PATH ни пользователя, ни root'а.

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

Интерфейс Virtualbox'а основывается на библиотеке Qt, поэтому при первом запуске в среде Xfce он выглядит вполне отвратительно. Что исправимо легко: Главное меню -> Настройки -> Qt4 config, где для Qt-приложений устанавливается стиль, соответствующий настройкам рабочего стола Xfce. После чего Virtualbox выглядит так же, как и все остальные программы для этой среды.

Шпаргалки по установке пакетов: Komodo Editor

Полюбив с недавних пор Komodo Editor (далее – KE), применяемый в Mint'е, я озаботился его установкой и в Salix'е.Поиск готового пакета в репозиториях Salix'а и среди его Slackbuild'ов успехом не увенчался. Не обнаружился KE и ни в одном из дополнительных репозиториев для Slackware и её клонов (их список – в приложении). Однако оставался вариант установки бинарного пакета с официального сайта. Благо процесс этот прост и включает получение архива, распаковку его в любой временный каталог и запуск установочного сценария от имени пользователя или, как сделал я, администратора:

$ sudo ./install.sh

Благодаря последнему моменту при выборе каталога для установки KE есть возможность поместить его в /opt/Komodo-Edit-8.5.4/. Затем находится его исполняемый файл – /opt/Komodo-Edit-8.5.4/lib/mozilla/komodo (/usr/local/bin/komodo – символическая ссылка на него). И создаётся ещё один симлинк на него:

$ sudo ln -s /opt/Komodo-Edit-8.5.4/lib/mozilla/komodo /usr/local/bin/komodo

После этого KE под именем Editor самопроизвольно появяется в секции Разработка главного меню Xfce, откуда и запускается в последующем.

Для запущенного KE можно первым делом выполнить его русификацию его интерфейса. Пакет русификации усилиями Labogrado собран в виде расширения для KE — файла localru-*-ko.xpi, который и следует скачать с сайта автора – нужно только проследить, чтобы версия пакета соответствовала версии KE.

Установка русификатора выполняется через меню KE: Tools -> Add-ons, что вызывает такую панель:

Рисунок 12-22. Komodo Editor: панель дополнений

Слева от поля для поискового запроса можно видеть кнопку весьма бледного вида, которая вызывает каскадное меню – в нём нужно выбрать пункт Установить дополнение из файла:

Рисунок 12-23. Komodo Editor: выбор источника дополнений

А по выборе нужного файла в следующей панели нажимается кнопка Install Now:

Рисунок 12-24. Komodo Editor: установка дополнения

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

Dolphin и Root

В незапамятные времена, когда Konqueror был ещё чисто файловым менеджером, и на лавры браузера даже не замахивался, появилась в нём такая опция в контекстном меню – Edit as root для единимчного файла и Open as root для каталога. Было это, повторяю, очень давно, когда во всяких Nautilus'ах и Thunat'ах ничего продобного и в плагинах не было, не то что штатно. Хотя очень хотелось – отсюда в итоге и пошли всякие Nemo  с Marlin'ами, да и особые действия в Thunar'е. А вот в самом Nautilus'е – тоже, конечно, хотелось, да кололось, потому там объявили эту фичу ненужной и народу зело вредящей.

Надо сказать, что в смутное время перехода KDE на 4-ю ветку, и замену Konqueror'а (который из лучшего файлового менеджера того времени превратился в посредственный браузер, а потом и вовсе вышел в тираж) Dolphin'ом фича запуска файлового менеджера, терминала или текстового редактора с правами root'а то исчезала, то вновь появлялась. Пока как штатная функция не пропала вовсе.

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

Обрести этот плагин, казалось бы, просто. Для этого достаточно зайти в настройки Dolphin'а, перейти там в пункт Действия, нажать на длинную педаль Загрузить новые действия, отыскать среди кандидатов на загрузку вышеупомянутый SRAM (не подумайте плохого – это аббревиатура от названия плагина) и нажать на кнопку Установить:

Рисунок 12-25. Dophin: установка дополнений

На скриншоте, как легко догадаться, она находилась бы на месте кнопки Удалить – потому как установить этот плагин я успел до того, как взялся сочинять эту шпаргалку.

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

Казалось бы, SRAM'ота, да и только? Отнюдь, если прочитать то, что пишет по этому поводу автор (там же, по кнопке Сведения). А пишет он, что его плагин (aka плазмоид) надо, кто бы мог подумать, инсталировать.

Так что вопрос придётся решать большей кровью, и на земле своей. То есть отправляться на kde-apps.org, отыскивать там плагин по ключевым словам simple root actions menu, скачивать, разворачивать архив и запускать из него установочный скрипт:

$ ./sram_install -s

Да ещё и прочитавши предварительно README, как предлагает наивный автор.

Правда, в чтении README действительно большой необходимости нет – достаточно только не забыть про опцию -s (об этом сценарий напомнит) просто следовать логике установщика:

Рисунок 12-26. Dophin: установка Simple Root Actions

Она абсолютно прозрачна. Замечу только, что по умолчанию предлагается подключить SRAM к файловым менеджерам Konqueror'у и Dolphin'у, а для редактирования задействовать KWrite и Kate. Но можно ограничиться в первом случае Dolphin'ом (тем более, что при базовой установке Salix'а с KDE Konqueror'а просто нет), а во втором – KWrite, поскольку Kate обычно используется для более серьёзных целей.

Так или иначе, но по завершении установки плагина в контекстном меню Dolphin'а действительно появится пункт Как root, а в нём – несколько подпунктов:

Рисунок 12-27. Dophin: вид меню после установки плагина

Которые позволяют не только открывать каталог или файл с правами администратора, но и поменять атрибуты принадлежности и доступа. И вообще – делают гораздо больше, чем это было когда-то в древнем Konqueror'е. Не в этом ли заключается реальный прогресс?

Поддержка f2fs и nilfs2

На этой странице речь пойдёт о поддержке в Salix'е двух файловых систем, специально предназначенных для твердотельных накопителей – nilfs2 и f2fs. Хотя обе они официально включены в ядро Linux достаточно давно (первая – с 2009 года, вторая – с 2012), ни та, ни другая пока не получили широкого распространения. И, насколько мне известно, штатно не поддерживаются инсталлятором ни одного из современных дистрибутивов, в том числе и инсталлятором Salix. И скоро станет понятно, почему. Однако, как будет видно из дальнейшего, включить их поддержку в нём можно.

Для начала легко убедиться в том, что ядро текущей версии Salix'а собрано с модульной поддержкой обеих интересующих нас файловых систем:

$ ls /lib/modules/3.10.17/kernel/fs/{nilfs2,f2fs} /lib/modules/3.10.17/kernel/fs/f2fs: f2fs.ko

/lib/modules/3.10.17/kernel/fs/nilfs2: nilfs2.ko

После этого соответствующие модули следует загрузить:

$ sudo modprobe nilfs2 $ sudo modprobe f2fs

И удостовериться в успехе этой операции:

$ lsmod | grep nilfs2 nilfs2 147232 0 $ lsmod | grep f2fs f2fs 141479 0

Для работы с любой файловой системой (создания, монтирования etc.) необходим соответствующий инструментарий, и героини моего сегодняшнего рассказа – не исключение. Для f2fs он в виде пакета легко находится в штатном репозитории:

$ slapt-get --search f2fs f2fs_tools-1.2.0-x86_64-1_SBo [inst=нет]: f2fs_tools (Userland tools for the f2fs filesystem)

И столь же непринуждённо устанавливается:

$ slapt-get --install f2fs_tools

А вот за инструментами для nilfs2 придётся лезть в слакбилды:

$ slapt-src --search nilfs nilfs-utils:2.1.5 - nilfs-utils (Utilities for NILFS)

Впрочем, и этот пакет собирается без всяких проблем:

$ sudo slapt-src -i nilfs-utils

Теперь с обеими файловыми системами можно работать – например, я отвёл под каждую из них по флешке объёмом 4 ГБ (больше свободных не было) на предмет последующего сравнения их быстродействия:

$ sudo /mkfs.nilfs2 -f -K /dev/sdf1 $ sudo /mkfs.f2fs -t 0 /dev/sdg1

В первой команде опция -f означает принудительное форматирование – иначе на флешке с существующей файловой системой оно не пойдёт. А опция -K отключает поддержку TRIM, каковая на флешках бесполезна. Аналогичный смысл опции -t 0 во второй команде. У обоих команд есть ещё несколько опций, с которыми можно ознакомиться на соответствующих man-страницах, но мне они показались (пока) не актуальными.

К слову – после включения поддержки наших героинь и установки надлежащего инструментария они появляются и в списке доступных для создания через Gparted:

Рисунок 12-28. Файловые системы f2fs и nilfs2 в меню GParted

Всё это прекрасно, но работает до первой перезагрузки – при старте машины модули поддержки обеих файловых систем сами собой не подгружаются. И обычно практиковавшийся мной в таком случае метод – создание в каталоге /etc/modprobe.d/ соответствующих конфигов, nilfs2.conf и f2fs.conf – не прокатил.

Однако задача, тем не менее, решилась. Ибо в Slackwate для обеспечения загрузки модулей существует специальный файл, /etc/rc.d/rc.modules – симлинк на соответствующий конфиг для текущей версии ядра, в данном случае – /etc/rc.d/rc.modules-3.10.17. В его секцию

### Filesystem support ###

достаточно вписать такие строки:

/sbin/modprobe f2fs /sbin/modprobe nilfs2

чтобы всё стало замечательно.

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

А не тут-то было. При выборе из контекстного меню пункта Подключить том устройство действительно делает вид, что подключается. Но для записи обычным пользователем оно недоступно, пока не переопределишь (от root'а) атрибуты принадлежности и доступа к точке монтирования.

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

А с f2fs получается другая история: она вообще не желает монтироваться от лица обычного пользователя, если не вписать в файл /etc/fstab строку воде такой:

/dev/sdf1 /mount_point f2fs noauto,users,rw 0 0

Где /dev/sdf1 – первое устройство после подключённых постоянно. А точке монтирования нужно задать атрибуты принадлежности нужного пользователя. Причём сделать это обязательно после первого подключения устройства – в этот момент оно самопроизвольно становится принадлежащим root'у. Хотя установленная потом принадлежность пользователю в дальнейшем сохраняется. Об этом глюке я некогда писал. Судя по тому, что с тех пор прошёл год, бага приобрела статус фичи.

Тем не менее, после всего проделанного с устройством, несущим f2fs, можно работать почти нормально. Почти – потому что нет никакой гарантии, что оно будет найдено системой после отключения и повторного включения в том же сеансе. Это относится, кстати, и к nilfs2.

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

Резюмирую базар: в настоящее время и nilfs2, и f2fs представляют чисто академический интерес. Использование каждой из них по отдельности достаточно неудобно, а обе-две вместе вообще уживаются с напрягом. В чём, надо полагать, и заключается причина слабой, мягко говоря, их распространённости.

Поэтому всё сказанное выше – ни в малейшей степени не руководство к действию, а просто узелок на память: кто знает, может, триумфальное шествие SSD-накопителей по пользовательским десктопам побудит довести до ума не одну, так другую. И они будут поддерживаться дистрибутивами уже не для «галочки», а для реальной работы.

Поддержка ZFS

Включение поддержки ZFS было одним из первых моих деяний после установки Salix'а – все мои рабочие данные расположены на zpool'е, который должен быть доступен для всех установленных систем. Иначе они годились бы только «на посмотреть». Правда, я был уверен в успехе решения этой задачи, поскольку из сетевых материалов знал, что в Slackware поддержка ZFS on Linux в принципе существует, а Slackware и Salix – братья навек. Однако всё оказалось гораздо проще, и необходимые пакеты нашлись, не выходя из границ родных репозиториев.

Как и следовало ожидать, поиск по ключевому слову zfs в официальном репозитории результата не дал: бинарные модули для поддержки этой файловой системы имеют мали смысла, так как привязаны к версии ядра. Но зато среди слакбилдов легко обнаружился и zfs-on-linux.SlackBuild, и spl-solaris.SlackBuild. Кроме них, требуется также пакет kernel-headers (был установлен по умолчанию при начальной инсталляции) и исходники ядра той же версии, которая используется в системе. Так что для начала я определил таковую командой

$ uname -a

Linux salix 3.10.17 #2 SMP ...

После чего присвоил себе перманентные права администратора (далее они будут нужны постоянно)

$ sudo -i

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

# slapt-get --i kernel-source-3.10.17-noarch-2

Обращаю внимание, что требуется именно uname -a, потому что uname -r не даёт номера сборки, который не менее важен.

Далее последовательно были собраны требуемые слакбилды – сначала:

# slapt-src -i spl-solaris

а затем

# slapt-src -i zfs-on-linux

Делать это нужно именно в указанном порядке, иначе последует сообщение об ошибке.

Следующий шаг – подключение соответствующих модулей

# sudo modprobe zfs

и проверка результатов этого деяния:

# lsmod |grep zfs zfs 997378 5 zunicode 320867 1 zfs zavl 4875 1 zfs zcommon 32148 1 zfs znvpair 49518 2 zfs,zcommon spl 123549 5 zfs,zavl,zunicode,zcommon,znvpair

Перед импортом существующего пула я не забыл создать каталог – точку монтирования его datasets

# mkdir /home/data

и назначить для него «правильного хозяина»:

# chown -R alv:users data

Обращаю внимание: во всех используемых мной Linux-системах первый пользователь, то есть я, любимый, имеет UID 1000. Если в системах моего читателя это не так (например, есть дистрибутивы, присваивающие первому юзеру UID 500, возможно, существуют и другие варианты), то «право принадлежности» надо указывать в численном выражении. Что же до принадлежности группе и её GID, то в данном (моём) случае это рояля не играет: GID основной группы первого пользователя, как бы она ни называлась словами (users или username) во всех поих случаях равен 1000. Если это важно для читателя – следует учесть и этот фактор.

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

Теперь – самый ответственный момент, импорт существующего пула:

# zpool import -f data

Проверка показывает, что он прошёл успешно:

# zpool status pool: data state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM data ONLINE 0 0 0 sda3 ONLINE 0 0 0 sdb3 ONLINE 0 0 0

errors: No known data errors

Да ещё и все дейтасеты, входящие в пул, сами собой смонтировалсь куда надо:

# zfs mount data /home/data data/media /home/data/media data/other /home/data/other data/proj /home/data/proj data/vbox /home/data/vbox

Так что мой пул данных полностью пригоден к работе...

... увы, до перезагрузки системы. После которой ни малейших следов смонтированных файловых систем zpool'а мы не обнаруживаем. Хотя сам пул задействован, и команда zpool status возвращает правильный ответ, такой же, как раньше. Согласно ZFS on Linux FAQ, это ситуация достаточно обычная (в частности, с ней же я сталкивался в тестовых вариантах Ubuntu Trusty). И тот же документ (в том числе и в русском переводе) предлагает в каждом дистрибутиве, не входящем в его «белый список» (а Slackware в него не входит) решать её силами рук самих утопающих.

Будучи одним из представителей последних, я, конечно, легко решил её командой

$ sudo zfs mount -a

после которой все файловые системы в /home/data оказываются на своих местах. Однако это не дело – заниматься таким безобразием каждый раз после рестарта системы.

Процесс следует автоматизировать. Как? Теоретически рассуждая, разными способами. Я для начала избрал самый грубый, но простой, вспомнив о палочке-выручалочке каждого нерадивого слакварщика – файле /etc/rc.d/rc.local, в который можно запихать всё невпихуемое в другие места. По умолчанию он пуст, но я это быстро исправил, вписав туда строку

zfs mount -a

обеспечивающую монтирование всех файловых систем подключённого пула ZFS при старте системы. А для симметрии добавил в /etc/rc.d/rc.local_shutdown строку

zfs unmount -a

выполняющую обратную процедуру при выходе.

После этого проблем с доступом к файловым системам ZFS больше не наблюдалось. Правда, как легко догадается читатель, до обновления ядра – благо, автоматически оно обновляться не будет, так как входит в состав исключений. Однако если необходимость в пересборке или апгрейде ядра всё-таки возникнет – придётся также пересобрать модули zfs-on-linux и spl-solaris, сами собой они не соберутся.

Пара слов в заключение

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

Приложение. Slackware: дополнительные репозитории

Репозиторий пакетов Slackware содержит далеко не всё, что может понадобиться благородным донам и благородным доннам в их благородном деле – применении этого дистрибутива и его клонов в мирных целях. И потому на этой странице я попытался собрать все известные мне хранилища пакетов и как-то структурировать их, снабдив краткими аннотациями, а также указав, какие из них поддерживают зависимости и, следовательно, предпочтительны для использования в сочетании со slapt-get.

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

Репозиторий Slackware

Slackware Официальный репозиторий пакетов Slackware.Список официальных зеркал Зеркало Яндекса – отдельной строкой, не из патриотических соображений, и не из никзкопоклонства перед маленьким гигантом большого секса поиска, а потому что оно 1) в большинстве случаев оказывается в числе самых быстрых, и 2) провайдеры, сохранившие лимитные тарифы оплаты доступа в Интернет, часто считают трафик с него внутренним и, подобно гусарам, денег не берут.

Интегрированные репозитории

Slackware.org.uk Английский сервер, на котором имеются зеркала репозиториев многих проектов, связанных со Slackware: её клонов, портов на другие архитектуры, сборок отдельных программных комплексов, и так далее (многие из них будут фигурировать далее).

Репозитории прямых клонов

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

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

Slackel Репозиторий соответствующего дистрибутива (адаптации Salix’а), в специфической своей части содержит сборки пакетов для версии Current. Зависимости поддерживаются.

Репозитории общего назначения

SlackBuild.org Наиглавнейший источник слакбилдов.

MLED Репозиторий проекта Microlinux Enterprise Desktop, цель которого – создание наборов пакетов для специализированных систем на базе Slackware. Ветка MLES содержит пакеты серверной ориентации. Зависимости не поддерживаются.

Slacky Репозиторий сообщества Slackware, содержит многочисленные пакеты, дополняющие базовый дистрибутив, поддерживает зависимости.

Slakers Также репозиторий, созданный и развиваемый сообществом. Содержит исключительно 64-битные сборки для версии Current. Хотя по крайней мере отдельные пакеты можно использовать и в стабильной версии. Зависимости не поддерживаются, репозиторий структурирован просто по пакетам.

Репозитории отдельных десктопов и оконных менеджеров

Ktown Репозиторий пакетов для версий KDE, более новых, чем в официальном релизе и в Current. Собраны Эриком Хамелирсом (также известным как Alien Bob, ведущий блогAlien Pastures).

MSB Репозиторий пакетов десктопа MATE, собранных на основе MATE SlackBuilds с GitHub. Зависимости поддерживаются.

CSB Репозиторий пакетов десктопа, собранных на основе Cinnamon SlackBuilds с GitHub. Зависимости не поддерживаются, но установка всех пакетов даёт работоспособную среду Cinnamon.

Slacke17 Репозиторий пакетов оконного менеджера Enlightenment DR17 (E17), поддерживающий зависимости.

Slacke18 То же самое, но для Enlightenment DR18 (E18).

Персональные репозитории

Alien Bob иAlien Restricted Репозитории с различными пакетами, собранными Эриком Хамелирсом, предназначенные для применителей из США и более иных стран, соответственно. Зависимости не поддерживаются.

PONCE Персональный репозиторий Ponce, зависимости не поддерживаются.

Johannes Schoepfer Репозиторий пакетов, собранных Йоханнесом Шёпфером (Johannes Schoepfer) с поддержкой зависимостей.

ZeroUno Репозиторий ZeroUno, он же Маттео Россини (Matteo Rossini), содержит только 64-битные сборки пакетов для Slackware Current.

Nonstop Репозиторий Евгения Ратникова aka nonstop, содержит авторские слакбилды, иногда перекрывается со SlackBuild.org, но кое-чего на последнем нет.

Службы поиска пакетов

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

Pkgs Поиск пакетов для большинства распространённых дистрибутивов Linux, включая Slackware, по имени пакета, имени файла пакета, имени входящего в пакет файла, по зависимостям, а также так называемый «умный поиск» (Smart search).

Оглавление

Глава 1. Общая характеристика, назначение, история 2

Введение 2

Вопросы терминологии 4

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

Появление Salix 9

Salix: что было дальше 11

Глава 2. Стандартная установка 13

Системные требования 13

Подготовка источника установки 13

Личная самоподготовка 15

Стандартная установка 16

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

Глава 3. Варианты установки 25

Введение 25

Особенности установки BASIC и CORE 25

Особенности режима AUTOINSTALL 30

Установка на программный RAID 31

Есть ли особенности при установке на SSD? 33

Установка на ноутбуки 34

Заключение 34

Глава 4. Итоги установки 36

Начальная загрузка 36

Вариант FULL 37

Вариант BASIC 45

Вариант CORE 46

Краткий итог 46

Глава 5. Управление пакетами: slapt-get 48

Введение 48

Управление пакетами: обзор 48

Утилита slapt-get: обзор 51

Утилита slapt-get: применение 52

Пара слов в заключение 55

Глава 6. Управление пакетами: репозитории 57

Серии пакетов Slackware: вместо введения 57

Репозитории Salix 58

Настройка slapt-get 63

Дополнительные репозитории 66

Глава 7. Управление пакетами: Gslapt 68

Обзор 68

Действия с отдельными пакетами 72

Групповые действия с пакетами 74

Настройка Gslapt 76

Краткий итог 79

Глава 8. Управление пакетами: сборка из исходных текстов 80

Что такое slackbuilds 80

Слакбилбы и Salix 82

Утилита slapt-src 84

Глава 9. Управление пакетами: оболочка Sourcery 87

Вступление 87

Пример применения 89

Немного о настройке 94

Глава 10. «Фирменные» утилиты 97

Глава 11. Редакции и сородичи 102

Salix: MATE-редакция 102

Slackel, сын Salix'а: вступление 111

Slackel, сын Salix'а: *box'овые редакции 112

Slackel и Salix: KDE-редакции 124

Salix и Slackel: установка с LiveCD, или проще некуда 130

Глава 12. Разные мелкие полезности 135

Искоренение кириллицы из домашнего каталога 135

Доводка консольного режима: включение мыши в консоли 135

Доводка консольного режима: русификация вывода 136

Thunar и архивы 138

Thunar и права root’а 139

Thunar и поиск файлов 149

Thunar и Яндекс.Диск 152

Шпаргалки по установке пакетов: gThumb 152

Шпаргалки по установке пакетов: GPRename 153

Шпаргалки по установке пакетов: Chromium 154

Шпаргалки по установке пакетов: Мультимедиа 155

Шпаргалки по установке пакетов: выпадающий терминал Tilda 155

Шпаргалки по установке пакетов: VirtualBox 159

Шпаргалки по установке пакетов: Komodo Editor 159

Dolphin и Root 161

Поддержка f2fs и nilfs2 164

Поддержка ZFS 167

Пара слов в заключение 171

Приложение. Slackware: дополнительные репозитории 172

Репозиторий Slackware 172

Интегрированные репозитории 172

Репозитории прямых клонов 172

Репозитории общего назначения 173

Репозитории отдельных десктопов и оконных менеджеров 173

Персональные репозитории 173

Службы поиска пакетов 174

Оглавление

Глава 1. Общая характеристика, назначение, история Введение Вопросы терминологии Предыстория Появление Salix Salix: что было дальше Глава 2. Стандартная установка Системные требования Подготовка источника установки Личная самоподготовка Стандартная установка Предварительный итог Глава 3. Варианты установки Введение Особенности установки BASIC и CORE Особенности режима AUTOINSTALL Установка на программный RAID Есть ли особенности при установке на SSD? Установка на ноутбуки Заключение Глава 4. Итоги установки Начальная загрузка Вариант FULL Вариант BASIC Вариант CORE Краткий итог Глава 5. Управление пакетами: slapt-get Введение Управление пакетами: обзор Утилита slapt-get: обзор Утилита slapt-get: применение Пара слов в заключение Глава 6. Управление пакетами: репозитории Серии пакетов Slackware: вместо введения Репозитории Salix Настройка slapt-get Дополнительные репозитории Глава 7. Управление пакетами: Gslapt Обзор Действия с отдельными пакетами Групповые действия с пакетами Настройка Gslapt Краткий итог Глава 8. Управление пакетами: сборка из исходных текстов Что такое slackbuilds Слакбилбы и Salix Утилита slapt-src Глава 9. Управление пакетами: оболочка Sourcery Вступление Пример применения Немного о настройке Глава 10. «Фирменные» утилиты Глава 11. Редакции и сородичи Salix: MATE-редакция Slackel, сын Salix'а: вступление Slackel, сын Salix'а: *box'овые редакции Slackel и Salix: KDE-редакции Salix и Slackel: установка с LiveCD, или проще некуда Глава 12. Разные мелкие полезности Искоренение кириллицы из домашнего каталога Доводка консольного режима: включение мыши в консоли Доводка консольного режима: русификация вывода Thunar и архивы Thunar и права root’а Thunar и поиск файлов Thunar и Яндекс.Диск Шпаргалки по установке пакетов: gThumb Шпаргалки по установке пакетов: GPRename Шпаргалки по установке пакетов: Chromium Шпаргалки по установке пакетов: Мультимедиа Шпаргалки по установке пакетов: выпадающий терминал Tilda Шпаргалки по установке пакетов: VirtualBox Шпаргалки по установке пакетов: Komodo Editor Dolphin и Root Поддержка f2fs и nilfs2 Поддержка ZFS Пара слов в заключение Приложение. Slackware: дополнительные репозитории Репозиторий Slackware Интегрированные репозитории Репозитории прямых клонов Репозитории общего назначения Репозитории отдельных десктопов и оконных менеджеров Персональные репозитории Службы поиска пакетов Fueled by Johannes Gensfleisch zur Laden zum Gutenberg