Мастерство работы в Unix

Citkit, 23 марта 2006 г

• Вступление
• Что такое Unix
• Пользователь Unix - кто он?
• Три метода решения пользовательских проблем в Unix
• Читать или не читать?

Вступление

Работа есть работа,
Работа есть всегда...
Булат Окуджава

Это - наброски к книге, которая, возможно, никогда не будет написана до конца. Идея ее, как легко догадаться, навеяна замечательной книгой Эрика Реймонда The Art of Unix Programming (в русском переводе - Искусство программирования для Unix. М.: Издательский дом "Вильямс", 2005, 544 с.). Каковую стоит прочитать каждому - даже тем, кто и в мыслях не держал сочинять программы ни для Unix, ни для какой-либо другой операционной системы. В ней идеолог движения Open Source наглядно демонстрирует, как, руководствуясь полутора десятками основополагающих принципов, следует сочинять программы. И, более того, приводит примеры программ, написанных на основе этих принципов.

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

Для начала - о заглавии. Как назвал свою книгу Эрик - я уже говорил. Но следует помнить, что английское Art передается русским словом "искусство" не вполне адекватно. Также, как и производное от него слово Artist означает вовсе не обязательно актера на сцене, а скорее художника - творца в самом широком смысле этого слова. То есть русским эквивалентом к нему выступил бы Мастер. Точнее, конечно, псевдо-русским - но в языках-источниках, опять-таки, этому слову придается совсем другой смысл. Потому я и позволил дать своим заметкам такое заглавие - Мастер работы в Unix.

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

Другое дело - Работа в Unix. Работа, как еще встарь отметил великий поэт, есть всегда. И даже тогда, когда предметом ее оказывается то, что со стороны показалось бы в лучшем случае развлечением, а то и блажью - а со временем мы увидим, что деятельность создателей Unix и Linux могла бы предстать именно в таком качестве. Но: "Настоящая работа всегда груба и яростна" - эти слова героя "Территории" Олега Куваева вовсе не перечеркивают то, что она при этом остается "радостным искусством"...

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

Где-то близ середины второго тысячелетия до нашей эры (или, как нынче принято говорить среди бывших коммунистов-атеистов, до Рождества Христова), на просторах Ближнего Востока появились "колесничные народы" - индоевропейцы, выходцы из евразийских степей. Наиболее известны из них арии, давшие правящую династию царства Митанни. Но к тому же общевосточному колесничному койнэ принадлежали, вероятно, и касситы - покорители Вавилонии, и гиксоссы, завоевавшие Нижний Египет, в него органично вписались хетты Анатолии и микенские греки-ахейцы. А отклики колесничной культуры достигли кельтов на Западе, индоариев Индии на Юге и Китая эпохи Чжоу - на Востоке.

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

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

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

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

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

К чести его, колесничного бойца, заметим: все исторические источники говорят, что он предъявляемым требованиям соответствовал. Подтверждением чему будут и так называемый Эпос Пентаура (тот самый, в котором описываются подвиги Рамзеса II в битве при Кадеше), и Махабхарата, повествующая о почти фантастических колесничных поединках между Пандавами и Кауравами, и Записки о Галльской войне Цезаря, Гая Юлия - он застал последних колесничных бойцов древней Британии, и более поздние свидетельства ирландских скел, сохранивших память ушедшей эпохи.

Не правда ли, если присмотреться к компонентам, определившим успех "колесничных народов", можно увидеть картину, знакомую по IT-индустрии? В основании которой окажутся:

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

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

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

Что такое Unix

Термин Unix и не вполне эквивалентный ему UNIX используется в разных значениях. Начнем со второго из терминов, как более простого. В двух словах, UNIX (именно в такой форме) - зарегистрированная торговая марка, первоначально принадлежавшая корпорации AT&T, сменившая за свою долгую жизнь много хозяев и ныне являющаяся собственностью организации под названием Open Group. Право на использование имени UNIX достигается путем своего рода "проверки на вшивость" - прохождения тестов соответствия спецификациям некоей эталонной ОС (Single Unix Standard - что в данном случае можно перевести как Единственный Стандарт на Unix). Процедура эта не только сложна, но и очень недешева, и потому ей подверглись лишь несколько оперционок из ныне здравствующих, и все они являются проприетарными, то есть представляют собой собственность неких корпораций.

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

• Sun с ее SunOS (более известной в миру под именем Solaris);
• IBM, разработавшая систему AIX;
• Hewlett-Packard - владелец системы HP-UX;
• IRIX - операционка компании SGI.

Кроме этого, собственно имя UNIX применяется к системам:

• True64 Unix, разработанная фирмой DEC, с ликвидацией коей перешедшая к Compaq, а ныне, вместе с последней, ставшая собственностью той же Hewlett-Packard;
• UnixWare - собственность компании SCO (продукту слияния фирм Caldera и Santa Cruz Operation).

Будучи проприетарными, все эти системы продаются за немалые (даже по американским масштабам) деньги. Однако это - не главное препятствие к распространению собственно UNIX'ов. Ибо общей их особенностью является привязка к определенным аппаратным платформам: AIX работает на серверах и рабочих станциях IBM с процессорами Power, HP-UX - на собственных машинах HP-PA (Precission Architecture), IRIX - на графических станциях от SGI, несущих процессоры MIPS,True64 Unix - предназначена для процессоров Alpha (к сожалению, в бозе почивших). Лишь UnixWare ориентирована на "демократическую" платформу PC, а Solaris существует в вариантах для двух архитектур - собственной, Sparc, и все той же PC. Что, однако, не сильно поспособствовало их распространенности - вследствие относительно слабой поддержки новой PC-периферии.

Таким образом, можно видеть, что UNIX - это понятие в первую очередь юридическое. А вот за термином Unix закрепилась технологическая трактовка. Так в обиходе IT-индустрии называют все семейство операционных систем, либо происходящих от "первозданной" UNIX компании AT&T, либо воспроизводящих ее функции "с чистого листа", в том числе свободные ОС, такие, как Linux, FreeBSD и другие BSD, никакой проверке на соответствие Single Unix Standard никогда не подвергавшиеся. И потому их часто называют Unix-подобными.

Широко распространен также близкий по смыслу термин "POSIX-совместимые системы", которым объединяется семейство ОС, соответствующих одноименному набору стандартов. Сами по себе стандарты POSIX (Portable Operation System Interface based on uniX) разрабатывались на основе практики, принятой в Unix-системах, и потому последние все являются по определению POSIX-совместимыми. Однако это - не вполне синонимы: на совместимость со стандартами POSIX, претендуют операционки, связанные с Unix лишь косвенно (QNX, Syllable), или несвязанные вообще (вплоть до Windows NT/2000/XP).

Чтобы прояснить вопрос взаимоотношений UNIX, Unix и POSIX, придется немного углубиться в историю. Собственно, история этого вопроса подробно рассмотрена в соответствующей главе книги "Свободный Unix: Linux, FreeBSD и другие" (в ближайшее время выходит в издательстве БХВ-Петербург) и в статьях по истории Linux и BSD-систем. Поэтому я зафиксирую внимание только на нескольких моментах, слабо освещенных в указанных материалах, но важных для темы данного раздела (да и всех этих набросков вообще).

Операционная система Unix (точнее, ее первый вариант) была разработана сотрудниками Bell Labs (подразделения компании AT&T) в 1969-1971 годах. Первые ее авторы - Кен Томпсон и Деннис Ричи, - делали это исключительно для собственных целей, в частности, для того, чтобы можно было развлекаться любимой игрой StarTravel. И по ряду юридических причин сама компания не могла использовать ее как коммерческий продукт. Однако практическое применение Unix нашлось довольно быстро. Во-первых, она использовалась в Bell Labs для подготовки разного рода технической (в том числе патентной) документации. А во-вторых, на Unix базировалась коммуникационная система UUCP (Unix to Unix Copy Programm - программа копирования из Unix в Unix). Запомним эти первые сферы практического применения Unix - это потребуется нам уже в следующем разделе).

Другая сфера применения Unix в 70-х - начале 80-х годов прошлого века, оказалась совсем необычной. А именно, в исходных текстах она распространялась среди научных учреждений, ведущих работы в области Computer Science. Целью такого распространения (оно не было вполне свободным в нынешнем понимании, но фактически оказывалось весьма либеральным) были: образование и исследования в вышеуказанной области знаний.

Однако "мрачные бородатые хакеры из университетских лабораторий" не ограничились самообразованием и исследованием, а активно занялись разработкой самой Unix, результаты которой как инкорпорировались в "материнскую" систему, так и создавали собственные варианты этой системы, из которых наибольшую известность получила система BSD Unix, созданная в Университете Беркли, Калифорния. Которая, постепенно освобождаясь от проприетарного кода первозданной Unix, в конце концов, после драматических перипетий (подробно описанных здесь), дала начало современным свободным BSD-системам - FreeBSD, NetBSD и другим.

Одним из наиболее важных результатов работы университетских хакеров оказалось (1983 год) внедрение в Unix поддержки протокола TCP/IP, на котором основывалась тогдашняя сеть ARPANET (и который стал основой основ современного Интернета). Это стало препосылкой к доминированию Unix во всех сферах, связанных со Всемирной Сетью. И это оказалось следующим практическим применением этого семейства операционок - к тому времени о единой Unix говорить уже не приходилось. Потому что она, как было сказано ранее, обособились две ее ветки - происходящая от первозданной UNIX (со временем она получила имя System V) и система берклианского происхождения. С другой же стороны, System V легла в основу тех разнообразных проприетарных UNIX'ов, которые, собственно, и имели юридическое право претендовать на это имя.

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

Именно на стандарты POSIX опирался Линус Торвальдс, создавая "с нуля" (то есть не используя ранее существовавшего кода) свою операционную систему - Linux. А та, быстро и успешно освоив традиционные сферы применения Unix-систем (разработка софта, коммуникации, Интернет), со временем открыла для них и новую - настольные пользовательские платформы общего назначения. Что и обеспечило ее популярность в народе - популярность, превосходящую таковую всех прочих Unix-систем, вместе взятых, как проприетарных, так и свободных.

Далее речь пойдет о работе в Unix-системах в самом широком смысле этого слова, без учета всякого рода торговых марок и прочих юридических заморочек. Хотя основные примеры, относящиеся к приемам работы, будут взяты из области свободных их реализаций - Linux, в меньшей степени FreeBSD, и еще в меньшей - из прочих BSD-систем.

Пользователь Unix - кто он?

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

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

Далее - коммуникации и Интернет. Естественно, что в круг пользователей Unix попадают администраторы локальных сетей, web- и ftp-серверов, файловых серверов организаций и серверов баз данных. То есть - потенциально все, имеющие отношение к этим областям IT-индустрии.

Столь же очевидна роль Unix-пользователей в образовании и исследованиях в области Computer Science. Однако этим его образовательная роль не исчерпывается. Именно на Unix-машинах обучаются так называемой "компьютерной грамотности" студенты естественно-научных и инженерных специальностей, вплоть до геологов, геофизиков, океанологов, во многих множествах университетов мира (к сожалению, наша страна тут часто оказывается несчастливым исключением). Возможно, что в дальнейшем этим "некомпьютерным" студентам дела с Unix иметь и не придется - что ж, изучение его можно рассматривать как элемент базового инженерного или естественно-научного образования, подобно общей физике или матанализу.

А потом - кто знает? Человек предполагает, а судьба располагает. Могу сослаться на свой опыт: университетские курсы по термодинамике и физхимии (каюсь, весьма скверно усвоенные в промежутках между полевыми работами, пьянками с аморалками и изучением спецпредметов - примерно таков был ряд приоритетов нормального советского скубента-геолога) для меня оказались востребованными уже через год-два работы. А лет 20 спустя я с удовольствием вспоминал об университетском курсе программирования на Мир-2 с ее Алголом - который также оказался совсем не лишним.

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

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

Тут впору вспомнить лозунг, активно продвигаемый энтузиастами и их сообществами: Linux - на каждый десктоп! То есть поговорить и превращении Linux (в данный момент выступающего как ипостась Unix вообще - просто как самая массовая ОС этого семейства) в столь же массовую систему, как MS Windows любого рода. И задаться парой вопросов: возможно ли это? и нужно ли?

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

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

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

На Unix никогда не перейдут запойные игроманы и те, кто использует компьютер исключительно в качестве развлекательного центра. И причины понятны: игр под Linux катастрофически мало, и нет в нем ничего, что оправдывало бы смену ОС для домашней аудио- и видеостанции.

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

Аналогично - с теми, для кого необходимо работать с векторной, пусть даже технического плана, графикой. А также - активными пользователями CAD-систем. Разумеется, в мире Unix и Open Source есть кое-какие векторные рисовалки и CAD-системы, но ни те, ни другие для профессионального использования практически не пригодны.

Так кто же остается в сухом остатке, кроме разработчиков софта и профессиональных администраторов компьютерных сетей, а также занятых в первую очередь образованием и самообразованием энтузиастов? И вот тут пора вспомнить о двух первых, в историческом плане, сферах практического применения Unix: обработке текстов и коммуникациях (включая общение в Глобальной Сетью). Разве не к этому сводятся потребности (в первую очередь сугубо профессиональные) многих и многих пользователей компьютеров? Вынужденных удовлетворять их посредством заведомо избыточного Word'а и однозначно убогих Outloock'ов с Internet Explorer'ом.

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

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

Три метода решения пользовательских проблем в Unix

Спасение утопающих -
дело рук самих утопающих
Ильф и Петров

Нет, наверное, прикладной программы - будь она под DOS или Windows, Unix или MacOS, свободной или проприетарной, бесплатной или коммерческой, - использование которой не создавало бы время от времени каких либо проблем, требующих разрешения. Однако бытует устойчивое мнение, что наибольшее количество проблем возникает при пользовании именно свободных и бесплатных программ под Unix, конкретно - под Linux и BSD. Как, впрочем, чревато проблемами и использование самых этих ОСей. По крайней мере, сообщениями о такого рода проблемах полны форумы соответствующей тематики.

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

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

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

Достоинства первого метода очевидны. Разобравшись в проблеме и найдя ее решение самостоятельно, пользователь приобретает:

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

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

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

Безусловно, официальная документация проектов Open Source - могучий инструмент познания. Как сказал собеседник Бени Крика, оставшийся неизвестным: "Вы знаете тетю Маню?" - Я знаю тетю Маню", - ответил ему Беня. - "Вы верите тете Мане?" - "Я верю тете Мане"...

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

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

Однако предположим, что наш начинающий пользователь тем или иным образом прорвался сквозь тернии начальных проблем, неизбежных при освоении "чужой" системы. Превратившись, тем самым, в пользователя "действующего". Однако почивать на лаврах ему не придется: ведь проблемы возникают и у "действующих" пользователей, в том числе и достаточно опытных. И тут перед ними в полный рост встает второй недостаток самостоятельного их решения. Который легко сформулировать, процитировав бессмертный афоризм Козьмы Пруткова: "Нельзя объять необъятное". Что применительно к нашим условиям можно трактовать как невозможность одинаково глубокого изучения всех аспектов устройства и использования свободных ОС и (особенно) их приложений.

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

О втором методе - платной поддержке, фирменной или индивидуальной - я, к сожалению (или - к счастью?) сказать ничего не могу, кроме самых общих соображений. К услугам фирменной техподдержки, обещаемой многими майнтайнерами дистрибутивов, в том числе отечественных, ни разу не довелось обращаться. Что же до индивидуального эникейства - похоже, в области софта Open Source это занятие популярности не приобрело. В отличие от Windows-сферы, где установка и настройка системы и программ для нее обеспечивало хлеб насущный (или, по крайней мере, пиво насущное) не одному поколению пользователей с некоторым опытом...

Остается третий метод - обратиться к другу-понимальщику. Метод идеальный - ведь "друг всегда уступить готов место в лодке и круг". Правда, для этого надо, чтобы друг такой был - тот самый, с которым пройдены тысячи километров по горам и долам, с кем съедены пуды соли и выпиты цистерны водки. И который сделает для вас все. Правда, и самому нужно быть готовым сделать для него все. Но это - лишь один момент. Второй же - чтобы друг этот был еще и понимальщиком в той проблеме, которая возникла - а вот с этим уже сложнее: ведь возможных проблем немало, а друзей, по определению, много не бывает...

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

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

Содержание основных сайтов Рунета, посвященных тематике Unix, Linux и Open Source, весьма разнообразно. Там можно найти и переводы официальной документации проектов, и переводные же статьи с зарубежных (точнее, иноязычных) онлайновых источников, и более или менее подробные оригинальные статьи, и краткие советы по частным вопросам. Объединяет их одно: все эти ресурсы создаются и поддерживаются на голом энтузиазме. И потому содержат лишь то, что интересно (или в данный момент нужно) авторам материалов и переводчикам. Так что ожидать, что на сайтах найдутся решения на все случаи жизни - было бы несколько опрометчиво.

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

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

Во-первых, следует по возможности избегать так называемых "дурацких" вопросов (я никого не хочу обидеть этим определением: "дурацкие" вопросы задают и весьма умные люди - в тех сферах, в которых они не вполне компетентны). Таковыми традиционно считаются вопросы, лишенные всякой конкретики. Прекрасный образец "дурацкого" вопроса был дан классиками советской фантастики: "Дорогие товарищи ученые! Третий год у меня в подполе раздается какой-то стук. Объясните, пожалуйста, откуда он берется" (А. и Б. Стругацкие, "Понедельник начинается в субботу").

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

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

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

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

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

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

Как избежать повторяющихся вопросов? Большинство форумов имеет функции поиска (те же, что таковой не имеют - вряд ли заслуживают наименования форума, их практическая польза сведется к нулю после недолгого времени функционирования). Далеко не всегда эти поисковые средства идеальны (чай, не Google), однако с некоторых попыток близкие темы отыскать удается. И лучше задать вопрос в такой, уже существующей, близкой по смыслу, теме, нежели плодить очередной топик: в крайнем случае, модератор перенесет ваш вопрос куда надо, или просто выделит в "отдельное производство". Разумеется, при соблюдении все того же второго условия.

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

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

"Дар красен отдарком" - эта древняя мудрость не потеряла своего значения и по сей день. И в ответ на дружескую услугу, как я уже говорил, всегда следует быть готовым оказать услугу ответную. О каком же ответе может идти речь в данном случае? Да все проще пареной репы: с вами поделились своими знаниями - и вы должны быть готовым ими же поделиться в ответ. Как? Элементарно: описать решение своей проблемы, на форуме ли, в виде ли статьи на сайте, заметки в блоге, и так далее - форм представления информации может быть немерянно. В расчете на то, что ваши материалы помогут кому-либо решить свои проблемы.

И тут мы возвращаемся к тому, с чего начали: к первому методу решения пользовательских проблем. Ведь чтобы поделиться способом решения какой-либо проблемы, в ней следует разобраться более или менее досконально. Благо, уже сказано, как: путем поиска в Google и аналогичных службах, чтения сетевых и литературных источников, сообщений на форумах. И, конечно же, изучения документации. Таким образом, способствуя увеличению общего количества информации на тему Open Source. И, рискну добавить словами одного из персонажей куваевской "Территории", увеличивая суммарное количество добра на земле. Ибо поделиться с другими в благодарность за полученное - это единственный к тому способ. По крайней мере, я другого не знаю...

Читать или не читать?

Расплата за ошибки -
Она ведь тоже труд.
Хватило бы улыбки,
Когда под ребра бьют...
Булат Окуджава

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

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

Правда, существуют системы - так называемые user-ориентированные дистрибутивы Linux (их еще называют дружественными к пользователю), которые, казалось бы, позволяют на первых порах не обременять себя изучением документации. Тогда как другие системы (все BSD и дистрибутивы Linux, в свое время метко названные "дружественными к админу") заставляют вникнуть в документацию с первых шагов их освоения. А наиболее яркие их представители (например, один из дистрибутивов Linux - Gentoo) в обязательном порядке требуют этого еще до установки системы - иначе пользователь, пожалуй, и установить-то ее сможет разве что случайно.

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

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

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

Аналогичный случай и с освоением работы в Unix. Конечно, большинство пользователей его с чего-либо юзерофильного - результаты опросов и личные наблюдения позволяют предположить, что обычно в этой роли выступает дистрибутив Linux под названием Mandrake (ныне Mandriva), на протяжении многих (в масштабах времени индустрии) лет удерживавший пальму первенства в отношении "любви к пользователю". И, опять-таки, в большинстве случаев это оправданно: Windows-подобие таких систем позволяет отодвинуть постижение законов POSIX-мира (а чтение документации, как уже было сказано, один из них) на неопределенный срок. Однако в конце концов ситуация может обернуться вполне по анекдоту о поручике Ржевском. Помните, как он ответил на вопрос дамы, любят ли гусары своих лошадей?

И потому всегда находились и находятся индивидуумы, которые не хотели бы, даже случайно, оказаться в положении лошади, любимой гусарами Ахтырского полка. И вот для них-то вполне приемлемым вариантом первого выбора может оказаться Linux-дистрибутив типа Gentoo или, скажем, любая из BSD-систем. Только нужно помнить: в этом случае никакого снисхождения к их неопытности от окружающего мира ждать не приходится. И законы его придется постигать сразу. Хорошо это или плохо - обсуждать, опять-таки, не будем: главное, чтобы сделанный выбор был осознанным, сопровождаясь пониманием всех возможных последствий.