Рецепты против принципов
Однако опять вернемся к рецептам и принципам. Худо-бедно, но с развлечениями на компьютерах можно справиться посредством первых. А вот с производством любого рода? Рассмотрим это на примере более-менее близкой мне области - работы с текстами, претендующими на оригинальность (то есть выдумываемыми из головы).
Подобно нашему видеолюбителю, профессиональный текстовик, пересев с пишущей машинки (или с письменного стола со стопой бумаги и паркеровской авторучкой) за компьютер, быстро узнает множество простых рецептов, как то: нажав клавишу Insert, он может забить неправильно введенный текст (как забивочные листки на машинке, только проще), клавишами Delete или Backspace можно уничтожить лишнюю букву (в отличие от замазки, без следов), и так далее.
Жить нашему текстовику становится лучше, становится веселей. Но еще не до конца. Потому как он узнает об управляющих последовательностях, с помощью которых может мгновенно переместиться в требуемое место текста и продолжить набор-редактирование, о глобальном поиске и замене, об автоматической проверке правильнописания, и о многом, многом другом.
Однако суть работы текстовика при этом не меняется, как не меняется и стиль мышления. И то, и другое по прежнему линейно, оригинальный текст создается от начала и до конца, как и за пишущей машинкой, расширяются только возможности возврата к написанному и внесения в него корректив. И потому следующая мысль - а не структурировать ли текст изначально, внеся соответствующую разметку рубрик, подрубрик, параграфов? И вот это - уже скачок качественный, ведь для структуризации (ненаписанного еще) текста последний весь, целиком, уже должен быть вот здесь, в ... (ну, сами знаете где).
К слову сказать, современные ворд-процессоры WYSIWYG-типа пользователя к такой структуризации отнюдь не стимулируют. За ненужностью народу, вероятно. В одной книжке про Word мне как-то встретилась фраза, что стилевая разметка - это штука очень сложная, которая по силам только высоким профессионалам. Простым людям, видимо, проще вручную придавать заголовку каждой главы кегль и начертание (и при этом помнить, какое оформление было придано Главе 1, какое - Главе 2, и так далее).
Впрочем, я опять отвлекся, перестройка мышления текстовика - тема совершенно отдельная. Вернемся к принципам. С созданными и отредактированными текстами подчас приходится продолжать работать - делить на фрагменты, соединять, извлекать части одного документа и вставлять в другой. И вот тут-то и обнаруживается неэффективность рецептов.
Возьмем простую задачу - создание единого документа из нескольких существующих, причем - включенных в определенной последовательности. Мне этот пример кажется очень показательной, и я не устаю его повторять. Можно: открыть документ 1, перейти в его конец, щелкая мышью по контекстному меню (или даже воспользовавшись существующим рецептом - макрокомандами с привязанными к ним горячими клавишами), вставить туда документ 2, и так далее. Быстрее, конечно, чем подклеивать бумажные листы силикатным клеем, но все ли это, что может компьютер?
Нет, если узнать (или вспомнить) несколько принципов более общего порядка. Любой документ - есть файл. Любой файл может быть выведен на устройство вывода (экран или, скажем, принтер). А любой вывод может быть перенаправлен с одного устройства вывода на другое. Но ведь любое устройство вывода - тоже файл. Значит, вывод любого файла может быть перенаправлен не в файл устройства, а в другой, например, текстовый, файл. Остается только отыскать команду, которая это сделает. И такая команда легко находится - это cat. В результате конструкция
$ cat file1 file2 file3 > file-all
создаст нам результирующий документ в один присест. Причем составные части его расположатся в той последовательности, в какой нам нужно - в соответствие с порядком аргументов команды cat. И, если мы заранее озаботились тем, чтобы структура наших рабочих файлов хоть как-то коррелировала (не обязательно плоско-линейно, но по какому-либо принципу) со структурой итоговой работы (а это та самая структуризация мозгов, о которых я говорил чуть раньше) - результирующий документ будет структурирован должным образом, причем без всяких дополнительных усилий.
Задача обратная - поделить наш правильно (!) структурированный документ на отдельные части в соответствие с его внутренней структурой (например, разбить книгу на главы, как это обычно требуется для представления в издательство). Для автоматизации процесса нам достаточно знать о другом относительно общем понятии - регулярных выражений, причем лишь в той его части, которая описывается термином шаблон (pattern). И задача сводится к тому, чтобы отыскать в нашем файле строки, начинающиеся последовательностью символов Глава и каждую последовательность символов в промежутке записать (то есть вывести) в самостоятельный файл. Что можно сделать многими способами, но один из них - штатен и элементарен, это команда split (в BSD) или csplit (в Linux).
Последний пример показывает, что, хотя понимание принципов и не избавляет уж совсем от обращения к рецептам, но зато позволяет вычислить последние при их незнании. Дело в том, что в BSD команда split универсальна, и служит для разделения файла по любому параметру - размеру, номеру строки или шаблону. Одноименная же команда в Linux выполняет только первые две функции, опции -p (--pattern) в ней не предусмотрено. Что поначалу может расстроить. Однако если понимать, что в принципе разделение файлов по шаблону почти ничем не отличается от такового по номеру линии или размеру (и то, и другое суть действия, основанные на анализе последовательности символов), остается только изыскать соответствующий рецепт. Что можно сделать просто в лоб - поискать слово split в каталоге с man-страницами командой grep (строго говоря, не слово, а последовательность символов, и командой zgrep, так как страницы эти обычно в gzip-сжатом виде). Чем и обнаруживается man-страница с описанием команды csplit, прочитать которую - уже вопрос элементарной грамотности.
Следующий пример соотношения рецептов и принципов касается установки пакетов. Пользователь любого прекомпилированного дистрибутива быстро усваивает простые рецепты управления оными. Таким рецептом в rpm-based дистрибутивах Linux является команда вида
$ rpm -ihv package_name.rpm
прекрасно работающая в штатных ситуациях. Однако что делать, если пакет таким образом не устанавливается (например, вследствие нарушения зависимостей), работает не так, как ожидалось, или просто отсутствует? На помощь приходит понимание принципов распространения свободных программ - в исходных текстах, - и принципов их сборки, универсальных и не зависящих ни от дистрибутива, ни даже от операционной системы. А понимание принципов сборки, в свою очередь, способствует проникновению в суть дистрибутив-специфичного пакетного менеджмента...
Но особенно явно превосходство принципов над рецептами выступает при конфигурировании всего и вся - от общесистемных опций до шрифта меню конкретного приложения. Рецептурный подход - использование специализированных средств настройки, оформленных в виде самостоятельных утилит или встроенных в прикладные программы. Самостоятельные утилиты такие многочисленны и разнообразны, не зря же Владимир Попов как-то заметил, что число утилит конфигурирования давно превзошло количество конфигурируемых параметров. Интерфейс у них разный в разных дистрибутивах, да к тому же еще и может меняться от версии к версии. Так что доскональное знание какого-либо DrakX из Mandrake ничем не поможет при работе с sysinstall из FreeBSD, и наоборот.
Если же не "поступаться принципами" - достаточно раз и навсегда понять, что все параметры настройки системы описываются в соответствующих конфигурационных файлах, которые суть обычные тексты, могущие быть открытыми в любом текстовом редакторе и там модифицированными надлежащим образом. Что и проделывают, только в завуалированном виде, все настроечные утилиты.
Что касается объектов конфигурирования, то есть соответствующих файлов, и субъектов оного - параметров настройки, - то они определяются стандартными утилитами работы с текстами, например, командой find - для поиска файлов по маске, и командой grep - для изыскания в них подходящих по смыслу фрагментов. Ну и, разумеется, осмысленного анализа результатов того и другого...
Вопреки сложившемуся убеждению, для этого не обязательно быть Unix-гуру или к таковому обращаться. Во-первых, тот же гуру даст, скорее всего, именно конкретный рецепт на злобу дня. Во-вторых, многие вещи в системе настраиваются один раз в жизни, и вполне возможно, что наш гуру благополучно забыл о том, как именно он это делал. Так что своей просьбой вы просто вынуждаете его вторично проделать ту самую цепочку логических рассуждений, отталкивающихся от общих принципов, которую вы легко (и с пользой для духовного самосовершенствования) могли бы проделать сами.
И еще к слову - с успехом (надеюсь) применяя принципиальный подход к жизненно важным для работы настройкам, можно не поступаться принципами и при настройке вещей развлекательного свойства. Например: звуковая карта определена и в ядре настроена правильно, соответствующий софт установлен и работает, но mpeg-файлы, скажем, воспроизводиться не желают.
Вероятно, в user-ориентированных дистрибутивах существуют какие-нибудь специальные утилиты для настройки этого хозяйства, и можно обратиться к ним. А можно просто вспомнить, что звук воспроизводится устройством, устройство есть файл, а файл имеет определенные атрибуты принадлежности (хозяину, то есть пользователю имя_рек, группе и всем прочим) и атрибуты доступа (в просторечии именуемые правом чтения, исполнения и изменения). И остается только проверить, а имеет ли данный пользователь должные права доступа к этому файлу? И если выясняется, что файл /dev/audio открыт для всеобщего использования во всех отношениях - посмотреть, а не есть ли его имя лишь символическая ссылка на файл реального устройства, отвечающего за воспроизведение звука, и проверить права доступа к нему.
И опять к слову: понятие атрибутов принадлежности и доступа, одно из краеугольных в Unix-системах, существует и в тех Windows, которые можно назвать всамделишними (то есть NT/2000/XP, даже в ME вроде бы есть зачатки - семейный доступ в систему и прочее). Да вот только пользователи их об этом часто не подозревают.
Не потому, что чайники, а потому, что их от этого знания тщательно оберегают.
В результате к нештатным ситуациям (например, потере пароля - кто от этого застрахован, все мы люди, все мы человеки) пользователи Windows оказываются просто морально не готовы: нужно дергаться, звать админа, даже (страшно подумать) лезть в книги (не для того ли мы отказывались от man- и info-страниц?) для поиска рецептов, соответствующих ситуации.
А в Unix (вернее, Linux/*BSD, за прочие не скажу по незнанию) - все просто, если помнить о файле (файлах) паролей, однопользовательском режиме (или возможности загрузки с внешнего носителя) и о том, что дисковые устройства нужно монтировать (насколько я знаю, в NT сотоварищи диски тоже как бы монтируются, только "дружелюбно" и "прозрачно" для пользователя; в итоге ему остается только удивляться сообщениям об ошибках, выдаваемых при неправильном извлечении USB-драйва).
В общем, подведу итог. Рецептурный подход вполне приемлем при потребительско-развлекательных задачах. И оказывается, мягко говоря, не самым эффективным при задачах производственно-креативных. А отработав принципиальный подход на них, становится уже в лом искать, какая кнопочка отвечает за масштабирование окна данной программы воспроизводства видео... Проще задать сиюминутную геометрию в командной строке или (раз навсегда) в соответствующем конфигурационном файле.
В я вскользь упоминал, что FreeBSD видится мне более подходящей системой для приобщения к POSIX'ивизму, нежели какой-либо из user-ориентированных дистрибутивов Linux. И теперь я могу высказать первый к тому резон: отличие этой ОС от Windows с первых же шагов проступает столь явственно, что не рождает даже мысли об использовании "подоконных" приемов работы.
Конечно, такие Source Based дистрибутивы Linux, как Gentoo, уже на стадии установки оставляющие пользователя наедине с командной строкой и текстовым редактором, еще более гармонируют с методом "большого болота". Однако для совсем уж неподготовленного юзера болото может оказаться чересчур уж глубоким.
FreeBSD же предлагает начинающему пользователю достаточно взвешенный подход: на первых порах можно положиться на умолчания системы, не идеальные, но разумные. А в дальнейшем, по мере накопления знаний и умений, все больше и больше вмешиваться руками.
Тем не менее, основной десктопной платформой среди открытых ОС выступает Linux. И среди Linux'ов также можно подобрать подходящие (можно сказать, модельные) объекты для постижения истин POSIX-мира. Многие поколения пользователей входили в этот мир через Linux Slackware. Однако в настоящей книге в качестве таких модельных систем выбраны два близкородственных дистрибутива - Archlinux и CRUX.
Может возникнуть вопрос - почему я остановился на относительно мало распространенных представителях этого семейства?
Во-первых, концепция их построения, в частности, обособление базовой системы от опциональных (и сугубо альтернативных) пользовательских приложений, подчеркивает системную целостность Linux как ОС.
Во-вторых, как это ни парадоксально, оба эти дистрибутива, казалось бы, отнюдь не ориентированные на начинающего пользователя, весьма просто устроены - почти так же просто, как и FreeBSD.
В третьих, Archlinux и CRUX, не смотря на близкое (можно сказать, генетическое) родство, демонстрируют разный подход к дистрибутивостроению вообще. Первый - это полнофункциональная система, включающая необходимый набор пользовательских приложений (сохраняющая, тем не менее, относительную компактность и обозримость), развертываемая за считанные минуты и позволяющая перейти к практической работе после нескольких несложных манипуляций. CRUX же - это скорее база для построения системы собственной - хотя и тут этот процесс можно осуществлять параллельно с выполнением пользовательских задач.
Наконец, я просто хотел привлечь внимание к этим достойным представителям Linux-семейства, отнюдь не пользующихся известностью - причем незаслуженно.
Я вовсе не навязываю свой выбор в качестве истины в последней (да и в любой другой) инстанции. Однако с чего-то начинать нужно - почему бы не начать с одной из перечисленных систем? Тем более, что начинающий POSIX'ивист должен четко понимать - выбрать с первого же раза дистрибутив или ОС, идеально подходящий к его задачам, потребностям, наконец, просто индивидуальным склонностям можно только при исключительном везении.Скорее всего, ему придется перепробовать не одну систему, прежде чем окончательно определиться в своих предпочтениях. Однако полученные навыки и знания лишними не окажутся в любом случае.
