Zenwalk
Приобщение к Linux

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

2008-06-25

назад | к началу | вперед

Интермедия 2.1 Кое-что об источниках информации

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

Пользователи Linux, приобщавшиеся к нему в 90-х годах, как правило, имели опыт работы в DOS (а то и в более древних операционных системах, типа CP/M). DOS-программы же никогда не имели стандартизированных интерфейсов. Что само по себе, может, и плохо, но волей-неволей заставляло пользователей, как минимум, обращаться к встроенной помощи, а то и чтению документации. И навык работы с документацией оказывался очень востребованным при переходе на Linux.

Далее, поколение 90-х, по крайней мере, знало о существовании иных операционных систем, таких, как OS/2, о различных надстройках над DOS, таких, как GEM, QuaterDesk, Geoworks — а подчас даже пробовали их использовать на практике. И потому не меряли все, что видели в Linux'е, «подоконным» аршином.

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

Далее, большинство пользователей Windows не имеют привычки к чтению документации. Что, в общем-то, понятно: на элементарном уровне им это не требуется, на более глубоком — легко доступной документации (Windows Help) недостаточно. А та, которой было бы достаточно — весьма трудно доступна (в первую очередь — финансово).

И, наконец, последнее: пользователи Windows, приходящие в Linux, очень часто не имеют самых элементарных навыков поиска нужной информации. Даже в том случае, если она лежит на поверхности. Что, в сущности, вытекает из предыдущего пункта: за каким таким зеленым ее искать, если она или не поможет, или не доступна?

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

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

Первое, и самое главное: помните, что Unix'у — более 35 лет, Lunux'у — скоро стукнет 15, а русскоязычное Linux-коммьюнити благополучно развивается уже около дюжины лет. И большинство вопросов, которые встают перед вами, точно также вставали и перед многими и многими поколениями начинающих пользователей Linux. А поскольку большинство из них остаются пользователями этой ОС по сей день, значит, ответы они нашли. И, более того, скорее всего, ими поделились — на «бумаге» или в Сети, дабы облегчить жизнь последователям. Вполне возможно, что даже и на русском языке— в оригинале ли, или в переводе, не важно.

Второе: большую часть ответов на любые вопросы уже дали сами разработчики систем и приложений— во встроенной системе документации, именуемой man-страницами (man-pages), сопровождающей любой пакет, создающийся в рамках проектов Open Source. И потому всегда должно помнить бессмертные слова, которыми обменялись бы неизвестный молодой человек и Беня Крик, если бы в те времена уже существовал Unix:

— Вы знаете тётю Маню?
— Я знаю тётю Маню.
— Вы верите тёте Мане?
— Я верю тёте Мане. Передайте тёте Мане — Беня знает за man-pages.
почти Бабель

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

Необходимость в этой интермедии выяснилась в ходе обсуждения опубликованных глав и разделов. Сначала я хотел отделаться ссылкой на Кандидатский минимум начинающего линуксоида. Но просмотрев его, обнаружил, что кое-что в нем устарело, кое-что лишнее, а кое-чего, применительно именно к Zenwalk'у, не хватает. И потому данная интермедия, хотя и перекликается, разумеется, с "Кандминимумом", не идентична ему.

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

• Введение
• О файлах
• Основы командного интерфейса
• Диски и дисковые разделы
• Файловые системы
• Файловая иерархия и монтирование
• Практикум по разметке и монтированию
• Аккаунты и права доступа
• Понятие локали
• Консоль против Иксов

Введение

Принято считать, что для установки Windows знать ничего не нужно, тогда как Linux предъявляет очень высокие требования к начальной подготовке пользователя. Оба эти мнения, мягко говоря, спорные. Пользователю современных Windows'ов (XP и Vista), впервые устанавливающему эту систему, не худо бы иметь представление, по крайней мере, о трёх вещах — дисковых разделах, файловых системах и пользовательских аккаунтах.

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

Для потенциальных пользователей Zenwalk'а первоначальный минимум имеет свою специфику. С одной стороны, его инсталлятор не уступает по "дружелюбию" ни одному другому, самому любвеобильному. И потому устанавливает для входящего ничуть не более высокую планку, чем Mandriva или Ubuntu.

С другой же стороны, Zenwalk — это всё-таки трамплин для погружения в глубины Linux'а, и потому чем больше изначально будет знать его потенциальный пользователь, тем лучше. Может быть, его "лишние" знания не будут востребованы в ходе установки, но наверняка пригодятся в дальнейшем.

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

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

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

Но прежде чем переходить к очерченному выше кругу вопросов, необходимо рассказать о краеугольном понятии не только Linux'а, но и всех Unix-подобных операционных систем —

О файлах

Ответить на вопрос, что такое файл в Unix-подобной системе, очень легко: это всё, что в ней существует: собственно файлы в понимании DOS/Windows, объединяющие их каталоги, устройства и многое другое. Даже протекающие в системе процессы и каналы обмена данными между ними тоже предстают перед пользователем в виде файлов. То есть образ файла есть универсальное понятие, обеспечивающее доступ к устройству Unix-подобной системы.

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

И так, среди файлов в Linux выделяются:

• каталоги (directory) — списки имен файлов любого типа (в том числе и каталогов более глубокого уровня вложенности);
• символические ссылки (symlinks) — указатели на файлы любого иного типа; содержание символической ссылки представляет просто описание пути к некоторому другому файлу; нечто подобное в Windows именуется ярлыками; на один и тот же файл может существовать сколько угодно символических ссылок:
• файлы устройств — имена, присваиваемые действительно существующим в системе физическим устройствам (или могущим существовать в ней), от дисков до принтеров и сканеров; выделяются файлы символьных устройств, обмен данными с которыми происходит побайтно (например, последовательные и параллельные порты), и файлы устройств блочных, которые взаимодействуют с окружающим миром наборами байтов — блоками (жесткие диски и прочие накопители);
• именованные каналы (pipes) и сокеты (sockets) — через них осуществляется взаимодействие между протекающими в системе процессами);
• обычные (regular) файлы — всё, что не вошло в перечисленные выше группы; среди обычных файлов можно выделить текстовые, образованные наборами символов, и бинарные, представляющие собой наборы последовательностей нулей и единиц.

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

Основы командного интерфейса

Далее в этой интермедии (и во всей остальной книжке тоже) нам время от времени придется иметь дело с командами. И потому именно сейчас уместно рассмотреть основы командного интерфейса, так называемого CLI (Command Line Interface).

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

Командная директива (или просто команда) — основная единица, посредством которой пользователь взаимодействует с шеллом. Она образуется по определенным правилам, именуемым синтаксисом. Синтаксис командной директивы определяется конкретным шеллом; ниже речь будет идти только о sh-совместимом синтаксисе, свойственном, в частности, командной оболочке bash принятой по умолчанию во всех дистрибутивах Linux, в том числе и в Zenwalk.

Командная директива образуется:

• именем команды, однозначно определяющим ее назначение,
• опциями, определяющими условия выполнения команды, и
• аргументами — объектами, над которым осуществляются действия.

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

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

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

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

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

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

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

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

Порядок опций, если их приводится более одной, для большинства команд не существенен. Хотя, например, для команды tar, создающей файловые архивы, опция -f, значением которой является имя создаваемого или распаковываемого архива, традиционно указывается последней. И, к слову сказать, именно эта команда — одна из немногих, опции которой не обязаны предваряться символами дефиса.

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

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

Большинство команд допускает указание не одного, а нескольких (и даже очень многих) аргументов.

Если в качестве аргумента указан путь к некоему каталогу, возможно рекурсивное выполнение команды — то есть по отношению ко всем входящим в него файлам и вложенным подкаталогам (обычно это задаётся специальной опцией — -r или -R). Вообще рекурсия (то есть определение некоего выражения через самого себя) — очень важное понятие в Unix-подобных системах, пронизывающее их насквозь и служащее основой своеобразного хакерского юмора. Рекурсия применима почти ко всем файловым операциям, позволяя распространить действие одной командной директивы не только на файлы данного каталога, но и на все вложенные подкаталоги и их содержимое.

Командные директивы могут объединяться в командные конструкции. Это очень важный компонент интерфейса командной строки. Они позволяют объединять несколько команд воедино и выполнять различные команды последовательно или параллельно. Для этого служат специальные символы — операторы фонового режима, объединения, перенаправления и конвейеризации.

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

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

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

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

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

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

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

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

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

При конвейеризации команд стандартный вывод первой команды передается не в файл, а на стандартный ввод следующей команды. Оператор конвейеризации — одинарная вертикальная черта (|).

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

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

• создать командную конструкцию, достойную увековечивания;
• поместить ее в простой текстовый файл, который начинается с такой строки: #!/bin/bash (она явным образом задает командный интерпретатор, который будет обрабатывать скрипт, в данном случае — bash);
• присвоить этому файлу право исполнения (для пользователя, создавшего файл, или для всех — см. раздел об аккаунтах).

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

Диски и дисковые разделы

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

Схема дисковой разметки — это правила дробления диска на разделы. Диски в машинах с архитектурой PC (то есть во всех обычных настольных персоналках) могут быть разделены на четыре физических части — так называемые первичные разделы, Primary Partition (почему именно так — здесь обсуждать не будем). Один из этих первичных разделов может быть определен как раздел расширенный (Extended Partition). А уж он может далее делиться на логические разделы (Logical Partition) в практически неограниченном количестве. На самом деле ограничение есть, и оно составляет 63 логических раздела, но я не представляю себе разумной схемы, способной использовать их все.

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

Так вот, некогда в природе существовало только два типа дисковых интерфейсов — IDE и SCSI. Все устройства с интерфейсами первого типа (точнее, конечно, не сами устройства, а соответствующие им файлы) именовались /dev/hda, /dev/hdb (Master и Slave на 1-м канале IDE), /dev/hdc и /dev/hdd (они же на 2-м), и, при наличии дополнительных IDE-контроллеров, так далее. Независимо от того, были ли они жесткими дисками, CD-приводами или, например, Zip-накопителями.

Диски с интерфейсом SCSI величали /dev/sda, /dev/sdb и так далее (очевидно, что для них понятие канала смысла не имело). Причём в эту же линейку имен попадали и файлы любых накопителей с интерфейсом, отличным от IDE, например, внешние диски с USB и FireWire-интерфейсами, флэшки, встроенные и съемные накопители цифровых фотокамер (почему — тайна сия велика есть). А вот CD-приводы со SCSI-интерфейсом назывались иначе — /dev/sr0 и /dev/sr1.

Для CD-приводов любых типов в каталоге /dev, содержащем имена файлов устройств, имелся и специальный файл — /dev/cdrom. Однако он представлял (и поныне представляет) собой символическую ссылку на имя файла реального устройства, например, /dev/hdc.

Дисковые разделы идентифицировались их порядковыми номерами. Цифры с 1 по 4 были зарезервированы за первичными разделами, включая и тот из них, который был определен как расширенный. А логические разделы внутри него нумеровались, начиная с цифры 5. Таким образом, если на мастер-диске первого IDE-канала имелось два первичных раздела, второй из которых определен как расширенный и поделен на три логических, то соответствующие им файлы устройств именовались так:

• /dev/hda1 — первичный раздел;
• /dev/hda2 — первичный раздел, определенный в качестве расширенного;
• /dev/hda5, /dev/hda6 и /dev/hda7 — логические разделы внутри него.

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

И сначала подумали kernel-разрабы, что это хорошо: файлы в каталоге /dev создавались только для устройств, реально существующих в системе, в том числе и съемных. Поначалу это понравилось и пользователям (хотя их никто не спрашивал — но ведь разработчики Linux'а такие же его пользователи, как и все остальные). Действительно, теперь при подключении нового устройства, для которого изначально не было предусмотрено собственного имени файла, не нужно было запускать специальный сценарий создания файлов устройств или, паче того, создавать этот файл вручную, с помощью соответствующей команды, и при этом помнить о допустимых старших и младших номерах устройств (в двух словах — это численные идентификаторы каждого имени файла устройства, а не в двух — нас это более не волнует, хотя сами major- и minor-номера никуда не делись). Да и содержимое каталога /dev можно было охватить если не одним взглядом, то двумя-тремя (в прежние времена для этого нужно было быть стойким Аргусом).

Однако прошло немного времени, и в devfs разочаровались все — и разработчики, и пользователи. У первых резонов к тому было очень много, и останавливаться на них я не буду. А для пользователей основные неудобства сводились к двум моментам.

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

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

• /dev/ide/host0/bus0/target0/lun0/part1 — первый раздел на первом IDE-диске,
• /dev/ide/host0/bus0/target0/lun0/part2 — второй раздел на нем же,
• /dev/ide/host0/bus0/target0/lun0/part5 — первый логический раздел

и так далее. Что это всё значит, расшифровывать не буду, поскольку это давно изжито. Правда, был и менее устрашающий вариант, с обозначением разделов как /dev/discs/disc0/part1, /dev/discs/disc0/part2 и так далее — с тем же значением. А в ряде дистрибутивов сохранилась и старая добрая простота — /dev/hda1 и так далее. Правда, не для сохранности нервов пугливых пользователей, а для понимания программами, разработчики которых так и "ниасилили" devfs. Но в итоге каталог /dev утратил свою обозримость и стал похож не на ветку (файлового) дерева, а скорее на переплетенный терновый куст.

Думаю, читатель уже догадался, что файлы устройств вроде /dev/discs/disc0/part1 или /dev/hda1 — не более, чем символические ссылки на истинные имена, то есть /dev/ide/host0/bus0/target0/lun0/part1. Отчего, впрочем, разбираться с ними не легче. Да и на стадии инсталляции ряда дистрибутивов, таких, например, как Gentoo, когда ошибка в именовании дискового раздела может иметь печальные последствия, этим символические ссылки часто отсутствовали, заставляя пользователя вбивать руками столь устрашающие конструкции.

В результате devfs в современных дистрибутивах Linux отмерла сама собой, и на смену ей пришла программа udev, которая ныне и занимается динамическим созданием файлов устройств и присвоением им имен по определенным правилам. Останавливаться на деталях я не буду (о них можно прочитать, например, здесь, замечу лишь, что она делает это только для реально присутствующих в системе устройств, вследствие чего каталог /dev наконец-то стал действительно обозримым.

Для нас сейчас важно только то, что отныне (и хочется верить, что присно, и вовеки веков) IDE-диски, их разделы и CD-приводы снова стали файлами устройств вида /dev/hda, /dev/hda1, /dev/hdc, SCSI-диски и всякого рода "левые" накопители — /dev/sda и так далее.

Распространившиеся в это же примерно время диски с интерфейсом SATA также виделись программой udev как SCSI-диски (то есть /dev/sda etc.), а SATA-CD-приводы — как устройства /dev/sr0. И это не лишено логики, потому что по принципам своей работы SATA ближе к интерфейсу SCSI, чем к классическому IDE/ATA, который ныне обычно называют PATA.

Таким образом, жить стало проще, стало веселей. Однако это был еще не предел упрощения. Потому что появилась подсистема libata. Сначала она была ориентирована только на SATA-накопители, но позднее к ней прикрутили поддержку PATA. И теперь при использовании libata все диски, независимо от их интерфейса, именуются — /dev/sda, /dev/sdb и так далее. А оптические приводы получают имена типа /dev/sr0 и далее (если это "далее", конечно, есть). Именно таким образом и сконфигурирован Zenwalk, точнее, его ядро, которое грузится при старте с инсталляционного CD и в дальнейшем устанавливается на диск.

Так что всё, что нам надо запомнить для PATA-накопителей, можно представить в небольшой таблицы (табл. 1).

Примечание: предполагается, что слейвом на 2-м IDE-канале является CD-ROM.

Для SATA-накопителей картина будет еще проще (табл. 2).

Понятно, что никаких мастеров и слейвов мы не видим. А последний разъём SATA, как и в предыдущем случае, занят CD-приводом.

И, наконец, резюмируем и разговоры про номенклатуру разделов (табл. 3).

Как можно видеть, первый же по счету логический раздел внутри расширенного получает имя /dev/sda5, несмотря на то, что 4-й из возможных первичных разделов не определён, и файл устройства, который мог бы ему соответствовать, отсутствует.

Для создания (и удаления) дисковых разделов в Linux предназначена специальная утилита — fdisk. Это — тот жупел, которым из поколения в поколение пугали начинающих пользователей Linux. Хотя на самом деле ничего непреодолимо сложного в ней нет — просто она требует определенной аккуратности. И, кстати говоря, лишь в редких дистрибутивах (например, в Gentoo) она непосредственно используется при установке. Обычно же инсталлятор содержит какое-либо "продвинутое" средство дисковой разметки — от простейшего cfdisk до весьма изощренных DiskDruid, DiskDrake или того безымянного самого по себе инструмента, который используется для дисковой разметки в Debian Installer.

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

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

Файловые системы

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

В отличие от Windows, способной работать только с FAT любого рода и с NTFS, Linux в качестве "родных" (native) поддерживает большое количество типов файловых систем: ext2fs, ext3fs, ReiserFS, XFS и JFS. В стадии разработки находится ряд новых, иногда — принципиально новых файловых систем, таких как ext4fs (дальнейшее развитие ext2 и ext3) или Btrfs, интегрирующая в себе управление логическими томами и собственно файловую систему. Однако для практического применения они пока не предназначены, и в ядро Linux их поддержка не включена.

Файловая система ext2fs — старейшая из используемых в Linux. Отличается исключительным быстродействием, совместимостью и достаточно надежна для использования на десктопе. Правда, после системных сбоев (например, по питанию) она обязательно должна проходить проверку целостности, что при современных объемах дисков может занять изрядное время. Да и вероятность повреждения данных не равна нулю. Так что использовать её следует только при наличии источника бесперебойного питания.

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

ReiserFS, XFS и JFS — также журналируемые файловые системы, каждая со своими особенностями. Общее между ними то, что, как правило, все они безболезненно переносят процес выдирания силового кабеля — журналы файловых операций гарантируют целостность файловых систем. Хотя отнюдь не сохранность не записанных на диск данных — так что от необходимости в бесперебойнике они не избавляют.

Конёк ReiserFS — работа с большим количеством маленьких и очень маленьких (в несколько байт) файлов, а таких файлов в любой Unix-системе очень даже много. XFS, напротив, ориентирована на работу с (очень) большими файловыми системами и отдельными файлами мультимедийной направленности, размер которых вполне может составлять не один гигабайт. Ну а JFS, разработка фирмы IBM, — это эпоним журналируемых файловых систем, с нее-то и началось понятие журналирования. Впрочем, никакими другими достоинствами ее Linux-реализация не отмечена, являясь, пожалуй, самой медленной из всего семейства.

В некоторых дистрибутивах одно время включалась поддержка файловой системы Reiser4 (в их числе был и Zenwalk в версиях с 1.3 по 2.8). Это — дальнейшее развитие ReiserFS, представляющее собой уже не только (а может быть, и не столько) файловую систему, а так называемое "пространство имен" (Namespace) для манипулирования дисковыми объектами. Впрочем, официально Reiser4 ядром Linux пока не поддерживается, и я не знаю ни одного из ныне развиваемых дистрибутивов, в котором она поддерживалась бы "из коробки". Ну, а будущее Reiser4 остаётся совершенно неопределённым.

Для создания файловых систем (процесса, именуемого в DOS/Windows форматированием) предназначены специальные утилиты — mkfs.ext2, mkfs.ext3, mkfs.reiserfs, mkfs.xfs и mkfs.jfs, каждая из которых создает соответствующую файловую систему. Кроме того, существует универсальная утилита mkfs: вызванная с соответствующими опциями (какими — описано в man mkfs), она способна создать любую файловую систему из числа поддерживаемых в Linux (включая FAT16/VFAT/FAT32, но не NTFS).

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

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

Раздел подкачки создается специальной утилитой — mkswap, после чего нуждается в активации — это делается командой swapon. Впрочем, практически во всех инсталляторах (яркое исключение — опять-таки Gentoo) и то, и другое выполняется прозрачно для пользователя — достаточно соответствующий раздел определить как раздел подкачки.

Раздел подкачки перекидывает мостик от реальных, то есть лежащих на дисковых устройствах и их разделах, файловых систем к файловым системам витртуальным, которые не следует путать с упомянутой только что виртуальной памятью. В отличие от первых (именуемых также block device based), виртуальные файловые системы не занимают места на диске или разделе, не нуждаются в форматировании и существуют только во время работы машины, воссоздаваясь заново при её рестарте.

Об одной из таких виртуальных файловых систем мы уже говорили — это злополучная devfs, ныне благополучно изжитая. Но в Linux сохранилась (или добавилась) поддержка иных файловых систем — procfs, sysfs и tmpfs. Первые две пользователь может видеть только как наблюдатель, получая из них информацию о протекающих в системе процессах и наличных устройствах. Кстати, программа udev также черпает сведения, необходимые ей для создания файлов устройств, из файловой системы sysfs.

А вот файловой системой tmpfs пользователь в какой-то мере может манипулировать. Это — файловая система в оперативной памяти, во всём подобная "всамделишней", в частности, на неё можно записывать данные и удалять их, причем, поскольку и то, и другое выполняется без обращения к относительно медленным дисковым устройствам, делать это очень быстро. Однако, как и любая виртуальная файловая система, она существует только до тех пор, пока машина работает. Поэтому tmpfs широко используется там для хранения всякого рода временных данных.

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

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

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

Файловая иерархия и её монтирование

И, наконец, файловая иерархия. Сколько бы ни было в системе дисковых разделов и файловых систем на них, для пользователя они предстают в качестве логически единой иерархически устроенной файловой системы древовидного облика (правда, дерево это выглядит поставленным с ног на голову). В основании ее лежит корень (root, символически обозначаемый как /). Обязательными же ветвями являются каталоги — /boot (в нем хранится всё необходимое для загрузки системы, включая её ядро), /bin и /sbin (место помещения исполняемых файлов общесистемных программ), /etc (каталог для общесистемных конфигурационных файлов), /dev (каталог для файлов устройств, о которых недавно шел разговор), /var и /tmp (каталоги для всякого рода регулярно изменяемых данных), /usr, где имеет место быть большинство пользовательских программ со всем сопровождающим их инвентарем типа библиотек и документации, /home — место пользовательских каталогов для данных.

Перечисленные ветви вовсе не обязаны быть единой частью файловой системы в физическом смысле. Напротив, каталог /home почти всегда лежит на отдельном дисковом разделе, отдельные физически файловые системы часто составляют и такие ветви, как /usr, /var и /tmp. Возможно и много более дробное разбиение файлового древа.

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

$ mount -t vfat /dev/hda1 /mnt

включит в файловую иерархию Linux, в каталог /mnt, раздел Windows с файловой системой VFAT или FAT32.

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

Кроме упомянутой выше опции -t, определяющей тип файловой системы, команда mount имеет еще массу опций (см. man mount). И "дюже умные" инсталляторы подчас предлагают, кроме создания раздела, файловой системы, определения точки монтирования, еще и включить те или иные из них (о чем поговорим подробнее в следующем разделе).

Как правило, инсталлятор распознает и "чуждые" файловые системы, такие как FAT любого рода и, в некоторых случаях, NTFS, и также обеспечивает (по умолчанию или после запроса и подтверждения пользователя) их автоматическое монтирование.

Файловые системы, расположенные на сменных носителях (CD, DVD, флэш-драйвы, внешние винчестеры с интерфейсом USB или FireWire и так далее — вплоть до встроенных и сменных накопителей цифровых камер), при старте системы не монтируются. Этот выполняется по мере надобности — с помощью упомянутой выше команды mount. Однако инсталляторы, как правило, в силах установить наличие, по крайней мере, CD/DVD-приводов (еще бы, ведь, скорее всего, дистрибутив с них и устанавливается) и создать в /etc/fstab запись, обеспечивающую монтирование по упрощенной форме, например

$ mount /mnt/cdrom

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

• имя файла устройства или дискового раздела;
• точка монтирования;
• тип файловой системы;
• опции монтирования — для временно используемых файловых систем это поле должно иметь значение noauto, запрещающее монтирование при загрузке системы, и, скорее всего, user (через запятую), разрешающее монтирование от лица обычного пользователя; по умолчанию это имеет право сделать только root;
• условия проверки и "дампа" — для временно используемых файловых систем тут можно ограничиться нулями.

После этого процедура монтирования сведётся к команде mount с одним аргументом — либо точки монтирования, либо имени файла устройства, и необходимости в каких-либо опциях также не возникнет.

Перед выключением машины (или перезагрузкой системы) все задействованные файловые системы должны быть в обязательном порядке размонтированы, что проделывается автоматически при корректном завершении сеанса командами halt или reboot. В большинстве случаев на современных материнских платах стандарта ATX корректное завершение сеанса обеспечивается и выключением машины кнопкой Power (но не выдергиванием силового кабеля) — при этом отрабатывается тот же сценарий, что и при программном отключении системы.

Если в течение рабочего сеанса возникнет потребность, например, сменить компакт в CD-приводе или извлечь флэш-драйв — размонтирование нужно выполнить явным образом, командой umount. Которая в любом случае потребует одного аргумента, точки монтирования или имени файла устройства.

Во многих современных дистрибутивах к редактированию файла /etc/fstab, ручному монтированию и размонтированию устройств приходится обращаться только в исключительных случаях. Корректным монтированием файловых систем при старте системы, как уже говорилось, озаботится программа установки. Что же до сменных носителей — их монтирование обеспечивается механизмом HAL (Hardware Abstration Layer), в результате чего сменные носители монтируются прозрачно для пользователя — сразу же при подключении соответствующего устройства или вставки носителя в привод.

Правда, отключение сменных носителей при использовании механизма HAL потребует от пользователя некоторых манипуляций. А именно — щелчка правой клавишей на пиктограмме рабочего стола, соответствующего CD/DVD или флэш-драйву (USB-винчестеру), и выбора из появившегося контекстного меню — в первом случае пунктов Отмонтировать и затем Извлечь, во втором — пункта Безопасно извлечь. Правда, для CD-приводов в большинстве случаев тот же результат достигается и просто нажатием на кнопку открытия лотка.

Механизм HAL не использует описаний из файла /etc/fstab, и потому никаких дополнений в него вносить не нужно, более того, они могут лишь помешать его работе.

Именно такая схема обращения со сменными носителями используется в дистрибутиве Zenwalk. Точнее, в используемой им по умолчанию рабочей среде Xfce — в отличие от команды mount, представляющей собой часть системного окружения ядра, механизм HAL является атрибутом не системы, а именно интегрированных рабочих сред (GNOME, KDE, Xfce). Поэтому в "голой" консоли, без загрузки какого-либо из перечисленных выше десктопов, никакого автоматического монтирования и размонтирования не будет. Как и в случае, если рабочая среда будет заменена каким-либо менеджером окон.

Практикум по разметке и монтированию

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

Для начала определимся — сколько разделов необходимо для установки Linux? Обязательными считаются два — под корневую файловую систему и под своппинг; именно такая схема разметки предлагается многими инсталляторами по умолчанию. Современные дистрибутивы обычно требуют в типовой установке не менее 2-3 Гбайт дискового пространства — и это без учета пакетов, которые, возможно, придется доустанавливать впоследствии. Так что отвести под Linux 5-7 Гбайт при нынешних объемах дисков будет не внапряг — я последнее время, дабы не ломать голову рассчетами, отдаю под это 10 Гбайт. Что же до раздела подкачки — его размер традиционно определяется равным удвоенному объему оперативной памяти и, опять-таки во избежание ломки головы, остановимся на этой величине.

Часто можно услышать мнение, что при типичных современных объемах оперативной памяти (от 1 Гбайт и более) раздел подкачки не нужен вообще. Резон в этом есть — при указанных объемах памяти своппинга в штатных ситуациях практически не происходит никогда. Однако, возможно, в последующем вам может захотеться использовать файловую систему в оперативной памяти — tmpfs — и задействовать ее, например, под промежуточные продукты компиляции. А поскольку оценить потребное под них место весьма трудно (OpenOffice.org, например, желает под это дело несколько гигабайт), возникает риск переполнения соответствующей файловой системы.

Так что повторюсь еще раз: не стоит жмотничать, и лучше отдать под раздел подкачки один-другой гигабайт, нежели потом сожалеть о его отсутствии. Единственное ограничение касается случая, если оперативной памяти ну очень много (более 2 Гбайт — ныне это уже не фантастика, а реальность). Дело в том, что 32-битные версии Linux'а (а Zemwalk именно таков) не поддерживают объем виртуальной памяти (то есть RAM+Swap) более 4 Гбайт (на самом деле лимит ещё ниже, около 3,3 Гбайт), так что раздел подкачки в 4 Гбайт просто не будет использован.

Вернемся, однако, к корню файловой иерархии. Широким жестом отведя под него 5, 7 или даже 10 Гбайт, мы не учли одного: собственно пользовательских данных (а не ради них ли все и затевалось?). А потому под них нужно выделить собственный раздел (и, возможно, не один — см. ниже). Какого размера? Вам виднее, сколько данных у вас имеется (и предвидится). Обычно тут руководствуются одним из трёх принципов — сколько нужно, сколько есть или сколько не жалко.

Итак, приходим к выводу о необходимости трех разделов — под корень, под своппинг и под каталог /home. Однако это не предел дискодробительства: в ряде случаев на отдельные разделы целесообразно вынести такие ветви файлового древа, как /usr, /var и /tmp, а иногда и еще более глубоко лежащие каталоги, вроде /usr/local (для самостоятельно собираемых пользователем пакетов) и /usr/src (для исходников ядра и, как в Zenwalk'е, также и всех пакетов, устанавливаемых штатным образом).

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

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

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

В-третьих, в дистрибутивах типа Zenwalk, где нет необходимости в хранении таких вещей, как дерево портов, множества скачанных дист-файлов к ним и тому подобного антуража Source Based дистрибутивов, дробное разбиение диска под общесистемные каталоги просто не нужно.

А вот каталог /home целесообразно разбить на несколько подкаталогов, каждый на своем разделе. Почему это удобно? Ответить нетрудно. Сами по себе пользовательские каталоги представляют собой отдельные ветви каталога /home, имеющие вид /home/username1, /home/username2 и так далее. И основное их содержание — это так называемые dot-файлы, содержащие пользовательские настройки различных утилит и приложений. Они далеко не всегда создаются лично пользователем, но обычно возникают сами собой — при первом запуске соответствующей программы. Они совсем небольшие, но их очень много, и отыскать среди них собственно файлы и каталоги с пользовательскими данными нелегко.

Поэтому я последнее время отказался от выделения раздела под каталог /home — все пользовательские каталоги (впрочем, у меня их обычно всего два) лежат в общем дереве корневой файловой системы. Вместо этого я создаю в каталоге /home подкаталоги типа /home/works, /home/soft, /home/docs, /home/media (для рабочих материалов, скачанных из сети программ и дистрибутивов, документации и всякой мультимедии соответственно). И в каждый из них монтирую файловую систему на собственном разделе. Нужно только не забывать устанавливать для них соответствующие права доступа для обычного пользователя (пользователей), о чем будет сказано со временем.

Кроме того, при некоторых обстоятельствах может понадобиться ещё и небольшой (в диапазоне 30-100 Мбайт) раздел в самом начале диска. В качестве загрузчика Zenwalk, как мы увидим со временем, использует Lilo. Однако если планируется использовать на машине много (более двух) операционных систем или активно экспериментировать с разными ядрами, то целесообразно заменить его загрузчиком GRUB, а для него такой специальный раздел, задействуемый под каталог /boot, будет далеко не лишним.

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

Какие разделы создавать под Linux — первичные или логические? Если ограничиться минимально необходимыми — /, swap, /home, — это значения не имеет: три раздела можно сделать и первичными (и еще один Primary Partition останется про запас — например, для Windows).

Однако если прибегнуть к более дробной схеме разметки или использовать более двух операционок, практически неизбежным становится создание логических разделов в Extended Partition. Причем никаких ограничений на их использование давно уже нет — на логических разделах могут лежать и корневая файловая система, и swap, и даже /boot (не говоря уже о всех прочих). Правда, /boot разработчики GRUB'а рекомендуют все же помещать на первичный раздел, причём монтировать его не автоматически, при старте системы, а руками — по мере возникновения потребности (например, для установки нового ядра.

Файловые системы... Тут есть немало поводов поломать голову. Если, конечно, не следовать умолчаниям инсталлятора. А он, скорее всего, предложит нынче по умолчанию ext3fs для всех ветвей файлового древа. С этим можно смело соглашаться — это будет вполне разумным (хотя и не всегда идеальным) выбором, особенно для корневой файловой системы. Выбор же файловых систем для ветвей каталога /home — вопрос скорее привычки и личных препочтений. Так, под каталог для рабочих материалов есть смысл задействовать ReiserFS, на раздел для мультимедийных файлов поместить XFS и так далее.

Выше упоминалось об опциях монтирования. На данном этапе нас интересуют лишь некоторые из них (а имя им — легион). Это — опции noatime и nodiratime, запрещающие обновлять время последнего доступа к файлам и каталогам соответственно, что на десктопе мало для чего нужно. Это несколько способствует повышению быстродействия файловых операций в любом случае. А для файловой системы ReiserFS, в сочетании со специфичной для нее опцией notail, препятствующей упаковке мелких "хвостов" файлов, этот выигрыш становится видимым невооруженным (тестами) взглядом.

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

Отступление. Все, что было сказано выше касательно разметки дисков, исходило из молчаливого допущения, что Linux устанавливается на чистый диск, причем в качестве единственной операционной системы. Либо — на диск, содержимым которого можно пожертвовать. Либо, наконец, просто на второй физический диск. Случай, когда на диске должны уживаться две операционные системы, рассмотрен в Интермедии 3.1.

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

Аккаунты и права доступа

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

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

За одним-единственным исключением — в системе имеется, как правило, пользователь с логином root (не путать с корневым каталогом), по русски называемый обычно суперпользователем или администратором. Он обладает правами на изменение всех файлов и каталогов системы, в том числе и общесистемных. Именно от лица суперпользователя следует производить настройку системы и устанавливать всякие дополнительные программы.

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

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

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

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

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

Команда sudo используется обычно для выполнения единичных директив, которые указываются в качестве её аргумента. После этого следует запрос на пароль пользователя, давшего команду (а не администратора!). После его ввода директива исполняется.

В отличие от su, которая работает всегда и (почти) везде, команда sudo требует некоторой настройки, которая по умолчанию в Zenwalk не выполнена. Этим мы займемся в главе 4.

Понятие локали

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

Так, страна Россия (RU) подразумевает русский же язык (ru); это не так очевидно, как кажется — страна Украина кроме украинской же локали имеет также и русскоязычную. Многоязычие свойственно и локалям многих других стран — классическим примером тут является Швейцария с её четырьмя государственными языками и, соответственно, четырьмя же локалями. А для английского языка, напротив, свойственно участие в локалях очень многих стран (Великобритания, США, Канада, Австралия и так далее)

Для локали ru_RU характерной особенностью является изобилие наборов символов (charset, называемые также кодировками): KOI8-R, CP866, CP1251, ISO8859-5 и еще несколько полузабытых или мало используемых. Такое положение сложилось исторически и не влекло за собой ничего кроме путаницы. И потому в последнее время на роль универсальной, отменяющей кодировки, локали претендует UTF8. Правда, пока желаемой унификации с ее помощью не достигнуто, но прогресс в этом направлении виден невооруженным глазом.

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

Установки правильной локали недостаточно для полной русификации системы. Для этого требуется также подключение кириллических шрифтов и раскладок клавиатуры с поддержкой кириллицы (причем и те, и другие должны быть в нужных кодировках или иметь таблицы соответствия кодировки ввода кодировке вывода), а также переключателя с латиницы на кириллицу. Соответствующие действия обычно выполняются инсталляторами. Причем в одних случаях они распространяются и на текстовый, и на графический режим, в иных же — только на последний. И тогда дело кириллизации консоли предоставляется самому пользователю. Как именно это делается в общем случае — распространяться не буду, на сей счет существует немеренное количество руководств. А применительно к Zenwalk'у вопросы русификации будут рассмотрены в главе 4.

Консоль против Иксов

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

Так вот, Linux изначально предназначался для работы в текстовом режиме. В коем и поддерживает все видеокарты, соответствующие стандарту VESA — то есть все, изготовленные человечеством за последние полтора десятка лет. Правда, в ядре его есть и поддержка собственно графического режима — через так называемый линейный кадровый буфер (frame buffer). Однако программ, использующих такой режим, очень немного, возможности их ограничены, и используются они редко.

Основным же способом вывода графики в Linux является оконная система X (X Window System) или, в просторечии, Иксы. Это — не часть Linux'а, а именно самостоятельная система, предназначенная для работы поверх любых Unix-подобных операционок (и не только их). Тем не менее, она стандартно входит во все дистрибутивы Linux общего назначения, за исключением специализированных (например, сугубо серверных). И часто устанавливается по умолчанию.

Установить Иксы мало — их нужно еще и должным образом настроить. В понятие это входит определение видеокарты, характеристик монитора, мыши, установка экранного разрешения и так далее. С большинством вопросов, касающихся распознавания "железа", успешно справляются инсталляторы юзерофильных дистрибутивов, и соответствующие параметры устанавливаются автоматически (хотя тут часто допустимы и ручные коррективы). А вот доведение до конца локализации предоставляется пользователю: он может указать желаемую клавиатурную раскладку (например, русскую), ее вариант (в современных условиях обычно winkeys — для Windows-маркированных клавиатур), переключатель с латиницы на кириллицу и так далее.

Однако и настройкой Иксов дело не заканчивается. Так как сама по себе оконная система X не способна выполнить никакие пользовательские задачи. Для этого она требует специальной программы — менеджера окон или интегрированной рабочей среды (так называемого пользовательского десктопа).

И, наконец, последнее. Традиционный способ авторизации в Linux — задание логина и пароля в текстовом режиме. После чего Иксы можно (и обычно — нужно) запустить вручную специальной командой. Однако возможна и автоматическая загрузка Иксов при старте системы — и сейчас в юзерофильных дистрибутивах именно это, как правило, и практикуется. В этом случае авторизация происходит посредством специальной программы — десктоп-менеджера. Который, помимо всего прочего, позволяет обычно выбрать менеджер окон или интегрированную среду. Авторизация в графическом режиме принята по умолчанию и в дистрибутиве Zenwalk.

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

Как легко догадаться, все man-страницы пишутся на международном языке IT-индустрии, сиречь английском. Однако целый ряд людей (и в этом ряду следует выделить Виктора Вислобокова и Алексея Махоткина) не поленились переводить их на язык родных осин — и немало в этом преуспели. Именно эти переводы по большей части и включаются в «хорошо русифицированные» дистрибутивы отечественного происхождения. Однако использовать их и в дистрибутивах «заграничных», вроде нашего Zenwalk'а, никто не запрещает.

Весь вопрос упирается в получение этих самых переводных man-страниц — не покупать же или не качать ради этого Altlinux, ASPlinux или MOPS.

Долгое время наиболее полная (и, что немаловажно, актуальная с точки зрения версий) коллекция переводов man-страниц лежала на сайте Виктора Вислобокова. Однако в данный момент сайт находится в процессе перестройки и коллекция эта недоступна. Тем не менее, воспользовавшись поиском через Google, легко найти и другие подборки, например, вот эту.

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

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

Так что старайтесь читать тётю Маню в подлиннике. И поверьте — английский язык man-страниц очень простой, тем паче что многие из них написаны вовсе не англичанами, и не с оксфордским образованием.

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

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

• Виктора Вислобокова — как мне кажется, самая полная и регулярно обновляемая; правда, как уже говорилось, в связи с реконструкцией сайта в данный момент она доступна не полностью, но ведь реконструкция когда-нибудь да закончится, верно?;
• Linux-Ярославль, созданная когда-то Александром Благиным; правда, она не обновляется года с 2004-го, но благодаря содействию (или попустительству) администрации, существует по сей день; всё, что было до того по-русски, там есть;
• Opennet.ru — сайт Максима Чиркова; он обычно воспринимается как новостной портал, но там есть очень много документации, причём не только по Linux, но и по BSD и Unix вообще;
• Citforum — хотя это преимущественно сайт с авторскими материалами (о чем скажу чуть позже), но документации там тоже много, причем кое-какая — уникальна.

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

Полноты картины ради следует отметить еще один источник информации — официальную документацию в формате info. Подобно man-страницам, они сопровождают практически каждый пакет Open Source и, в большинстве случаев, идентичны им по содержанию. В отличие от man-страниц, документация в формате info обладает зачаточными гипертекстовыми средствами, и потому некоторые полагают её более удобной. Что до меня, я считаю info-страницы одним из самых запутанных изобретений человеческого разума в этой области.

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

В своем мнении относительно документации info я не одинок: например, Пер Лиден, разрабатывая свой дистрибутив CRUX, предусмотрел в нем систему безжалостного искоренения любой документации, кроем man-страниц (в том числе и документации info).

К сожалению (моему и моих единомышленников) некоторые очень важные пакеты, особенно разрабатываемые непосредственно в рамках проекта GNU (например, GRUB) в man-формате содежат только краткую свой характеристику, за более подробными сведениями отсылая к документации info. Так что волей-неволей к ней иногда приходится обращаться.

Если вы не нашли ответов на свои вопросы на man- и info-страницах, а также в прочих, официальных и полуофициальных, документах, следует обратиться к материалам авторским — то есть специально описывающим те или иные вопросы в виде статей и заметок (обычно на основе личного опыта авторов). Таких тоже немало на разных сайтах, в том числе и на упомянутых выше Citforum и Opennet.ru. Кроме того, существует чисто авторский сайт (пожалуй, чуть не единственный в Рунете) — POSIX.ru, созданный и поддерживаемый одноимённой командой, в которой состоит и ваш покорный слуга.

Нельзя объять необъятное, и возможно, что какие-то важные вопросы останутся неохваченными в перечисленных выше источниках. Тут впору поискать нужное среди коллекций ссылок на другие ресурсы. Наиболее полная из них: Виртуальная энциклопедия, уже много лет (с 1999 года) поддерживаемая Виктора Костромина. В ней содержатся ссылки на практически все русскоязычные материалы, относящиеся к Linux и Unix; кстати, собственные материалы автора и коллекции документов там тоже представлены.

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

Решив всё же задать вопрос на форуме, для начала определитесь — на каком? От конкретных рекомендаций воздержусь — это вопрос не просто личный, а, я бы сказал, интимный. Форумов Linux-тематики в Рунете без счета, пожалуй, что и поболее, чем подборок документации и коллекций ссылок. И всегда можно выбрать наиболее подходящий для себя— как по содержанию, так и по стилю общения. Упомяну здесь только, что существует единственный «чистый» (то есть не несущий другого контента) форум — Linuxforum, рассматривающий все вопросы Linux, Unix и Open Source.

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

Кроме того, не следует забывать и о поиске в глобальном масштабе — на сей предмет существует Google а на нем — специальный раздел, посвященный Linux — http://www.google.ru/linux. Об этом разделе почему-то не очень любят говорить вслух, однако обращение к нему резко сужает круг поисков, ограничивая его только сайтами соответствующей тематики. Тем самым сокращается время поиска и возрастает его релевантность.

Использование поисковых систем требует грамотного составления запросов, иначе даже если ограничиться Linux-тематикой Google, можно получить такое количество информационного «шума», что нужные сведения в нем просто будут заглушены. Умение «гуглить» (сочетание to google не так давно принято в английском языке в качестве официального термина) достигается только опытом. Для начала хорошо бы внимательно ознакомиться с опциями расширенного поиска и посмотреть, как они отражаются в строке запроса. Это самый простой способ разобраться с синтаксисом сложных запросов и научиться составлять таковые, что называется, из головы.

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

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

Отдельная история — «бумажные» книги по Linux и Unix. Их в настоящее время издано великое множество— как переводных, так и оригинальных, актуальных, несколько устаревших и полностью морально самортизированных — посвященных описанию конкретных версий определенных дистрибутивов, ныне, возможно, и не существующих в том виде, в каком они имели место быть в момент подготовки книги к изданию. Типичный пример тому — издававшиеся в изобилии книга про Red Hat, ныне разделившийся на существенно различные ветки — коммерческую RHEL и свободную Fedora.

Впрочем, я вообще не рекомендовал бы покупать (и тем более читать) книги, описывающие конкретные дистрибутивы: книг по Zenwalk'у вы на полках магазинов не увидите (надеюсь, что пока), а детальные описания rpm-based или deb-based систем в освоении системы нашей мало помогут. Предпочтительнее читать общие книги по Linux и UNIX.

В качестве примера, вслед за Бернардом Шоу, могу сказать: читайте меня. В частности, книгу Доступный Unix. Конечно, с ней можно ознакомиться и в онлайне, в частности, на этом сайте она лежит под названием Введение в POSIX'ивизм . Однако в «бумажном» варианте исправлены ошибки, выявленные при обсуждении на форумах, кое-где она чуть-чуть сокращена (за счет беллетристики), кое-где— немного дополнена (за счет технологии). В общем, это не совсем идентичные сочинения.

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

И, наконец, статьи о Linux в компьютерных журналах. Нынче, в связи с популярностью этого слова в широких кругах околокомпьютерной общественности, обусловленной известными причинами— делом Поносова, выступлениями депутата Алксниса за Русскую ОС, пилотными проектами по внедрению Linux'а в школах, — материалы на эту тему печатают практически все журналы IT-напрвленности. В том числе и те, что еще недавно шарахались от самого слова Linux, как чёрт от ладана. Однако во всех общекомпьютерных изданиях материалы эти появляются эпизодически (исключение — журнал Системный администратор, публикующий статьи по Linux и BSD-системам систематически :) ).

Однако есть на Руси и специализированный журнал, печатающий только материалы по Linux, BSD-системам и свободному программному обеспечению вообще — Linuxformat, российская версия одноименного английского журнала.

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

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

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

Всё сказанное выше касалось источников информации по Linux'у вообще. А затронув man-страницы и документацию info, я и вовсе сильно забежал вперед. Ибо дистрибутив Zenwalk устроен так, что на начальной стадии его освоения вполне можно обойтись без помощи тёти Мани, одно упоминание которой вызывает у новичков священный ужас. Хотя, как уже отмечалось, тётка она совсем не страшная, а как раз напротив — добрая и душевная, в чем мы убедимся при углубленном изучении дистрибутива Zenwalk и Linux'а вообще: тут уж без неё никуда.

А пока есть смысл обратиться к штатной документации проекта Zenwalk. Как я уже говорил, она доступна на официальном сайте проекта в формате pdf и в виде xml-исходника для него; из последнего, теоретически расссуждая, можно при желании сгенерировать нормальный html-документ.

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

Недостаток подробностей и неудобство формата частично восполняется Zenwalk Wiki, в которой содержится ряд дополнительных сведений, как то:

• How to по вопросам инсталляции, загрузки, сборки ядра, локализации, в том числе кириллической и даже японской, и так далее;
• традиционный FAQ;
• раздел, посвященный совместимости со всякого рода «железом»;
• ряд других материалов.

Однако и Zenwalk Wiki в основном англоязычна, имея франзузскую, немецкую, венгерскую, итальянскую, польскую и испанскую версии, но не русскую.

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

Практически неотъемлемой частью дистрибутива Zenwalk является интегрированная рабочая среда XFce. Хотя никто не запрещает использовать с ним KDE или GNOME, не говоря уже об оконных менеджерах (в репозиториях имеются как минимум Window Maker и Fluxbox, возможно, и другие — специально не искал. Однако скажу по собственному опыту использования Zenwalk'а совместно с KDE — в этом случае он не производит того впечатления стремительности, как при штатном Xfce. А уж если из последнего запускать KDE-приложения — быстродействие дистрибутива вообще испаряется.

Так что ознакомиться с документацией Xfce как минимум не вредно. Она доступна непосредственно из дистрибутива в каталоге /usr/share/xfce4/doc/C/, не требуя выхода в Интернет. Частично эта документация переведена и на другие языки, в том числе на русский (правда, только в части, касающейся файлового менеджера Thunar).

Еще более подробная документация имеется на официальном сайте проекта Xfce, Правда, тут уже нет и намека на русский язык.

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

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

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

Его (то есть свободный софт — А.Ф.) создали и отдали вам бесплатно люди, которые вложили в него много личного времени, не прося ничего взамен. В конце концов, не затруднит ли вас воздать им по заслугам, вложив немного своего времени, прежде чем жаловаться, что программа работает не так, как её аналог в ОС Windows".

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

назад | к началу | вперед